April, 2008

Introduction

Hello, this is Jonathan from the Directory Services team.

The Network Device Enrollment Service (NDES) is one of the role services of the Active Directory Certificate Services (ADCS) role. It implements the Simple Certificate Enrollment Protocol (SCEP). SCEP defines the communication between network devices and a Registration Authority (RA) for certificate enrollment.

When the NDES role is added, it automatically requests two certificates that it uses as part of its functionality. The first is an Exchange Enrollment Agent certificate the other is a CEP Encryption certificate. In both cases, the private keys associated with this certificate are not exportable, so it is difficult to share these certificates amongst multiple instances of the RA.

This document describes the steps necessary to replace the original certificates requested during the install of the role with a new set of certificates requested manually afterwards. As part of the manual request process, the Administrator can specify that the private keys be exportable facilitating the sharing of certificates and keys amongst multiple servers.

While not recommended, it assumed that the risks associated with this practice are understood and accepted by the Administrator.

Finally, this document assumes that the issuing CA is running Microsoft Windows Server 2008 Active Directory Certificate Services in Enterprise mode.

Process Overview

The first step in the process is to remove the original certificates from the server. Next, new certificates will be requested from the CA and installed in the Local Computer Personal store. After that, the permissions on the new private keys will be modified to permit the SCEP Agent account specified during role install access to the private keys. Finally, the IIS service will be reset. NDES will locate the new certificates when it receives the first SCEP request from a network device.

Removing the Original Certificates

After the NDES role is installed, there will be two certificates in the Local Computer Personal store issued to the NDES Registration Authority. The name of the RA is constructed like so:

%COMPUTERNAME%-MSCEP-RA

These certificates should be revoked on the CA and removed from the server. Simply deleting the certificates from the Local Computer Personal store is sufficient, but Windows stores private keys separately from the associated certificate so deleting the certificates will result in orphaned private keys that remain on the server. It is good practice to delete the private keys first, and then remove the associated certificates.

The first step is to identify the private keys. NDES does not support the new Crypto Next Generation (CNG) Cryptographic Service Providers (CSP) introduced in Windows Server 2008. Instead, it uses the legacy CryptoAPI (CAPI) providers. The default Windows CAPI CSPs store private keys encrypted in the file system. You can use the following method to locate the encrypted key files so that you can delete them.

Locating Private Keys

The private key files for certificates issued to the Local Computer are located in the following directory:

%systemdrive%\ProgramData\Microsoft\Crypto\RSA\MachineKeys

ProgramData is a hidden system directory so you must be a local Administrator to perform this task. Once you have opened the directory, you then need to determine which of the files contained therein is associated with the certificate you wish to remove. This is easily accomplished using certutil.exe.

Certutil can be used to enumerate the certificates in the Local Computer Personal store and display the associated key container. The name of the key container will match the name of the file in the directory mentioned above. Please note, non-Microsoft CSPs may not behave in this manner since key storage implementations can vary from vendor to vendor, but the behavior is consistent amongst the Microsoft default CAPI CSPs.

The following command will search the Local Computer Personal store for all certificates issued to the RA and display the key container name.

for /f "tokens=*" %i in ('certutil -store MY %COMPUTERNAME%-MSCEP-RA') do @echo %i | findstr /i /c:"Unique container name"

The above command line has been wrapped, but it should be entered on one line in the command prompt. It uses the for command to step through each line of the certutil.exe output and pipe the result to the findstr.exe command. Findstr looks for the string “Key Container” and prints the line to the command prompt if it is found. Any line that does not contain the string “Key Container” is ignored.

The actual key container names will vary from machine to machine, but the output should look similar to the following:

Key Container = 355b8e247af95b2340ba226a6bc25ab5_cde5adfd-972a-420b-986e-e40fef6ea415
Key Container = bc1fa1b6c3c724366bcb30b581f4280f_cde5adfd-972a-420b-986e-e40fef6ea415

Deleting the Original Private Keys

Putting everything together, you would delete the following files:

%systemdrive%\ProgramData\Microsoft\Crypto\RSA\MachineKeys\355b8e247af95b2340ba226a6bc25ab5_cde5adfd-972a-420b-986e-e40fef6ea415

%systemdrive%\ProgramData\Microsoft\Crypto\RSA\MachineKeys\bc1fa1b6c3c724366bcb30b581f4280f_cde5adfd-972a-420b-986e-e40fef6ea415

Once the private keys have been deleted, you can simply delete the certificates in the Local Computer Personal store issued to NDES RA (%COMPUTERNAME%-MSCEP-RA).

Requesting New Certificates

The next step in the process is to request new certificates from the CA to be used by the NDES RA. The following steps will use certreq.exe to create and submit the certificate request, and to retrieve and install the issued certificate. Let's start with the Exchange Enrollment Agent certificate.

Requesting the Exchange Enrollment Certificate

First, you'll need to create an .INF file containing information that certreq.exe will use to generate the request. A sample ws08_ndes_sign.inf is included below.

Once the ws08_ndes_sign.inf file has been created you use certreq.exe to generate the request, submit it to the CA, retrieve the issued certificate, and then install it. Follow these steps to accomplish these tasks:

1. Open the command prompt and change to the directory that contains the file ws08_ndes_sign.inf.
2. Run the following command:
   
   certreq –f -new ws08_ndes_sign.inf ws08_ndes_sign.req
   
   This command will generate the certificate request and save it as ws08_ndes_sign.req. If you see the warning dialog that states "User context template conflicts with machine context", click Ok. This warning can be ignored.  Please review the sample ws08_ndes_sign.inf file for more information on the switches in the command line above.
3. Next, run the following command:
   
   certreq –submit ws08_ndes_sign.req ws08_ndes_sign.cer
   
   You will be prompted to select to which CA the request should be submitted. Once that is done, the request will be submitted and the issued certificate will be retrieved and saved as ws08_ndes_sign.cer.
4. Finally, run the following command:
   
   certreq –accept ws08_ndes_sign.cer
   
   This command import the new certificate and move it into the Local Computer Personal store.

Figure 1 below shows the commands described above and the expected output.

Figure 1

Requesting the CEP Encryption Certificate

Next you’ll need to request the CEP Encryption certificate. As with the Exchange Enrollment Agent certificate, you will need to create and .INF file that contains information that certreq.exe will use to generate the request. A sample ws08_ndes_xchg.inf file is included below.

Once the ws08_ndes_xchg.inf file has been created you use certreq.exe to generate the request, submit it to the CA, retrieve the issued certificate, and then install it. Follow these steps to accomplish these tasks:

1. Open the command prompt and change to the directory that contains the file ws08_ndes_xchg.inf.
2. Run the following command:
   
   certreq –f –new ws08_ndes_xchg.inf ws08_ndes_xchg.req
   
   This command will generate the certificate request and save it as ws08_ndes_xchg.req. Please review the sample ws08_ndes_xchg.inf file for more information on the switches in the command line above.
3. Next, run the following command:
   
   certreq –submit ws08_ndes_xchg.req ws08_ndes_xchg.cer
   
   You will be prompted to select to which CA the request should be submitted. Once that is done, the request will be submitted and the issued certificate will be retrieved and saved as ws08_ndes_xchg.cer. 
4. Finally, run the following command:
   
   certreq –accept ws08_ndes_xchg.cer
   
   This command import the new certificate and move it into the Local Computer Personal store.

Figure 2 below shows the command described above and the expected output.

Figure 2

Verifying the New Certificates

You can now run the following command to verify that both certificates have been installed in the Local Computer Personal store:

certutil -store My %COMPUTERNAME%-MSCEP-RA

The output should look similar to the following:

Setting Permissions on the Private Keys

Next, the permissions on the private keys files will need to be modified to permit the MSCEP RA service account to access the associated key material.

Windows Server 2008 now makes it easier to manage permissions on private keys through the Certificates snap-in. Once the new NDES RA certificates have been installed, the Administrator needs to grant access to the associated private keys to the MSCEP RA service account.

To grant the MSCEP RA access to the private keys, follow these steps:

1.  Open the Certificates MMC snap-in focused on the Local Computer.

2.  Open the Personal store, and select the CEP Encryption certificate issued to the MSCEP RA.

3.  Right-click on the certificate, select All Tasks from the context menu, and then select Manage Private Keys... as in Figure 3 below.

Figure 3

4.  This will launch the ACL Editor.

Figure 4

5.  Click Add, and select the NDES service account created prior to installing the NDES role.

6.  Click Ok.

7.  Verify that the NDES service account has full control over the key, and then click Ok.

Figure 5

Repeat this process with the Exchange Enrollment Agent certificate issued to the MSCEP RA account.

Testing Enrollment

Once all the above steps have been complete, reset the IIS service on the NDES server. To do this, launch the command prompt and run iisreset.exe. The NDES service is now ready to accept device administrator password requests as well as SCEP enrollment requests from the network devices.

At this point the device administrator should attempt an SCEP enrollment from a network device to verify that the NDES service is configured correctly.

To obtain the SCEP password, the device administrator uses Internet Explorer to go to the following site:

http://<servername>/certsrv/mscep_admin

Figure 6

With the password in hand, the device administrator configures the network device with the password and the enrollment site in order for the device to enroll for the certificate. The enrollment site is:

http://<servername>/certsrv/mscep

If enrollment succeeds the NDES service is configured correctly.

Summary

The goal of this document was to replace the non-exportable certificates and keys generated during the install of the Network Device Enrollment Service role with new certificates that are exportable. The server administrator should now take steps to export the CEP Encryption and Enrollment Agent certificates issued to the MSCEP RA so that they can be imported on another server as needed.

- Jonathan Stephens

Craig here. In Directory Services we support a whole bunch of components which each have their own debug logging. A while back I pulled together all the information from various KB and TechNet articles and distilled it into a concise list of how logging is enabled for each component we support. I cleaned it up a bit and am posting it here thinking that some of you may also find it useful.

A few caveats before you dive in and start enabling logging all over the place:

• Enabling debug logging in general is not the first troubleshooting step to take. In many situations it can be overkill and only serve to confuse things. Better to first know the exact steps to reproduce a problem, the exact error messages involved, and overall have a good understanding of the problem end-to-end. I say “in general” because if you are an expert at reading a certain type of debug log, you may be successful at using it earlier in your troubleshooting process, but even that level of expertise rarely gets you around the need for a solid understanding of how the problem presents itself.
• Not all errors in debug logs are really errors. Many types of debug logging in Windows were never intended to be used by customers to troubleshoot problems, but rather as a way for the developer to debug their own component. Because of that, there are many times when an error is logged that is normal, expected behavior for a component. This is why looking at the debug logs can often only confuse matters if you start troubleshooting an error that is actually perfectly normal behavior for the component. In situations like this it is helpful to compare the output to that of a functioning machine, although even that isn’t always fool-proof at determining what the “real” errors are.
• Debug logging can be resource intensive and should only be enabled while you are troubleshooting the problem. One of the most common questions asked when we tell a customer to enable some type of logging is “what will this do to the machine?” Unfortunately there isn’t always a simple answer. For many types of logging there is negligible overhead, and the machine will perform nearly the same as if the logging was not enabled. However there are some types of logging that are fairly resource intensive and may cause a tangible performance decrease while enabled. There are many variables that make it difficult to know exactly how it will affect a specific machine. The level of logging enabled, the hardware specs of the machine, and what the machine is being used for are just a few variables that come into play. That is why it is a best practice to enable logging for the shortest period of time necessary to troubleshoot an issue, and then disable it.

Enabling Logging From the Command Line, Vbscript, or PowerShell

Here are a few of the basic methods using command scripting, Vbscript, or PowerShell. Since a majority of logging types are enabled in the registry, the examples will focus on that.

Reg.exe is included in Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. It is also part of the Windows 2000 Resource Kit, although that version is not available for public download. Reg.exe lets you manipulate the registry on a local or remote machine from the command line. If the registry key, value name, or value data contain a space, you must put them in quotes. If the value data is a hex number, for example, 0x4B, it must contain the 0x prefix in the command syntax. Using the /f switch with Reg Add and Reg Del prevents it from asking to overwrite if the value already exists, and prevents it from asking for a delete confirmation. To run these against a remote computer, add \\<computername> to the registry path, for example, "\\SRV01\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

Using Reg.exe to Enable UserEnv Logging

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v UserEnvDebugLevel /t REG_DWORD /d 0x10002 /f

Using Reg.exe to Disable UserEnv Logging

reg delete"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v UserEnvDebugLevel /t REG_DWORD /d 0x10002 /f

Using Reg.exe to Determine if UserEnv Logging is Enabled

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v UserEnvDebugLevel

Since the Windows Scripting Host is available on just about every Windows computer you might run into today, Vbscript is another simple way to automate this. To specify a remote computer, you would change strComputer = “.” to strComputer = “SRV01” or whatever the target computer name is.

The first three lines stay the same regardless if you are adding, deleting, or querying the registry value.

Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")

To add the value, you would add this line:

objReg.SetDWORDValue HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon","UserEnvDebugLevel",65538

To delete the value, you would instead add:

objReg.DeleteValue HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon","UserEnvDebugLevel"

To query the value, you would instead add:

objReg.GetDWORDValue HKEY_LOCAL_MACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon","UserEnvDebugLevel",strValue
Wscript.Echo Hex(strValue)

For more information, see WMI Tasks: Registry and the Script Center.

PowerShell is not installed on any released Windows version by default. It is available as an optional component to install in Windows Server 2008, but it is not installed by default there either. Despite that, it really is the best environment for admin scripting, and even with the lack of remoting in version 1.0, we get around that here by using the .NET RegistryKey class, although you could also use WMI’s StdRegProv similar to how it was called in the Vbscript sample above.

The first three lines stay the same regardless if you are adding, deleting, or querying the registry value. Replace SRV01 with the name of your target computer.

$RegKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,"SRV01")
$RegKey = $regKey.OpenSubKey("SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon",$True)

To add the value, you would add this line:

$RegKey.SetValue("UserEnvDebugLevel",0x10002)

To delete the value, you would instead add:

$RegKey.DeleteValue("UserEnvDebugLevel")

To query the value, you would instead add:

"{0:X}" -f $RegKey.GetValue("UserEnvDebugLevel")

The "{0:X}" -f just tells it to display as hex. For more information, see Scripting with Windows PowerShell.

Directory Services Debug Settings

Active Directory Federation Service (ADFS)

To enable debug logging for the ADFS Authentication Package on an account federation server:

To enable debug logging for the ADFS Token Authentication service:

To enable debug logging for the ADFS ISAPI extension:

To enable debug logging for the ADFS Web Agent Authentication package:

Use the following to specify the level of events that you want logged for Windows NT Token-based applications in the Application log on the Web Server:

For more information, see Configuring ADFS Servers for Troubleshooting.

AppMgmt

Note that you may need to create the Diagnostics key. For more information, see Enable Logging for Software Installation Client Side Extension and KB article 246509.

Certificate Services

CAPI2

CAPI2 is the new cryptography API available in Vista/2008. CAPI2 diagnostics greatly improves on the PKI diagnostics available in 2000/XP/2003. CAPI2 diagnostic information is logged to the CAPI2 Operational log, which is located at Applications and Services Logs\Microsoft\Windows\CAPI2\Operational in Event Viewer. You can use CAPI2 logging to troubleshoot most PKI operations in Vista/2008.

CAPI2 logging is not enabled by default. To enable it, right-click the CAPI2 Operational log in Event Viewer and select Enable Logging. You can also enable it using Wevtutil:

wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true

To disable it with Wevtutil the syntax is:

wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false

For more information, see Troubleshooting PKI Problems in Windows Vista.

DCPROMOUI

For more information, see KB article 221254 and Active Directory and Removal Issues.

DFS Replication

Except for event log verbosity, every setting listed below can be enabled using WMIC (included in Windows) or by directly editing \System Volume Information\DFSR\Config\DfsrMachineConfig.XML. Editing the XML file is more tedious as many settings do not exist in the XML file until they are changed from defaults, so it is not as simple as changing a value, you must also add the associated XML tags. Using WMIC to change the WMI properties takes care of all of that for you.

By default DFS Replication debug logs are created in %SystemRoot%\Debug. The log files are named Dfsr#####.log. This naming convention is hard-coded. The log level is set to Informational (4) by default. DFS Replication logs up to a configurable maximum number of 200,000 lines per log file. When the numbers of lines in a log file exceeds the configured maximum lines per log file, DFS Replication will move on to the next log file (Dfsr00002.log, Dfsr00003.log, and so on). In order to conserve disk space (especially since logging is at log level 4 by default), DFS Replication compresses each log file using Gzip compression before creating the next log. Compressed files are named Dfsr#####.log.gz and can be decompressed with most of the common compression tools (Winzip, WinRAR, etc.).

With the default settings (MaxDebugLogFiles=100,MaxDebugLogMessages=200000) all the debug logs combined should use no more than approximately 50 mb of disk space.

By default the following events are suppressed unless verbose event logging is enabled. This was done to keep the event log free of excessive informational events.

Sample WMIC command syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogseverity=5

Sample WMIC command syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set maxdebuglogmessages=500000

Sample WMIC command syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set maxdebuglogfiles=200

Sample WMIC command syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogfilepath="d:\dfsrlogs"

The new path must be created manually; if not, at service restart, the default value %SystemRoot%\Debug will be used.

Sample WMIC command syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set enabledebuglog=true

For more information, see Using DFSR.

DFS Management

Output: %SystemRoot%\Debug\DfsMgmt\DfsMgmt.current.log

Steps:

1. Open %SystemRoot%\System32\Dfsmgmt.dll.config in Notepad.
2. Change this line:
   
   <add key="DfsTraceListenerEnabled" value="0" />
   
   to this:
   
   <add key="DfsTraceListenerEnabled" value="1" />
   
   Change this line:
   
   <add name="DfsFrsTracing" value="0" />
   
   to this:
   
   <add name="DfsFrsTracing" value="65535" />
   
   Change this line:
   
   <add name="DfsFrsSnapIn" value="0" />
   
   To this:
   
   <add name="DfsFrsSnapIn" value="65535" />
   
3. Close and reopen DFS Management (Dfsmgmt.msc) if it was open.

The default maximum log size is 10 MB (10,240 KB). The maximum you can configure it for is 256 MB (262,144 KB). When the maximum size is reached DfsMgmt.current.log is renamed to DfsMgmt.previous.log and a new DfsMgmt.current.log is created.

To change the maximum log size:

Change this line in the %SystemRoot%\System32\Dfsmgmt.dll.config file:

<add key="MaxTraceLogSize" value="10240" />

to this:

<add key="MaxTraceLogSize" value="262144" />

DNS Client

Steps:

1. Create Dnsrslvr.log in %SystemRoot%\System32 with at least one character or space in the file.
2. Restart the DNS client service.

Steps:

1. Create Asyncreg.log in %SystemRoot%\System32 with at least one character or space in the file.
2. Restart the computer.

Folder Redirection

For more information, see KB 907355 and Enable Logging for Folder Redirection Client Side Extension.

File Replication Service (FRS)

For more information, see KB article 221112 and FRS Tools and Settings.

Group Policy Processing

In Vista/2008, Group Policy processing information is logged to the System log and the Group Policy Operational log, which is located in Applications and Services Logs\Microsoft\Windows\GroupPolicy\Operational in Event Viewer. The logging done to the System log and the Group Policy Operational log are both enabled by default. The GPLogView tool can be used to export Group Policy processing events to aid in troubleshooting. For more information see Troubleshooting Group Policy Using Event Logs.

In 2000/XP/2003, Group Policy processing information is logged to the Application log and to the User Environment (UserEnv) debug log. UserEnv logging is discussed later in this post.

Group Policy Object Editor (Gpedit.msc)

Additional debug value data settings are:

A data value of 30003 would set all the appropriate flags in this case (and would also write to the debugger port, which would slow the system somewhat). That is why we recommend setting the value to 10002 (Verbose plus Logfile).

Gptext logging can also be helpful for troubleshooting QoS, Scripts, Wireless, and IPSEC.

For more information, see Fixing Group Policy Problems By Using Log Files.

Group Policy Management Console (GPMC)

For more information, see Enable Logging for Group Policy Management Console and KB article 942412.

IPSec

For more information, see KB article 257225 and Troubleshooting Tools.

Kerberos

For more information, see Troubleshooting Kerberos Errors and KB article 262177.

Microsoft Directory Synchronization Service (MSDSS)

For more information, see KB article 269536.

Netlogon

Besides editing the registry directly, you can use the Nltest tool (part of the Support Tools) to enable it:

nltest /dbflag:0x2080ffff

To disable it run:

nltest /dbflag:0x0

If the Netlogon.log file size exceeds the MaximumLogFileSize, the file will be renamed with a .BAK extension and a new Netlogon.log file will be created. If a Netlogon.bak file currently exists, it is deleted before the current log file is renamed to Netlogon.bak. The end result is a circular logging amount of 2 * MaximunLogFileSize (default is 20000000 bytes, or approximately 20 MB). The MaximumLogFileSize can be modified by editing the registry.

MaximumLogFileSize can be up to 0xFFFFFFFF, which would allow for a 4 GB Netlogon.log. The MaximumLogFileSize registry value does not exist by default.

On Windows Server 2003 the log file size can be configured using Group Policy:

\Computer Configuration\Administrative Templates\System\Net Logon\Maximum Log File Size

For more information, see Domain Controller Locator and KB article 109626.

NTDS

Note that setting any of these to 5 can result in an excessive number of events being logged. For more information, see KB article 314980 and Data Store Tools and Settings.

Schannel

Software Restriction Policies

For more information, see Using Software Restriction Policies to Protect Against Unauthorized Software.

User Environment (UserEnv) Debug Logging

For more information, see KB article 221833 and Enable Logging for Core Group Policy.

Windows Time Service (W32Time)

• 0-300 is the highest possible value for the most detailed logging. The actual value you type in is “0-300” without the quotes.
• You must restart the W32Time service for the logging to take effect (not necessary for Windows Vista or Server 2008).
• You cannot use a system variable such as %SystemRoot% or %Windir% in the FileLogName path. It must be an explicit path such as C:\Windows\Temp\W32Time.log.
• You cannot use C:\Windows\Debug for the FileLogName path. The service will log an Access Is Denied error when you restart it and no logging will occur.

For more information, see KB article 816043 and Windows Time Service Tools and Settings.

Windows Installer (MSI)

For more information, see KB article 223300 and Fixing Group Policy Problems By Using Log Files.

Winlogon

For more information, see KB article 245422 and Fixing Group Policy Problems By Using Log Files.

- Craig Landis

Hi. Jim from DS here to tell you more than you ever wanted to know about the Security Descriptor Definition Language (SDDL). Windows uses SDDL in the nTSecurityDescriptor. The SDDL defines string elements for enumerating information contained in the security descriptor. You may want to grab some coffee now.

Before we explain SDDL , let me explain what SDDL describes – a security descriptor. A security descriptor is a binary data structure of changeable length that contains security information associated with a protected (securable) object. This includes information about the object’s owner and who can access the object and in what way. The security descriptor also includes information on how access to the object is audited. Windows uses security descriptors to control access to resources. Examples of resources to which security descriptors apply are files, folders, registry keys, network shares, printers and Active Directory objects like OU’s and DNS zones.

A security descriptor contains two access control list’s (ACL) for each resource, Discretionary Access Control List (DACL) and System Access Control List (SACL). An ACL is a list of ordered Access Control Entries (ACE) that specify allowed, denied or audited access rights. The DACL identifies users and groups who are allowed or denied access to an object and in what way the object is accessed. The SACL defines how access is audited on an object.

What we are talking about here at the core is permissions and auditing. Each permission for a securable object granted to a user or group is stored as an ACE within a DACL that is a part of…

You guessed it! The security descriptor. Can you feel the love? Try to contain your excitement as we press onward.

The access token is linked to the security descriptor. An access token contains security information about an authenticated user. Windows performs an access check when a user or service attempts to access a resource. During the access check, Windows compares the access token of the requesting account to the objects DACL. This bit of wonderment is discussed in great detail here - http://blogs.technet.com/askds/archive/2007/11/02/what-s-in-a-token.aspx

If auditing is enabled for an object, the objects Security Descriptor will also contain a SACL that controls how attempts to access the object are tracked by the security subsystem.

Just for fun let’s view the security descriptor for shares on a server by traversing the registry. The following screen shot illustrates the security descriptor on a share named Tools as REG_BINARY data on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSEt\Services\lanmanserver\Shares\Security key of a 2003 DC. This key contains all the information I spoke about earlier (DACL, SACL, etc.) Good luck deciphering that data format.

Of course you are all familiar with the GUI representation of the security descriptor as shown in the following screenshot of the very same TOOLS share.

Auditing Tab

Now that you understand what a Security Descriptor “is”, we can explore the language used to describe what the security descriptor contains. This language is useful for developers and administrators alike to understand and utilize the administrative functionality as well as the portability of the security descriptor.

It is possible to use the SDDL to simplify some administrative tasks in regard to setting ACL’s on objects. What follows is a cursory overview on what can be contained in an nTSecurityDescriptor SDDL string. Here is an example of a SDDL string extracted from the aforementioned TOOLS share:

O:BAG:SYD:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU)S:AI(AU;OICINPFA;RPDTSDWD;;;BU)(AU;OICINPSA;CCSWRPDTLOSD;;;BU)

Each nTSecurityDescriptor SDDL string is composed of 5 parts which correspond to:

The Header - The header contains flags that designate whether the object is allowing or blocking inheritance for the SACL and DACL. If inheritance is allowed, permissions flow down from a parent object. If inheritance is blocked the permissions do not flow down from a parent container or object.

DACL (D:) – The Discretionary Access Control List denoted by the (D:)

SACL (S:) – The System Access Control List denoted by the (S:)

Primary Group (G:) – This value is still in the security descriptor for compatibility reasons. Windows 2000/2003 does not rely on this part of the security descriptor unless you are using services for UNIX and/or Macintosh with tools and utilities applying thereto.

Owner (O:) – Indicates which trustee owns the object. A trustee is the user account, group account, or logon session to which an access control entry (ACE) applies. Each ACE in an access control list (ACL) has one security identifier (SID, also called a principal) that identifies a trustee. The value is represented in SID string format. A security identifier (SID) identifies a user, a group, or a logon session. Each user has a unique SID, which is retrieved by the operating system at logon.

SIDs are issued by an authority such as the operating system or a domain server. Some SIDs are well-known and have names as well as identifiers. For example, the SID S-1-1-0 identifies Everyone (or World).

The contents of both the primary group and owner parts are a single SID. The contents of both the SACL and DACL parts are a string with varying length. ACE’s are contained within these strings.

ACE’s are enclosed within parenthesis. There are 6 fields in each ACE. These 6 fields are separated by a semicolon delimiter.

The fields are as follows:

ACE type (allow/deny/audit)

ACE flags (inheritance and audit settings)

Permissions (list of incremental permissions)

ObjectType (GUID)

Inherited Object Type (GUID)

Trustee (SID)

By using CACLS you see below in SDDL format the security descriptor for the ACL’s on the very same Tools share:

Here is the output exported to a .txt file:

"D:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU)"

In part II of my SDDL Blog series I will dissect the SDDL format in the previous extraction and from other securable objects to further explain the descriptor language and its usefulness.

- Jim Tierney

Hi, Tim here. Ever heard of a Best Practice Analyzer, otherwise known as a ‘BPA’? It’s a type of tool that many of our product or support teams have been creating the last few years which can be used to gauge the general health of a component before things go catastrophically wrong. BPA's can also identify problems that are present in one nice fell swoop so that you don’t have to work super hard to find them yourself.

Exchange BPA is one that is widely used and has had great successes over the past few years, as an example.

You may know of this kind of thing by its only other real world implementation: a consultant.

This brings up the main two differences you may see between a BPA and a consultant: BPA's never vary in quality or experience and BPA's are FREE. Free, as I’ve mentioned before, is my favorite word.

We have a BPA for Group Policy. This tool can be ran against Server 2003 and Windows XP computers to give a good and instant idea on whether there are problems and what they are. There’s your value in this folks-problems are identified for you. In addition you can take a sample of your normal problem-free environment and store it as a Baseline for comparison purposes for when you run GP BPA following a problem or as a standard procedural health check.

Group Policy BPA installs as an application and has an easy to use wizard type interface to walk you through. Reports can be reviewed later (as I mentioned above) for comparison or even exported to send to a colleague or backup.

Check out these problems Group Policy BPA found on one of my servers:

Anything that minimizes the required thinking without a degradation in my performance or quality of work is a Good Thing. Group Policy BPA is therefore a Good Thing for IT People.

We have a general Knowledge Base Article about this great FREE offering here: "How to use the Microsoft Group Policy Diagnostic Best Practice Analyzer (GPDBPA) tool to collect and to analyze data" (http://support.microsoft.com/kb/940122). One of the big things that article does is contain links to where you can download GP BPA. In order to be repetitive and repeat myself or say the same thing again I’m giving you those same links below:

Group Policy Diagnostic Best Practice Analyzer for Windows Server 2003 (KB940122)

http://www.microsoft.com/downloads/details.aspx?FamilyId=47F11B02-8EE4-450B-BF13-880B91BA4566&displaylang=en

Group Policy Diagnostic Best Practice Analyzer for Windows Server 2003 x64 Edition (KB940122)

http://www.microsoft.com/downloads/details.aspx?familyid=70E0EDEC-66F7-4499-83B7-4F2009DF2314&displaylang=en

Group Policy Diagnostic Best Practice Analyzer for Windows XP (KB940122)

http://www.microsoft.com/downloads/details.aspx?FamilyId=70E4A971-DA91-4D4F-BF92-5C75A84F3742&displaylang=en

Group Policy Diagnostic Best Practice Analyzer for Windows XP x64 Edition (KB940122)

http://www.microsoft.com/downloads/details.aspx?FamilyId=317C372C-0FE3-4AD0-BE52-2FF3004DAEF0&displaylang=en

Group Policy BPA is an administrator’s friend and can either shed light on pre-existing problems or set your mind at ease that you don’t have problems at all.

So I have two questions for you:

• If you’re not using Group Policy BPA, why aren’t you?
• If you are using Group Policy BPA, what do you think?

Microsoft is very interested in your feedback on how we can make Group Policy BPA better for you so please tell us what you think. This is a great chance to get your feedback directly back to the folks who make the product, and we’d love to hear from you.

So please comment this post or email us to let us know!

- Tim Springston

Hi, Brantley here. I would like to share some information with you about how digital certificates work. Understanding the concepts about how certificates work is important when troubleshooting PKI issues.

Let’s start by defining digital certificate: digital certificates are electronic credentials that are used to assert the online identities of individuals, computers and other entities on a network. The concept of digital certificates is much like the concept of a driver’s license. Like a drivers’ license, a certificate is issued by a central authority that has validated the identity of the person (or computer, application, services, etc) requesting the certificate. Now that we have defined digital certificates let us move on to the details.

Certificate Architecture

Certificates issued by Windows Server 2003 and earlier are based on standards established by the Public-Key Infrastructure X.509 Working Group of the Internet Engineering Task Force. Version 1 of the standard defines a set of fields that should exist in every X.509 digital certificate. Version 2 added two more fields in order to support X.500 directory access control. Finally, version 3 introduced the concept of a Certificate Extension. Certificate extensions are simply fields that may be specified in standards or may be defined by a registered by a vendor, individual, or community. The Windows Certificate Server included in Windows 2000 and later supports X.509 Version 3 digital certificates.

The format of a v3 digital certificate is illustrated below.

X.509 Version 3 Certificate

• Version: Identifies the version of the X.509 standard to which the certificate adheres. Certificates issued by a Windows CA certificate authority are always v3.
• Certificate Serial Number: A unique identifier for each certificate issued by a particular Certificate Authority. This number must be unique amongst all certificates issued by that CA.
• Issuer: The distinguished name of the CA that issued the certificate. This field identifies the authority responsible for verifying the identity of the Subject of the certificate.
• Subject: The name of the computer, user, network device or service to which the certificate is issued.
• Valid from: The date and time when the certificate becomes valid.
• Valid to: The date and time when the certificate expires.
• Public Key: Contains the public key of the key pair that is associated with the certificate.
• Issuer Unique Identifier: Information that can be used to uniquely identify the issuer of the digital certificate.
• Subject Unique Identifier: Information that can be used to uniquely identify the owner of the digital certificate.
• Extensions: Version 3 certificates include extensions that provide additional functionality and features to the certificates.

As can be seen, a digital certificate links a subject identity and a public/private key in a signed and therefore verifiable digital document.

Example User Certificate

When double clicking on a certificate in Windows the Details tab displays the fields mentioned above. This is an easy way of visually verifying the Validity dates and the Subject.

The Certification Path tab displays the certificate path from the root down to the certificate being evaluated.

Basic Certificate Validation:

For a certificate to function properly, the following items must validate correctly (at a minimum):

1. Subject name: The subject of the certificate must match the resource subject that is being used. For example, when using https the subject in the certificate being used on the web server must match the https URL that users will use to connect to the https website. Subject name is analogous to the name on a driver’s license.

2. Validity Period: The (Valid From) and (Valid To) must be within the time frame the certificate is planning on being used. This is much like the expiration of a driver’s license. Validity period is analogous to the expiration date on a driver’s license.

3. Trust: The certificate must be used by a trusted Certificate Authority. Trust is analogous to the State that issued a driver’s license. Because the State that issued the license is a member of the union that makes up the United States we trust the issuer of the license.

4. Chain Building: Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate.

5. Key Usage: To help control the usage of a certificate outside of its intended purpose, the optional Enhanced Key Usage extension can be included in the certificate by the CA. The Enhanced Key Usage extension contains a list of usages for which the certificate is valid. These usages, also known as intended purposes, are displayed on the General tab of the certificate dialog box. This is important when evaluating why a certificate may not be working correctly. Key Usage is analogous to driver’s license endorsements (types of vehicles that can be driven with this license).

6. Revocation Checking: Each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. A certificate can be revoked prior to the expiration date to disavow the certificate. Revocation Checking is analogous to checking a driver’s license against a State database to verify that a driver’s license has not been revoked for a violation.

Summary:

Certificates issued by Windows Server 2003 and earlier are based on standards established by the Public-Key Infrastructure X.509 Working Group of the Internet Engineering Task Force. The Windows Certificate Server included in Windows 2000 and later supports X.509 Version 3 digital certificates. Subject Name, Validity Period, Trust, Chaining, Key Usage, and Revocation need to be validated for a certificate to function properly.

- Brantley Whitley

Hi.  This is Jim from Directory Services.  I spend a great deal of time working through remote Easy Assist / Live Meeting sessions, sometimes with client machines half way round the globe and the latency can be excruciating.

In my experience I have found that using the CMD line as well as START - RUN to launch administrative tools can be a more expedient way to do system administration.  Using the mouse and clicking repeatedly to launch an administrative interface is not always the most efficient, especially in an extremely latent remote session.  An errant click will always do you in. To this end I felt the need to create a one stop “short cut” reference to launch some of the more popular administrative applets.  This is suitable for pinup in your cube or office.  Feel free to commit them all to memory.

RUN/CMD shortcuts for AD management

These are .exe’s

The following are contained within the WINDOWS 2003 ADMINISTRATION TOOLS PACK
*Installed from the Windows Server 2003 CD

2008 SERVER

RUN shortcuts for Windows OS management

- Jim "Mouse-Click Blues" Tierney

Hi, Ned here again. The Microsoft Office 2007 product group has released a terrific new whitepaper that covers the ins and outs of deploying Group Policy settings for Office 2007, and they asked that we share the love with you here from AskDS.

The whitepaper covers (in 187 exhaustive pages) recommendations and how-to info for Planning, Deployment, Operations, and a complete technical reference. This guide is actually a subset of the even more massive 2007 Office Resource Kit.

You can download the Group Policy for Office 2007 guide from here.

And while this is linked in the document, there's also a complete set of ADM, ADMX, and ADML group policy templates available.

You can download the ADM/ADMX/ADML templates from here.

Finally, you may also want to grab the 2007 Office Security Guide. This whitepaper covers the aspects of security that are often overlooked - document security once it leaves your safe and secure file servers. Confidentiality, integrity, and availability are the watchwords here. It has a number of tie-ins to Group Policy as well.

You can download the Office 2007 Security Guide from here.

Keep in mind that these templates and Office Group Policy are supported by the Office teams. In Directory Services, we support you getting the policies onto your users and machines - it's up to the component affected to have it actually work as expected. But I figured if you read this blog, you probably care about GP. :-)

If you want to get more info on the Office suite and stay in the MS blog-o-sphere, check out:

http://blogs.technet.com/office_resource_kit/
http://blogs.msdn.com/microsoft_office_word/
http://blogs.msdn.com/excel/
http://blogs.msdn.com/outlook/
http://blogs.msdn.com/access/
http://blogs.msdn.com/officedevdocs/
http://blogs.msdn.com/officerocker/

Dang, that's a lot of links. Nice work, Office folks.

- Ned Pyle

Sorry for the delay. I'm having to catch up on some posts after being on vacation. In the meantime, plenty of wonderful Directory Services-related KB articles have been published. As expected, lots of content for Windows Server 2008 now that the product is out the door.

- Craig Landis