Overview#
Root Directory Server Agent Service Entry or RootDSE is defined in RFC 2251 Section 3.4:An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the rootDSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter (objectClass=*)", however they are subject to access control restrictions. The RootDSE MUST NOT be included if the client performs a subtree search starting from the root.
Also Known As#
DSAs may allow DUAs to modify these attributes.RootDSE is primarily a Discovery Mechanism for Lightweight Directory Access Protocol
RootDSE Contents#
The following attributes of the root DSE are defined in section 5 of 5. Additional attributes may be defined in other documents. Servers MUST recognize these attribute names, but it is not required that a server provide values for these attributes, when the attribute corresponds to a feature which the server does not implement.- namingContexts
- subschemaSubentry
- altServer
- supportedExtension - (LDAP Extensions and Controls Listing)
- supportedControl - (LDAP Extensions and Controls Listing)
- supportedSASLMechanisms
- supportedLDAPVersion
- supportedFeatures - (LDAP Extensions and Controls Listing)
- supportedAuthPasswordSchemes
- supportedGroupingTypes
- vendorName
- vendorVersion
- dsaName
- changelog
- firstChangeNumber
- lastChangeNumber
If the server does not master entries and does not know the locations of schema information, the subschemaSubentry attribute is not present in the root DSE. If the server masters directory entries under one or more schema rules, there may be any number of values of the subschemaSubentry attribute in the root DSE.
Issues with RootDSE#
Determining whether the server supports any specific SupportedControl, SupportedExtension or SupportedFeatures presents some problems because, even though directory servers should publish the OIDs for supported features in the SupportedFeatures attribute in the RootDSE, as an example, RFC 4525 merely states that servers should publish the OID of the Modify-Increment extension in the root DSE, not that servers must publish the OID.[1]RootDSE Example#
- Information on Retrieving RootDSE
More Information#
There might be more information for this subject on one of the following:- Absolute True and False Filters
- Active Directory Functional Levels
- AltServer
- Best Practices for LDAP Security
- Changelog
- Constructed Attribute
- DSA-Specific Entry
- Determine LDAP Server Vendor
- Directory Partition Subtrees
- Directory Synchronization Control
- DirectoryTreeName
- Domain root object
- DomainControllerFunctionality
- DomainFunctionality
- DsaName
- EDirectory LDAP Transaction
- EDirectory Version
- Extended Request
- FederationBoundary
- FirstChangeNumber
- ForestFunctionality
- Glossary Of LDAP And Directory Terminology
- How to get OpenSSL to recognise an Active Directory CA
- LDAP Grouping of Related Operations
- LDAP Metrics
- LDAP Modify-Increment Extension
- LDAP Protocol Mechanisms
- LDAP Proxy User
- LDAP ping
- LDAP_SERVER_RANGE_OPTION_OID
- LastChangeNumber
- MOVE Sub-Tree Obituary
- MaxPageSize
- NDS Tree-name
- NamingContext
- NovellS Challenge Response System
- Oracle Internet Directory and DirXML Moves
- Oracle OID Anomalies
- PASSWD_NOTREQD
- Proxied Authorization Control
- Retrieving All Attributes
- Retrieving Constructed Attributes
- Root Directory Server Agent Service Entry
- Root Domain Directory Partition
- RootDSE Example
- Schema Sync
- SubschemaSubentry
- SupportedAuthPasswordSchemes
- SupportedControl
- SupportedExtension
- SupportedFeatures
- SupportedGroupingTypes
- SupportedLDAPPolicies
- SupportedLDAPVersion
- Tree_new_RDN Obituary
- Tree_old_RDN Obituary
- UserPrincipalName
- VendorName
- VendorVersion
- View the Available Controls
- [#1] - http://ldapmaven.com/2011/08/02/mastering-modify-increment/
- based on informayion retreived 2013-06-15