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@game.co.ukThe 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.