Question Comment utiliser Active Directory pour authentifier les utilisateurs de Linux


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

Pour que cela fonctionne, il faudrait ajouter des utilisateurs AD à un groupe - par exemple administrateurs linux ou serveur web linuxet, en fonction de leur appartenance à un groupe, ils n'auraient / n'auraient pas le droit d'accéder à un serveur particulier. Idéalement, le compte root serait le seul à être géré de manière standard.

Mes objectifs sont les suivants:

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

Les choses que je veux éviter sont:

  • rien difficile / contre-intuitif pour notre administrateur Active Directory pour gérer
  • verrouiller les utilisateurs si les serveurs AD sont inaccessibles pour une raison quelconque (c'est-à-dire qu'il doit mettre en cache les informations d'identification d'une manière ou d'une autre)
  • tout ce qui est trop complexe ou non standard pourrait casser la prochaine fois que je mettrai à niveau le serveur.

7
2018-06-10 20:02


origine




Réponses:


Regarde aussi Clients Linux sur un domaine Windows et Est-il pratique d'authentifier un serveur Linux auprès d'AD?


4
2018-06-10 20:11





Le logiciel que vous recherchez s'appelle Likewise-open.

De leur page:

  • Joint les systèmes non Windows aux domaines Active Directory en une seule étape à partir de la ligne de commande ou d'une interface graphique
  • Authentifie les utilisateurs avec un seul nom d'utilisateur et mot de passe sous Windows et non Windows
  • Applique les mêmes stratégies de mot de passe pour les utilisateurs non-Windows et les utilisateurs Windows
  • Prend en charge plusieurs forêts avec des approbations inter-forêts unidirectionnelles et bilatérales
  • 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/


4
2018-05-01 15:08



Est-ce que Likewise Open a un référentiel Debian? Ceci est important pour nous pour la gestion des correctifs de sécurité. - Brent
Il contient un paquet Ubuntu: Paquet: likewise-open Etat: non installé Version: 4.1.2982-0ubuntu1 Priorité: optionnel Section: net Mainteneur: Développeurs Ubuntu Core <ubuntu-devel-discuss@lists.ubuntu.com> - jay_dubya


J'ai utilisé Likewise-Open et je 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 à le faire beaucoup du tout. Je préfère de loin la configuration du fichier de configuration de Centrify à la configuration de 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


3
2017-08-15 13:59





Vous n'avez aucune raison d'utiliser 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" pour les utilisateurs Linux, que vos machines Linux utilisent le protocole NTP commun avec vos systèmes Windows (requis par Kerberos) et que vous êtes OK avec les recherches NSS en texte brut (pas le mot de passe, mais les informations sur l'appartenance à un groupe, etc. utilisez TLS mais c'est plus compliqué à mettre en place). Vous ne devez PAS avoir pam_ldap en tant que 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 machines Linux utilisent des serveurs DNS qui connaissent AD (les zones _msdcs avec les enregistrements SRV appropriés peuvent être résolues).

/etc/nsswitch.conf devrait avoir des "fichiers LDAP" pour les utilisateurs, les groupes, l'ombre.

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

3
2018-02-05 19:02





Vous devriez évaluer Radius. Configurez les boîtes Linux pour utiliser pam-radius et installez le plugin MS radius NPS. Il va parler à 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.


0