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

Re: [LDAP-SOFTWARE] ACLand regex (matching self)

Hi Peter,

Thanks for helping me out so far ! But...
> AFAIK there is only one object that seems to be hidden:
> The tree root, with the name "" (the empty string between the quotes)
> This object is not hidden, but has simply an empty name which
> makes it hard to find.

Thanks to previous posts, I got that far already.
What I coudn't find out from the docs was:

a. if you DON'T specify any access rule for the empty DN (the RootDSE)
that other ACL's don't work anymore. 

access to dn="app=qwido"
  by dn="app=qwido"

gives access to the ENTIRE tree under app=qwido.

(at least, that is my finding in 2.0.27)

> This object contains information about the directory:
> where to find the schema, which naming contexts are there,
> what LDAP controls/extensions the server supports, ...
> All these informations are given in attributes of the rootDSE.
> The values of these attributes may be DNs for branches in the
> directory tree.

This, I still don't understand completely.
AFAIK, this means that a subschemaEntry MAY be part of the tree, even if I 
didn't add it. I can't understand that !

Also, by not specifying explicit access to these (apparently server-dependend) 
dn's, the ACL's don't work as expected. For instance, GQ dind't allow me to 
browse the schema's - what's worse, it didn't let me add specific objects 
that rely on self-made schema's, because it couldn't read those schema's.

Furthermore, let's say I have a list of 'unexpected' dn's obtained by the 
command you recommend:

> The most famous examples are the subschemaSubentry attribute which
> contains the the DN of the schema and the namingContexts attribute
> that contains the names of the top level nodes of your directory branches.
> ldapsearch -b "" -s base '(objectclass=*)' +
> gives you the information required.

what kind of access do they need ? search, compare ? or write ? or read ?

Followng is the output of your command on my 2.0.27 server:

ldapsearch -x -W -D "o=o,app=qwido" -b "" -s base '(objectclass=*)' +

version: 2

# filter: (objectclass=*)
# requesting: +

namingContexts: app=qwido
supportedControl: 2.16.840.1.113730.3.4.2
supportedLDAPVersion: 2
supportedLDAPVersion: 3
subschemaSubentry: cn=Subschema

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


Does this mean that I should add 

access to dn.subtree="cn=Subschema"
	by * read

to all my ACL's ?