tonymurray

Event logs and the "Maximum security log size" Group Policy setting

tonymurray — Fri, 01 Sep 2006 19:22:00 GMT

A post yesterday on ActiveDir.org reminded me of something I learnt recently about event logging and, in particular, how certain Group Policy settings can cause problems and inconsistencies. The customer I was working with had implemented an entry in the Default Domain Controllers Policy to set the value for the Maximum security log size to 4194240 KB (4GB). This is the largest value that can be set. I was assisting with investigating a security incident and we were surprised to find that the security event logs on the DCs did not contain the audit entry we were looking for. Events were being overwritten after approximately 3 days. I figured this was unusual given that the security event log size had been configured to 4GB. That's when I got a surprise - the size of the security event logs on the DCs was on average about 380MB. In other words, considerably smaller than the 4B configured by Group Policy.

At first I thought the issue must be with Group Policy not applying, so I did some troubleshooting around that. That turned out to be a blind alley as everything seemed to be applying successfully. I then spent some time with my good friend Mr. Google and eventually we found the answer. The issue has to do with the event log service using memory mapped files. There is apparently an architectural limitation common to all current versions of Windows with regard to memory-mapped files. No process can have more than 1GB of memory-mapped files in total, which means that all of the services that run under the services.exe process must share the 1GB pool. This implies that not only can the Maximum security log size not get anywhere near the 4GB mark, but that all event logs need to come in well under the 1GB limit to allow room for the other memory mapped services.

The recommendations for setting the event log sizes are made in the following two Microsoft web pages:

http://www.microsoft.com/technet/security/topics/serversecurity/tcg/tcgch06n.mspx

http://technet2.microsoft.com/WindowsServer/en/library/5a86ab0f-c7eb-45ed-9e5e-514173bf15e31033.mspx?mfr=true

The most relevant quote for me from these articles was this:

"On domain controllers, the combined size of these three logs — plus the Directory Service, File Replication Service, and DNS Server logs — should not exceed 300 MB."

Note that on my customer's DCs the security event log by itself was on average about 380MB, which was clearly in the red zone and didn't leave much left for the other memory mapped services.

Well, the bottom line is that I re-configred the Group Policy for my customer to a much more sensible maximum, so the end result was positive. On the downside, I still feel bemused that Group Policy actually allows the limit to be set to 4GB for an individual log. Surely, this makes no sense given the recommendation around 300MB, especially as this information is not easy to find. As an example, Windows Server 2003 SP1 includes a modification in gpedit.msc (the Group Policy editor) that, when configuring the Maximum security log size, shows a warning and a pointer (see screenshot above) to a KB article (823659). Sounds good doesn't it - this article will give us the information about how to conigure the appropriate maximum sizes, right? Well, no - actually the article is generally unnecessarily wordy and, in relation to the security event log settings, only mentions the 4GB maximum and a health warning about using the Shut down system immediately if unable to log security audits setting. Mmm.

Tony

www.activedir.org

Join the Active Direcotry Discussions mailing list: http://www.activedir.org/List.aspx

Troubleshooting LDAP issues with Server Performance Advisor (SPA)

tonymurray — Fri, 25 Aug 2006 22:15:00 GMT

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.

        <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

New ActiveDir.org RSS Feed

tonymurray — Wed, 23 Aug 2006 20:51:00 GMT

We recently added a new RSS feed on ActiveDir.org for the mailing list.

http://www.activedir.org/Rss/Rss.aspx?opt=ml

It's updated hourly with newly archived mailing list posts.

I realise that this is not going to be very everyone, especially those that are already subscribed to the mailing list, but it could be useful for people who have problems with the volume of traffic on the list, as well as those with a general interest.

I've noticed that the performance isn't optimal at the moment - I've seen a few time-outs when opening the archived mail items, so will be looking into that.

It would be good to know your thoughts.on the RSS feed. Is it working for you? Is it useful? What else would you like to see? Post your comment here or email me (tony [at] activedir.org)

Oh, and, yes, we know the search feature on the mail archive page sucks. We're working on that too .

Tony

Restricted Groups Quirkiness

tonymurray — Fri, 18 Aug 2006 03:36:00 GMT

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:

Put the Exchange servers in a new OU and link a GPO with a Restricted Group setting that includes the Nasty3rdPartyApp group.
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.
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/

How to search for groups of different type and scope

tonymurray — Tue, 08 Aug 2006 08:51:00 GMT

Searching AD for groups using LDAP can be tricky as it often involves using the groupType attribute, which requires a bitwise filter. Another attribute that can be useful is the sAMAccountType attribute, but you need to be careful as Universal and Global groups share the same values. You should also ensure that you use the Global Catalog when searching for Universal Groups. This blog post provides advice on searching for groups and provides specific examples using AdFind (http://www.joeware.net/win/free/tools/adfind.htm).

The table below shows the information of interest when searching for different types of group. Note that the sAMAccountType attribute may not be unique to the Group Type (see items in red and green bold).

Group Scope	Group Type	groupType value	sAMAccountType attribute
Universal	Distribution	8	268435457
Universal	Security	-2147483640	268435456
Global	Distribution	2	268435457
Global	Security	-2147483646	268435456
Domain Local	Distribution	4	536870913
Domain Local	Security	-2147483644	536870912

The following sections provide advice on how to search for groups together with examples.

Find all groups

LDAP Filter:

(objectcategory=group)

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -f "(objectcategory=group)"

Find all Universal Distribution groups

LDAP Filter:

(&(objectcategory=group)(sAMAccountType=268435457)(grouptype:1.2.840.113556.1.4.804:=8))

e.g.

adfind –gc -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(sAMAccountType=268435457)(grouptype:OR:=8))" 1.1

Find all Universal Security groups

LDAP Filter:

(&(objectcategory=group)(grouptype:1.2.840.113556.1.4.803:=-2147483640))

e.g.

adfind –gc -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(grouptype:AND:=-2147483640))" 1.1

Find all Universal groups: Distribution and Security

LDAP Filter:

(&(objectcategory=group)(grouptype:1.2.840.113556.1.4.804:=8))

e.g.

adfind -gc -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(grouptype:OR:=8))" 1.1

Find all Global Distribution groups

LDAP Filter:

(&(objectcategory=group)(sAMAccountType=268435457)(grouptype:1.2.840.113556.1.4.804:=2))

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(sAMAccountType=268435457)(grouptype:OR:=2))" 1.1

Find all Global Security groups

LDAP Filter:

(&(objectcategory=group)(grouptype:1.2.840.113556.1.4.803:=-2147483646))

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(grouptype:AND:=-2147483646))" 1.1

Find all Global groups: Distribution and Security

LDAP Filter:

(&(objectcategory=group)(grouptype:1.2.840.113556.1.4.804:=2))

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(grouptype:OR:=2))" 1.1

Find all Domain Local Distribution groups

LDAP Filter:

(&(objectcategory=group)(samaccounttype=536870913))

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -f "(&(objectcategory=group)(sAMAccountType=536870913))" 1.1

Find all Domain Local Security groups

LDAP Filter:

(&(objectcategory=group)(samaccounttype=536870912))

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -f "(&(objectcategory=group)(sAMAccountType=536870912))" 1.1

Find all Domain Local groups: Distribution and Security

LDAP Filter:

(&(objectcategory=group)(grouptype:1.2.840.113556.1.4.804:=4))

e.g.

adfind -b "OU=Groups,DC=colours,DC=com" -s subtree -bit -f "(&(objectcategory=group)(grouptype:OR:=4))" 1.1

Tony

www.activedir.org

Enabling a new DC as a DNS Server - a cautionary tale.

tonymurray — Mon, 07 Aug 2006 09:28:00 GMT

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