[Dovecot] fastbind patch -> auth_bind_userdn patch (attached)
Let me know how you like this one.
This assumes one config parameter. The non-null of auth_bind_userdn overrides auth_bind = yes.
I'm using this patch now on cvs head.
Comments are always welcome. Thanks much,
Geff
On Mon, 2006-01-02 at 17:43 -0800, Geff wrote:
Let me know how you like this one.
This assumes one config parameter. The non-null of auth_bind_userdn overrides auth_bind = yes.
I'm using this patch now on cvs head.
Committed. I moved some of the common authbind code to a new function. See if I broke it :)
I was starting to have nightmares about maintaining my own branch. :)
thanks for including this. I just 'checked it out' (co - ba dump
bump..). It passes the "it compiles and retrieved my mail once test".
:-p
just a thought, looking at my logs, maybe the login should be with the DN? This might be beneficial if one is actually searching (auth_bind = yes).
Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=<boing>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
vs something like
Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=<cn=boing,ou=people,o=boing>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
Thanks again, great work on the imap (and pop) server.
Geff
Quoting Timo Sirainen <tss@iki.fi>:
On Mon, 2006-01-02 at 17:43 -0800, Geff wrote:
Let me know how you like this one.
This assumes one config parameter. The non-null of auth_bind_userdn overrides auth_bind = yes.
I'm using this patch now on cvs head.
Committed. I moved some of the common authbind code to a new function. See if I broke it :)
On Fri, 2006-01-06 at 17:53 -0800, Geff wrote:
just a thought, looking at my logs, maybe the login should be with the DN? This might be beneficial if one is actually searching (auth_bind = yes). .. Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=<cn=boing,ou=people,o=boing>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
If you make LDAP's userdb query return the DN as "user", and also make sure that you're not using %u in default_mail_env, you could have that.
I'm not sure if I'd want to make a separate "log-user" variable to confuse things..
Quoting Timo Sirainen <tss@iki.fi>:
Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=<cn=boing,ou=people,o=boing>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
If you make LDAP's userdb query return the DN as "user", and also make sure that you're not using %u in default_mail_env, you could have that.
I'm not sure if I'd want to make a separate "log-user" variable to confuse things..
From a security perspective audit logs or access control mechanisms have what's called SRA or subject resource action. So in the simple case of a website that's as follows:
subject: user, also called user princple. resource: host + url + query string action: get (post, etc)
Or in the case of mail:
subject: user resource: mail file action: read / login / search / select.
However it seems that we have two subjects. We have one for the passdb and one of the userdb. On my setup the passdb's subject is theoretically the ldap dn and the userdb's subject is the /etc/passwd getpwnam type unix account. So we really have two subjects that need to be logged in general unless they match of course. Yeah that can be messy, but perhaps worse not to know about both principles in the event of a security incident.
Just food for thought.
Geff
participants (2)
-
Geff
-
Timo Sirainen