Active Directory Cookbook for windows server 2003- P48 potx

15.9.4 See Also Recipe 4.3 for using a LDAP controls, Recipe 4.5 for searching for objects, Recipe 10.13 for more on ANR, and Recipe 15.8 for more on expensive and inefficient searches

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

15.8.4 See Also

Recipe 15.2 for enabling diagnostics logging

Recipe 15.9 Using the STATS Control to View LDAP Query Statistics

15.9.1 Problem

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

15.9.2 Solution

15.9.2.1 Using a graphical user interface

1 Open LDP

2 From the menu, select Connection Connect

3 For Server, enter the name of a domain controller (or leave blank to do a serverless bind)

4 For Port, enter 389

5 Click OK

6 From the menu, select Connection Bind

7 Enter credentials of a user to perform the search

8 Click OK

9 From the menu, select Options Control

10 For the Windows Server 2003 version of LDP, you can select Search Stats from the Load Predefined selection For Windows 2000, add a control with the OID

1.2.840.113556.1.4.970

11 Click OK

12 From the menu, select Browse Search

13 Enter your search criteria and then click the Options button

14 Under Search Call Type, be sure that Extended is selected

15 Click OK and Click Run

15.9.3 Discussion

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 if 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:

***Searching

ldap_search_ext_s(ld, "cn=users,DC=rallencorp,DC=com", 2,

"(objectcategory=group)",

attrList, 0, svrCtrls, ClntCtrls, 20, 1000 ,&msg)

Result <0>:

Matched DNs:

Stats:

Call Time: 10 (ms)

Entries Returned: 17

Entries Visited: 17

Used Filter:

(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=rallencorp,DC=com)

[RETURN]

Used Indexes: INTERSECT_INDEX:17:I;

A couple things are worth noting here First, the search visited only 17 entries and ended up returning all 17 In terms of the definitions defined in Recipe 15.8, this query is both inexpensive and efficient You can also see that the filter that I used, (objectcategory=group), was

expanded to (objectCategory=CN=Group,CN=Schema,

CN=Configuration,DC=rallencorp,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 I'll perform an ANR search for "Jim Smith":

***Searching

ldap_search_ext_s(ld, "ou=Sales,DC=rallencorp,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 I 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 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 Recipe 10.13 The point of showing this is that the STATS control is very powerful and can be an invaluable tool when trying to troubleshoot or optimize LDAP queries

15.9.4 See Also

Recipe 4.3 for using a LDAP controls, Recipe 4.5 for searching for objects, Recipe 10.13 for more on ANR, and Recipe 15.8 for more on expensive and inefficient searches

Recipe 15.10 Using Perfmon to Monitor AD

15.10.1 Problem

You want to use Perfmon to monitor the performance of Active Directory

15.10.2 Solution

15.10.2.1 Using a graphical user interface

1 Open the Performance Monitor

2 Click on System Monitor in the left pane

3 Type Ctrl + I This will bring up the page to add counters

4 Under Select counters from computer, enter the name of the domain controller you want

to target

5 Select the NTDS performance object

6 Select the counters you want to monitor

7 After you done with your selections, click Close

15.10.3 Discussion

There are several Perfmon 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, Kerberos authentication, and the Security Account Manager (SAM)

Here is a list of some of the most useful NTDS counters I've also included their Perfmon

explanation, which you can view by clicking on the Explain button in the Add Counters dialog box

DRA Inbound Bytes Total/sec

Shows the total number of bytes replicated in It is the sum of the number of

uncompressed bytes (never compressed) and the number of compressed bytes (after compression)

DRA Inbound Objects/sec

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

DRA Inbound Values Total/sec

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 Zero values indicates property removal

DRA Outbound Bytes Total/sec

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)

DRA Outbound Objects/sec

Shows the number of objects replicated out

DRA Outbound Values Total/sec

Shows the number of object property values sent to outbound replication partners

DRA Pending Replication Synchronizations

Shows the number of directory synchronizations that are queued for this server, but not yet processed

DS Client Binds/sec

Shows the number of Ntdsapi.dll binds per second serviced by this DC

DS Directory Reads/sec

Shows the number of directory reads per second

DS Directory Searches/sec

Shows the number of directory searches per second

DS Directory Writes/sec

Shows the number of directory writes per second

KDC AS Requests

Shows the number of Authentication Server (AS) requests serviced by the Kerberos Key Distribution Center (KDC) per second AS requests are used by client to obtain a ticket-granting ticket

KDC TGS Requests

Shows the number of Ticket Granting Server (TGS) requests serviced by the KDC per second TGS requests are used by the client to obtain a ticket to a resource

Kerberos Authentications

Shows the number of times per second that clients use a ticket to this DC to authenticate

to this DC

LDAP Bind Time

Shows the time, in milliseconds, taken for the last successful LDAP bind

LDAP Client Sessions

Shows the number of currently connected LDAP client sessions

LDAP Searches

Shows the percentage of directory searches coming from LDAP

LDAP Searches/sec

Shows the rate at which LDAP clients perform search operations

LDAP Successful Binds

Shows the percentage of LDAP bind attempts that are successful

LDAP Successful Binds/sec

Shows the number of LDAP binds per second

LDAP Writes

Shows the percentage of directory writes coming from LDAP

LDAP Writes/sec

Shows the rate at which LDAP clients perform write operations

Recipe 15.11 Using Perfmon Trace Logs to Monitor AD

15.11.1 Problem

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

15.11.2 Solution

1 Open the Performance Monitor

2 In the left pane, expand Performance Logs and Alerts

3 Right-click on Trace Logs and select New Log Settings

4 Enter a name for the log and click OK

5 Click the Add button

6 Highlight one or more of the Active Directory providers and click OK

7 Use the tabs to configure additional settings about the log

8 When you are done, click OK

9 Unless you've scheduled it to run at a different time, the trace log you created should show up in the right pane next to a green icon, which indicates it is running

10 To stop the Trace Log, right-click on it in the right pane and select Stop

11 Now open up a command shell (cmd.exe)

12 Use cd to change into the directory where the trace log files are stored (c:\perflogs by

default)

13 Run the following command:

> tracerpt <LogFileName>

This command is available by default with Windows Server 2003 On Windows 2000, you'll need to use the Resource Kit utility called tracedmp.exe

The tracerpt command generates a summary.txt file that summarizes all of the events by total

A second file called dumpfile.csv is created that can be imported into Excel or viewed with a text

viewer to show the details of each event

15.11.3 Discussion

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 and even figuring out the inner-workings of Active

Directory Trace Logs can be resource intensive, so you should enable them with care

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_000001.etl

Total Buffers Processed 5

Total Events Processed 193

Total Events Lost 0

Start Time Friday, May 23, 2003

End Time Friday, May 23, 2003

Elapsed Time 24 sec

+ -+

|Event Count Event Name Event Type Guid

|

+ -+

| 1 EventTrace Header

{68fdd900-4a3e-11d1-84f4-0000f80464e3}|

| 69 SamNameById Start

{25059476-899f-11d2-819e-0000f875a064}|

| 69 SamNameById End

{25059476-899f-11d2-819e-0000f875a064}|

| 2 KerbInitSecurityContext End

{52e82f1a-7cd4-47ed-b5e5-fde7bf64cea6}|

| 2 KerbInitSecurityContext Start

{52e82f1a-7cd4-47ed-b5e5-fde7bf64cea6}|

| 1 KerbAcceptSecurityContext Start

{94acefe3-9e56-49e3-9895-7240a231c371}|

| 1 KerbAcceptSecurityContext End

{94acefe3-9e56-49e3-9895-7240a231c371}|

| 1 SamGetAliasMem Start

{1cf5fd19-1ac1-4324-84f7-970a634a91ee}|

| 1 SamGetAliasMem End

{1cf5fd19-1ac1-4324-84f7-970a634a91ee}|

| 14 LdapRequest End

{b9d4702a-6a98-11d2-b710-00c04fb998a2}|

| 14 LdapRequest Start

{b9d4702a-6a98-11d2-b710-00c04fb998a2}|

| 1 DsLdapBind Start

{05acd009-daeb-11d1-be80-00c04fadfff5}|

| 1 DsLdapBind End

{05acd009-daeb-11d1-be80-00c04fadfff5}|

| 8 DsDirSearch End

{05acd000-daeb-11d1-be80-00c04fadfff5}|

| 8 DsDirSearch Start

{05acd000-daeb-11d1-be80-00c04fadfff5}|

+ -+

Here you can see that over a 24-second period there was 1 LDAP bind request (DsLdapBind), 8

directory searches (DsDirSearch), and 14 total LDAP requests (LdapRequest)

The dumpfile.csv contains entries for every event that was generated during the time period Here

is an example of an entry for one of the DsDirSearch requests (note that the lines will wrap due

to their length so I've added a blank line in between for separation):

DsDirSearch, Start, 0x000003F4, 126982224636242128, 61350, 440530, "DS", 3, 3,

1141178432, 2694848000, "192.168.5.26", "deep",

"OU=Sales,DC=rallencorp,DC=com", "0,

0

DsDirSearch, End, 0x000003F4, 126982224636342271, 61350, 440540, "DS", 3, 5,

1157955648, 2694848000, "0", "

(&(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=rallencorp,DC=com) (objectClass=user)) 0, 0

Based on just those two lines (disregarding most of the numeric values), we can deduce that a user on the host with IP address 192.168.5.26 performed an LDAP query for user objects in the

Sales OU Pretty neat, huh?

15.11.4 See Also

MS KB 302552 (HOW TO: Create and Configure Performance Monitor Trace Logs in Windows 2000)

Recipe 15.12 Enabling Auditing of Directory Access

15.12.1 Problem

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

15.12.2 Solution

15.12.2.1 Using a graphical user interface

1 Open the Domain Controller Security Policy snap-in

2 In the left pane, expand Local Policies and click on Audit Policy

3 In the right pane, double-click Audit directory service access

4 Make sure the box is checked beside Define these policy settings

5 Check the box beside Success and/or Failure

6 Click OK

15.12.2.2 Using a command-line interface

> auditpol \\<DomainControlerName> /enable /directory:all

15.12.3 Discussion

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 Domain Controller Security GPO with the Audit directory service access setting Once this 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 it 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 the

Everyone auditing and apply more specific auditing, or keep a close eye on your domain

controllers to ensure they are not adversely affected while auditing is enabled

Here is an example event that was logged after the Administrator account created a contact

object called foobar in the Sales OU:

Event Type: Success Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Date: 5/26/2003

Time: 7:24:10 PM

User: RALLENCORP\administrator

Computer: DC1

Description:

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: organizationalUnit

Object Name: OU=Sales,DC=rallencorp,DC=com

Handle ID: -

Primary User Name: DC1$

Primary Domain: RALLENCORP

Primary Logon ID: (0x0,0x3E7)

Client User Name: administrator

Client Domain: RALLENCORP

Client Logon ID: (0x0,0x3B4BE)

Accesses: Create Child

Properties:

Create Child

contact

Additional Info: CN=foobar,OU=Sales,DC=rallencorp,DC=com Additional Info2: CN=foobar,OU=Sales,DC=rallencorp,DC=com Access Mask: 0x1

It can also be useful to enable Audit Account Management in the Domain Controller Security GPO This provides additional information about account management operations, for example, finding what account deleted

a certain object

15.12.4 See Also

MS KB 232714 (HOW TO: How to Enable Auditing of Directory Service Access), MS KB

314955 (HOW TO: Audit Active Directory Objects in Windows 2000), MS KB 314977 (HOW

TO: Enable Active Directory Access Auditing in Windows 2000), and MS KB 814595 (HOW TO: Audit Active Directory Objects in Windows Server 2003)