Jak podłączyć linuxa do domeny Windows? praktyczny poradnik z realmd i SSSD

Jeśli zastanawiasz się, jak podłączyć linuxa do domeny windows, potraktuj to jak wdrożenie kilku zależnych od siebie usług, a nie jedną komendę w terminalu. W praktyce najpierw muszą zadziałać DNS, FQDN i czas systemowy, dopiero potem Kerberos, SSSD i PAM. Dzięki temu logowanie domenowe na Linuxie działa przewidywalnie także w małej lub średniej firmie.

Dlaczego warto połączyć system Linux z domeną Active Directory

Integracja Linuxa z Active Directory ma sens wszędzie tam, gdzie firma chce centralnie zarządzać tożsamościami, a nie utrzymywać osobnych kont lokalnych na każdym komputerze. Użytkownik loguje się tym samym hasłem, administrator kontroluje dostęp grupami, a przy zmianie roli lub odejściu pracownika nie trzeba szukać kont na kolejnych stacjach.

To rozwiązanie jest też praktyczne od strony wsparcia. Na jednym hoście Linux możesz oprzeć dostęp do zasobów, logowanie i uprawnienia sudo na tej samej polityce, którą już znasz z domeny Windows. W środowisku biurowym upraszcza to audyt, zmniejsza liczbę haseł do zapamiętania i ogranicza ryzyko, że ktoś zostanie zbyt długo z lokalnym kontem administracyjnym.

Warto jednak pamiętać, że to nie jest wybór „zróbmy to, bo wszyscy tak robią”. Jeśli masz jedną maszynę i bardzo proste użycie, lokalne konto może być wystarczające. Gdy jednak chcesz zarządzać większą liczbą stacji, serwerów lub komputerów technicznych, Linux w domenie Windows daje po prostu lepszą kontrolę. Największa korzyść pojawia się wtedy, gdy dostęp można cofnąć jedną zmianą w grupie AD, zamiast ręcznie poprawiać konfigurację na każdej maszynie.

Przygotowanie systemu Linux do integracji z domeną Windows

Zanim zainstalujesz pakiety integracyjne, sprawdź trzy rzeczy: nazwę hosta, DNS i czas. To etap, który administratorzy najczęściej pomijają, a potem szukają błędu w SSSD, choć problem leży dużo wcześniej. W małej firmie najlepiej traktować ten krok jak checklistę przed zmianą systemową: warto mieć kopię ważnych danych, znać aktualną konfigurację i wiedzieć, jak się wycofać, jeśli coś pójdzie źle.

Najpierw ustaw pełną nazwę hosta. Dla domeny twojadomena.pl maszyna może nazywać się np. linux01.twojadomena.pl. Polecenie hostnamectl ustawia nazwę systemową, którą później wykorzystują usługi logowania i Kerberos:

sudo hostnamectl set-hostname linux01.twojadomena.pl

Potem sprawdź plik /etc/hosts. W wielu środowiskach warto dodać wpis powiązany z lokalnym adresem i FQDN, aby system nie rozwiązywał własnej nazwy do dziwnego adresu z DNS zewnętrznego. To drobiazg, ale przy integracji domenowej bardzo pomaga w diagnostyce. Jeśli korzystasz z NetworkManagera lub systemd-resolved, pamiętaj, że /etc/resolv.conf bywa generowany automatycznie — liczy się efekt końcowy, czyli to, czy maszyna naprawdę pyta kontroler domeny o rekordy DNS.

Najważniejszy jest jednak serwer DNS. W AD Linux powinien wskazywać DNS kontrolera domeny, a nie publiczny resolver od dostawcy internetu. To DNS odpowiada za rekordy SRV, których potrzebuje realm discover i późniejszy kontakt z kontrolerem domeny. Jeśli system ma pytać o domenę Windows przez niewłaściwy serwer nazw, dołączenie do domeny zwykle zakończy się błędem mimo poprawnych danych logowania.

Trzeci element to synchronizacja czasu. Kerberos bardzo źle toleruje rozjazd zegara, a różnica większa niż kilka minut potrafi zablokować uwierzytelnianie. W praktyce warto mieć na Linuksie chrony albo inną usługę NTP i wskazać wiarygodne źródło czasu, najlepiej z tej samej infrastruktury co domena. Sprawdzenie jest proste:

timedatectl status
chronyc sources -v
chronyc tracking

Jeśli po tych testach czas się nie zgadza, nie przechodź dalej. Najpierw napraw NTP. To oszczędza godzinę diagnostyki później.

Jak podłączyć linuxa do domeny windows krok po kroku przy użyciu Realmd i SSSD

Realmd + SSSD to dziś najrozsądniejsza ścieżka dla Debiana, Ubuntu i pochodnych. Daje sensowny kompromis między prostotą wdrożenia, bezpieczeństwem i łatwością diagnozy. To właśnie ten wariant polecam jako domyślny, bo jest przewidywalny i nie wymaga nietypowych obejść. Jeśli zastanawiasz się, jak podłączyć linuxa do domeny windows bez dłubania w starych narzędziach, zacznij właśnie tutaj.

1. Zainstaluj pakiety integracyjne. Na Debianie i Ubuntu najczęściej wystarczają realmd, sssd, sssd-tools, libnss-sss, libpam-sss, krb5-user, adcli, samba-common-bin oraz oddjob z modułem do katalogów domowych. Przykład:

   sudo apt update
   sudo apt install realmd sssd sssd-tools libnss-sss libpam-sss krb5-user adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

   Jeśli instalator pyta o domenę Kerberos, wpisz swoją rzeczywistą nazwę realm, zwykle dużymi literami. Gdy pakiety nie chcą się doinstalować, zatrzymaj się i sprawdź repozytoria oraz łączność z Internetem, ale nie pomijaj DNS lokalnego.

2. Odkryj domenę. To szybki test, który mówi, czy Linux w ogóle widzi kontroler domeny przez DNS:

   realm discover twojadomena.pl

   Jeśli komenda nic nie zwraca albo pokazuje błędny wynik, przyczynę szukaj w rekordach SRV i resolverze. Nie przechodź od razu do join, bo zły discovery zwykle kończy się tym samym problemem tylko później.

3. Sprawdź Kerberos przed dołączeniem. To bezpieczniejsza diagnostyka niż czekanie na błąd podczas join:

   kinit [email protected]
   klist

   Jeśli biletu nie da się pobrać, najczęściej winny jest czas, DNS albo nieprawidłowy realm. Ten krok od razu pokazuje, czy uwierzytelnienie działa po stronie protokołu, zanim system zacznie zmieniać własną konfigurację.

4. Dołącz host do domeny. Użyj konta, które ma prawo tworzyć obiekty komputerów w AD lub wskaż właściwą jednostkę organizacyjną:

   sudo realm join -U Administrator twojadomena.pl

   W bardziej uporządkowanym wdrożeniu możesz doprecyzować OU:

   sudo realm join -U Administrator twojadomena.pl --computer-ou="OU=Linux,DC=twojadomena,DC=pl"

   Jeśli polecenie kończy się błędem uprawnień, nie zgaduj. Sprawdź konto w AD, uprawnienia do tworzenia komputerów i zgodność nazwy domeny z DNS.

5. Zweryfikuj wynik i uruchom SSSD. Po udanym join sprawdź stan domeny i zrestartuj usługę:

   realm list
   systemctl enable --now sssd
   systemctl restart sssd

   Test logowania warto wykonać od razu, najlepiej poleceniami id uż[email protected] oraz getent passwd użytkownik. Jeśli system nie zwraca danych użytkownika, problem jest po stronie NSS, SSSD albo zasad dostępu.

Jeżeli potrzebujesz wycofać zmiany, nie walcz z konfiguracją ręcznie. Zwykle łatwiej wykonać realm leave twojadomena.pl, usunąć zmiany w SSSD i sprawdzić, co dokładnie zostało zapisane. Dobre wdrożenie to nie tylko skuteczne dołączenie, ale też możliwość bezpiecznego powrotu.

Konfiguracja logowania i automatycznego tworzenia katalogów domowych

Po samym dołączeniu do domeny użytkownik nadal może nie mieć wygodnego logowania ani katalogu domowego. To właśnie tutaj wchodzi PAM i moduł pam_mkhomedir. Jego zadanie jest proste: kiedy użytkownik domenowy loguje się pierwszy raz, system tworzy mu katalog w /home automatycznie, zamiast kończyć sesję błędem.

Na Debianie i Ubuntu najczęściej wystarczy włączyć odpowiedni moduł przez pam-auth-update albo dodać wpis do /etc/pam.d/common-session. Bezpieczny wariant wygląda tak:

session required pam_mkhomedir.so skel=/etc/skel umask=0077

umask=0077 jest tutaj ważny. Dzięki niemu pliki i katalogi nowego użytkownika nie będą domyślnie czytelne dla innych osób. W praktyce to lepszy wybór niż zbyt luźne uprawnienia, bo w środowisku firmowym katalog domowy powinien być prywatny. Jeśli polityka organizacji wymaga trochę większej współdzielności, można to dostosować, ale bezmyślne pozostawienie domyślnej maski to zły pomysł.

Równie ważna jest konfiguracja /etc/sssd/sssd.conf. To tam decydujesz, czy użytkownik ma logować się pełną nazwą domenową, czy krótszym loginem, oraz gdzie mają trafiać katalogi domowe. Przykładowy, bezpieczny szablon dla jednej domeny może wyglądać tak:

[sssd]
config_file_version = 2
services = nss, pam
domains = twojadomena.pl

[domain/twojadomena.pl]
id_provider = ad
access_provider = ad
ad_domain = twojadomena.pl
krb5_realm = TWOJADOMENA.PL
cache_credentials = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
default_shell = /bin/bash
ldap_id_mapping = True

Po zapisaniu pliku ustaw jego prawa na 600 i zrestartuj SSSD. To ważne, bo konfiguracja zawiera dane, które nie powinny być czytelne dla zwykłych użytkowników. Jeśli masz więcej niż jedną zaufaną domenę, use_fully_qualified_names = False nie zawsze będzie najlepszym wyborem. Wtedy lepiej zachować pełne nazwy, żeby uniknąć konfliktów kont.

Na końcu zrób test praktyczny: zaloguj się jako użytkownik domenowy lokalnie lub przez SSH i sprawdź, czy katalog domowy pojawił się automatycznie. Jeśli nie, najpierw weryfikuj PAM, potem SSSD, a dopiero na końcu samą domenę.

Zarządzanie uprawnieniami i nadawanie praw sudo użytkownikom domenowym

Najbezpieczniejszy model to nadawanie sudo nie pojedynczym osobom „na zawsze”, ale wybranej grupie domenowej przeznaczonej tylko do administracji Linuxem. Dzięki temu członkostwo w grupie w AD staje się jednym miejscem kontroli, a po odebraniu dostępu nie musisz poprawiać kilku hostów osobno.

W praktyce tworzysz osobną grupę, na przykład Linux Admins lub, jeszcze lepiej, nazwę techniczną bez spacji. To nie jest kaprys. sudoers jest bardziej wrażliwy na format nazwy niż konsola AD, a nazwy z odstępami częściej prowadzą do błędów lub nieczytelnej konfiguracji. W środowisku produkcyjnym polecam grupę bez spacji i bez ozdobników, bo tak jest po prostu łatwiej ją utrzymać.

Plik z wyjątkami twórz przez visudo, najlepiej w /etc/sudoers.d/. Przykład dla grupy domenowej:

sudo visudo -f /etc/sudoers.d/ad-linux-admins

%linux-admins ALL=(ALL) ALL

Jeśli chcesz nadać prawa tylko jednej osobie, wpis może wyglądać podobnie, ale w praktyce grupa jest znacznie bezpieczniejsza i łatwiejsza do audytu. Dobrą praktyką jest też ograniczenie zakresu, jeśli użytkownik nie potrzebuje pełnego roota. Zamiast dawać wszystko, można zezwolić tylko na konkretne komendy, ale to zależy już od polityki firmy i tego, jak szeroki ma być dostęp.

Po zapisaniu pliku sprawdź składnię i przetestuj widoczność grupy w systemie. Jeżeli getent group linux-admins nic nie zwraca, problem leży wcześniej w integracji z AD, a nie w samym sudoers. Z kolei jeśli grupa jest widoczna, ale użytkownik nie dostaje praw, sprawdź cache SSSD i odśwież informacje poleceniem sss_cache -E oraz ponownym logowaniem.

Alternatywne metody integracji: PBIS Open oraz Microsoft Entra ID

Jeśli środowisko jest starsze albo masz specyficzny powód, możesz rozważyć PBIS Open jako alternatywę. To rozwiązanie bywa stosowane tam, gdzie administrator chce mieć jeden agent integracyjny i prosty model logowania. Trzeba jednak uczciwie powiedzieć, że nie jest to automatycznie lepszy wybór niż realmd + SSSD. W nowoczesnym Debianie i Ubuntu standardem pozostaje raczej zestaw oparty o SSSD, bo łatwiej go diagnozować i utrzymać.

W środowiskach chmurowych, zwłaszcza przy Microsoft Entra Domain Services, zasady są podobne, ale szczegóły zależą od aktualnej dokumentacji i konfiguracji infrastruktury. Dochodzą kwestie sieci VNet, DNS zarządzanego katalogu i polityk dostępności. Nie zakładaj, że konfiguracja z klasycznego AD zadziała identycznie bez poprawek. Tu ważniejsza od „magicznych komend” jest zgodność z usługą i dokładne sprawdzenie, skąd maszyna bierze nazwę domeny oraz czas.

Jeżeli wybierasz między metodami, patrz przede wszystkim na wsparcie dystrybucji, przewidywalność i łatwość odzyskania konfiguracji po błędzie. W małej lub średniej organizacji zwykle lepiej sprawdza się rozwiązanie, które da się wytłumaczyć i odtworzyć za pół roku, niż narzędzie efektowne na starcie, ale trudne w utrzymaniu. Dlatego jako punkt wyjścia nadal polecam realmd + SSSD, a PBIS Open traktuję jako wariant zależny od konkretnego środowiska.

Rozwiązywanie najczęstszych problemów podczas dołączania do domeny

Gdy proces kończy się błędem, nie zgaduj na ślepo. Najpierw sprawdź, czy realm discover widzi domenę. Jeśli nie, wróć do DNS i rekordów SRV. Wiele środowisk psuje się na domenach .local, bo kolidują z mDNS i Avahi. Jeśli możesz, wybierz nazwę DNS, która nie wchodzi w konflikt z mechanizmami rozgłaszania lokalnego.

Jeżeli realm join zwraca błędy Kerberosa, typu GSSAPI albo problem z uwierzytelnieniem, sprawdź zegar. Różnica czasu między klientem a kontrolerem domeny nadal jest jednym z najczęstszych powodów porażki. Użyj timedatectl, chronyc tracking i porównaj wynik z czasem serwera domeny. W praktyce nawet poprawne hasło nie pomoże, jeśli czas się rozjechał.

Gdy host jest już w domenie, ale użytkownik nie może się zalogować, zwykle problem siedzi w regułach dostępu SSSD albo w cache. Sprawdź realm list, getent passwd [email protected] i logi journalctl -u sssd oraz pliki w /var/log/sssd/. Jeśli korzystasz z reguł dopuszczających tylko wybranych użytkowników, upewnij się, że nie zablokowałeś logowania przez pomyłkę. Warto też odświeżyć cache poleceniem sss_cache -E i ponownie uruchomić usługę.

Jeżeli wszystko działa, ale katalog domowy nie tworzy się automatycznie albo ma złe uprawnienia, wróć do PAM i sprawdź pam_mkhomedir.so oraz ustawioną maskę umask. To jest etap, który łatwo przeoczyć, bo samo logowanie wydaje się działać, a problem ujawnia się dopiero przy zapisie plików. Właśnie dlatego warto testować całość od razu po wdrożeniu, nie po kilku dniach.

Na koniec jedna praktyczna zasada: jeśli musisz wybierać, najpierw napraw sieć i tożsamość, potem dopiero wygodę. Gdy DNS, czas, Kerberos i SSSD są poprawne, Linux w domenie Windows przestaje być problemem technicznym, a staje się normalnym, przewidywalnym elementem administracji. I o to właśnie chodzi przy wdrożeniu w firmie.