This chapter deals with tracking the activity and usage of various Active Directory components. When you need to troubleshoot a problem, often the first place you look is the logfiles. With Active Directory, there are several different logfiles, and each has different ways to increase or decrease the verbosity of the information that is logged. Viewing log messages can be a useful troubleshooting step, but you should also look at performance metrics to determine whether system hardware or a particular service is being overutilized. In this chapter, we’ll review a couple of ways you can view performance metrics, as well as monitor Active Directory performance. For more extensive monitoring, we suggest looking at Microsoft System Center Operations Manager (OpsMgr), or similar products from other vendors such as NetIQ and Quest. In addition to the typical items that you would monitor on a Windows server (e.g., disk space usage, physical and virtual memory errors, processor utilization), you should also monitor AD-specific performance metrics. This extends to monitoring replication activity and Event Log information.
We’ll also cover a somewhat-related topic called quotas, which allow you to monitor and limit the number of objects that a security principal (user, group, or computer) can create within a partition. This feature closes a hole that allowed users who had access to create as many objects in Active Directory as they wanted. These users could cause a denial-of-service attack by creating objects until the disk drive on the domain controllers filled to capacity. This kind of attack is not likely to happen in most environments, but you should still consider the possibility and protect against it.
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.
Table 15-1. Attributes of msDS-QuotaContainer objects
Attribute | Description |
---|---|
| RDN of quota container
objects. By default, this is equal to |
| The default quota applied to all security principals that do not have another quota specification applied. See Setting the Default Quota for All Security Principals in a Partition for more details. |
| A constructed attribute that contains the effective quota of the security principal that is viewing the attribute. See Finding the Quota Usage for a Security Principal for more details. |
| A constructed attribute that contains the quota usage of the security principal that is viewing the attribute. See Finding the Quota Usage for a Security Principal for more details. |
| Percentage that tombstone objects count against a quota. The default is 100, which means a tombstone object has equal weighting to a normal object. See Changing How Tombstone Objects Count Against Quota Usage for more details. |
| Multivalued attribute that contains information about the security principals with the top quota usage. See Finding the Quota Usage for a Security Principal for more details. |
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.
Table 15-2. Attributes of msDS-QuotaControl objects
Attribute | Description |
---|---|
| RDN of the quota object. |
| Number of objects that can be created by the security principals that the quota applies to. See Creating a Quota for more information. |
| SID of the security principal that the quota applies to. This can be a user, group, or computer SID. See Creating a Quota for more information. |
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.
In the left pane, expand the following Registry key: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSDiagnostics.
In the right pane, double-click on the diagnostics logging entry you want to increase, and enter a number (0–5) based on how much you want logged.
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
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
If you set that Registry value manually instead of using nltest, you’ll need to create the string value, adjust the value, and then restart the NetLogon service for it to take effect.
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.
Table 15-3. Registry settings to enable Group Policy logging
Logging for the CSE | Location | Enable verbose logging by adding this key or value ... | ...to this Registry key |
---|---|---|---|
Security CSE | %windir%securitylogswinlogon.log | ExtensionDebugLevel = REG_DWORD 0x2 | HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogonGpExtensions{827d319e-6eac-11d2-a4ea-00c04f79f83a} |
Folder Redirection CSE | windir%debugusermodefdeploy.log | FdeployDebugLevel = Reg_DWORD 0x0f | HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionDiagnostics |
Software Installation CSE | %windir%debugusermodeappmgmt.log | Appmgmtdebuglevel=dword:0000009b | HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionDiagnostics |
Windows Installer (deployment-related actions) | %windir% empMSI*.log | Logging = voicewarmup Debug = DWORD: 00000003 | HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsInstaller |
Windows Installer (user-initiated actions) | %temp%MSI*.log | Logging = voicewarmup Debug = DWORD: 00000003 | HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsInstaller |
In the left pane, expand HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters.
If the LogLevel
value
doesn’t already exist, right-click on Parameters and select
New→DWORD value. Enter LogLevel
for the value name and click OK.
In the right pane, double-click on LogLevel
and enter 1
.
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.
Click on Performance Monitor in the left pane.
In the right pane, click the + button. This will bring up the page to add counters.
Under “Select counters from computer”, enter the DNS server you want to target.
Select the DNS performance object.
Select the counters you want to add and click the Add button.
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.
You can obtain a subset of the statistics by providing a
statid after the /statistics
option. Each statistics category
has an associated number (i.e., statid). For a complete list of
categories and their statids, run the following command:
> dnscmd /statistics /?
Here is an example of viewing the Query
(statid = 2)
and Query2 (statid =
4)
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.
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.
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.
If you want to see all the LDAP queries that are being sent to a
domain controller, a quick way to do that would be to set the 15 Field
Engineering setting to 5
and
Expensive Search Results Threshold to 0
. This would cause the domain controller to
consider every search as expensive and log all the LDAP searches.
While this can be very useful, you should use it with care as it could
quickly fill your event log. Be sure to allow sufficient disk space
for your event logs to avoid any issues with low disk space on your
domain controllers.
Enabling Diagnostics Logging for enabling diagnostics logging
From the menu, select Connection→Connect.
For Server, enter the name of a domain controller.
For Port, enter 389
.
Click OK.
From the menu, select Connection→Bind.
Enter the credentials of a user to perform the search or accept the default and bind as the currently logged on user.
Click OK.
From the menu, select Options→Controls.
From the Load Predefined drop-down, select Search Stats.
Click OK.
From the menu, select Browse→Search.
Enter your search criteria and then click the Options button.
Under Search Call Type, be sure that Extended is selected.
Click OK and then click Run. The status will be shown at the top of the search results.
The AdFind command-line utility has four switches that will display efficiency statistics for any query:
-stats
Enables the STATS control to return statistics about the query, along with the actual results of the query
-statsonly
Returns only the statistics about the query, and suppresses the actual query results
-stats+
Similar to -stats
, but
also displays additional advanced analysis about the
query
-stats+only
Just like -stats+
, but
will suppress the actual results of the query and display only
the query statistics
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
Click on Performance Monitor in the left pane.
Click the + button. This will bring up the page to add counters.
Under “Select counters from computer”, enter the name of the domain controller you want to target.
Select the NTDS performance object.
Select the counters that you want to monitor.
After you’re done with your selections, click Close.
To retrieve a continuous counter for a performance object, use the following PowerShell command:
Get-Counter -Counter "<PerformanceObject>
" -Continuous
For example, to view the performance counter for the DS Directory Searches/sec
object, run the
following command:
Get-Counter -Counter "NTDSDS Directory Searches/sec" -Continuous
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.
Shows the total number of bytes received through replication. It is the sum of the number of uncompressed bytes (never compressed) and the number of compressed bytes (after compression).
Shows the number of objects received from neighbors through inbound replication. A neighbor is a domain controller from which the local domain controller replicates locally.
Shows the total number of object property values received from inbound replication partners. Each inbound object has one or more properties, and each property has zero or more values. A zero value indicates property removal.
Shows the total number of bytes replicated out. It is the sum of the number of uncompressed bytes (never compressed) and the number of compressed bytes (after compression).
Shows the number of objects replicated out.
Shows the number of object property values sent to outbound replication partners.
Shows the number of directory synchronizations that are queued for this server but not yet processed.
Shows the number of ntdsapi.dll binds per second serviced by this DC.
Shows the number of directory reads per second.
Shows the number of directory searches per second.
Shows the number of directory writes per second.
Shows the time, in milliseconds, taken for the last successful LDAP bind.
Shows the number of currently connected LDAP client sessions.
Shows the rate at which LDAP clients perform search operations.
Shows the number of LDAP binds per second.
Shows the rate at which LDAP clients perform write operations.
In the left pane, expand Data Collector Sets.
Right-click Event Trace Sessions and click New→Data Collector Sets.
In the Name: field, enter AD Trace
Log
. Click Next.
Click Add. In the Event Trace Providers screen, click Active Directory Domain Services: Core. Click OK.
Click Next, note the directory to be used for the log, and then click Next again.
Click the “Start this data collector set now” radio button and click Finish.
Open a command prompt and run the following command:
tracerpt <LogFileName>
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.
Expand Data Collector Sets. Right-click User-Defined and click New→Data Collector Set.
In the Name text box, enter AD
Performance Alert
. Select the “Create manually” radio
button and click Next.
Click the Performance Counter Alert radio button and click Next.
Click Add. Select the counter that you wish to be alerted about. Click Add and click OK.
In the “Alert when:” drop-down box, click Above or Below. In the Limit text box, enter the threshold value that you wish to monitor. Click Next.
Click the “Start this data collector now” radio button. Click Finish.
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.
You want to create an alert that will notify an administrator via email if a performance alert is generated.
You can create a Windows scheduled task that runs the following PowerShell command. Then, the task can be called from a performance counter alert in Performance Monitor.
Send-MailMessage -SmtpServer "<ServerName>
" -From "<FromAddress>
" -To "<ToAddress>
" -Subject "<MessageSubject>
" -Body "<MessageBody>
"
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:
Date/time
The value that was measured by the alert
The name of the alert
The name of the counter being measured
The value of the limit that was exceeded
A manually defined text string
You can also use a number of third-party tools to implement this solution, such as the open-source Blat SourceForge project, which allows you to send SMTP or NNTP messages from a command line.
You want to enable auditing of directory access and modifications. Audit events are logged to the Security event log.
Open the Group Policy Management snap-in (gpmc.msc) and edit the Default Domain Controllers Policy.
In the left pane, expand Computer Configuration→Policies→Windows Settings→Security Settings→Local Policies and click on Audit Policy.
In the right pane, double-click “Audit directory service access.”
Make sure the box is checked beside “Define these policy settings.”
Check the box beside Success and/or Failure.
Click OK.
Alternatively, you can also use the Advanced Audit Policy Configuration settings, which allow for a bit more granularity:
Open the Group Policy Management snap-in (gpmc.msc) and edit the Default Domain Controllers Policy.
In the left pane, expand Computer Configuration→Policies→Windows Settings→Security Settings→Advanced Audit Configuration Policy and click on Audit Policies.
In the right pane, double-click “DS access.”
In the right pane, enable “Success and/or Failure auditing” for the Audit Directory Service Access and the Audit Directory Service Changes subcategories.
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 -
It can also be useful to enable Audit Account Management in the GPO that’s linked to the Domain Controllers OU. This provides additional information about account-management operations—for example, finding what account deleted a certain object.
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:
Event 4738 will be logged when an object is modified. In the case of a modify event, you will see the old value (e.g., the old description attribute) and the new value (e.g., the new description attribute).
Event 4720 will be logged when an object is created.
Event 4725 will be logged when an object is disabled.
Event 4740 will be logged when an object is locked out.
Event 4726 will be logged when an object is deleted.
To enable auditing of a Registry key on an individual domain controller, do the following:
Create a Group Policy Object (or edit an existing GPO) that enables settings under the following path: Computer Configuration→Policies→Windows Settings→Security Settings→Local Policies→Audit Policy:
Audit object access: Success
Audit object access: Failure
Link the GPO to the OU containing the DC that you wish to audit.
On the DC that you want to audit, open regedit.exe.
Navigate to the Registry key that you want to enable auditing on.
Right-click on the key and select Permissions. Click Advanced and select the Auditing tab.
Click Add to select a user or group to audit, then click OK. For Apply Onto, select “This key only,” “This key and subkeys,” or “Subkeys only.”
Under Access, select the actions that should be audited, and click OK.
If you need to enable auditing of the same Registry keys on multiple computers, a much more efficient solution would be to use a GPO as follows:
Create a Group Policy Object (or modify an existing GPO) that enables the following settings under Computer Configuration→Policies→Windows Settings→Security Settings→Local Policies→Audit Policy:
Audit object access: Success
Audit object access: Failure
Navigate to Computer Configuration→Policies→Windows Settings→Security Settings→Registry.
Right-click on Registry and select “Add key.” On the “Select Registry key” screen, navigate to the key that you want to audit and click OK.
Right-click on the key and select Permissions. Click Advanced and select the Auditing tab.
Click Add to select a user or group to audit, then click OK. For Apply Onto, select “This key only,” “This key and subkeys,” or “Subkeys only.”
Under Access, select the actions that should be audited, and click OK.
Link the GPO to the container containing the computers that you wish to audit.
The Advanced Audit Policy Configuration settings offer another way to audit the Registry. This method allows you to use a global object access audit policy, which provides for auditing without having to specify security access control lists (SACLs). For additional information, check out the “See Also” section of this recipe.
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.
You want to limit the number of objects a security principal can create in a partition by creating a quota.
> dsadd quota -part<PartitionDN>
-qlimit<QuotaLimit>
-acct<PrincipalName>
[-rdn<QuotaName>
]
The following command creates a quota specification that allows
the ADATUM
allen user to create only five
objects in the dc=adatum,dc=com
partition:
> dsadd quota -part dc=adatum,dc=com -qlimit 5 -acct ADATUM allen
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:
Currently, quotas can apply only to an entire partition. You cannot create a quota that pertains only to a subtree in a partition. You can create quotas for any partition, including application partitions, except for the schema naming context. The reasoning behind this restriction is that the schema is a highly protected area of the directory, and you shouldn’t need to restrict how many objects get created there.
A quota can be defined for any type of security principal.
The msDS-QuotaTrustee
attribute
on the quota object stores the target principal in the form of an
SID.
This determines how many objects the target security principal can create.
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.
Quotas do not apply to members of the Enterprise Admins and Domain Admins groups. Even if you’ve configured a default quota for all users, members of those administrative groups will not have any restrictions.
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
Connect to the partition on which you want to modify this setting. (This setting must be changed for each partition that you want to configure.)
In the left pane, expand the root of the partition.
Right-click on cn=NTDS
Quotas
and select Properties.
Set the msDS-TombstoneQuotaFactor
attribute to a
value between 0 and 100.
Click OK.
Create an LDIF file called change_ tombstone_quota.ldf with the following contents:
dn: cn=NTDS Quotas,<PartitionDN>
changetype: modify replace: msDs-TombstoneQuotaFactor msDs-TombstoneQuotaFactor:<1-100>
-
Then run the following command:
> ldifde -v -i -f change_tombstone_quota.ldf
You can also make the change using DSMod or AdMod. DSMod takes the following syntax:
> dsmod partition<PartitionDN>
-qtmbstnwt<1-100>
You can make the change with AdMod, as follows:
> admod -b<PartitionDN>
msDs-TombstoneQuotaFactor::<0-100>
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”
Connect to the partition you want to modify. (This setting must be changed for each partition that you want to configure.)
In the left pane, expand the root of the partition.
Set the msDS-DefaultQuota
attribute to the number of objects that security principals should
be allowed to create if they are not assigned another
quota.
Click OK.
Create an LDIF file called set_default_quota.ldf with the following contents:
dn: cn=NTDS Quotas,<PartitionDN>
changetype: modify replace: msDs-DefaultQuota msDs-DefaultQuota:<NumberOfObjects>
-
Then run the following command:
> ldifde -v -i -f set_default_quota.ldf
You can also make the change using DSMod or AdMod. DSMod takes the following syntax:
> dsmod partition<NTDS Quotas DN>
-qdefault<DefaultQuota>
You can make the change with AdMod, as follows:
> admod -b<NTDS Quotas DN>
msDs-DefaultQuota::<DefaultQuota>
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.
The quota usage of a security principal can be determined a few different ways. First, you can use DSGet. Here is an example:
> dsget user "<UserDN>
" -part<PartitionDN>
-qlimit -qused
This displays the effective quota limit and how much of the
quota has been used for a particular user. You can use similar
parameters with dsget computer
and
dsget group
to find the quota usage
for those types of objects.
Users can find their own quota usage by querying the msDs-QuotaUsed
and msDs-QuotaEffective
attributes on the
cn=NTDS Quotas
container for a
partition. These two attributes are constructed, which means they are
dynamically calculated based on the user that is accessing them (see
Finding Nonreplicated and Constructed Attributes for more on
constructed attributes). The msDs-QuotaUsed
attribute returns how much of
the quota has been used by the user, and the msDs-QuotaEffective
attribute contains the
quota limit.
Alternatively, view the msDs-TopQuotaUsage
attribute on a
partition’s cn=NTDS Quotas
container, which contains the users with the top quota usage. This
attribute is multivalued, with each value being XML-like text that
contains the SID and how much of the quota the principal has used. To
view the quota usage, use the following command:
Get-ADObject "cn=NTDS Quotas,<PartitionDN>
" -Properties msds-TopQuotaUsage
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
3.146.255.87