First, I don't see why you would want to let your users logon with any password. A user with a valid certificate could logon as any user, as long as you don't actually somehow check who is the certificates' owner.
And i don't think there's a big chance that EXTERNAL will be implemented in the next time (though this post is a bit outdated): http://archives.neohapsis.com/archives/postfix/2005-12/1323.html Also, there's no further information at Roadmap: http://wiki.dovecot.org/Roadmap
Maybe you could use "auth external" with couriers authlib, as it recently started to support AUTH EXTERNAL: http://sourceforge.net/project/shownotes.php?group_id=5404&release_id=296342 The problem is that I don't see how authlib would be able to access the the certificate.
-----Original Message----- From: dovecot-bounces+siebert+lists=et.rub.de@dovecot.org [mailto:dovecot-bounces+siebert+lists=et.rub.de@dovecot.org] On Behalf Of Zohan Sent: Tuesday, December 09, 2008 12:45 AM To: dovecot@dovecot.org Subject: [Dovecot] "nopassword" extra field useless with LDAP passdb
Hi,
We are trying to implement a highly secure mail server with user authentication restricted to SSL certificates only (not using passwords at all). Still, user information is stored in a LDAP directory. In this configuration LDAP is used to check whether the user is registered (and probably supply quota and other info), and actual authentication is done by SSL layer.
According to wiki, a "nopassword" extra field should be supplied, together with empty password. But there is no way to return an empty password from LDAP, as LDAP simply does not allow "empty attributes"; if an attribute is present, it is not empty. Supplying empty password as a static field (like this: pass_attrs = uid=user,=password=,nopassword) works an odd way, allowing empty password only, not "any password", and most MUAs (including our target Thunderbird) do not allow empty passwords.
Log excerpt follows ("1" was entered as a password during POP3 session; static empty password was configured as above):
Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): pass search: base=ou=People,dc=example,dc=com scope=subtree filter=(&(objectClass=inetOrgPerson)(uid=user1)) fields=uid,nopassword Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): result: uid(user)=user1 Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): Password mismatch Dec 9 02:11:15 localhost dovecot: auth(default): ldap(user1,127.0.0.1): PLAIN(1) != '' Dec 9 02:11:17 localhost dovecot: auth(default): client out: FAIL 1 user=user1 Dec 9 02:11:19 localhost dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<user1>, method=PLAIN, rip=127 .0.0.1, lip=127.0.0.1, secured
That's why we now have to maintain a separate passwd-like file with the following contents:
user1:::::::nopassword user2:::::::nopassword ...
and so on (updating it each time manually as users are added/removed), and use it as passdb. Only this allows true "any password" policy.
In fact, the problem seems to be a little bit deeper. In our setup user/password challenge is not needed at all. This is exactly what RFC 4959, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", is about (http://tools.ietf.org/html/rfc4959 , see SASL EXTERNAL example). Are there any plans to implement SASL EXTERNAL mechanism in Dovecot?
Thank you! Zohan