Protokół LDAP może wspomagać pracę serwerów poczty elektronicznej. Istnieją różnorodne aspekty zastosowania LDAP-a w serwerach pocztowych działających według protokołów SMTP (sendmail, qmail), IMAP, czy POP3 (rozwiązania projektu Cyrus z Carnegie Mellon oraz implementacje University of Washington).
1. LDAP jako serwer bazy użytkowników
Po pierwsze LDAP może udostępniać serwerom bazę użytkowników systemu pocztowego. Przydzielenie użytkownikowi skrzynki pocztowej w takiej sytuacji nie koniecznie musi oznaczać, że użytkownik dysponuje kontem w systemie.Serwer SMTP przyjmując pocztę sprawdza, czy dany użytkownik jest znany w systemie. Nie musi w tym procesie korzystać z systemowego pliku haseł (/etc/passwd), w wyszukaniu użytkownika może pośredniczyć serwer LDAP lub można korzystać z innych, zdefiniowanych w systemie źródeł danych. Dzieje się tak dzięki odpowiedniej konfiguracji usługi zwanej Name Service Switch (NSS). Mechanizm ten został opracowany przez firmę Sun w celu ujednolicenia procedur stosowanych w celu dotarcia przez stację kliencką, czy aplikację sieciową do informacji dotyczącej sieci komputerowej. Takie podejście jest stosowane m.in. w systemach Solaris oraz Linux. Bazuje na zastosowaniu pliku nsswitch.conf, który steruje sposobem doboru źródeł informacji. Typowo dane dotyczące użytkowników, grup, stacji komputerowych, protokołów, czy zdefiniowanych sieci są pobierane z plików lub z usługi NIS (Network Information Service). Podejście NSS jest uniwersalne i stosunkowo łatwo można rozszerzać źródła danych. Między innymi w ramach PADL Software powstał moduł nss_ldap umożliwiający korzystanie z usługi katalogowej LDAP. Serwer LDAP, z którym współpracuje NSS przechowuje dane zgodne z definicją zawartą w dokumencie [RFC2307]. Jeśli w systemowym pliku nsswitch.conf wskazano usługę katalogową LDAP jako źródło bazy danych passwd; np. jest w nim wiersz:
passwd ldap files
to użytkownik o danym identyfikatorze jest najpierw poszukiwany w zasobach LDAP, potem w pliku /etc/passwd.host nazwa_hosta
Należy pamiętać, że nazwa_hosta musi być rozstrzygalna bez pomocy usługi LDAP."(&(objectClass=posixAccount)(uid=nazwa))"
czyli użytkownik musi być reprezentowany w bazie danych za pomocą klasy obiektów posixAccount.W opisanym powyżej rozwiązaniu realizacja bazy użytkowników za pomocą usługi LDAP jest funkcją zintegrowaną z systemem operacyjnym, na którym działa serwer pocztowy. Takie podejście nie wymaga więc żadnej specjalnej konfiguracji serwera poczty SMTP, którego zadaniem jest przyjmowanie poczty kierowanej do użytkowników systemu oraz wysyłanie maili.
Serwery POP/IMAP odgrywają w systemie nieco inną rolę - obsługują zlecenia użytkownika dotyczące skrzynki pocztowej (otwarcie skrzynki, pobranie kolejnego listu itp.). W tym przypadku nie jest wystarczające stwierdzenie, że dany użytkownik istnieje w systemie. Niezbędne jest również jego uwierzytelnienie, czyli sprawdzenie, czy dane dostarczone w celu weryfikacji tożsamości są poprawne. Taki proces jest standardowo realizowany w oparciu o parę danych (identyfikator, hasło). Również w tej sytuacji można wykorzystać LDAP-a. Tym razem współpraca LDAP-a z systemem operacyjnym jest realizowana za pomocą rozwiązania nazywanego w skrócie PAM (Pluggable Authentication Module), które jest standardowo stosowane od kilku lat w większości popularnych systemów unixowych ([RFC86.0]). W najnowszych systemach operacyjnych właśnie PAM jest odpowiedzialny za realizację procesu uwierzytelnienia użytkownika ubiegającego się o prawo korzystania z usługi sieciowej. PAM działa w oparciu o zestaw modułów, które mogą być rozbudowywane w celu zaimplementowania w systemie nowych metod uwierzytelniania. Odpowiednia konfiguracja PAM-a umożliwia dopasowanie sposobu uwierzytelnienia do lokalnych potrzeb, m.in. zastosowanie usług katalogowych LDAP. Odbywa się to przez dodanie modułu pam_ldap.so przygotowanego dla danego systemu operacyjnego oraz zgodną z intencjami konfigurację (katalog /etc/pam.d w Linuxie lub plik /etc/pam.conf w Solarisie). Oprogramowanie pam_ldap jest dostarczane również w ramach PADL Software (pam_ldap.tgz). Jeżeli sam system operacyjny korzysta z PAM-a, to ta technika dostępu może być stosowana w dowolnej usłudze sieciowej. Gdy serwer POP/IMAP działa w systemie nie korzystającym standardowo z PAM-a, to można wymusić tego typu pracę dla konkretnej aplikacji. Służy do tego protokół SASL, Simple Authentication and Security Layer ([RFC2222]).
2. Przechowywanie tablic konfiguracyjnych serwera pocztyWiększość serwerów pocztowych korzysta z dodatkowych plików do przechowywania różnego typu danych konfiguracyjnych, np. aliasów, stacji wirtualnych, tablic zawierających dodatkowe odwzorowania adresów (tzw. mapy). Sendmail stosuje również z tzw. klasy, które są tworzone za pomocą plików lub zewnętrznych programów. W tym zakresie można również zastosować usługę LDAP. W zasobach LDAP można umieszczać tablice pomocnicze sendmaila, a sam serwer pocztowy tak skonfigurować, że potrzebne dane są pobierane za pomocą zapytań przekazywanych do serwera LDAP. Szczegółowe rozwiązania zostaną przedstawione dalej, przy opisie konkretnych implementacji serwerów (p. 4). Oczywiście takie rozwiązanie wymaga zastosowania odpowiedniego schematu danych w bazie LDAP (p. 4a). Zaletą przechowywania aliasów, map i klas w bazie LDAP jest poprawa bezpieczeństwa tych danych oraz ułatwienie zarządzania. Takie podejście nie wymaga również żadnych dodatkowych czynności po wniesieniu modyfikacji do bazy LDAP, podczas gdy typowo aktualizacja danych w plikach systemowych wiąże się z koniecznością realizacji dodatkowych operacji (np. wywołanie polecenia newaliases czy makemap w celu utworzenia właściwej wersji bazy danych, albo wręcz restart serwera poczty). Z kolei w serwerze qmail LDAP może pośredniczyć w ustalaniu dodatkowych danych o użytkownikach oraz definiować takie parametry, jak maksymalny dopuszczalny rozmiar skrzynki pocztowej (p. 4b).
3. Realizacja routingu poczty elektronicznejW styczniu 2001 w serii Internet-Draft została opublikowana druga wersja schematu LDAP służącego do definiowania informacji, z której aplikacje sieciowe mają korzystać do realizacji routingu poczty w ramach intranetu (draft-lachman-laser-ldap-mail-routing-02.txt, [LachmanI-D
]). Często zdarza się, że uzasadniona jest konfiguracja serwisu pocztowego w ten sposób, że z zewnątrz jest widoczny jeden serwer obsługujący całą domenę, tymczasem w ramach domeny chcemy niezależnie realizować routing poczty do lokalnych serwerów (tzw. routing intranetowy).Poniżej zostały przedstawione możliwości poszczególnych pakietów implementujących serwery poczty elektronicznej (protokołów SMTP, POP, IMAP) w zakresie współpracy z usługą katalogową LDAP.
Zastosowanie LDAP-a do obsługi aliasów, map i klas
Aby włączyć zastosowanie LDAP-a w sendmailu musi zostać zdefiniowana stała LDAPMAP, np. poprzez wpisanie w pliku devtools/Site/site.config.m4 wiersza:APPENDDEF(`confINCDIRS', `-I/opt/LDAP/include -I/opt/SSL/include') APPENDDEF(`confLIBDIRS', `-L/opt/LDAP/lib -L/opt/SSL/lib -Xlinker -R/opt/LDAP/lib -Xlinker -R/opt/SSL/lib') APPENDDEF(`confLIBS', `-lldap -llber -lssl -lcrypto')Jeśli korzystamy z wersji 2.x serwera LDAP, to w celu współpracy z programem sendmail musi zostać włąćzona w pliku konfiguracyjnym slapd.conf opcja
allow bind_v2Można wyspecyfikować własne reguły odwzorowania za pomoca LDAP-a lub skorzystać z reguł wbudowanych. Wbudowana, czyli domyślna specyfikacja sposobu realizacji odwzorowania za pomoca LDAP-a dostarcza metody dopasowywania na podstawie: (1) pełnej kwalifikowanej nazwy stacji (odpowiednik makra $j w konfiguracji sendmaila) lub (2) nazwy klastra. Wprowadzenie pojęcia klastra pozwala na współdzielenie wpisów umieszczonych w bazie LDAP przez wiele stacji, bez konieczności wpisywania nazw tych stacji do bazy katalogowej. Aby ustalić nazwę klastra LDAP-owskiego należy w konfiguracji m4 serwera (czyli w pliku .mc, na podstawie którego program m4 wyprodukuje właściwy plik konfiguracyjny serwera) zdefiniować zmienną confLDAP_CLUSTER; np. poniższe przypisanie nadaje klastrowi nazwę Serwery:
define(`confLDAP_CLUSTER', `Serwery')
Do obsługi aliasów, map i klas poprzez LDAP-a sendmail stosuje
własny schemat, który można znaleźć w dystrybucji pakietu w pliku
sendmail.schema.
Schemat ten należy włączyć do konfiguracji
serwera LDAP, dodając do pliku slapd.conf wiersz:
include /opt/LDAP/etc/openldap/schema/sendmail.schema
Schemat sendmaila definiuje sześć klas obiektów:
Definicja aliasów
Aby sendmail korzystał z LDAP-a do obsługi aliasów należy w konfiguracji m4 serwera następująco zdefiniować wartość ALIAS_FILE:
ldap -k (&(objectClass=sendmailMTAAliasObject)
(|(sendmailMTACluster=${sendmailMTACluster})
(sendmailMTAHost=$j))
(sendmailMTAKey=%0))
-v sendmailMTAAliasValue
Oznacza to, że w bazie LDAP jest wyszukiwany wpis określony za pomocą filtru
podanego w opcji -k, tj. wpis spełniający następujące warunki:
define( ALIAS_FILE, ldap:-k (&(objectClass=mailAlias)(uid=%0)) -v "uniqueMember,uniqueAlias")W tej sytuacji w celu znalezienia aliasu będzie poszukiwany wpis należący do klasy mailAlias mający wartość atrybutu uid równą wartości przekazanej w zapytaniu. Wynikiem przeszukania będzie wartość atrybutu uniqueAlias.
Oto przykład danych, które załadowane do bazy LDAP sprawią, wyszukanie aliasu dla klucza będącego lokalnym adresem Maja.Wolniewicz zwróci wartość mgw (zakłada się, że jest stosowane domyślne ustawienie wyszukiwania):
dn: sendmailMTAKey=Maja.Wolniewicz, dc=uci, dc=uni, dc=torun, dc=pl objectClass: sendmailMTA objectClass: sendmailMTAAlias objectClass: sendmailMTAAliasObject sendmailMTAAliasGrouping: aliases sendmailMTAHost: smtp.uci.uni.torun.pl sendmailMTAKey: Maja.Wolniewicz sendmailMTAAliasValue: mgwW podobny sposób realizuje się obsługę list mailowych. W tej sytuacji zazwyczaj określa się więcej niż jedną wartość atrybutu sendmailMTAAliasValue.
We wszystkich prezentowanych przykładach zamiast podawania atrybutu sendmailMTAHost można zdefiniwać wartość atrybutu sendmailMTACluster, by skorzystać z możliwości udostępnienia aliasu na kilku serwerach klastra.
Definicja map
Mapy są definiowane w konfiguracji m4 sendmaila za pomocą
dyrektywy FEATURE. W pierwszym argumencie podaje się nazwę mapy
(dopuszczalne nazwy to access_db, authinfo,
bitdomain, domaintable, genericstable,
mailertable, uucpdomain, virtualdomain).
Drugi argument określa rodzaj mapy i jej nazwę (np.
`dbm /etc/mail/virtusers'). W celu korzystania z danych
dostarczanych przez serwer LDAP należy podać w drugim argumencie
wartość `LDAP', np.
FEATURE(`genericstable', `LDAP').
Taka definicja spowoduje, że do wyszukiwania danych będzie używana następująca
formuła:
Kgenerics ldap
-1
-k (&(objectClass=sendmailMTAMapObject)
(|(sendmailMTACluster=${sendmailMTACluster})
(sendmailMTAHost=$j))
(sendmailMTAMapName=generics)
(sendmailMTAKey=%0))
-v sendmailMTAMapValue
czyli w bazie LDAP jest poszukiwany klucz określony za pomocą filtru
podanego w opcji -k, tj. wpis spełniający następujące warunki:
dn: sendmailMTAMapName=generics, dc=uci, dc=uni, dc=torun, dc=pl objectClass: sendmailMTA objectClass: sendmailMTAMap sendmailMTAHost: smtp.uci.uni.torun.pl sendmailMTAMapName: generics dn: sendmailMTAKey=Maja.Wolniewicz, sendmailMTAMapName=generics, dc=uci, dc=uni, dc=torun, dc=pl objectClass: sendmailMTA objectClass: sendmailMTAMap objectClass: sendmailMTAMapObject sendmailMTAMapName: generics sendmailMTAHost: smtp.uci.uni.torun.pl sendmailMTAKey: mgw sendmailMTAMapValue: Maja.Wolniewicz@uni.torun.plW tym przypadku zostaną załadowane do bazy LDAP dane realizujące odwzorowanie adresu wyjściowego mgw na adres Maja.Wolniewicz@uni.torun.pl.
Definicja klas
Jest również możliwe użycie LDAP-a do definicji klas, z których korzysta sendmail. Do klas stosowanych w tym programie należą m.in. klasy: R definiująca tzw. domeny relayowania (ustalenie, jak serwer postępuje z pocztą dla danej domeny) oraz G używana razem z mapą generics do określenia domen uwzględnianych w pełnej nazwie kwalifikowanej. Użycie w definicji klasy argumentu `@LDAP', np. umieszczenie w konfiguracji m4 serwera wierszy:
GENERICS_DOMAIN_FILE(`@LDAP') RELAY_DOMAIN_FILE(`@LDAP')oznacza, że klasy G i R będą korzystały z przeszukiwań LDAP-a, stosując domyślny filtr, np. w przypadku klasy G:
F{R}@ldap:-k (&(objectClass=sendmailMTAClass)
(sendmailMTAClassName=G)
(|(sendmailMTACluster=${sendmailMTACluster})
(sendmailMTAHost=$j)))
-v sendmailMTAClassValue
czyli w bazie LDAP jest wyszukiwany klucz określony za pomocą filtru
podanego w opcji -k, tj. wpis spełniający następujące warunki:
Oto przykładowa postać danych dotyczących klas G oraz R:
dn: sendmailMTAClassName=G, dc=uci, dc=uni, dc=torun, dc=pl objectClass: sendmailMTA objectClass: sendmailMTAClass sendmailMTAHost: smtp.uci.uni.torun.pl sendmailMTAClassName: G sendmailMTAClassValue: uci.uni.torun.pl sendmailMTAClassValue: smtp.uci.uni.torun.pl dn: sendmailMTAClassName=R, dc=uci, dc=uni, dc=torun, dc=pl objectClass: sendmailMTA objectClass: sendmailMTAClass sendmailMTAHost: smtp.uci.uni.torun.pl sendmailMTAClassName: R sendmailMTAClassValue: uci.uni.torun.pl
Realizacja routingu poczty w intranecie
Właczenie dyrektywy FEATURE(`ldap_routing') w konfiguracji m4 serwera sendmail oznacza, że będą impementowane własności zawarte w dokmencie Internet-Draft Lachmana i Shapiro, draft-lachman-laser-ldap-mail-routing-02.txt. Jest wówczas możliwe oparte na LDAP-ie routowanie poszczególnych adresów mailowych do innego serwera lub pod inny adres. Poszukiwanie w zasobach LDAP jest realizowane najpierw z pełnym adresem docelowym odbiorcy (np. user@aaa.pl), a następnie, w przypadku niepowodzenia, z adresem ograniczonym do części domenowej (np. @aaa.pl). Domena, której dotyczy routing za pomocą LDAP-a jest definiowana poleceniem:Zgodnie z dokumentem [LachmanI-D] do potrzeb routingu intranetowego jest używana jedna klasa obiektów - inetLocalMailRecipient. Klasa ta jest podporzadkowana klasie top. Zdefiniowano również trzy nieobowiązkowe atrybuty tej klasy:
Dyrektywa FEATURE(`ldap_routing') włącza domyślne procedury postępowania. Istnieje jednak możliwość dostosowania postaci zapytań do indywidualnych potrzeb. Służą do tego dodatkowe argumenty w poleceniu FEATURE():
FEATURE(`ldap_routing', <mailHost>, <mailRoutingAddress>, <bounce>, <detail>)
ldap -1 -v mailHost
-k (&(objectClass=inetLocalMailRecipient)
(mailLocalAddress=%0))
(wyszukujemy wpis należący do klasy inetLocalMailRecipient,
którego wartość atrybutu mailLocalAddress jest równa wartości
podanej w zapytaniu, zostaje zwrócona wartość atrybutu mailHost,
ale tylko gdy atrybut ten jest jednowartościowy)
ldap -1 -v mailRoutingAddress
-k (&(objectClass=inetLocalMailRecipient)
(mailLocalAddress=%0))
(wyszukujemy wpis należący do klasy inetLocalMailRecipient,
którego wartość atrybutu mailLocalAddress jest równa wartości
podanej w zapytaniu, zostaje zwrócona wartość atrybutu
mailRoutingAddress,
ale tylko gdy atrybut ten jest jednowartościowy)
define(`confLDAP_DEFAULT_SPEC', `-h ldap_server -p port_no -b base_dn')
Losy routingu intranetowego zależą od postaci danych w bazie LDAP. Oto możliwe warianty:
dn: uid=mgw, dc=uni, dc=torun, dc=pl objectClass: inetLocalMailRecipient mailLocalAddress: mgw@uni.torun.pl mailRoutingAddress: Maja.Wolniewicz@uci.uni.torun.plPoczta do mgw@uni.torun.pl będą kierowane pod adres Maja.Wolniewicz@uci.uni.torun.pl.
dn: uid=mgw, dc=uni, dc=torun, dc=pl objectClass: inetLocalMailRecipient mailLocalAddress: mgw@uni.torun.pl mailHost: smtp.uci.uni.torun.plPoczta do mgw@uni.torun.pl będą kierowane do serwera smtp.uci.uni.torun.pl.
dn: uid=mgw, dc=uni, dc=torun, dc=pl objectClass: inetLocalMailRecipient mailLocalAddress: mgw@uni.torun.pl mailHost: smtp.uci.uni.torun.pl mailRoutingAddress: Maja.Wolniewicz@uci.uni.torun.plPoczta do mgw@uni.torun.pl będą przekazywane zgodnie z rekordem MX dla smtp.uci.uni.torun.pl i będzie używany nowy adres docelowy: Maja.Wolniewicz@uci.uni.torun.pl.
dn: dc=uci, dc=uni, dc=torun, dc=pl objectClass: inetLocalMailRecipient mailLocalAddress: @uci.uni.torun.pl mailHost: smtp.uni.torun.plPoczta kierowana do wszystkich użytkowników w domenie uci.uni.torun.pl, czyli poczta pod adres @uci.uni.torun.pl będzie przekazywany do serwerasmtp.uci.uni.torun.pl. Aby serwer qmail wspólpracował z LDAP-em konieczne jest zastosowanie uzupełnień do pakietu (instalacja dodatkowego patche'a). W wyniku modyfikacji drzewa pakietu zostaną m.in. dodane w pliku Makefile ustawienia związane z korzystaniem z pakietów LDAP oraz SSL. Jeśli jest to potrzebne, należy je zmienić, by odzwierciedlały właściwą lokalizację bibliotek i plików nagłówkowych w systemie. Istotna jest opcja LDAPFLAGS=-DQLDAP_CLUSTER, jej włączenie jest niezbędne, gdy zamierzamy korzystać z klastrowania. Ważne są również definicje zawarte w pliku qmail-ldap.h. M.in. ustawia się w nim stałe:
Qmail-LDAP korzysta z własnego schematu, który rozszerza sposób opisu użytkownika w bazie LDAP. Może zostać tak skonfigurowany, że wszystkie serwery pocztowe w jednostce organizacyjnej mogą korzystać z tych samych danych dotyczących użytkownika. Umożliwia również stosowanie routingu komunikatów zgodnie z nazwą serwera pocztowego podaną w opisie użytkownika w LDAP-ie, w przypadku gdy użytkownik na zewnątrz posługuje się adresem ogólnym np. o postaci @uni.torun.pl.
qmail.schema definiuje jedną nową klasę obiektów - qmailUser. Klasa ta wymaga określenia wartości dwóch atrybutów: mail oraz uid (oba te atrybuty są zdefiniowane w podstawowym schemacie, core.schema). Obiekt tej klasy opcjonalnie może używać atrybutów:
dn: cn=Jan Kowalski, o=UMK, c=PL
cn: Jan Kowalski
sn: Kowalski
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: qmailUser
mail: jankowal@uni.torun.pl
mailHost: smtp.uni.torun.pl
mailMessageStore: /usr/home/jankowal/Maildir/
mailQuota: 1000000S,100C
qmailUID: 1001
qmailGID: 1001
uid: jankowal
userPassword: {MD5}b28a87511da157f147ed4766b0474a8a
Wśród wielu programów rozwijanych w ramach projektu Cyrus,
http://asg.web.cmu.edu/cyrus/
jest równie serwer IMAP/POP. Zgodnie z analizą w punkcie 1,
w przypadku serwerów POP/IMAP może nie być potrzebna żadna dodatkowa
konfiguracja w celu korzystania z bazy LDAP. Wystarczy, że w systemie są
stosowane PAM-owskie reguły uwierzytelniania. Pakiet
IMAP Cyrusa
korzysta z oprogramowania
SASL tego
projektu. Jeśli SASL korzysta z PAM-a lub z dodatkowego demona
pwcheck pośredniczącego w obsłudze zapytań o dane dotyczące
użytkownika systemu (w tej sytuacji praca demona opiera się na usługach NSS i PAM), to takie rozwiązanie jest wystarczające, by mogło
być realizowane uwierzytelnienie użytkowników zdefiniownaych w bazie
LDAP.
d. IMAP University of Washington
Pakiet UW-IMAP jest udostępniany przez projekt prowadzony w University of Washington. Podobnie jak rozwiązanie Cyrus, serwer ten nie wymaga żadnej dodatkowej konfiguracji, wystarczy odpowiednio skompilować oprogramowanie: w Linuxie należy wskazać zamiar korzystania z PAM-a w wywołaniu programu make: