Quota objects are stored in the NTDS Quotas container of the naming contexts and application partitions except for the schema naming context. (Quotas cannot be associated with the schema NC.) By default, this container is hidden from view within tools such as Active Directory Users and Computers, but you can see it by selecting View→Advanced Features from the menu. The quota object container has an objectClass of msDS-QuotaContainer and contains several attributes that define default quota behavior. Table 15-1 lists some of the important attributes of msDS-QuotaContainer objects.

Quota objects have an objectClass of msDS-QuotaControl, which defines three attributes that relate to quotas. Table 15-2 contains these attributes and provides a description for each.

You want to enable diagnostics event logging because the current level of logging is not providing enough information to help pinpoint the problem you are troubleshooting.

A useful way to troubleshoot specific problems you are encountering with Active Directory is to increase the diagnostics logging level. Diagnostics logging can be enabled for individual components of AD. For example, if you determine the KCC is not completing every 15 minutes, you can enable diagnostics logging for the “1 Knowledge Consistency Checker” setting.

These settings are stored under HKLMSYSTEMCurrentControlSetServicesNTDSDiagnostics. By default, all settings are set to 0, which disables diagnostics logging, but you can increase it by setting it to a number from 1 through 5. As a general rule, a value of 1 is used for minimum logging, 3 for medium logging, and 5 for maximum logging. It is a good practice to ease your way up to 5 because some diagnostics logging settings can generate a bunch of events in the event log, which may make it difficult to read, along with increasing resource utilization on the domain controller.

Here is the complete list of diagnostics logging settings:

1 Knowledge Consistency Checker
2 Security Events
3 ExDS Interface Events
4 MAPI Interface Events
5 Replication Events
6 Garbage Collection
7 Internal Configuration
8 Directory Access
9 Internal Processing
10 Performance Counters
11 Initialization/Termination
12 Service Control
13 Name Resolution
14 Backup
15 Field Engineering
16 LDAP Interface Events
17 Setup
18 Global Catalog
19 Inter-site Messaging
20 Group Caching
21 Linked-Value Replication
22 DS RPC Client
23 DS RPC Server
24 DS Schema
25 Transformation Engine
26 Claims-Based Access Control

“Active Directory Diagnostic Logging”

You want to enable NetLogon logging to help with troubleshooting client account logon, lockout, or domain controller location issues.

The netlogon.log file located in %SystemRoot%Debug can be invaluable for troubleshooting client logon and related issues. When enabled at the highest setting (0x2080ffff), it logs useful information such as the site the client is in, the domain controller the client authenticated against, additional information related to the DC Locator process, account password expiration information, account lockout information, and even Kerberos failures.

The NetLogon logging level is stored in the following Registry value:

HKLMSystemCurrentControlSetServicesNetlogonParametersDBFlag

One of the issues with the netlogon.log file is that it can quickly grow to several megabytes, which makes it difficult to peruse. The command-line tool nlparse can filter the contents of the netlogon.log file so that you’ll see only certain types of log entries. The nlparse tool is part of the Account Lockout and Management Tools.

MS KB 109626 (Enabling Debug Logging for the Netlogon Service); MS KB 247811 (How Domain Controllers Are Located in Windows); MS KB 273499 (Description of Security Event 681); “Troubleshooting Netlogon Error Codes”

You want to troubleshoot GPO processing issues on a client or server by enabling additional logging in the Application event log.

If you experience problems with client GPO processing, such as a GPO not getting applied even though you think it should, there are a number of different Registry keys that can help you troubleshoot the problem. One way to get detailed information about which GPOs are applied on a client computer is by enabling additional GPO event logging. Table 15-3 lists a number of Registry settings that can be configured to enable Group Policy logging, as well as the files that are created when the settings are enabled.

“Fixing Group Policy problems by using log files”; “Troubleshooting Group Policy Using Event Logs”; “Userenvlog for Windows Vista/2008/Win7”

You want to enable Kerberos logging on a domain controller to troubleshoot authentication problems.

If you are experiencing authentication problems or would like to determine whether you are experiencing any Kerberos-related issues, enabling Kerberos logging will ensure that Kerberos errors will be logged in the System event log. The Kerberos events can point out if the problem is related to clock skew, an expired ticket, an expired password, etc. For a good overview of some of the Kerberos error messages, see MS KB 230476.

Here is a sample event:

  Event type:  Error
  Event source:  Security-Kerberos
  Event ID:  3

  A Kerberos error message was received:
  on logon session user5@adatum
  ClientTime
  ServerTime 19:34:26.0000 12/17/2012 Z
  ErrorCode 0x17
  ErrorMessage 0x19 KDC_ERR_PREAUTH_REQUIRED
  ExtendedError
  ClientRealm
  ClientName
  ServerRealm ADATUM.COM
  ServerName krbtgt/ADATUM.COM
  TargetName krbtgt/[email protected]
  ErrorText
  File e
  Line d3a
  Error Data is in record data.

“How to enable Kerberos event logging”

You want to view DNS server performance statistics.

The Microsoft DNS Server keeps track of dozens of performance metrics. These metrics include the number of queries, updates, transfers, directory reads, and directory writes processed by the server. If you can pump these metrics into an enterprise management system, you can track DNS usage and growth over time.

These statistics can also be useful to troubleshoot load-related issues. If you suspect a DNS server is being overwhelmed with DNS update requests, you can look at the Dynamic Update Received/sec counter and see whether it is processing an unusually high number of updates.

> dnscmd /statistics /?

> dnscmd /statistics 6
DNS Server . statistics:

Queries and Responses:
----------------------
Total:
    Queries Received =   14902
    Responses Sent   =   12900
UDP:
    Queries Recvd    =   14718
    Responses Sent   =   12716
    Queries Sent     =   23762
    Responses Recvd  =       0
TCP:
    Client Connects  =     184
    Queries Recvd    =     184
    Responses Sent   =     184
    Queries Sent     =       0
    Responses Recvd  =       0

Queries:
--------
Total         =   14902
    Notify    =       0
    Update    =    2207
    TKeyNego  =     184
    Standard  =   12511
       A      =    1286
       NS     =      29
       SOA    =    2263
       MX     =       0
       PTR    =       1
       SRV    =    8909
       ALL    =       0
       IXFR   =       0
       AXFR   =       0
       OTHER  =      23

Command completed successfully.

MSDN: MicrosoftDNS_Statistic

You want to verify the correct functioning of the Windows Time Service.

Because Active Directory relies on Kerberos for authentication, it’s critical that all of your domain controllers, member servers, and client computers maintain a consistent time across the network; if any computer’s clock is off by more than five minutes, then by default, it will not be able to authenticate to Active Directory. You can use the w32tm utility to verify time synchronization on one or more computers using the /monitor switch, as well as using the /resync switch to prompt a computer to immediately resynchronize its clock with its authoritative time source.

“Configuring a Time Source for the Forest”; “How to configure an authoritative time server in Windows Server”

You want to log inefficient and expensive LDAP queries to the Directory Services event log.

To log a summary report about the total number of searches, total expensive searches, and total inefficient searches to the Directory Services event log, set the 15 Field Engineering diagnostics logging setting to 4. This summary is generated every 12 hours during the garbage collection cycle.

To log an event to the Directory Services event log every time an expensive or inefficient search occurs, set the 15 Field Engineering diagnostics logging setting to 5.

See Enabling Diagnostics Logging for more on enabling diagnostics logging.

A search is considered expensive if it has to visit a large number of objects in Active Directory. The default threshold for an expensive query is 10,000. That means any search that visits 10,000 or more objects would be considered expensive. A search is considered inefficient if it returns fewer than 10 percent of the total objects it visits. If a query visited 10,000 objects and only returned 999 of them (less than 10 percent), it would be considered inefficient. The default bottom limit for an inefficient query is 1,000. If the query returned 1,000 instead, it would not be considered inefficient. To summarize, with 1,000 as the default bottom threshold, no search that visits fewer than 1,000 entries (even if it visited 999 and returned 0) would be considered inefficient.

Here is a sample summary report event that is logged when 15 Field Engineering is set to 5:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          12/21/2012 11:38:32 PM
Event ID:      1643
Task Category: Field Engineering
Level:         Information
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      adatum-dc.adatum.com
Description:
Internal event: Active Directory Domain Services performed the following number of search operations within this time interval.

Time interval (hours):
0
Number of search operations:
38529

During this time interval, the following number of search operations were characterized as either expensive or inefficient.

Expensive search operations:
7
Inefficient search operations:
22

If you set 15 Field Engineering to 5, the summary event is logged during the garbage collection cycle, and event 1644 is generated every time an expensive or inefficient search occurs. Setting this value can provide useful information if you are running applications that regularly generate expensive or inefficient queries. Notice that this event provides details on all aspects of the search, including the authenticating user, search base DN, search filter, attributes, controls, number of entries visited, and number of entries returned. The following entry is from a Windows Server 2012 domain controller:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          12/22/2012 1:19:05 AM
Event ID:      1644
Task Category: Field Engineering
Level:         Information
Keywords:      Classic
User:          SYSTEM
Computer:      dc1.adatum.com
Description:
Internal event: A client issued a search operation with the following options.

Client:
SAM
Starting node:
dc=adatum,dc=com
Filter:
( & (userAccountControl&2) (objectClass=user)
(objectCategory=cn=Person,cn=Schema,cn=Configuration,dc=adatum,dc=com) )
Search scope:
subtree
Attribute selection:
[shortnames]objectSid,sAMAccountName,userAccountControl
Server controls:

Visited entries:
51443
Returned entries:
3513

With the default settings, the query shown in the preceding event is considered both expensive and inefficient. It is expensive because it visited more than 10,000 entries. It is inefficient because it returned fewer than 10 percent of those entries.

You can customize what a domain controller considers expensive and inefficient by creating a couple of Registry values under the HKLMSYSTEMCurrentControlSetServicesNTDSParameters key. You can create a value named Expensive Search Results Threshold of type DWORD and specify the number of entries a search would need to visit to be considered expensive. Similarly, you can create a value named Inefficient Search Results Threshold of type DWORD and specify the minimum number of entries visited where a match returning fewer than 10 percent would be considered inefficient.

Enabling Diagnostics Logging for enabling diagnostics logging

You want to use the STATS LDAP control to test the efficiency of a query.

The STATS control is a useful way to obtain statistics about the performance of an LDAP query. With the STATS control, you can find out information such as the amount of time it took the server to process the query, how many entries were visited versus returned, what the search filter expanded to, and whether any indexes were used. Here is an example of what the STATS control returns for a search for all group objects in the cn=Users container:

Statistics
==================================================
Elapsed time: 0 (ms)
Returned 18 of 23 visited - (78.26%)

Used Filter:
  (objectCategory=cn=Group,cn=Schema,cn=Configuration,cn=adatum,cn=com

Used Indices:
  Ancestors_index:23:N

Pages referenced: 332
Pages read from disk: 0
Pages pre-read from Disk: 0

Analysis
--------------------------------------------------

Indices used:

Index name: Ancestors_index
Record count: 23 (estimate)
Index type: Normal attribute index
Ancestor index used, possibly inefficient, verify filter

A couple of things are worth noting here. You can also see that the filter used, (objectcategory=group), was expanded to:

(objectCategory=cn=Group,cn=Schema,cn=Configuration,dc=adatum,dc=com)

The syntax of the objectCategory attribute is a distinguished name, but Active Directory provides a shortcut so that you need to use only the LDAP display name of the class instead. Internally, Active Directory converts the display name to the distinguished name, as shown here. Finally, we can see that our search used an index, INTERSECT_INDEX:17:I.

Let’s look at another example, except this time we’ll perform an ANR search for Jim Smith:

***Searching ...
ldap_search_ext_s(ld, "ou=Sales,dc=adatum,dc=com", 2, "(anr=Jim Smith)",
attrList, 0, svrCtrls, ClntCtrls, 20, 1000 ,&msg)
Result <0>:
Matched DNs:
Stats:
        Call Time:        20 (ms)
        Entries Returned:        1
        Entries Visited:        2
        Used Filter:         ( | (displayName=Jim Smith*) (givenName=Jim Smith*)
(legacyExchangeDN=Jim Smith)  (msDS-AdditionalSamAccountName=Jim Smith*)
(physicalDeliveryOfficeName=Jim Smith*)  (proxyAddresses=Jim Smith*) (name=Jim
Smith*)  (sAMAccountName=Jim Smith*)
(sn=Jim Smith*)  ( & (givenName=Jim*)  (sn=Smith*) )  ( & (givenName=Smith*)
(sn=Jim*) ) )
        Used Indexes:
idx_givenName:10:N;idx_givenName:10:N;idx_sn:9:N;idx_
sAMAccountName:8:N;idx_name:7:N;idx_proxyAddresses:6:N;idx_
physicalDeliveryOfficeName:5:N;idx_msDS-AdditionalSamAccountName:4:N;idx_
legacyExchangeDN:3:N;idx_givenName:2:N;idx_displayName:1:N;

You can see from the second line that we used a very simple filter, (anr=Jim Smith). If you look down a little farther at Used Filter: you can see a better example of search-filter expansion. Like the objectCategory example earlier, ANR is a shorthand way to do something complex. A simple one-term search filter expands into a multiterm filter that searches across numerous attributes. (For more on the behavior of ANR, see Modifying the Attributes Included with ANR.) The point of showing this is to illustrate that the STATS control is very powerful and can be an invaluable tool when trying to troubleshoot or optimize LDAP queries.

Using LDAP Controls for using LDAP controls; Searching for Objects in a Domain for searching for objects; Modifying the Attributes Included with ANR for more on ANR; Enabling Inefficient and Expensive LDAP Query Logging for more on expensive and inefficient searches

You want to use the Performance Monitor to examine the performance of Active Directory.

There are several Performance Monitor counters that can be very valuable for monitoring and troubleshooting Active Directory. The NTDS performance object has counters for address-book lookups; inbound and outbound replication; LDAP reads, writes, and searches; and the Security Account Manager (SAM).

Here is a list of some of the most useful NTDS counters. We’ve also included their Performance Monitor explanation, which you can view by clicking on the Explain button in the Add Counters dialog box.

You want to enable Trace Logs to view system-level calls related to Active Directory.

Trace Logs capture detailed system- and application-level events. Applications support Trace Log capability by developing a Trace Log Provider. Active Directory supports several providers that log low-level system calls related to Kerberos, LDAP, and DNS, to name a few. This can be an extremely valuable tool for debugging or just exploring the inner workings of Active Directory. Trace Logs can be resource-intensive, so you should enable them with care.

The tracerpt/tracedmp commands generate a summary.txt file that summarizes all of the events by total. A second file called dumpfile.xml is created by default, but the dump format can be changed by specifying the -of switch, with a CSV, EVTX, or XML value.

Here is an example of what the summary.txt file looks like on a domain controller that had all of the Active Directory−related Trace Log Providers enabled:

Files Processed:
    AD Trace Log.etl
Total Buffers Processed 18
Total Events  Processed 720
Total Events  Lost      0
Start Time              Saturday, December 22, 2012
End Time                Saturday, December 22, 2012
Elapsed Time            51 sec
+--------------------------------------------------------------------------------+
|Event Count Event Name     Task    Opcode       Version    Guid            
+--------------------------------------------------------------------------------+
|          1 EventTrace     0       DbgIdRSDS    2          {68fdd900-4a3e-11d1↵
                                                             -84f4-0000f80464e3}|
|          1 EventTrace     0       BuildInfo    2          {68fdd900-4a3e-11d1↵
                                                             -84f4-0000f80464e3}|
|          1 EventTrace     0       Header       2          {68fdd900-4a3e-11d1↵
                                                             -84f4-0000f80464e3}|
|          2 DsDrsReplGtChg 0       End          4          {14f8aa24-7f4b-11d2↵
                                                             -b389-0000f87a46c8}|
|          2 DsDrsReplGtChg 0       Start        4          {14f8aa24-7f4b-11d2↵
                                                             -b389-0000f87a46c8}|
|        125 LdapRequest    0       End          4          {b9d4702a-6a98-11d2↵
                                                             -b710-00c04fb998a2}|
+--------------------------------------------------------------------------------+

Here you can see that over a 51-second period, there was one Event Trace request (EventTrace), two directory replication change requests (DsDrsReplGtChg), and 125 total LDAP requests (LdapRequest).

The dumpfile.csv file contains entries for every event that was generated during the time period. Here is an example of an entry for one of the DsDrsReplGtChg requests (note that the lines will wrap due to their length, so we’ve added a blank line in between for separation):

DsDrsReplGtChg,      Start,            0,          4,          0,          0,
          1,          0, 0x0000000000000000, 0x00000240, 0x00001388,
                    0,             ,                     ,
   {00000000-0000-0000-0000-000000000000},                                         
,   130006457569095598,         15,          0, "DS", 4, 8, 3506765888,        0,
 "e5a1b109-4add-4503-a909-66e55820265c (DC2.adatum.com)", "dc=adatum,dc=com",
 "250469",
 "250469", "2147483760", "536", "5363998", "0",
  0x00000000000000000000A7E12200CD00

DsDirGtNcChg,      Start,            0,          4,          0,          0,
          1,          0, 0x0000000000000000, 0x00000240, 0x00001388,
                    0,             ,                     ,
   {00000000-0000-0000-0000-000000000000},                                         
,   130006457569097056,         15,          0, "DS", 4, 6, 805568576,        0,
 "e5a1b109-4add-4503-a909-66e55820265c (DC2.adatum.com)", "dc=adatum,dc=com",
 "250469", "80000070", "0", "0",  0x47D92200CD000000A820303D

Based on those two lines, you can see Active Directory Domain Services replication commutation occur from this server to another server named dc2.adatum.com.

You want to define a threshold for a performance counter that should cause an alert to be generated.

There are a number of options for monitoring the ongoing performance of the Windows operating system, whether the machine in question is a domain controller, member server, or client computer. For larger environments, you can look into add-on tools such as the Microsoft System Center Operations Manager (OpsMgr) or third-party utilities from NetPro, NetIQ, and others. For a built-in solution, however, the Performance Monitor MMC snap-in can monitor performance metrics and send various administrative alerts.

“Windows Performance Monitor”

You want to create an alert that will notify an administrator via email if a performance alert is generated.

A common request among Windows system administrators is to have the ability to email an on-call administrator when a critical performance alert is generated—for example, when a domain controller is experiencing a critical hardware failure. It is a relatively simple matter to send email through PowerShell using the sample command shown in the solution. You can either hardcode the appropriate alert messages into the email message and maintain multiple scripts for the various alerts that you create, or include counter information in each message by using a generic email message (see Monitoring the Performance of Active Directory). Using the Performance Monitor MMC, you can submit one or more of the following as command-line arguments to a script that’s been fired in response to an alert:

Send-MailMessage cmdlet overview

You want to enable auditing of directory access and modifications. Audit events are logged to the Security event log.

You can log events to the Security event log for every successful and/or failed attempt to access or modify the directory, which is referred to as auditing. Auditing is enabled via the Security Settings section of a GPO that’s linked to the Domain Controllers OU, using either the “Audit directory service access” setting or the “Advanced Audit Policy Configuration” settings. Once either is enabled, you need to use the ACL Editor to define auditing in the SACL of the objects and containers you want to monitor.

By default, the domain object has an inherited audit entry for the Everyone security principal for all object access and modifications. That means once you enable auditing in the Domain Controller Security Policy and this configuration change replicates out, domain controllers will log events for any directory access or modification to any part of the directory. As you can imagine, auditing every access to Active Directory can generate a lot of events, so you’ll either want to disable auditing of the Everyone group and use the Advanced Audit Policy Configuration settings instead, or else keep a close eye on your domain controllers to ensure that they are not adversely affected while auditing is enabled.

Here is a sample event that was logged after the Administrator account created a user object called foobar in the Sales OU:

Event Type:        Audit Success
Event Source:      Microsoft Windows security
Task Category:     User Account Management
Event ID:          4720
Date:              12/26/2012
Time:              7:24:10 PM
User:              N/A
Computer:          DC1
A user account was created.

Subject:
    Security ID:        ADATUMadministrator
    Account Name:        administrator
    Account Domain:              ADATUM
    Logon ID:        0x36BFF

New Account:
    Security ID:        ADATUMfoobar
    Account Name:        foobar
    Account Domain:          ADATUM

Attributes:
    SAM Account Name:        foobar
    Display Name:        foobar
    User Principal Name:  [email protected]
    Home Directory:      -
    Home Drive:        -
    Script Path:       -
    Profile Path:      -
    User Workstations: -
    Password Last Set: <never>
    Account Expires:   <never>
    Primary Group ID:  513
    Allowed To Delegate To:    -
    Old UAC Value:        0x0
    New UAC Value:        0x15
    User Account Control:
        Account Disabled
        'Password Not Required' - Enabled
        'Normal Account' - Enabled
    User Parameters:    -
    SID History:        -
    Logon Hours:        <value not set>

Additional Information:
    Privileges     -

Once you have enabled auditing of Directory Service Changes and configured auditing on the relevant objects or containers, the Directory Services Event Viewer will record detailed entries whenever an AD object is created, modified, moved, or deleted, as follows:

“Advanced Security Audit Policy Settings”; “Planning and Deploying Advanced Security Audit Policies”

You want to enable auditing of any changes to one or more Registry keys.

Before you can enable auditing on specific Registry keys, you must create an audit policy that enables auditing of object access events, both Success and Failure events. You can enable auditing by modifying an existing GPO or by creating a new GPO created expressly for this purpose. Maintaining a number of single-purpose GPOs can make for easier Group Policy troubleshooting but can lead to performance implications if clients need to process too many GPOs at logon and during the background refresh of Group Policy. As is usually the case, the definition of “too many” will vary from one environment to the next; it’s important to monitor the performance of your clients to determine which approach is appropriate for your environment. Once you’ve enabled auditing of a specific key or keys, information about the activity that you’ve chosen to audit will appear in the Security event log of the computer where the event took place.

“Advanced Security Audit Policy Step-by-Step Guide”

You want to limit the number of objects a security principal can create in a partition by creating a quota.

Quotas allow an administrator to limit the number of objects that a user (or group of users) can create. A quota applies not just to a user object, but also to the creation of any object type in Active Directory. Three things need to be set when creating a quota specification:

The quota limit is a combination of the new objects that a user creates plus any tombstone objects that are created by that user. If a user creates an object and then deletes another object, that would still count as two objects toward any quotas that apply to the user. This is because when an object is deleted, it isn’t removed; it is simply marked as tombstoned. Once the tombstone object is removed from Active Directory, the user’s quota will be decremented accordingly. By default, a tombstone object counts as one object, but that is configurable. See Changing How Tombstone Objects Count Against Quota Usage for more on changing the tombstone quota factor.

Since quotas can be assigned to both users and groups, it is conceivable that multiple quotas may apply to a user. In this case, the quota with the highest limit will be in force for the user. You can also create a default quota for a partition that applies to all security principals. See Setting the Default Quota for All Security Principals in a Partition for more information on configuring the default quota.

Modifying the Attributes of a computer Object for more on the computer object quota; this chapter’s Introduction section for more on the attributes of quota objects; Finding the Quotas Assigned to a Security Principal for finding the quotas assigned to a security principal; Changing How Tombstone Objects Count Against Quota Usage for changing the tombstone quota factor; Setting the Default Quota for All Security Principals in a Partition for setting a default quota

You want to find the quotas that have been configured for a security principal (i.e., user, group, or computer).

The DSQuery solution will find only quotas that have been directly assigned to a security principal; it will not list quotas that have been assigned to any group objects that the principal may be a member of. The msDS-QuotaTrustee attribute on quota objects defines an SID that the quota applies to. The dsquery quota command will look up the SID for the specified account and match that against quota objects that reference that SID. Unfortunately, this doesn’t quite show the whole picture. A user could have a quota assigned directly, which the DSQuery command would show, but the user could also be part of one or more groups that have quotas assigned. These won’t show up using DSQuery. The PowerShell solution lists all quotas, including groups, for the Active Directory domain. However, it does not show a relation between the user object and any groups returned.

A more robust solution would entail retrieving the tokenGroups attribute of the user, which contains a list of SIDs for all expanded group memberships, and then querying each of those groups to determine whether any of them have quotas assigned. This is actually the type of algorithm that is used to determine a user’s effective quota, as shown in Finding the Quota Usage for a Security Principal.

Creating a Quota for creating a quota; Finding the Quota Usage for a Security Principal

You want to change the relative weight of tombstone objects in quota calculations.

The tombstone quota factor is a percentage that determines how much each tombstone object counts against a security principal’s quota usage. By default, tombstone objects count as one object. This means if a user’s quota is set to 10 and the user deletes 10 objects, that user will not be able to create or delete any other objects until those tombstone objects have been purged from Active Directory.

The msDs-TombstoneQuotaFactor attribute on the NTDS Quota container for each partition defines the tombstone quota factor. As mentioned previously, the default is that tombstone objects count 100 percent of a normal object; thus, the attribute msDs-TombstoneQuotaFactor contains 100 by default. If you modify this attribute to contain a value of 50 and a user has a quota limit of 10, then that user could delete a maximum of 20 objects (i.e., create 20 tombstone objects) because 20 × 50 percent = 10. As another example, you may not care about how many objects your users delete; in this case, you’d want to set the tombstone quota factor to 0 so that tombstoned objects would not count against a user’s NTDS quota at all.

MSDN: ms-DS-Tombstone-Quota-Factor attribute [AD Schema]; MSDN: ms-DS-Quota-Container class [AD Schema]; “Active Directory Quotas”

You want to set a default quota for all security principals.

The easiest way to apply a default quota to all of your users is to modify the msDS-DefaultQuota attribute on the NTDS Quotas container for the target partition. This attribute contains the default quota limit that is used if no other quotas have been assigned to a security principal. A value of −1 means that no quota exists; security principals can create and/or tombstone as many objects as they wish.

You should be careful when setting the default quota because it applies to every nonadministrator security principal. If you set the default to 0, for example, computers would not be able to dynamically update their DNS records in an AD integrated zone because that creates an object. This may not be applicable in your environment, but the point is that you need to consider the impact of the default quota and test it thoroughly before implementing it.

You want to find the quota usage for a certain security principal.

If you implement quotas, you’ll certainly need to tell users what their quotas are (or provide instructions on how they can find out for themselves). Currently, there are a few ways to determine quota usage, as outlined in this recipe’s “Solution” section.

Perhaps the most interesting is obtaining the top-quota usage. Note that it contains quota usage for all objects, even if the objects don’t have a quota. Each value of the msDs-TopQuotaUsage attribute contains an entry that details the top quota users in the database, listed in decreasing order of quota usage. Each value of the msDs-TopQuotaUsage attribute contains blocks of data formatted in an XML-like language. Each block has the SID of the security principal (<ownerSID>), quota used (<quotaUsed>), number of tombstone objects created (<tombstonedCount>), and number of objects that are still active (<liveCount>) (i.e., not tombstoned). Here is an example of what the attribute can contain:

DistinguishedName  : cn=NTDS Quotas,dc=adatum,dc=com
msds-TopQuotaUsage : {
                     <MS_DS_TOP_QUOTA_USAGE>
                         <partitionDN> dc=adatum,dc=com </partitionDN>
                         <ownerSID> S-1-5-32-548 </ownerSID>
                         <quotaUsed> 10003 </quotaUsed>
                         <deletedCount> 7 </deletedCount>
                         <liveCount> 10001 </liveCount>
                     </MS_DS_TOP_QUOTA_USAGE>
                     ,
                     <MS_DS_TOP_QUOTA_USAGE>
                         <partitionDN> dc=adatum,dc=com </partitionDN>
                         <ownerSID> S-1-5-21-1553546772-1433447814-1030694943-512 </ownerSID>
                         <quotaUsed> 240 </quotaUsed>
                         <deletedCount> 14 </deletedCount>
                         <liveCount> 237 </liveCount>
                     </MS_DS_TOP_QUOTA_USAGE>
                     ,
                     <MS_DS_TOP_QUOTA_USAGE>
                         <partitionDN> dc=adatum,dc=com </partitionDN>
                         <ownerSID> S-1-5-18 </ownerSID>
                         <quotaUsed> 37 </quotaUsed>
                         <deletedCount> 32 </deletedCount>
                         <liveCount> 32 </liveCount>
                     </MS_DS_TOP_QUOTA_USAGE>
                     ,
                     <MS_DS_TOP_QUOTA_USAGE>
                         <partitionDN> dc=adatum,dc=com </partitionDN>
                         <ownerSID> S-1-5-32-544 </ownerSID>
                         <quotaUsed> 21 </quotaUsed>
                         <deletedCount> 0 </deletedCount>
                         <liveCount> 21 </liveCount>
                     </MS_DS_TOP_QUOTA_USAGE>
                     ...}
Name               : NTDS Quotas
ObjectClass        : msDS-QuotaContainer
ObjectGUID         : c4bad721-caa3-4893-9bf5-cf399edca9aa

Additionally, AdFind has switches that can decode this output in a much friendlier format, as follows:

adfind -b "cn=NTDS Quotas, <PartitionDN>" msDs-TopQuotaUsage;binary -resolvesids

This command will return results similar to the following:

cn=NTDS Quotas,dc=adatum,dc=com
> msDs-TopQuotaUsage;binary: NC: dc=adatum,dc=com Owner: ADATUMDomain Admins
Used:175 Tombstone: 0 LiveCount: 175
cn=NTDS Quotas,dc=adatum,dc=com
> msDs-TopQuotaUsage;binary: NC: dc=adatum,dc=com Owner: NT AUTHORITYSYSTEM Used:
62 Tombstone: 29 LiveCount: 33
> msDs-TopQuotaUsage;binary: NC dc=adatum,dc=com Owner: BUILTINAdministrators
Used: 14 Tombstone: 0 LiveCount: 14

Finding the Quotas Assigned to a Security Principal for more on finding the quotas that are assigned to a security principal