Come integrare il sistema CentOS/RHEL in un dominio AD con LDAP/Kerberos/SSSD

Il post descrive i passaggi per integrare i server CentOS/RHEL 6 (client) in un dominio AD con LDAP/Kerberos/SSSD.

1. Installa i pacchetti richiesti:

# yum install sssd samba-common krb5-workstation

Nota :assicurati che NTP sia in esecuzione e funzioni come previsto e aggiungi il tuo server AD in /etc/hosts

2. Configura /etc/krb5.conf per assomigliare al seguente::

# 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. Configura /etc/samba/smb.conf per assomigliare al seguente:

# 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. Apri un ticket Kerberos come amministratore AD:

# kinit your-admin-user

Nota :Assicurati di rimuovere la vecchia chiave nel caso venga presentata. :“rm /etc/krb5.keytab”

5. Unisci la macchina OL ad Active Directory e genera un Keytab:

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

6. Eseguire quanto segue per abilitare SSSD all'interno di /etc/nsswitch.conf e PAM:

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

7. Crea /etc/sssd/sssd.conf e imposta i permessi corretti:

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

8. Configurare /etc/sssd/sssd.conf in modo che sia simile a quanto segue:

# 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. Riavvia il servizio SSSD per rendere effettive le modifiche.

# service sssd restart

Note

La mappatura dell'ID di SSSD è identica all'autorid di Winbind per la quale utilizza lo stesso algoritmo per generare UID e GID memorizzati nella cache locale basati sull'attributo SID di un oggetto LDAP, in modo che tutte le macchine che utilizzano SSSD con la mappatura degli ID siano coerenti negli identificatori UID e GID.

Nel caso in cui il tuo ambiente Active Directory contenga attributi POSIX anziché solo nomi utente e SID, puoi utilizzare le seguenti configurazioni aggiuntive all'interno del [dominio] sezione di /etc/sssd/sssd.conf per disabilitare id_mapping:

ldap_id_mapping = false

Puoi anche sovrascrivere le informazioni sugli attributi di Shell e Home Directory modificando fallback_homedir e default_shell per override_homedir e override_shell . Il "ripiego ' e 'impostazione predefinita ' le opzioni verranno utilizzate solo se queste informazioni non vengono restituite da AD. Tuttavia, le opzioni di "override" sovrascriveranno qualsiasi annuncio restituito, a prescindere.

Tieni inoltre presente che ogni volta che apporti modifiche significative come questa a SSSD o non sei sicuro se la cache SSSD locale debba essere rigenerata, esegui sempre quanto segue in seguito:

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