spn alias

[Jeffrey Hutzelman]

It sounds like the setup uses a load balancer that accepts TCP connections
and relays to some available server. Basically a reverse proxy at the TCP
layer, and pretty common for this type of service (i.e. not HTTP).

Unfortunately, the Cyrus SASL library used by OpenLDAP has a limitation in
the GSSAPI mechanism, which is that it supports only a single service
principal name(*). By default, that's ldap/<hostname>, using the machine's
configured FQDN. You can configure it to use a different name, such as the
one belonging to the shared load balancer VIP, but I'm afraid I don't
recall exactly how offhand (and I'm not in front of a computer). So, you
can support the server's individual name or the shared name, but not both.

Years ago we patched Cyrus SASL to avoid this problem by allowing any
principal whose keys appear in the keytab, but that unfortunately was never
merged. The change is simple enough -- when calling gss_accept_sec_context,
use GSS_C_NO_CREDENTIAL instead of going out of the way to call
gss_acquire_cred to get a specific server credential.

FWIW, our current solution to this issue at CMU is to use a DNS-based load
balancer which returns the address of a different LDAP server on each
lookup of ldap.cmu.edu. The servers then each only need to accept their own
SPN, since the clients reverse resolve the LDAP server address before
requesting a service ticket(**).

* "service principal name" is the name of a principal used as a service. In
Windows AD, this is often an alias for an "account", but that's an artifact
of the design of AD. In other implementations including MITa and Heimdal,
service principals are first-class objects just like client principals, and
the question about aliasing is a reasonable one, though not really the
cause of the problem here.

** RFC 4120 specifically said not to rely on insecure DNS queries for this,
but that advice is unfortunately frequently ignored, by applications and
libraries in ways that are hard to avoid. Fortunately, everyone seems to
follow the corresponding advice for TLS and X.509 PKI, which essentially
means that as long as you use ldaps and validate certificates, the reverse
DNS lookup before calling SASL/GSS/Kerberos doesn't introduce any problem.


On Thu, Mar 6, 2025, 17:25 Michael B Allen <ioplex at gmail.com> wrote:

> On Thu, Mar 6, 2025 at 11:45 AM Stefan Kania <stefan at kania-online.de>
> wrote:
>
> > hi to all,
> > is it possible to set an alais for the spn? We still having the problem
> > doing  kerberos authentication through a loadbalancer. We created a
> > principal for the loadbalancer and a keytab. We then added the key to
> > the ldap-keytab file, so we are having both, the ldap key for the server
> > and the ldap key for the loadbalancer in one file. This file we use as
> > keytab for the ldap-server. the client connets to the loadbalancer (with
> > ldapsearch) and we are getting "err=49" and the log is showing that the
> > spn is wrong. So we think with an alias for the spn for the loadbalancer
> > it might work. Or is there any other way to get the
> > kerberos-authentication through the loadbalancer?
> >
>
> Hi Stefan,
>
> How are you load balancing LDAP exactly?
>
> The most common way to load balance LDAP is to use SRV records.
> Clients pick a server based on SRV record priority and weight.
>
> An SPN /is/ an alias for an account + secret so, no, I would not say you
> can have an alias for an SPN.
>
> Each service instance should have a unique DNS hostname with a unique SPN
> that probably refers to different accounts but it is common to have
> multiple SPNs reference the same account (albeit usually for different
> schemes).
>
> If your load balancing is more like a reverse proxy arrangement, that would
> mean clients are all using the same exact SPN which means each endpoint
> must use the same account + secret and thus the same key. This sounds like
> your point-of-failure.
>
> But I'm no expert on such things. I have never load balanced LDAP in any
> way other than the usual SRV record method.
>
> If you explain your architecture in a little more depth, you might get a
> better answer.
>
> Mike
>
> --
> Michael B Allen
> Java AD DS Integration
> https://www.ioplex.com/ <http://www.ioplex.com/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>