eXtreme. tech. : Active Directory

ADMX policy missing or blank - bug

David Tesar — Sat, 11 Apr 2009 02:48:00 GMT

When you create a policy with a custom ADMX template which uses a registry key outside of the standard 4 recommended locations (below) and open up your group policy editor using gpedit.msc, the policy will not be listed and you will get no error. The workaround is to use the group policy editor which comes with the group policy management console (i.e. right click on a policy in the GPMC.msc and choose edit). This one wasted a bunch of my time wasted, so hopefully you don’t have to go through the same.

Recommended Group policy locations:

HKLM\Software\Policies (computer settings, the preferred location)

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (computer settings, an alternative location)

HKCU\Software\Policies (user settings, the preferred location)

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (user settings, an alternative location)

One other note - this bug appears to have already been fixed in Win7 & Server 2008 R2.

Windows Server 2008 – AD Auditing Enhancements

David Tesar — Thu, 29 Nov 2007 03:50:00 GMT

I hope this post will act as a good reference point to be able to quickly understand the good and bad about new AD auditing enhancements and then enable you to dive deeper at will using the links in this article.

There’s nothing more exciting than auditing right? Well, check this out and hopefully it will spark some interest.

In Windows Server 2003 R2 and prior, the auditing of active directory certainly has not been a strong point. You would enable or disable global AD auditing for success or failures, set a SACL on the objects you wanted to monitor, and then typically one or both of the following would happen:

Your security event log fills up with way more security events than you’d ever hoped for, possibly wrapping or ballooning the size of the security log.
Auditing doesn’t actually provide enough information for you to make any use of the events which are recorded in the security event log. i.e. it only says who was successful at modifying the object, but nothing on the details of the value(s) which were changed.

In Server 2008, we are on a good path to fix this pain. Some of the key improvements to AD auditing are as follows:

You can limit the number of attributes which are audited for object types. For instance, you only want to know if the Employee’s Pay Level attribute is modified for all user accounts and nothing else.
Auditing is now broken into four categories: Access (same as 2000/2003), Changes, Replication, and Detailed Replication. The most interesting come from the new changes category:

AD DS logs the previous and current values of the attribute. If the attribute has more than one value, only the values that change as a result of the modify operation are logged.
If a new object is created, values of the attributes that are populated at the time of creation are logged.
If an object is moved, the previous and new location (distinguished name) is logged for moves within the domain. When an object is moved to a different domain, a create event is generated on the domain controller in the target domain.
If an object is undeleted, the location where the object is moved to is logged.

What are the downfalls?

You have to modify the schema in order to limit the number of attributes which are audited per object type. This isn’t really difficult, but it would be nice if there were some friendlier type way to do it.
You cannot view or modify the audit policy subcategories with the Local Group Policy Editor (GPedit.msc). You can only do this with the command-line tool Auditpol.exe.
As far as I can tell, you can’t limit auditing to different specific attributes for a subset of the same type of object. For instance, you would like to audit attributes X, Y, Z for all admin user accounts, but only attribute X for all regular user accounts. Of course you have some control over this with your SACLs…

Get Started:

A screencast on How to enable granular AD auditing in WS08 (coming in the future from me
Windows Server 2008 Auditing AD DS Changes Step-by-Step Guide
TechNet - AD DS: Auditing
Windows Networking Site AD enhancements overview
MS Directory Services Team Blog Posts on:
WS08 Auditing Enhancements and Cool Auditing Tricks in Vista and 2008

Please comment on the same post on TechNet Edge.

Technorati tags: Windows Server 2008, AD, Active Directory, Auditing

Analysis of Windows Server 2008 – AD Snapshot Viewer

David Tesar — Thu, 18 Oct 2007 18:36:00 GMT

This feature is currently known as the “Database Mounting Tool” (DMT), which is better than the previous name of “Data Mining Tool”. Who knows what we’ll end up calling this at RTM, but I like the previous name “Snapshot Viewer” the best so this is what I entitled the post.

DMT allows you to quickly take snapshots of your AD database at any point in time and view those snapshots using the LDP viewer of your choice. At first I was extremely excited about this feature, but after realizing the command-line action you have to go through in order to do this (see below), it killed my buzz a little bit. If you compare this to automating ldifde/csvde backups of your AD, I can see these advantages to snapshots:

You can mount a snapshot and attach GUI LDP tools to it. Ldifde/csvde method doesn’t do this.
You can “backup” the entire database in one shot. Ldifde/csvde only allows a single DN or partition per shot.
The ldifde/csvde dump of your entire partition is in clear text and snapshots are not. However, from a security standpoint there’s not much difference considering if someone has the snapshot file they can also open it up but not as easily.

Below is a general process flow for recovering deleted object(s) more quickly using DMT (see step-by-step guide for more details):
1) Create a snapshot of your AD database using the ntdsutil snapshot sub-context menu system.
Note: This can be automated if you so choose.

2) Mount the snapshot of your choice by using ntdsutil snapshot sub-context menu system again.

3) Make this snapshot readable by LDP, ADSIedit, AD Users and Computers (ADUC or dsa.msc), or other LDAP viewers using dsamain.exe (new tool included with WS2008 by default)
Note: At this point, you can view any object/attribute/etc of the snapshot to use for comparison.

Two paths to restore objects (using only MS tools):
4) Export/import the information from the snapshot to recover objects using ldifde/csvde:
a. Utilize the tombstone reanimation process (same as in Server 2003) to recreate the object(s) which were deleted. The ADRestore tool also helps here. b. Restore metadata such as back-links, attributes, etc for those objects by utilizing ldifde

5) Do an authoritative restore of a portion of the objects using NTDSutil (same way as you would in Server 2003). You can restore objects which haven't been already deleted from a DC (i.e. replication hasn't come to this DC yet) via using the restartable AD feature.

Bottom line: DMT is a nice feature to be able to view previous snapshots of your AD, but overall our restore story still doesn't help as great as some of the 3^rd party tools do with AD object recovery (see below).

GET STARTED:
Database Mounting Tool Feature Overview
Step-by-Step Guide for Using the Active Directory Database Mounting Tool in Windows Server 2008
Ntdsutil snapshot command line syntax
Dsamain command line syntax
Microsoft Sysinternal ADRestore tool

Quest’s AD recovery tools
Scriptlogic's Active Administrator

Server 2008 Password Policies - PSOs

David Tesar — Thu, 09 Aug 2007 03:06:00 GMT

In Server 2003 or R2 one of the major limitations was the ability to only have one password policy per domain. The product team realized this was a major pain point for many customers, so they hooked Server 2008 up with some new password policy functionality which is available in Beta 3.

In Server 2008, we’ve created the concept of password settings objects or PSOs. Every PSO contains all of the same password-related information you’re familiar with in server 2000/2003 such as lockout duration, minimum password age, etc.

A cool common use scenario: All domain administrators have a more complex password policy while the rest of the users in the domain have a less-restrictive password policy.

So what are some things you can do now with Password policies (PSOs)?
1. Create and link as many PSOs as you’d like
2. Link a PSO to one or more users or global security groups
3. Override a PSO applied to individual user(s) in a group with a different PSO via “ExceptionalPSOs”
4. Create a precedence for the PSO (so one will have a higher priority than another)
5. Delegate who can link or modify individual PSOs to specific users or groups. (Only Domain Admins can create PSOs.)
6. Hide the Password policy settings from the user
7. PSOs do not interfere with custom password filters

What are some of the downfalls?
1. No official Microsoft GUI to set up the policies. There is a 3^rd party tool to do this (link below), but otherwise you’ll have to use ADSIedit to create and manage PSOs.
2. Inability to assign a PSO to a computer or directly to an OU. However, you can assign a “shadow group” to the OU and then manually or script the addition/removal of members who reside in that OU to the shadow group.
3. You must be in Server 2008 domain functional level (all DCs running Server 2008 in the domain). Not surprising, but should be pointed out in case you were thinking you could roll this out in a mixed 2003/2008 domain.

GET STARTED

Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration

Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008 – Page 83

Video Screencast of editing the PSOs manually (no GUI tools)

Command Line Tool to create and manage PSOs (Joeware)

SpecOps GUI tool for PSOs

GUI tool which uses powershell comandlets to manage PSOs by Quest

Fine Grain Password Policy Tool - Another GUI Tool created by a Microsoft Employee

Blog post with Powershell examples on managing PSOs

Get Server 2008 Beta 3