Integrarea SLES 15 Active Directory cu SSSD: Un ghid pas cu pas

Pentru o gazdă tipică SUSE Linux Enterprise Server 15 care necesită conectarea utilizatorilor de domeniu, SUSE documentează YaST User Logon Management cu SSSD ca fiind cea mai potrivită opțiune în majoritatea mediilor Active Directory. SSSD oferă identitatea Linux și calea de autentificare PAM, în timp ce Active Directory rămâne sursa pentru conturi și autentificarea Kerberos. Winbind este o opțiune mai potrivită atunci când designul depinde de suportul NTLM sau de încredere între păduri. Dacă preferați automatizarea, SUSE documentează și alăturarea cu realmd; este un instrument de descoperire a domeniilor și de apartenență, așa că confirmați ce software client și politică de acces va configura sistemul dvs. înainte de a le utiliza la scară largă.

Această prezentare detaliată respectă Ghidul de securitate și consolidare SLES 15 SP7, verificat pe 6 octombrie 2026. Pachetele service pack SUSE pot diferi, iar instrucțiunile de mai jos reprezintă o procedură bazată pe documentație, nu o afirmație că comenzile au fost executate pe domeniul dvs. Înlocuiți numele de domeniu și gazdă din exemplu cu valori din mediul dvs. Testați mai întâi pe o mașină SLES necritică și păstrați disponibil un cont de administrator local în cazul în care autentificarea domeniului este configurată greșit.

Alegeți metoda de integrare care se potrivește jobului

SUSE descrie opțiunea YaST bazată pe SSSD ca fiind potrivită pentru majoritatea asocierilor AD și identifică Winbind pentru cazurile care necesită NTLM sau trusturi între păduri. Acestea sunt puncte de plecare practice, nu un substitut pentru testarea nevoilor specifice aplicației, cum ar fi servirea fișierelor Samba, regulile sudo, căutarea cheilor SSH sau coliziunile de nume multi-domeniu. Pentru o flotă simplă de conectare Linux, începeți cu SSSD, cu excepția cazului în care o cerință documentată indică altceva.

Ce trebuie să pregătiți înainte de a asocia SLES cu Active Directory

• Un nume de gazdă stabil: Alegeți numele de gazdă complet calificat dorit și asigurați-vă că acesta se rezolvă în mod consecvent în rețeaua dvs. și în AD. Coordonați orice convenție de denumire a conturilor de computer cu echipa de directoare.
• DNS compatibil cu AD: Clientul SLES trebuie să interogheze un server DNS care poate rezolva zona AD și înregistrările sale de serviciu (SRV). Utilizarea exclusivă a unui rezolver public întrerupe, de obicei, descoperirea domeniului.
• Timp sincronizat: Kerberos depinde de ceasurile strâns aliniate ale clientului și controlerelor de domeniu. Confirmați sincronizarea NTP înainte de a depana parolele sau SSSD-ul.
• Accesul la rețea la controlerele de domeniu: Confirmați că firewall-ul și rutarea permit protocoalele și porturile necesare designului AD al organizației dvs., inclusiv DNS, Kerberos, LDAP și orice trafic necesar pentru catalogul global sau schimbarea parolei. Nu deschideți toate porturile în general; solicitați administratorului AD/de rețea să furnizeze regulile aprobate.
• O identitate de înscriere autorizată: Folosiți un cont cu permisiunea de a adăuga sau reutiliza obiecte de computer în unitatea organizațională corectă. Evitați utilizarea de rutină a unui cont cu privilegii ridicate atunci când sunt disponibile drepturi de alăturare delegate.
• Acces pentru recuperare: Păstrați un autentificare de administrator local testată și o modalitate de a accesa consola. Nu setați domeniul drept singura rută de întoarcere către un server înainte de a valida noua cale de conectare.

SUSE solicită în mod specific DNS-ul accesibil prin AD și ora exactă pentru Kerberos. Ghidul său menționează că un domeniu care se termină în .localpoate intra în conflict cu DNS-ul multicast în anumite scenarii de asociere. Dacă AD-ul dvs. folosește acest sufix, verificați implicațiile pentru versiunea SLES și configurația rețelei cu administratorul de director înainte de a modifica setările de denumire sau de resolver.

hostnamectl --static
hostname -f
timedatectl status
getent hosts ad01.corp.example.com
host -t SRV _ldap._tcp.dc._msdcs.corp.example.com

Comanda hostpoate necesita pachetul de utilitare DNS la o instalare minimală. Aceste verificări nu dovedesc că fiecare cale necesară pentru firewall este deschisă; ele ajută la depistarea problemelor comune legate de rezoluția numelor și de ceas înainte de înscriere.

Alăturați-vă domeniului folosind YaST și SSSD

1. Setați resolver-ul. Deschideți YaST și alegeți Setări rețea , apoi Nume gazdă/DNS . Configurați serverul DNS AD sau un resolver intern care redirecționează corect zona AD. Salvați și confirmați că gazda poate rezolva controlerul de domeniu și înregistrările serviciului AD.
2. Deschideți Gestionare conectare utilizatori. Din fereastra principală YaST, lansați Gestionare conectare utilizatori și selectați Modificare setări . Acesta este modulul de autentificare bazat pe SSSD din ghidul SLES 15 SP7; este diferit de modulul Apartenență domeniu Windows , care utilizează Winbind.
3. Adăugați domeniul AD. Alegeți Adăugare domeniu , introduceți numele domeniului DNS, cum ar fi corp.example.comși selectați Microsoft Active Directory atât pentru datele de identitate, cât și pentru autentificare. Asigurați-vă că domeniul este activat. Dacă descoperirea automată DNS nu este potrivită în rețeaua dvs., specificați numele de gazdă aprobate ale controlerului de domeniu, așa cum este descris în ghid.
4. Verificați numele mașinii și rezultatul descoperirii. Comparați numele gazdei locale cu numele computerului dorit în AD. Corectați orice nepotrivire înainte de înscriere. YaST ar trebui să descopere un server AD și să raporteze că clientul nu este încă înscris. Dacă descoperirea eșuează, reveniți la verificările DNS, oră, rutare și firewall, în loc să încercați furnizori de autentificare aleatorii.
5. Înregistrați-vă cu un cont autorizat. Introduceți acreditările AD permise pentru a vă conecta la mașină. YaST poate instala software-ul lipsă în timpul acestui proces. Dialogul poate oferi o opțiune de suprascriere a configurației Samba; activați-o numai atunci când modificarea respectivă este destinată configurației Samba/AD și păstrați mai întâi configurația existentă dacă serviciile Samba sunt deja utilizate.
6. Activați comportamentul de conectare dorit. În Gestionare conectare utilizatori domeniu , activați conectarea utilizatorilor domeniu numai după ce ați decis ce conturi ar trebui să aibă acces. Configurați crearea de directoare principale locale dacă utilizatorii au nevoie de ele. SUSE documentează opțiunile fallback_homedirși override_homedirși le afișează /home/%uca format posibil. Într-un mediu cu mai multe domenii, proiectați o cale unică și consultați manualul SSSD înainte de a vă baza doar pe un nume de utilizator scurt.
7. Salvați, verificați și testați cu un utilizator fără privilegii. Aplicați setările, confirmați că domeniul și opțiunile alese sunt corecte, apoi testați un cont de domeniu normal din consolă sau prin serviciul de conectare pe care intenționați să îl utilizați. Nu testați doar cu contul care s-a conectat la mașină.

Cum verifici asocierea SSSD?

Verificați dacă SSSD este activ, dacă NSS poate rezolva o identitate de domeniu cunoscută și dacă o conectare reală are succes. După ce utilizatorul de test se conectează, verificați dacă există un tichet Kerberos. SUSE listează klistși getent passwdprintre verificările sale de conexiune.

systemctl status sssd
getent passwd 'alex@corp.example.com'
id 'alex@corp.example.com'
klist

Șirul de identitate exact depinde de setările de denumire SSSD; unele medii utilizează DOMAIN\userun nume în loc de un nume în stil UPN. Dacă getentnu returnează nicio înregistrare, verificați dacă interogați formatul de nume și domeniul configurate, apoi inspectați jurnalele de service:

sudo journalctl -u sssd --since "15 minutes ago"

O căutare reușită nu dovedește că utilizatorul se poate conecta, iar un tichet Kerberos existent nu dovedește că fiecare aplicație folosește stiva PAM dorită. Testați o sesiune nouă, o schimbare de parolă, dacă este necesar, autorizarea bazată pe grup și calea de conectare SSH sau desktop relevantă. Confirmați că accesul este restricționat persoanelor pe care ați intenționat să le permiteți.

SSSD sau Winbind: care compromis contează cel mai mult?

Pentru majoritatea clienților SLES care au nevoie de identități AD și conectări interactive, SSSD este alegerea simplă, susținută de ghidul SUSE privind gestionarea conectării utilizatorilor. Acesta integrează căutarea identității și autentificarea PAM și poate stoca în cache informații pentru reziliență atunci când directorul este temporar inaccesibil. Accesul în cache are limite: o prima conectare nu se poate baza pe o acreditare stocată în cache, iar resursele bazate pe director sau modificările de parolă necesită în continuare un controler de domeniu accesibil. Stabiliți și testați politica de conectare offline, în loc să tratați memorarea în cache ca o soluție completă pentru întreruperile AD.

Alegeți Winbind atunci când o cerință depinde în mod specific de integrarea domeniului Samba, NTLM sau încrederile între păduri. Nu este pur și simplu o casetă de selectare alternativă pentru SSSD: fiecare cale utilizează daemoni și componente NSS/PAM diferite. Documentați ce serviciu deține căutările și autentificările de domeniu și evitați să amestecați editările manuale vechi PAM/NSS cu setările gestionate de YaST.

Se utilizează realmdatunci când este important un flux de lucru shell repetabil. Ghidul de administrare a stocării SLES 15 SP7 de la SUSE documentează realm discover --verbosepentru descoperirea bazată pe DNS, realm join --verbosepentru înscriere și realm permitpentru permisiunile de conectare. Inspectați ce software client este selectat și ce configurație SSSD este produsă în versiunea dvs. Evitați accesul larg „permiteți tuturor” în producție, cu excepția cazului în care aceasta este o politică explicită.

Defecțiuni frecvente și următoarea verificare

• Descoperirea domeniului nu returnează nimic: Verificați serverul DNS al clientului și înregistrarea AD SRV, apoi confirmați că gazda poate accesa controlerele de domeniu listate.
• Erori Kerberos în ciuda unei parole corecte: Verificați sincronizarea orei sistemului, numele DNS utilizat pentru controlerul de domeniu și dacă contul de computer este activat și denumit corect.
• Utilizatorul rezolvă problema, dar nu se poate conecta: Confirmați că autentificarea la domeniu este activată în YaST, verificați restricțiile de acces și starea contului în AD și examinați jurnalele SSSD/PAM.
• Autentificarea funcționează, dar directorul principal lipsește: Confirmați că este activată crearea directorului principal și că calea configurată este validă și unică pentru utilizator.
• O asociere eșuează după experimente anterioare: Verificați dacă există obiecte de computer învechite, nume de gazdă duplicate, configurații Winbind rămase sau NSS/PAM manuale și parole de mașină nepotrivite. Coordonați curățarea cu administratorul AD înainte de a șterge un obiect de computer sau de a șterge datele SSSD locale.

Când ar trebui să te oprești și să alegi o altă abordare?

Întrerupeți înainte de lansare dacă mediul dvs. se bazează pe comportamentul de încredere între păduri, NTLM, un rol de server Samba, mai multe păduri cu nume de utilizator scurte care se suprapun sau reguli de acces complexe pe care setările de bază ale YaST nu le exprimă. Aceste condiții pot schimba furnizorul preferat sau pot necesita o configurare SSSD suplimentară. Testați-le cu conturi reprezentative și servicii reale într-un sistem de testare și păstrați datele de autentificare pentru recuperare până când politica este verificată.

Concluzie: Pentru o stație de lucru sau un server SLES 15 SP7 standard care necesită identități și date de conectare Active Directory, începeți cu calea YaST User Logon Management, susținută de SSSD. Obțineți mai întâi permisiunile DNS, oră, denumirea gazdei și de alăturare corecte; apoi verificați căutarea numelui, Kerberos, conectarea PAM și domeniul de acces. Selectați Winbind pentru cerințele specifice Samba, NTLM sau între păduri pe care le identifică SUSE și utilizați-l realmdatunci când fluxul de lucru din linia de comandă se potrivește mai bine procesului dvs. operațional.

Surse: Ghid de securitate și consolidare pentru SUSE SLES 15 SP7: asistență Active Directory ; Ghid de administrare a spațiului de stocare SUSE SLES 15 SP7: realmd ; SUSE SLES 15 SP7: clienți de autentificare și SSSD ; Note de lansare SUSE SLES 15 SP7 .