Integrazione di Active Directory con SSSD in SLES 15: una guida passo passo

Per un tipico host SUSE Linux Enterprise Server 15 che necessita di utenti di dominio per l'accesso, SUSE documenta YaST User Logon Management con SSSD come la soluzione migliore nella maggior parte degli ambienti Active Directory. SSSD fornisce l'identità Linux e il percorso di autenticazione PAM, mentre Active Directory rimane la fonte per gli account e l'autenticazione Kerberos. Winbind è più adatto quando la progettazione dipende da NTLM o dal supporto per relazioni di trust tra foreste. Se si preferisce l'automazione, SUSE documenta anche l'adesione con realmd; si tratta di uno strumento di rilevamento e appartenenza al dominio, quindi è necessario verificare quale software client e policy di accesso verranno configurati dal sistema prima di utilizzarlo su larga scala.

Questa procedura si basa sulla Guida alla sicurezza e alla protezione di SLES 15 SP7, verificata il 6 ottobre 2026. I Service Pack di SUSE possono essere diversi e le istruzioni seguenti sono una procedura basata sulla documentazione, non una garanzia che i comandi siano stati eseguiti sul vostro dominio. Sostituite il dominio e i nomi host di esempio con i valori del vostro ambiente. Eseguite prima un test su una macchina SLES non critica e tenete a disposizione un account amministratore locale nel caso in cui l'autenticazione di dominio sia configurata in modo errato.

Scegli il metodo di integrazione più adatto al lavoro

SUSE descrive l'opzione YaST basata su SSSD come adatta alla maggior parte delle aggiunte ad Active Directory e indica Winbind per i casi che richiedono trust NTLM o tra foreste. Questi sono punti di partenza pratici, non un sostituto per testare le esigenze specifiche dell'applicazione, come la condivisione di file Samba, le regole sudo, la ricerca di chiavi SSH o le collisioni di nomi di dominio multipli. Per una semplice rete di login Linux, è consigliabile iniziare con SSSD a meno che un requisito documentato non indichi un'altra soluzione.

Cosa preparare prima di integrare SLES in Active Directory

• Un nome host stabile: scegli il nome host completo desiderato e assicurati che venga risolto correttamente nella tua rete e in Active Directory. Concorda qualsiasi convenzione di denominazione degli account computer con il team di directory.
• Funzionamento del DNS compatibile con Active Directory: il client SLES deve interrogare un server DNS in grado di risolvere la zona Active Directory e i relativi record di servizio (SRV). L'utilizzo del solo resolver pubblico spesso compromette il rilevamento del dominio.
• Sincronizzazione dell'ora: Kerberos si basa sulla sincronizzazione precisa degli orologi del client e dei controller di dominio. Verificare la sincronizzazione NTP prima di risolvere i problemi relativi alle password o a SSSD.
• Accesso alla rete dei controller di dominio: verificare che il firewall e il routing consentano i protocolli e le porte richiesti dalla configurazione di Active Directory dell'organizzazione, inclusi DNS, Kerberos, LDAP e qualsiasi traffico necessario per il catalogo globale o per la modifica delle password. Non aprire tutte le porte indiscriminatamente; richiedere all'amministratore di Active Directory/rete di fornire le regole approvate.
• Identità di registrazione autorizzata: utilizzare un account autorizzato ad aggiungere o riutilizzare oggetti informatici nell'unità organizzativa corretta. Evitare l'uso abituale di un account con privilegi elevati quando sono disponibili diritti di accesso delegati.
• Accesso di ripristino: mantieni un login di amministratore locale testato e un modo per accedere alla console. Non rendere il dominio l'unica via di accesso al server prima di aver convalidato il nuovo percorso di login.

SUSE fa specifico riferimento al DNS raggiungibile da Active Directory e all'ora precisa per Kerberos. La sua guida osserva che un dominio che termina con .localpuò entrare in conflitto con il DNS multicast in alcuni scenari di join. Se il tuo Active Directory utilizza tale suffisso, verifica le implicazioni per la tua versione di SLES e la configurazione di rete con l'amministratore di directory prima di modificare le impostazioni di denominazione o di risoluzione.

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

Il hostcomando potrebbe richiedere il pacchetto di utilità DNS in un'installazione minima. Questi controlli non dimostrano che ogni percorso del firewall richiesto sia aperto; aiutano a individuare i problemi comuni di risoluzione dei nomi e di orologio prima della registrazione.

Unisciti al dominio utilizzando YaST e SSSD

1. Configura il resolver. Apri YaST e seleziona Impostazioni di rete , quindi Nome host/DNS . Configura il server DNS di Active Directory o un resolver interno che inoltri correttamente la zona di Active Directory. Salva e verifica che l'host sia in grado di risolvere il controller di dominio e i record di servizio di Active Directory.
2. Aprire Gestione accesso utente. Dalla finestra principale di YaST, avviare Gestione accesso utente e selezionare Modifica impostazioni . Questo è il modulo di autenticazione basato su SSSD descritto nella guida di SLES 15 SP7; è diverso dal modulo Appartenenza al dominio Windows , che utilizza Winbind.
3. Aggiungi il dominio AD. Seleziona Aggiungi dominio , immetti il ​​nome del dominio DNS, ad esempio corp.example.com, e seleziona Microsoft Active Directory sia per i dati di identità che per l'autenticazione. Assicurati che il dominio sia abilitato. Se il rilevamento automatico DNS non è appropriato nella tua rete, specifica i nomi host del controller di dominio approvato come descritto nella guida.
4. Verifica il nome del computer e il risultato del rilevamento. Confronta il nome host locale con il nome del computer desiderato in Active Directory. Correggi eventuali discrepanze prima della registrazione. YaST dovrebbe rilevare un server Active Directory e segnalare che il client non è ancora registrato. Se il rilevamento fallisce, torna ai controlli DNS, dell'ora, del routing e del firewall anziché provare provider di autenticazione casuali.
5. Registrati con un account autorizzato. Inserisci le credenziali AD consentite per l'accesso al computer. YaST può installare il software mancante durante questo processo. La finestra di dialogo potrebbe offrire un'opzione per sovrascrivere la configurazione di Samba; abilitala solo se tale modifica è destinata alla tua configurazione Samba/AD e, se i servizi Samba sono già in uso, mantieni prima la configurazione esistente.
6. Abilita il comportamento di accesso previsto. In Gestisci accesso utenti di dominio , attiva l'accesso degli utenti di dominio solo dopo aver deciso quali account devono avere accesso. Configura la creazione di directory home locali se gli utenti ne hanno bisogno. SUSE documenta le fallback_homediropzioni override_homedire mostra /home/%uun formato possibile. In un ambiente multidominio, progetta un percorso univoco e consulta il manuale di SSSD prima di affidarti esclusivamente a un nome utente breve.
7. Salva, rivedi e testa con un utente non privilegiato. Applica le impostazioni, verifica che il dominio e le opzioni scelte siano corrette, quindi testa un normale account di dominio dalla console o tramite il servizio di accesso che intendi utilizzare. Non eseguire il test solo con l'account che si è connesso al computer.

Come si verifica l'adesione al servizio SSSD?

Verifica che SSSD sia attivo, che NSS sia in grado di risolvere un'identità di dominio nota e che un accesso effettivo abbia successo. Dopo che l'utente di test ha effettuato l'accesso, verifica la presenza di un ticket Kerberos. SUSE elenca kliste getent passwdtra i suoi controlli di connessione.

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

La stringa di identità esatta dipende dalle impostazioni di denominazione SSSD; alcuni ambienti utilizzano DOMAIN\userun nome in stile UPN anziché un nome in stile UPN. Se getentnon viene restituito alcun record, verificare di star interrogando il formato del nome e il dominio configurati, quindi esaminare i log del servizio:

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

Una ricerca andata a buon fine da sola non dimostra che l'utente possa accedere, e un ticket Kerberos esistente non dimostra che ogni applicazione utilizzi lo stack PAM previsto. Testa una nuova sessione, un eventuale cambio di password, l'autorizzazione basata sui gruppi e il percorso di accesso SSH o desktop pertinente. Verifica che l'accesso sia limitato alle persone a cui intendi concederlo.

SSSD o Winbind: quale compromesso è più importante?

Per la maggior parte dei client SLES che necessitano di identità AD e accessi interattivi, SSSD è la scelta più semplice, supportata dalle linee guida di SUSE per la gestione degli accessi utente. Integra la ricerca delle identità e l'autenticazione PAM e può memorizzare nella cache le informazioni per garantire la resilienza quando la directory è temporaneamente irraggiungibile. L'accesso tramite cache presenta dei limiti: il primo accesso non può basarsi su credenziali memorizzate nella cache e le risorse basate sulla directory o le modifiche delle password richiedono comunque un controller di dominio raggiungibile. È consigliabile definire e testare la propria policy di accesso offline, anziché considerare la memorizzazione nella cache come una soluzione completa per le interruzioni di Active Directory.

Scegli Winbind quando un requisito dipende specificamente dall'integrazione del dominio Samba, da NTLM o dalle relazioni di trust tra foreste. Non si tratta semplicemente di un'alternativa a SSSD: ogni percorso utilizza daemon e componenti NSS/PAM diversi. Documenta quale servizio gestisce le ricerche di dominio e gli accessi ed evita di mescolare vecchie modifiche manuali PAM/NSS con le impostazioni gestite da YaST.

Da utilizzare realmdquando è importante un flusso di lavoro di shell ripetibile. La Guida all'amministrazione dello storage di SUSE SLES 15 SP7 documenta realm discover --verboseil rilevamento basato su DNS, realm join --verbosela registrazione e realm permitle autorizzazioni di accesso. Verificare quale software client è selezionato e quale configurazione SSSD viene generata nella propria release. Evitare di concedere l'accesso generico "a tutti" in produzione, a meno che non si tratti di una policy esplicita.

Guasti comuni e controllo successivo

• La ricerca del dominio non restituisce alcun risultato: controlla il server DNS del client e il record SRV di Active Directory, quindi verifica che l'host possa raggiungere i controller di dominio elencati.
• Errori Kerberos nonostante una password corretta: verificare la sincronizzazione dell'ora di sistema, il nome DNS utilizzato per il controller di dominio e se l'account del computer è abilitato e denominato correttamente.
• L'utente riesce a risolvere il problema ma non riesce ad accedere: verificare che l'accesso al dominio sia abilitato in YaST, controllare le restrizioni di accesso e lo stato dell'account in Active Directory e rivedere i log di SSSD/PAM.
• L'accesso funziona, ma la directory home non è presente: verificare che la creazione della directory home sia abilitata e che il percorso configurato sia valido e univoco per l'utente.
• L'operazione di join fallisce dopo precedenti tentativi: verificare la presenza di oggetti computer obsoleti, nomi host duplicati, configurazioni Winbind o NSS/PAM manuali residue e password dei computer non corrispondenti. Coordinare le operazioni di pulizia con l'amministratore di Active Directory prima di eliminare un oggetto computer o cancellare i dati SSSD locali.

Quando è il momento di fermarsi e scegliere un approccio diverso?

Prima di procedere con il rollout, sospendi l'implementazione se il tuo ambiente si basa su comportamenti di trust tra foreste, NTLM, un ruolo server Samba, diverse foreste con nomi utente brevi sovrapposti o regole di accesso complesse non contemplate dalle impostazioni di base di YaST. Queste condizioni possono modificare il provider preferito o richiedere una configurazione SSSD aggiuntiva. Esegui dei test con account rappresentativi e servizi reali in un sistema di staging e mantieni l'accesso di ripristino finché la policy non sarà valida.

In sintesi: per una workstation o un server SLES 15 SP7 standard che necessita di identità e accessi ad Active Directory, il percorso di gestione degli accessi utente YaST supportato da SSSD è il primo passo. Assicurati innanzitutto che DNS, ora, denominazione host e autorizzazioni di join siano corretti; quindi verifica la risoluzione dei nomi, Kerberos, l'accesso PAM e l'ambito di accesso. Seleziona Winbind per i requisiti specifici di Samba, NTLM o cross-forest identificati da SUSE e utilizzalo realmdquando il suo flusso di lavoro da riga di comando si adatta meglio al tuo processo operativo.

Fonti: Guida alla sicurezza e alla protezione di SUSE SLES 15 SP7: supporto per Active Directory ; Guida all'amministrazione dello storage di SUSE SLES 15 SP7: realmd ; SUSE SLES 15 SP7: client di autenticazione e SSSD ; Note di rilascio di SUSE SLES 15 SP7 .