Integracja SLES 15 Active Directory z SSSD: przewodnik krok po kroku

W przypadku typowego hosta SUSE Linux Enterprise Server 15, który wymaga logowania użytkowników domeny, SUSE dokumentuje YaST User Logon Management z SSSD jako najlepsze rozwiązanie w większości środowisk Active Directory. SSSD zapewnia tożsamość systemu Linux i ścieżkę uwierzytelniania PAM, podczas gdy Active Directory pozostaje źródłem kont i uwierzytelniania Kerberos. Winbind jest lepszym rozwiązaniem, gdy projekt opiera się na NTLM lub obsłudze zaufania między lasami. Jeśli preferujesz automatyzację, SUSE dokumentuje również łączenie z realmd; jest to narzędzie do wykrywania domen i członkostwa, dlatego przed użyciem na dużą skalę należy upewnić się, jakie oprogramowanie klienckie i polityka dostępu zostaną skonfigurowane w systemie.

Ten przewodnik jest oparty na przewodniku SLES 15 SP7 Security and Hardening Guide, sprawdzonym 6 października 2026 r. Dodatki Service Pack SUSE mogą się różnić, a poniższe instrukcje stanowią procedurę opartą na dokumentacji, a nie stwierdzenie, że polecenia zostały uruchomione w Twojej domenie. Zastąp przykładowe nazwy domeny i hosta wartościami ze swojego środowiska. Przetestuj najpierw na niekrytycznym komputerze SLES i zachowaj lokalne konto administratora na wypadek nieprawidłowej konfiguracji uwierzytelniania domeny.

Wybierz metodę integracji odpowiednią do zadania

SUSE opisuje opcję YaST wspieraną przez SSSD jako odpowiednią dla większości połączeń AD i identyfikuje Winbind w przypadkach wymagających NTLM lub zaufania między lasami. Są to praktyczne punkty wyjścia, które nie zastępują testowania specyficznych wymagań aplikacji, takich jak obsługa plików Samba, reguły sudo, wyszukiwanie klucza SSH czy kolizje nazw w wielu domenach. W przypadku prostej floty logowań do systemu Linux, należy zacząć od SSSD, chyba że udokumentowane wymagania wskazują na inne rozwiązanie.

Co przygotować przed dołączeniem SLES do Active Directory

• Stabilna nazwa hosta: Wybierz zamierzoną, w pełni kwalifikowaną nazwę hosta i upewnij się, że jest ona spójna w sieci i w usłudze Active Directory. Uzgodnij konwencję nazewnictwa kont komputerów z zespołem ds. katalogu.
• Działający DNS z obsługą AD: Klient SLES musi wysłać zapytanie do serwera DNS, który może rozpoznać strefę AD i jej rekordy usług (SRV). Samo użycie publicznego resolvera często uniemożliwia odnalezienie domeny.
• Synchronizacja czasu: Kerberos wymaga ścisłego dopasowania zegarów klienta i kontrolerów domeny. Przed rozwiązywaniem problemów z hasłami lub SSSD należy sprawdzić synchronizację NTP.
• Dostęp sieciowy do kontrolerów domeny: Upewnij się, że zapora sieciowa i routing zezwalają na protokoły i porty wymagane przez projekt Active Directory (AD) w Twojej organizacji, w tym DNS, Kerberos, LDAP oraz wszelki wymagany ruch związany z katalogiem globalnym lub zmianą hasła. Nie otwieraj szeroko każdego portu; poproś administratora AD/sieci o podanie zatwierdzonych reguł.
• Autoryzowana tożsamość rejestracji: Użyj konta uprawnionego do dodawania lub ponownego używania obiektów komputerowych w odpowiedniej jednostce organizacyjnej. Unikaj rutynowego korzystania z konta o wysokich uprawnieniach, gdy dostępne są delegowane uprawnienia do dołączania.
• Dostęp do odzyskiwania: Zachowaj sprawdzony login administratora lokalnego i sposób dostępu do konsoli. Nie ustawiaj domeny jako jedynej drogi powrotnej na serwer przed zatwierdzeniem nowej ścieżki logowania.

SUSE wyraźnie wskazuje na dostępność DNS przez AD i dokładny czas dla Kerberos. W przewodniku zaznaczono, że domena kończąca się na .localmoże kolidować z DNS multicast w niektórych scenariuszach dołączania. Jeśli AD używa tego sufiksu, przed zmianą nazewnictwa lub ustawień resolvera należy skonsultować się z administratorem katalogu w celu sprawdzenia konsekwencji dla wersji SLES i konfiguracji sieci.

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

Polecenie hostmoże wymagać pakietu narzędzi DNS w przypadku instalacji minimalnej. Te kontrole nie dowodzą, że każda wymagana ścieżka zapory jest otwarta; pomagają one wykryć typowe problemy z rozpoznawaniem nazw i zegarem przed rejestracją.

Dołącz do domeny za pomocą YaST i SSSD

1. Ustaw resolver. Otwórz YaST i wybierz Ustawienia sieciowe , a następnie Nazwa hosta/DNS . Skonfiguruj serwer DNS usługi Active Directory lub wewnętrzny resolver, który poprawnie przekierowuje strefę Active Directory. Zapisz zmiany i sprawdź, czy host może rozpoznać kontroler domeny i rekordy usługi Active Directory.
2. Otwórz Zarządzanie logowaniem użytkowników. W oknie głównym YaST uruchom Zarządzanie logowaniem użytkowników i wybierz Zmień ustawienia . Jest to moduł uwierzytelniania oparty na SSSD w podręczniku SLES 15 SP7; różni się on od modułu Członkostwa w domenie Windows , który korzysta z Winbind.
3. Dodaj domenę usługi Active Directory (AD). Wybierz opcję Dodaj domenę , wprowadź nazwę domeny DNS, taką jak corp.example.com, i wybierz Microsoft Active Directory dla danych tożsamości i uwierzytelniania. Upewnij się, że domena jest włączona. Jeśli automatyczne wykrywanie DNS nie jest dostępne w Twojej sieci, określ zatwierdzone nazwy hostów kontrolerów domeny zgodnie z opisem w przewodniku.
4. Sprawdź nazwę komputera i wynik wykrywania. Porównaj nazwę hosta lokalnego z docelową nazwą komputera w usłudze Active Directory. Popraw wszelkie niezgodności przed rejestracją. YaST powinien wykryć serwer usługi Active Directory i zgłosić, że klient nie jest jeszcze zarejestrowany. Jeśli wykrywanie się nie powiedzie, wróć do sprawdzania DNS, czasu, routingu i zapory sieciowej, zamiast próbować losowych dostawców uwierzytelniania.
5. Zarejestruj się za pomocą autoryzowanego konta. Wprowadź dane logowania do usługi Active Directory (AD) uprawniające do połączenia z komputerem. Podczas tego procesu YaST może zainstalować brakujące oprogramowanie. Okno dialogowe może zawierać opcję nadpisania konfiguracji Samby. Włącz ją tylko wtedy, gdy zmiana ta jest przeznaczona dla Twojej konfiguracji Samba/AD, a jeśli usługi Samby są już używane, najpierw zachowaj istniejącą konfigurację.
6. Włącz zamierzony sposób logowania. W sekcji „Zarządzanie logowaniem użytkowników domeny” włącz logowanie użytkowników domeny dopiero po ustaleniu, które konta powinny mieć do niego dostęp. Skonfiguruj tworzenie lokalnych katalogów domowych, jeśli użytkownicy ich potrzebują. Dokumentacja SUSE zawiera fallback_homediropcje override_homediri pokazuje /home/%umożliwy format. W środowisku wielodomenowym zaprojektuj unikalną ścieżkę i zapoznaj się z podręcznikiem SSSD, zanim zaczniesz polegać wyłącznie na krótkiej nazwie użytkownika.
7. Zapisz, przejrzyj i przetestuj z użytkownikiem bez uprawnień. Zastosuj ustawienia, sprawdź poprawność domeny i wybranych opcji, a następnie przetestuj zwykłe konto domenowe na konsoli lub za pośrednictwem usługi logowania, z której planujesz korzystać. Nie testuj tylko na koncie, które zostało podłączone do komputera.

Jak weryfikujesz dołączenie SSSD?

Sprawdź, czy SSSD jest aktywne, czy NSS może rozpoznać znaną tożsamość domeny i czy logowanie się powiodło. Po zalogowaniu się użytkownika testowego sprawdź, czy jest dostępny bilet Kerberos. SUSE wymienia klisti getent passwdsprawdza połączenia.

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

Dokładny ciąg identyfikacyjny zależy od ustawień nazewnictwa SSSD; niektóre środowiska używają DOMAIN\usernazwy w stylu UPN. Jeśli getentnie zwróci żadnego rekordu, sprawdź, czy odpytujesz skonfigurowany format nazwy i domenę, a następnie przejrzyj dzienniki usługi:

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

Samo pomyślne wyszukiwanie nie dowodzi, że użytkownik może się zalogować, a istniejący bilet Kerberos nie dowodzi, że każda aplikacja korzysta z odpowiedniego stosu PAM. Przetestuj nową sesję, zmień hasło, jeśli jest to wymagane, autoryzację opartą na grupach oraz odpowiednią ścieżkę logowania SSH lub na komputerze. Upewnij się, że dostęp jest ograniczony do osób, którym chcesz zezwolić.

SSSD czy Winbind: który kompromis jest ważniejszy?

Dla większości klientów SLES, którzy potrzebują tożsamości w usłudze Active Directory i interaktywnych logowań, SSSD to oczywisty wybór, wspierany przez przewodnik SUSE dotyczący zarządzania logowaniem użytkowników. Integruje wyszukiwanie tożsamości i uwierzytelnianie PAM oraz może buforować informacje, zapewniając odporność na awarie, gdy katalog jest tymczasowo niedostępny. Dostęp z pamięci podręcznej ma swoje ograniczenia: pierwsze logowanie nie może polegać na buforowanych danych uwierzytelniających, a zasoby obsługiwane przez katalog lub zmiany haseł nadal wymagają dostępnego kontrolera domeny. Skonfiguruj i przetestuj swoją politykę logowania offline, zamiast traktować buforowanie jako rozwiązanie na wypadek awarii usługi Active Directory.

Wybierz Winbind, gdy wymaganie zależy konkretnie od integracji domeny Samby, NTLM lub zaufania między lasami. Nie jest to po prostu alternatywne pole wyboru dla SSSD: każda ścieżka korzysta z innych demonów i komponentów NSS/PAM. Udokumentuj, która usługa jest właścicielem wyszukiwań domen i logowań, i unikaj mieszania starych, ręcznych zmian w PAM/NSS z ustawieniami zarządzanymi przez YaST.

Używaj, realmdgdy powtarzalny przepływ pracy powłoki ma znaczenie. Dokumenty w Podręczniku administratora pamięci masowej SUSE SLES 15 SP7 realm discover --verbosedotyczą wykrywania w oparciu o DNS, realm join --verboserejestracji i realm permituprawnień logowania. Sprawdź, jakie oprogramowanie klienckie jest wybrane i jaka konfiguracja SSSD jest generowana w Twoim wydaniu. Unikaj szerokiego dostępu „zezwól wszystkim” w środowisku produkcyjnym, chyba że jest to wyraźnie określone.

Typowe awarie i następna kontrola

• Wykrywanie domeny nie zwraca żadnych wyników: sprawdź serwer DNS klienta i rekord SRV usługi AD, a następnie potwierdź, czy host może nawiązać połączenie z wymienionymi kontrolerami domeny.
• Błędy protokołu Kerberos pomimo podania prawidłowego hasła: Sprawdź synchronizację czasu systemowego, nazwę DNS używaną dla kontrolera domeny oraz to, czy konto komputera jest włączone i ma prawidłową nazwę.
• Użytkownik rozwiązuje problem, ale nie może się zalogować: Sprawdź, czy logowanie domenowe jest włączone w YaST, sprawdź ograniczenia dostępu i status konta w usłudze AD oraz przejrzyj dzienniki SSSD/PAM.
• Logowanie działa, ale brakuje katalogu domowego: Sprawdź, czy tworzenie katalogu domowego jest włączone i czy skonfigurowana ścieżka jest prawidłowa i unikatowa dla użytkownika.
• Dołączenie kończy się niepowodzeniem po wcześniejszych eksperymentach: Sprawdź, czy nie występują nieaktualne obiekty komputerowe, zduplikowane nazwy hostów, resztki konfiguracji Winbind lub ręcznej konfiguracji NSS/PAM oraz niezgodne hasła komputera. Przed usunięciem obiektu komputerowego lub wyczyszczeniem lokalnych danych SSSD skonsultuj czyszczenie z administratorem usługi Active Directory.

Kiedy należy przerwać i wybrać inne podejście?

Wstrzymaj się przed wdrożeniem, jeśli Twoje środowisko opiera się na zachowaniu zaufania między lasami, NTLM, roli serwera Samba, kilku lasach z nakładającymi się krótkimi nazwami użytkowników lub złożonych regułach dostępu, których podstawowe ustawienia YaST nie uwzględniają. Takie warunki mogą zmienić preferowanego dostawcę lub wymagać dodatkowej konfiguracji SSSD. Przetestuj je na kontach reprezentatywnych i rzeczywistych usługach w systemie przejściowym i zachowaj login odzyskiwania do momentu potwierdzenia poprawności polityki.

Podsumowanie: W przypadku standardowej stacji roboczej lub serwera SLES 15 SP7, który wymaga tożsamości i loginów Active Directory, należy rozpocząć od ścieżki zarządzania logowaniem użytkowników YaST obsługiwanej przez SSSD. Najpierw sprawdź uprawnienia DNS, czas, nazewnictwo hostów i dołączanie; następnie zweryfikuj wyszukiwanie nazw, Kerberos, logowanie PAM i zakres dostępu. Wybierz Winbind dla konkretnych wymagań Samba, NTLM lub międzylasowych zidentyfikowanych przez SUSE i użyj go, realmdgdy jego przepływ pracy w wierszu poleceń lepiej pasuje do Twojego procesu operacyjnego.

Źródła: SUSE SLES 15 SP7 Security and Hardening Guide: obsługa Active Directory ; SUSE SLES 15 SP7 Storage Administration Guide: realmd ; SUSE SLES 15 SP7: klienci uwierzytelniania i SSSD ; SUSE SLES 15 SP7 Release Notes .