¿Qué tan práctico es autenticar un servidor Linux contra AD?

Utilizamos tanto servidores Windows como Linux en nuestra empresa de desarrollo de software.

Uno de los puntos de fricción con esta configuración es que no tenemos una solución de inicio de sesión único. Al ser más una tienda de Microsoft que una de Linux, queremos autenticarnos contra AD.

Leí un par de artículos en línea y entiendo que esto sea posible.

Actualmente estamos utilizando los siguientes servicios en Linux que requieren autenticación:
- servidor git (a través de SSH)
- Sendmail
- servidor web Apache que actualmente utiliza archivos .htaccess.
- Compartir archivos SAMBA

Lo que quiero saber es qué tan práctico es este tipo de configuración. ¿Realmente funciona o es propenso a errores?

No es difícil y es perfectamente práctico.

Tenemos unos cientos de máquinas de escritorio de arranque dual que usan autenticación AD, así como varios servidores que usan autenticación AD para permitir que los clientes de Windows usen sus recursos compartidos de samba sin autenticación explícita por parte de los usuarios.

Hubo otro artículo sobre SF sobre lo que debe hacer.

Básicamente necesita configurar kerberos, winbind, nss y pam.

Luego haces a kinity a net ads joiny estás arriba.

Puede configurar pam para usar múltiples métodos de autenticación si lo desea, por lo que si uno no funciona, volverá al siguiente.

Usualmente utilizamos archivos, winbindd y ldap para servidores que sirven archivos compartidos a servidores Windows.

Si fuera posible, usaría LDAP para la información de la cuenta y windbind estrictamente para la autenticación, pero creo que puede asignar atributos en /etc/ldap.conf si lo necesita. Si termina usando winbindd para obtener información de la cuenta, es posible usar el RID (método hash) para generar uids / gids, pero también es posible usar otros métodos. Utilizamos RID en un servidor de archivos grande y ha sido un verdadero dolor, así que intentaría explorar una de las otras opciones si es posible. En nuestro caso, todos los usuarios y grupos de AD se reflejan en LDAP mediante un sistema IDM ascendente, por lo que utilizamos LDAP para obtener información de la cuenta en servidores más nuevos y utilizamos winbind solo para autenticación.

La autenticación es absolutamente simple usando Likewise Open. http://www.likewise.com/products/likewise_open/index.php

Casi toda mi infraestructura de Linux tiene autenticación centralizada y gestión de usuarios gracias a Likewise Open. Es increíblemente simple de instalar e implementar. No puedo decir lo suficiente sobre eso.

Como nota, los UID y GID se asignan de acuerdo con una función hash, por lo que son idénticos en toda la infraestructura, por lo que los montajes NFS funcionan perfectamente.

Instalé los Servicios de Windows para Unix y agregué un usuario en AD llamado "Autenticador Unix", luego hice los siguientes cambios en el archivo de configuración en las máquinas 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

Espero que esto ayude.

Los usuarios de Windows se autenticaron contra AD, pero la mayoría de nuestros servidores (unidad pública, etc.) son Linux y son parte del dominio. Desde un punto de vista de Windows nadie se da cuenta. Por mi parte, se siente un poco afrutado con mi nombre de usuario de Windows, pero eso es aproximadamente del tamaño.

Solo usin simple samba vieja.

No necesita usar Samba, AD admite Kerberos y LDAP directamente. No hay ninguna razón para que use ningún software externo en la mayoría de las distribuciones.

Para Debian / Ubuntu puede hacerlo con libnss-ldap y libpam-krb5. Hay algunos trucos para obtener el 100%. Esto supone que tiene "unixHomeDirectory" poblado para usuarios de Linux, sus cajas de Linux están usando NTP común con sus sistemas Windows (requerido por Kerberos) y que está bien con búsquedas de texto sin formato NSS (no contraseña sino información de membresía grupal, etc.) también puede use TLS pero es más complicado de configurar). NO debe tener pam_ldap como contraseña o fuente de autenticación en PAM a menos que esté configurado para usar 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

No debería necesitar editar /etc/krb5.conf asumiendo que sus cajas de Linux están utilizando servidores DNS que conocen AD (las zonas _msdcs con los registros SRV apropiados son resolubles)

/etc/nsswitch.conf debería tener "archivos ldap" para usuarios, grupos, shadow.

Para Red Hat con 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