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

RE: GSSAPI Binds openldap 2.1.12

> -----Original Message-----
> From: Derek T. Yarnell [mailto:derek@cs.umd.edu]

> Ok, let me explain a little more,
> cn=staff,dc=csic,dc=umd,dc=edu
> is the rootdn, so it should be able to see anything, anywhere.

If it's truly the rootdn, then remove it from the ACLs. The rootdn is already
handled specially by the ACL engine, so specifying it in your clauses only
wastes execution time in the parser/evaluator.

> uid=derek,ou=staff,dc=csic,dc=umd,dc=edu
> is say a user, I want to be able to bind so that they could
> change certain attributes on their dn.
> so, my access rights right now is this,
> access to attr=uid,uidNumber,gidNumber,homeDirectory,mailLocalAddress
>         by dn="cn=staff,dc=csic,dc=umd,dc=edu"
>         by users read
> access to attr=loginShell,gecos,cn,mailroutingaddress,mailHost
>         by dn="cn=staff,dc=csic,dc=umd,dc=edu"
>         by self write
>         by users read
> You would have to be authenticated to just read the
> attributes and some you would
> be able to write to.
> I would obviously like to do this with GSSAPI, so I don't
> need to put any passwords,
> etc in the ldap database.

As I said before, you still need to provide more general access rights
because with just those clauses, users don't have access to the Entries
themselves. This has nothing to do with GSSAPI, and everything to do with
basic access control configuration. See the FAQ-o-Matic:

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support