On 2023-07-05 11:18, dbarstis@nd.edu wrote:
Total newbie here so please be gentle. I'm trying to set up a simple ldap server that uses SASL and Kerberos for authentication. I built OpenLDAP --with-cyrus-sasl and --enable-spasswd. I have the service principal and testsaslauthd works. I used slapadd to build the initial config (from slapd.ldif) and ldapadd to define a rootdn and basedn (basically ou=people and ou=groups). Added a user (me) and a group.
You don't say what OS you are using. I am really only familiar with Debian/Ubuntu and if I build OpenLDAP I start from the source package and just add patches to that. This is just to explain the paths that I use in describing my configuration.
Oh, and it might make sense for you to just use the Symas packages if you can. Their builds are quite complete. Paths are different, i.e. /opt/symas/openldap as a base, but most everything else just follows.
I have a slapd.conf file at /usr/lib/sasl2 that defines keytab: krb5.keytab, mech_list: GSSAPI, pwcheck_method: saslauthd, saslauthd_path: /run/saslauthd/mux.
In Debian base distributions the SASL configuration for the slapd is in /etc/ldap/sasl2/slapd.conf. My version of this file contains:
mech_list: GSSAPI plain
You do not need saslauthd to authenticate to slapd. You need that only if you need to support simple binds to the directory and only then on the client system.
What you do need is a ldap/<fqdn> keytab. On Debian systems the location of the keytab is set in /etc/default/slapd. This file is a simple bash fragment and the relevant property to set is KRB5_KTNAME. Here is a copy of my configuration:
SLAPD_CONF=/etc/ldap/slapd.d SLAPD_USER="" SLAPD_GROUP="" SLAPD_SERVICES="ldap:///" SLAPD_SENTINEL_FILE=/etc/ldap/noslapd export KRB5_KTNAME=/etc/ldap/ldap-host.keytab export KRB5CCNAME=/run/service-ldap.tgt
The KRB5CCNAME is there for use by replication. And, if you are on a system with systemd you should be able to set these environment variables there.
Running pluginviewer, I see GSSAPI. Running ldapsearch ... supportedSASLMechanisms, it returns nothing. I've found websites that talk about adding sasl-realm <Kerberos-Realm> sasl-host <ldap-host> sasl-secprops none to slapd.conf. But this isn't the same slapd.conf I mentioned above correct? And since I used slapd.ldif to do the inital load, I don't have another slapd.conf.
How to I define these variables? Also, it looks like I need a direct mapping i.e. authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=com
These expressions are used to map the GSSAPI credential to an LDAP distinguished name. Here are some edited examples from my server that map host, ldap, service, and user principals into dn's.
olcAuthzRegexp: {0}"uid=host/(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///ou=net,dc=domain,dc=com??sub?krb5PrincipalName=host/$1@DOMAIN.COM" olcAuthzRegexp: {1}"uid=ldap/(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///ou=net,dc=domain,dc=com??sub?krb5PrincipalName=host/$1@DOMAIN.COM" olcAuthzRegexp: {2}"uid=service/(.*),cn=domain.com,cn=gssapi,cn=auth"
"ldap:///ou=auth,dc=domain,dc=com??sub?krb5PrincipalName=service/$1@DOMAIN.COM" olcAuthzRegexp: {4}"uid=(.*),cn=domain.com,cn=gssapi,cn=auth" "ldap:///dc=domain,dc=com??sub?krb5PrincipalName=$1@DOMAIN.COM"
Note, these are probably more complicated that you need since they perform an ldap search to find the dn. The associated entries in the directory need to have the krb5PrincipalName specified. For example:
$ ldapsearch uid=mac krb5principalname objectclass
dn: uid=mac,ou=people,dc=domain,dc=com objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson objectClass: krb5Principal krb5PrincipalName: mac@DOMAIN.COM
I haven't used the more simple form in a long time, but as I remember if the directory has a strict convention for where entries are you could use something like:
olcAuthzRegexp: {3}"uid=(.*),cn=domain.com,cn=gssapi,cn=auth" "uid=$1,ou=people,dc=domain,dc=com"
Note, that once you get principals mapped into dn's you will need to set ACLs to allow access to the entries in the directory. But, you can do that after you get the mapping working.
To get mapping working ldapwhoami is our friend. For example:
$ kinit mac Password for mac@DOMAIN.COM: $ ldapwhoami -H ldap://ldapserver SASL/GSSAPI authentication started SASL username: mac@DOMAIN.COM SASL SSF: 256 SASL data security layer installed. dn:uid=mac,ou=people,dc=domain,dc=com
If the mapping was failing I would have gotten a dn of uid=mac,cn=domain.com,cn=gssapi,cn=auth.
Where and how does that get defined? Any and all help would be greatly appreciated!
This gets defined in the cn=config branch of the directory. Because I started using OpenLDAP before cn=config existed I still use files base configuration, sort of. I dump the cn=config branch of the directory, edit the ldif, and then reload it with slapadd. Of course, the server has to be stopped and restarted, but in my case the load and restart is very fast so I don't mind.
Oh, and you can use slaptest to convert a slapd.conf configuration to a cn=config configuration. Take a look at that man page.
Hope this helps and that I didn't make too many mistakes to lead you astray.
Bill