This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.

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

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_realm]
  .domain.dom = DOMAIN.DOM
  domain.dom = DOMAIN.DOM
 .kerberos.server = DOMAIN.DOM

Make sure the domain name is in caps or you might get a 'KDC reply did not match expectations' error while trying to obtain the keys in the next step.

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 –i <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:

auth_ntlm_use_winbind = yes
auth_use_winbind = yes
auth_winbind_helper_path = /usr/bin/ntlm_auth

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

mechanisms = plain ntlm gss-spnego 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 {
   driver=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
}

https://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.

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

Dovecot.org https://www.dovecot.org

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

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

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

HowTo/ActiveDirectoryNtlm (last edited 2017-05-31 09:45:42 by mail)