!!! Overview
Microsoft Active Directory has [Anomalies|Anomaly] like all [LDAP Server Implementations]

!! [Naming Attributes]
* Naming has to be Unique within each Active Directory Domain, regardless of full distinguished name. This means there can not be two "Tom Smith"s or two groups named Sales. 
* Only supports Domain Naming constructs in LDAP Tree layout, not the X.500 of ou=,o=. 

[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 Directory][Domain 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|Partition] 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 [{$pagename}] 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): 
* IETF [RFC 2256] 
* DMTF DEN (most interesting because [Microsoft] was one of the founders of the DEN effort...) 
* ITU-T X.520(93) 

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 Address]es to be recognized by [clients]. 

If you want to experiment with the cache interval: 
* Open the DNS Management console on the W2K [DNS] server that is the master primary server for the zone. If you use [Microsoft Active Directory] integrated zones, you can make the change at any [Domain Controller] running [DNS]. 
* Right-click the top of the zone and select Properties from the flyout menu. 
* Select the [Start of Authority] ([SOA]) record. 
* Change the value for the Minimum Default [Time To Live] ([TTL]) entry. 
* Click OK to save the change. 

[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: 
[{ReferringPagesPlugin before='*' after='\n' }] 
----
* [#1] - [How the Data Store Works|https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772829(v=ws.10)|target='_blank'] - based on information obtained 2020-02-24