openldap24-server not honouring KRB5_KTNAME or SASL slapd.conf

G

gon

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.
 
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
Code: 
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
 
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
Code: 
...
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
 
Hi,

I want to know how I can compile heimdal-1.5.2 with OpenLDAP backend - openldap24-server) without this error message
Code: 
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
 
You must log in or register to reply here.
Back
Top