On Wed, Aug 16, 2017 at 10:09:06PM -0400, Robert Marcano wrote:
> I have been using Postfix with Kerberos without problem for a few years.
> Our setup uses a DNS alias (CNAME) for the hostname. Let call it
> smtp.example.com, pointing to the real hostname server.example.com.
Is this an MX hostname, or a submission service? Are the clients MUAs
or MTAs?
Optional forward name canonicalization of host-based service names
is performed by GSSAPI clients, not servers. Absent such
canonicalization, a service may need multiple entries in the KDC
database and mutliple corresponding keytab entries, one for each
of its alias names.
> With a default MIT Kerberos client configuration, dns_canonicalize_hostname
> is true.
Correct, but do not confuse this with the even more deprecated,
and rather unwise "rdns = true". In a typical configuraiton, you'd
have:
rdns = false
dns_canonicalize_hostname = true
> This setting [1] enable the reverse lookup to search the hostname
> given the alias.
No, not "reverse" (which maps IP addresses back to names via PTR
records when DNS is used), but forward which recursively expands
CNAME records in DNS or just returns the first name in /etc/hosts
from a line containing the lookup key as one of the names. This
is obtained via getaddrinfo(3) with the AI_CANONNAME flag.
> The Linux distribution used for our clients machines is
> changing the default to dns_canonicalize_hostname = false.
This improves GSSAPI security in the face of insecure DNS, but
makes administration of services more complex in some cases.
If you're not ready for this change in the default, you can
maintain the status quo ante with an explicit non-default
setting.
> Changing dovecot was not difficult, but I have been unable to make Postfix
> to work in this new setup.
The setting in question affects client behaviour, with the client
attempting to obtain service tickets for smtp/aliasname@REALM,
rather than smtp/targetname@REALM.
Obviously, for this to work, the new service principal needs to be
registered at the KDC, and the corresponding keys need to appear
in the server's keytab file.
> I tried testing with an empty keytab for Postfix
> and the error message was:
>
> warning: SASL authentication failure: GSSAPI Error: Unspecified GSS
> failure. Minor code may provide more information (Request ticket server
> smtp/smtp.example....@example.com not found in keytab (ticket kvno 4))
You failed to merge the associated keys into the server's keytab
file.
> As postfix was looking for that.
Really the client was trying to perform authentication with that
new principal, and so the SASL GSSAPI plugin was handling a client
request in which the server principal name was the new alias.
Now, as it turns out the Cyrus SASL GSSAPI plugin does not (as it
really should by default) support multiple service names in the
keytab file (by using GSS_C_NO_NAME as the service name passed to
gss_accept_sec_context(3)). Rather, the plugin requires the
application to register a single service name, and only requests
for that service name will be accepted.
In the case of Postfix, the service hostname passed to sasl_server_new(3)
is the value of "myhostname". Thus, each smtpd(8) that performs
GSSAPI authentication needs to be known to all its GSSAPI clients by
a single name, with that name matching "myhostname" (possibly via a
"-o myhostname=..." override in master.cf).
> I added the service smtp/
> smtp.example....@example.com to it. The new error message was:
This won't work, unless "myhostname" == "smtp.example.com" and
EXAMPLE.COM is your default_realm in krb5.conf.
> warning: SASL authentication failure: GSSAPI Error: Unspecified GSS
> failure. Minor code may provide more information (No key table entry found
> matching smtp/server.example.com@)
The empty realm above is a red herring, it is a side-effect of the
GSSAPI abstraction over Kerberos hiding the Kerberos realm name
from the GSSAPI client API. The real problem is that Cyrus SASL
insists on hardcoding the server name.
> Notice the service name doesn't include a realm: smtp/server.example.com@
Red herring, the real problem is the wrong hostname.
> As the realm was empty I then tried with the Postfix setting named
> smtpd_sasl_local_domain without any change, same error.
This has no effect on kerberos.
> Dovecot has a setting named auth_gssapi_hostname [2] that allow to change
> the hostname used for the Kerberos service and it allowed me to make
> Dovecot work in this new environment.
That's because Dovecot bypasses Cyrus SASL and supports GSSAPI
directly. Postfix supports "dovecot" auth, and indeed my
SMTP server's submission service does GSSAPI via "dovecot"
not Cyrus.
> do Postfix has something like that?.
Only by setting "myhostname" as explained above, but you
can also set:
smtpd_sasl_type = dovecot
And let dovecot handle GSSAPI authentication also for Postfix. I
have:
dovecot.conf:
auth_mechanisms = gssapi plain
auth_gssapi_hostname = "$ALL"
auth_krb5_keytab = /var/spool/keytabs/imap
/var/spool/keytabs/imap:
Vno Type Principal Aliases
2 aes128-cts-hmac-sha1-96 imap/imap.example....@example.org
2 aes128-cts-hmac-sha1-96 smtp/smtp.example....@example.org
--
Viktor.
