Linux i Active Directory - część I
27 grudnia 2007 10:56
Patryk Królikowski
Administruję niewielką siecią. Mam kilka serwerów i kilka stacji Linuksowych, reszta to Windowsy pracujące w domenie. Chciałbym ujednolicić uwierzytelnianie użytkowników pracujących na obydwu rodzajach systemów operacyjnych. Czy da się jakoś "udomenowić" Linuksy? Chodzi mi głównie o zarządzanie użytkownikami i pozbycie się oddzielnych kont na Linuksie.
Na szczęście, począwszy od Windowsa 2000, Microsoft zdecydował się na wspieranie protokołu uwierzytelniania Kerberos. Dzięki temu przyłączanie stacji pracujących pod kontrolą Linuksa do domeny Active Directory stało się możliwe.
Oprócz samego Kerberosa, potrzebna będzie SAMBA i dostarczane wraz z nią narzędzia - w szczególności winbindd. Cały proces możemy podzielić na dwa etapy. Pierwszym jest przyłączenie stacji/serwera do domeny; drugim skonfigurowanie zasad uwierzytelniania przy użyciu loginu domenowego. Przyłączanie będzie wyglądało trochę inaczej w przypadku serwerów, inaczej w przypadku stacji roboczych. Przede wszystkim dlatego, że rzadko kiedy na serwerach wykorzystuje się nakładki graficzne np. KDE czy Gnome.
Zacznijmy więc od serwerów. W naszym przykładzie działamy na serwerze pod kontrolą CentOS 4.5 Server. Zakładamy, że Samba jest już zainstalowana. Możemy przystąpić do poszczególnych kroków konfiguracyjnych. Na pierwszy rzut Kerberos. W każdej dystrybucji Linuksa natywnie dostępny jest klient Kerberosa. Jego parametry konfiguruje się za pomocą pliku /etc/krb5.conf.
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = NASZTEST.PL
dns_lookup_realm = true
dns_lookup_kdc = true
[realms]
NASZTEST.PL = {
kdc =dc.nasztest.pl
}
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
Jest to okrojona wersja konfiguracyjna krb5.conf, ale do naszych potrzeb wystarczająca. To, co zostało oznaczone kolorem czerwonym należy dopasować do własnego środowiska Active Direcotry. Koniecznie trzeba pamiętać o rozróżnieniu na duże i małe litery - bez tego usługa może nie działać prawidłowo. Ponieważ Kerberos jest bardzo wrażliwy na rozbieżności czasowe należy też zadbać o ustawienie synchronizacji czasu z serwerem czasu (polecenie ntpdate). Dla wygody warto wywoływać synchronizację automatycznie w określonych odstępach czasu za pomocą systemowego cron-a.
Kolejny krok to konfiguracja samej SAMBY. Tutaj zmian dokonuje się w pliku /etc/samba/smb.conf. Poniżej znajduje się lista parametrów w sekcji [global], które koniecznie należy zmodyfikować lub dopisać:
workgroup = NASZTEST # tutaj wpisujemy nazwę domeny
security = ads
encrypt passwords = yes
realm = NASZTEST.PL
password server = DC.NASZTEST.PL
winbind separator = +
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
Pozostała część konfiguracji SAMBY to już inna historia.
Teraz można podłączyć serwer do domeny:
# net ads join -U Administrator
Administrator's password:
Using short domain name - NASZTEST
Joined 'LINSERWER' to realm 'NASZTEST.PL'
Warto jeszcze sprawdzić, czy faktycznie zostaliśmy dołączeni do domeny:
# wbinfo -t
checking the trust secret via RPC calls succeeded
# wbinfo net ads testjoin
Join is OK
Jeżeli teraz uruchomimy przystawkę zarządzania użytkownikami i komputerami Active Directory (na kontrolerze domeny), to w sekcji "Komputery" powinniśmy zobaczyć nowo dodany serwer. Teraz pora na aktywację usługi winbind - korzysta ona z Linuksowej implementacji odwołań Microsoftowego RPC. W tym celu trzeba zmodyfikować plik /etc/nsswitch.conf odpowiedzialny za dostarczanie źródeł rozwiązywania nazw np. hostów, aliasów pocztowych, użytkowników. Wskazanie winbind jako źródła informacji pozwala na powiązanie ich z domeną Windows. Musimy zatem w pliku nsswitch.conf dokonać dwóch zmian:
passwd: files winbind
group: files winbind
Kolejnym etapem jest uruchomienie mechanizmu uwierzytelniania w Linuksie przy pomocy danych domenowych. W tym celu konieczne będzie "pogrzebanie" w modułach PAM (Pluggable Authentication Modules).
W niektórych systemach uniksowych np. AIX wszelkich zmian w PAM-ie dokonuje się za pośrednictwem jednego pliku (/etc/pam.conf). W Linuksach jednak konfiguracja PAM-a rozproszona jest pomiędzy kilkunastoma modułami znajdującymi się w katalogu /etc/pam.d/.
UWAGA!!! Już przy odrobinie niefrasobliwości, wszelkie zabawy z PAM-em, mogą skończyć się katastrofą - brakiem możliwości zalogowania w systemie (w takim przypadku ratować można się np. uruchomieniem systemu w trybie tzw. single user mode). Dlatego też przed rozgrzebaniem PAM-a koniecznie trzeba zrobić kopię całego katalogu /etc/pam.d/.
W zależności od usługi, którą będziemy chcieli zintegrować pod kątem logowania z AD musimy poddać edycji odpowiedni plik. Moduł odpowiedzialny za obsługę winbind przez PAM-a znajduje się najczęściej w katalogu /lib/security i nosi nazwę pam_winbind.so. Jeżeli więc decydujemy się na integrację wszystkich usług możemy zmodyfikować plik /etc/pam.d/system-auth. Najważniejsze podczas wprowadzania zmian do PAM-a jest dodanie dwóch linii:
auth sufficient /lib/security/pam_winbind.so
oraz
account sufficient /lib/security/pam_winbind.so
Przy tej okazji należy pamiętać, co - z punktu widzenia PAM-a - powoduje dodanie atrybutu sufficient. Jeżeli moduł, który wskazany jest po tym atrybucie (w naszym przypadku pam_winbind.so) zwróci rezultat OK wówczas (pod warunkiem, że żaden z przetwarzanych wcześniej modułów z atrybutem required nie zwrócił błędu) to na nim kończy się przetwarzanie. Oznacza to, że jeżeli po takim wpisie znajdzie się inny, z atrybutem required nigdy nie zostanie przetworzony. Trzeba zatem dobrze przemyśleć kolejność wpisów w PAM-ie przed wprowadzeniem zmian. Dla przykładu następujące wpisy w dowolnym z modułów PAM:
auth required pam_nologin.so #1
auth sufficient pam_winbind.so #2
auth required pam_unix.so use_first_pass #3
oznaczają, że:
1. jeżeli w katalogu /etc znajdzie się plik n login wówczas logowanie będzie dozwolone tylko dla root-a.
2. pozostali użytkownicy mogą logować się przy użyciu hasła domenowego
3. jeżeli nie będzie można zalogować się korzystając z modułu winbind (np. awaria kontrolera domeny, zatrzymanie procesu winbind) wówczas zostanie wykorzystany standardowy moduł uwierzytelniania Unix (za pomocą danych z /etc/passwd, group i shadow). Parametr use_first_pass oznacza, że pierwsze wprowadzone hasło będzie wykorzystywane przez pozostałe moduły (w innym wypadku konieczne byłoby każdorazowe wprowadzanie hasła podczas przetwarzania każdego z modułów PAM).
Dla przykładu skonfigurujmy usługę /etc/pam.d/login:
auth required pam_securetty.so
auth required pam_nologin.so
auth sufficient pam_winbind.so
auth required pam_unix.so use_first_pass
auth required pam_stack.so service=system-auth
account sufficient pam_winbind.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session required pam_mkhomedir.so skel=/etc/skel umask=0022
session required pam_loginuid.so
session optional pam_console.so
Oznaczone kolorem czerwonym wpisy zostały dodane do pliku. Wyjaśnienia wymaga jeszcze moduł pam_mkhomedir.so. Jest to bardzo użyteczny moduł pozwalający na automatyczne tworzenie katalogu domowego użytkownika podczas jego logowania do systemu. Katalog domowy tworzony jest tylko wtedy, kiedy użytkownik jeszcze go nie posiada.
Teraz dla pewności wystarczy zrestartować usługi Samby i Winbind:
# service smb restart
# service winbind restart
Teraz można przetestować możliwość logowania bezpośrednio z konsoli serwera. Należy używać następującej składni podczas logowania:
[nazwa domeny] + [nazwa użytkownika] np. NASZTEST + Patryk
Rezultaty procesu logowania możemy śledzić korzystając z logu systemowego (/var/log/messages). Jeżeli wszystko poszło zgodnie z planem powinniśmy móc logować się do systemu korzystając z konta domenowego.
W części drugiej pokażemy jak podłączyć do domeny stację roboczą wykorzystującą środowisko graficzne.
AudioBot - odsłuchaj materiał
wydrukuj
wyślij do znajomego
