[Dovecot] ldap auth (with user and domain a different places)
Hi,
I am trying to use dovecot with my virtual-hosting setup. I have all users in LDAP like uid=user,dc=domain.tld,o=myorganization for the user with the mail-address user@domain.tld. This is also the username that user should use for login, but it is nowhere in the ldap-db in this form together, just user and domain at their own places. Is it possible to authenticate with dovecot against such an ldap-directory?
After reading docs and comments in the config-file, I think no, but I am not sure. As I read the source, it is not possible just now, but would be, if I could use %d in the searchbase.
Or did I understand something wrong?
TIA
Timo Boettcher
On Monday 10 January 2005 04:21, Timo Boettcher wrote:
I am trying to use dovecot with my virtual-hosting setup. I have all users in LDAP like uid=user,dc=domain.tld,o=myorganization for the user with the mail-address user@domain.tld. This is also the username that user should use for login, but it is nowhere in the ldap-db in this form together, just user and domain at their own places. Is it possible to authenticate with dovecot against such an ldap-directory? If you don't have multiple domains, you could just authenticate the user using %n. E.g., in dovecot-ldap.conf:
user_filter = (uid=%n) pass_filter = (uid=%n)
If you do have multiple domains, it's not that more complicated:
user_filter = (&(uid=%n)(dc=%d)) pass_filter = (&(uid=%n)(dc=%d))
:PeterHi Peter,
Thanks for your answer.
- Peter Clark peter-clark@bethel.edu, Monday, January 10, 2005, 5:06:55 AM:
On Monday 10 January 2005 04:21, Timo Boettcher wrote:
I am trying to use dovecot with my virtual-hosting setup. I have all users in LDAP like uid=user,dc=domain.tld,o=myorganization for the user with the mail-address user@domain.tld. This is also the username that user should use for login, but it is nowhere in the ldap-db in this form together, just user and domain at their own places. Is it possible to authenticate with dovecot against such an ldap-directory?
If you don't have multiple domains, you could just authenticate the user using %n. E.g., in dovecot-ldap.conf: I have multiple domains.
If you do have multiple domains, it's not that more complicated: It looks like
o=myorganization
- dc=somedomain.tld
- dc=someotherdomain.tld
| + uid=someuser
| + uid=someotheruser
| \uid=user
\dc=domain.tld
- uid=someuser
- uid=someotheruser \uid=user
The user uid=user,dc=domain.tld,o=myorganization would have the following attributes (and no more than that): objectclass=top objectclass=mailuser uid=user cn=Joe sn=User userpassword=theuserscryptedpassword clearpassword=acleartextpassword mailmessagestore=/var/mail/domain.tld/user
user_filter = (&(uid=%n)(dc=%d)) pass_filter = (&(uid=%n)(dc=%d)) But that would only work, if dc was an attribute of my user (which it is not), wouldn't it?
Timo
The user uid=user,dc=domain.tld,o=myorganization would have the following attributes (and no more than that): objectclass=top objectclass=mailuser uid=user cn=Joe sn=User userpassword=theuserscryptedpassword clearpassword=acleartextpassword mailmessagestore=/var/mail/domain.tld/user
user_filter = (&(uid=%n)(dc=%d)) pass_filter = (&(uid=%n)(dc=%d))
But that would only work, if dc was an attribute of my user (which it is not), wouldn't it? Yes, that would probably have to be the case. Theoretically, this kind of
On Monday 10 January 2005 11:10, Timo Boettcher wrote: problem could be solved by being more specific in your base dn (specifying "base = dc=domain.tld, o=myorganization" but I don't think that Dovecot allows things like %d in the "base" option of dovecot-ldap.conf, so you couldn't have "base = dc=%d, o=myorganization". (Someone correct me if I'm wrong.) However, it looks like you are using a custom schema. The easiest way would just be to edit the schema and add an attribute for the user's full email and be done with it. If the mountain will not come to Mohammed, Mohammed will go to the mountain. Or something like that. Or (just noticed this before I was about to send), you could search for the domain in the mailmessagestore attribute if you're really set on things as the way they are. In which case you might be able to do this:
user_filter = (&(uid=%n)(mailmessagestore=*%d*)) pass_filter = (&(uid=%n)(mailmessagestore=*%d*))
Note that I haven't tried it, so I don't know if Dovecot will handle having the %d between two wildcards. Try it and find out. :Peter
Hi Peter,
- Peter Clark peter-clark@bethel.edu, Monday, January 10, 2005, 12:34:04 PM:
On Monday 10 January 2005 11:10, Timo Boettcher wrote:
But that would only work, if dc was an attribute of my user (which it is not), wouldn't it? Yes, that would probably have to be the case. Theoretically, this kind of problem could be solved by being more specific in your base dn (specifying "base = dc=domain.tld, o=myorganization" but I don't think that Dovecot allows things like %d in the "base" option of dovecot-ldap.conf, so you couldn't have "base = dc=%d, o=myorganization". (Someone correct me if I'm wrong.)
As I read the sourcecode, thats not possible just now. But unless I am wrong (which I could quite possible be) the change to make this possible would be about one line to do variable expansion on the search-base.
However, it looks like you are using a custom schema. The easiest waywould just be to edit the schema and add an attribute for the user's full email and be done with it.
I omitted that attribute on purpose, because of the complications of redundant and possibly conflicting data. Now the schema of my ldap-db makes any conflicting data (like two users with the same mailaddress, a user with a mail-address of a domain other than his own) impossible without need for checking this in any administrative frontend. Thats the beauty of ldap in this case. If you have a better schema, please tell me.
If the mountain will not come to Mohammed, Mohammed will go to the mountain. Or something like that.
Hm. Why drop a schema that is perfectly valid and matches the spirit of ldap just because the ldap-software is not ldap-enabled enough to use it?
Timo
On Mon, 2005-01-10 at 18:28 +0100, Timo Boettcher wrote:
But that would only work, if dc was an attribute of my user (which it is not), wouldn't it? Yes, that would probably have to be the case. Theoretically, this kind of problem could be solved by being more specific in your base dn (specifying "base = dc=domain.tld, o=myorganization" but I don't think that Dovecot allows things like %d in the "base" option of dovecot-ldap.conf, so you couldn't have "base = dc=%d, o=myorganization". (Someone correct me if I'm wrong.)
As I read the sourcecode, thats not possible just now. But unless I am wrong (which I could quite possible be) the change to make this possible would be about one line to do variable expansion on the search-base.
I guess this would fall into same category with authentication binds. When they are supported, supporting %d in base is simple. I don't have plans to do auth binds anytime soon though. pam_ldap might help you.
Hi Timo,
* Timo Sirainen
On Mon, 2005-01-10 at 18:28 +0100, Timo Boettcher wrote:
As I read the sourcecode, thats not possible just now. But unless I am wrong (which I could quite possible be) the change to make this possible would be about one line to do variable expansion on the search-base.
I guess this would fall into same category with authentication binds. When they are supported, supporting %d in base is simple. I don't have plans to do auth binds anytime soon though. pam_ldap might help you.
I am not sure if it works the way I intended, but from the first look of it, the following patch [c|w|sh]ould do the trick. diff -ur dovecot-0.99.11/src/auth/userdb-ldap.c dovecot-0.99.11-patched/src/auth/userdb-ldap.c --- dovecot-0.99.11/src/auth/userdb-ldap.c 2003-11-08 16:31:22.000000000 +0100 +++ dovecot-0.99.11-patched/src/auth/userdb-ldap.c 2005-01-10 22:26:49.868212864 +0100 @@ -167,6 +167,10 @@ filter = str_c(str); } + str = t_str_new(512); + var_expand(str, conn->set.base, user, NULL); + conn->set.base = str_c(str); + request = i_new(struct userdb_ldap_request, 1); request->request.callback = handle_request; request->request.context = context Please correct me if I am wrong, if I delivered total **** or forgot something. Sorry for using the old version (but a patch of this size should port forward easily). Timo Boettcher
On Tue, 2005-01-11 at 00:54 +0100, Timo Boettcher wrote:
I guess this would fall into same category with authentication binds. When they are supported, supporting %d in base is simple. I don't have plans to do auth binds anytime soon though. pam_ldap might help you.
I am not sure if it works the way I intended, but from the first look of it, the following patch [c|w|sh]ould do the trick.
Oh. I remembered base was set while connecting to LDAP server, not for each request separately. Looks like that works, I'll implement it for 1.0-tests as well.
Although you did it only for userdb, you probably want it for passdb as well?
On Monday 10 January 2005 20:28, Timo Boettcher wrote:
If the mountain will not come to Mohammed, Mohammed will go to the mountain. Or something like that.
Hm. Why drop a schema that is perfectly valid and matches the spirit of ldap just because the ldap-software is not ldap-enabled enough to use it?
Why? Because it is wiser to pick your battles. :) In this case, it seems to me that you don't need to drop your schema, just modify it. But first of all, does using mailmessagestore work? If not, and if you don't want to add the full email address, then just add the domain name the user belongs to. That way you a.) can expend your energies on other battles and b.) not have to worry about conflicting data. :Peter
participants (3)
-
Peter Clark
-
Timo Boettcher
-
Timo Sirainen