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
