Comment utiliser Active Directory pour authentifier les utilisateurs Linux

Quelles sont les meilleures pratiques pour utiliser Active Directory pour authentifier les utilisateurs sur des boîtes Linux (Debian)?

La façon dont je souhaiterais que cela fonctionne consiste à ajouter des utilisateurs AD à un groupe - par exemple, des administrateurs Linux ou un serveur Web Linux , et en fonction de leur appartenance à un groupe, ils n'auraient / n'auraient pas accès à un serveur particulier. Idéalement, le compte root serait le seul géré de manière standard.

Mes objectifs en faisant cela sont les suivants:

• Pour autoriser les changements de mot de passe en un seul endroit
• Pour autoriser automatiquement certaines personnes à accéder aux serveurs Linux à l'aide de leurs informations d'identification AD
• Pour consolider toutes nos informations utilisateur dans une seule base de données

Les choses que je veux éviter sont:

• tout ce qui est difficile / contre-intuitif à gérer par notre administrateur Active Directory
• verrouiller les utilisateurs si les serveurs AD sont inaccessibles pour une raison quelconque (c'est-à-dire - il doit mettre en cache les informations d'identification d'une manière ou d'une autre)
• tout élément trop complexe ou non standard qui se brisera lors de la prochaine mise à niveau du serveur.

Voir également les clients Linux sur un domaine Windows et dans quelle mesure est-il pratique d'authentifier un serveur Linux par rapport à AD?

Le logiciel que vous recherchez s'appelle également ouvert.

De leur page:

• Joint des systèmes non Windows à des domaines Active Directory en une seule étape à partir de la ligne de commande ou d'une interface graphique
• Authentifie les utilisateurs avec un nom d'utilisateur et un mot de passe uniques sur Windows et non Windows
• Applique les mêmes politiques de mot de passe pour les utilisateurs non Windows et les utilisateurs Windows
• Prend en charge plusieurs forêts avec des approbations de forêts croisées unidirectionnelles et bidirectionnelles
• Met en cache les informations d'identification en cas de panne de votre contrôleur de domaine
• Fournit une connexion unique pour SSH et Putty
• Moteur d'authentification de nouvelle génération prenant en charge Kerberos, NTLM et SPNEGO
• Aucune modification de schéma à Active Directory requise

Nous l'avons utilisé sur certaines machines ici et cela semble bien fonctionner.

http://www.likewise.com/products/likewise_open/

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 d'accord avec les recherches NSS en texte brut (pas le mot de passe mais les informations d'appartenance au 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

J'ai utilisé Likewise-Open et l'ai trouvé bogué et peu fiable. L'année dernière, je suis passé à Centrify, à la fois pour Linux et pour Mac, et je n'ai pas eu à me soucier du tout. Je préfère de loin la configuration du fichier conf de Centrify à la configuration du fichier de registre de Likewise-Open qui nécessite une manipulation avec des outils externes.

http://www.centrify.com/express/free-active-directory-tools-for-linux-mac.asp

Vous devez évaluer le rayon. Configurez les boîtiers Linux pour utiliser pam-radius et installez le plugin MS radius NPS. Il parlera à AD. Vous pouvez obtenir un aperçu dans le guide PDF ici: http://www.wikidsystems.com/learn-more/two-factor-authentication-white-papers (pas de reg). Ignorez simplement les bits d'authentification à deux facteurs.