We should be able to access control the RootDSE. The reason we cannot today is because there's no way to make it an AP and have a subordinate subentry for the ACIItem that will control access to it. My reason for asking about the use cases was to try to weigh the need/criticality for this feature verses the amount of work needed to do this without using a hack. The hack would be to have a simple AA rooted at this RootDSE as the AP but nothing below it. We could manage subentries as read only in memory objects for this limited AA.
The right solution (non-hack) would be to enable nestable partitions, have a root partition, and do away with the nexus. Then the whole tree is treated in the same way with the same mechanism - no hacks.
This is why I wanted to know if the use case for anything other than read only global exposure as we have it today is critical. If so then we can prioritize this nested partition feature and have a root partition that can hold AC subentries under the RootDSE to make it an AP. Looks like Howard just posted some really good points - we need this feature but it's not critical IMHO so it can wait until we get nested partitions in place.
Another reason why we should have a root partition with partition nesting so we can get rid of the need to have both a system and a schema partition in the server.
Alex Karasulu wrote:Sorry, I misunderstood your question, not intended to make you feel like you don't know the RFC.
No need to quote the RFC with me, I know that it can be subject to access control - read my question.
When you use HTTPd, you usually mask the version and name just for security reasons (if you know which version you are connected too, you can use the knowns security issues the specific version has to attack the server).
You know of situations when it is actually set to anything but read-only by everyone?
I don't know if this is a strong enough use case anyway. Let say that this JIRA is pretty much a 'non conformance to the spec' JIRA.
I can downgrade it to Improvement, instead of 'bug'.
Not a big deal, really !
On Tue, May 6, 2008 at 1:04 AM, Emmanuel Lecharny <email@example.com <mailto:firstname.lastname@example.org>> wrote:
Alex Karasulu wrote:
This is because the RootDSE is usually bare so applications
can perform discovery but some servers might want to protect
it. Know of any situation when the RootDSE could be hidden?
RFC 4512 :
5.1. Server-Specific Data Requirements
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as
a group of attributes located in the root DSE, which is named with
the DN with zero RDNs (whose [RFC4514] representation is as the
These attributes are retrievable, _subject to access control_ and
restrictions, if a client performs a Search operation [RFC4511] with
an empty baseObject, scope of baseObject, the
filter"(objectClass=*)" [RFC4515], and the attributes field
names of the desired attributes.