[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Ldap kerberos ticket - GSSAPI



See bellow.

From: Donn Cave <donn@u.washington.edu>
To: openldap-software@OpenLDAP.org
Subject: Re: Ldap kerberos ticket - GSSAPI
Date: Tue, 29 Mar 2005 16:43:45 -0800

On Tuesday, March 29, 2005, at 04:22 PM, Manel Euro wrote:
(quoting me)

From your sasl-regexp it isn't clear to me what you want, but logically
I think it follows that if you want principals who are represented in the
directory to have similar DNs to those who are not, then you must want
them all in the form of the first one who was not in there, not the second.



With my sasl-regexp I map my GSSAPI ids (<uid=testUser,cn=EXAMPLE.NET,cn=GSSAPI,cn=auth>) to my directory DNs (test user exists as <uid=testUser,dn=example,,dn=net>).


If I have understood well, I can use Ldap and Kerberos in two ways:

1st- SASL/gssapi
2nd- pass throught authentication - userPASSWORD: {sasl}user@REALM-COM and saslauthd


I am using the first one. So, in this method when the kerberos ticket is presented to the slapd, slapd maps this kerberos principal to the *corresponding* directory DN. On this case, the principal testePac@EXAMPLE.NET does not have an entry on the directory. Therefore, according to what I have understood, this user shout not get a Kerberos TGS to LDAP.

No - if you mean TGT (ticket granting ticket) - this user must get a TGT, because
in fact that's how it got here. It authenticates to the LDAP service, and then
we know who it is and what it's authorized to do. That analysis can't be done
without authentication first, and the TGT is issued for authentication. (Moreover,
it isn't even issued by the LDAP server, but rather by the Kerberos KDC, but I take
it your concern at the moment has less to do with the TGT itself and more with the
way the authenticated user is handled by the LDAP service.)


I mean Ticket Granting Service (TGS), not TGT.


Thank you .

Ps. This is a bit off topic, but I was wondering, are you using a proxy so uid and gid information is fectch before pam_krb5 gets into action? I am currently allowing anonymous binds because I have read that when saslauthd checks if the kerberos password/principal match the performance degrades (ignoring the fact that the principal password is sent in clear text).

What's pam_krb5? I am sort of joking - please don't answer that question - but
honestly I don't know anything about these matters or how they relate to LDAP.

:) If I use GSSAPI and only authenticated users can access the directory (which has /etc/passwd, /etc/group and automount information) before login I need a binddn to get uid and gid of the user trying to login.






Donn Cave, donn@u.washington.edu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/