[Date Prev][Date Next]
Re: Authorization for operational data
At 10:15 AM 8/11/00 +0200, Michael Ströder wrote:
>I'm doing some first tests with openldap-2.0beta. My LDAP client is
>trying to do anonymous searches from the RootDSE (e.g.
>namingContexts) prior to binding as authorized user to get the right
>search root (for finding user entries).
I'll assume you are requesting the return of this operational
attribute. The current server only returns operational attributes
when explicitly requested. It is due to our interpretation of
the LDAP specification and the fact that the root DSE may contain
We do provide a means to "discover" operational attributes (e.g.
by requesting "+" in the attribute list) and are hoping this becomes
part of the LDAP specification and fairly uniquitous.
I'll assume you've read previous discussions regarding this and
are actually asking about access controls upon operational attributes.
>In the default configuration I can't read the RootDSE with anonymous
>access. How to change that?
The defaultaccess is "read" until you define an "access" directive,
then it's "none".
>Thinking about it a while it's not clear to me how to deal with
>security issues regarding operational data stored in the directory
>(RootDSE and schema).
You can control access to operational attributes regardless of
location by defining ACLs.
>I understand that the default configuration
>trys to protect everything but does that make sense?
Actually, the default configuration is "read" which offers
little protection which makes little sense in the real world.
However, "defaultaccess none" default would be painful to first
>It might lead to the situation where you have to pre-configure
>things on the client side e.g. search root like for LDAPv2 servers
>or even worse some people might configure rootdn/rootpw on their
>clients which leads to less security.
I see no real way to avoid having some minimal configuration
(or user provided) information at the client. Hopefully most
clients only need a single LDAP URI (which could be obtained
dynamically via various non-LDAP means).
>Another thing: It seems to me that the first rootdn in slapd.conf is
>allowed to retrieve the RootDSE. Is that correct?
No. The rootdn is grants super-user access within a backend
database. It has no impact upon entries not within any backend.
>If yes, this looks
>inconsistent to me. The RootDSE should have it's own database
>section and ACLs. And how about the schema data?
Global ACLs may be provided for the Root DSE and other information
which is outside the scope of any backend.