Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
KR
--On Tuesday, January 23, 2007 4:33 PM -0500 Kenneth Rogers kenneth.rogers@gmail.com wrote:
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
Well, are you mapping the users to an entry in the server? If yes, then use that DN.
If not, then use the SASL authz ID. The logs are generally pretty clear at loglevel 256 what DN is being used.
For example:
Jan 23 14:29:00 ldap1 slapd[22096]: conn=11888542 op=2 BIND authcid="webauth/proxy.stanford.edu@stanford.edu" authzid="webauth/proxy.stanford.edu@stanford.edu"
So here's the authz DN (webauth/proxy.stanford.edu@stanford.edu).
Jan 23 14:29:00 ldap1 slapd[22096]: conn=11888542 op=2 BIND dn="cn=proxy,cn=webauth,cn=applications,dc=stanford,dc=edu" mech=GSSAPI ssf=56
And here's the DN of what I map it to:
cn=proxy,cn=webauth,cn=applications,dc=stanford,dc=edu
In case you haven't played with mappings, here's how the mapping is done:
sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu
And this is what the internal entry looks like:
ldap1:~> lsearch cn=proxy dn: cn=proxy,cn=webauth,cn=applications,dc=stanford,dc=edu objectClass: applicationProcess objectClass: suApplication objectClass: krb5Principal cn: proxy description: webauth access for proxy.stanford.edu krb5PrincipalName: webauth/proxy.stanford.edu@stanford.edu
Just to give you some thoughts to ponder. ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Kenneth Rogers wrote:
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
KR
Use the LDAP WhoAmI extended operation. That's what the ldapwhoami commandline tool does.
On Jan 23, 2007, at 1:33 PM, Kenneth Rogers wrote:
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
Would you be looking for something like int ldap_whoami_s(LDAP *, struct berval **authzid, 0, 0) ?
Donn Cave, donn@u.washington.edu
I think that's exactly what I was looking for, just didn't know what it was called.
Thanks
On 1/23/07, Donn Cave donn@u.washington.edu wrote:
On Jan 23, 2007, at 1:33 PM, Kenneth Rogers wrote:
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
Would you be looking for something like int ldap_whoami_s(LDAP *, struct berval **authzid, 0, 0) ?
Donn Cave, donn@u.washington.edu
Am Dienstag, 23. Januar 2007 22:33 schrieb Kenneth Rogers:
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
sasl returns an authentication string something like uid=<user>,cn=<realm>,cn=<mechanism>,cn=auth this string can be mapped to an entry, see the authz-regexp directive in slapd.conf(5).
-Dieter
Thanks,
I guess I wasn't clear enough, I'm working on the client and need to get the DN from the server after performing a GSSAPI bind.
ldap_whoami_s(...) looks like it should work, although right now I'm getting an LDAP_DECODING_ERROR (-4) from it, and I don't know why.
Any ideas what causes that error. The client is using openldap 2.3.24 on a linux system, and the server is Windows 2000 Active Directory.
KR
On 1/24/07, Dieter Klünter dieter@dkluenter.de wrote:
Am Dienstag, 23. Januar 2007 22:33 schrieb Kenneth Rogers:
Hi,
After a successful GSSAPI binding, is there an easy way to get the DN for that user from the server?
sasl returns an authentication string something like uid=<user>,cn=<realm>,cn=<mechanism>,cn=auth this string can be mapped to an entry, see the authz-regexp directive in slapd.conf(5).
-Dieter
-- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
On Jan 24, 2007, at 7:50 AM, Kenneth Rogers wrote:
Thanks,
I guess I wasn't clear enough, I'm working on the client and need to get the DN from the server after performing a GSSAPI bind.
ldap_whoami_s(...) looks like it should work, although right now I'm getting an LDAP_DECODING_ERROR (-4) from it, and I don't know why.
This error means the library was unable to decode the response PDU.
Any ideas what causes that error.
Most likely a malformed response PDU.
The client is using openldap 2.3.24 on a linux system, and the server is Windows 2000 Active Directory.
You should verify the server in question supports the LDAP Whoami? operation (RFC 4532). If the server doesn't support this, you might see if the server supports authorization identity controls (RFC 3829). Otherwise, you might see if the server supports some other means for obtaining the desired information. A forum about AD would be an appropriate place to ask such questions.
-- Kurt
KR
On 1/24/07, Dieter Klünter dieter@dkluenter.de wrote:
Am Dienstag, 23. Januar 2007 22:33 schrieb Kenneth Rogers:
Hi,
After a successful GSSAPI binding, is there an easy way to get
the DN
for that user from the server?
sasl returns an authentication string something like uid=<user>,cn=<realm>,cn=<mechanism>,cn=auth this string can be mapped to an entry, see the authz-regexp directive in slapd.conf(5).
-Dieter
-- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
-- "Linux doesn't exist." -- Kieren O'Shaghnessy (Director of SCO Australia)
On Jan 24, 2007, at 7:50 AM, Kenneth Rogers wrote:
I guess I wasn't clear enough, I'm working on the client and need to get the DN from the server after performing a GSSAPI bind.
ldap_whoami_s(...) looks like it should work, although right now I'm getting an LDAP_DECODING_ERROR (-4) from it, and I don't know why.
Any ideas what causes that error. The client is using openldap 2.3.24 on a linux system, and the server is Windows 2000 Active Directory.
Oh. Well, you might ask on some other forum whether Active Directory supports this operation - specifically, 1.3.6.1.4.1.4203.1.11.3
In your shoes, I would be guessing that it doesn't, but we're not the right people to ask.
Donn Cave, donn@u.washington.edu
openldap-software@openldap.org