On Tue, Oct 31, 2023 at 08:22:50AM -0400, Brendan Kearney via Postfix-users
wrote:
> > But since you mentioned haproxy and multiple nodes, you're still only
> > working your way up to base-camp...
> >
> so, yes, full blown GSSAPI with all the fixin's.
> The syncing of the keytab across the cluster members is a matter of creating
> it once and scp'ing that same exact keytab to the other servers.
That makes key rollover a nuisance you'll neglect, or that would require
a full cluster shutdown maintenance window. I guess you're willing to
accept that...
> The path forward seems to 1) hack the hostname in Postfix and deal with any
> fallout or, 2) move from Cyrus to Dovecot SASL.
I'd go with that approach, especially if you're going to operate an IMAP
service (via Dovecot).
> Since I am using Kerberos for passdb,
You can't be using "Kerberos" for "passdb", that's only for verifying
passwords, which aren't what's in GSSAPI with Kerberos 5 as the mech.
I also have a passdb, because some "devices" don't do Kerberos, those
passwords are never entered or remembered by humans, they are machine
generated 15 random bytes encoded in Base64, saved in the device and
forgotten by the user. Only specific users are allowed to use
passwords (configured via PAM):
# PAM for non-gssapi users, who must be in group "pamimap",
# see /etc/pam.d/dovecot
#
passdb {
driver = pam
}
> I want to use LDAP for userdb only, and bind to the directory with the
> Dovecot keytab. it seems i should be able bind without a DN, and use
> SASL binds instead, but i have that to work out with questions on the
> Dovecot mailing list.
My personal server user base is rather small, anyone who can
authenticate is automatically a user. So no direct experience with
dovecot LDAP:
userdb {
args = uid=... gid=... home=/var/spool/virtual
mail=maildir:/var/spool/virtual/%n
driver = static
}
My recommendation for "bind" AUTH would be to use a "prestashed" ticket,
not a keytab for client-side auth. Run a cronjob once an hour to
with "kinit -k" to place a ticket as the right service principal
in /var/spool/tickets/<someuser>. Then put
KRB5CCNAME=FILE:/var/spool/tickets/<thatuser>
in dovecot's environment, or equivalent configuration if a ticket
location can be specified explicitly that way.
I can't help further with GSSAPI support in Dovecot's LDAP client, never
had to look into it.
> What drawbacks are there in setting $myhostname to the VIP name in Postfix?
> does that have nuances that need to be accounted for otherwise?
It would by default appear in the EHLO response, and would give some TLS
clients (Postfix, for example) the impression that they're working with
a single TLS server, and that session tickets from one node can be used
with another. That will make TLS session caching work poorly.
Therefore, set:
actual_unique_hostname = ...
smtpd_banner = $unique_hostname ESMTP $mail_name
otherwise, not much depends on $myhostname in smtpd(8), but look over
your config and see how you're using it. Note that address classes
(e.g. via $mydestination for local addresses) are determined in
trivial-rewrite(8) not smtpd(8). You'll probably want to override
"myhostname" in just the smtp/inet service in master.cf, not main.cf.
But you don't need to mess with $myhostname if you choose Dovecot, just
set "$ALL" as the server principal name. Do use distinct hostnames on
the cluster nodes.
> What does using Dovecot mean, given that I am using Kerberos for AuthN and
> LDAP for AuthZ?
Postfix only cares about the "AuthN" part, it has its own "authz" in the
form of access(5) tables and sender/recipient restrictions. It doesn't
matter whether you'd use Dovecot or Cyrus.
> The authentication is done via Kerberos, and I would like to have that
> be the case in Postfix.
Dovecot supports this. It can also supports PLAIN, if you enable that
in Postfix (smtpd_sasl_mechanism_filter), then Dovecot's "passdb" comes
into play.
> LDAP access, via the keytab and not via a user/pass credential set in
> configs, would be to validate email address, groups, etc.
I thought above you were looking at LDAP for dovecot IMAP user account
info. If you're instead talking about LDAP for email addresses (groups,
...), that has nothing to do with dovecot. You want to read the Postfix
LDAP_README.
There, I do have significant experience. Go with the prestashed ticket
approach. And in main.cf put:
import_environment = KRB5CCNAME=FILE:/var/spool/tickets/postfix
and run a cron job as "postfix" (hourly is more than sufficient) to
keep the ticket current. If you make it a 7 day ticket, you can
run the job daily. Then just specify "gssapi" as the SASL mechanism
in your LDAP table ".cf" files:
version = 3
bind = sasl
sasl_mechs = gssapi
> I have no hard set requirement to use Cyrus and can switch to Dovecot,
> but I do want to keep complexity as low as possible.
You've chosen a funny way to keep complexity low. :-)
> I see this as more of a decision based on which has less pitfalls.
You'll find dovecot easier to configure, if you're hosting an IMAP
service anyway. Running "dovecot" just as a Postfix auth backend
is perhaps more complex than a working Cyrus config, but that limits
your choices of server principal name to just one hostname.
Perhaps Postfix should allow a separate setting for that, but that's not
the case today, and it would still be just one value. There's no way
to give Cyrus multiple server-name personalities without patching it.
> Thanks for the insight. I know there are complexities and I have gotten
> through a lot of them in other places. I was only able to because others
> were as kind and as helpful as you.
You're welcome. If this thread continues, you can return the favour by
repairing the shift key on your keyboard... :-)
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
