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

Re: Ldap kerberos ticket - GSSAPI

See bellow.

I have configured Kerberos, OpenLdap and Cyrus-Sasl. Everything is working ok . However, I was doing some testing and found the following situation.

When a Kerberos principal, not represented on the ldap directory, runs the command ldapwhoami I get:

SASL/GSSAPI authentication started
SASL username: testePac@EXAMPLE.NET
SASL installing layers

when a principal which is also on the directoyr tree runs ldapadmin I get:

SASL/GSSAPI authentication started
SASL username: testeF@EXAMPLE.NET
SASL installing layers

So, I see that the dns are different. However, on both situation I get a kerberos TGS ticket for LDAP.

How can I avoid this happening?

sasl-regexp uid=(.+),cn=EXAMPLE.NET,cn=gssapi,cn=auth ldap:/// dc=example,dc=net??sub?(|(uid=$1)(krb5PrincipalName=$1@EXAMPLE.NET))

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.

If that's true, then I think you should use a simpler sasl-regexp, like
sasl-regexp uid=(.+),cn=EXAMPLE.NET,cn=gssapi,cn=auth uid=$1,cn=example.net,cn=gssapi,cn=auth

(I'm assuming that the predicate has been working for you - in the version
I'm using, GSSAPI authentications from my own realm are uid=x,cn=gssapi,... -
not uid=x,cn=realm,cn=gssapi,... And if you're dealing with external realms it
might be a good idea to put them somewhere in the result DN, as I did not do
I am using version 2.2.24 and cyrus-sasl 2.1.19. The cn=realm predicate is working.

Thanks for your help.


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).

Donn Cave, donn@u.washington.edu

Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963