on Mon, Oct 30, 2023 at 08:19:16PM -0400, Brendan Kearney via Postfix-users
wrote:
> I am setting up submission behind haproxy and want to use kerberos
> authentication via SASL.
Do you mean *actual* Kerberos authentication (as in the SASL GSSAPI
mechanism) with Kerberos tickets provided by the user agent?
Or pseudo server-side-only Kerberos, where the server's internal
implementation of PLAIN passes the user supplied password off to
something that'll attempt to use it to obtain and verify a ticket from
the KDC against its own keytab?
> I have setup saslauthd, [...]
Sounds like the latter, since I don't think "saslauthd" does actual
Kerberos.
> [...] configured Postfix and submission and generated the keytab.
Fine.
> Because I want load balancing, the keytab has to match the name of the
> VIP on haproxy, not the individual hosts load balanced behind
> haproxy.
Actually, that's only the case for the "real Kerberos case", so which is
it? With Kerberos as a backend for "PLAIN", that's not necessary.
If you actually mean real "GSSAPI" auth from SMTP client, then yes, the
multiple cluster nodes need to synchronise their keytabs, by
coordinating injection of the next "kvno" for the principal across all
the hosts, before the KDC declares that "kvno" to be the active "kvno"
for the service principal.
But in that case, "saslauthd" is not the droid you're looking for.
The Cyrus SASL library has direct support for GSSAPI, right in the
Postfix server, and you'd use that. Also requires a bit of care.
The other way to do GSSAPI is to use the GSSAPI support in "dovecot",
unlike "saslauthd", it will do real GSSAPI reasonably well, but you'll
still have the keytab synchronisation issues to deal with.
The Heimdal project (where I previously worked on some of the code in
question) has extensive support for server clusters, but this rather an
advanced use-case. You've chosen a steep hill to climb...
> usually there is a config tweak to specify a kerberos principal that
> differs from the expected smtp/host.domain.tld@REALM principal, and I
> cannot find that tweak.
The low-level fog is obscuring the true height of the mountain you're
set on climbing, and even obscuring the trail to get started...
> The haproxy VIP submission.bpk2.com and the hostname is
> mail.bpk2.com. I want to specify that submission should use the
> naming convention I want, and not the expected principal. How do I
> set this in the configs?
First things, first. Are you implementing "GSSAPI" or "PLAIN" with the
KDC + keytab as a backend?
> Sending of the message failed.
> The Kerberos/GSSAPI ticket was not accepted by the Outgoing server (SMTP)
> submission.bpk2.com. Please check that you are logged in to the
> Kerberos/GSSAPI realm.
Now we see you realy/truly mean GSSAPI, prepare to journey to Mount
Everest base camp. Make sure your gear is complete and in order, oxygen
tanks full...
With actual GSSAPI, you don't get to choose the principal name the
client sends, that client decides that based on its configuration,
and your keytab needs to list exactly what the client expects.
In addition, the library validating the ticket (Cyrus SASL), needs to be
willing to accept whatever name the *client* sent, and look for that in
its keytab, rather than insist that the only acceptable principal name
it will use is service/<system-hostname>@<systemrealm>.
You appear to be attempting to use Cyrus SASL GSSAPI. It has no support
for accepting the client signalled server name, and requires the
application (say, Postfix) to supply a fixed name to check for in the
keytab. Postfix will supply the value of the "myhostname" main.cf
parameter. I've used patched versions of Cyrus SASL that allow that
logic to be disabled, but you're unlikely to want to build your own...
If all clients agree on the same name, you'll have to make "$myhostname"
in the Postfix smtpd(8) service be that name.
Unlike Cyrus, "dovecot" is more sensible. In my "dovecot"
configuration, I have:
dovecot.conf:
auth_realms = <REALM>
auth_mechanisms = gssapi plain
auth_gssapi_hostname = "$ALL"
auth_krb5_keytab = /var/spool/keytabs/imap
This accepts creds for all principals present in the specified keytab,
and doesn't insist on just one name.
But since you mentioned haproxy and multiple nodes, you're still only
working your way up to base-camp...
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
