Cómo integrar el sistema CentOS/RHEL en un dominio AD con LDAP/Kerberos/SSSD

La publicación describe los pasos para integrar los servidores CentOS/RHEL 6 (cliente) en un dominio AD con LDAP/Kerberos/SSSD.

1. Instale los paquetes necesarios:

# yum install sssd samba-common krb5-workstation

Nota :Asegúrese de que NTP se esté ejecutando y funcione como se esperaba y agregue su servidor AD en /etc/hosts

2. Configure /etc/krb5.conf para parecerse a lo siguiente::

# vi /etc/krb5.conf
[logging]
kdc = SYSLOG:DEBUG
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
allow_weak_crypto = true

[realms]
EXAMPLE.COM = {
kdc = adserver.example.com
admin_server = adserver.example.com

}

[domain_realm]
example.com = EXAMPLE.COM
.example.com = EXAMPLE.COM

3. Configure /etc/samba/smb.conf para parecerse a lo siguiente:

# vi /etc/samba/smb.conf
[global]
workgroup = ADGRP
realm = EXAMPLE.COM
security = ads
kerberos method = secrets and keytab
log file = /var/log/samba/log.%m
max log size = 50
client signing = yes
client use spnego = yes
idmap config * : backend = tdb
password server = adserver.example.com

4. Abra un ticket de Kerberos como administrador de AD:

# kinit your-admin-user

Nota :Asegúrese de quitar la llave antigua en caso de que se presente. :“rm /etc/krb5.keytab”

5. Una la máquina OL a Active Directory y genere un Keytab:

# net ads join createupn=host/[email protected] -k
# net ads keytab create -k

6. Ejecute lo siguiente para habilitar SSSD dentro de /etc/nsswitch.conf y PAM:

# authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update

7. Cree /etc/sssd/sssd.conf y establezca los permisos correctos:

# echo > /etc/sssd/sssd.conf
# chmod 600 /etc/sssd/sssd.conf

8. Configure /etc/sssd/sssd.conf para que se asemeje a lo siguiente:

# vi /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
debug_level = 9
domains = example.com
services = nss, pam
cache_credentials = true
ad_server = adserver.example.com
id_provider = ad
access_provider = ad

[domain/example.com]
id_provider = ad
debug_level = 9
access_provider = ad
override_homedir = /home/%u
default_shell = /bin/bash
auth_provider = ad
chpass_provider = ad
ldap_schema = ad
cache_credentials = true
use_fuly_qualified_domain_name = true
ad_enable_gc = false

9. Reinicie el servicio SSSD para que los cambios surtan efecto.

# service sssd restart

Notas

El mapeo de id de SSSD es idéntico al autoid de Winbind, para el cual utiliza el mismo algoritmo para generar UID y GID almacenados en caché localmente basados ​​en el atributo SID de un objeto LDAP, de modo que todas las máquinas que usan SSSD con mapeo de id son consistentes en los identificadores UID y GID.

En caso de que su entorno de Active Directory contenga atributos POSIX en lugar de solo nombres de usuario y SID, puede usar las siguientes configuraciones adicionales dentro del [dominio] sección de /etc/sssd/sssd.conf para deshabilitar id_mapping:

ldap_id_mapping = false

También puede anular la información de atributos de Shell y Home Directory cambiando fallback_homedir y default_shell a override_homedir y override_shell . El 'alternativo ' y 'predeterminado Las opciones solo se utilizarán si esta información no se devuelve desde AD. Sin embargo, las opciones de "anulación" anularán lo que devuelva AD, independientemente.

También tenga en cuenta que cada vez que realice cambios significativos como este en SSSD o no esté seguro de si se debe regenerar el caché SSSD local, siempre ejecute lo siguiente después:

# service sssd stop
# rm -rf /var/log/sssd/*
# rm -rf /var/lib/sss/db/*
# service sssd start