Postfix, Dovecot költöztetése Samba 4 alá

Ubuntu Linux

Sziasztok!

Adott egy Postfix/Dovecot levelező rendszer, ami jelenleg az /etc/passwd-ből authentikál. Később bekerült egy Samba 4.0.5 szerver, ami megvalósítja az AD-t.
Elég kényelmetlen a jelenlegi megoldás, a usereket az AD-ba viszik fel, a mail címeket pedig a mail szerveren kell külön karbantartaniuk.
Az lenne a kérdésem, hogy mennyire macerás átkonfigolni a Postfix-et, Dovecot-ot, hogy AD-ból authentikáljon?
Mindkét szerver Ubuntu 12.04.

Köszönöm!

  • 23836 megtekintés

( SzBlackY | 2016. 03. 30., sze – 16:36 )

Egyáltalán nem az, a kérdés, hogy ugyanaz-e a user az AD-ban és a passwd-ben (az is megoldható, ha nem, de körülményesebb).

Az ArchWiki-n az OpenChange szócikknél (https://wiki.archlinux.org/index.php/OpenChange_server) vannak kész konfigok mindkettőhöz az AD sémával, aztán már csak a LDAP query-kkel kell játszanod.

Nagyjából: csinálsz egy usert valami jó hosszú, soha nem lejáró jelszóval az AD-ben. Beállítod a dovecot-ot, hogy onnan vegye a usereket (userdb), utána hogy onnan autholjon (authdb), utána beállítod a postfix-et, hogy milyen virtuális domainek vannak és honnan vegye a usereket...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Most épp ez alapján próbálom csinálni: http://wiki2.dovecot.org/HowTo/ActiveDirectoryNtlm

De pl. ez a rész nem teljesen világos:
Dovecot employs winbind internally, so we don’t need to specify any password database, but we do need user information, usually a static userdb for virtual users (AD users)

Tehát nem kell beállítani passdb-t? És a userdb-be kéne beállítani azt az AD user-t, akinek a nevében csinálná a lekérdezést?
Egyelőre ezt kapom a logban:

Apr 1 10:05:45 ldapteszt dovecot: pop3-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=15232, secured
Apr 1 10:05:45 ldapteszt dovecot: pop3(defo): Error: user defo: Couldn't drop privileges: User is missing UID (see mail_uid setting)
Apr 1 10:05:45 ldapteszt dovecot: pop3(defo): Error: Internal error occurred. Refer to server log for more information.

Ok, elég nagyvonalúan kezelik a dolgokat a leírások, csak az auth-system volt engedélyezve, most betettem az auth_ldap-ot, így már változott a helyzet. Csináltam egy ldapteszt usert a lekérdezésekre. De még így sem tetszik neki:

Error: LDAP: binding failed (dn cn=ldapteszt,dc=example,dc=com): Invalid credentials, Simple Bind Failed: NT_STATUS_LOGON_FAILURE

Alakulunk, már többször sikerült sikeresen bejelntkezni.
Egy valamit nem értek: néha a jelszó megadása után percek telnek el és nem történik semmi, aztán el is timeout-ol a kapcsolat, ez vajon mitől lehet?

Apr 1 12:13:49 ldapteszt dovecot: pop3-login: Error: master(pop3): Auth request timed out (received 0/12 bytes)

Első körben hagyd a GSSAPI-t (az inkább a Kerberos lesz, ami ha lehet, mégrosszabb, ott még legalább klienstől is függ, hogy minden működik-e, ráadásul ha debugolni akarod, az kész katasztrófa :) ) és menjen a sima plaintext.

Debian van előttem, ott a /etc/dovecot/conf.d/10-auth.conf [hogy bekapcsold a következőt], /etc/dovecot/conf.d/auth-ldap.conf.ext [egy userdb és egy passdb szekció, args-nak megadva az utolsó kettőt], /etc/dovecot/ldap-db/dovecot-ldap-passdb.conf [ez lesz a passdb-d] és egy /etc/dovecot/ldap-db/dovecot-ldap-userdb.conf [ez lesz a userdb-d] kell. (azt hiszem ez utóbbi kettőt össze is lehetne vonni, itt nem teljesen ugyanaz)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( nvik | 2016. 03. 30., sze – 22:03 )

OpenDirectory -s rendszer van nálunk (OSX Server és OSX kliensek).
Több (5+) éves tapasztalatom az, hogy a levelezést és a vpn -t és a wifi EAP-TTLS -t ÉRDEMES leválasztani az OD-ről (esetedben AD-ről).
Megmondom miért.
Ha a levelezést esetleg valamelyik user használja mondjuk nyaralás alatt netkávézóból vagy akárhonnan, ami felet tnincs kontrollod, lelophatják a jelszavát. És ha a Directory -ba be van kötve, akkor ezzel a jelszóval máris lehet jönni vpn -en is befele, meg a belső hálózatba is a felhasználó jogosultságával befele.
Az enterprise-wifi EAP-TTLS -t meg azért érdemes szintén különválasztani, mert nálunk pl. volt olyan renitens, hogy a fiának akart a wifi-hez hozzáférést adni, ezért megadta az OpenDirectory user/jelszó párost............
Mivel a DHCP kliensek monitorozva vannak, ezért hamart kiderült, hogy hogy a fenébe kerülhet ez az eszköz a hálózatra, és gyakorlatilag azonnal megtudtuk a turpisságot.
Szegény user nem akart rosszat, nem is "fogta át a tudata" hogy a wifire való bejelentkezéshez hazsnált user/jelszó páros ugyan az, maivel a gépére bejelentkezik, és amivel a fileszervert is eléri..........

Jobb az külön, hallgass rám. :)

( Swifty v | 2016. 04. 04., h – 13:30 )

Ha eddig /etc/passwd volt, akkor néz körül a PAM háza táján...
--
Debian Linux rulez... :D
RIP Ian Murdock

( pekob | 2016. 04. 07., cs – 13:46 )

Egy valamit nem értek egyelőre:
postmap -q -val le tudom kérdezni az ad-s userek tulajdonságait, ha nincs olyan user, nem ad vissza semmit.
Ennek ellenére, bármilyen usernek küldenék levelet, olyannak is, aki nem létezik az AD-ban, simán átadja a dovecot-nak, az pedig létrehozza neki a könyvtárat és beleteszi a levelet.
Ez hogy lehet, még nem értem...

Nem, ilyet nem tettem bele.
A baj az, hogy nagyjából százféle leírás kering a megvalósításról, nagyon könnyen el lehet keveredni.
Postfix-nek pl. elvileg elég a domain-ban lennie, máris tud fogadni levelet AD-s userek számára, mondjuk a csoportoknak egyelőre nem, pedig wbinfo-val őket is szépen látja.

Én windows 2008 ADDC-ből veszem a user/alias listát.
main.cf-be:
smtpd_sender_login_maps = proxy:ldap:/etc/postfix/ad_sender_login_maps.cf
virtual_mailbox_maps = proxy:ldap:/etc/postfix/ad_virtual_mailbox_maps.cf
virtual_alias_maps = proxy:ldap:/etc/postfix/ad_virtual_group_maps.cf

ad_sender_login_maps.cf :
# Directory settings
server_host = 399.399.399.399
server_port = 389
version = 3
bind = yes
start_tls = no
bind_dn = cn=postfix,ou=services,dc=teszt,dc=valami,dc=hu
bind_pw = x
search_base = cn=users,dc=teszt,dc=valami,dc=hu
scope = sub
# Filter
query_filter = (&(userPrincipalName=%s)(objectClass=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
result_attribute= userPrincipalName
debuglevel = 0

ad_virtual_group_maps.cf:
Ezzel létrehozott biztonsági vagy terjesztési csoport (ldap szerint mindegy) és az azon belüli csoportoknak is tudsz levelet küldeni.

server_host = 399.399.399.399
server_port = 389
version = 3
bind = yes
start_tls = no
bind_dn = cn=postfix,ou=services,dc=teszt,dc=valami,dc=hu
bind_pw = x
search_base = dc=teszt,dc=valami,dc=hu
scope = sub
query_filter = (|(&(objectClass=group)(mail=%s))(&(objectclass=person)(otherMailbox=%s)))
special_result_attribute = member
#leaf_result_attribute = otherMailbox
result_attribute= userPrincipalName
debuglevel = 0

ad_virtual_mailbox_maps.cf:
server_host = 399.399.399.399
server_port = 389
version = 3
bind = yes
start_tls = no
bind_dn = cn=postfix,ou=services,dc=teszt,dc=valami,dc=hu
bind_pw = x
search_base = cn=users,dc=teszt,dc=valami,dc=hu
scope = sub
# Filter
#query_filter = (&(objectclass=person)(userPrincipalName=%s))
query_filter = (&(mail=%s)(objectClass=user))
result_attribute= userPrincipalName
result_format = %u/Maildir/
debuglevel = 0

Összekalapáltam a postfix konfigot, jónak is tűnik, egyedül a csoport címekkel van gondom. Itt a belső domain: domain.in a külső domain.hu. Ha megcímzek egy tesztcsoportot, akkor mind a .in-es, mind a .hu-s címekre kézbesít. Az ldap lekérdezést kellene még megfiltereznem .hu-ra?

root@ldapteszt:/home/bekaspizza# postmap -q tesztcsopi@domain.hu ldap:/etc/postfix/ad_virtual_group_maps.cf
user1@domain.in,user1@domain.hu,user2@domain.in,user2@domain.hu

result_attribute= userPrincipalName
Ezt a sort kell változtatnod a megfelelő értékre. Töprengj egy kicsit. Ha megmondok mindent, akkor a működését nem fogod átlátni és bajban leszel legközelebb.
Csinálj egy lekérdezést (ldapsearch -t) és nézd meg mi a kívánt érték.

Lényegében az első, van pár domain, ami csak úgy van, a jó ég tudja minek, de be van állítva jelenleg a virtual-ban, hogyha egyszer az életben véletlenül jönne oda levél, akkor az hova menjen.
De megoldottam a Proxyaddresses attribútum lekérdezésével.
Tulajdonképpen kész is van, lassan jöhet az éles szerver átállítása :)

Rövid jótanács: a proxyAddresses jelentésének utánanéztél? Mármint hogy nem simán e-mail címek mennek bele hivatalból, hanem protokoll-specifikációval együtt, érdemes ezt követni:

pl.:
SMTP:foo@example.org (ő lesz az elsődleges smtp cím)
smtp:bar@example.org (nem elsődleges, további címek)
smtp:asdasd@example.org (mint előbb)
X400:c=US;a= a;p=Example Org;o=Admin Group;s=foo (x400 cím)
=EX:/o=Example Org/ou=Admin Group/s=foo (Exchange DN)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Van azért még megoldatlan probléma :)
Van csoportom, aminek tagja egy külső email cím is (mármint a jelenlegi pam-os verzióban). Azt a tanácsot kaptam, hogy csináljak a külsős címhez egy AD-S usert és állítsam be neki a külső email címet, majd ezt a usert adjam hozzá az AD-s csoporthoz.
Ez meg is történt, a postmap szépen vissza is adja:
postmap -q csoport@domain.hu ldap:/etc/postfix/ldap-group.cf
user1@domain.hu,user2@domain.hu,kulsos@kulsos.hu

De ha küldök a csoportnak levelet, a logba már ez kerül:
to= kulsos@domain.hu , orig_to= csoport@domain.hu

Ez vajon mitől lehet?

# Directory settings
server_host = 1.2.3.4
search_base = dc=domain,dc=hu
scope = sub
version = 3

# User Binding
bind = yes
bind_dn = Domain\user
bind_pw = password

# Filter
query_filter = (&(objectclass=group)(mail=%s))
special_result_attribute = member

és a postmap jól is adja vissza.

Itt mi a result_attribute / leaf_result_attribute? Alapból a Postfix a maildrop-ot nézi, de az az AD sémában AFAIK nincs. Egy teljes konfigot (main.cf és az összes map) tudsz dobni?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szia
Bocsánat a késői válaszért, de nem voltam internetközelbe.. teleltem/tavaszoltam/nyaraltam
A feltét teszi lehetővé az összevonást.
query_filter = (|(&(objectClass=group)(mail=%s))(&(objectclass=person)(otherMailbox=%s)))

De íhartod külön is őket ha jobban tetszik.
Ezt például a main.cf-ben felveheted virtual_alias_maps = ldap:/etc/postfix/ad_virtual_alias_maps.cf,ldap:/etc/postfix/ad_virtual_group_maps.cf.
alias:
query_filter = (&(objectClass=user)(otherMailbox=%s))
result_attribute = mail

A továbbítást megcsinálhatod sieve scriptel is akár.

http://ftp.uma.es/mirror/postfix/doc/LDAP_README.html

de ha nem akarsz akkor hozzáadsz egy bejegyzést az ldap shemához:
virtual_alias_maps = ldap:/etc/postfix/ad_virtual_alias_maps.cf,ldap:/etc/postfix/ad_virtual_group_maps.cf, ad_virtual_fw_maps.cf
fw.cf:
scope = sub
query_filter = (&(&(objectClass=user)(maildrop=%s))
result_attribute = mailforward

De ezt nem teszteltem, SzBlackY kolléga véleményét várd meg.

Az utókornak:
Létre kell hozni az AD schemában 2 attributot, pl maildeliverimode , bcc (multi value) mindkettőt unicode stringként vegyük fel.
Fontos, hogy minden felhasználónál legyen kitöltve a maildeliverymode mert különben nem fog működni, a működését remélem nem kell elmagyaráznom.

tesztelt:
main.cf
virtual_alias_maps = ldap:/etc/postfix/ad_virtual_group_maps.cf,ldap:/etc/postfix/ad_virtual_forwardonly.cf,ldap:/etc/postfix/ad_virtual_forward.cf

ad_virtual_group_maps.cf
query_filter = (&(objectClass=group)(mail=%s))
leaf_result_attribute = othermailbox
special_result_attribute = member

ad_virtual_forwardonly.cf
query_filter = (&(|(mail=%s)(otherMailbox=%s))(objectClass=person)(maildeliveryMode=forwardonly))
result_attribute = bcc

ad_virtual_forward.cf
query_filter = (&(|(mail=%s)(otherMailbox=%s))(objectClass=person)(maildeliveryMode=forward))
result_attribute = bcc,mail

postfix is ahol egyezést talál ott megáll és nem megy tovább, így a sorrend is fontos.

( arpi_esp v | 2016. 04. 07., cs – 18:40 )

alapvetoen eleg egy sima ldap auth hozza, ad-t lehet ldapon olvasni es ldap tdu autholni (jelszot ellenorizni) is. a macerasabb inkabb az hogy az userek home-jat vagy generalni kell (pl /home/mail/$U/) vagy ad-ben tarolni valahol.

igy az auth ad-bol megy, de kliens oldalon kulon kezelodik, tehat a mail programban kulon be kell irni a jelszot. ha single signont akarsz, akkor kerberos kell, na az mar nem kicsit macera. en ossze szenvedtem anno, postfix+cyrussaslauthd+radiusclient es kulon egy radius szerver samba4-el ad-be beleptetve). nem kicist bonyolult, es kellett hozza a windozon is generalni kulcsokat stb.

( istju | 2016. 04. 14., cs – 17:59 )

Egy dolognak azért örülök:-) A hírös Ubuntunak, lehet segít a hírhödt ArchWiki. Ennyit a népszerű, és a jó disztrókról:-)
Szívesebben olvastam volna első hozzászólásnak azt, hogy lásd" az ubuntu wiki eme részében " De vagy az ubi júzer inaktív, vagy a ubiwiki nem túl jó. Ezt mindenki maga döntse el:-)
Egy Arch User

Bocs, ha szabira megyek akkor az első szempontom az, hogy lehetőleg térerő csak hébe-hóba legyen internet sebesség meg vetekedjen a modemes korszakbélivel, így bármi problémát a kollégáimnak kell megoldani saját fejből és nem mindig rám hagyatkozni,
Elsősorban pihenni akarok és nem dolgozni/szakmai dolgokkal foglalkozni a szabim alatt.. szerencsére a vezetőség megérti ezt, és még sosem volt problémám ebből, se rendszerlerohadás...