Object Attributes of category 'Constructed'
On this web page we want to have a look at the so called Constructed Attributes in Active Directory Services environments. These attributes do not really exist in the directory database, they rather will be cretaed by the directory server in the specific moment of the LDAP clients request for such an attribute. There are a few limitations which applies according to Constructed Attributes:
- There is no way for an LDAP client to write a value to a Constructed Attribute - after all these attributes are only assembledby a server as a reply to a specific request.
- In most cases, Constructed Attributes cannot be used in LDAP filters. Attention: The search with an LDAP filter where a Constructed Attribute was used maybe doesn't raise a runtime error - but there will just be no results for the search query! Exceptions to this rule are the attributes createTimeStamp, modifyTimeStamp, objectClasses and structuralObjectClass.
- Constructed Attributes cannot be returned as value data in an LDAP search request. unless the search scope is set to "base" which means that the LDAP client accesses only one single object. However, it is not possible for example to search for all objects in a container and specify a Constructed Attribute as one of the requested attributes in that search. Attention: Such "illegal" LDAP searches maybe doesn't raise a runtime error - but there will just be no results for the search query! Exceptions to this rule are the attributes createTimeStamp, modifyTimeStamp, objectClasses and structuralObjectClass.
The following operational attributes are contained in an Windows 2003 AD, which schema have been extended by an Exchange 2003 setup:
| allowedAttributes | allowedAttributesEffective |
| allowedChildClasses | allowedChildClassesEffective |
| aNR | attributeTypes |
| canonicalName | createTimeStamp |
| dITContentRules | entryTTL |
| extendedAttributeInfo | extendedClassInfo |
| fromEntry | modifyTimeStamp |
| ms-DS-Approx-Immed-Subordinates | ms-DS-Auxiliary-Classes |
| ms-DS-KeyVersionNumber | ms-DS-NC-Repl-Cursors |
| ms-DS-NC-Repl-Inbound-Neighbors | ms-DS-NC-Repl-Outbound-Neighbors |
| ms-DS-Principal-Name | ms-DS-Quota-Effective |
| ms-DS-Quota-Used | ms-DS-Repl-Attribute-Meta-Data |
| ms-DS-Repl-Value-Meta-Data | ms-DS-Resultant-PSO |
| ms-DS-Revealed-List | ms-DS-Revealed-List-BL |
| ms-DS-SiteName | ms-DS-Top-Quota-Usage |
| ms-DS-User-Account-Control-Computed | ms-DS-User-Password-Expiry-Time-Computed |
| objectClasses | parentGUID |
| possibleInferiors | possibleInferiors |
| sDRightsEffective | structuralObjectClass |
| subSchemaSubEntry | tokenGroups |
| tokenGroupsGlobalAndUniversal | tokenGroupsNoGCAcceptable |
Other directory services like, for example, Sun's Directory Server or Novell's eDirectory don't have such Constructed Attributes. But in these LDAP services there are other special attribute types (known also in Active Directory) which also has to be taken care of: The so-called Operational Attributes.
To see whether an attribut is constructed or not, the System-Flags in the schema definition of this attribute has to be analyzed. This is a bit field stored as systemFlags in the schema entry, for constructed attributes, the third bit in this field is set to 1.
You can detect all the Constructed Attributes in your Active Directory enviroment with the following script:
