Ask the Directory Services Team

New Directory Services KB Articles/Blogs 10/25-10/31

2009-11-04T16:03:59Z

975830	The memory usage of the Dns.exe process keeps increasing after you install hotfix 941672 on a computer that is running Windows Server 2003 SP2 and that has the DNS server role installed
972622	The Active Directory Application Mode index may become corrupted if you search the instance by using the LDAP virtual list view control
975792	Numeric host names cannot be resolved on a computer that is running Windows Vista or Windows Server 2008
969371	Error message when you run a command at the Command Prompt window in Windows Server 2008 Server Core: "The specified service does not exist as an installed Service"
975943	Error code when an application uses the CredSSP if the authenticated user account is a member of many security groups on a computer that is running Windows Vista or Windows Server 2008: "0x80090329"
976921	A DFSR propagation report logs the following error on a Windows Server 2008 domain controller: "Cannot open test file on the member The network path was not found."
976922	The "Run only allowed Windows applications" Group Policy setting displays no entries on a computer that is running Windows Vista, Windows Server 2008, or Windows 7
968929	Description of the Windows Management Framework on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
974522	A LDAP simple bind action fails on a domain controller that is running Windows Server 2008 if the distinguished name of the user account exceeds 256 characters
976427	Computers that are running Windows 7 or Windows Server 2008 R2 stop responding at a black screen if a screen saver is enabled
977110	How to select time zone for countries or regions that are not listed in Windows time zone list

Blogs

Explanation of the Remote Desktop Services CAL Upgrade behavior in Windows Server 2003 and Windows Server 2008

DFS Referrals and IPv6: Outta site!

How to Decommission an ADAM/ADLDS server and Add Additional Servers

Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains

Learn more about system image backup

Quick, Dirty, Super-Useful Scripting

Remote Desktop Load Simulation Toolset

DNSSEC Security Guide – update now available

Free MS Press ebook: Introducing Windows Server 2008 R2

Snapshot recovery tool strikes back

Cross post: Terminal Server 2003 issues with Group Policy Preferences History Folder

Announcing the availability of Remote Desktop Connection 7.0 for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2

Update: Free P2V tool: Disk2Vhd.exe – Command line support

Cool new tool for comparing IE Zone Security Settings

Powershell v2 is yours!

Windows Management Framework is here!

New DirectAccess documentation is now available

Optional configuration for the DFS Replication Management Pack

Windows 7 - Do I need to change my Active Directory for new Group Policy features?

Configuring the DFS Replication Management Pack

Scalable Networking Pack revisited for 2008

Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

2009-11-02T18:13:39Z

Ned here again. Let’s talk about auditing your domain for changes made to Password and Account Lockout policies. Frankly, it’s a real pain in the neck to figure out Password and Account Lockout auditing and there are legacy architectural decisions behind how this all works, so I’ll make sure to cover all the bases. This also includes auditing your Fine Grain Password policies (FGPP), for you bleeding-edge types.

Understanding how these policies work

We use Password and Account Lockout policies to control domain authentication. Password policies set requirements for things like password length, complexity, and maximum age. Account Lockout policies control lockout threshold and duration, and are very popular with The Devil.

There are two types of Password and Account Lockout policies in a domain:

Domain-wide – Introduced in Windows NT and set in Active Directory through domain security policy.
Fine Grained – Introduced in Windows Server 2008 and set in AD through manual means like ADSIEDIT or AD PowerShell. It configures settings on a user or group-membership basis, and there can be as many as you like.

Domain-based policy, while being set through security policy, is actually written to attributes on the root of the domain. ADSIEdit shows this object using the distinguished name of the domain name. This odd location results from providing NT 4.0 compatibility. Since NT 4.0 could not apply group policy, we had to store these values somewhere and answer requests about the settings in an NT fashion.

On the other hand, Fine Grained policies write to their own location. Windows stores each policy as a leaf object.

When you edit your built-in Default Domain password policy, you are actually editing:

\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

All your settings are in this format:

[System Access]
MinimumPasswordAge = 0
MaximumPasswordAge = 60
MinimumPasswordLength = 8
PasswordComplexity = 1
PasswordHistorySize = 4
LockoutBadCount = 50
ResetLockoutCount = 30
LockoutDuration = 30
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
ClearTextPassword = 0
LSAAnonymousNameLookup = 0

When DC applies this security policy during the five minute group policy refresh, the DC stamps these settings on the domainDNS object. And voila, you have your policies in place. But think about that – the DC stamps these settings in place when applying computer policy. Who do you think will be listed as the user in your audit event logs? That’s right – the DC itself. And that’s where this blog post comes in. :-)

Auditing Domain-Wide Policy

There are three main things you need to do to see domain-wide password and account lockout setting changes, but they differ slightly by OS:

1. Put an auditing entry on the “Policies” container. Enabling auditing for EVERYONE on the “CN=Policies,CN=System,DC=<your domain>” container causes auditing to track all writes, deletes, and permission modifications. The audit event shows the user modifying group policy in general. Obviously, this is useful for more than just password policy changes – “Hey, who set this policy to push a Domo-Kun wallpaper out to all the computers?”

2. Enable subcategory auditing for:

    a. “Authentication Policy Change” (if using Windows Server 2008 R2 DC’s).

    b. “Other Account Management Events” (if using Windows Server 2008 DC’s).

3. Enable subcategory auditing for “Directory Service Changes”.

    Note: In Windows Server 2008 R2, granular subcategory auditing is available through GPMC.

In Windows Server 2008, you need to use the script provided in KB921469.

After enabling auditing, Windows then generates security audit events for anyone editing domain-wide security policy for passwords and account lockouts:

1.    An event 5136 will be written that shows the versionNumber attribute of the policy being raised:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 3:04:17 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
    Security ID:        CONTOSO\Administrator
    Account Name:        Administrator
    Account Domain:        CONTOSO
    Logon ID:        0x1e936

Directory Service:
    Name:    contoso.com
    Type:    Active Directory Domain Services
Object:
    DN:    CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=POLICIES,CN=SYSTEM,DC=CONTOSO,DC=COM
    GUID:    CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com
    Class:    groupPolicyContainer
Attribute:
    LDAP Display Name:    versionNumber
    Syntax (OID):    2.5.5.9
    Value:    121

Note: The event ID shows the name of the user that modified the policy – every policy edit raises the version number. Now we know to go look at the policy and that someone changed it.

2. Windows writes a follow-up event (event id 4739) for each type of change – lockout policy or password policy. For example:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 3:01:28 PM
Event ID:      4739
Task Category: Authentication Policy Change
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
Domain Policy was changed.

Change Type:        Lockout Policy modified

Subject:
    Security ID:        SYSTEM
    Account Name:        2008R2-F-01$
    Account Domain:        CONTOSO
    Logon ID:        0x3e7

Domain:
    Domain Name:        CONTOSO
    Domain ID:        CONTOSO\

Changed Attributes:
    Min. Password Age:    -
    Max. Password Age:    -
    Force Logoff:        -
    Lockout Threshold:    500
    Lockout Observation Window:
    Lockout Duration:
    Password Properties:
    Min. Password Length:
    Password History Length:
    Machine Account Quota:
    Mixed Domain Mode:
    Domain Behavior Version:
    OEM Information:    -

====

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 3:04:23 PM
Event ID:      4739
Task Category: Authentication Policy Change
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
Domain Policy was changed.

Change Type:        Password Policy modified

Subject:
    Security ID:        SYSTEM
    Account Name:        2008R2-F-01$
    Account Domain:        CONTOSO
    Logon ID:        0x3e7

Domain:
    Domain Name:        CONTOSO
    Domain ID:        CONTOSO\

Changed Attributes:
    Min. Password Age:    -
    Max. Password Age:    -
    Force Logoff:        -
    Lockout Threshold:    -
    Lockout Observation Window:    -
    Lockout Duration:    -
    Password Properties:    -
    Min. Password Length:    5
    Password History Length:    -
    Machine Account Quota:    -
    Mixed Domain Mode:    -
    Domain Behavior Version:    -
    OEM Information:    -

Notice the account name is the DC itself. This event, while useful, needs to be correlated with the 5136 event to see what changed. And even then, these events can sometimes be difficult to understand – what is a “password property” after all? (it’s for complexity being turned on or off). You should probably use these events as a notification to go examine the actual policies in GPMC.

You’re probably asking yourself why I didn’t just audit the actual domain root object and skip using the “Authentication Policy Change” and “Other Account Management Events”. This is another of the vagaries of security policy auditing – it doesn’t work. Simply auditing the “DC=domain,DC=com” object does not return any information about password or lockout changes. Go figure.

Auditing Fine-Grained Policy

Auditing FGPP is simpler and the data is easier to read. FGPP does not contain intermediate security policy settings. Creating and modifying these policies directly edits the objects in Active Directory. You can create or modify FGPP using PowerShell, LDP, LDIFDE, or ADSIEDIT. This means there’s no layer between doing work on your behalf. Also, your audit events are clean and self-evident.

1. Put an auditing entry on the “Password Settings Container” container. Enabling auditing for EVERYONE on the “CN=Password Settings Container,CN=System,DC=<your domain>” object causes Windows to track all users who write, delete, and modify permissions on any FGPPs.

2. Enable subcategory auditing for “Directory Service Changes” (see previous section for steps).

After enabling auditing, Windows generates a security audit event for anyone editing FGPPs for each change made. Also, the audit event includes the new value and the value prior to the change:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 4:20:54 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
    Security ID:        CONTOSO\RobGreene
    Account Name:        RobGreene
    Account Domain:        CONTOSO
    Logon ID:        0x1e936

Directory Service:
    Name:    contoso.com
    Type:    Active Directory Domain Services
Object:
    DN:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    GUID:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    Class:    msDS-PasswordSettings
Attribute:
    LDAP Display Name:    msDS-PasswordComplexityEnabled
    Syntax (OID):    2.5.5.8
    Value:    TRUE
Operation:
    Type:    Value Deleted
    Correlation ID:    {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
    Application Correlation ID:    -

===

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 4:20:54 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
    Security ID:        CONTOSO\RobGreene
    Account Name:        RobGreene
    Account Domain:        CONTOSO
    Logon ID:        0x1e936

Directory Service:
    Name:    contoso.com
    Type:    Active Directory Domain Services
Object:
    DN:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    GUID:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    Class:    msDS-PasswordSettings
Attribute:
    LDAP Display Name:    msDS-PasswordComplexityEnabled
    Syntax (OID):    2.5.5.8
    Value:    FALSE
Operation:
    Type:    Value Added
    Correlation ID:    {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
    Application Correlation ID:    -

Here I can see the user RobGreene logged on and changed the password complexity requirements from TRUE to FALSE. I knew it! Rob Greene, always breaking my stuff…

See Edie, I told you I’d write a blog post on this. :-)

- Ned “the chiropractor” Pyle

New Directory Services KB Articles/Blogs 10/18-10/24

2009-10-30T19:21:43Z

976723	IPv6 network address seems case-sensitive at address assignment for multiple network adapters installed on a Windows7 and Windows Sever 2008 R2 based computer.
976647	The migration of hotfixes may fail after the installation of a Windows Server 2003 or Windows XP service pack
975702	Error message when you change security settings for a folder that contains a child object for which you do not have access permission: "Access is denied"
974971	Error message when you use the CryptAcquireContext function to request a handle to a third-party CSP on a computer that is running Windows Vista or Windows Server 2008: "0x800b0100 (Invalid Signature)"
974504	The Windows Remote Manager (WinRM) service does not start after you uninstall WinRM 2.0 on Windows Server 2008 or on Windows Vista
975815	File corruption occurs under a stress situation when the CopyFileEx function is used to copy a file between two computers that are running Windows Server 2008 or Windows Vista
976924	You receive Windows Time Service event IDs 24, 29, and 38 on a virtualized domain controller that is running on a Windows Server 2008-based host server with Hyper-V
974909	The network connection of a running Hyper-V virtual machine is lost under heavy outgoing network traffic on a Windows Server 2008 R2-based computer
974625	You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2
976659	Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers
976826	Upgrading a member server to Windows Server 2008 R2 does not fully remove FRS
976736	How to install Windows PowerShell on a computer that is running Windows Server 2008 R2 Core
976888	Error message when you try to manage a server that is running Windows Server 2008 R2 by using the Remote Server Administration Tools for Windows 7: "You do not have the permission to complete this task"

Blogs

ADMT, RODC’s, and Error 800704f1

Importing the DFS Replication Management Pack

Group Policy Slow Link Detection in Vista and beyond

Linus Torvalds gives Microsoft Windows 7 a thumbs up!

RDS CAL Single Pack now available in Retail channel

View/Configure Protected ACL and Fixing Broken Inheritance

Installing the DFS Replication Management Pack

Windows 7 Virtual PC and XP Mode RTM - now available for download

How do you tell AdFind that you only want just the xyz attribute returned?

Interesting Issue with Major Implications

Windows 7 / Windows Server 2008 R2: Problem Steps Recorder

Group Policy Changes in Windows XP SP3

Microsoft releases Windows-7-friendly version of Desktop Optimization Pack

DFS Replication Management Pack for Operations Manager 2007 is available

Windows 7 / Windows Server 2008 R2: AppLocker

Comment issues, continued

2009-10-29T21:38:00Z

Hey all. If you have a moment, please try and post a comment on this post. Especially non-Microsoft employees. We're still trying to see why comments stopped working.

Update Nov 2: Well, it seems to be working now. :-) Thanks for all the help folks, it's much appreciated. Comment away, we'll see 'em now.

Thanks,

Ned

Explanation of the Remote Desktop Services CAL Upgrade behavior in Windows Server 2003 and Windows Server 2008

2009-10-29T13:32:26Z

Hello everyone, Brian Singleton here. There has been a lot of confusion over the Remote Desktop Services (aka Terminal Server) client access license upgrade process in Windows and this posting is an explanation on how the behavior is actually supposed to function.

In Windows Server 2003 as well as Windows Server 2008 and Windows Server 2008 R2 we have a group policy setting called, “Prevent License Upgrade” and below is a description of the setting:

The license server will always try to provide the appropriate RDS CAL for a connection. For example a license Server provides a Windows 2000 Remote desktop services (RDS) CAL token for clients connecting to a terminal server running Windows 2000, operating system, a Windows Server 2003 family RDS CAL token for a connection to a terminal server running Windows Server 2003, and a Windows Server 2008 family RDS CAL token for a connection to a terminal server running Windows Server 2008.

By default, if the most appropriate RDS CAL is not available for a connection, a Windows Server 2003 license server will issue a Windows Server 2003 RDS CAL, if available, to the following:

A client connecting to a Windows 2000 terminal server

In the case of a Windows Server 2008 license server, it will issue a Windows Server 2008 RDS CAL, if available, to the following:

A client connecting to a Windows Server 2003 terminal server
A client connecting to a Windows 2000 terminal server

So if it works like it is stated in the group policy setting by default, “why does it not work for me”?

This feature is only utilized in mixed terminal server\terminal server license server environments.

The RDS CAL upgrade behavior functions as follows:

Scenario 1: Windows 2000 and Windows Server 2003:

In my environment I have a Windows Server 2000 licensing server as well as a Windows Server 2003 licensing server (TLS). The Windows 2000 TLS does not have any available Windows 2000 TS CAL tokens, but my Windows Server 2003 TLS has only Windows Server 2003 Per Device TS CAL tokens installed. I also have a Windows 2000 terminal server which retrieves its TS CAL token from the Windows Server 2000 TLS via license server override. In this scenario my client is a WinCE thin client, since we require a purchased TS CAL to be installed. The first time I connect to the Windows 2000 terminal server, I obtain a Windows 2000 Temporary TS CAL token from my Windows 2000 TLS. The second time I connect to the Windows 2000 terminal server the following occurs:

Since my Windows 2000 TLS does not have any purchased, permanent TS CAL tokens available, the Windows 2000 TLS will forward the request to another TLS via TS licensing discovery, in the case of my environment, to the Windows Server 2003 TLS. Since my Windows Server 2003 TLS does not have any Windows 2000 TS CAL tokens installed it will issue a Windows Server 2003 TS CAL token to the client connecting to the Windows 2000 terminal server.

Scenario 2: Windows Server 2003 and Windows Server 2008/Windows Server 2008 R2:

In my environment I have a Windows Server 2003 licensing server as well as a Windows Server 2008 licensing server. The Windows Server 2003 TLS does not have any Windows Server 2003 TS CAL tokens available, but my Windows Server 2008 TLS has only Windows Server 2008 Per Device RDS CAL tokens installed. I also have a Windows Server 2003 terminal server which retrieves its TS CAL tokens from the Windows Server 2003 TLS via license server override.

In this scenario my client is a Windows XP Professional client. The first time I connect to the Windows Server 2003 terminal server, I obtain a Windows Server 2003 Temporary TS CAL token from my Windows Server 2003 TLS. The second time I connect to the Windows Server 2003 terminal server the following occurs:

Since my Windows Server 2003 TLS does not have any permanent TS CAL tokens available, the Windows Server 2003 TLS will forward the request to another TLS via TS licensing discovery, in the case of my environment, to the Windows Server 2008 TLS. Since my Windows Server 2008 TLS does not have any Windows Server 2003 TS CAL tokens installed it will issue a Windows Server 2008 RDS CAL token to the client connecting to the Windows Server 2003 terminal server.

I hope this explanation on the TS CAL upgrade process has cleared the confusions you may have on this feature.

Brian “Bingleton” Singleton

DFS Referrals and IPv6: Outta site!

2009-10-28T13:33:11Z

Hi, David Everett here again to discuss an issue where DFS clients connect to out-of-site targets when the IPv6 protocol has been partially disabled using an incorrect method.

The customer deployed a DFS link replicated by DFSR. An in-site DFS namespace (DFSN) target called ContosoFS1 was deployed in the branch site. It wasn’t long before branch site users started reporting slow performance access data on the DFS link.

The 1^st step was to determine what Active Directory site the DFS clients resided, whether in-site targets existed in the DFS referral and if the in-site target was the Active Target of the DFS client.

To determine which site the client thought it belonged to in Active Directory, we ran this command from the client’s command prompt:

Nltest.exe /dsgetsite

This returned the correct site name. Then in order to determine if the in-site target server was appearing in the list of servers we had the user connect to the DFS link and had the user run this command at the command prompt:

Dfsutil.exe /pktinfo

We found that the client was seeing the in-site DFS target server in the referral. As shown below the in-site DFS target server, which is also a DFS Root server, was at the top of the referral order for \\contoso\dfsroot but ContosoFS1 was at the bottom of the referral order for the in-site folder target.

c:\>dfsutil /pktinfo
Microsoft(R) Windows(TM) Dfs Utility Version 4.2
Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.

--mup.sys--
4 entries...
Entry: \Contoso\DFSRoot
ShortEntry: \Contoso\DFSRoot
Expires in 0 seconds
UseCount: 3 Type:0x81 ( REFERRAL_SVC DFS )
   0:[\ContosoFS1\DFSRoot] State:0x119 ( ACTIVE TARGETSET )
   1:[\ContosoFS2\DFSRoot] State:0x09 ( )
   2:[\ContosoFS3\DFSRoot] State:0x109 ( )
   3:[\ContosoFS4\DFSRoot] State:0x09 ( )
   4:[\ContosoFS5\DFSRoot] State:0x09 ( )

Entry: \Contoso\DFSRoot\TargetFolder
ShortEntry: \Contoso\DFSRoot\TargetFolder
Expires in 0 seconds
UseCount: 0 Type:0x1 ( DFS )
   0:[\ContosoFS4\TargetFolder] State:0x131 ( ACTIVE TARGETSET )   <- out of site IPv4-only W2K3 target that client is connected to
   1:[\ContosoFS3\TargetFolder] State:0x21 ( )    <- out of site IPv4-only W2K3 target
   2:[\ContosoFS5\TargetFolder] State:0x21 ( )    <- out of site IPv4-only W2K3 target
   3:[\ContosoFS1\TargetFolder] State:0x121 ( )    <- In-site target that should be at top of list but isn't because IPv6 is incorrectly disabled

Once we knew the client was determine its site correctly from active Directory and that the in-site DFS target server was appearing in the DFS referral the focus turned from the client to the Active Directory and the target server.

A quick glance at Active Directory Sites and Services snap-in suggested the IPv4 Site/Subnet logic was properly configured and correct site discovery by the client reinforced this. However, there were no Site/Subnet associations for IPv6 which is the preferred protocol for Windows Server 2008.

Since IPv6 is the preferred protocol for Vista and later Operating Systems I was going to implement an IPv6 Site/Subnet association in Active Directory Sites and Services and see if this would improve DFS referral ordering of the in-site DFS target server. I checked the configuration of IPv6 on ContosoFS1 and found the protocol had been unchecked; which is not a good practice.

It’s a common misconception that unchecking IPv6 disables the protocol when in fact all it does is introduce transient errors. Windows Vista and later operating systems heavily rely upon IPv6 for internal operation, which means the protocol cannot be disabled or uninstalled entirely. Unchecking IPv6 on the adapter settings only unbinds the protocol from the NIC and the OS can still attempt to send remote traffic to the NIC where it never hits the wire.

There are two solutions for this:

I. The preferred method is to configure Static IPv6 addresses on your Windows Server 2008 DFS target servers and then define IPv6 Subnet/Site associations in Active Directory Sites and Services. See the following TechNet article on how to do this:

Create a Subnet Object or Objects and Associate them with a Site

II. For those who have some aversion to having any IPv6 traffic hitting the wire there is a “supported” [not recommended by the Microsoft Product Group] way to disable outbound IPv6 using the DisabledComponents registry value as directed in KB929852. Contrary to what the article states, it is possible to simply use Group Policy Preferences to disable IPv6 domain-wide – there is no need for a custom ADMX.

NOTE: It is beyond the scope of this blog to determine which components of IPv6 should be disabled in a given environment using DisabledComponents. To completely disable all External use of IPv6 configure DisabledComponents to ffffffff. Also, if you find IPv6 remains checked in the UI after configuring DisabledComponents in the registry rest assured the protocol is disabled for all remote traffic.

For those interested in more about DFS Site Discovery and Target Selection please see the DFS FAQ.

-David “Dy-no-miiiite!” Everett

Followup - more info on the new SCOM 2007 Management Pack for DFSR

2009-10-27T15:34:00Z

Hey all. Mahesh from the DFSR development team has new posts up on the System Center Operations Manager 2007 management pack that was released for DFSR. Give them a read, Mahesh always writes good stuff.

Installing the management pack

Importing the management pack

Configuring the management pack

Optional configuration – enabling backlog monitoring

These are in addition to the post I referenced back here.

- Ned 'the redirector' Pyle

How to Decommission an ADAM/ADLDS server and Add Additional Servers

2009-10-27T15:29:30Z

Hello, LaNae here again. Recently I worked with a customer that was looking for a comprehensive document that outlined the steps for decommissioning a server that had an ADAM/ADLDS instance installed on it. I along with the customer realized there is no such document and you have to piece together multiple documents to get the steps. I decided to write this blog at the urging of the customer so that others do not have this issue.

For the purpose of this blog we will work with the following example:

Current Configuration

There are 2 ADAM/AD LDS instances in one configuration set.
Server A and Server B are the names of the servers that host the instances.

Goal

Add Server C and Server D and install and configure ADAM/AD LDS instances that will be part of the existing configuration set. Remove the ADAM/AD LDS instances from Server A and Server B and decommission them.

Overview of Steps

1. Install ADAM or the AD LDS role on servers C and D.

2. Install and configure the ADAM/AD LDS instances one on each server to be members of the existing configuration set. Steps for ADAM: Managing Configuration Sets Steps for AD LDS: Practice Managing Replica AD LDS Instances

3. Once replication is complete you will need to transfer the ADAM/AD LDS built-in FSMO roles from Server A or B which ever holds the roles to Server C or D. There are only 2 roles you will need to transfer, Naming Master and Schema Master. Replication in ADAM or AD LDS

Check Replication

From an ADAM command prompt or regular command prompt depending on whether this is ADAM or AD LDS you can run the following command to check replication.

Repadmin /showreps servername:portnumber of instance

Determining FSMO Role Holder

If ADAM is installed all the following steps must be done from the ADAM command prompt. If using ADLDS a regular command prompt is fine.

1. Type dsmgmt <enter>

2. Type roles <enter>

3. Type connections <enter>

4. Type connect to server servername:portnumber of instance <enter>

5. Type quit <enter>

6. Type select operation target <enter>

7. Type list roles for connected server <enter> Note: This should list who owns the FSMO roles.

Transfer FSMO Roles to new Server

The following steps need to be done from an ADAM command prompt if running ADAM.

1. Open an ADAM tools command prompt.

2. At the command prompt, type: dsmgmt

3. At the dsmgmt: command prompt, type: roles

4. At the FSMO maintenance: command prompt, type: connections

5. At the server connections: command prompt, type: connect to server servername:portnumber where servername:portnumber is the computer name and communications port number of the ADAM instance that you want to use as the new naming master or schema master.

6. At the server connections: command prompt, type: quit

7. At the FSMO maintenance: command prompt, type: transfer rolename

Remove the Instances from the old servers

To remove an ADAM instance

1. Open Add or Remove Programs.

2. Click Change or Remove Programs, and then click the ADAM instance that you want to remove.

3. Click Remove.

To remove an AD LDS instance

1. To open Programs and Features, click Start, click Settings, click Control Panel, and then double-click Programs and Features.

2. Locate and click the AD LDS instance that you want to remove.

3. Click Uninstall.

You can now decommission Server A and B.

- Lanae Wade

Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains

2009-10-26T13:52:00Z

Hi all, Ned here again. Microsoft is still working on ADMT 3.2, which can be installed on Windows Server 2008 R2 servers for migrations. There's no estimated date for this new tool yet.

In the meantime, we have tested ADMT 3.1 and come up with supported scenarios for using it to migrate to R2 domains. Below are two KB articles that cover the requirements, what's supported, and known issues. As anyone who has emailed me already knows, we definitely support running ADMT 3.1 on a Windows Server 2008 DC or member server in an R2 domain, and migrating with it will be supported. Read more about this:

Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers - http://support.microsoft.com/kb/976659

You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2 -
http://support.microsoft.com/kb/974625

Important note: If you do not have Windows Server 2008 (i.e. you went from Windows 2000 or Windows Server 2003 straight to Windows Server 2008 R2), you do have downgrade rights. See this website on how to get product keys and media for R2:

http://www.microsoft.com/windowsserver2008/en/us/downgrade-rights.aspx

Perhaps the onslaught of emails about this can now subside... :-)

- Ned "go go go" Pyle

Group Policy Slow Link Detection using Windows Vista and later

2009-10-23T15:13:31Z

Mike here again. Many Group Policy features rely on a well connected network for their success. However, not every connection is perfect or ideal; some connections are slow. The Group Policy infrastructure has always provided functionality to detect slow links. However, the means by which Group Policy determines this are different between operating systems prior to Windows Server 2008 and Windows Vista.

Before Windows Server 2008 and Vista

Windows Server 2003, Windows XP, and Windows 2000 Group Policy uses the ICMP protocol to determine a slow link between the Group Policy client and the domain controller. This process is documented in Microsoft Knowledgebase article 227260: How a slow link is detected for processing user profiles and Group Policy (http://support.microsoft.com/default.aspx?scid=kb;EN-US;227260).

The Group Policy infrastructure performs a series of paired ICMP pings from the Group Policy client to the domain controller. The first ping contains a zero byte payload while the second ping contains a payload size of 2048 bytes. The results from both pings are computed and voila, we have the bandwidth estimation. However, using ICMP has some limitations.

Many "not-so-nice" applications use ICMP maliciously. This new found use increased ICMP’s popularity forced IT professional to take precautions. These precautions included blocking ICMP. The solution to block ICMP provided relief from the susceptibility of malicious ICMP packets, but broke Group Policy. Workarounds were created (Microsoft Knowledgebase article 816045 Group Policies may not apply because of network ICMP policies); But the update did not remove the ICMP dependency.

The Windows Server 2008 and Vista era

Windows 7 and Windows Vista to the rescue! These new operating systems implement a new slow link detection mechanism that DOES NOT use ICMP-- but we already knew this. The question we will answer is how does the new Group Policy slow link detection work?

The easy answer to how the new slow link detection works is Network Location Awareness (NLA). This networking layer service and programming interface allows applications, like Group Policy, to solicit networking information from the network adapters in a computer, rather than implementing their own methods and algorithms. NLA accomplishes this by monitoring the existing traffic of a specific network interface. This provided two important benefits: 1) it does not require any additional network traffic to accomplish its bandwidth estimate-- no network overhead, and 2) it does not use ICMP.

Group Policy using NLA

The question commonly asked is how does Group Policy slow link detection implement NLA. The actual algorithms used by NLA are not as important as what Group Policy does during its request to NLA for bandwidth estimation.

Locate a domain controller

A Group Policy client requires communication with a domain controller to successfully apply Group Policy. The Group Policy service must discover a domain controller. The service accomplishes this by using the DCLocator service. Windows clients typically have already discovered a domain controller prior to Group Policy application. DCLocator caches this information makes it available to other applications and services. The Group Policy service makes three attempts to contact a domain controller, with the first attempt using the domain controller information stored in the cache. The latter two attempts force DCLocator to rediscover domain controller information. Retrieving cached domain controller information does not traverse the network, but forceful rediscovery does. Domain controller information includes the IP address of the domain controller. The Group Policy service uses the IP address of the domain controller (received from DCLocator) to begin bandwidth estimation.

During bandwidth estimation

The Group Policy service begins bandwidth estimation after it successfully locates a domain controller. Domain controller location includes the IP address of the domain controller. The Group Policy service performs the following actions during bandwidth estimation.

NOTE: All actions listed in this section generate network traffic from the client to the domain controller unless otherwise noted. I've included a few actions that do not generate network traffic because their results could be accomplished using methods that generate network traffic. These actions are added for clarity.

Authentication

The first action performed during bandwidth estimation is an authenticated LDAP connect and bind to the domain controller returned during the DCLocator process. This connection to the domain controller is done under the user's security context and uses Kerberos for authentication. This connection does not support using NTLM. Therefore, this authentication sequence must succeed using Kerberos for Group Policy to continue to process. Once successful, the Group Policy service closes the LDAP connection.

NOTE: The user's security context is relative to the type of Group Policy processing. The security context for computer Group Policy processing is the computer. The security context for the user is the current user for the current session.

The Group Policy service makes an authenticated LDAP connection as the computer when user policy processing is configured in loopback-replace mode.

Determine network name

The Group Policy services then determines the network name. The service accomplishes this by using IPHelper APIs to determine the best network interface in which to communicate with the IP address of the domain controller. The action also uses Winsock APIs; however, this action does not create any network traffic. Additionally, the domain controller and network name are saved in the client computer's registry for future use.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History is where the service stores these values. The value names are DCName and NetworkName.

NOTE: The NetworkName registry value is used by the Windows firewall to determine if it should load the domain firewall profile.

Site query

Group Policy processing must know the site to which the computer belongs. To accomplish this, the Group Policy service uses the Netlogon service. Client site discovery is an RPC call from the client computer to a domain controller. The client netlogon service internally caches the computer's site name. The time-to-live (TTL) for the site name cache is five minutes. However, TTL expiry is on demand. This means the client only checks the TTL during client discovery. This check is implemented by Netlogon (not the Group Policy service). If the cached name is older than five minutes from when the name was last retrieved from the domain controller, then the Netlogon service makes an RPC call to the domain controller to discover the computer site. This explains why you may not see the RPC call during Group Policy processing. However, the opportunity for network traffic exists.

Determine scope of management

The following Group Policy actions vary based on Group Policy processing mode. Computer Group Policy processing only uses normal Group Policy processing. However, user Group Policy processing can use normal, loopback-merge, and loopback-replace modes.

Normal mode

Normal Group Policy processing is the most common Group Policy processing actions. Conceptually these work the same regardless of user or computer. The most significant difference is the distinguished name used by the Group Policy service.

Building the OU and domain list

The Group Policy service uses the distinguished name of the computer or user to determine the list of OUs and the domain it must search for group policy objects. The Group Policy service builds this list by analyzing the distinguished name from left to right. The service scans the name looking for each instance of OU= in the name. The service then copies the distinguished name to a list, which it uses later. The Group Policy service continues to scan the distinguished name until for OUs until it encounters the first instance of DC=. At this point, the Group Policy service has found the domain name, which completes the list. This action does not generate any network traffic.

Example: Here is the list from a given distinguished name

Distinguished Name:
            cn=user,OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
List:
            OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
            OU=hq,DC=na,DC=contoso,DC=com
            DC=na,DC=contoso,DC=com

Evaluate scope of management

The Group Policy service uses the list OUs to determine the Group Policy objects linked to each scope of management and the options associated with each link. The service determines linked Group Policy objects by using a single LDAP query to the domain controller discovered earlier.

LDAP requests have four main components: base, scope, filter, and attributes. The base is used to specify the location within the directory the search should begin, which is usually represented as a distinguished name. The scope determines how far the search should traverse into the directory; starting from the base. The options include base, one-level, and subtree. The base scope option limits the search to only return objects matching the filter that matches the base. The onelevel option return objects from one level below the base, but not including the base. The subtree option returns objects from the base and all levels below the base. The filter provides a way to control what objects the search should return (see MSDN for more information on LDAP search filter syntax). The attribute setting is a list of attributes the search should return for the objects discovered that match the filter.

The service builds the LDAP request with the following arguments:

BaseDN: domain
Scope: Sub Tree
Filter: (|(distinguishedname=OU=xxx)( more OUs)(ends domainNC DC=))
Attributes: gpLink, gpOptions, ntSecurityDescriptor

Example: Scope of management LDAP search
       BaseDN: DC=na,DC=contoso,DC=com
       Scope: SubTree
       Filter: (|(distinguishedname= OU=marketing,OU=hq,DC=na,DC=contoso,DC=com)
               (distinguishedname =OU=hq,DC=na,DC=contoso,DC=com)
               (distinguishedname =DC=na,DC=contoso,DC=com))
    Attributes:gPlink,gPoptions,nTSecurityDescriptor

Determining the scope of normal Group Policy processing mode occurs in the security context of the applying security principal. The computer performs the LDAP query computer processing and the user performs the LDAP query for user processing. Merge and Replace are user-only processing modes, which occur under the security context of the user.

Replace user-processing performs an LDAP query using the computer’s distinguished name. Each component of the distinguished name is inserted into the filter portion of the LDAP query. The LDAP query filter parameter ends with the distinguished name of the domain (which is assembled using the parts of the computer’s distinguished name.

Merge user-processing performs two LDAP queries. The first LDAP query uses the distinguished name of the user object. The second query uses the distinguished name of the computer object. The Group Policy links returned from both queries are merged into one list. The Group Policy service merges these lists together by adding the Group Policy links returned from the computer query to the end of the list of Group Policy links returned from the user query. Concatenating the computer list to the end of the user list results with the Group Policy links listed in the order they apply.

Determine the Link Status:

The Group Policy service is ready to determine the status of the link between the client computer and the domain controller. The service asks NLA to report the estimated bandwidth it measured while earlier Group Policy actions occurred. The Group Policy service compares the value returned by NLA to the GroupPolicyMinTransferRate named value stored in HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, which is the preference key or, HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System, which is the policy key. The default minimum transfer rate to measure Group Policy slow link is 500 (Kbps). The link between the domain controller and the client is slow if the estimated bandwidth returned by NLA is lower than the value stored in the registry. The policy value has precedence over the preference value if both values appear in the registry. After successfully determining the link state (fast or slow—no errors), then the Group Policy service writes the slow link status into the Group Policy history, which is stored in the registry. The named value is IsSlowLink and is located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. This value is an REG_DWORD value that is interpreted as a Boolean value; with a non-zero value equaling false and a zero value equaling true. If the Group Policy service encounters an error, it read the last recorded value from the history key and uses that true or false value for the slow link status.

Conclusion

Group Policy slow link detection has matured since the days of using ICMP for slow link detection. Today, Windows 7 and Windows Vista’s Group Policy services use NLA to sample TCP communication between the client and the domain controller, without sending additional network traffic.

- Mike “Huuuh, whaaaa?” Stephens

Come and get it

2009-10-22T22:20:00Z

Windows 7 and Windows Server 2008 R2 reached general availability today.

The line in our site’s company store was out the door, but we were able to snag some for this nice picture taken from a new Windows Mobile phone. Yeah, I went there too.

Win7 and R2 Beta have been my fulltime job since October 2008 and it's been the most fun I've ever had as a Microsoft employee. I hope you enjoy using it as much as I enjoyed breaking it.

- Ned “The Shill” Pyle

New Directory Services KB Articles/Blogs 10/11-10/17

2009-10-19T19:09:46Z

970401	Description of BitLocker To Go Reader
972422	A Windows XP-based computer stops responding at the "Windows is loading your profile" screen when you connect to the computer by using an RDP connection
975652	Error message when you use an application that monitors the event log to open an event log file on a computer that is running Windows Server 2003 SP2: "The event log file is corrupt"
972635	The Active Directory Application Mode service may crash if the Active Directory Application Mode instance database is of a large scale on a computer that is running Windows Server 2003 SP2
972122	A query takes a long time to complete and increases CPU usage to a high level on the domain controllers that are running Windows Server 2003 when you use NSPI API functions to query address book information
973667	A Windows Server 2003-based domain controller may incorrectly return the "NO_SUCH_USER (0xc0000064)" status code in response to logon requests when the domain controller is shutting down or restarting
973995	You may lose some events when you subscribe to some events that are in multiple event logs on a computer that is running Windows Server 2008 or Windows Vista
973509	The advanced security settings for Windows Firewall that you deploy by using a Group Policy object (GPO) are not displayed in Windows Vista or in Windows 2008
975212	When you use a VPN connection that uses Smart Card authentication on a client computer that is running Windows Vista or Windows Server 2008, the computer stops responding
971265	A memory leak issue in the Lsass.exe process causes an application or a service to stop responding if the application or the service uses the NTLM authentication on a computer that is running Windows Server 2008 or Windows Vista.
974178	Error code 1450 after you transfer data by using the named pipes protocol between a client computer and a server that are running Windows Vista or Windows Server 2008
975598	The Nslookup.exe utility does not use all the suffixes in the DNS suffix search list if the total length of the DNS suffix search list is longer than 255 characters on a computer that is running Windows Server 2008 or Windows Vista
975142	You cannot install Active Directory Domain Services on a member server that is running Windows Server 2008 in a branch office if the DNS and LDAP communication between the branch office and the forest root domain is blocked
975808	All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2
974639	Lots of SceCli 1202 events are added to the application event log on a domain controller that is running Windows Server 2008 R2 or Windows 7 after some domain level group policies are updated
974636	AD RMS may stop working when it queries Active Directory global catalogs on a computer that is running Windows Server 2008 R2
974431	An update is available to improve the stability and reliability of Windows 7 and of Windows Server 2008 R2

Blogs

Windows Server 2008 R2 CAPolicy.inf Syntax

Breaking News: Argentina DST Change

The Four Stages of NTFS File Growth

Classification made easy with File Classification Infrastructure in Windows Server 2008 R2

Error when installing AD Management Gateway Service

Introducing the Windows 7 Resource Kit PowerShell Pack

Using Hyper-V without re-installing your world

Domain and Forest Functional Levels

Hypervisor is not running error: How to fix

Upgrading Windows Server 2008 R2 without media

Add Object Specific ACEs using Active Directory Powershell

Security Bulletins for the Regular IT Guy - oct 09

BranchCache Deployment Guide for Windows Server 2008 R2 and Windows 7

Exchange Automatic conversion of non-security enabled groups into security enabled groups

Offline NT Password Editor Still Works for Windows 7

Network Monitor Videos on Channel 9

Windows 7 / Windows Server 2008 R2: What’s New in Remote Desktop Services

DFSR Monitoring Management Pack for System Center 2007 Released

2009-10-19T17:44:00Z

You can stop yelling at me, it's released:

Download:

DFS Replication Management Pack for System Center Operations Manager 2007

Overview:

The DFS Replication Management Pack for System Center Operations Manager 2007 monitors the health of the DFS Replication service on Windows Server 2003 R2 and Windows Server 2008 computers. This management pack monitors events generated by the DFS Replication service. These events provide an insight into the health of the service and folders replicated on monitored computers. This management pack includes a dashboard view which can be used to monitor replication backlogs.

The management pack also features consolidation rules that monitor computers for frequent occurrences of certain operational conditions such as staging cleanups, sharing violations, replication conflicts etc.

Feature Summary:

The following features are new in this release of the DFS Replication Management Pack:

Alerts indicating outages of the DFS Replication service on monitored computers.
Alerts indicating configuration issues that require administrative intervention.
Dashboard view that enables tracking of replication backlogs on monitored computers.
Tracking of intermittent operational conditions. These conditions are tracked by the management pack and show up either as warnings/errors. Transient warnings/errors flagged for conditions that are resolved over time are automatically corrected by the management pack, once those conditions are resolved.
Intuitive state view indicating red, yellow and green states of the service, replication groups, and replicated folders configured on monitored computers.
Monitoring of important service parameters such as staging area usage and replication conflicts generated.

System Requirements:

Supported Operating Systems: Windows Server 2003 R2 (32-Bit x86); Windows Server 2003 R2 x64 editions; Windows Server 2008
Other Software: System Center Operation Manager 2007

Big thanks to MaheshU for letting everyone know the instant it was out.

- Ned 'you hurt me with your words' Pyle

ADMT, RODC’s, and Error 800704f1

2009-10-19T16:11:00Z

Hello all, Jason here again. With this blog post, I just wanted to bring an ADMT issue to the masses’ attention, as I’ve experienced it multiple times within just the last couple of months.

There’s an issue when attempting to migrate computer account objects into a Windows 2008 domain that had been prepared for a Read-Only Domain Controller with the ‘ADPrep /RODCPrep’ command. To confirm if the command had been implemented, look for the following attribute within the ADSIEdit snap-in on the targeted 2008 domain:

CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<DomainName>,DC=com

Note: If ran, the value for the ‘Revision’ attribute will be set to ‘2’.

This is what is specifically witnessed within the ADMT log file:

ERR3:7075 Failed to change domain affiliation, hr=800704f1

The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

When this error is generated, it is due to the following hotfix NOT being installed onto the client machine that you are migrating into the Windows 2008 domain:

944043 Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista
http://support.microsoft.com/default.aspx?scid=kb;EN-US;944043

Upon installing the hotfix and rebooting the client machine(s), re-running ADMT for the computer object migration will now succeed.

- Jason “J4” Fournerat

Windows Server 2008 R2 CAPolicy.inf Syntax

2009-10-15T14:05:00Z

Greetings! This is Jonathan again. I was reviewing Chris’ excellent blog post series on designing and implementing a PKI when I realized that it would be helpful to better document the CAPolicy.inf file. The information in this post relies heavily on the information published in the Windows Server 2003 Help File, but this information is updated to include information pertinent to Windows Server 2008 R2.

Another helpful document that discusses many of these settings is available on Technet.

Background

First, what is a CAPolicy.inf file? The CAPolicy.inf contains various settings that are used when installing the Active Directory Certification Service (ADCS) or when renewing the CA certificate. The CAPolicy.inf file is not required to install ADCS with the default settings, but in many cases the default settings are insufficient. The CAPolicy.inf can be used to configure CAs in these more complicated deployments.

Once you have created your CAPolicy.inf file, you must copy it into the %systemroot% folder (e.g., C:\Windows) of your server before you install ADCS or renew the CA certificate.

I’m not going to discuss what settings you need for your particular configuration, nor will I offer guidance on how you should set up your PKI to meet whatever your needs may be. Please follow Chris’ series for that sort of information. I’m simply going to document the available settings in the CAPolicy.inf which, if you follow Chris’ guidance, you’ll find will come in handy.

Let’s get started, shall we?

As I mentioned earlier, the CAPolicy.inf file uses the .INF file structure to specify sections, settings, and values for those settings. It will be impossible here to define a default template suitable for all purposes, so I’m just going to describe all the options and allow you to decide which settings meet your needs. Not all the settings below are required in the file, but those that are required will be called out.

The following key words are used to describe the .INF file structure.

A section is an area in the .INF file that covers a logical group of keys. A section always appears in brackets in the .INF file.
A key is the parameter that is to the left of the equal sign.
A value is the parameter that is to the right of the equal sign.

Version

The first two lines of the CAPolicy.inf file are:

[Version]
Signature=”$Windows NT$”

[Version] is the section.
Signature is the key.
“$Windows NT$” is the value.

Version is the only required section, and must be at the beginning of your CAPolicy.inf file.

PolicyStatementExtension

Next is the PolicyStatementExtension section. This section lists the name of the policies for this CA. Multiple policies are separated by commas. The names LegalPolicy and ManagementPolicy are used here as examples, but the names can be whatever the CA administrator chooses when creating the CAPolicy.inf file.

NOTE: Administrator defined section names must observe the following syntax rules:

A section name cannot have leading or trailing spaces, a linefeed character, a return character, or any invisible control character, and it should not contain tabs.
A section name cannot contain either of the bracket ([]) characters, a single percent (%) character, a semicolon (;), or any internal double quotation (“) characters.
A section name cannot have a backslash (\) as its last character.

The names have meaning in the context of a specific deployment, or in relation to custom applications that actually check for the presence of these policies.

[PolicyStatementExtension]
Policies=LegalPolicy,ManagementPolicy

For each policy defined in the PolicyStatementExtension section there must be a section that defines the settings for that particular policy. For the example above, the CAPolicy.inf must contain a [LegalPolicy] section and a [ManagementPolicy] section.

For each policy, you need to provide a user-defined object identifier (OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. The URL can be in the form of an HTTP, FTP, or LDAP URL. Continuing on with the example started above, if you are going to have text in the policy statement, then the next three lines of the CAPolicy.inf will be:

[LegalPolicy]
OID=1.1.1.1.1.1.1
Notice=”Legal policy statement text”

If you are going to use a URL to host the CA policy statement, then next three lines would instead be:

[ManagementPolicy]
OID=1.1.1.1.1.1.2
URL=http://pki.wingtiptoys.com/policies/managementpolicy.asp

Please note that the OID above is arbitrary and is used as an example. In a true deployment, you would obtain an OID from your own OID gatekeeper.

In addition:

Multiple URL keys are supported
Multiple Notice keys are supported
Notice and URL keys in the same policy section are supported.
URLs with spaces or text with spaces must be surrounded by quotes. This is true for the URL key, regardless of the section in which it appears.
The Notice text has a maximum length of 511 characters on Windows Server 2003 [R2], and a maximum length of 4095 characters on Window Server 2008 [R2].

An example of multiple notices and URLs in a policy section would be:

[LegalPolicy]
OID=1.1.1.1.1.1.1
URL=http://pki.wingtiptoys.com/policies/legalpolicy.asp
URL=ftp://ftp.wingtiptoys.com/pki/policies/legalpolicy.asp
Notice=”Legal policy statement text”

CRLDistributionPoint

You can specify CRL Distribution Points (CDPs) for a root CA certificate in the CAPolicy.inf. This section does not configure the CDP for the CA itself. After the CA has been installed you can configure the CDP URLs that the CA will include in each certificate that it issues. The URLs specified in this section of the CAPolicy.inf file are included in the root CA certificate itself.

[CRLDistributionPoint]
URL=http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl

Some additional information about this section:

Multiple URLs are supported.
HTTP, FTP, and LDAP URLs are supported. HTTPS URLs are not supported.
This section is only used if you are setting up a root CA or renewing the root CA certificate. Subordinate CA CDP extensions are determined by the CA which issues the subordinate CA’s certificate.
URLs with spaces must be surrounded by quotes.
If no URLs are specified – that is, if the [CRLDistributionPoint] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. This is usually preferable when setting up a root CA. Windows does not perform revocation checking on a root CA certificate so the CDP extension is superfluous in a root CA certificate.

Authority Information Access

You can specify the authority information access points in the CAPolicy.inf for the root CA certificate.

[AuthorityInformationAccess]
URL=http://pki.wingtiptoys.com/Public/myCA.crt

Some additional notes on the authority information access section:

Multiple URLs are supported.
HTTP, FTP, LDAP and FILE URLs are supported. HTTPS URLs are not supported.
This section is only used if you are setting up a root CA, or renewing the root CA certificate. Subordinate CA AIA extensions are determined by the CA which issued the subordinate CA’s certificate.
URLs with spaces must be surrounded by quotes.
If no URLs are specified – that is, if the [AuthorityInformationAccess] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. Again, this would be the preferred setting in the case of a root CA certificate as there is no authority higher than a root CA that would need to be referenced by a link to its certificate.

Enhanced Key Usage

Another section of the CAPolicy.inf file is [EnhancedKeyUsageExtension], which is used to specify the Enhanced Key Usage extension OIDs placed in the CA certificate.

Multiple OIDs are supported.
This section can be used during CA setup or CA certificate renewal.
This section is only used if you are setting up a root CA or renewing a root CA certificate. The Enhanced Key Usage extension for a subordinate CA is determined by the CA that issued the subordinate CA’s certificate.
This extension can be marked as Critical.

An example of this section is:

[EnhancedKeyUsageExtension]
OID=1.2.3.4.5
OID=1.2.3.4.6
Critical=No

If this section is omitted from the CAPolicy.inf file, the Enhanced Key Usage extension will be omitted from the root CA certificate. If this extension does not exist in a root CA certificate then that root CA certificate can be trusted for all purposes.

By populating this section with specific OIDs, you are limiting the purposes for which the root CA certificate can be trusted. For example, consider the following section:

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.4 ; Secure Email
OID=1.3.6.1.4.1.311.20.2.2 ; Smart Card Logon
Critical=No

During the setup of the CA, the root CA certificate will be created with the two OIDs above in the Enhanced Key Usage extension. This root certificate, because of the OIDs specified, can only be trusted for Secure Email (signing and encrypting) and Smart Card Logon. Any certificate issued for some other purpose, such as Client or Server Authentication, would be considered invalid. This restriction would apply not only to this root CA, but also to any CA subordinate to this root.

Basic Constraints

You can use the CAPolicy.inf file to define the PathLength constraint in the Basic Constraints extension of the root CA certificate. Setting the PathLength basic constraint allows you to limit the path length of the CA hierarchy by specifying how many tiers of subordinate CAs can exist beneath the root. A PathLength of 1 means there can be at most one tier of CAs beneath the root. These subordinate CAs will have a PathLength basic constraint of 0, which means that they cannot issue any subordinate CA certificates.

This extension can be marked as Critical.

[BasicConstraintsExtension]
PathLength=1
Critical=Yes

It is not recommended to use this section in the CAPolicy.inf file for a subordinate CA. To add a PathLength constraint to a subordinate CA certificate if the parent CA has no PathLength constraint in its own certificate, you can set the CAPathLength registry value on the parent CA. For example, to issue a subordinate CA certificate with a PathLength constraint of 1, use the following command to configure the parent CA.

Certutil –setreg Policy\CAPathLength 2

Setting this value causes the CA to behave as though its own certificate had a PathLength constraint of whatever number you specify. Any subordinate CA certificate issued by the parent CA will have a PathLength constraint set appropriately in its Basic Constraints extension.

You must restart Active Directory Certificate Services for this change to take effect.

Cross Certificate Distribution Points

The cross certificate distribution point (CCDP) extension identifies where cross certificates related to the CA certificate can be obtained and how often that location is updated. The CCDP extension is useful if the CA has been cross-certified with another PKI hierarchy. Windows XP and later operating systems would use this extension for the discovery of cross-certificates that might be used during the path discovery and chain building process.

The SyncDeltaTime key indicates how often, in seconds, the locations referred to by the URL key(s) are updated. While this entire section is optional, if it exists, and if the SyncDeltaTime key is present, then at least one URL key must also be present.

This extension can be marked as Critical.

[CrossCertificateDistributionPointExtension]
SyncDeltaTime=600 ; in seconds
URL=http://pki.wingtiptoys.com/ccdp/PartnersCA.crt
Critical=No

Request Attributes

The [RequestAttributes] section, when implemented on a subordinate CA, allows you to specify a custom subordinate certification authority template. There is already the default Subordinate Certificate Authority template that is published in Active Directory the first time an Enterprise CA is installed in the forest. This default template, however, is a v1 template (Windows 2000-style) and cannot be edited. The CertificateTemplate key allows you specify a different template for your subordinate CA certificate request, one that you created by duplicating the default template.

[RequestAttributes]
CertificateTemplate=WingtipToysSubCA

Server Settings

Another optional section of the CAPolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed. None of the keys in this section are required. Many of these settings have default values that are sufficient for most needs and can simply be omitted from the CAPolicy.inf file. Alternatively, many of these settings can be changed after the CA has been installed.

An example would be:

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4
CRLOverlapPeriod=Hours
CRLOverlapUnits=3
CRLDeltaOverlapPeriod=Minutes
CRLDeltaOverlapUnits=5
ClockSkewMinutes=20
LoadDefaultTemplates=True
DiscreteSignatureAlgorithm=0
ForceUTF8=0
EnableKeyCounting=0

RenewalKeyLength sets the key size for renewal only. This is only used when a new key pair is generated during CA certificate renewal. The key size for the initial CA certificate is set when the CA is installed.

When renewing a CA certificate with a new key pair, the key length can be either increased or decreased. We in Support see this most often when a customer has set a root CA key size of 4096 bytes or higher, and then discover that they have Java apps or network devices that can only support key sizes of 2048 bytes. In that situation, we can use this setting in the CAPolicy.inf file to reduce the key size of the CA. Of course, that means that we have to reissue all the certificates issued by that CA. The higher up in the hierarchy the CA resides, the more inconvenient this procedure is.

RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of the new root CA certificate when renewing the old root CA certificate. It only applies to a root CA. The certificate lifetime of a subordinate CA is determined by its superior. RenewalValidityPeriod can have the following values: Hours, Days, Weeks, Months, and Years.

CRLPeriod and CRLPeriodUnits establish the validity period for the base CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period of the delta CRL. CRLPeriod and CRLDeltaPeriod can have the following values: Hours, Days, Weeks, Months, and Years. Each of these settings can be configured after the CA has been installed:

Certutil -setreg CA\CRLPeriod Weeks
Certutil -setreg CA\CRLPeriodUnits 1
Certutil -setreg CA\CRLDeltaPeriod Days
Certutil -setreg CA\CRLDeltaPeriodUnits 1

Restart Active Directory Certificate Services for any changes to take effect.

CRLOverlapPeriod and CRLOverlapUnits work together to specify the how long to extend the validity period of a base CRL past the CRL’s publication interval. CRLOverlapPeriod specifies the number of units and CRLOverlapUnits refers to which units are being specified. The default is Days, but Hours, Weeks, Months and Years are also valid. The CRL overlap is useful for setting a “buffer period” on the CA to allow for things like AD replication latency – the time it takes for the CRL when published in Active Directory to propagate to all domain controllers in the forest.

CRLDeltaOverlapPeriod and CRLDeltaOverlapUnits permit you to set the same buffer period for the CA’s delta CRL.

The overlap settings for the base CRL and delta CRL can also be set after the CA has been installed.

Certutil -setreg CA\CRLOverlapPeriod Hours
Certutil -setreg CA\CRLOverlapUnits 3
Certutil -setreg CA\CRLDeltaOverlapPeriod Minutes
Certutil -setreg CA\CRLDeltaOverlapUnits 5

As before, restart Active Directory Certificate Services for any changes to take effect.

The default overlap period for the base CRL and delta CRL is 10% of the publication interval up to a maximum of 12 hours. If this default value is sufficient for your needs then you can simply omit these keys from the CAPolicy.inf file.

ClockSkewMinutes allows you to accommodate possible clock synchronization issues. The CA will set the effective time of the published base CRL and delta CRL to the current time less the ClockSkewMinutes. For example, if the clock skew is set to 5 minutes, and the current time is 4:00pm, then the effective time of a newly published CRL would be 3:55pm.

This value can also be set after the CA has been installed.

Certutil -setreg CA\ClockSkewMinutes 10

Restart Active Directory Certificate Services for any changes to take effect.

The default value for ClockSkewMinutes is 10 minutes; if this interval is sufficient then this key can be omitted from the CAPolicy.inf file.

LoadDefaultTemplates only applies during the install of an Enterprise CA. This setting, either True or False (or 1 or 0), dictates whether or not the CA is configured with any of the default templates.

In a default installation of the CA, a subset of the default certificate templates is added to the Certificate Templates folder in the Certification Authority snap-in. This means that as soon as the ADCS service starts after the role has been installed a user or computer with sufficient permissions can immediately enroll for a certificate. This behavior is not always desirable.

To illustrate the point, the Domain Controller and Domain Controller Authentication templates are among the default templates added to the CA as it is installed. The default permissions on these two templates allow all domain controllers in the forest to enroll for certificates based those two templates. Finally, the default behavior of a domain controller is to immediately enroll for a Domain Controller or Domain Controller Authentication template as soon as an Enterprise CA is detected in the forest (Windows 2000 DCs will attempt to enroll for a Domain Controller certificate; Windows Server 2003 and higher will attempt to enroll for a Domain Controller Authentication certificate).

You may not want to issue any certificates immediately after a CA has been installed, so you can use the LoadDefaultTemplates setting to prevent the default templates from being added to the Enterprise CA. If there are no templates configured on the CA then it can issue no certificates.

On Windows Server 2003 and Windows Server 2003 R2, the LoadDefaultTemplates setting only applies to a root Enterprise CA. It is ignored on a subordinate Enterprise CA.

On Windows Server 2008 and Windows Server 2008 R2, the LoadDefaultTemplates setting applies to both root and subordinate Enterprise CAs.

DiscreteSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1 signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes the PKCS#1 V2.1 signature format.

ForceUTF8 changes the default encoding of relative distinguished names (RDNs) in Subject and Issuer distinguished names to UTF-8. Only those RDNs that support UTF-8, such as those that are defined as Directory String types by an RFC, are affected. For example, the RDN for Domain Component (DC) supports encoding as either IA5 or UTF-8, while the Country RDN (C) only supports encoding as a Printable String. The ForceUTF8 directive will therefore affect a DC RDN but will not affect a C RDN.

Finally, EnableKeyCounting configures the CA to increment a counter every time the CA’s signing key is used. Do not enable this setting unless you have a Hardware Security Module (HSM) and associated cryptographic service provider (CSP) that supports key counting. Neither the Microsoft Strong CSP nor the Microsoft Software Key Storage Provider (KSP) support key counting.

For more caveats to be aware of when using key counting, please review the following KB article:

951721 The certification authority startup event in the Security log always reports a usage count of zero for the signing key on a computer that is running Windows Server 2008 or Windows Server 2003

Conclusion

There we go. We’ve finally finished the list of all the settings you can configure via the CAPolicy.inf file.

I had at first considered putting all the sections I talked about above into one file so you could see how a “finished” CAPolicy.inf file would look. Then I realized that would be a monumentally bad idea seeing as, with the exception of the [Version] section, everything covered above is totally optional – perhaps with some settings even being contradictory. I’d hate to be responsible for a bad sample CAPolicy.inf file bouncing around the Internet.

The settings that you will want to configure in your CAPolicy.inf file will completely depend on your needs, and will vary between root CAs and subordinate CAs. I certainly hope that you find this information useful.

- Jonathan ‘Small bills only’ Stephens