LDAP: Konfigurace programu Dovecot

11. 12. 2009 | Lukáš Jelínek | Sítě | 28256×

Konfigurace programu Dovecot

U programu Dovecot to bude o něco složitější. Kromě informací o schránkách se totiž bude pracovat i s hesly. Celý problém ověřování hesel lze řešit dvojí cestou. Buď se uživatel přímo ověří pomocí autentizace LDAP, anebo se heslo získá jako kterákoli jiná informace a pak se použije běžným způsobem (viz minulé díly). První metoda je o něco bezpečnější (heslo se nedostane mimo LDAP), je však pomalejší a omezuje škálu autentizačních mechanismů (jde o stejný problém jako třeba při autentizaci přes PAM). Následující odstavce budou založeny na metodě druhé, tedy založené na stejném principu, jako při využití MySQL v minulém dílu seriálu.

Heslo se v rámci LDAP objektu inetOrgPerson ukládá do atributu userPassword. Do tohoto atributu se uloží jak samotné heslo, tak i použité schéma a případně také „sůl“ (tedy dodatečná informace použitá pro zašifrování hesla). Protože v tomto případě bude – v zájmu použití co nejširší škály autentizačních mechanismů – heslo uloženo vždy v otevřeném tvaru (plain), sůl se samozřejmě nepoužije a ani nebude uvedeno schéma.

Protože se heslo bude v otevřeném tvaru také přenášet z LDAP serveru na poštovní server (pokud nejde o totožný stroj), je důležité data chránit proti případnému odposlechu. Lze tedy buď využít přímo TLS nebo SSL, anebo posílat data tunelem. Toto pravidlo samozřejmě platí obecně při posílání citlivých dat, nejen pro tento případ.

Konfigurace bude nápadně připomínat tu, která byla využita pro řešení s MySQL. Přestože UID a GID lze uvést v konfiguraci pro LDAP (podobně, jako tomu bylo v minulých dvou článcích, tedy u souborového řešení a MySQL), jde o neměnné hodnoty a mohou být tedy nadefinovány globálně – netýká se to samozřejmě jen konfigurace pro LDAP, lze to použít i v jiných případech. Nastavení patří na nejvyšší úroveň konfigurace, tedy například za last_valid_gid.

mail_uid = 100
mail_gid = 100

V sekci auth default se změní jen toto (sekce passdb a userdb budou nahrazeny uvedeným fragmentem):

  passdb ldap {
    args = /etc/dovecot/ldap.conf
  }
userdb ldap {
    args = /etc/dovecot/ldap.conf
  }

Vlastní konfigurace bude pak obsažena v souboru ldap.conf. Tady je příklad takového souboru (pozor na přístupová práva – heslo pro LDAP je citlivou informací!):

hosts = ldap.moje.domena
tls = yes

dn = uid=dovecot,ou=users
dnpass = nejakeheslo

scope = onelevel
base = dc=moje,dc=domena

user_attrs = =home=/var/mail/virtual/%d/%n
user_filter = (&(preferredDeliveryMethod=physical)(uid=%n))

default_pass_scheme = PLAIN
pass_attrs = uid=user=%$@moje.domena, userPassword=password
pass_filter = (&(preferredDeliveryMethod=physical)(uid=%n))

Vypadá to trochu divoce, možná složitěji než u Postfixu, ale je to v podstatě jednoduché. V parametru hosts je seznam LDAP serverů (zde jeden), případně i s čísly portů. Místo něj lze použít parametr uris, kdy se místo obyčejných adres používají plné URI, tedy i včetně schématu. Jednotlivé servery se vždy oddělují mezerou. Parametr tls zapíná TLS komunikaci (server ji samozřejmě musí podporovat; lze použít také SSL přes URI začínající ldaps://, opět je třeba podpora serveru anebo použití něčeho jako stunnel).

Parametry dn a dnpass slouží k autentizaci LDAP klienta, protože jde o přístup k citlivým informacím (heslům). Uvedený příklad předpokládá, že jde o uživatele uid=dovecot,ou=users, čili že uživatelé jsou uvedeni pod objektem třídy organizationalUnit s RDN users. Konkrétní nastavení záleží samozřejmě na tom, jak vypadá struktura konkrétního stromu – klidně by mohlo jít i o uživatele pod dc=moje,dc=domena, kde jsou umístěny uživatelé pro schránky, nic tomu nebrání.

Pro vyšší výkon by bylo možné udělat dvě věci – buď oddělit dotazování na uživatele do samostatného souboru (kde by se nemuselo používat šifrování ani autentizace), anebo pro dotazování na uživatele použít přímo dotaz pro hesla, případně statickou definici se šablonou (protože existence uživatele se ověří dotazem na heslo). Tím se ovšem částečně „pohřbí“ flexibilita a pro využití například doručovacího agenta nebo některých pluginů by se tato forma musela opustit. Informace o těchto „zlepšovácích“ se souhrnně objeví v některém z pozdějších dílů seriálu.

Parametr scope říká, kde všude se budou objekty hledat. Zde je to onelevel, tedy jediná úroveň stromu. base má stejný význam jako search_base u Postfixu, tedy bázová cesta k prohledávání.

Následující parametry už souvisejí přímo s dotazy. user_attrs mapuje (pro dotazování na uživatelské schránky) atributy LDAP na atributy programu Dovecot, ovšem v tomto případě se ve skutečnosti nic nemapuje. Dotaz je pouze testem na existenci uživatele, nejsou potřeba žádné hodnoty z databáze. Proto se hodnota sestavuje napevno, což říká onen tvar „=proměnná“, protože obecné mapování má podobu proměnnáLDAP=proměnnáDovecot. Zde je to ovšem jinak, proměnná LDAP chybí, zato ale následuje definice hodnoty pomocí šablony, podobně jako třeba u mail_location v hlavní konfiguraci.

Teď je na místě udělat drobnou vsuvku, která se měla objevit již v předminulém dílu seriálu. V tomto příkladě, stejně jako ve všech dosud uváděných (s virtuálními uživateli), se úložiště pošty a domovský adresář shodovaly. Bylo to pro jednoduchost, aby nevznikala další adresářová úroveň nebo jiné složité řešení, a tady to nijak nevadí. Ovšem pokud se budou využívat některé pluginy, které si do domovského adresáře ukládají informace (to bude například Sieve při využití doručovacího agenta; ale nerad bych teď předbíhal), je lepší toto oddělit a udělat například v „domovském adresáři“ virtuálního uživatele ještě podadresář pro poštu, aby v souborech a adresářích nevznikal zmatek.

Parametr user_filter slouží k vyhledávání (filtrování) záznamů. Je to prakticky stejné jako u Postfixu. Úplně stejnou podobu má také parametr pass_filter. Zajímavější je však pass_attrs, a to ve své první části (druhá je prosté mapování atributů). Formát uid=user=%$@moje.domena říká, že se atribut uid (identifikace uživatele v LDAP objektu inetOrgPerson) namapuje do Dovecot atributu user tak, že jeho hodnota nahradí symbol %$. Je to potřeba, protože Dovecot zde pracuje s uživatelskými jmény v podobě celé e-mailové adresy, přitom v adresáři LDAP se hledají jen samotná jména. Pokud by se přiřazení provedlo přímo, Dovecot by získal nesprávnou informaci, chyběl by zavináč a doména.

Tím je Dovecot nakonfigurován a měl by fungovat standardním způsobem pro oba podporované protokoly. Samozřejmě se stejná autentizace využije i pro účely programu Postfix, tedy při odesílání pošty směrem ven z počítačů mimo mynetworks – ale to není nic nového, nijak se to neliší od chování v předchozích dílech.

       

Komentáře

[Robert Smol]

Dobry den,

predevsim, diky za skvely clanek. Jen bych se chtel zeptat, zdali bude take uvedena konfigurace dovecotu jako LDA ( treba se Sieve ci procmail pro presun SPAMU do adresare ci automaticke promazavani SPAM adresar)? Nebo jsem to nekde prehledl? Cetl jsem, ze Dovecot jako LDA muze mit vliv na vykonnost, nebot dovecot si udrzuje nejake indexy.

Pak taky, zda-li byste mohl dokoncit tu vsuvku o podadresarich kvuli pluginum. Co vsechno se zmeni (user_attrs?).

Dekuji

[Luk]

Jen bych se chtel zeptat, zdali bude take uvedena konfigurace dovecotu jako LDA ( treba se Sieve ci procmail pro presun SPAMU do adresare ci automaticke promazavani SPAM adresar)?

Samozřejmě bude.

Pak taky, zda-li byste mohl dokoncit tu vsuvku o podadresarich kvuli pluginum. Co vsechno se zmeni (user_attrs?).

Teď jen ve stručnosti. Jde o to, že pokud se například využívá Sieve a nad domovským adresářem pracuje ManageSieve (ať už jako součást Dovecotu nebo jako samostatný program, např. PySieved), budou se v klientovi zobrazovat i soubory, které nemají. A obráceně, Dovecot bude adresář vytvořený pro účely Sieve (kam se budou ukládat Sieve skripty) považovat za poštovní složku (pokud bude název začínat tečkou, jak je obvyklé), čili ji bude klientům nabízet společně s jinými složkami. To není stav, o který by člověk zrovna stál. Ale znovu říkám, ve všech příkladech dosud používaných v seriálu využití "domovského adresáře virtuálního uživatele" nijak nevadilo, proto jsem také nevytvářel další adresářovou úroveň.

Při použití se samozřejmě user_attrs nezmění, protože tam je právě domovský adresář, který zůstane stejný. Změní se naopak mail_location (například na maildir:/var/mail/virtual/%d/%n/Maildir, pokud bude pošta v adresáři Maildir pod domovským adresářem). U Postfixu by se změnil result_format (v tomto případě na %d/%u/Maildir/).

[Karel Benák]

Výborný článek!!! Je vidět, že autor opravdu ví, o čem píše. A možná by se mělo hodně zdůraznit, že LDAP je ve firmě takřka nutnost, protože to je standardizovaný zdroj informací a pokud jej administrátor nechce ve své síti zavést, nemá tam co dělat. LDAP je možné nakrmit jakkoliv, ale co je hlavní, on poskytuje standardizovaná data po standardizovaném protokolu. Proč si myslíte, že MS slaví velké úspěchy se svým Active Directory a Exchange serverem? Ano, maji skvělý marketing, ale hlavně pochopili význam X.509 protokolu a jeho odvarů. Kéž bych měl více času na experimenty, od té doby co jsem o LDAPu psal diplomku uteklo spousty vody a já toho hoooodně moc zapomněl. Dneska bych ji asi napsal jinak, ale rozhodně by obsahovala to, co napsal autor, někde jsem to měl dokonce rozepsané jako článek, ale bohužel jsem to nedokončil.

[ch-in-A]

jeste pred MS k tomuhle dosel podle me novell, u ktero se MS nebojim se rict hodne inspiroval :)

[Karel Benák]

Hodně? Novell udělal funkční implementaci X.509, AD je kočkopes LDAP protokolu a kdoví čeho ještě. Ale je funkční a hodně rozšířený.

[unix-programer]

...LDAP je ve firmě takřka nutnost, protože to je standardizovaný zdroj informací a pokud jej administrátor nechce ve své síti zavést, nemá tam co dělat. ..

administruji v make firme (5 lidi) pocitacovou infrastrukturu. O LDAP se zatim jeste neuvazuje. Myslite, ze bych mel me misto prenechat nejakemu schopnejsimu adminovi? Jaka nebezpeci hrozi firme, kdyz z ciste egoistickych duvodu budu delat jako ze nic a o LDAP se nezminim?

[Luk]

Při 5 lidech je to kanón na vrabce. Ale při 50 uživatelích už je LDAP užitečný.

[Heron]

Tyhle kategorické soudy (kdo nezná LDAP není admin) jsou k ničemu. Ber to prostě tak, že Karel si na tom udělal diplomku a používá to. A neumí si představit síť bez LDAPu. Takových technologií je.

Já třeba do LDAPu umím zadávat (změněné kopie již existujících záznamů ), umím z něj číst, ale vůbec nechápu princip jeho činnosti (nenašel jsem ani návod pro blbé, takže soudím, že to bude triviální a někdy prostě nastane ahááááá efekt) ani jej neumím nainstalovat. Přesto jsem mnoho let spokojeným adminem.

[Luk]

vůbec nechápu princip jeho činnosti

Co na tom nechápeš? Základní princip je naprosto triviální. Je to prostě strom objektů a každý objekt může mít atributy (jaké přesně a které jsou povinné atd., to záleží na schématu). Ten strom může vycházet třeba z hierarchie DNS nebo být úplně jiný, podle potřeby. Představ si to třeba jako XML strom nebo něco takového (třeba registry ve Windows ), je to jedno. Jak si to server vnitřně reprezentuje (třeba klidně jako nějaký XML soubor, databázi nebo jako objekty v C++, které se pak binárně zapisují na disk), to už je čistě implementační záležitost.

K jednotlivým objektům a atributům lze pak nastavovat práva.

ani jej neumím nainstalovat

Instalace je taktéž triviální. Netriviální může být u některých implementací počáteční konfigurace (např. u OpenLDAP). Ale jsou implementace, kde je to také jednoduché (třeba Apache Directory Server; pro něj existuje také klikátko Apache Directory Studio, kterým lze jak pracovat se stromem, tak i konfigurovat server).

[Heron]

ad 1) Tak toto je mi zrovna jasné. Pokud je to ovšem celé, tak pak nechápu smysl samotného LDAPu , resp. napadají mě technologie, které zvládnou totéž co si myslím, že má být LDAP (nasazení LDAPu tak jak jej máme u nás by šlo snadno přepsat do SQL).

ad 2) Zde to bude zřejmě tím OpenLDAPem.

Není to technologie, kterou bych musel znát (nemám to kde využít), takže to nechám v klidu jiným. Pokud o tom někdo napíše srozumitelný článek včetně příkladů nasazení (od nejjednodušších, řekněme pro ověřování uživatelů na jedné mašině (místo /etc/passwd)), rád si jej přečtu. A jistě nebudu sám.

[Luk]

Pokud je to ovšem celé, tak pak nechápu smysl samotného LDAPu , resp. napadají mě technologie, které zvládnou totéž co si myslím, že má být LDAP (nasazení LDAPu tak jak jej máme u nás by šlo snadno přepsat do SQL).

LDAP je především komunikační protokol. O to jde v první řadě. A protože tento protokol má poměrně širokou podporu, lze ho využívat v mnoha programech. Lze měnit klientský i serverový software podle potřeby, aniž by se musel měnit zbytek celku.

[otula]

Pokud o tom někdo napíše srozumitelný článek včetně příkladů nasazení (od nejjednodušších, řekněme pro ověřování uživatelů na jedné mašině (místo /etc/passwd)), rád si jej přečtu. A jistě nebudu sám.

Jo, k tomu článku pro blbé se také přidávám S (open)LDAP jsem se dostal do fáze, kdy běží (jakože se jen samoúčelně spustí bez použitelných dat), ale nejsem tam schopen nic rozumného nasáčkovat tak, abych to mohl jakkoliv použít. Většina návodů se spoléhá na nějaké skripty, které udělají většinu práce (ale tyto skripty v Archu nejsou). Chtěl jsem začít zdrojem adres pro mailové klienty, ale nějak jsem se neprokousal k výsledku.

Pro Lukáše: kdyby se ti chtělo napsat knihu o LDAP, určitě bys měl jistého minimálně jednoho kupce

[Karel Benák]

Pro první pokusy o nasáčkování doporučuju Apache Directory klienta. Problém je s návrhem stromu tak, aby dával smysl. A hlavním problémem je oproštění se od klasického přemýšlení ve stylu SQL. Chceš proniknout do LDAPu? Začni myslet ve stromové struktuře, nikoliv v tabulkách. Chceš proniknout do LDAPu? Začni studovat i ostatní protokoly

Pro Luka - pokud budeš psát knihu, dobře si to rozmysli, moc čtenářů mít nebude. LDAP je hodně komplexní a vyžaduje dost znalostí souvisejících věcí. O Tebe starost nemám, evidentně o tom hodně víš. Problém je se čtenáři, protože je to může odradit. Příklady použití jsou docela komplexní, leckdy zasahují spíš do podnikové sféry a vyžadují dost času a experimentů.

[Luk]

Pro Luka - pokud budeš psát knihu, dobře si to rozmysli, moc čtenářů mít nebude.

Knihu psát nebudu - viz níže

[otula]

Ono by to chtělo i nějaký přehled, která schémata k čemu slouží a jak je zužitkovat. Možná jsem jen špatně hledal. Každopádně bych se potřeboval dostat přesně přes ten aháááá efekt, který vzpomněl Heron ;)

[Luk]

Pro Lukáše: kdyby se ti chtělo napsat knihu o LDAP, určitě bys měl jistého minimálně jednoho kupce

Zaprvé nejsem odborník na LDAP (proto píšu v článku, že "lépe se vyjádří znalec LDAP" - a to já bohužel nejsem), zadruhé teď dokončuji zapracování odborné korektury do knihy na úplně jiné téma, takže o psaní knih zase nějakou dobu nebudu chtít ani slyšet

[otula]

Zaprvé nejsem odborník na LDAP (proto píšu v článku, že "lépe se vyjádří znalec LDAP" - a to já bohužel nejsem), zadruhé teď dokončuji zapracování odborné korektury do knihy na úplně jiné téma, takže o psaní knih zase nějakou dobu nebudu chtít ani slyšet

To je škoda. Píšeš pěkně "čitelně" :)

[ch-in-A]

Pochopeni toho proc LDAP a ne SQL jednim z prvnich kroku pri seznamovani se s LDAP. Me osobne to trvalo peknych par desitek minut cteni o LDAP a lehkeho premysleni :))

Zde zminovana diplomka KB byla pro me jednim z klicovych dokumentu pro pochopeni o co vlastne jde. Dobra prace!

Dokud clovek vec nezna, tak nepozna situaci, ve ktere je prave ona nejlepsi volbou :)

[jezevec]

výborný článek,

jen by mě zajímala jedna věc. Čemu by tak hrozně vadilo to, kdybychom si vytvořili vlastní schema ?

To, že toto naše schema není registrované by v tomto případě nemuselo vůbec vadit. A při přechodu na jiný SW ? No to stejně budeme muset respektovat odlišnosto toho, či onoho SW tak jako tak...

přeji ještě hodně takových článků

[Luk]

Čemu by tak hrozně vadilo to, kdybychom si vytvořili vlastní schema ?

Nevadilo by. Tedy aspoň v tomto případě (u některých programů by vadilo, protože ty napevno počítají s objekty určitých tříd). Akorát že by se muselo vymýšlet a muselo by se nainstalovat. Pokud se použije hotové schéma, toto celé odpadá.

[ch-in-A]

vytvareni schemat neni tak snadne. je treba dodrzovat standardy, brat ohled na zavislosti/konflikty (jedna se hierarchicke struktury), distribuovat to schema potom s aplikaci.

Osobne mam pocit, ze spousta schemat odrazi nejaky RFC, takze uprava takovychto schemat by mela toto respektovat - v opacnem pripade hrozi freestyle anarchie jako v sql based vecech....

Myslim, ze se to vyplati pouze v pripade navrhu nejake komplexni aplikace. Delat si schema protoze me chybi atribut velikostBot prinese vic starosti nez usitku

[Mike]

Něco zkouším

[Vskutečnosti Saýc]

To je rozhodne dobre.