In this post I will explain how to setup Postfix authentication against an AD server. This is similar to regular LDAP authentication, I am running a Samba 4.0 domain, but it should work just as well against a “real” Microsoft AD Domain.
MECHANISMS="ldap" OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" NAME=Mailserver
This code sets the SASL auth daemon (saslauthd) up to use LDAP authentication (for which the configuration is read from /etc/saslauthd.conf as detailed below), and puts the saslauthd communication socket inside the Postfix chroot so we can reach it from Postfix.
/etc/saslauthd.conf (complete file):
ldap_servers: ldap://domaincontroller.example.com/ ldap_search_base: cn=Users,dc=domain,dc=example,dc=com ldap_filter: (userPrincipalNameemail@example.com) ldap_bind_dn: cn=lookupuser,cn=Users,dc=domain,dc=example,dc=com ldap_password: omnomnom
This file configures the actual LDAP connection. You need a working user/password combination for the domain to be able to connect to the domain controller and browse the tree. We’re filtering on userPrincipalName; in this example @domain.example.com is added behind the username, as the principalName in AD is actually yourusername@yourwindowsdomain. I prefer to authenticate to Postfix without adding the Windows domain to the username, so we have to hardcode it in the LDAP query filter. You can add multiple servers after ldap_servers, which will be tried in order.
After configuring both saslauthd files, (re)start the saslauthd service.
You can then test if the SASL authentication works already with the testsaslauthd command. Careful, you have to pass it the password on the command line in plain text – be sure to use a test password or clear your terminal and shell history! If this doesn’t work, there’s no reason to continue to Postfix yet, as working SASL authentication is key!
smtpd_tls_cert_file=/etc/ssl/certs/mycert.crt smtpd_tls_key_file=/etc/ssl/private/mycert.key smtpd_tls_CAfile = /etc/ssl/certs/myintermediate.crt smtpd_use_tls=yes smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Use your commercial or selfsigned certificate and key combination for the first 3 lines. I have a wildcard certificate that I use for most of my servers, which matches the hostname used to identify this relaying Postfix server.
submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject
These 2 blocks are already in master.cf on Debian, but they’re commented out. The first block enables submission on port 587 via STARTTLS (fully encrypted after initial greeting dialogue). The second enables secure smtp on port 465, which is fully SSL encrypted.
/etc/postfix/sasl/smtpd.conf (complete file):
pwcheck_method: saslauthd mech_list: plain login
Finally, we set Postfix up to use saslauthd as authentication mechanism. We can only support plain, because we don’t have the plaintext password stored in Active Directory. This means we have to get it from the client and hash it (or well, verify by logging in) at our side to make sure it’s correct.
Finally, add Postfix to the “sasl” group, to be able to access the saslauthd communication socket.
# useradd -G sasl postfix
Restart Postfix, and sending mail through it should work, authenticated against Active Directory! Be sure to test with a wrong password, so that you don’t accidentally create an open relay somehow. With running a mail server on the internet comes great responsability, so make sure not to contribute to the spam problem – SMTP relay accounts get stolen on a regular basis as well so monitor your queues for unusually high amounts of outgoing mail.
Feel free to leave comments, questions or suggestions below!