openldap24-server and GSSAPI

K

kshots

I've been poking at this for a while... basically, I've got a server I've migrated from an older system that worked (copied the slapd.conf file over) and ran with it for several months before realizing that kerberos auth wasn't working... and all my local network clients were working off of cached credentials because they couldn't authenticate to my ldap server. Time to solve that...

Current state:
Machine is running FreeBSD 13.1-RELEASE under a jail, using the ports version of openldap24-server with GSSAPI enabled.
Within the jail, I have /etc/rc.conf with the following relevant contents:
Code: 
slapd_enable="YES"
slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap://10.4.12.23"'
slapd_sockets="/var/run/openldap/ldapi"
slapd_krb5_ktname="FILE:/etc/krb5.keytab"
saslauthd_enable="YES"
saslauthd_flags="-a kerberos5"
I have installed cyrus-sasl2-saslauthd, and have the following under /usr/local/lib/sasl2/slapd.conf
Code: 
mech_list: plain GSSAPI
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
I've also changed group ownership of /var/run/saslauthd to ldap and granted read and execute rights to that group. In addition, I have the following in my keytab as defined in the rc.conf above:
Code: 
root@ldap1:/usr/ports # ktutil -k /etc/krb5.keytab list
/etc/krb5.keytab:

Vno  Type                     Principal                                 Aliases
 10  aes256-cts-hmac-sha1-96  host/ldap1.example.com@EXAMPLE.COM
  9  aes256-cts-hmac-sha1-96  ldap/ldap1.example.com@EXAMPLE.COM
The keytab is granted read access to the ldap group. I have the following in my /usr/local/etc/openldap/slapd.conf:
Code: 
sasl-realm    EXAMPLE.COM
sasl-host    ldap1.example.com
authz-policy    from
authz-regexp    uid=([^/]*),cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
        uid=$1,ou=Users,dc=example,dc=com,o="Example Org"
... and yet, when I attempt to run ldapwhoami -H ldap://ldap1.example.com -Y GSSAPI (after running kinit), I get the following:
Code: 
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
    additional info: SASL(-1): generic failure: GSSAPI Error:  No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown)
From what I've been reading, this is usually caused by the server not having access to the keytab... but from the above, I'm fairly sure it does (unless the line slapd_krb5_ktname="FILE:/etc/krb5.keytab" is being ignored... is there a way to check that?)
EDIT: For reference, here's what I get when I run klist:
Code: 
Ticket cache: FILE:/tmp/krb5cc_1500_mhG6Qa
Default principal: myuser@EXAMPLE.COM

Valid starting       Expires              Service principal
10/24/2022 13:37:08  10/25/2022 05:37:08  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    renew until 10/25/2022 13:37:52
10/24/2022 13:37:15  10/25/2022 05:37:08  nfs/mynfsserver.example.com@EXAMPLE.COM
    renew until 10/25/2022 13:37:52
10/24/2022 14:09:06  10/25/2022 05:37:08  ldap/ldap1.example.com@EXAMPLE.COM
    renew until 10/25/2022 13:37:52

EDIT2: A relevant log snippet may also help:
Code: 
Oct 24 14:41:57 jailer.example.com slapd[4793]: conn=1086 fd=12 ACCEPT from IP=10.4.12.200:37678 (IP=10.4.12.23:389)
Oct 24 14:41:57 jailer.example.com slapd[4793]: conn=1086 op=0 BIND dn="" method=163
Oct 24 14:41:57 jailer.example.com slapd[4793]: SASL [conn=1086] Failure: GSSAPI Error:  No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown)
Oct 24 14:41:57 jailer.example.com slapd[4793]: conn=1086 op=0 RESULT tag=97 err=80 text=SASL(-1): generic failure: GSSAPI Error:  No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown)
Oct 24 14:41:57 jailer.example.com slapd[4793]: conn=1086 op=1 UNBIND
Oct 24 14:41:57 jailer.example.com slapd[4793]: conn=1086 fd=12 closed
That's what I get when I run the ldapwhoami query.
 
Code: 
root@ldap1:/usr/ports # ls -l /etc/krb5.keytab
-rw-r-----  1 ldap  ldap  200 Oct 20 18:29 /etc/krb5.keytab
 
I would suggest leaving the permissions on /etc/krb5.keytab on root:wheel and use an ACL to add only read access for the ldap user (and any other user that might need access to an SPN). Also check the user (saslauth?) saslauthd(8) is running on. It would require read access too. Not really sure if LDAP itself requires the read access though, now that saslauthd(8) is handling the authentication.

In any case, nobody else but root should have write access to /etc/krb5.keytab. Nobody else should be able to modify those keys. You don't want to give anyone read access to them either (but these services require it to function).
 
Just verified that saslauthd is running as root, so should have access to the keytab. I also reverted ownership back to root - having it owned by ldap to begin with was a debugging step that proved ineffective and needed to be reverted anyways. I'll do some reading on the concept behind the ACL - I'm only familiar with user/group ownership for file access, not ACL access.
 
After doing some reading on ACL and modifying my filesystem to support it, I have the following ACL on /etc/krb5.keytab:
Code: 
# file: /etc/krb5.keytab
# owner: root
# group: wheel
user::rw-
user:ldap:r--
group::r--
mask::r--
other::---
... still doesn't work, though
 
You must log in or register to reply here.
Back
Top