Authenticating Dovecot pop3/imap users against Active Directory using ntlm (secure password authentication)

by Dimitrios Karapiperis

postmaster at thessaloniki.gr

Abstract / Rationale

Seeking ways for encrypted password transmission on imap/pop3 server, supported by widely used MUAs (eg. Mozilla Thunderbird, Microsoft Outlook)

Having an imap/pop3 server querying Active Directory (AD) to validate a pair of username and password can be achieved using the ldap-classic way or employing Microsoft ntlm authentication process.

Ldap authentication is simple and supported by the majority of imap servers, but should we need enhanced security, we must enable SSL/TLS, which includes obtaining a valid key from a known Certificate Authority (CA).

Ntlm, on the other hand, uses a challenge-response sequence, requiring the exchange of three messages between the client (dovecot imap server) and the server (AD) using MD4/MD5 hashing algorithms and DES encryption. Moreover, ntlm has a major advantage over the ldap way, the seamless, passwordless single sign-on, that can be offered on logged on users to the AD domain.

SSL/TLS encrypts the whole conversation between MUA and imap/pop3 server, whereas ntlm only the exchange of the credentials.

In our example the test environment is

CentOS 5
Dovecot 1.1.16
Samba 3.0.33
Kerberos 5 1.6.1

AD server is ad.domain.dom.

Step 1. joining the AD

The first thing to do is to set up the Kerberos keys. Kerberos is time-dependent, so we have to synchronize time with the AD server. Use ntpdate or much better, add a server statement in /etc/ntp.conf for the ntp daemon.

server ad.domain.dom

Remember that ntp works on udp/123, in case there is a firewall between the AD server and the linux box.

Kerberos in /etc/krb5.conf requires the following minimal configuration:

[libdefaults]
default_realm = DOMAIN.DOM

[realms]
DOMAIN.DOM = {
  kdc = ad.domain.dom
}

[domain_realms]
  .domain.dom = DOMAIN.DOM
  domain.dom = DOMAIN.DOM
 .kerberos.server = DOMAIN.DOM

Now it’s time to obtain the keys:

kinit Administrator

then supply the Administrator’s password and that’s it. This step requires tcp/88 open to the AD machine.

Samba configuration in /etc/samba/smb.conf:

[global]
  workgroup = DOMAIN
  realm = DOMAIN.DOM
  security = ADS
  local master = no
  domain master = no
  preferred master = no
  dns proxy = no
  idmap uid = 10000-20000
  idmap gid = 10000-20000
  password server = ad.domain.dom
  encrypt passwords = yes
  use kerberos keytab = true
  winbind use default domain = yes
  winbind offline logon = false
  winbind separator = +

The smb daemon is not needed at all. Ports tcp/135, tcp/139 and tcp-udp/389 should be reachable to the AD server.

net ads join –U Administrator

A successful message comes up:

Joined 'LINUX-MAIL' to realm 'DOMAIN.DOM'

In case of failure debug output is enabled with the option –d <debug-level> on the net command.

Step 2. Starting up the winbind daemon

service winbind start

We can test our configuration submitting wbinfo –u <AD_username>. This should return information regarding the AD user. A very important option in /etc/samba/smb.conf is winbind use default domain = yes, if we omit this statement, we have to provide the domain on every attempt to authenticate a user eg. wbinfo –i DOMAIN+user.

Step 3. Configuring Dovecot.

The configuration file /etc/dovecot.conf should include the following lines before the protocols statement:

# v1.1:
auth_ntlm_use_winbind = yes
# v1.2+:
auth_use_winbind = yes

auth_winbind_helper_path = /usr/bin/ntlm_auth
protocols = imap imaps pop3 pop3s

We should also complement the mechanisms statement with the ntlm method:

mechanisms = plain ntlm login

Dovecot employs winbind internally, so we don’t need to specify any password database, but we do need user information, usually a static userdb for virtual users (AD users):

userdb static {
   args= uid=501 gid=501 home=/home/vmail/%1Ln/%Ln
   mail=maildir:/home/vmail/%d/%1Ln/%Ln:INBOX=/home/vmail/%d/%1Ln/%Ln
   allow_all_users=yes
}

Stressed on Dovecot official web site:

Dovecot currently does blocking lookups, so if ntlm_auth is slow on responding (e.g. network
problems), Dovecot blocks all other authentication requests until it's finished.

http://wiki.dovecot.org/Authentication/Mechanisms/Winbind

Step 4. Testing

Click on the MUA, the Secure Password Authentication checkbox (Mozilla Thunderbind and definitely Microsoft Oulook support it).

Receive any e-mails by the MUA and then check imap/pop3 server’s log, usually in /var/log/maillog:

Aug 9 16:20:34 rsync dovecot: pop3-login: Login: user=<virtual>, method=NTLM, rip=10.65.15.247, lip=10.65.0.23
Aug 9 16:20:34 rsync dovecot: POP3(virtual): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0

Step 5. Passwordless authentication

If you have logged on from Windows to the AD domain, try leaving the password field, on the account, on the MUA, blank. The username / password, from the initial logon to the Windows machine, are seamlessly picked up and supplied to the challenge-response process between the MUA, Dovecot and AD. Employing this way of authentication we achieve single sign-on and we don't need to maintain MUA local passwords.

Useful links and further reading

Samba domain membership http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html

Dovecot.org http://www.dovecot.org

Dovecot winbind http://wiki.dovecot.org/Authentication/Mechanisms/Winbind

NTLM http://en.wikipedia.org/wiki/NTLM

NTLM vulnerability to MITM attack. http://wiki.dovecot.org/Authentication/Mechanisms/NTLM