User Logon ManagementPentru o stație de lucru sau un server SLES 15 tipic care necesită utilizatori și date de autentificare bazate pe AD, utilizați modulul YaST și selectați Microsoft Active Directory atât pentru identitate, cât și pentru autentificare; aceasta este calea bazată pe SSSD a SUSE. De exemplu, această demonstrație folosește o gazdă fictivă numită linux01și un domeniu ad.example.com. Se aplică atunci când clientul poate accesa serviciile DNS și de oră AD și aveți o acreditare autorizată pentru înscrierea computerului.
Această procedură respectă Ghidul de securitate și consolidare SLES 15 SP7 de la SUSE. Pachetele de service anterioare pot avea ecrane YaST sau detalii despre pachete diferite, așadar utilizați ghidul care corespunde cu service pack-ul instalat. Dacă cerința dvs. necesită în mod specific suport NTLM sau trusturi între păduri, SUSE identifică modulul separat Windows Domain Membership, bazat pe Winbind, ca fiind cel mai potrivit.
Descoperirea AD se bazează pe înregistrări DNS, iar autentificarea Kerberos depinde de un ceas precis. Îndreptați clientul SLES către DNS-ul care poate rezolva domeniul AD și controlerele sale de domeniu; într-o configurație obișnuită, aceasta înseamnă utilizarea serverului DNS AD în loc de un resolver public. Sincronizați clientul cu sursa de timp aprobată pentru domeniul dvs.
În YaST, deschideți Network Settings, selectați Hostname/DNSși setați Name Server 1la adresa serverului DNS AD. Adresa din ilustrație este doar un substituent. Apoi confirmați numele gazdei locale și starea orei:
hostname
timedatectl statusComparați numele computerului cu numele înregistrat pentru acesta în AD. Dacă acestea diferă, caseta de dialog de alăturare din SUSE oferă un AD hostnamecâmp. Nu dezactivați firewall-ul ca scurtătură de descoperire; solicitați echipei de rețea să permită traficul client-controler de domeniu necesar conform regulilor organizației dvs. SUSE avertizează, de asemenea, că numele care se termină în .localpot intra în conflict cu DNS-ul multicast, așa că verificați designul DNS-ului dacă acesta este sufixul domeniului dvs.
În YaST, deschideți User Logon Management. Nu alegeți Windows Domain Membershipaceastă procedură: SUSE documentează modulul respectiv ca fiind bazat pe Winbind, în timp ce User Logon Management este opțiunea bazată pe SSSD și este în general preferată pentru autentificarea AD.
Deschideți Change Settings, selectați Add Domainși introduceți numele DNS al domeniului, cum ar fi ad.example.com. Setați atât serviciul de identitate, cât și serviciul de autentificare la Microsoft Active Directoryși asigurați-vă că Enable the domaineste selectat.
Păstrați celelalte valori implicite, cu excepția cazului în care mediul dvs. necesită un nume de gazdă AD specific sau o listă fixă de controlere de domeniu. Dacă descoperirea automată DNS nu este potrivită, introduceți numele de gazdă ale controlerelor de domeniu furnizate de echipa dvs. AD. Selectați OKastfel încât YaST să poată instala orice software lipsă și să verifice dacă un controler este accesibil.
Când YaST raportează că a descoperit un server AD, dar computerul nu este încă înscris, introduceți contul și parola autorizate pentru înscriere. Dialogul documentat al SUSE utilizează un cont de administrator AD; urmați procesul aprobat de echipa directorului pentru înscrierea computerului și nu introduceți niciodată parola într-un script sau articol. Dacă dialogul nu poate descoperi un server, reveniți la verificările DNS și ale numelui de gazdă înainte de a încerca din nou.
După înscriere, activați Allow Domain User Logon. Decideți dacă activați Create Home Directoriespe baza politicii serverului privind datele utilizatorului. Aceasta creează directoare principale locale pentru utilizatorii AD la prima conectare; este utilă pentru o mașină care ar trebui să păstreze datele principale locale, dar nu creează sau gestionează contul de utilizator în AD.
Dacă AD furnizează deja atributul fiecărui utilizator UnixHomeDirectory, confirmați că acesta este populat și disponibil conform cerințelor designului directorului. Când clientul are nevoie de o cale de rezervă, utilizați Service Options> Name switch> Extended Optionspentru a configura fallback_homedir, de exemplu /home/%u. SUSE documentează faptul că se utilizează o cale de rezervă atunci când nu este furnizată o cale AD; override_homedirîn schimb, face ca valoarea clientului să aibă prioritate. Alegeți unul numai după ce verificați politica directorului principal.
Salvați setările și examinați rezumatul configurației rezultat. Dacă sistemul utilizează și Samba, selectați o opțiune pentru a suprascrie configurația Samba doar atunci când este intenționată această integrare; este separată de activarea conectării utilizatorului bazate pe SSSD.
Verificați dacă SSSD este activ, apoi interogați un cont de domeniu real folosind formatul de nume aprobat pentru domeniul dvs. În acest exemplu, înlocuiți EXAMPLE`and` alicecu numele de domeniu scurt și un cont de test existent:
systemctl status sssd
getent passwd 'EXAMPLE\alice'O intrare passwd returnată confirmă că NSS poate rezolva contul; aceasta nu dovedește singură că utilizatorul se poate autentifica sau accesa aplicații. Testați o autentificare interactivă cu acreditările domeniului, utilizând formularul documentat DOMAIN_NAME\USER_NAMEdin consolă sau din managerul de afișare. După autentificare, rulați comanda klistpentru a verifica dacă sesiunea are un tichet Kerberos.
Dacă SSSD rulează, dar căutarea utilizatorului eșuează, verificați din nou numele de domeniu complet calificat, serverul DNS, numele gazdei și selecțiile de identitate și autentificare din YaST. Dacă căutarea funcționează, dar conectarea eșuează, verificați dacă este activat contul, dacă parola sa este validă și dacă clientul poate accesa controlerul de domeniu. Finalizați numai după ce un utilizator de test permis se poate conecta, comportamentul așteptat al directorului principal este confirmat și serviciile necesare ale serverului încă funcționează.
Urmați procedura SP7 a SUSE pentru a activa modul FIPS, reporniți în siguranță, verificați politica activă și verificați dacă cerința de conformitate necesită module validate.
Comparați YaST și cryptsetup pentru un nou volum de date SLES criptat, alegeți LUKS1 sau LUKS2 și verificați comportamentul de deblocare și montare în siguranță.
Configurați RMT pe SLES 15, oglindiți repozitoriile autorizate și verificați înregistrarea HTTPS și accesul la pachet de la un client de testare.
Conectați SLES 15 la AD cu ajutorul gestionării logon-ului bazate pe SSSD din YaST, apoi verificați căutarea în directoare, conectarea la domeniu și tichetele Kerberos.
Configurați calea corectă pentru Live Patching pentru SLES 16.0 sau 15 SP7, aplicați corecțiile eligibile ale kernelului și confirmați ce este activ fără a-l confunda cu o actualizare a kernelului care necesită repornire.
SLES 15 SP5 poate migra online la SP6, dar fiecare nod trebuie să repornească. Folosiți o actualizare continuă testată sau o trecere de la un sistem blue-green la altul pentru a menține accesibile sarcinile de lucru.
Creați, rafinați și verificați un profil AppArmor cu privilegii minime pe SLES 15 SP7, cu o notă clară privind setările implicite SELinux pentru SLES 16.
Folosește profilul STIG acceptat de SUSE pentru a scana SLES 15, a testa remedierea, a revizui constatările rămase și a păstra dovezile evaluării.
Urmăriți o conexiune Cockpit eșuată prin DNS, portul 9090, socketul systemd, firewalld, TLS și setările de conectare folosind instrucțiunile SUSE actuale.
Creați o conexiune Ethernet redundantă pe SLES 15 cu YaST și Wicked, configurați legătura activă de backup și verificați ambele porturi și failover-ul.
