Dan,
Here are version details: openldap 2.4-39 RHEL 6.5 cyrus-sasl and cyrus-sasl-gssapi 2.1.23-15 krb5-libs 1.10.3-42
The tests I'm running (ldapclient) are on the same system as is slapd.
It appears that cross-realm authentication is problematic. In the following results, "success" means that the search specified by the regex occurred and the identity was remapped. Both commands used GSSAPI (-Y for ldapwhoami, -M for slapauth):
krb5.conf default TEST.NET.ISC.UPENN.EDU
ldapwhoami -R TEST.NET... success ldapwhomai no -R success slapauth -R TEST.NET... success slapauth no realm fail
krb5.conf default UPENN.EDU
ldapwhoami -R TEST.NET... fail ldapwhoami no realm fail slapauth -R TEST.NET... success slapauth no realm specified fail
so: slapauth appears to work if a realm is explicitly specified with -R (either cross-realm or within realm), but won't remap if the realm isn't specified. ldapwhoami (and ldapsearch) works within a realm whether or not the realm is specified with -R; but won't remap if -R specifies a different realm.
Here's output from slapauth that shows the different behavior when the realm is specified or not. Note that in this case, the
]$ sudo slapauth -d 4 -M GSSAPI -R TEST.NET.ISC.UPENN.EDU netmon 55e45abb mdb_db_open: "dc=upenn,dc=edu" 55e45abb slap_sasl_getdn: conn 18446744073709551615 id=netmon [len=6] 55e45abb [rw] authid: "uid=netmon,cn=test.net.isc.upenn.edu,cn=gssapi,cn=auth" -> "ldap:///ou=entities,dc=upenn,dc=edu??one?(userPassword={SASL}netmon@TEST.NET.ISC.UPENN.EDU)" 55e45abb mdb_idl_fetch_key: [b49d1940] 55e45abb mdb_idl_fetch_key: [4f7f6931] 55e45abb send_ldap_result: err=0 matched="" text="" ID: <netmon> check succeeded authcID: <uid=netmon,ou=entities,dc=upenn,dc=edu>
$ sudo slapauth -d 4 -M GSSAPI netmon 55e45ac6 mdb_db_open: "dc=upenn,dc=edu" 55e45ac6 slap_sasl_getdn: conn 18446744073709551615 id=netmon [len=6] 55e45ac6 [rw] authid: "uid=netmon,cn=gssapi,cn=auth" -> "uid=netmon,cn=gssapi,cn=auth" ID: <netmon> check succeeded authcID: <uid=netmon,cn=gssapi,cn=auth>
Peter ________________________________________ From: Dan White [dwhite@olp.net] Sent: Sunday, August 30, 2015 10:09 AM To: Peter Heinemann Cc: openldap-technical@openldap.org Subject: Re: authz-regexp behavior with GSSAPI
On 08/26/15 12:51 +0000, Peter Heinemann wrote:
I am trying to figure out different behaviors with authz-regexp in slapd.conf.
In production is:
sasl-host pennid.upenn.edu sasl-realm UPENN.EDU authz-regexp uid=(.*),cn=UPENN.EDU,cn=gssapi,cn=auth ldap:///ou=entities,dc=upenn,dc=edu??one?(userPassword={SASL}$1@UPENN.EDU)
and the authentication mapping works as desired; the user@realm gets mapped to the just the username and the search succeeds:
ldapwhoami -Y GSSAPI -U netmon -H ldaps://pennid.upenn.edu SASL/GSSAPI authentication started SASL username: netmon@UPENN.EDU SASL SSF: 56 SASL data security layer installed. dn:uid=netmon,ou=entities,dc=upenn,dc=edu
However, on development in a different kerberos realm, that statement will not map properly. The mapping doesn't take place, so user@realm is used for the (unsuccessful) search:
sasl-host pennid-dev.net.isc.upenn.edu sasl-realm TEST.NET.ISC.UPENN.EDU authz-regexp uid=(.*),cn=TEST.NET.ISC.UPENN.EDU,cn=gssapi,cn=auth ldap:///ou=entities,dc=upenn,dc=edu??one?(userPassword={SASL}$1@TEST.NET.ISC.UPENN.EDU)
no mapping takes place:
ldapwhoami -Y GSSAPI -U netmon -H ldaps://pennid-dev.net.isc.upenn.edu SASL/GSSAPI authentication started SASL username: netmon@TEST.NET.ISC.UPENN.EDU SASL SSF: 56 SASL data security layer installed. dn:uid=netmon@test.net.isc.upenn.edu,cn=test.net.isc.upenn.edu,cn=gssapi,cn=auth
However, a change to the regexp on the development system will cause mapping to work there:
authz-regexp uid=(.*)@TEST.NET.ISC.UPENN.EDU,cn=TEST.NET.ISC.UPENN.EDU,cn=gssapi,cn=auth ldap:///ou=entities,dc=upenn,dc=edu??one?(userPassword={SASL}$1@TEST.NET.ISC.UPENN.EDU)
$ ldapwhoami -Y GSSAPI -U netmon -H ldaps://pennid-dev.net.isc.upenn.edu SASL/GSSAPI authentication started SASL username: netmon@TEST.NET.ISC.UPENN.EDU SASL SSF: 56 SASL data security layer installed. dn:uid=netmon,ou=entities,dc=upenn,dc=edu
But a similar regexp in production will not map properly:
Can anyone shed light on the different behavior?
- only the authz-regexp has been modified
- slapd was restarted after the changes.
Any differences in your /etc/krb5.conf? What is your default realm? Any differences in the libraries you're using (cyrus-sasl and kerberos)?
-- Dan White dwhite@olp.net