Tracking all LDAP activity on a specific DC is not trivial to achieve with the native toolset.  I recently posted an article over at ActiveDir.org that showed how to log all LDAP activity by enabling diagnostic logging and tweaking the inefficient and expensive LDAP search thresholds.  The article is available here:

http://www.activedir.org/article.aspx?aid=97

The problem with the approach shown in that article is its inability to help with LDAP failures.  For example, the information logged will not show LDAP failures due to protocol errors.

When troubleshooting an application that is exhibiting LDAP problems another alternative is to trace the activity at the network level using tools such as Ethereal or Microsoft's NetMon.  The information available with tracing is certainly detailed, but troubleshooting problems can be a little like finding a needle in a haystack, especially if the data is encrypted over an SSL connection.  You could also look at command line tools such as LogMan and TraceRpt.

Last year Microsoft published version 2.0 of the Server Performance Advisor (http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en).  The main function of the tool is performance diagnostics and it has the ability to provide specialised reports, including a System Overview and reports for server roles such as Active Directory, Internet Information System (IIS), DNS, Terminal Services, SQL, print spooler, and others.  I recently started looking at the tool to see what its capabilities were in regard to Active Directory.  What I've seen so far has been very impressive.  I've only scratched the surface of the capabilities of the tool and already it's paying dividends.  Perhaps the most useful feature I've found so far is the ability to trace LDAP activity, as described in the remainder of this article. 

Once you have downloaded and installed the tool on the target Domain Controller, start it up and enable the Scope Tree view as shown below.

Expand the Tree to show the Data Collectors and Reports item.  Right-click Active Directory and select Properties, as shown below.

In the Properties window change the Expert Level in the Reports section to 10.  This is the maximum value and ensures that the diagnostic reports show the maximum amount of detail.  This is an important step - without it you will not be able to see the required level of LDAP activity in the report.  [Thanks are due here to Steve Linehan at Microsoft for giving me this tip - thanks Steve ]

At this point you are ready to start recording activity on the local DC.  To do this highlight Active Directory in the Tree view and click the green arrow in the top left hand corner (F9 will also work).  You will see a progress bar appear at the bottom of the SPA window.  The default recording time is 500 seconds, but you can change this on the Schedule tab of the Active Directory properties (in Tree view).

At this point you should run your LDAP searches against the DC.  Note that the amount of information being gathered is large and will itself generate a performance impact on the system. 

When the recording has completed SPA will automatically generate a report.  This can take some time, during which you will see the following text in the notification area. Again, the CPU overhead for the data analysis is high, so you might consider running the reports on another machine (SPA supports running the data analyser on a separate machine, but the data collection must be done locally).

When the reprot has been generated, navigate to the Current report in the Tree view.

As you can see there is a significant amount of information to browse through, as can be seen in the list of Active Directory report options below.

Click on Unique Searches to go to the section of the report showing all LDAP searches.  You should be able to see the search you issued during the recording by browsing through the full list of searches.  Be aware that there might be a very large number of searches, especially on a production DC.

The level of detail for each search is impressive.  You will see the requesting client (resolved name or IP address), the base DN, the search scope (deep = subtree), the search filter, the number of objects visited and returned...and a fair bit more.

I find the report format quite hard to navigate because of the amount of information generated.  As an alternative you have the option to open the raw XML file (AD.XML) by opening the folder that contains the traces and reports.

If you open the XML file in Notepad (or editor of choice) you can easily find your LDAP search of interest.  A sample extract from the AD.XML file is shown below.

<item level="1">

        <data name="Client" note="Address 192.168.5.67">W2K3R2TPL</data>

        <data name="Choice">deep</data>

        <data name="ObjDn">DC=north,DC=com</data>

        <data name="Filter">( A (objectClass=user) (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=north,DC=com) (sAMAccountName=a*) )</data>

        <data name="Index">idx_objectCategory:7:N;</data>

        <data name="DsSimpleStatus">Success</data>

        <data name="ObjVisited">7</data>

        <data name="ObjReturned">2</data>

        <data name="requestRate">0.01</data>

        <data name="responseTime">75</data>

        <data name="cpu">0.00</data>

      </item>

In this extract the information shows that the LDAP search was issued by a computer named W2K3R2TPL with an IP address of 192.168.5.67.  The search base was DC=north,DC=com and it was a subtree search.  The filter was (&(objectClass=user)(objectCategory=Person)(sAMAccountName=a*)).  The search was successful, visiting 7 objects and returning 2 results.   Also, it is clear that the DC was not overly taxed making the search as the cpu time didn't register above 0.00.

This example shows a normal, successful search, but the information captured could just as easily have flagged a problem, either with the success of the search, unusually high CPU time, high number of objects visited, etc.

The Server Performance Advisor (SPA) is capable of much more than tracking LDAP activity and it is certainly worth spending more time exploring the feature set.  As a starting point I would recommend looking at MVP Gil Kirkpatrick's session on AD performance here:

http://www.netpro.com/community/medialibrary.cfm.

Tony

www.activedir.org

I was recently asked whether it is possible to add users to groups using the Restricted Groups feature of Group Policy using the Member Of feature.  Now, unlike Darren Mar-Elia (http://www.gpoguy.com/), I am no Group Policy guru, so I was forced to visit my test lab to obtain the answer.  What I found surprised me.  It is in fact possible to do this – and not in the way you might expect.

What nearly everyone knows about Restricted Groups.

The main way in which people use Restricted Groups is to enforce membership of a given group.  It’s an all or nothing setting that will throw out existing members of the group and replace them with whatever you have in the restricted group (with the exception of built-in accounts).  Here’s an example.

The main limitation with this method is that, when used for setting membership of local groups on member servers and workstations, it does not allow you to easily make exceptions.  For example, you might want to set the membership of the Administrators local group on all member servers, but for only the Exchange servers you need to also need to include the Nasty3rdPartyApp group.  To do this you would either have to:

1. Put the Exchange servers in a new OU and link a GPO with a Restricted Group setting that includes the Nasty3rdPartyApp group.
2. Keep the Exchange servers in the same OU and use security filtering to force the Exchange servers to receive a different Restricted Group setting from a new GPO.
3. Stop using Restricted Groups and set the group membership for different server types using a startup script.

What not so many people know about Restricted Groups

If you want a group to contain a specific group as a member, but are not concerned about controlling the overall membership of the group then you can use the Member Of feature of Restricted Groups.  This is useful, for example, if you have a Global security group called ServerAdmins and you want it to be a member of the local Administrators group on all member servers.

What very few people know about Restricted Groups

When using the Member Of feature, everything about it suggests that you can only use it to add groups as members of other groups (the giveaway here is the Add Group dialog!). 

But what if you want to force the inclusion of a user account as a member of a group using Restricted Groups?  No possible?  Well, actually it is.  Here's how to do it.

In the Add Group dialog, type the name of the user account and click OK.  Add name of the group to which you want to add the user as member in the box labelled This group is a member of.  The screenshots below show two examples, one with a domain user account (COLOURS\bobj) being made a member of the Domain Admins group, and the second with a local user account (athurm) being made a member of the Administrators local group.

So what’s the catch?

The problem is that you can only use this method to make local user accounts members of local groups or domain accounts members of domain groups.  You can’t (well, I couldn’t) use this method to add a domain account to a local group. I’m not sure whether this undocumented capability with regard to user accounts was envisaged by Microsoft or not, but it might help you if you like using Restricted Groups to manage group memberships.

Tony

http://www.activedir.org/

Sign up for the Active Directory Discussions mailing list (http://www.activedir.org/List.aspx)!

I recently came across a fairly serious DNS issue.  Here's what had happened.

A customer had decided to add a new DC.  They had run DCPROMO and everything ran without a hitch.  After the reboot they thought that it would be good to enable the DC as a DNS server (fair enough).  The existing zone was AD-integrated. 

Here's where things went awry.  There are a couple of ways in which a DC can be made a DNS Server.  The one that is probably most familiar to us is to go to Control Panel -> Add/Remove Programs -> Add/Remove Windows Components -> Networking Services -> Details -> Domain Name System (DNS).

This method would have been fine.

The alternative method is to use the Configure Your Server Wizard to add a role, as shown below.

At the next screen (after simply selecting Next above) things get a little tricky.  All you want to do is to install DNS Server on this machine.  That's it.  Finshed.  Nothing else to do, because we know AD Integrated DNS will simply replicate the zone infromation to our new DC without any other effort required.  But the wizard doesn't know this and so tries to be helpful by suggesting you do something else (see below) when you select Next.

Clicking Cancel at this point will achieve the desired result.  Unfortunately, my customer became confused and went ahead and created the forward lookup zone THAT ALREADY EXISTED.  The effect of this was to overwrite the existing zone information.  Oops - not good.

Personally, I think it would be helpful if the wizard offered an extra option in the screen above.  For example, something that says, "This is a DC in an existing forest with these AD integrated zones (X, Y and Z) already configured."

Tony

www.activedir.org