spn alias

[Michael B Allen]

On Thu, Mar 6, 2025 at 5:57 PM Jeffrey Hutzelman <jhutz at cmu.edu> wrote:

> 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.
>

I thought that's how kerberos worked by default - just use the spn in the
ap-req to lookup the base key from the keytab or wherever.

Sounds gssapi got in the way of itself.


> * "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.
>

Ah, ok. Clearly I'm exposing myself on the Internets again.


> ** 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.
>

Deploying CA certs is annoying.

I've been thinking about adding a utility to my toolchain that does an LDAP
bind with Kerberos and, if and only if mutual is successful, grab the CA
cert from the SSL layer and offer to install it (like
into jre/lib/security/cacerts for java in my case).

Mike

-- 
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/ <http://www.ioplex.com/>