Est-il pratique d'authentifier un serveur Linux contre AD?

Nous utilisons à la fois un serveur Windows et Linux dans notre société de développement de logiciels.

L'un des points de friction avec cette configuration est que nous n'avons pas de solution de connexion unique. Étant plus une boutique Microsoft qu'une boutique Linux, nous voulons nous authentifier contre AD.

J'ai lu quelques articles en ligne et je comprends que cela soit possible.

Nous utilisons actuellement les services suivants sous Linux qui nécessitent une authentification:
- serveur git (via SSH)
- Sendmail
- serveur Web Apache utilisant actuellement des fichiers .htaccess.
- Partages de fichiers SAMBA

Ce que je veux savoir, c'est à quel point ce type de configuration est pratique? Cela fonctionne-t-il vraiment ou est-il sujet aux erreurs?

Ce n'est pas difficile et c'est parfaitement pratique.

Nous avons quelques centaines de machines de bureau à double démarrage qui utilisent l'authentification AD ainsi qu'un certain nombre de serveurs qui utilisent l'authentification AD pour permettre aux clients Windows d'utiliser leurs partages Samba sans l'authentification explicite des utilisateurs.

Il y avait un autre article sur SF sur ce que vous devez faire.

Fondamentalement, vous devez configurer kerberos, winbind, nss et pam.

Ensuite, vous faites un kinitet un net ads joinet votre place.

Vous pouvez configurer pam pour utiliser plusieurs méthodes d'authentification si vous le souhaitez, donc si l'une ne fonctionne pas, elle reviendra à la suivante.

Nous utilisons généralement des fichiers, winbindd et ldap pour les serveurs servant des partages de fichiers aux serveurs Windows.

Si possible, j'utiliserais LDAP pour les informations de compte et Windbind strictement pour l'authentification, mais je pense que vous pouvez mapper les attributs dans Je pense /etc/ldap.conf si vous en avez besoin. Si vous finissez par utiliser winbindd pour les informations de compte, il est possible d'utiliser le RID (méthode de hachage) pour générer des uids / gids, mais il est également possible d'utiliser d'autres méthodes. Nous avons utilisé des RID sur un grand serveur de fichiers et cela a été très difficile, alors j'essaierais d'explorer l'une des autres options si possible. Dans notre cas, tous les utilisateurs et groupes AD sont reflétés dans LDAP par un système IDM en amont, nous utilisons donc LDAP pour les informations de compte sur les serveurs plus récents et utilisons winbind uniquement pour l'authentification.

L'authentification est absolument simple en utilisant Likewise Open. http://www.likewise.com/products/likewise_open/index.php

Presque toute mon infrastructure Linux a centralisé l'authentification et la gestion des utilisateurs grâce à Likewise Open. C'est incroyablement simple à installer et à mettre en œuvre. Je ne peux pas dire assez de bien à ce sujet.

Remarque: les UID et GID sont attribués en fonction d'une fonction de hachage, ils sont donc identiques sur l'ensemble de l'infrastructure, de sorte que les montages NFS fonctionnent parfaitement.

J'ai installé les services Windows pour Unix et ajouté un utilisateur dans AD appelé "Unix Authenticator", puis j'ai apporté les modifications de fichier de configuration suivantes sur les machines Linux:

host ldap.<foo>.com
base cn=Users,dc=<foo>,dc=com
binddn cn=Unix Authenticator,cn=Users,dc=<foo>,dc=com
bindpw <password>
nss_base_passwd cn=Users,dc=<foo>,dc=com?sub
nss_base_shadow cn=Users,dc=<foo>,dc=com?sub
nss_base_group cn=Users,dc=<foo>,dc=com?sub
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute cn msSFUName
nss_map_attribute uid msSFUName
nss_map_attribute gid gidNumber
nss_map_attribute gecos sAMAccountName
nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_attribute uniqueMember Member
pam_login_attribute msSFUName
pam_filter objectclass=user
pam_password ad

<password>

passwd: compat ldap
shadow: compat ldap
group: compat ldap

host files dns

auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so

account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok
password sufficient /lib/security/pam_ldap.so use_first_pass use_authtok
password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so

J'espère que cela t'aides.

Vous avez des utilisateurs Windows qui s'authentifient contre AD, mais la plupart de nos serveurs (lecteur public, etc.) sont Linux et font partie du domaine. À partir d'un Windows PoV, personne ne le remarque. De mon côté, ça sent un peu fruité avec mon nom d'utilisateur Windows mais c'est à peu près la taille de celui-ci.

Utilisez simplement de la vieille samba.

Vous n'avez pas besoin d'utiliser Samba, AD prend directement en charge Kerberos et LDAP. Il n'y a aucune raison pour que vous utilisiez un logiciel externe sur la plupart des distributions.

Pour Debian / Ubuntu, vous pouvez le faire avec libnss-ldap et libpam-krb5. Il y a quelques astuces pour l'obtenir à 100%. Cela suppose que vous avez "unixHomeDirectory" rempli pour les utilisateurs Linux, vos boîtes Linux utilisent NTP commun avec vos systèmes Windows (requis par Kerberos) et que vous êtes OK avec des recherches NSS en texte brut (pas de mot de passe mais des informations d'appartenance à un groupe, etc. - vous pouvez également utiliser TLS mais c'est plus compliqué à configurer). Vous ne devriez PAS avoir pam_ldap comme mot de passe ou source d'authentification dans PAM, sauf si vous êtes configuré pour utiliser TLS.

/etc/ldap.conf

# LDAP Configuration for libnss-ldap and libpam-ldap.
# Permit host to continue boot process with out contacting LDAP server
bind_policy soft
# Define LDAP servers to use for queries, these must be Global Catalog servers
uri ldap://ldap.site.company.local
# Define root search location for queries
base dc=company,dc=local
#debug 1
# LDAP version, almost always going to be v3, it is quite mature
ldap_version 3
# Username used to proxy authentication. You can have this in a separate file owned by root for security OR use TLS/SSL (see man page)
# Do NOT use LDAP for authentication if you are using plain text binds, use Kerberos instead (and LDAP for authorization only). See libpam-krb5.
binddn cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
# Password for proxy acct
bindpw SooperSekeretPazzwerd
#  TCP port to perform queries on, 3268 is a Global Catalog port which will reply for all users in *.company.local
port 3268
# Search range scope (sub = all)
scope sub
# Tell the client to close TCP connctions after 30 seconds, Windows will do this on the server side anyways, this will prevent errors from showing up in the logs.
 idle_timelimit 30
# Expect queries for group membership to return DN for group members instead of usernames (lets you use MSAD group membership seamlessly)
nss_schema rfc2307bis
# Filters - User accounts must have a UID >= 2000 to be recognized in this configuration and must have a unixHomeDirectory defined.
nss_base_group dc=company,dc=local?sub?&(objectClass=group)(gidNumber=*)
nss_base_user dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_shadow dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
# Object Class mappings.  You may want to have the posixAccount to map to "mail" and have users login with their email addresses, i.e.  "nss_map_objectclass posixAccount mail".
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
# Attribute mappings.
nss_map_attribute uniqueMember member
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
# Attribute in LDAP to query to match the username used by PAM for authentication
pam_login_attribute sAMAccountName
# Filter for objects which are allowed to login via PAM
pam_filter objectclass=User

Vous ne devriez pas avoir besoin de modifier /etc/krb5.conf en supposant que vos boîtiers Linux utilisent des serveurs DNS qui connaissent AD (les zones _msdcs avec les enregistrements SRV appropriés sont résolvables)

/etc/nsswitch.conf devrait avoir "files ldap" pour les utilisateurs, groupes, shadow.

Pour Red Hat utilisant SSSD:

/etc/sssd/sssd.conf

[domain/AD]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_uri = ldap://ldap.company.local:3268/
ldap_search_base = dc=company,dc=com
ldap_default_bind_dn = cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
ldap_default_authtok = SooperSekeretPazzwerd
ldap_schema = rfc2307bis
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
enumerate = true
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_id_use_start_tls = False
cache_credentials = True
krb5_realm = SITE.COMPANY.COM
case_sensitive = false
[sssd]
services = nss, pam
config_file_version = 2

domains = AD
[nss]
filter_users = root,named,avahi,nscd