# openldap24-server not honouring KRB5_KTNAME or SASL slapd.conf



## gon (Mar 3, 2010)

Hi,

I've been wrestling with getting openldap24-server on FreeBSD 8.0-RELEASE to authenticate against a Heimdal Kerberos server (running the standard server shipped with FreeBSD 8.0) . It works fine if I modify the permissions to allow ldap group read on /etc/krb5.keytab on the LDAP server. However I'd like to have a separate keytab just for the ldap server.  The two servers are both running in jails with /proc and /dev access. 

I set KRB5_KTNAME via the slapd_krb5_ktname rc.conf option. This didn't work. So I set keytab in /usr/local/etc/sasl2/slapd.conf and also tried /usr/local/lib/sasl2/slapd.conf. That didn't work either.
Doing a truss of slapd shows it reads the keytab: value but when truss runs against an authentication attempt it shows slapd is trying to open /etc/krb5.keytab.

I've tried the SASL sample client/server test tools and these work fine when KRB5_KTNAME is set in the environment. 

I'm at a bit of a loss now. It seems that something is happening to the KRB5_KTNAME before it can be used by the Heimdal libraries. KRB5_KTNAME is showing in a ps aux -e output. 

I've checked for bugs against the port and googled my best but found nothing related that indicated what was happening.

Any help is greatly appreciated!

Thanks for your time.


----------



## migle (Mar 20, 2011)

Hi,

It's been a year since you posted. I have the same problem here with FreeBSD 8.2-STABLE and openldap-sasl-server-2.4.24.

I have a /etc/krb5.ldap and a /etc/krb5.keytab and 
	
	



```
slapd_krb5_ktname="/etc/krb5.ldap"
```
 in rc.conf. /etc/krb5.ldap belongs to ldap:ldap, so *slapd* can read it. When I let the ldap user read /etc/krb5.keytab, authentication works, when I don't, it doesn't work.

If you found out anything in the meanwhile, please tell.

For now, I'll use a different strategy: create a group k5tab just for owning the system keytab, make the file group readable, and add the ldap user to that group.

It's still not as clean as having a separate file. It kinda beats the purpose of having the *slapd* daemon running non-root. In the eventuality of a catastrophic security flaw in *slapd*, it will have access to all keys in the keytab (even host/...) and the whole system is compromised.

migle


----------



## hcoin (Sep 21, 2011)

Here's an approach/fix/patch I submitted:

https://list.sics.se/sympa/arc/heimdal-discuss/2011-09/msg00022.html
"Patch for uid based default keytabs for sasl gssapi slapd/ldap"

It creates a new default_keytab_name filetype UIDF.   So in krb5.conf you have

```
...
default_keytab_name=UIDF:/etc/krb5.keytab
...
```
What that does is:  it tries to replace the . with .<user id in decimal>.
if that file exists and is readable by the current caller, that file gets used instead of krb5.keytab.  If not accessible, then krb5.keytab gets used.  More details over at the given link, including a patch for FreeBSD 8-STABLE.

The upshot is: you can create krb5.389.keytab and just put the ldap/<your.box.com> principal in it, secure readonly to ldap:ldap .. and leave the host key in krb5.keytab secured root readonly.  You could even create a krb5.0.keytab and put the host/<fqdn> principal there, and use krb5.keytab default for some lesser shared principal among a group of gssapi sasl users.   

Note root users can use the KRB5.. and other environment variables.  This bug only happens because krb5 tried to protect against suid programs twiddling the environment.  But, the test issetugid claims 'tainted' happens when root drops to user or the other way round.  Hence the ignored environment issues you found.

HTH

Harry


----------



## ghostrider95 (May 14, 2012)

Hi,

I want to know how I can compil*e* heimdal-1.5.2 with OpenLDAP backend - openldap24-server) without this error message 
	
	



```
kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so: Cannot open "/usr/lib/hdb_ldap.so
```
 in FreeBSD 8.3?

Can you help me?

Thanks,

Fry


----------

