[SRU]slapd gssapi failure - apparmor profile doesn't support kerberos gssapi
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openldap (Ubuntu) |
Fix Released
|
Undecided
|
Jamie Strandboge | ||
Hardy |
Fix Released
|
Undecided
|
Unassigned | ||
Intrepid |
Fix Released
|
Undecided
|
Jamie Strandboge |
Bug Description
Binary package hint: slapd
I'm setting up a ldap server allowing gssapi (kerberos) authentication, and it looks like the slapd daemon does not work properly. I've tried with both sasl-gssapi flavours (MIT & heimdal), and both fail when the slapd is running on the ubuntu (hardy) box, but works properly when the slapd is on a debian (etch) box.
The behaviour (described below) is the same when I supply the proper KRB5_KTNAME on /etc/default/slapd and when no keytab is supplied there, so it looks like the environment variable is not honoured.
When using the Heimdal-GSSAPI library, I get
ldap_sasl_
MIT-GSSAPI library gives
ldap_sasl_
and on the credential cache I see two ticket for a ldap principal one with the realm and another one that looks like realm-less.
There is also a quite probably related syslog message (selinux disabled, keytab owned by openldap user):
kernel: [ 783.797967] audit(121051159
CVE References
Changed in openldap: | |
status: | New → Confirmed |
Changed in openldap: | |
status: | Fix Released → Confirmed |
status: | Confirmed → Fix Released |
I've just had a similar problem. It's caused by a conflict with AppArmor's slapd policy (in /etc/apparmor. d/usr.sbin. slapd).
I switched apparmor's policy to complain mode with aa-complain and it fixed the problem.