Pracując z Active Directory wyobrażamy sobie jednorodne środowisko. Serwery z Windows 2xxx oraz końcówki z systemem operacyjnym Windows 10. Rzeczywistość nie jest taka różowa, ponieważ z najróżniejszych powodów trafiać będą nam się komputery z desktopowym Linuxem, lub z MAC OS`em. Żeby zachować porządek z komputerami i mieć nad nimi jakąkolwiek “władzę” dobrze jest mieć je w jednym miejscu oraz być pewnym, że użytkownicy logują się swoimi kontami domenowymi i hasłami z AD, co niewątpliwie ułatwia życie. Tu z pomocą przychodzą nam dwa demony: realmd oraz sssd.
Nasz pierwszy demon – realmd – jest to systemowa usługa na żądanie, która umożliwia konfiguracje uwierzytelnienia sieciowego i członkostwa w domenie. Realmd konfiguruje sssd lub winbind do uwierzytelniania sieciowego i wyszukiwania kont użytkowników. Natomiast SSSD (System Security Services Daemon) jest odpowiedzialny za zapewnienie dostępu do lokalnych lub zdalnych zasobów tożsamości i uwierzytelnienia poprzez wspólną strukturę, która może zapewnić buforowanie i obsługę systemu offline. Zapewnia kilka interfejsów, w tym moduły NSSi PAM lub interfejs D-BUS.
Tyle tytułem wstępu i wprowadzenia. Przejdzmy zatem do sedna, czyli zajmijmy się dodaniem Debiana do domeny.
W pierwszej kolejności sprawdzamy, czy mamy system w pełni aktualny:
sudo apt update
sudo apt upgrade
Następnie musimy upewnić się, ze nasz host ma odpowiednią nazwę:
#hostname
moj_host.pelna.nazwa.naszej.domeny
Jeśli nazwa jest zła to korygujemy to:
#sudo hostnamectl set-hostname moj_host.pelna.nazwa.naszej.domeny
Sprawdzamy , czy jest poprawnie:
#hostnamectl
Static hostname: moj_host.pelna.nazwa.naszej.domeny
Icon name: computer-laptop
Chassis: laptop
Machine ID: 93e5e421d6844c33b811b114b99cbfc9
Boot ID: 380075b170354e41b475165f8c89ab0d
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 5.8.0-2-amd64
Architecture: x86-64
Upewniamy się, czy w /etc/resolv.conf mamy poprawne DNS`y, które zapewnią nam kontakt z kontrolerem domeny. Mamy system przygotowany, teraz trzeba zainstalować niezbędne pakiety.
#sudo apt -y install realmd libnss-sss libpam-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Po prawidłowej instalacji nasz system jest gotowy do odkrywania Active Directory.
#sudo realm discover pelna.nazwa.naszej.domeny
pelna.nazwa.naszej.domeny
type: kerberos
realm-name: PELNA.NAZWA.NASZEJ.DOMENY
domain-name: pelna.nazwa.naszej.domeny
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
Jeżeli mamy łączność z AD, czas dodać do niej nasz komputer. Potrzebujemy do tego konta domenowego, uprawnionego do dodawania komputerów do domeny (w tym przypadku – ad_admin).
#sudo realm join -U ad_admin pelna.nazwa.naszej.domeny
Password for Administrator:
Zweryfikujmy nasze poczynania:
#realm list
pelna.nazwa.naszej.domeny
type: kerberos
realm-name: PELNA.NAZWA.NASZEJ.DOMENY
domain-name: pelna.nazwa.naszej.domeny
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U@pelna.nazwa.naszej.domeny
login-policy: allow-permitted-logins
Dla pewności należy skorzystać z przystawki na Window Active Directory Users and Computers i przenieść naszą nowo dodaną maszynę do właściwego OU. Następnym krokiem jest zapewnienie nowo logującym się użytkownikom automatycznegp utworzenia katalogów domowych. W tym celu zawartość pliku /usr/share/pam-configs/mkhomedir powinna wyglądać następująco:
Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session:
required pam_mkhomedir.so umask=0022 skel=/etc/skel
Teraz wprowadzimy te ustawienia w życie:
sudo pam-auth-update
Upewniamy się, czy wszystkie pola są zaznaczone [*] I potwierdzamy <OK>
Kolej na sssd. Sprawdzamy, czy nasza integracja jest uruchomiona. Jeśli nie, uruchamiamy ją za pomocą:
#/etc/init.d/sssd status
● sssd.service – System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-10-14 15:05:20 CEST; 1h 13min ago
Main PID: 4435 (sssd)
Tasks: 4 (limit: 9084)
Memory: 89.2M
CGroup: /system.slice/sssd.service
├─4435 /usr/sbin/sssd -i –logger=files
├─4436 /usr/libexec/sssd/sssd_be –domain pelna.nazwa.naszej.domeny –uid 0 –gid 0 –logger=files
├─4437 /usr/libexec/sssd/sssd_nss –uid 0 –gid 0 –logger=files
└─4438 /usr/libexec/sssd/sssd_pam –uid 0 –gid 0 –logger=files
Jeżeli wszystko działa to przetestujmy komunikacje z AD i wyszukajmy użytkownika:
#id uzytkownik.domenowy@pelna.nazwa.naszej.domeny
uid=1783929917(uzytkownik.domenowy@pelna.nazwa.naszej.domeny) gid=1784800513(domain users@pelna.nazwa.naszej.domeny) groups=1783870513(domain users@pelna.nazwa.naszej.domeny)
Żeby użytkownicy mogli się logować do Linuxa, musimy im na to zezwolić.
Możemy robić to per user:
#realm permit uzytkownik1@pelna.nazwa.naszej.domeny
#realm permit uzytkownik1@pelna.nazwa.naszej.domeny uzytkownik2@pelna.nazwa.naszej.domeny uzytkownik3@pelna.nazwa.naszej.domeny
Lub per grupa domenowa:
#ream permit -g admini
#realm permit -g 'Programisci Kalisz’
#realm permit 'Centala’ 'Filia 1′
Możemy także zezwolić wszystkim użytkownikom na dostęp do Linuxa:
#sudo realm permit –all
Bądź zabronić wszystkim użytkownikom domenowym dostępu:
#sudo realm deny –all
Gdy zgody na logowanie zostały przydzielone, należy jeszcze ustawić uprawnienia do korzystania z sudo, ponieważ domyślnie użytkownicy domenowi bez względu na to,do jakiej grupy w domenie będą należeć uprawnień do sudo mieć nie będą. Stwórzmy sobie osobny plik z uprawnieniami dla użytkowników domenowych i dodajmy ich tam.
#sudo nano /etc/sudoers.d/domenowi
uzytkownik1@pelna.nazwa.naszej.domeny ALL=(ALL) ALL
uzytkownik2@pelna.nazwa.naszej.domeny ALL=(ALL) ALL
uzytkownik3@pelna.nazwa.naszej.domeny ALL=(ALL) ALL
Dla grupy będzie wyglądać to tak:
%grupa1@pelna.nazwa.naszej.domeny ALL=(ALL) ALL
%grupa\ z\ dluzsza\ nazwa@pelna.nazwa.naszej.domeny ALL=(ALL) ALL
Po tych zabiegach przyszedł czas na testy. Należy teraz spróbować dostać się na konta domenowe tych użytkowników przez ssh (pamietajmy o używaniu pełnej nazwy użytkownika uzytkownik1@pelna.nazwa.naszej.domeny ). Jeśli zadziała to logowanie się do interfejsu graficznego też nie będzie stanowić problemu. Należy tylko umożliwić logowanie się przez interfejs graficzny do systemu innym użytkownikom, niż lokalne konta np. dla lightdm trzeba dodać wpis i zrestartować usługę.
nano /etc/lightdm/lightdm.conf
greeter-show-manual-login=true
#sudo service lightdm restart
Z poziomu Linuxa użytkownik może sam zmienić sobie hasło za pomocą komendy:
smbpasswd -U uzytkownik1 -r kontroler_domeny.pelna.nazwa.naszej.domeny
I tym sposobem mamy host z Linuxem dodany w domenie a użytkownicy logują się do systemu za pomocą poświadczeń z Active Directory.
Ostatnio zastanawiałem się nad dodaniem linucha jako zapasowy kontroler AD, ale samba chyba nie ogarnia niczego powyżej lasu Win Svr 2008R2?
A jak wygląda z poziomu WinSvr tworzenie zarządzanie komputerami innymi niż Windows? Właśnie Linux i Mac?
A jest jakaś faktyczna alternatywa względem AD opartym o WinSvr?