Hello,
I'm setting up an openldap server for Kerberos (GSSAPI) authentication only. I'm using slapd-2.4.21 from Ubuntu 10.04.1.
It's basically working, and I had to do very little other than change export KRB5_KTNAME in /etc/default/slapd to point to the service keytab.
However, there are a couple of strange things which I wonder if someone could help me with.
(1) According to the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI then the authentication DN should be uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
However, running slapd in debug mode I see the cn=<realm> is missing. Here I have a ticket for inst/admin@WS.NSRC.ORG and run slapd -d 255:
... do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="inst/admin" slap_sasl_getdn: conn 1000 id=inst/admin [len=10] => ldap_dn2bv(16) <= ldap_dn2bv(uid=inst/admin,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=inst/admin,cn=GSSAPI,cn=auth
dnNormalize: <uid=inst/admin,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=inst/admin,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=inst/admin,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=inst/admin,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=inst/admin,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=inst/admin,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst/admin,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="inst/admin" authzid="inst/admin" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=inst/admin,cn=gssapi,cn=auth" sasl_ssf=56 ... ==> limits_get: conn=1000 op=3 self="uid=inst/admin,cn=gssapi,cn=auth" this="dc=ws,dc=nsrc,dc=org" ...
Now this works, if I change my ACL to
olcAccess: {0}to * by dn.regex="^uid=([^,]+)/admin,cn=gssapi,cn=auth$" manage by users read
However, I wonder why the realm is missing, and whether it can be included (because in future, if I end up with a cross-realm setup, I'll want to see the realm for authorization)
Is this a documentation error, or is there some configuration option which needs setting to preserve the realm?
(2) I would like to be able to do ldapsearch without specifying -Y GSSAPI explicitly. However if I omit it, the client picks DIGEST-MD5 instead (which isn't much use, since I have no passwords in the database)
# ldapsearch -b "ds=ws,dc=nsrc,dc=org" SASL/DIGEST-MD5 authentication started Please enter your password:
Adding -d 255 I see that the server is offering these:
... ldap_sasl_interactive_bind_s: server supports: NTLM DIGEST-MD5 GSSAPI CRAM-MD5 ldap_int_sasl_bind: NTLM DIGEST-MD5 GSSAPI CRAM-MD5 ...
How can I configure the server not to offer the other authentication mechanisms, or else to put GSSAPI at the front of the list?
Thanks,
Brian.
Supplementary question: I tried to set minssf so as to require encryption, like this:
# ldapmodify -Y EXTERNAL -H ldapi:/// <<EOS dn: cn=config replace: olcSaslRealm olcSaslRealm: WS.NSRC.ORG - replace: olcSaslSecProps olcSaslSecProps: noanonymous,noplain,minssf=112 EOS
Unfortunately I now seem to have locked myself out from using the EXTERNAL mechanism:
# ldapsearch -s base -b "cn=config" -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak
So: (a) it would be nice to know how to recover from this. If I stop slapd and edit /etc/ldap/slapd.d/cn=config.ldif directly, that seems to be OK, but are there any risks in directly manipulating the config in this way?
(b) how can I enforce encryption for Kerberos users without locking myself out of EXTERNAL?
Thanks,
Brian.
Brian Candler wrote:
Supplementary question: I tried to set minssf so as to require encryption, like this:
# ldapmodify -Y EXTERNAL -H ldapi:///<<EOS dn: cn=config replace: olcSaslRealm olcSaslRealm: WS.NSRC.ORG
replace: olcSaslSecProps olcSaslSecProps: noanonymous,noplain,minssf=112 EOS
Unfortunately I now seem to have locked myself out from using the EXTERNAL mechanism:
# ldapsearch -s base -b "cn=config" -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak
So: (a) it would be nice to know how to recover from this. If I stop slapd and edit /etc/ldap/slapd.d/cn=config.ldif directly, that seems to be OK, but are there any risks in directly manipulating the config in this way?
The main risk is that if you enter any typos or syntax errors, slapd will refuse to start. You should probably use slapmodify instead, so at least you'll get some syntax checking.
(b) how can I enforce encryption for Kerberos users without locking myself out of EXTERNAL?
Read the slapd-config(5) manpage, olcLocalSSF.
On Tue, Dec 28, 2010 at 02:31:44PM -0800, Howard Chu wrote:
# ldapsearch -s base -b "cn=config" -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak
So: (a) it would be nice to know how to recover from this. If I stop slapd and edit /etc/ldap/slapd.d/cn=config.ldif directly, that seems to be OK, but are there any risks in directly manipulating the config in this way?
The main risk is that if you enter any typos or syntax errors, slapd will refuse to start. You should probably use slapmodify instead, so at least you'll get some syntax checking.
That's not in Debian/Ubuntu:
root@noc:~# man slapmodify No manual entry for slapmodify root@noc:~# dpkg-query -L slapd | grep modify root@noc:~# apt-cache search slapmodify root@noc:~#
I can't even find it in the latest release (openldap-2.4.23) source tarball.
$ grep -R slapmodify . $ find . -name 'slapmod*' $
I see there is slapadd though. Is slapmodify a recent addition?
Regards,
Brian.
Am Tue, 28 Dec 2010 09:41:33 +0000 schrieb Brian Candler B.Candler@pobox.com:
Supplementary question: I tried to set minssf so as to require encryption, like this:
# ldapmodify -Y EXTERNAL -H ldapi:/// <<EOS dn: cn=config replace: olcSaslRealm olcSaslRealm: WS.NSRC.ORG
replace: olcSaslSecProps olcSaslSecProps: noanonymous,noplain,minssf=112 EOS
Unfortunately I now seem to have locked myself out from using the EXTERNAL mechanism:
# ldapsearch -s base -b "cn=config" -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak
The default ssf of ldapi is 71, but you may change localSSF in slapd.conf(5). [...]
-Dieter
On Wed, Dec 29, 2010 at 07:57:43AM +0100, Dieter Kluenter wrote:
The default ssf of ldapi is 71, but you may change localSSF in slapd.conf(5). [...]
Thank you, that is very clear.
Having changed that, I can use EXTERNAL with minssf=112, but not GSSAPI. I find that if I set minssf=56 it's fine, but at minssf=57 it isn't.
It looks like this is a fundamental limitation of the GSSAPI: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-September/000628.html http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-September/000635.html
FYI, here's what I see with minssf=57 (the 'No such attribute' error is somewhat confusing)
root@noc:~# ldapsearch ldap_sasl_interactive_bind_s: No such attribute (16) root@noc:~# ldapsearch -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech GSSAPI is too weak
Regards,
Brian.
Am Wed, 29 Dec 2010 16:50:17 +0000 schrieb Brian Candler B.Candler@pobox.com:
On Wed, Dec 29, 2010 at 07:57:43AM +0100, Dieter Kluenter wrote:
The default ssf of ldapi is 71, but you may change localSSF in slapd.conf(5). [...]
Thank you, that is very clear.
Having changed that, I can use EXTERNAL with minssf=112, but not GSSAPI. I find that if I set minssf=56 it's fine, but at minssf=57 it isn't.
It looks like this is a fundamental limitation of the GSSAPI: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-September/000628.html http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-September/000635.html
FYI, here's what I see with minssf=57 (the 'No such attribute' error is somewhat confusing)
root@noc:~# ldapsearch ldap_sasl_interactive_bind_s: No such attribute (16) root@noc:~# ldapsearch -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech GSSAPI is too weak
That is because Kerberos DES, und thus GSSAPI, only has a security strength factor of 56.
-Dieter
Dieter Kluenter wrote:
Am Wed, 29 Dec 2010 16:50:17 +0000 schrieb Brian CandlerB.Candler@pobox.com:
On Wed, Dec 29, 2010 at 07:57:43AM +0100, Dieter Kluenter wrote:
The default ssf of ldapi is 71, but you may change localSSF in slapd.conf(5). [...]
Thank you, that is very clear.
Having changed that, I can use EXTERNAL with minssf=112, but not GSSAPI. I find that if I set minssf=56 it's fine, but at minssf=57 it isn't.
It looks like this is a fundamental limitation of the GSSAPI: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-September/000628.html http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2006-September/000635.html
FYI, here's what I see with minssf=57 (the 'No such attribute' error is somewhat confusing)
root@noc:~# ldapsearch ldap_sasl_interactive_bind_s: No such attribute (16) root@noc:~# ldapsearch -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL(-15): mechanism too weak for this user: mech GSSAPI is too weak
That is because Kerberos DES, und thus GSSAPI, only has a security strength factor of 56.
But this value is pure fiction, it's an arbitrary value hardcoded into the SASL gssapi plugin. Generally Kerberos is using triple-DES today, or AES.
On Tue, Dec 28, 2010 at 09:26:56AM +0000, Brian Candler wrote:
(1) According to the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI then the authentication DN should be uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
However, running slapd in debug mode I see the cn=<realm> is missing. Here I have a ticket for inst/admin@WS.NSRC.ORG and run slapd -d 255:
Even more strangely, if I set olcSaslRealm to some junk, e.g.
ldapmodify -Y EXTERNAL -H ldapi:/// <<EOS dn: cn=config replace: olcSaslRealm olcSaslRealm: WS.NSRC.ORGZ EOS
Then the junk is passed through into the authentication DN, even though the Kerberos ticket is from a different realm (WS.NSRC.ORG)
do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="inst/admin" slap_sasl_getdn: conn 1000 id=inst/admin [len=10] => ldap_dn2bv(16) <= ldap_dn2bv(uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth
dnNormalize: <uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="inst/admin@WS.NSRC.ORGZ" authzid="inst/admin@WS.NSRC.ORGZ" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth" sasl_ssf=56
It's as if the realm from the client is being ignored completely, and replaced by that from olcSaslRealm. Is that correct??
I notice some potential Kerberos fixes in ITS: ITS#6091 \ ITS#6092 | merged in 2.4.17 according to http://www.openldap.org/software/release/changes.html ITS#6093 / ITS#6225 -- outstanding
but I don't see any specific reference to what I'm seeing.
Regards,
Brian.
Brian Candler wrote:
Hello,
I'm setting up an openldap server for Kerberos (GSSAPI) authentication only. I'm using slapd-2.4.21 from Ubuntu 10.04.1.
It's basically working, and I had to do very little other than change export KRB5_KTNAME in /etc/default/slapd to point to the service keytab.
However, there are a couple of strange things which I wonder if someone could help me with.
(1) According to the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI then the authentication DN should be uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
However, running slapd in debug mode I see the cn=<realm> is missing.
That's normal. The SASL library doesn't provide the realm name when it is equal to the default realm. This has been true of Cyrus SASL for probably the past dozen years. Read the Cyrus SASL documentation.
(2) I would like to be able to do ldapsearch without specifying -Y GSSAPI explicitly. However if I omit it, the client picks DIGEST-MD5 instead (which isn't much use, since I have no passwords in the database)
Configure a sasl/slapd.conf with the options you want. Read the Cyrus SASL documentation.
On Tue, Dec 28, 2010 at 02:28:40PM -0800, Howard Chu wrote:
(1) According to the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI then the authentication DN should be uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
However, running slapd in debug mode I see the cn=<realm> is missing.
That's normal. The SASL library doesn't provide the realm name when it is equal to the default realm. This has been true of Cyrus SASL for probably the past dozen years. Read the Cyrus SASL documentation.
Perhaps the openldap documentation could put the cn=<realm> section in square brackets to show it is not always present:
| For the purposes of authentication and authorization, slapd(8) associates an | authentication request DN of the form: | | uid=<primary[/instance]>[,cn=<realm>],cn=gssapi,cn=auth
Furthermore, the example which follows this is apparently incorrect:
| Continuing our example, a user with the Kerberos principal kurt@EXAMPLE.COM | would have the associated DN: | | uid=kurt,cn=example.com,cn=gssapi,cn=auth | | and the principal ursula/admin@FOREIGN.REALM would have the associated DN: | | uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth
That is, if what you're saying is true and kurt is in the default realm, there would be no ",cn=example.com"
However I've done some testing, and the interaction between the krb5 default realm, the olcSaslRealm and the actual realm of the request appears to be rather bizarre.
The client has a ticket for inst@WS.NSRC.ORG, and here are the variations I've tried on the server side.
Config 1 -------- oclSaslRealm: WS.NSRC.ORG krb5.conf default realm: WS.NSRC.ORG result: auth is successful, DN is uid=inst,cn=ws.nsrc.org,cn=gssapi,cn=auth
This is fine, but it disagrees with your comment that "The SASL library doesn't provide the realm name when it is equal to the default realm"
Config 2 -------- olcSaslRealm: BAR.NSRC.ORG krb5.conf default realm: WS.NSRC.ORG result: auth is successful, DN is uid=inst,cn=bar.nsrc.org,cn=gssapi,cn=auth
Surely this is wrong? The ticket had realm ws.nsrc.org! bar.nsrc.org is just a value copied from the olcSaslRealm.
Am I being blind, or should I raise this as a bug in ITS?
Config 3 -------- olcSaslRealm: WS.NSRC.ORG krb5.conf default realm: FOO.NSRC.ORG result: auth fails!
# ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table entry not found)
Now this seems odd; presumably slapd is only trying to use a keytab entry of ldap/noc.ws.nsrc.org@FOO.NSRC.ORG (which doesn't exist)
My understanding is that modern kerberos apps should just try all keys in the keytab until they find one which decrypts the ticket. http://mailman.mit.edu/pipermail/kerberos/2010-December/016797.html
But in any case, shouldn't it use olcSaslRealm in preference to the krb5.conf default realm? (I'd expect the default realm to be used if olcSaslRealm were empty though)
I'm inclined to raise this in ITS too, or am I mistaken?
Config 4 -------- olcSaslRealm: unset krb5.conf default realm: WS.NSRC.ORG result: auth is successful, DN is uid=inst,cn=gssapi,cn=auth
So the realm is being omitted from the bind DN only when olcSaslRealm is not present
Config 5 -------- olcSaslRealm: unset krb5.conf default realm: FOO.NSRC.ORG result: as per config 3 (auth fail, "Key table entry not found")
(2) I would like to be able to do ldapsearch without specifying -Y GSSAPI explicitly. However if I omit it, the client picks DIGEST-MD5 instead (which isn't much use, since I have no passwords in the database)
Configure a sasl/slapd.conf with the options you want. Read the Cyrus SASL documentation.
OK, I got this in the end, although more thanks to Google than to Cyrus documentation. For benefit of the archives:
# cat /etc/ldap/sasl2/slapd.conf mech_list: gssapi external #
Regards,
Brian.
Brian Candler B.Candler@pobox.com writes:
Config 3
olcSaslRealm: WS.NSRC.ORG krb5.conf default realm: FOO.NSRC.ORG result: auth fails!
# ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table entry not found)
Now this seems odd; presumably slapd is only trying to use a keytab entry of ldap/noc.ws.nsrc.org@FOO.NSRC.ORG (which doesn't exist)
My understanding is that modern kerberos apps should just try all keys in the keytab until they find one which decrypts the ticket. http://mailman.mit.edu/pipermail/kerberos/2010-December/016797.html
Cyrus SASL doesn't. This is a long-standing bug in Cyrus SASL that we patch locally at Stanford. (It's a simple one-line patch.) It really needs to be fixed upstream in Cyrus SASL.
But in any case, shouldn't it use olcSaslRealm in preference to the krb5.conf default realm? (I'd expect the default realm to be used if olcSaslRealm were empty though)
I don't believe there's any way to pass that information down into Cyrus SASL, so there isn't anything OpenLDAP can do. Cyrus SASL forces using the hostname unless you patch it to not be stupid.
On Wed, Dec 29, 2010 at 10:21:28AM -0800, Russ Allbery wrote:
My understanding is that modern kerberos apps should just try all keys in the keytab until they find one which decrypts the ticket. http://mailman.mit.edu/pipermail/kerberos/2010-December/016797.html
Cyrus SASL doesn't. This is a long-standing bug in Cyrus SASL that we patch locally at Stanford. (It's a simple one-line patch.) It really needs to be fixed upstream in Cyrus SASL.
Have you got the one-line patch? Is there a ticket open for it upstream?
But in any case, shouldn't it use olcSaslRealm in preference to the krb5.conf default realm? (I'd expect the default realm to be used if olcSaslRealm were empty though)
I don't believe there's any way to pass that information down into Cyrus SASL, so there isn't anything OpenLDAP can do. Cyrus SASL forces using the hostname unless you patch it to not be stupid.
I don't mind SASL using the hostname (I'd expect olcSaslHost to take preference, but haven't tested this (*)). It bothers me a bit that it ignores the olcSaslRealm and just picks the default realm instead.
What bothers me greatly is that when a client connects the Kerberos realm is lost, and olcSaslRealm is being pasted in unconditionally for authorization. This to me seems like a huge security hole: superuser@FOREIGN.REALM is currently treated the same as superuser@LOCAL.REALM in ACLs.
Regards,
Brian.
(*) But testing does suggest that clients canonicalise the hostname. I have pointed them to ldap.ws.nsrc.org, but they get a ticket for noc.ws.nsrc.org (which is the name which the reverse DNS points to)
On Wed, Dec 29, 2010 at 05:40:05PM +0000, Brian Candler wrote:
However I've done some testing, and the interaction between the krb5 default realm, the olcSaslRealm and the actual realm of the request appears to be rather bizarre.
I found a hint here: http://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/gssapi.php
"if for example you're using Kerberos, the Cyrus SASL library strips out the @REALM from your identity if you are in the same realm as the server"
This begs the question of what the "server's realm" actually means, and my previous tests suggest this is just the default realm from krb5.conf. The oclSaslRealm is a string which is pasted back in if the @REALM has been stripped out.
To test this properly, I had to set up an environment with cross-realm auth. The two realms are WS.NSRC.ORG and REALM3.WS.NSRC.ORG
The LDAP server has default_realm=WS.NSRC.ORG and has oclSaslRealm set to EXAMPLE.COM
(1) If the client has a ticket for inst@WS.NSRC.ORG then I get authDN="uid=inst,cd=example.com,cn=gssapi,cn=auth"
(2) If the client has a ticket for student@REALM3.WS.NSRC.ORG then I get authDN="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth"
The server logs (slapd -d 255) for these two cases are shown below.
My result for case (2) is in disagreement with the examples at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI
which suggests I should have seen
uid=student,cn=realm3.ws.nsrc.org,cn=gssapi,cn=auth
Regards,
Brian.
do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="inst" slap_sasl_getdn: conn 1000 id=inst [len=4] => ldap_dn2bv(16) <= ldap_dn2bv(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
dnNormalize: <uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=inst,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=inst,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=inst,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="inst@EXAMPLE.COM" authzid="inst@EXAMPLE.COM" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=inst,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56
do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="student@REALM3.WS.NSRC.ORG" slap_sasl_getdn: conn 1000 id=student@REALM3.WS.NSRC.ORG [len=26] => ldap_dn2bv(16) <= ldap_dn2bv(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
dnNormalize: <uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="student@REALM3.WS.NSRC.ORG" authzid="student@REALM3.WS.NSRC.ORG" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56
openldap-technical@openldap.org
-
Brian Candler -
Dieter Kluenter -
Howard Chu -
Russ Allbery