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.