Linux Mail Server Setup and Howto Guide

LDAP authentication is available in Dovecot starting version 1.0. Since Active Directory is an implementation of LDAP directory services, we can use the LDAP authentication to authenticate Dovecot against an Active Directory server. But for users of Dovecot prior to 1.0 or those having problems with LDAP authentication, we can instead use the Kerberos authentication mechanism in Windows via the Linux PAM.

Setup and Configure Kerberos

The steps below describes how to configure Kerberos using the GUI tool. You can apply the changes manually by editing the file /etc/krb5.conf.

The Kerberos network authentication protocol requires the clocks of the involved machines to be synchronized or at least the difference is less than 5 minutes.

1. Click System, select Administration and click Authentication. This will launch the Authentication Configuration window.

2. Click the Authentication tab and check the Enable Kerberos Support. Next, click the Configure Kerberos button.

3. In the Kerberos Settings window, fill in the Realm, clear out KDC and Admin Servers and check the Use DNS to locate KDCs for realms. Realm is usually your domain name capitalized, capitalization is important. KDC is your Active Directory server. Click Ok when you’re done.

To make sure that your KDC can be automatically located, type in the command host -t any _kerberos._tcp.acme.local in a terminal window. Replace acme.local with your own realm. If it replies “_kerberos._tcp.acme.local has SRV record …” then it works. This is how the Windows workstation is able to find the domain controller during domain logon. If it does not work, something is wrong with your DNS setting. You could either fix your DNS settings or manually fill in the KDC field above. You can specify more than one KDC by separating each server with a comma or space.

4. Uncheck the Enable Kerberos Support and click Ok. We don’t actually want to use Kerberos authentication in Linux, we just want the tool to setup Kerberos for us.

5. Test Kerberos by typing in kinit username in a terminal window. If you need help in making sense of the kinit error messages, check out Test the Kerberos Authentication.

Configuring Dovecot PAM

1. Edit the file /etc/pam.d/dovecot and replace the content with the lines below.

auth        sufficient   pam_krb5.so no_user_check validate
account     sufficient   pam_permit.so

2. Edit the file /etc/dovecot.conf and change the value of the following keys below

passdb pam {
}

userdb static {
  args = uid=501 gid=501 home=/home/vmail/%Lu
}

uid, gid and home should contain the user id, group id and home directory respectively of the vmail user account.

3. Restart the dovecot service. Learn how to start and stop services here.

4. You should now be able to login using the user names found in your Active Directory server. See Test Dovecot using Telnet and try using Active Directory user names instead of the system user names.

If you encounter any problems, check the log file at /var/log/maillog.

***
Posted on 4/12/2008 and last updated on 10/31/2008
Filed under Active Directory , CentOS 5 , Dovecot , Kerberos , Red Hat Enterprise Linux 5

Share This

 

8 Responses to “Active Directory and Dovecot PAM Authentication”

1. Francis Says:
   April 25th, 2008 at 3:36 pm

   Hi,

   I was able to do this and made my setup use PAM authentication for dovecot and postfix. Just some observations though, I was doing this step:

   host -t any _kerberos._tcp.acme.local

   And it told me that I had no SRV record. I completed the KDC and Admin server fields and I could kinit fine. I was also able to authenticate via AD. Are there any downsides if my server has no SRV record in the DNS Server?

2. consultant Says:
   April 25th, 2008 at 11:24 pm

   The only downside I see is that you have to configure and update it manually. Only the KDC field needs to be filled up. Admin server, a service for off-site users to be able to change their passwords, is not applicable in Active Directory.

3. consultant Says:
   April 26th, 2008 at 1:29 am

   BTW, I assume you’ve replace acme.local with your own realm.

4. Francis Says:
   April 26th, 2008 at 1:30 pm

   Hi,

   Thanks for the comments. It works now and I don’t wanna break it. Yup, I did replace acme.local with my own realm.

   Will note what you said about the Admin server. I will run additional tests on it in the next few days to see if I can remove it’s entry and still get my setup to work.

   Thanks again.

5. Paul Says:
   August 24th, 2008 at 2:56 pm

   The above setup worked fine. One issue I noticed as we went live is that users would sometimes login in all caps. Since AD usernames are case insensitive sending the authentication for USERNAME or username are both valid. The above setup causes a wrinkle. USERNAME logins would be valid, but would have none of their email / folders. And it would create /home/vmail/USERNAME directories. Obviously, home=/home/vmail/USERNAME is not the same as home=/home/vmail/username.

   A bit of research provided a simple solution.

   userdb static {
   args = uid=501 gid=501 home=/home/vmail/%Lu
   }

   Will still allow case insensitive logins, but will direct them to their lower case mail folder.

6. hamuod Says:
   October 27th, 2008 at 11:40 am

   Hi,
   i have followed your guide as it is .

   but when i do telnet i get error:

   -ERR authentication Failed

   and after some time it time out.

   Please advise?

   Thanks

7. consultant Says:
   October 31st, 2008 at 10:04 pm

   Hi Paul,

   Nice tip. I’ve updated the text to allow case insensitive logins, thanks.

8. consultant Says:
   October 31st, 2008 at 10:05 pm

   Hi hamuod,

   Please check /var/log/maillog to see the problem.

Leave a Reply