Hello,

I try to figure out which ACL I need to get the rewriting of the sasl-username working.

I have in my slapd.conf the following lines: ---------- authz-regexp uid=(.+),cn=gssapi,cn=auth ldap:///dc=example,dc=net??sub?(uid=$1) -----------

If I do a "ldapwhoami" without any ACL I get what I want:

----------- ptau@provider-stat:~$ ldapwhoami SASL/GSSAPI authentication started SASL username: ptau@EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. dn:uid=ptau,ou=users,dc=example,dc=net -----------

As soon as I include my ACLs I get: ------------ ptau@provider-stat:~$ ldapwhoami SASL/GSSAPI authentication started SASL username: ptau@EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. dn:uid=ptau,cn=gssapi,cn=auth ------------ So the rewrite of the DN is not working anymore with ACLs. Here are the relevant part of my ACLs. (It's at the beginning of the ACLs) ------------ limits dn.exact="uid=repl-user,ou=users,dc=example,dc=net" size=unlimited time=unlimited

limits dn.exact="cn=kdc,ou=kerberos-adm,dc=example,dc=net" size=unlimited time=unlimited

limits dn.exact="cn=kadmin,ou=kerberos-adm,dc=example,dc=net" size=unlimited time=unlimited

access to dn.base="" by * read

access to dn.base="cn=subSchema" by * read

access to * by dn.exact="uid=sssd-user,ou=users,dc=example,dc=net" read by dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" write by dn.exact="uid=repl-user,ou=users,dc=example,dc=net" read by dn.exact="cn=kdc,ou=kerberos-adm,dc=example,dc=net" write by dn.exact="cn=kadmin,ou=kerberos-adm,dc=example,dc=net" write by dn.regex="(.+),cn=gssapi,cn=auth" auth by * break ------------

As soon as I remove the line: ------------ by dn.regex="(.+),cn=gssapi,cn=auth" auth ------------ and change the last line to:

------------- by * auth -------------

But this will make all other ACLs, after this ACLs, useless.

I tried so far: by ssf=256 auth by sasl_ssf=256 auth non of the above is working

So it's definitely an ACL issue, but how do I solve it? The log-File is giving me the following output: -------------- Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 fd=20 ACCEPT from IP=192.168.56.81:50728 (IP=0.0.0.0:636) Dez 20 19:22:46 provider-stat ldapwhoami[2047]: GSSAPI client step 1 Dez 20 19:22:46 provider-stat ldapwhoami[2047]: GSSAPI client step 1 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 fd=20 TLS established tls_ssf=256 ssf=256 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=0 BIND dn="" method=163 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Dez 20 19:22:46 provider-stat ldapwhoami[2047]: GSSAPI client step 1 Dez 20 19:22:46 provider-stat slapd[2038]: connection_input: conn=1004 deferring operation: binding Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=1 BIND dn="" method=163 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Dez 20 19:22:46 provider-stat ldapwhoami[2047]: GSSAPI client step 2 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=2 BIND dn="" method=163 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=2 BIND authcid="ptau" authzid="ptau" Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=2 BIND dn="uid=ptau,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=256 ssf=256 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=2 RESULT tag=97 err=0 text= Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.3 Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=3 WHOAMI Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=3 RESULT oid= err=0 text= Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 op=4 UNBIND Dez 20 19:22:46 provider-stat slapd[2038]: conn=1004 fd=20 closed Dez 20 19:22:46 provider-stat ldapwhoami[2047]: DIGEST-MD5 common mech free --------------

I think it had something to do with what I found in the manpage: ------------------- Some internal operations and some controls require specific access privileges. The authzID mapping and the proxyAuthz control require auth (=x) privileges on all the attributes that are present in the search filter of the URI regexp maps (the right-hand side of the authz-regexp directives). Auth (=x) privileges are also required on the authzTo attribute of the authorizing identity and/or on the au‐ thzFrom attribute of the authorized identity. In general, when an internal lookup is performed for authentication or authorization purposes, search-specific privileges (see the access requirements for the search operation illustrated above) are relaxed to auth. ------------------- But my problem here is, I'm not a native English speaker and it's hard for me to figure out what the write is telling me here :-(

Any solution for the right ACL to solve the problem?

Greetings

Stefan