[Dovecot] Please help: LDAP configuration _almost_ works.

Wed Apr 16 20:08:41 EEST 2008

Rob. actually it works... you made me check one thing again and i did 
have a mistake with the user specified in dn in dovecot-ldap.conf. it 
was not possible to search userdb information with it. so a small fix in 
slapd.conf and it is working.

now i am off to setting the ldap aliases for postfix. setting mailing 
lists with mailman, making ldap work with samba, etc...

i need to offer users simple way of changing the password and editing 
mail address aliases. i was thinking of writing a simple web interface. 
but maybe there are already programs for doing this?

all the best! Wojtek

Rob Coward wrote:
> On Wed, 2008-04-16 at 10:39 +0100, Wojtek Bogusz wrote:
>> dear Rob, thank you for support!
>> there are small differences in mine and yours config, like:
>>
>> - you do not have auth_bind_userdn defined. if i comment my out i cannot 
>> authenticate at all - log file:
>> auth(default): ldap(wojtek,192.168.0.200): unknown user
>> dovecot: auth(default): client out: FAIL^I1^Iuser=wojtek
> 
> Our initial connection is made using the "dn" and "dnpass" settings.
> This looks up the user's dn based on the "(&(objectClass=user)(mail=%
> u))" search criteria.
> 
> My understanding of the auth_bind_userdn setting is that it is only
> useful if all your users are in a specific tree in the ldap, so that you
> can specify (from
> http://wiki.dovecot.org/HowTo/DovecotOpenLdap?highlight=%
> 28auth_bind_userdn%29 ) auth_bind_userdn = uid=%
> u,ou=People,dc=_WIZZY_HOSTNAME_,ou=wizzy
> 
> This I believe saves the first lookup to find the dn of the user trying
> to login. Our users are spread throughout our tree, hence using the
> initial lookup as the 'dn'/'dnpass' user to find our user's dn.
> 
> If you remove auth_bind_userdn, do you have 'dn' & 'dnpass' setup with a
> suitable unprivileged user to allow the initial lookup of the logging-in
> user's dn ?
> 
>> - you have user_attrs = mail=user, me: user_attrs = 
>> homeDirectory=home,uidNumber=uid. but i do not think it make any difference.
>>
> 
> Our users login with their email address as the userid - hence
> "mail=user" telling dovecot that the userid is stored in the 'mail'
> attribute in the ldap results. We dont bother with 'home' or 'uid' as
> they are all virtual users, using a fixed uid set by "user_global_uid =
> dovecot" and "mail_location: maildir:/data/shared/mailstore/%d/%n"
> 
>> - i did not have deref = never. do you know what does it do? i do not 
>> understand man ldapsearch explanation :(
> 
> something to do with following links to other ldap servers I think. Dont
> think its strictly necessary in a single server setup.
> 
>> Rob, could you send me your ldap config (/etc/ldap/slapd.conf) please? 
>> maybe i am making some simple mistake with my ldap config...
> 
> As I said, we use Active Directory (running on Win2k3 servers I
> believe), not slapd.
> 
> Regards,
> Rob
> 
> 
>> Rob Coward wrote:
>>> I cant help you with what is going wrong for you, but we use dovecot
>>> very successfully with ldap lookups against Active Directory, using
>>> auth_bind=yes, and it does not require anonymous connections. The
>>> initial connection is by an un-privileged user that searches for the
>>> user, then a 2nd connection is used, authenticating against AD as the
>>> looked up user using the password supplied to dovecot.
>>>
>>> Our setup looks like this:
>>>
>>> # rpm -q dovecot
>>> dovecot-1.0-1.2.0.el5
>>>
>>> # dovecot -n
>>> # /etc/dovecot.conf
>>> protocols: imap pop3
>>> login_dir: /var/run/dovecot/login
>>> login_executable(default): /usr/libexec/dovecot/imap-login
>>> login_executable(imap): /usr/libexec/dovecot/imap-login
>>> login_executable(pop3): /usr/libexec/dovecot/pop3-login
>>> login_user: dovecotlogin
>>> login_process_size: 64
>>> login_processes_count: 10
>>> login_max_processes_count: 64
>>> first_valid_uid: 97
>>> default_mail_env: maildir:/data/shared/mailstore/%d/%n
>>> mail_location: maildir:/data/shared/mailstore/%d/%n
>>> mail_executable(default): /usr/libexec/dovecot/imap
>>> mail_executable(imap): /usr/libexec/dovecot/imap
>>> mail_executable(pop3): /usr/libexec/dovecot/pop3
>>> mail_plugin_dir(default): /usr/lib64/dovecot/imap
>>> mail_plugin_dir(imap): /usr/lib64/dovecot/imap
>>> mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3
>>> auth default:
>>>   passdb:
>>>     driver: ldap
>>>     args: /etc/dovecot-ldap.conf
>>>   passdb:
>>>     driver: ldap
>>>     args: /etc/dovecot-ldap-fr.conf
>>>   passdb:
>>>     driver: ldap
>>>     args: /etc/dovecot-ldap-se.conf
>>>   userdb:
>>>     driver: ldap
>>>     args: /etc/dovecot-ldap.conf
>>>   userdb:
>>>     driver: ldap
>>>     args: /etc/dovecot-ldap-fr.conf
>>>   userdb:
>>>     driver: ldap
>>>     args: /etc/dovecot-ldap-se.conf
>>>
>>> # cat /etc/dovecot-ldap.conf
>>> hosts = ad.our.net
>>> dn=CN=Lookup,CN=Users,DC=our,DC=net
>>> dnpass=XXXXXXXX
>>> auth_bind = yes
>>> ldap_version = 3
>>> base = OU=Stores,OU=UK,DC=our,DC=net
>>> deref = never
>>> scope = subtree
>>> user_attrs = mail=user
>>> user_filter = (&(objectClass=user)(mail=%u))
>>> pass_attrs = mail=user,userPassword=password,mail=userdb_user
>>> pass_filter = (&(objectClass=user)(mail=%u))
>>> user_global_uid = dovecot
>>> user_global_gid = dovecot
>>>
>>> We use multiple userdb / passdb definitions and ldap configs in order to
>>> limit the searches of our AD schema to specific sub-trees, both for
>>> performance and as there are other users elsewhere in our schema that we
>>> dont want dovecot to allow to connect.
>>>
>>> Hope this helps you.
>>> Rob
>>>
>>> On Wed, 2008-04-16 at 00:19 +0100, Wojtek Bogusz wrote:
>>>>>> /etc/ldap/sldap.conf:
>>>>>> access to attr=uid,homeDirectory,uidNumber
>>>>>>         by anonymous read
>>>>> 	I do not have this in my configuration, and dovecot does indeed use the
>>>>> credential I provide to successfully query LDAP for the user based on
>>>>> the (mail=%u) criteria.  However, it does not see the reply.
>>>>> 	The fact that it does perform the query successfully implies to me that
>>>>> it does not use an anonymous connection.  Very puzzling.
>>>> i have no idea what dovecot is doing :-) from the log file it looks like 
>>>> there are 2 queries to ldap: 1. to check provided password for provided 
>>>> user name, 2. to find a user related information (and from what Steffen 
>>>> wrote this one is done with anonymous user - correct?).
>>>>
>>>> [on the margin: why isn't it done in one query: get me the user related 
>>>> information, i am binding with provided user and with provided password. 
>>>> this way it would be one query for two things.]
>>>>
>>>> in my case, i cannot list user related information from ldap in 
>>>> anonymous connection even from command line, using: ldapsearch -x -b 
>>>> 'ou=Users,dc=frontline' '(&(objectClass=posixAccount)(uid=wojtek))' 
>>>> homeDirectory
>>>>
>>>> so i guess that i have to workout ldap settings for anonymous query. my 
>>>> /etc/ldap/slapd.conf related to access permissions is:
>>>>
>>>> access to dn.children="ou=Users,dc=frontline" 
>>>> attrs=uid,homeDirectory,uidNumber
>>>>         by anonymous read
>>>> access to attrs=userPassword,sambaNTPassword,sambaLMPassword
>>>>          by dn="cn=admin,dc=frontline" write
>>>>          by anonymous auth
>>>>          by self write
>>>>          by * none
>>>> access to dn.children="ou=Users,dc=frontline"
>>>>          by dn="cn=root,ou=Users,dc=frontline" read
>>>>          by anonymous auth
>>>>          by self write
>>>> access to dn.base="" by * read
>>>> access to *
>>>>          by dn="cn=admin,dc=frontline" write
>>>>          by * read
>>>>
>>>> maybe the problem is here... any hints please?
>>>>
>>>> regards, Wojtek
> 
> 
> Please consider the environment before printing this email. 
> 
> 
> GAME Stores Group Ltd has been awarded ‘Retailer of the Year’ at the 2006 and 2007 Golden Joystick Awards and 
> 'Thames Valley Business Award' for Outstanding Employer of Choice 2006.
> 
> This e-mail and any files transmitted with it are confidential and intended solely for the use of the 
> individual or entity to whom they are addressed. If you have received this e-mail in error please 
> notify the system manager at:  
>  
>         mailto:postmaster at game.co.uk
>  
> The recipient acknowledges that the transmissions made via the Internet can be corrupted and therefore 
> THE GAME GROUP PLC and any of its subsidiaries do not give any warranty as to the quality or accuracy of 
> any information contained in the message or assume any liability for it or for its transmission, reception or storage.  
> 
> This footnote also confirms that this e-mail message has been swept by anti-virus software for the presence of computer viruses.
>  
> http://www.game.co.uk
> http://www.gamegroup.plc.uk 
> 
> Registered Number: 1937170
> Registered Office: Unity House, Telford Road, Basingstoke, Hampshire. RG21 6YJ Registered in England and Wales.