Microsoft Active Directory Anomalies

Overview#

Microsoft Active Directory has Anomalies like all LDAP Server Implementations

Naming Attributes#

Microsoft Active Directory allows only a single Naming Attribute to be used when creating LDAP objects.

Reading the Schema #

Only authenticated users may read the Active Directory schema.

No modifiersName or creatorsName #

Active Directory does not have a modifiersName or creatorsName attribute equivalent.

We have seen where this causes issues with various IDM connectors where any event that goes into Active Directory will come back from Active Directory as a new event.

LDAP policy in Active Directory #

We have no real issue with the method of using the policy settings, the re-boot thing is tough, but can be tolerated. However, to then go and override the values set by Administrators is confusing at best.

LDAP_SERVER_RANGE_OPTION_OID #

The LDAP_SERVER_RANGE_OPTION_OID in Microsoft Active DirectoryDomain Controllers set a limit on the maximum number of attribute values returned. The version of the server that supplies the requested data determines the maximum number of values that can be retrieved in a single query is defined in the MaxValRange within the LDAP policy in Active Directory.

Replication #

On the surface, partitioning the whole domain replication employed in Microsoft Active Directory is a lot easier to understand and manage than with Compared to NDS eDirectory. But as soon as you start to build large networks Microsoft Active Directory Anomalies starts to get an awful lot more complicated than most other vendors.

That being said, other than EDirectory, Microsoft has the second best replication and Multi-master replication system available.

CommonName, cn #

On the ldap-nis mailing list (discussing PADL Software's software projects) it has come to light that naming attributes (particularly "cn" - "commonName", also "CN" in NDS) in AD are always single-valued; the current definition of the attribute in AD is:

http://msdn.microsoft.com/library/sdkdoc/adschema/attrdetl_0yed.htm

Note the Attribute-ID (OID), "2.5.4.3". The page also indicates that the information is subject to change (let's hope it does so).

Various members of the list (and off-list) have checked the standards and reported that the following all define the attribute (same OID) to be multi-valued (not single-valued):

Testing against some existing LDAPv3 servers Netscape Directory 4.0 and Novell EDirectory LDAPv3 shows that they accept "cn" as multi-valued.

The discussion was in relation to RFC 2307 (and whether or not AD could really be compliant with the existing schema given this - and other - limitations and namespace clashes).

Access Control Lists #

Access Control Lists (ACLs) are the mechanisms by which a directory service tracks the access rights of each network entity represented in the directory. Proper management of ACLs is critical to proper functioning of the directory as well assuring simplified management. As an illustration of how ACLs function, consider an example of a user being granted access to a server. When the user is granted the right to access a given server, an entry is created in the server’s ACL that records the type of access right granted to the user. When the user next tries to access that server, the directory checks the associated Server Object to see if the user is listed in its ACL. If the user is listed, appropriate access is allowed.

Microsoft Active Directory does not maintain backlinks and therefore the ACL for each resource to which the user has been granted access must be manually updated to remove the user. To illustrate the significance of this problem, consider a realistic instance in which a user has been granted access to 20 resources. After deleting the user from AD, an erroneous reference to that user will continue to appear in the ACL for each of those 20 resources until the administrator manually edits the ACL for each of them or until an automated AD "clean up" function eventually removes them. In a large network, the scale of this problem and the administrative costs that would result are significant. AD’s lack of backlinks also prevents administrators from easily determining the network resources to which a user has been granted access, therefore making administrative actions requiring this knowledge more difficult, and therefore costly, to perform.

Access Rights #

Dynamic Access Rights Inheritance #

Directories should provide inheritance as a mechanism for simplifying management of access rights. With inheritance, a child object automatically receives the access rights of its parent object. If a parent object’s access rights are changed, the same changes are applicable to all child objects below it in the directory tree. Grouping resources into Organizational Units enables inheritance-based management of resources through single administrative actions, thus saving time. Inheritance-based management also provides unprecedented scalability of management.

Microsoft Active Directory statically stores the full access rights for a network entity in the access control list (ACL) of its associated object. While inheritance ensures that access rights changes to a parent object are eventually applied to all child objects, the method by which access rights are calculated is quite different from NDS. If the rights of a parent are changed, AD subsequently rebuilds the ACL list for each and every child object to cause their ACLs to reflect the change. This rebuilding process is a computer intensive function that consumes considerable CPU cycles and requires a significant amount of disk space. There is a delay between the time that a parent object’s rights are changed and the time when the ACLs of its child objects are rebuilt, and therefore the access rights changes to the parent object will not be immediately applied to child objects. There is a recent development of using Dynamic Authorization Management in Microsoft Active Directory

Why does this matter? #

Consider an example in which the right to access a given resource needs to be revoked from a group of users represented by an OU. It would seem apparent, that if the administrator removes the right from the parent OU, thereby causing all users in that OU to immediately lose access to the resource. In Microsoft Active Directory, however, even though the access right is revoked on the parent object, the users in the OU can continue to access the resource until their access control lists are rebuilt. AD does not guarantee immediate application of inherited rights, a situation that could lead to individuals having access to resources when they shouldn’t. To further complicate matters, when a user logs into the network, AD generates a static access token reflecting the user’s current group memberships. This access token is used when checking access rights during the entire time that the user is logged in, so any changes to the group memberships of the user while they are logged in are not enforced until the user logs out and logs back in again. Once again, AD does not guarantee immediate application of access rights changes, a situation that could lead to unexpected consequences.

Granular Delegation of Administrative Rights #

Active Directory supports Delegated Administration, which enables customers to distribute administrative responsibilities among any number of staff members while also limiting the scope of administrative functions that each member can perform. Delegation allows a core group of administrators to share the responsibilities of administering a large network, thus making management more scalable. The ability to restrict delegated rights also increases the security of the system by preventing administrators from making unauthorized changes to other portions of the network.

Microsoft Active Directory allows delegation to Users and Groups only (Security Principal Objects), which limits the usefulness of the delegation feature. Because Microsoft Active Directory does not allow delegation of rights to an OU object, AD requires administrators to define and set up an additional Group object for each type of delegation that is to apply to more than one administrator. In this system, administrators must personally have knowledge of which groups to add each new administrator to because AD doesn’t logically represent such knowledge via the directory tree hierarchy as NDS does. Such knowledge is difficult to learn, remember, and share, particularly in large companies with significant turnover and organizational flux.

DNS as a Discovery Mechanism #

A pure Windows Server 2000 domain relies on DNS for name resolution abandoning NetBIOS and WINS. W2K Pro has a DNS client resolver service which submits lookup queries to DNS servers. When the DNS server responds to a request, the client caches the response for a period of time so that it does not need to send another lookup request if the user wants to contact the same host again. A potential "gotcha" for network admins is that W2K supports RFC 2308 and also caches negative responses, that is NACKs. (NOTE: Be sure your DNS supports RFC 2308)

Its kinda like the situation I run into with web caching. A developer updates a page on the a web server and then winds up calling me when he cannot see his updates in the browser. His webbrowser has cached the page and is not requesting an update from the webserver. It will resolve itself ultimately or the user can clear the browser's cache or force an update from the webserver ( hold down shift key and press reload).

Windows Client #

When an Windows Client connects to a Microsoft network, the client will connect to the a Domain Controller that is able to handle the Windows Client connection. The Windows Client will not let go of this connection until the Domain Controller even if the server has been shut down. In our experience, this requires a reboot of the Windows Client to fix this.

This is a new unexpected result for network admins used to WINS. Take a situation where users cannot contact a new server because DNS server has a missing host (A) record. You add the missing record but the users still get Invalid host name when they ping the server name. Oddly enough, when pinging from an NT workstation or linux workstation it now works! What's the problem? The W2K clients cached the NACK they received from the original query and W2K is not going back to the DNS server for a fresh look up (just like the browser does refresh its cache).

To verify the contents of the DNS cache use ipconfig at the command line: 

ipconfig /displaydns

You will see the negative cache entries (NAKs). IPCONFIG can be used to flush the DNS cache: 

ipconfig /flushdns

W2K's default caches records for an hour. This is the timeout interval specified in the Start Of Authority (SOA) record for the primary DNS master for the zone that contains the record. If you change the Timeout default be cautious. Reducing the cache interval can cause increased network traffic while increasing it can make it take longer for changes in IP Addresses to be recognized by clients.

If you want to experiment with the cache interval:

Windows Server 2000 DNS secondaries will be updated via W2K's update notification. Unix and other non-Windows 2000 secondaries require you to force a zone transfer to propagate the change throughout your network.

To change W2K Pro's default behavior of caching NAKs, use the following Windows registry hack: 

 
Hive: HKEY_LOCAL_MACHINE
Key: System\CurrentControlSet\Services\DNSCache\Parameters 
Name: NegativeCacheTime 
Type: REG_DWORD
Set the NegativeCacheTime value to 0 to disable NACK caching.

You can not use Group Policy to control this behavior in W2K Pro. You can distribute the change to client workstations by including a Windows registry update in logon scripts. Use Regedit to save the Windows registry entry to a .reg file, save it in logon script directory and include a call to it in the logon script: regedit /I no_nak.reg

Recommended Maximum Number of Users in a Group (MaxPageSize)#

For Windows Server 2000 Microsoft Active Directory environments, the recommended maximum number of members in a group is 5,000. This recommendation is based on the number of concurrent atomic changes that can be committed in a single database transaction.

Starting with Windows Server 2003, the ability to replicate discrete changes to linked MULTI-VALUE attributes was introduced as a technology called Linked Value Replication (LVR). To enable LVR, you must increase the forest functional level to at least Windows Server 2003 interim. Increasing the forest functional level changes the way that group membership (and other linked multivalued attributes) is stored in the database and replicated between domain Controllers. This allows the number of group memberships to exceed the former recommended limit of 5,000 for Windows Server 2000 or Windows Server 2003 at a forest functional level of Windows 2000.

So far, testing in this area has yet to reveal any new recommended limits to the number of members in a group or any other linked multivalued attribute. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.

LDAP over UDP (CLDAP)#

UDP is not supported by the LDAP protocol. Microsoft Active Directory is trying supporting LDAP over UDP (CLDAP), but there is no way you can initiate a SSL/TCP connection over UDP.

Maximum Database Record Size#

Maximum Database Record Size is a restriction is a limitation of multivalued, non-Linked Attributes in Windows Server 2003.

More Information #

There might be more information for this subject on one of the following:

Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!