In looking at LDAP traffic through Wireshark I was curious to understand the conversation between the a windows client and Active Directory. Each conversation would vary to less than 80k bytes. But there are times when a conversation would be 2.5-3MB in size. Can someone explain the types of queries that are being asked of AD from a windows client and perhaps the varying sizes of packets being exchanged? I have the packet captures with the payload data but unsure how to read it. There is one way I know of to initiate the conversation and that's with the "gpupdate /force" command. I'd like to also find out what other internal processing within windows initiates the queries?
2 Answers
Active Directory is unusual among LDAP directories in that it is not uncommon to have very large payloads. In fact, the largest payload you can send is 12 Mbytes. This seems outlandishly large, but there you go.
On the input side, it's possible someone may send a query like (|(samAccountName=jsmith)(samAccountName=jdoe)(...)(samAccountName=zsmith)) and specify individual wildcards or'd together.
On the output side, one common reason for large payloads is paging. When you have a query that returns multiple results, the response could be huge. AD has builtin support for paging and it's pretty easy to do, so it's possible for a single, simple query for all objects to return GB of a response.
Another scenario is not specifying the actual attributes you need in a query. If not specified, all attributes for the objects may be returned (except for constructed attributes), and an AD object may have a LOT of attributes.
The 3 MB payload is actually interesting, due to if you have Exchange, that would be the amount of data returned by the DC to a workstation when someone logs on. This is the ADSI schema attributes. If you are on a local network, this is probably not noticeable, but if you have remote clients and limited network bandwidth, downloading the ADSI schema attributes every day can be very noticeable.
More information on the ADSI schema cache download:
When a user logs on a workstation, the workstation checks if the ADSI schema attributes have not been downloaded or if the modifyTimestamp attribute that is saved in the registry is older than what is stored in AD. The registry looks like this:
[HKEY_CURRENT_USER\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=contoso,DC=com]
"Time"="20141114030449.0Z"
The AD attribute that is compared:
DN: CN=Schema,CN=Configuration,DC=contoso,DC=com
Attribute: modifyTimestamp
modifyTimestamp is a "constructed" attribute. AD takes the most recent whenChanged date of the other attributes to determine modifyTimestamp. You can see the whenChanged dates by running repadmin /showObjMeta CN=Schema,CN=Configuration,DC=contoso,DC=com
A reasonable person would assume that a user would download the ADSI schema cache once, and not need to download it again because the AD schema does not change that often. However, the modifyTimestamp does not indicate only when the AD schema is updated, because a customer could perform their own schema updates.
Where this becomes a problem is backups. When a system state backup is performed on a domain controller, the backup info is recorded in the dsaSignature attribute on the partition. This in turn results in client workstations and member servers to determine that they need to download the ADSI schema cache again. On a local network, this is not noticeable, but if you have a WAN with limited bandwidth separating your clients and the domain controllers, it can be very painful.
To complicate matters further, when 2008 R2 SP1 was released, the modifyTimestamp functionality actually did not work correctly. Microsoft corrected this with a hotfix, which may actually cause the ADSI schema cache performance hit to manifest.
As a workaround, it is possible to set a flag on the dsaSignature attribute on the schema partition to indicate to the backup to not update the dsaSignature attribute when the backup completes. This will prevent the modifyTimestamp from continuously incrementing, and will stop the downloads of the ADSI schema attributes. Downside is your monitoring application may complain that the schema partition is not being backed up. Another alternative is you could create a GPO to tag the "Time" registry value to a date far into the future, but that would be a kluge.
answered Nov 14, 2014 at 0:31
-
Your description of the ADSI schema attributes describe the exact problem that led me into researching LDAP. We upgraded several months ago from Exch2003 to Exch2010 and recently I discovered this larger data exchange between our DCs and win7 clients from our remote branches. Can you expand further as to what is happening? Is it only at logon that the schema attr. are downloaded? Is this normal behavior and can it be configured to lessen the load from our remote branches?– rmnvNov 14, 2014 at 13:47
-
@greg
I have a very similar situation occurring with a remote site with limited network bandwidth. I have a approx. 3000 endpoints with a small connection back to local domain controllers. Bandwidth is approx. 60mbps. We have noticed that when we run a schema update or domain/forest prep, this causes these workstations to completely saturate this connection with ldap calls. First occurrence happened during a Exchange CU update and the CU required a schema update. Second occurrence happened when we promoted the first server 2019 domain controller into the environment and a domain/forest prep was required. We cannot figure out what it is these workstations are downloading at the time of this bandwidth constraint.
Do workstations require to download a local copy of the schema? Do they require downloading a copy of the domain\forest instructions when a change is made?
