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

Re: Ldap kerberos ticket - GSSAPI


See bellow.

From: Pierangelo Masarati <ando@sys-net.it>
To: Manel Euro <euro_32@hotmail.com>
CC: openldap-software@OpenLDAP.org
Subject: Re: Ldap kerberos ticket - GSSAPI
Date: Wed, 30 Mar 2005 08:28:51 +0200

Manel Euro wrote:

Hi,
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 SSF: 56
SASL installing layers
dn:uid=testepac,cn=example.net,cn=gssapi,cn=auth

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

SASL/GSSAPI authentication started
SASL username: testeF@EXAMPLE.NET
SASL SSF: 56
SASL installing layers
dn:uid=testef,ou=locationA,ou=people,dc=example,dc=net


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


ACLS:

access to *
  by self write
  by users read
  by anonymous read


when the user gets there, it's already authenticated, and you're supposed to trust the GSSAPI mech. 

Right, I agree.

Of course, it's up to the admin to give specific privileges to users that exist in the directory as opposed to those that authenticate but do not exist in the directory. What you should do is give privileges only to __authorized__users, i.e. those that do not authorize (pass sasl-regexp phase), and thus have a DN ending with "cn=auth", could be treated as anonymous. You can obtain this by means of ACLs, e.g. 


access to *
   by dn.subtree="cn=auth" none
   by self write
   by * read

Ok. Thank you, this is exactly what I need. This way the use of the acl solves my problem. I forgot that the DNs were different (althow I mentioned it on my previous email), thus subject to different ACLs.


Note, in fact, that in your example you make no distinction between users and anonymous, since you grant both read access, so you shouldn't even notice the problem, and your ACL could be

I know. This is temporary. I am still equating the use of saslauthd to get uid/gid before kerberos authentication.


access to *
   by self write
   by * read

since I don't see why you should give auth'd users not present in the directory less privileges than anonymous.

As soon as I finish setting up all the system no anonymous access will be allowed.

Thank you for your email.

M 

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497


_________________________________________________________________
Don?t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/