Score:1

Server

Cannot initialize openLDAP-backed kerberos realm using krb5_ldap_util with startTLS?

surfrock66

2/6/24, 2:43 AM

I have set up an openLDAP backed MIT Kerberos realm on a server after much iteration, and I am now trying to move it to its own server. When I first set it up on the original server, I created a local realm, then moved it to one backed by openLDAP which was installed on the same server.

On the new server, I've set up openldap and populated it, including setting up startTLS. I have validated the cert using openssl s_client. When I've gone forward to install kerberos, I started by trying to install krb5-kdc-ldap on Ubuntu Server 22.04.1 (which will install krb5-kdc as a dependency). The krb5-kdc package does not properly install; I tell it to not create the initial config, and when the installer tries to start the service, it fails with the following error:

Cannot open DB2 database '/var/lib/krb5kdc/principal': No such file or directory - while initializing database for realm SUBDOMAIN.DOMAIN.COM

For now, that is fine; it's expected, I'm not creating a file-based realm, we'll be hooking into the LDAP server as our DB. I then define most of my krb5 settings in /etc/krb5.conf. Dbmodules is defined in the krb5.conf pointing to "ldapi:///" and I am not pointing to a keyfile or bind user yet. I then try to create the realm with the following command:

kdb5_ldap_util -D cn=admin,dc=subdomain,dc=domain,dc=com -H ldapi:/// create -subtrees dc=subdomain,dc=domain,dc=com -sscope SUB -r SUBDOMAIN.DOMAIN.COM

However, I get the output that I cannot bind to the LDAP server because "Confidentiality required while initializing database". My understanding is this is a StartTLS issue; with commands like ldapadd I get a similar error when I don't pass the "-ZZ" flag. Is there a way to initiate krb5_ldap_util over startTLS? Am I doing things in the wrong order; in the existing environment things were done in so many iterations I'm not sure the order I did to get it working. Is there a step in setting up krb5.conf to indicate something about TLS; I don't have that in my existing working setup, and I'm not seeing anything in the documentation that leads me to the right path. I am using an internal certificate authority, and I have validated that the OpenLDAP server is serving a domain cert that will validate on my other clients, and I have validated that the CA is in the root CA store on the new LDAP server. I keep suspecting I just have a cert problem, but all checks are passing with flying colors.

Edit: ldif file I used for forcing TLS, per the comment below:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

202

1 + 2

ssl

openldap

kerberos

user1686

2/7/24, 7:39 AM

Why is your LDAP server even set up to require StartTLS over ldapi://, which is an inherently host-local transport?

surfrock66

2/7/24, 6:56 PM

Can you disable it for only ldapi? I edited the OP with the ldif used to force tls; I thought it was binary on/off.

Score:1

Server

user1686

2/9/24, 4:40 PM

The ldap kdb module in MIT Krb5 never requests StartTLS; only an ldaps:// URI will make it automatically use TLS.

You should instead reconfigure the server to not require TLS for local-host ldapi:// connections, i.e. you should not use olcSecurity: tls=1 but instead configure a minimum SSF requirement ("security strength factor") via olcSecurity: ssf=[...], as it can be satisfied either by TLS or by a local connection (or even by Kerberos GSSAPI encryption).

But also keep in mind that many clients read the operational attributes from the "rootDSE" entry (i.e. entry with null DN; ldapsearch -H <url> -b "" -s base +) to determine the availability of GSSAPI and/or StartTLS features on the server. Having either tls= or ssf= enforced globally would prevent rootDSE access, so it is better to do it at database level instead.

All together, you should do:

dn: cn=config
delete: olcSecurity
-

dn: olcDatabase={0}config,cn=config
replace: olcSecurity
olcSecurity: ssf=71
-

dn: olcDatabase={1}mdb,cn=config
replace: olcSecurity
olcSecurity: ssf=71
-

# (repeat for however many database backends you have)

(For TLS and GSSAPI, the SSF depends on the cipher suite being used, whereas the SSF implied by local connections is just reported as 71 by default. This value can be tweaked via olcLocalSSF if you want to insist on "ssf=128", for example.

But instead of raising olcLocalSSF to that level, it probably makes more sense to completely disable the negotiation of weak TLS ciphers via olcTLSCipherSuite or olcTLSProtocolMin, and to remove weak Kerberos enctypes through KDC configuration.)

+ 5

surfrock66

2/9/24, 10:30 PM

Ok, fascinating. I had never heard of this, and I'm going to read up on it and give it a whirl...I will report back with success (or more likely) more questions, but I really appreciate you opening my eyes to something I hadn't seen yet.

surfrock66

2/10/24, 9:04 PM

I see 5 databases in my instance, but I can't tell if I should apply that configuration to all of them; some of them look different? I have "cn=module{0}" which I don't think gets the rule, "cn=schema" which I don't think gets the rule, "olcDatabase={-1}frontend" which I don't think gets the rule, then the 2 you indicated. Am I understanding that right?

user1686

2/11/24, 1:08 PM

The first two entries don't represent databases at all, they're just generic configuration entries. (Not all child entries are always of the same type...) And yes, "frontend" doesn't need the rule since anything configured there would affect *any* LDAP access (including rootDSE) which you want to avoid in this case; so only configure the SSF requirement on the individual backend entries (olcDatabase=mdb, config, etc).

surfrock66

2/17/24, 11:50 PM

This was the fix. I have other issues around SASL, but I'm past this issue, thank you so much!!!

not2savvy

5/11/24, 10:44 AM

After applying the change to `dn: olcDatabase={0}config,cn=config`, I get `LDAP result code 13 - confidentiality required` over STARTTLS. What am I doing wrong?

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Cannot initialize openLDAP-backed kerberos realm using krb5_ldap_util with startTLS?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.