Apache jest jednym z najczęściej wykorzystywanych serwerów httpd. Jeśli skompilujemy go razem z modułem mod_authnz_ldap, będziemy mieli możliwość uwierzytelniania użytkowników poprzez katalog LDAP.
Korzystając z mechanizmu portów instalujemy serwer apache:
cd /usr/ports/www/apache22 make install clean
Przy wyborze opcji wybieramy LDAP oraz AUTHNZ_LDAP.
Teraz możemy przejść do skonfigurowania modułu. Na początek sprawdźmy czy te dwie poniższe linijki znajdują się w pliku konfiguracyjnym /usr/local/etc/apache22/httpd.conf:
LoadModule ldap_module libexec/apache22/mod_ldap.so LoadModule authnz_ldap_module libexec/apache22/mod_authnz_ldap.so
Powinny być one dodane automatycznie podczas instalacji apache. Jeśli jednach ich nie ma dopiszmy je na końcu listy dytektyw LoadModule.
Nadanie uprawnień użytkownikowi składa się z 2 faz. W pierwszej fazie uwierzytelnienia sprawdzana jest poprawność pary danych: loginu oraz hasła. W drugiej fazie moduł rozstrzyga, czy uwierzytelniony użytkownik ma prawo dostępu do zasobu.
Konfigurację przeprowadzamy wewnątrz dyrektywy
<Directory "/usr/local/www/apache22/data"> AuthName "Private ZONE" AuthType basic AuthBasicProvider ldap AuthLDAPURL "ldap://localhost:389/ou=people,dc=firma,dc=bogus" Require ldap-user "test" </Directory>
Trzy dytektywy: AuthLDAPURL, AuthLDAPBindDN oraz AuthLDAPBindPassword biorą udział w pierwszej fazie uwierzytelnienia. Pierwsza z nich jest obowiązkowa, pozostałe dwie są opcjonalne. Konfigurując AuthLDAPURL określamy adres serwer LDAP, korzeń DN, atrybut wykorzystywany podczas operacji wyszukiwania oraz dodatkowe filtry przeszukiwania. W przykładzie podałem jedynie korzeń, od którego ma nastąpić wyszukanie użytkownika. Rozszerzony zapis wyglądałby na przykład tak:
AuthLDAPURL "ldap://localhost:389/ou=people,dc=firma,dc=bogus?uid?sub?(objectClass=*)"AuthLDAPBindDN oraz AuthLDAPBindPassword określają DN oraz hasło, które mają być użyte podczas logowania do serwera LDAP. Te parametry wykorzystywane są w przypadku, gdy konfiguracja ACL’i serwera LDAP nie pozwala dostęp nie uwierzytelnionemu użytkownikowi.
Druga faza odpowiada za autoryzację użytkownika. Aby nadać użytkownikowi dostęp do danego zasobu, należy użyć dyrektywy Require. Możliwe są poniższe konfiguracje:
•Require ldap-user – sprawdzana jest nazwa użytkownika
•Require ldap-dn – porównywany jest DN zwrócony przez serwer LDAP
•Require ldap-group – sprawdzane jest czy użytkownik należy do grupy
•Require ldap-attribute – sprawdzany jest konkretny atrybut
•Require ldap-filter – podobnie jak wyżej, ale wyszukanie przeprowadzone jest na całym katalogu wykorzystując filtr, a nie poprzez proste porównanie atrybutów
Uwaga! Jeśli używamy wartości Required dla innego modułu, to aby możliwa była autoryzacja, dyrektywa AuthzLDAPAuthoritative musi mieć ustawioną wartość off.
OK. Czas rozszerzyć te suche informacje o przykłady. Sam korzystam głównie z dyrektywy ‘Require ldap-user’, aczkolwiek przydatne jak dla mnie są też ‘Require ldap-group’ oraz ‘Require ldap-attribute’.
Require ldap-user
W tej dytektywie podajemy nazwę użytkownika (lub użytkowników), który ma mieć przyznany dostęp do zasobu. Jeśli nie skonfigurowaliśmy atrybutu, po którym dokonywane jest sprawdzenie, użyty zostanie atrybut ‘uid’.
Require ldap-user test janek
Jeśli w dytektywie AuthLDAPURL (AuthLDAPURL ldap://localhost:389/ou=people,dc=firma,dc=bogus?cn) podaliśmy atrybut ‘cn’ jako ten, po którym ma być dokonywane sprawdzenie, dyrektywa Require może wyglądać tak:
Require ldap-user “Jan Kowalski”
W przypadku kilku użytkowników
Require ldap-user “Jan Kowalski”
Require ldap-user “Adam Nowak”
Należy pamiętać, że może to być problematyczne, jeśli kilka osób w tym samym katalogu ma podobne cn, ponieważ wyszukanie po atrybucie cn musi zwrócić dokładnie jeden wpis. Dlatego polecam przeszukiwać katalog po atrybucie uid, który jest unikalny.
Require ldap-group
W tej dyrektywie podajemy grupę, której członkowie mają mieć przyznany dostęp do zasobu, na przykład:
Require ldap-group cn=webaccess,ou=groups,dc=firma,dc=bogus
Dodatkowe zachowanie możemy skonfigurować za pomocą tych dwóch opcji:
AuthLDAPGroupAttribute – za pomocą tej dyrektywy określamy które atrybuty mają być użyte w celu sprawdzenia członkostwa w grupie (standardowo member oraz uniquemember)
AuthLDAPGroupAttributeIsDN Directive – jeśli ma wartość on (standardowo) sprawdzany jest DN. Jeśli off sprawdzana jest nazwa użytkownika(uid).
Require ldap-attribute
Sprawdzana jest wartość atrybutu
Require ldap-attribute employeeType=active
I na sam koniec jeszcze kilka dodatkowych przykładów.
Aby nadać uprawnienia wszystkim użytkownikom w bazie:
AuthLDAPURL "ldap://localhost:389/ou=people,dc=firma,dc=bogus?uid?sub?(objectClass=*)" Require valid-user
Podobnie jak w przykładzie powyżej uprawnienia zostaną nadane wszystkim użytkownikom, przy czym podaliśmy 2 serwery LDAP:
AuthLDAPURL "ldap://localhost backup_ldap.firma.local/ou=people,dc=firma,dc=bogus" Require valid-user
W tym przykładzie uprawnienia otrzymają wszyscy użytkownicy, którzy dodatkowo są aktywnymi pracownikami.
AuthLDAPURL ldap://localhost:389/ou=people,dc=firma,dc=bogus?uid??(employeeType=active) Require valid-user
A co jeśli chcemy nadać uprawnienia wszystkim aktywnym pracownikom oraz komuś kto na przykład nie jest pracownikiem firmy?
AuthLDAPURL ldap://localhost:389/ou=people,dc=firma,dc=bogus?uid??(|(employeeType=active) (uid=dziennikarz)) Require valid-user
Powyższe przykłady pokazują, że rozszerzając dyrektywę AuthLDAPURL o dodatkowe opcję, możemy (poprzez wprowadzenie do wpisu użytkownika dodatkowego atrybutu) w prosty sposób zarządzać dostępem do odpowiednich zasobów.
Virtual Hosts z LDAP
mod_cfg_ldap pozwala na przechowywanie konfiguracji hostów wirtualnych w katalogu LDAP i uaktualnianie jej w czasie rzeczywistym.
Korzystając z mechanizmu portów instalujemy moduł mod_cfg_ldap:
cd /usr/ports/www/mod_cfg_ldap make install clean
Przed uruchomieniem tego modułu musimy skopiować schemat LDAP:
cp /usr/local/share/doc/mod_cfg_ldap/mod_cfg_ldap.schema /usr/local/etc/openldap/schema/mod_cfg_ldap.schema
Następnie dodajmy go do konfiguracji serwera LDAP (/usr/local/etc/openldap/slapd.conf)
include /usr/local/etc/openldap/schema/mod_cfg_ldap.schema
i zrestartujmy serwer:
/usr/local/etc/rc.d/slapd restart
Teraz możemy zacząć konfigurację modułu w serwerze Apache. W tym celu musimy dodać 2 wpisy do pliku konfiguracyjnego /usr/local/etc/apache22/httpd.conf. Pierwszy z nich załaduje moduł podczas startu serwera. Podczas instalacji ta linijka zostanie dodana automatycznie, należy ją tylko odznaczyć:
LoadModule cfg_ldap_module libexec/apache22/mod_cfg_ldap.so
Drugi dołączy konfigurację modułu:
Include etc/apache22/extra/cfg_ldap.conf
Teraz tworzymy w katalogu /usr/local/etc/apach22/extra plik cfg_ldap.conf zawierający poniższą konfigurację:
<IfModule mod_cfg_ldap.c> EnableCfgLdap on CfgLdapUseTLS off #CfgLdapTrustedCA "/etc/apache2/ssl/ca.crt" CfgLdapServer "localhost" CfgLdapBindDN "cn=admin,dc=firma,dc=bogus" CfgLdapCredentials "secret" CfgLdapBaseDN "ou=apache,dc=firma,dc=bogus" # if you don't want to use any filter just keep the following CfgLdapFilter "(objectClass=apacheConfig)" # otherwise you could filter based on cosine.schema's ARecord # CfgLdapFilter "(|(ARecord=127.0.0.1)(ARecord=127.0.0.2))" CfgLdapCacheTTL 60 </IfModule>
Restartujemy serwer apache:
/usr/local/etc/rc.d/apache22 restart
Na sam koniec dodajemy wpisy do katalogu LDAP:
# Wpis 1: ou=apache,dc=firma,dc=bogus dn: ou=apache,dc=firma,dc=bogus ou: apache objectclass: organizationalUnit objectclass: top # Wpis 2: ou=my_virtual_host,ou=apache,dc=firma,dc=bogus dn: ou=my_virtual_host,ou=apache,dc=firma,dc=bogus apacheDocumentRoot: /usr/local/www/apache22/data/my_virtual_host_directory apacheServerName: my_virtual_host objectClass: organizationalUnit objectClass: top objectClass: apacheConfig ou: my_virtual_host
Aby wszystko zadziałało musimy jeszcze dodać rekord my_virtual_host do serwera DNS.
