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

Re: ACL's using group access do not work (ITS#2118)

To eliminate the SASL authzid stuff from this, you try authenticating directly as:

using simple authentication to see if problem is with
the group code or the authzid code.  Also, modifying
bdb_group() to print both the DN and the normalized
DN of the operation may be useful.

I've tried unsuccessfully to duplicate this problem by
hacking on test007-acls.


At 09:11 AM 2002-09-30, quanah@stanford.edu wrote:
>Full_Name: Quanah Gibson-Mount
>Version: HEAD
>OS: Solaris 8
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (
>Using Openldap-head from September 24th, on a Solaris 8 system, with Berkeley DB
>backend.  Cyrus sasl & kerberos 5 installed.
>Running the command "ldapsearch sukrb5name=quanah@stanford.edu" fails, even
>though I am a member of a group with * read access into the openldap directory.
>Given the following ACL file:
># ACL include file for slapd
># this is for testing
>access to dn=""
>        by * read
>access to attrs=krb5PrincipalName,suKrb5Name,member
>        by * read
>access to *
>        by dn="cn=replicator,cn=Applications,dc=stanford,dc=edu" write
>        by group="cn=Supervisor,cn=Applications,dc=stanford,dc=edu" read
>        by group="cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu" read
>        by anonymous auth
>access to dn=".*,cn=Accounts,dc=stanford,dc=edu" attrs=suSeasSunetID,suMaildrop
>        by dn="cn=StanfordMailRouter,cn=Applications,dc=stanford,dc=edu" read
>With the group supervisor defined as:
># supervisor, Applications, stanford.edu
>dn: cn=supervisor,cn=Applications,dc=stanford,dc=edu
>objectClass: groupOfNames
>cn: supervisor
>member: suRegID=87faaba8f61311d2ae662436000baa77,cn=People,dc=stanford,dc=edu
>member: suRegID=85e49978f61311d2ae662436000baa77,cn=People,dc=stanford,dc=edu
>When I bind using K5 with GSSAPI, the SASL-Regexp converts me to:
><==slap_sasl2dn: Converted
> SASL name to suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu
>getdn: dn:id converted to
>SASL Canonicalize [conn=1]
>: authcDN="suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu"
>do_bind: SASL/GSSAPI bind:
> dn="suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu"
>As you can clearly see, the DN I have been converted to, is a member of the
>supervisor group.  However, when slapd goes to check my access:
>[ID 806586 local4.debug] => string_expand: pattern:
>  cn=Supervisor,cn=Applications,dc=stanford,dc=edu
>[ID 489063 local4.debug] => string_expand: expanded
>: cn=Supervisor,cn=Applications,dc=stanford,dc=edu
>[ID 114958 local4.debug] >>> dnNormalize: <cn=Super
>[ID 532571 local4.debug] <<< dnNormalize: <cn=super
>[ID 248973 local4.debug] => bdb_group: gr dn: "cn=s
>[ID 231450 local4.debug] => bdb_group: op dn: "suRe
>[ID 529798 local4.debug] => bdb_group: oc: "groupOf
>Names" at: "member"
>[ID 461965 local4.debug] => bdb_group: tr dn: "suRe
>[ID 749508 local4.debug] bdb_dn2entry_rw("cn=superv
>[ID 157115 local4.debug] => bdb_dn2id( "cn=supervis
>or,cn=applications,dc=stanford,dc=edu" )
>[ID 108501 local4.debug] ====> bdb_cache_find_entry
>_dn2id("cn=supervisor,cn=applications,dc=stanford,dc=edu"): 5 (1 tries)
>[ID 472485 local4.debug] ====> bdb_cache_find_entry
>_id( 5 ) "cn=supervisor,cn=Applications,dc=stanford,dc=edu" (found) (1 tries)
>[ID 257784 local4.debug] => bdb_group: found group:
> "cn=supervisor,cn=applications,dc=stanford,dc=edu"
>[ID 721865 local4.debug] <= bdb_group: found object
>Class groupOfNames and member
>[ID 114958 local4.debug] >>> dnNormalize: <suRegID=
>[ID 631365 local4.debug] <= bdb_group: "suRegID=85e
>49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu" not in
>=stanford,dc=edu": member
>[ID 241745 local4.debug] ====> bdb_cache_return_ent
>ry_r( 5 ): returned (0)
>[ID 340953 local4.debug] bdb_group: rc=1
>Clearly, I am in supervisor, yet slapd continues to mark me as not being a
>member.  Going back through my logs, it appears that last time that slapd
>actually would authenticate me correctly to a group was with Openldap-2.1.3.