How to get Sendmail to authenticate with Active Directory

mfoley · 12-04-2017, 12:20 AM

This is another perennial quest I've been on for years ...

How can I get Sendmail to authenticate remote users using Active Directory? When trying, I get the usual "did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA" error. I do have:

Code:

TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl 
define(`confAUTH_OPTIONS', `A')dnl

I've also tried AUTH_OPTIONS 'A c y'

I do not have:

Code:

FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl

Please respond if you actually know how to do this.

Slackware 14.2 (no pam)

Elizine · 12-05-2017, 05:44 AM

Have you tried restarting sendmail?

Do you see this for all users, local and remote? How do you authenticate remote users for sending mail?

Is there an option to turn up the verbosity in the sendmail logs?

What do you see if you telnet to sendmail and manually try to send a message?

Migrating to another MTA (eg Postfix) may work around your problem but it's not a quick fix. You'd have to configure Postfix in the same way your sendmail setup is currently configured. It's better to try to understand and fix the issue at hand.

mfoley · 12-07-2017, 12:35 PM

Quote:

Originally Posted by Elizine

Have you tried restarting sendmail?

Yes.

Quote:

Do you see this for all users, local and remote? How do you authenticate remote users for sending mail?

LAN/Domain users use Dovecot with GSSAPI authentication for incoming IMAP mail to their workstations. This authenticates with their Domain Credentials. SMTP authentication is to port 587 (forwarded to port 25) which is Sendmail; no authentication required.

Remote users are in this case users with smart phones. Their incoming IMAP server is to port 993 (forwarded to 143) and TLS. This port is listened by Dovecot, the IMAP server. This DOES NOT authenticate with domain credentials but does authenticate with /etc/shadow. Therefore, domain users who have cell phones must be in both sam.ldb and /etc/passwd. The outgoing SMTP goes to port 587 (forwarded to 25) and TLS which is listened by Sendmail. Sign-in is required. Again, I believe sendmail is verifying cell-phone sent credentials against /etc/shadow.

I would very much like to get domain users out of /etc/passwd as that is not considered kosher by Samba AD/DC experts. I do have a mechanism for Dovecot to authenticate with AD credentials and NOT NEED /etc/shadow. However, if the user is not in /etc/passwd, the Sendmail port 25 authentication fails if "Sign-in required" is required. If I do not require sign-in, the cell-phone user can connect with Sendmail, but cannot actually send email from the cell-phone because relaying is denied.

I think my problem has to do with saslauthd and AUTH mechanisms. In my .mc file I have:

Code:

TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_OPTIONS', `A c y')dnl

In /etc/sasl2/Sendmail.conf I have:

Code:

pwcheck_method: saslauthd
mech_list: EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN

And, if I telnet to the mail server I get:

Code:

250-AUTH LOGIN PLAIN

So, the only AUTH mechanisms available are LOGIN and PLAIN. I don't really know why DIGEST-MD5 and CRAM-MD5 don't show up in 250-AUTH because they are in both Sendmail.conf and sendmail.mc. I believe that LOGIN and/or PLAIN are mechanism that Sendmail will use to authenticate with /etc/passwd - /etc/shadow. They are not mechanism that will work for AD authentication.

I think I have to change something in the .mc file, but I'm not sure what. What if I added GSSAPI to the TRUST_AUTH_MECH list and confAUTH_MECHANISMS?

Quote:

Migrating to another MTA (eg Postfix) may work around your problem but it's not a quick fix. You'd have to configure Postfix in the same way your sendmail setup is currently configured. It's better to try to understand and fix the issue at hand.

For numerous other reason (e.g. custom milters), that's not gonna happen. We'll leave cellphone users in /etc/passwd before changing MTAs.

mfoley · 12-13-2017, 01:03 PM

I've been doing more testing on this using http://www.sendmail.org/~ca/email/auth.html as my guide. I've checked my sendmail for sasl:

Code:

# sendmail -d0.1 -bv root | grep SASL
                PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS USERDB

This indicates to me that SASL is compiled in and enabled.

I then modified my .mc file to have:

Code:

TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN')dnl

Note that this removes the LOGIN mechanism shown in my IP -- mainly so I can confirm the new AUTH settings have changed. Then, trying to connect:

Code:

$ telnet localhost 25
Trying localhost...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Service ready; Wed, 13 Dec 2017 13:56:48 -0500
ehlo localhost
250-localhost Hello cpe-184-57-114-221.columbus.res.rr.com [184.57.114.221], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP

So, my first problem is, why does sendmail 250-AUTH not show any of the the mechanisms other than PLAIN (and LOGIN when I had that configured)? Even without the new GSSAPI, I previous had and still have DIGEST-MD5 and CRAM-MD5. These don't show in the 250-AUTH line either!

I think if I could get sendmail to list GSSAPI in the 250-AUTH line, I'd practically be done with this issue!