Konfiguracja klienta LDAP w systemie Solaris

Oracle Solaris ma wbudowane wsparcie dla LDAP w systemie operacyjnym, więc nie ma potrzeby instalowania specjalnego oprogramowania aby skonfigurować go do korzystania z repozytoriów użytkowników/grup i innych zdefiniowanych w LDAP. Można to zrobić na różne sposoby i ja opiszę tu kilka z nich.

Jeśli wymagana jest bezpieczna komunikacja, a korzystamy z własnoręcznie wygenerowanych i podpisanych certyfikatów to najpierw trzeba zainstalować certyfikat CA na każdym z klientów.
Można to osiągnąć importując certyfikat CA do lokalnego magazynu przy pomocy narzędzia certutil (/usr/sfw/bin/certutil w Solaris 10). Najpierw należy utworzyć bazę NSS:
(Proszę nie wprowadzać hasła, po prostu naciśnij enter)

certutil -N -d /var/ldap
chmod 444 /var/ldap/*

Teraz ściągnij certyfikat CA i zapisz go gdzieś na dysku, np. w /var/tmp/cacert.pem. Następnie dodaj certyfikat CA do NSS DB:

certutil -A -n "ca-cert" -i /var/tmp/cacert.pem -a -t CT -d /var/ldap

Powinny zostać utworzone trzy pliki w katalogu /var/ldap: cert8.db, key3.db oraz secmod.db. Teraz można przetestować czy to działa używając ldapsearch:

ldapsearch -v -h ldapsrvp01 -p 636 -Z -P /var/ldap/cert8.db \ 
 -b "dc=mycompany,dc=com" -s base "objectclass=*"

gdzie ldapsrvp01 jest nazwą serwera LDAP zdefiniowaną w /etc/hosts lub DNS i również znajduje się w polu Common Name w certyfikacie serwera. Jeśli te nazwy będą się różnić, dostaniesz komunikat błędu, np.

ldap_search: Can't contact LDAP server.

W tym przypadku należy zdefiniować nazwę z CN znajdującego się w certyfikacie serwera w /etc/hosts lub wygenerować na nowo certyfikat serwera z właściwą nazwą.

Teraz można przejść do inicjalizacji klienta LDAP.
Chwila! Jeszcze nie, szczególnie jeśli nie planujesz używania LDAPa jako resolvera nazw domenowych itp. Inicjalizacja klienta LDAP powoduje zastąpienie pliku /etc/nsswitch.conf plikiem /etc/nsswitch.ldap (w Solarisie 10). To może być niebezpieczne, ponieważ w większości instalacji, z którymi się spotkałem, do rozwiązywania nazw służy DNS, a to ustawienie zostanie nadpisane.
Moja rada jest taka, aby zrobić kopię pliku /etc/nsswitch.ldap i nadpisać go aktualną zawartością pliku /etc/nsswitch.conf:

mv /etc/nsswitch.ldap /etc/nsswitch.ldap.default
cp -p /etc/nsswitch.conf /etc/nsswitch.ldap

wtedy wyedytować /etc/nsswitch.ldap i dodać 'ldap’ do tych wpisów gdzie zamierzamy z tego repozytorium korzystać, np.:

passwd:     files ldap
group:      files ldap

ale pozostałe zostawić tak jak było i powinno być, np.:

hosts:      cluster files [SUCCESS=return] dns
# Note that IPv4 addresses are searched for in all of the ipnodes databases
# before searching the hosts databases.
ipnodes:    cluster files dns [TRYAGAIN=0]
networks:   files dns
protocols:  files

Teraz można zainicjalizować klienta LDAP ręcznie lub używając Profili zdefiniowanych na serwerze.
Zakładam, że użytkownik „cn=proxyuser,dc=mycompany,dc=com” z hasłem „secretProxyPassword” jest zdefiniowany w LDAPie i posiada dostęp do odczytu drzewa informacji (DIT), bazą jest „dc=mycompany,dc=com”, a nazwą serwera jest „ldapsrvp01” (można też użyć adresu IP).
Inicjalizacja manualna:

ldapclient manual \
-a domainName=mycompany.com -a credentialLevel=proxy \
-a defaultSearchBase=dc=mycompany,dc=com \ 
-a proxyDN=cn=proxyagent,dc=mycompany,dc=com \ 
-a proxyPassword=secretProxyPassword \
ldapsrvp01

To spowoduje następujące rzeczy:
Zostanie utworzony plik ldap_client_file z powyższymi ustawieniami LDAP
Zostanie utworzony plik ldap_client_cred z dn i hasłem użytkownika proxyagent
/etc/nsswitch.ldap zostanie skopiowany jako /etc/nsswitch.conf
Usługa svc:/network/ldap/client:default zostanie uruchomiona

Jeśli ma być użyta szyfrowana komunikacja oraz dostępna możliwość zmiany haseł użytkowników z systemu, należy dodać następujące ustawienia:

ldapclient mod \
-a authenticationMethod=tls:simple \
-a enableShadowUpdate=TRUE \
-a adminDN=cn=admin,dc=mycompany,dc=com \
-a adminPassword=secretAdminPassword

Trochę mylące może być to, że authenticationMethod jest „tls:simple”, ale połączenie do serwera nie odbywa się na porcie 389 z użyciem StartTLS, ale po SSL na porcie 636, proszę to mieć na uwadze.

Kolejnym sposobem jest inicjalizacja klienta LDAP używając Profilu, jeśli taki jest umieszczony w LDAP w gałęzi „ou=profile,dc=mycompany,dc=com”, mój poprzedni wpis zawiera krótki opis i przykładowy profil. Tutaj do skonfigurowania klienta używam profilu „cn=dev,ou=profile,dc=mycompany,dc=com”:

ldapclient init \
-a domainName=mycompany.com \
-a profileName=dev \
-a proxyDN=cn=proxyagent,dc=mycompany,dc=com \
-a proxyPassword=secretProxyPassword \
-a adminDN=cn=admin,dc=mycompany,dc=com \
-a adminPassword=secretAdminPassword \
-a enableShadowUpdate=TRUE \
192.168.0.1

Jeśli system zostanie pomyślnie skonfigurowany powinna być możliwość wylistowania ustawień LDAP:

ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,dc=mycompany,dc=com
NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f
NS_LDAP_SERVERS= 192.168.0.1
NS_LDAP_SEARCH_BASEDN= dc=mycompany,dc=com
NS_LDAP_CREDENTIAL_LEVEL= proxy
...

oraz użytkowników/grup z drzewa LDAP poprzez „getent passwd”, „getent group” itp.
Jeśli coś poszło źle, należy przyjrzeć się problemowi zaczynając od komunikatów zwróconych przez komendę ldapclient, logów, statusu usługi ldap/client oraz konfiguracji NSS (/etc/nsswitch.conf).

Inną metodą konfiguracji klienta LDAP – szczególnie jeśli jest duża ilość tych klientów – jest skonfigurowanie jednej maszyny używając którejś z powyższych metod, a następnie skopiowanie zawartości katalogu /var/ldap oraz pliku /etc/nsswitch.conf na pozostałe maszyny. Później wystarczy włączyć na nich usługę svc:/network/ldap/client:default i voila. Jest to szybka i niezbyt zalecana metoda, ale działa.