Re: spn alias

[Ken Hornstein via Kerberos]

>KRB5_TRACE=/dev/stdout kinit  is showing that I connect to   
>the LDAP-Server and the LDAP-server is responding and sending me a  
>service-ticket I can see with "klist". But then I got an err=49 from
>the LDAP-Server. I can see it in the log of the LDAP-Server.

"err=49" is not a Kerberos error!  I don't suppose you could post that
message from the LDAP server?

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Stefan Kania]

Am 08.03.25 um 21:23 schrieb Ken Hornstein:

If you are using MIT Kerberos (anything 1.10 or newer) on the
LDAP server, you can use the krb5.conf configuration entry
"ignore_acceptor_hostname" to allow the server to match on any valid
hostname.  See details here:


Hi Ken,

that did it. Thank you. Now we get the ticket trough the loadbalancer.
But OpenLDAP is complaining about the name of the principal is not
matching the fqd.  WE now will go the way without the load balancer. We
will use SRV-records.


Hm, _OpenLDAP_ is complaining?  Are you sure?  Like, how does it even know?
Exactly what error are you getting?

--Ken


KRB5_TRACE=/dev/stdout kinit 
is showing that I connect to the LDAP-Server and the LDAP-server is 
responding and sending me a service-ticket I can see with "klist". But 
then I got an err=49 from the LDAP-Server. I can see it in the log of 
the LDAP-Server.




smime.p7s
Description: Kryptografische S/MIME-Signatur

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Ken Hornstein via Kerberos]

>> If you are using MIT Kerberos (anything 1.10 or newer) on the 
>> LDAP server, you can use the krb5.conf configuration entry
>> "ignore_acceptor_hostname" to allow the server to match on any valid  
>> hostname.  See details here:  
>
>Hi Ken,
>
>that did it. Thank you. Now we get the ticket trough the loadbalancer.  
>But OpenLDAP is complaining about the name of the principal is not  
>matching the fqd.  WE now will go the way without the load balancer. We 
>will use SRV-records.   

Hm, _OpenLDAP_ is complaining?  Are you sure?  Like, how does it even know?
Exactly what error are you getting?

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Stefan Kania]

Am 07.03.25 um 02:10 schrieb Ken Hornstein via Kerberos:

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


If you are using MIT Kerberos (anything 1.10 or newer) on the LDAP server,
you can use the krb5.conf configuration entry "ignore_acceptor_hostname"
to allow the server to match on any valid hostname.  See details here:


Hi Ken,

that did it. Thank you. Now we get the ticket trough the loadbalancer. 
But OpenLDAP is complaining about the name of the principal is not 
matching the fqd.

WE now will go the way without the load balancer. We will use SRV-records.

Stefan

https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults

Should do what you want.

--Ken


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


--


smime.p7s
Description: Kryptografische S/MIME-Signatur

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Ken Hornstein via Kerberos]

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

If you are using MIT Kerberos (anything 1.10 or newer) on the LDAP server,
you can use the krb5.conf configuration entry "ignore_acceptor_hostname"
to allow the server to match on any valid hostname.  See details here:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults

Should do what you want.

--Ken


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Jeffrey Hutzelman]

On Thu, Mar 6, 2025, 19:16 Michael B Allen  wrote:

> On Thu, Mar 6, 2025 at 5:57 PM Jeffrey Hutzelman  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.
>

GSSAPI makes it easy to do this right, and that's the advice we've been
giving for at least 20 years. Unfortunately, or also makes it easy to get
the idea that servers have to acquire a credential to accept connections.

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

That seems reasonable, if you trust the server to send the right CA cert.
It would also work to use a Kerberos authenticated ssh connection, or set
up something behind https://www.eyrie.org/~eagle/software/remctl/ to
provide a CA cert. I agree, deploying CA certs or anything you can trust is
annoying. Once you've done that once, better to make use of it for others.

>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Michael B Allen]

On Thu, Mar 6, 2025 at 5:57 PM Jeffrey Hutzelman  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/ 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Michael B Allen]

On Thu, Mar 6, 2025 at 11:45 AM Stefan Kania  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/ 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: 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/, 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  wrote:

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

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Jeffrey Hutzelman]

What LDAP server software are you using?

On Thu, Mar 6, 2025 at 11:44 AM Stefan Kania  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?
>
> Stefan
>
>
>
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: spn alias

[Stefan Kania]

We are using openldap 2.6 together with mti-kerberos version 1.18 on 
debian 12.


Am 06.03.25 um 17:57 schrieb Jeffrey Hutzelman:

What LDAP server software are you using?

On Thu, Mar 6, 2025 at 11:44 AM Stefan Kania > 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?

Stefan




Kerberos mailing list Kerberos@mit.edu 
https://mailman.mit.edu/mailman/listinfo/kerberos 







smime.p7s
Description: Kryptografische S/MIME-Signatur

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos