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 <[email protected]> wrote: > On Thu, Mar 6, 2025 at 11:45 AM Stefan Kania <[email protected]> > 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
