GSSAPI SMTPD Authentication and MS Active Directory

Discussion:

(too old to reply)

Matthew Larsen

2013-04-25 00:35:17 UTC

I'm working on a project to replace an Exchange 2003 server that is only
still around these days because we have lots of SMTP clients around the
country that use it as an SMTP relay. It only relays messages for clients
authenticated by our Active Directory domain. Members of a group in the
parent domain and a group in the child domain are given relay permissions
for this server.

The clients are almost entirely a .Net application that's configured with a
username, password, server name, port, SSL requirement toggle, and return
address. The application uses this information to relay messages through
this server when there isn't another option available for relay at that
customer's site.

I've been working on a Postfix and SASL configuration to take this Exchange
server's place as an authenticated SMTP relay and have a couple of
questions about SASL and SMTP AUTH that I'm struggling to find information
on.

I've noticed in a network trace of the traffic on the Exchange server that
the authentication by SMTP clients uses the GSSAPI mechanism. I'm not sure
how a Kerberos exchange would work with these clients. None of them are
computers joined to our AD domain and would have no way of knowing where to
find or even accessing a KDC (domain controller) to get a TGT or make a
TGS_REQ from the KDC. I'm not sure how that works.

As this is translated to a Postfix configuration:

Is Postfix and the SASL framework both the client and service in the
Kerberos authentication process, and how would / does the SMTP client
exchange the credentials with the SMTP AUTH process?

Does the SMTP client have a fallback method where it encrypts or encodes
the username and password that is passed on to the SMTP AUTH process using
the GSSAPI mechanism? This obviously depends on the SMTP client, but I
guess I'm asking how this is even possible.

Is it a correct assumption that the authentication communication between
the SMTP client and the SMTP server with the GSSAPI mechanism is more
secure on the wire than AUTH LOGIN without TLS?

Among several other sources I've read through online, I've read through the
SASL documentation at:
http://cyrusimap.web.cmu.edu/docs/cyrus-sasl/2.1.23/
http://www.unixdev.net/docs/postfix/SASL_README.html#server_cyrus

As of yet I've been unsuccessful at getting Postfix and SMTP AUTH to work
with the GSSAPI mechanism and our AD. I've referenced a couple of guides
online, but I'm still not understanding something.
http://www.codealias.info/technotes/postfix_gssapi_authentication_howto
http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=6717

My apologies for the long email. Any answers, pointers, information, or
how-to information I should check out to get this working would be very
much appreciated.

The results from postfinger and saslfinger are given below:

/////////////////////////////////

postfinger - postfix configuration on Wed Apr 24 16:34:45 PDT 2013
version: 1.30

Warning: postfinger output may show private configuration information,
such as ip addresses and/or domain names which you do not want to show
to the public. If this is the case it is your responsibility to modify
the output to hide this private information. [Remove this warning with
the --nowarn option.]

--System Parameters--
mail_version = 2.6.6
hostname = SBSMTPNV03.mydomain.com
uname = Linux SBSMTPNV03.mydomain.com 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed
Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

--Packaging information--
looks like this postfix comes from RPM package:
postfix-2.6.6-2.2.el6_1.x86_64

--main.cf non-default parameters--
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mynetworks = 10.20.3.0/24, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
relay_domains = $mydestination, hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
smtpd_recipient_restrictions =
permit_sasl_authenticated,reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_security_options = noanonymous,noplaintext
transport_maps = hash:/etc/postfix/exchange_domains

--master.cf--
smtp inet n - n - - smtpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o smtp_fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache

-- end of postfinger output --

///////////////////////////////

//////////////////////////////

saslfinger - postfix Cyrus sasl configuration Wed Apr 24 16:32:46 PDT 2013
version: 1.0.2
mode: server-side SMTP AUTH

-- basics --
Postfix: 2.6.6
System: CentOS release 6.4 (Final)

-- smtpd is linked to --
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f8161d95000)

-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_security_options = noanonymous,noplaintext

-- listing of /usr/lib64/sasl2 --
total 432
drwxr-xr-x. 2 root root 4096 Apr 23 15:49 .
dr-xr-xr-x. 27 root root 20480 Apr 23 16:56 ..
-rwxr-xr-x. 1 root root 18776 Nov 27 03:49 libanonymous.so
-rwxr-xr-x. 1 root root 18776 Nov 27 03:49 libanonymous.so.2
-rwxr-xr-x. 1 root root 18776 Nov 27 03:49 libanonymous.so.2.0.23
-rwxr-xr-x. 1 root root 31256 Nov 27 03:49 libgssapiv2.so
-rwxr-xr-x. 1 root root 31256 Nov 27 03:49 libgssapiv2.so.2
-rwxr-xr-x. 1 root root 31256 Nov 27 03:49 libgssapiv2.so.2.0.23
-rwxr-xr-x. 1 root root 18784 Nov 27 03:49 libldapdb.so
-rwxr-xr-x. 1 root root 18784 Nov 27 03:49 libldapdb.so.2
-rwxr-xr-x. 1 root root 18784 Nov 27 03:49 libldapdb.so.2.0.23
-rwxr-xr-x. 1 root root 18808 Nov 27 03:49 liblogin.so
-rwxr-xr-x. 1 root root 18808 Nov 27 03:49 liblogin.so.2
-rwxr-xr-x. 1 root root 18808 Nov 27 03:49 liblogin.so.2.0.23
-rwxr-xr-x. 1 root root 18808 Nov 27 03:49 libplain.so
-rwxr-xr-x. 1 root root 18808 Nov 27 03:49 libplain.so.2
-rwxr-xr-x. 1 root root 18808 Nov 27 03:49 libplain.so.2.0.23
-rwxr-xr-x. 1 root root 22784 Nov 27 03:49 libsasldb.so
-rwxr-xr-x. 1 root root 22784 Nov 27 03:49 libsasldb.so.2
-rwxr-xr-x. 1 root root 22784 Nov 27 03:49 libsasldb.so.2.0.23

-- listing of /etc/sasl2 --
total 12
drwxr-xr-x. 2 root root 4096 Apr 24 15:22 .
drwxr-xr-x. 61 root root 4096 Apr 24 15:22 ..
-rw-r--r-- 1 root root 69 Apr 23 11:30 smtpd.conf

-- content of /etc/sasl2/smtpd.conf --
log_level: 6
pwcheck_method: saslauthd
mech_list: gssapi plain login

-- active services in /etc/postfix/master.cf --
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
smtp inet n - n - - smtpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o smtp_fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache

-- mechanisms on localhost --

-- end of saslfinger output --

////////////////////////////////////////////

The contents of my keytab file imported from ktpass:

[***@SBSMTPNV03 mpiadmin]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
4 smtp/***@MYDOMAIN.com (des-cbc-crc)
4 smtp/***@MYDOMAIN.com (des-cbc-md5)
4 smtp/***@MYDOMAIN.com (arcfour-hmac)
4 smtp/***@MYDOMAIN.com (aes256-cts-hmac-sha1-96)
4 smtp/***@MYDOMAIN.com (aes128-cts-hmac-sha1-96)

--
Thanks,
Matt Larsen

Quanah Gibson-Mount

2013-04-25 00:57:31 UTC

Permalink

--On Wednesday, April 24, 2013 5:35 PM -0700 Matthew Larsen

Post by Matthew Larsen
I'm working on a project to replace an Exchange 2003 server that is only
still around these days because we have lots of SMTP clients around the
country that use it as an SMTP relay. It only relays messages for
clients authenticated by our Active Directory domain. Members of a
group in the parent domain and a group in the child domain are given
relay permissions for this server.

If you replaced Exchange 2003 with Zimbra, and set up external auth to your
AD server, then it would use the custom zimbra authentication method for
cyrus-sasl to auth your clients against AD. I don't know what you intend
on replacing Exchange with though, so that may be a bit more than you want.
But it is a solution.

If you want to use SASL/GSSAPI, the clients have to be able to get a TGT
from the KDC.

Alternatively, you could just do straight ldap authentication against AD,
instead of Kerberos-AD, something like:

<http://www.howtoforge.com/postfix-dovecot-authentication-against-active-directory-on-centos-5.x>

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

Matthew Larsen

2013-04-25 19:27:59 UTC

Permalink

Post by Quanah Gibson-Mount
If you replaced Exchange 2003 with Zimbra, and set up external
auth to your AD server, then it would use the custom zimbra
authentication method for cyrus-sasl to auth your clients against
AD. I don't know what you intend on replacing Exchange with
though, so that may be a bit more than you want. But it is a solution.

Zimbra would be more than I want in this case. All I need is a secure
authenticated SMTP server, and it would be nice to have a GUI to monitor
the message queues. My thought has been that Postfix with webmin would
be a good fit if I can get the authentication to work with Active
Directory.

Post by Quanah Gibson-Mount
If you want to use SASL/GSSAPI, the clients have to be able to get
a TGT from the KDC.

The reason I've been looking at configuring the SASL/GSSAPI mechanism is
that's what I see the current Exchange server doing. I'm hoping to
build something I can drop in place without needing to touch client
systems for reconfiguration.

I'm just puzzled as to how this works because the clients aren't members
of our AD domain, and I strongly doubt they have data for, or access to,
the DNS servers in the domain or a KDC. All they are given is an SMTP
server, username (DOMAIN\Username), and password.

It's also my understanding that the GSSAPI mechanism is more secure on
the wire than a plain text authentication method without TLS. Is that
accurate?

I'm not sure that my understanding of the security of the GSSAPI method
is accurate, or that the infrastructure is there in this case to support
doing this with Postfix?

Here's a screen shot
<Loading Image...

> of an SMTP
authentication exchange taken from a wireshark trace on the Exchange server.

Any pointers or further information on this works would be appreciated.

Alternatively, you could just do straight ldap authentication
against AD, instead of Kerberos-AD, something like:

<http://www.howtoforge.com/postfix-dovecot-authentication-against-active-directory-on-centos-5
<http://www.howtoforge.com/postfix-dovecot-authentication-against-active-directory-on-centos-5.x>

I'll check out the LDAP authentication setup. Hopefully as I gain a
better understanding of other possible pieces of this configuration the
whole thing will start to gel together for me.

Thanks,
ML

Quanah Gibson-Mount

2013-04-25 19:41:28 UTC

Permalink

--On Thursday, April 25, 2013 12:27 PM -0700 Matthew Larsen

Post by Matthew Larsen

Post by Quanah Gibson-Mount
If you want to use SASL/GSSAPI, the clients have to be able to get a TGT
from the KDC.

But exchange knows about your domain, correct? And how to authenticate
users to AD?

Post by Matthew Larsen
I'm just puzzled as to how this works because the clients aren't
members of our AD domain, and I strongly doubt they have data for, or
access to, the DNS servers in the domain or a KDC. All they are given
is an SMTP server, username (DOMAIN\Username), and password.

Because Exchange is cheating and doing the kerberos auth for them to AD?
I.e., it isn't the clients themselves doing SASL/GSSAPI, correct? It is
exchange?

Post by Matthew Larsen
It's also my understanding that the GSSAPI mechanism is more secure on
the wire than a plain text authentication method without TLS. Is that
accurate?

Any form of encryption is more secure than plain text... so yes, that is a
correct statement.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

Matthew Larsen

2013-04-25 19:48:30 UTC

Permalink

Post by Quanah Gibson-Mount
--On Thursday, April 25, 2013 12:27 PM -0700 Matthew Larsen

Post by Matthew Larsen

Post by Quanah Gibson-Mount
If you want to use SASL/GSSAPI, the clients have to be able to get a TGT
from the KDC.

But exchange knows about your domain, correct? And how to authenticate
users to AD?

Yes.

Post by Quanah Gibson-Mount

Because Exchange is cheating and doing the kerberos auth for them to AD?
I.e., it isn't the clients themselves doing SASL/GSSAPI, correct? It is
exchange?

I guess that's what I'm asking, and it would make sense. Exchange would
be both the client and service in the Kerberos exchange if that's the
case. Can Postfix / SASL be made to do the same?

Viktor Dukhovni

2013-04-25 20:02:52 UTC

Permalink

Post by Matthew Larsen

Post by Quanah Gibson-Mount
If you want to use SASL/GSSAPI, the clients have to be able to get
a TGT from the KDC.

The reason I've been looking at configuring the SASL/GSSAPI
mechanism is that's what I see the current Exchange server doing.

What evidence do you have that the server is "doing" GSSAPI? It
seems likely you're mistaken. Simply listing GSSAPI as a supported
SASL AUTH mechanism is not "doing" GSSAPI, the client would actually
have to use GSSAPI. It is quite possible your client's IP address
was whitelisted on the Exchange servers, or access was unrestricted, ...

Post by Matthew Larsen
I'm just puzzled as to how this works because the clients aren't
members of our AD domain, and I strongly doubt they have data for,
or access to, the DNS servers in the domain or a KDC. All they are
given is an SMTP server, username (DOMAIN\Username), and password.

The clients may be doing NTLM or PLAIN or nothing at all. You need
to figure out what's actually used. If TLS is not in use a simple
packet capture plus wireshark or similar will show you exactly what
the client and server are doing.

Post by Matthew Larsen
I'm not sure that my understanding of the security of the GSSAPI
method is accurate, or that the infrastructure is there in this case
to support doing this with Postfix?

The Postfix SMTP client if compiled with Cyrus SASL support, and
provided the Cyrus SASL gssapi plugin is installed will do GSSAPI.
There is no GSSAPI-specific code in Postfix, all the logic is in
Cyrus SASL. However, you need to specify a KRB5CCNAME in the
client's environment that is readable by the "postfix" user and
contains valid tickets at all times. To do this, run a cron-job
periodically that uses a keytab file to populate the credential
cache with freshly valid tickets.

If the above is just a bunch of greek to you, you want to look for
alternatives to GSSAPI.

Post by Matthew Larsen
I'll check out the LDAP authentication setup. Hopefully as I gain
a better understanding of other possible pieces of this
configuration the whole thing will start to gel together for me.

If you replace the Exchange servers with Postfix, you can support
any of the following authorization methods:

- Allow any client to send anywhere (internal open relay).
- Whitelist the particular sending IPs.
- Allow the clients to send via authorized TLS client certs.
- Allow the clients to send via any mutually supported SASL
mechanism, including PLAIN and/or GSSAPI.

For server-side GSSAPI support the server will need a keytab file
containing shared keys with the appropriate realm's KDCs.

--
Viktor.

Matthew Larsen

2013-04-25 21:39:28 UTC

Permalink

Post by Viktor Dukhovni
What evidence do you have that the server is "doing" GSSAPI? It
seems likely you're mistaken. Simply listing GSSAPI as a supported
SASL AUTH mechanism is not "doing" GSSAPI, the client would actually
have to use GSSAPI. It is quite possible your client's IP address
was whitelisted on the Exchange servers, or access was unrestricted, ...

My apologies. I am mistaken about how this is happening. Sometimes it's
a challenge to get accurate information from a different division that
takes care of this client system.

The computers running the SMTP client software are members of a child
domain in our AD forest, there's a VPN between those computers and a
different segment of our network housing the child domain AD
infrastructure, but for some reason (probably bandwidth and latency) the
SMTP client is connecting over the public Internet connection at the
client sites rather than the VPN. I think that mostly explains how the
infrastructure is there to use Kerberos for authentication.

Here's what I see it doing with wireshark on the server.

A screen shot of some of what I see:
Loading Image...

The gist of it is

S: 220 mail.exch01.com ...
C: EHLO NETBIOSName
S: 250-mail.exch01.com Hello [ip.addr.of.client] | 250- ... several
items including AUTH GSSAPI NTLM LOGIN among others ....
C: AUTH gssapi ...long string...
S: 334 ...long string...
C: ...long string...
S: 235 2.7.0 Authentication successful.
C: MAIL FROM:<***@address.com>
S: 250 2.1.0 ***@address.com ... Sender OK
C: RCPT TO:<***@yahoo.com>
S: 250 2.1.5 ***@yahoo.com
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
... blah blah blah ...

Post by Viktor Dukhovni
The clients may be doing NTLM or PLAIN or nothing at all. You need
to figure out what's actually used. If TLS is not in use a simple
packet capture plus wireshark or similar will show you exactly what
the client and server are doing.

In addition to what I see in Wireshark, the event log shows it's using
GSSAPI when I turn on the MSTransport authentication logging level to debug.

Event Type: Information
Event Source: MSExchangeTransport
Event Category: Authentication
Event ID: 1708
Date: 4/25/2013
Time: 11:17:49 AM
User: N/A
Computer: EXCH01
Description:
SMTP Authentication was performed successfully with client "A510E". The
authentication method was "GSSAPI" and the username was "MYDOMAIN\AAA".

Post by Viktor Dukhovni

Post by Matthew Larsen
I'm not sure that my understanding of the security of the GSSAPI
method is accurate, or that the infrastructure is there in this case
to support doing this with Postfix?

The Postfix SMTP client if compiled with Cyrus SASL support, and
provided the Cyrus SASL gssapi plugin is installed will do GSSAPI.
There is no GSSAPI-specific code in Postfix, all the logic is in
Cyrus SASL. However, you need to specify a KRB5CCNAME in the
client's environment that is readable by the "postfix" user and
contains valid tickets at all times. To do this, run a cron-job
periodically that uses a keytab file to populate the credential
cache with freshly valid tickets.
If the above is just a bunch of greek to you, you want to look for
alternatives to GSSAPI.

It's not entirely greek, but I'm trying to learn more greek. However, I
don't believe that I need the Postifix client to do any authentication
other than anonymous. It would be relaying messages from authenticated
clients to Internet recipients via MX records. I'm only trying to
configure the stmpd portion of Postfix for secure authentication.

Post by Viktor Dukhovni
If you replace the Exchange servers with Postfix, you can support
- Allow any client to send anywhere (internal open relay).
- Whitelist the particular sending IPs.
- Allow the clients to send via authorized TLS client certs.
- Allow the clients to send via any mutually supported SASL
mechanism, including PLAIN and/or GSSAPI.
For server-side GSSAPI support the server will need a keytab file
containing shared keys with the appropriate realm's KDCs.

The fourth option listed is what I'm trying to accomplish with GSSAPI,
but have been finding challenging to get working. I'll go back over my
configuration a time or two and try and find something specific that
will point to where it's not working.

Viktor Dukhovni

2013-04-26 01:43:58 UTC

Permalink

Post by Matthew Larsen
The gist of it is
S: 220 mail.exch01.com ...
C: EHLO NETBIOSName
S: 250-mail.exch01.com Hello [ip.addr.of.client] | 250- ... several
items including AUTH GSSAPI NTLM LOGIN among others ....
C: AUTH gssapi ...long string...
S: 334 ...long string...
C: ...long string...
S: 235 2.7.0 Authentication successful.

So GSSAPI it is and the clients already have GSS credentials.

Post by Matthew Larsen

Post by Viktor Dukhovni
If the above is just a bunch of greek to you, you want to look for
alternatives to GSSAPI.

It's not entirely greek, but I'm trying to learn more greek.
However, I don't believe that I need the Postifix client to do any
authentication other than anonymous. It would be relaying messages
from authenticated clients to Internet recipients via MX records.
I'm only trying to configure the stmpd portion of Postfix for secure
authentication.

The fourth option listed is what I'm trying to accomplish with
GSSAPI, but have been finding challenging to get working. I'll go
back over my configuration a time or two and try and find something
specific that will point to where it's not working.

You'll need to use the Microsoft command-line tools for to create
"SPN"s (service principals) for smtp/<hostname> for each new host
on which you plan to install Postfix. Then another tool to extract
a keytab file for each SPN. The keytab file will need to installed
mode 0600 owned by "postfix".

The Postfix SMTP server will need:

import_environment = ... KRB5_KTNAME=FILE:/path/of/keytab/file

where "..." includes all the default values of import_environment. It
is also possible to delegate all the work of doing GSSAPI auth to dovecot,
in which case the dovecot keytab will need to contain keys for both
imap and smtp (or perhaps just smtp if dovecot is not used for imap),
or choose gssapi as the mechanism in smtpd.conf for Cyrus SASL.

The clients will need to be reconfigured to connect to a new set of
server hosts.

--
Viktor.