Jeroen Scheerder
2014-Mar-05 10:33 UTC
[Dovecot] Using AD, one more try - "successfol auth" and crashing auth process
Hi, I have no success in using AD with dovecot. The little checkpassword script I cooked up that uses ldapsearch to lookup a user DN (with an authenticated bind) and then ldapsearch with an authenticated bind for that DN again works well. * Approach 1: use a service account to bind to AD, lookup the user DN, and bind to that DN. It fails. The LDAP config looks like: hosts = dc2.office.on2it.net ldap_version = 3 base = dc=office,dc=on2it,dc=net scope=subtree auth_bind = yes dn = CN=DovecotSvc,OU=Svcs,DC=office,DC=on2it,DC=net dnpass = suppressed pass_attrs = sAMAccountName=user pass_filter = (&(objectClass=person)(sAMAccountName=%u)) user_attrs = sAMAccountName=user user_filter = (&(objectClass=person)(sAMAccountName=%u)) What happens in this case is best shown in the packet capture as displayed by tshark: $ tshark -o tcp.check_checksum:FALSE -tr -r dc2.pcap 1 0.000000 172.17.50.13 -> 172.17.10.2 LDAP 197 bindRequest(7) "CN=DovecotSvc,OU=Svcs,DC=office,DC=on2it,DC=net" simple 2 0.001879 172.17.10.2 -> 172.17.50.13 LDAP 88 bindResponse(7) success Yay! The service account binds just fine. 3 0.001967 172.17.50.13 -> 172.17.10.2 LDAP 180 searchRequest(8) "dc=office,dc=on2it,dc=net" wholeSubtree 4 0.002772 172.17.10.2 -> 172.17.50.13 LDAP 502 searchResEntry(8) "CN=Jeroen Scheerder,OU=Users,DC=office,DC=on2it,DC=net" \ | searchResRef(8) | searchResRef(8) | searchResRef(8) | searchResDone(8) success 5 0.098367 172.17.50.13 -> 172.17.10.2 TCP 66 49416 > 389 [ACK] Seq=246 Ack=459 Win=1037 Len=0 TSval=602425599 TSecr=124473537 Yay! The user DN is found successfully. 6 225.149885 172.17.50.13 -> 172.17.10.2 LDAP 166 bindRequest(12) "CN=Jeroen Scheerder,OU=Users,DC=office,DC=on2it,DC=net" simple 7 225.152323 172.17.10.2 -> 172.17.50.13 LDAP 88 bindResponse(12) success 8 225.248387 172.17.50.13 -> 172.17.10.2 TCP 66 49416 > 389 [ACK] Seq=346 Ack=481 Win=1040 Len=0 TSval=602650749 TSecr=124496053 Yay! The user DN bind works. But wait, why is it taking dovecot 225 seconds to get around to trying it? The auth process has already given up. * Approach 2: A template defines the user DN. Bind to that DN. AD DNs don't contain usernames, but AD allows all kinds of non-LDAP shorthands for DNs, inclusing %user%@domain. I've verified this to work using ldapsearch: $ ldapsearch -o ldif-wrap=no -x -LLL -E pr=200/noprompt -H ldap://dc2.office.on2it.net \ -b dc=office,dc=on2it,dc=net -s sub \ -D js at office.on2it.net -W \ '(&(ObjectClass=person)(sAMAccountName=js))' DN Enter LDAP Password: dn: CN=Jeroen Scheerder,DC=office,DC=on2it,DC=net The config looks like: hosts = dc2.office.on2it.net ldap_version = 3 base = dc=office,dc=on2it,dc=net scope=subtree auth_bind = yes auth_bind_userdn = "%u at office.on2it.net" pass_attrs = sAMAccountName=user user_attrs = sAMAccountName=user What happens in this case is best shown by a snippet of dovecot logging: Mar 5 09:57:36 <mail.err> ponyboy dovecot: auth: Error: ldap(js,127.0.0.1,<z1dLNtjzJwB/AAAB>): ldap_search(base=dc=office,dc=on2it,dc=net filter=(&(objectClass=posixAccount)(uid=js))) failed: Operations error Mar 5 09:57:36 <mail.err> ponyboy dovecot: imap: Error: Disconnected from auth server, aborting (client-pid=7247 client-id=1) Mar 5 09:57:36 <mail.crit> ponyboy dovecot: auth: Fatal: master: service(auth): child 7245 killed with signal 11 (core not dumped - set service auth { drop_priv_before_exec=yes }) Mar 5 09:57:36 <mail.info> ponyboy dovecot: imap-login: Internal login failure (pid=7247 id=1) (internal failure, 1 successful auths): user=<js>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=7248, secured, session=<z1dLNtjzJwB/AAAB> I find this intriguing -- "1 successful auths", so says imap-login, with auth dying horribly. I smell a rat. Something's wrong here... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 881 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20140305/0a1a9a2d/attachment.sig>