Comment intégrer le système CentOS/RHEL dans un domaine AD avec LDAP/Kerberos/SSSD

Le message décrit les étapes pour intégrer les serveurs CentOS/RHEL 6 (client) dans un domaine AD avec LDAP/Kerberos/SSSD.

1. Installez les packages requis :

# yum install sssd samba-common krb5-workstation

Remarque :Assurez-vous que NTP est en cours d'exécution et fonctionne comme prévu et ajoutez votre serveur AD dans /etc/hosts

2. Configurez /etc/krb5.conf ressembler à ce qui suit ::

# 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. Configurez /etc/samba/smb.conf ressembler à ce qui suit :

# 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. Ouvrez un ticket Kerberos en tant qu'administrateur AD :

# kinit your-admin-user

Remarque :Assurez-vous de retirer l'ancienne clé au cas où cela se présenterait. :"rm /etc/krb5.keytab"

5. Joignez la machine OL à Active Directory et générez un Keytab :

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

6. Exécutez ce qui suit pour activer SSSD dans /etc/nsswitch.conf et PAM :

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

7. Créez /etc/sssd/sssd.conf et définissez les autorisations appropriées :

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

8. Configurez /etc/sssd/sssd.conf pour qu'il ressemble à ce qui suit :

# 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. Redémarrez le service SSSD pour que les modifications prennent effet.

# service sssd restart

Remarques

Le mappage d'identifiant de SSSD est identique à l'autorid de Winbind pour lequel il utilise le même algorithme pour générer des UID et des GID mis en cache localement en fonction de l'attribut SID d'un objet LDAP, de sorte que toutes les machines utilisant SSSD avec le mappage d'identifiant soient cohérentes dans les identifiants UID et GID.

Si votre environnement Active Directory contient des attributs POSIX au lieu des seuls noms d'utilisateur et SID, vous pouvez utiliser les configurations supplémentaires suivantes dans le [domaine] section de /etc/sssd/sssd.conf pour désactiver id_mapping :

ldap_id_mapping = false

Vous pouvez également remplacer les informations d'attribut Shell et Home Directory en modifiant fallback_homedir et default_shell à override_homedir et override_shell . Le "repli ' et 'par défaut ' ne seront utilisées que si ces informations ne sont pas renvoyées par AD. Cependant, les options de "remplacer" remplaceront tout ce que AD renvoie, quoi qu'il en soit.

Notez également que chaque fois que vous apportez des modifications importantes telles que celle-ci à SSSD ou que vous ne savez pas si le cache SSSD local doit être régénéré, exécutez toujours ce qui suit par la suite :

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