On 2023-07-05 11:18, dbars...@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: m...@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 m...@domain.com:
$ ldapwhoami -H ldap://ldapserver
SASL/GSSAPI authentication started
SASL username: m...@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

--
"What can be asserted without evidence can also be dismissed without
 evidence."
    Christopher Hitchens

Reply via email to