Blog - Title

March, 2008

  • Managing Power with Group Policy: Part 1 of 3

    Hi, Mike here again. This post was originally published in the Group Policy Team blog. Many of you probably know about the power management improvements included in Windows Vista and that you can manage power using Group Policy. However, did you know that you can manage power on Windows XP using Group Policy as well? I decided to update the “Power” blog series to show you how Windows Server 2008 can help you manage power at the desktop for both Vista and Windows XP.

    Windows Vista provides a tremendous amount of power management support through Group Policy. Power management is comprised of 34 policy settings grouped in 6 different categories. The categories I will write about this week include Button, Hard Disk, Notification, and base Power Management settings.

    These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\System\Power Management. These policy settings are new with Windows Vista and apply only to computers running Windows Server 2008 or Windows Vista or. Also, these policy settings can co-exist in policies applicable to clients earlier than Windows Vista. Operating systems other than Windows Vista ignore the settings.

    clip_image002

    Figure 1- Computer power management

    Power management Group Policy settings target computers therefore; the majority of the settings are under the Computer Configuration. The main category, Power Management, contains two settings, one settings allows you to deploy one of the standard power management configurations and the others allows you to specific a GUID of a customer power management configuration.

    Under Power Management is the Button Category. This category has eight policy settings. You can further categorize these policy settings into two categories of four: policies for when the computer is plugged-in and for when the computer is on battery. The four settings allow you to define the actions performed when the user presses the power or sleep button or, when the user closes the lid of the computer. The last setting controls the power button located on the Start menu. Enabling any of these policy settings gives you a choice of Hibernate, Shut down, Sleep, or Take No Action.

    clip_image004

    Figure 2- Button policy settings

    The next category is Hard Disk. This category has two policy settings. As with the other power management categories, it categorizes these policy settings for when the computer is plugged-in and when the computer is on battery. You use this policy setting to shut down the user hard drive after a specified amount of inactivity. Enabling this policy setting allows you to provide the number of seconds before Windows reduces power to the hard drive.

    clip_image006

    Figure 3- Hard drive power policy settings

    The last category for the blog entry is Notification. These five policy settings allow you to configure the notification levels and actions for Low Battery and Critical Battery events. Also, you can disable Low Battery user notification. Low Battery and Critical Battery level policy settings allow you to set the level where Windows will trigger Low Battery or Critical Battery actions. You determine each level by entering a percentage of remaining battery power. Your choice of settings for Low Battery and Critical Battery actions include: Hibernate, Shut down, Sleep, and Take No Action.

    Don’t ignore power management; sure, it is only a small amount of money saved per client. But add that amount up over time and across multiple computers and you could save a substantial sum of cash from reduced power usage, less wear-and-tear, as well as environmental cooling benefits.

    Managing Power with Group Policy: Part 1 of 3
    Managing Power with Group Policy: Part 2 of 3
    Managing Power with Group Policy: Part 3 of 3

    -Mike Stephens

  • Managing Power with Group Policy: Part 2 of 3

    Mike here. Last time, I introduce new Power Management policy settings included in Windows Vista. In the first of a three parts, I wrote about Button, Hard Disk, and Notification policy settings. Today, I continue to review Power Management by writing about Sleep and Video and Display power management policy settings.

    As a reminder, these categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\System\Power Management. These policy settings are Windows Vista policy settings and apply only to computers running Windows Vista. Also, these policy settings can co-exist in policies applicable to clients earlier than Windows Vista. Operating systems other than Windows Vista will ignore the settings.

    clip_image002

    Figure 1- Sleep power policy settings

    I’ll start with the Sleep power management category and its policy settings. As I wrote in part one, Windows divides most Power Management policy settings into Plugged In or On Battery policy settings (Plugged In or On Battery actually appears in the name of the policy setting). This gives the category 12 policy settings total; 6 for Plugged In and 6 for On Battery. These policy provide the means to adjust how Windows Vista behaves prior to entering, during, and waking from sleep mode. I’ll begin by providing the name of each policy setting and a summary of its intent.

    The policy setting Turn on Applications to Prevent Sleep Transitions, when enabled, provides application and services a way to prevent Windows Vista from entering sleep mode (including but not limited to Hybrid Sleep, Stand By, or Hibernate).

    Enabling the policy setting Specify the System Hibernate Timeout allows you to enter a value, in seconds, to indicate how much idle time elapses before Windows enters into hibernate. Another related policy setting is Specify the System Sleep Timeout, only the value entered (in seconds) indicates how much idle time elapses before Windows enters sleep mode.

    The policy setting Require a Password when a Computer Wakes works exactly as it is written—it prompts the user for password when the computer wakes. It is also important to know this is the default behavior for Windows Vista, even when you set this policy setting to Not Configured.

    Windows Vista includes a Hybrid Sleep mode. Hybrid sleep saves the system state and additional information to a hiberfile. Windows uses this file when it wakes from Hybrid Sleep mode. When enabled, the policy setting Turn Off Hybrid Sleep prevents Windows from creating the hiberfile, which disables Hybrid Sleep mode.

    The last setting in this category controls the behavior (or state) of a computer running Windows Vista while in sleep mode. Recently manufactured computers conform to the specification know as Advanced Configuration and Power Interface, or ACPI. This specification is the most popular standard for computer power management. The ACPI specification describes standby states when a computer is sleeping. A portion of the specification labels these standby states as S1, S2, S3, and S4 (you can find more information on ACPI and the specifics to these states at http://www.acpi.info/). When you enable the policy Allow Standby States (S1-S3) when sleeping, Windows Vista may use standby states S1 - S3 while in sleep mode. If you disable the policy, Window Vista only allows the computer to use hibernate (standby state S4) as a sleep state.

    clip_image004

    Figure 2- Video power management policy settings

    The last category in Power Management is Video and Display Settings. This category has four policy settings total, two when Plugged In and two when On Battery. The first policy setting controls a new feature included in Windows Vista-- Adaptive Display. Adaptive Display Timeout, on by default, extends the time Windows waits to turn off the display if you repeatedly turn on the display using the keyboard or mouse. Enabling Turn Off Adaptive Display Timeout disables Adaptive Display timeout resulting in Windows turning off the display once the idle timeout time is exceeded, which is controlled by the remaining policy in this category. The Turn Off the Display policy settings, when enabled, allows you to enter a value in seconds indicating the maximum allotted idle time before Windows turns off the display.

    Two blogs complete and one more to go. Next time, I’ll conclude Managing Power with Group Policy by discussing how to use Window Server 2008 to manage power on Windows XP workstations.

    Managing Power with Group Policy: Part 1 of 3
    Managing Power with Group Policy: Part 2 of 3
    Managing Power with Group Policy: Part 3 of 3

    -Mike Stephens

  • Kerberos for the Busy Admin

    Hi Rob here, I am a Support Escalation Engineer in Directory Services out of Charlotte, NC, USA. We work a lot of Kerberos authentication failure issues. Since Kerberos is typically the first authentication method attempted, it ends up having authentication failures more often. One of the great things about Windows is that the product seems to just work without too much customization that is needed by the customer. However I wanted to create a blog to try and demystify how Kerberos authentication works. I plan on writing several Kerberos blogs in the near future to include Kerberos Delegation aka Double-hop, how to troubleshoot Kerberos authentication.

    There are some general terms that you might not be familiar, so let's run through them quickly.

    Principal Names:

    Kerberos defines two different types of accounts (or Principals). The two different names given to these types of accounts are User Principal Name (UPN), and Service Principal Name (SPN). We would typically relate these two types of principals to Active Directory users and computers.

    Only user accounts have a UPN defined on their account. When looking at a user account if you click on the Account tab, the UPN is derived from the combining of the two fields listed for “User logon name”. A User Principal Name must be unique across the entire forest otherwise when the KDC goes to look up the Users Account via UPN it will get back more than one account and cause authentication failures for all users that have the same UPN. The UPN of an Active Directory object is an attribute of the object, and can only hold a single value. The attribute name is userPrincipalName. An example of a UPN is: rob@contoso.com.

    Service Principal Names MUST be unique across the entire Active Directory forest, and can be assigned to either User accounts or Computer accounts. Only computer accounts automatically have Service Principal Names defined.

    Service Principal Names define what services run under the accounts security context. For example some of the services that a computer might have are File server / CIFS (Common Internet File System), if it is a domain controller it is going to have an LDAP SPN, and Active Directory Replication SPN, and FRS SPN. Service Principal Names can be defined on user accounts when a Service or application is running under that users Security context. Typically these types of user accounts are known as “Service Accounts”. It is very import that you understand that Service Principal Names MUST be unique throughout the entire Active Directory forest.

    Some typical scenarios when a user account has a Service Principal Name defined are:

    • When SQL Server Service is using a user account or “Service Account” instead of the default of “LocalSystem”. An example is: MSSQLSvc/sqlsrvr.contoso.com:1433
    • When an IIS Web Application Pool is running as a specified user account rather than as the default of “Network Service”. An example is: http/websrvr.contoso.com

    Some tools that can be used to list the Service Principal names on an Active Directory object are: LDP, LDIFDE (These two are great utilities if you want to query LDAP for all objects that have the SPN defined on them.), next is ADSIEdit, or SetSPN. The last two are great utilities if you want to see what SPNs are registered on a given object.

    Kerberos tickets:

    KDC (Key Distribution Center): The KDC is a service that should only be running on a domain controller. The service name is “Kerberos Key Distribution Center”. Basically the KDC is the service that is responsible for authenticating users when Kerberos is used. The KDC implements two server components. Authentication Server (AS), and Ticket Granting Server (TGS).

    Authentication Server (AS): The KDC role that verifies the identity of the principal and issues the Ticket Granting Ticket (TGT) to the principal upon successful authentication. Holding a valid TGT allows the principal to request a Service ticket from the Ticket Granting Server (TGS). There will be a TGT in the Credentials Cache for each domain the principal has accessed resources in. An example of this would be: a user in contoso.com domain wanted access to a file server in emea.contoso.com the user would have a TGT for contoso.com, and emea.contoso.com

    Ticket Granting Server (TGS): The KDC role that issues a service ticket when a principal requests connection to a Kerberos service. You must have a Ticket Granting Ticket (TGT) for the Active Directory domain before you can be issued a service ticket in that Active Directory domain. Although the KDC issues the service ticket it does not talk directly to the service that the principal is requesting the ticket for. Once a service ticket has been issued by the Ticket Granting Server, the service ticket is put into the principal’s credentials cache for later use. When the principal needs to connect to the requested service the service ticket is used from the credentials cache and sent to the service it is attempting to connect to.

    There are only two different types for tickets that the KDC issues.

    • Ticket Granting Ticket (TGT)
    • Service tickets from the Ticket Granting Server.

    Kerberos Ticketing Process:

    How Kerberos works can be very difficult to keep straight. There is a lot of decrypting and encrypting of authentication data. I have laid out the entire ticketing process here in two formats. If you are just trying to understand at a high level of how Kerberos authentication works I would suggest that you keep to the number lists below. If you already know the high level Kerberos ticketing process and are looking for more detail on how Kerberos authentication works I would suggest that you look at the bulleted list under each numbered list below.

    clip_image002

    Image is taken from the Kerberos TechNet article

    1. The client sends a KRB_AS_REQ to the KDC and more specifically the Authentication Server to request a Ticket Granting Ticket (TGT).

    • The AS_REQ is built on the client machine using the current computer time and encrypting it with the users Password hash. There is some other information within the AS_REQ packet that includes the UPN of the Principal. This information is called “Authentication Data”

    2. Once the KDC verifies the users Authentication Data, it responds back to the client with a KRB_AS_REP to the client with a TGT and session key for the TGT.

    • The KDC can decrypt the AS_REQ because the principal’s password hash is stored within Active Directory; it then verifies that the timestamp in the AS_REQ to make sure that the systems are within 5 minutes of time skew. This process validates that the principal authenticating knows the users account and password.
    • The TGT session key is used in subsequent service ticket requests.

    3. The client is then able to request service tickets since it has a valid TGT for the Active Directory domain. The client then sends a KRB_TGS_REQ to the KDC and more specifically the Ticket Granting Server to request a Service Ticket. Keep in mind that it not only sends the Service Ticket Request, but also a copy of the TGT that it was given earlier.

    • The principal is going to build an authenticator that is encrypted with the Session key of the TGT. This authenticator data is the User Principal Name, as well as the current system timestamp. The TGS_REQ has the following information: The Service Principal name that they want access to, and the TGT from the previous step.

    4. Once the KDC has verified the validity of the TGT that is included with the Service Ticket request it responds back to the client with a KRB_TGS_REP with the Service Ticket and service session key.

    • After successful decryption of the TGT, the Ticket Granting Server has access to the TGS Session key that the authenticator data is encrypted with. Decrypting the Authenticator data helps to prove the user principal who was issued the TGT is who sent the Service Ticket Request. Also with decrypting the Authenticator data, the KDC is able to verify that system time is within 5 minutes of time skew and is not a replay attack.
    • An LDAP query is done for the Service Principal Name (SPN) that the ticket is being requested for from the Ticket Information. The LDAP Search is doing a query on the servicePrincipalName attribute and is done against a domain partition.
    • The TGS generates a Unique Service Session Key. This session key is going to be used by the principal and service.
    • The KDC then creates the service ticket with the following information within it:
      • A copy of the unique session key
      • v Authorization data that is copied from the principals TGT that was given in the request. The Authorization data is going to have the Principals SID, all group information, again this information is known as the Privileged Attribute Certificate or PAC.
      • Once the service ticket information is compiled the entire service ticket is encrypted with the Services User Key (password hash).
      • The ticket information and the principal’s copy of the service session key are encrypted with the Ticket Granting Server session key.

    5. Next the client sends the Service Ticket to the Service/Application as a KRB_AP_REQ. You will typically see this embedded in the type of packet that the service uses. Like file shares use SMB, for example.

    • The information in the KRB_AP_REQ is the service ticket obtained from the TGS, and an authenticator encrypted with the session key for the service.

    6. After authentication succeeds The Service responds back to the client with a KRB_AP_REP.

    • When the client receives KRB_AP_REP, it decrypts the service’s authenticator with the service session key it shares with the service and compares the time returned by the service with the time in the client's original authenticator. If the times match, the client knows that the service is genuine.
    • After the server authenticates the client using Kerberos authentication, the Privilege Attribute Certificate or PAC is taken from the service ticket and used to create the user's access token. This PAC is verified against a domain controller through a NetLogon call to verify the PAC Signature.

    As you can see, the KDC does not participate directly in the authentication of users to the end service with Kerberos. The KDC is known as the trusted 3rd party in this type of authentication. It is known this way because it is the only service that knows the passwords of the user and the service.

    Kerberos Delegation:

    Kerberos delegation is the act of principal (Service) impersonating another principal (user) to gain access to a 3rd principal (service). In other words, User connecting to an IIS Server that queries a SQL Server as the user who is requesting some data from the web server.

    There are two different types of delegation.

    • Unconstrained (Windows 2000/2003/2008 Servers can do this type of delegation.)
    • Constrained (Windows 2003/2008 Servers in 2003 Domain Functional Level (or higher) can do this type of delegation.)

    We are going to cover Kerberos Delegation in detail in another blog entry.

    Tools used to view and troubleshoot Kerberos:

    KerbTray: This is a great utility GUI based utility that shows up in the system tray that allows you to view all your Kerberos tickets as well as being able to purge them. The purge feature is done by right clicking the green ticket in the system tray and selecting “Purge Tickets”. The Purge Tickets options delete all Kerberos tickets.

    http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&DisplayLang=en

    KList: This is a great command line tool that lists Kerberos tickets as well as being able to purge Kerberos tickets. The nice thing about this tool is that you can selectively purge Kerberos tickets rather than deleting all tickets like the KerbTray utility does.

    http://www.microsoft.com/downloads/details.aspx?FamilyID=1581e6e7-7e64-4a2d-8aba-73e909d2a7dc&DisplayLang=en

    Network Captures: Network capturing utilities can be indispensable when troubleshooting a Kerberos authentication issue. As we say here “the truth is on the wire”. Most network capture utilities have very good Kerberos parsers included. Some of our favorites here are Network Monitor 3, WireShark, and Ethereal.

    Kerberos Event logging: The operating system by default does not create event log entries for Kerberos authentication events. You can however turn this feature by reviewing the following KB article:

    262177 How to enable Kerberos event logging - http://support.microsoft.com/default.aspx?scid=kb;EN-US;262177

    You would enable this feature on the client machines and any other machines participating in Kerberos delegation.

    Note: I would caution you on enabling this feature. There are some events that you will see that are really not Kerberos errors – such as 0x12 KDC_ERR_CLIENT_REVOKED, 0xD KDC_ERR_BADOPTION, or 0x34 KRB_ERR_RESPONSE_TOO_BIG. We have had cases where the customer enabled this from a previous case and never turned it back off. Since they were now sensitive to all Kerberos errors they have opened up a new case just to be asked to turn off the logging because the events were not really errors.

    Kerberos Dependencies:

    There are some basic dependencies that need to be in place for Kerberos Authentication to succeed.

    For Kerberos to function correctly, the supporting infrastructure must be sound. Since Passwords are used to encrypt data within Tickets it is imperative that when a user or computer changes their password that Active Directory replication is able to send these changes throughout the environment.

    Proper name resolution is required. For Kerberos to function it has to be able to resolve the proper IP Addresses for the KDC as well as the Service Principal you are attempting to access. Both DNS and NetBIOS name resolution must be setup correctly. Many cases identified as Kerberos issues were caused by bad records in DNS, broken WINS replication, or HOSTS/LMHOSTS files with invalid data. DNS SRV records for _kerberos will need to be in place, for both the _tcp and _udp DNS sub-domains. Check the configured DNS suffixes and search order as well. A typical problem that we find is that the DNS Zone has been configured for WINS Lookup. When this happens the wrong DNS FQDN is found for the service the user is attempting to connect to, which then causes the application to ask for a service principal for the wrong FQDN.

    All machines participating in Kerberos authentication need to be within 5 minutes of time. By default Windows will use the Windows Time (w32time) service, but can use a third party NTP client. We don’t care what time it is as long as all computers in the forest agree to within 5 minutes of one another.

    We need to ensure that we have good connectivity. TCP and UDP port 88 must be open from clients to domain controllers. A common problem is that routers will arbitrarily fragment UDP packets; when this happens the Kerberos ticket request packets are discarded by the KDC. Windows Vista and Windows Server 2008 now default to using TCP for kerberos ticket requests. Typically you work around this issue by implementing the following KB article:

    244474 How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;244474

    LDAP queries will be made by the DC / KDC for Service Principal Name records. Duplicate computer names, usernames, etc, or manually registered duplicate SPN's anywhere in the forest can cause Kerberos errors. There is an event that is created when this happens, but it is only logged on the domain controller that attempted to find the service principal. It is a Kerberos Event 7.

    Other Kerberos information:

    How the Kerberos Version 5 Authentication Protocol Works http://technet2.microsoft.com/WindowsServer/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx

    Kerberos Authentication in Windows Server 2003 http://technet2.microsoft.com/windowsserver/en/technologies/featured/kerberos/default.mspx

    MIT’s references for Kerberos

    http://web.mit.edu/kerberos/

    The Kerberos Consortium

    http://www.kerberos.org

    Kerberos RFC

    http://www.ietf.org/rfc/rfc1510.txt
    http://www.ietf.org/rfc/rfc4120.txt

    - Rob Greene

  • Managing Power with Group Policy: Part 3 of 3

    Mike here. It’s time we wrap up our discussion on managing power using Group Policy. The previous blog posts discussed managing power on Windows Vista (and Windows Server 2008). Today, I’ll cover how we can achieve the equivalent for Windows XP.

    The key to managing power on Windows XP is Group Policy preferences. The Group Policy Management Console (GPMC) included with Windows Server 2008 and (soon to be released) Remote Server Administration Tools contains the management portion of portion of preferences. Next, you need preference client side extensions that allow Windows XP to process Group Policy objects that contain preference configuration data. Group Policy preferences client side extensions are available from Microsoft for Windows Vista, Windows Server 2003, and Windows XP.

    Preferences provide two preference items you can use to configure power on Windows XP (or Windows Server 2003 and Windows Server 2003 R2). The first of these items is the Power Option item. Figure 1 shows you the properties on a Power Option preference item. This is one of the great features with preferences—the configuration screen closely resembles the screen you actually use on the operating system.

    clip_image002

    Figure 1- Power Option preference item

    The Power Option preference item gives you the ability to configure hibernation, prompting for password when the computer resumes. Also, you can configure the Power button action when you close the lid of the computer (laptop), press the power button, or press the sleep button.

    One of the cool things about preferences is you have control over which settings you want to configure and ones that you do not. Figure 1 shows each setting in the preference item underlined with a single green line. This means the setting in the item is enabled and the setting applies as configured. Using Figure 1 as an example, the Always show icon on the taskbar is enabled but, the checkbox is not selected. During Group Policy processing, this preference item configures Always show icon on the taskbar, Prompt for password when computer resumes from standby, and Enable Hibernate as off. This result is because the setting in the item was enabled (green underline) and the checkbox is cleared (off). This is a very powerful feature because it allows you full control over the setting you want to configure and the setting that you do not. Let’s look at another example.

    clip_image004

    Figure 2- Disabled setting in a preference item

    Figure 2 shows another configured Power Options preference item. In this example, Always show icon on the taskbar has a red dashed underline, which means the setting is disabled. This means when Group Policy applies this preference item, Prompt for password when computer resumes from standby and Enable hibernation are enabled and, Always show icon on the taskbar is ignored. You enable and disable a setting by using the function keys on the keyboard.

    • F5 enables all the settings in a preference item
    • F6 enables the currently selected setting in a preference item
    • F7 disables the currently selected setting in a preference item
    • F8 disables all the setting in a preference item

    clip_image006 Note

    Preference items are not policy settings, which means they are not enforced—just applied. Users with the proper privileges may have the ability to change the preference setting to another selection. However, preference item settings return on the next Group Policy refresh, unless configured otherwise.

    The other power preference item is Power Scheme. The Power Scheme preference item allows you to create, modify, and delete power schemes. This allows you to configure a Windows XP computer to use one of the pre-existing power schemes or modify the settings included in one of the pre-existing power schemes or, just you create your own—it is your choice. Each power scheme has settings for two options: Plugged in or Running on batteries. From there, you define the time out settings for turning off monitors, hard disks, system standby and system hibernate. The Power Scheme preference item has the same enable/disable feature as the Power Option preference item and behaves in the same fashion.

    The one difference with the Power Schemes preference item is the Action field. The action field determines the action Group Policy processing applies to the specific preference item. Configuring a Power Scheme preference item to Create; does just that—it creates a new power scheme. However, if, on the computer applying the preference item, a power scheme with the same name exists, the preference item does nothing. Delete and Update do just what they describe—delete and update. However, Update does provide additional functionality other than updating an existing power scheme with new settings. If you configure your Power Scheme preference item to update a power scheme that does not exist on the applying computer, then a new power scheme is created with that name. Lastly, configuring the preference item with Replace has similar results to using Update. When using Update, the Power Scheme preference item only updates the enabled settings within the preference item on the existing named power scheme—leaving all other settings as they are. Replace, however; actually deletes the named power scheme from the computer and then creates a new power scheme based on the settings configured in the Power Scheme preference item.

    Other things to remember with power management preference items:

    • You can configure power management preference items in both computer and user configurations. Understand, user configuration apply after computer configuration. This results in the user settings replacing the current power settings, which could have been from another preference item.
    • Local Administrators are Administrators. This means they can change their power configuration. Standard users cannot.
    • When Group Policy applies power management preference items; those items become the current power management scheme—even after the user logs off.
    • Power management preferences item support background refresh—your settings can change.

    That wraps up Managing Power with Group Policy. Three blog entries, six categories, 34 policy settings, and two preference items later, it should be easy to see how combining these Group Policy features could save your company significant resources. It may be a good time to review how you could implement some of these features and savings you may gain.

    Managing Power with Group Policy: Part 1 of 3
    Managing Power with Group Policy: Part 2 of 3
    Managing Power with Group Policy: Part 3 of 3

    -Mike Stephens

  • Troubleshooting LDAP Over SSL

    Hi, James here - I am a Support Escalation Engineer in Charlotte, NC, USA. Today I would like to talk to you about troubleshooting LDAP over SSL connectivity issues. We will be covering LDAP over SSL basics, how Subject Alternate Name’s (SAN) work, configuring Active Directory Application Mode (ADAM) for LDAP over SSL, and of course simple troubleshooting steps.

    LDAP OVER SSL BASICS

    In order to enable LDAP over SSL, the following server and client requirements must be met:

    SERVER REQUIREMENTS

    The server must have a certificate stored in the local machine store that meets the following criteria:

    • Certificate Contains the Server Authentication OID: 1.3.6.1.5.5.7.3.1
    • The Subject name or the first name in the SAN must match the FQDN of the host machine.
    • The Certificate passes the chaining validation test.
    • The host machine account has access to the private key
    • Note: Typically ADAM runs under a domain account as opposed to the Local System account. In this scenario the domain account must have access to the private key. This will be covered later in the blog.

    For an easy way to validate whether or not the machine has a valid certificate, we can run the following command:

    Certutil –VerifyStore MY

    The output will look similar to the following:

    ================ Certificate 0 ================
    Serial Number: 4678576700000000000e
    Issuer: CN=Contoso Issuing CA, DC=Contoso, DC=Com
    Subject: CN=ServerName.Contoso.com
    Certificate Template Name: Machine
    Non-root Certificate
    Template: Machine, Computer
    Cert Hash(sha1): d9 14 d3 cc 54 e7 02 3e a3 99 e6 31 0c 46 3d 03 81 c0 a7 cf
      Key Container = e08a8f744d85c46b5494c876e5a9c7c2_17012b00-a428-4a32-bb81-3d15f8bc3c10
      Provider = Microsoft RSA SChannel Cryptographic Provider
    Private key is NOT exportable
    Encryption test passed
    Verified Issuance Policies: None
    Verified Application Policies:
        1.3.6.1.5.5.7.3.2 Client Authentication
        1.3.6.1.5.5.7.3.1 Server Authentication
    Certificate is valid

    Note: We can of course have multiple certificates in our certificate store.   So the value “================ Certificate 0 ================” refers to the first certificate in the store as the index values are zero based.

    We can break down the output as follows:

    Subject, i.e. the name that we specify for our LDAP over SSL Connection:

    Subject: ServerName.Contoso.com

    The following section lets us know that we have a valid private key:

    Private key is NOT exportable
    Encryption test passed

    The following verifies the intended purpose of the certificate which is Server Authentication:

    Verified Application Policies:
        1.3.6.1.5.5.7.3.1 Server Authentication

    The last section, verifies that the certificate is indeed valid.  I.e. the certificate chains to a trusted issuer, is within the validity time period, and have not been revoked.

    Certificate is valid

    Now we can of course run into issues at it relates to certificate validation. These will fall primarily into one of two categories, issues with the private key and issues with certificate chaining. We will cover the private key first.

    Private Key

    A typical error message would be:

    No Key Provider Information or Missing Stored Keyset

    This problem is due to a missing private key. We can confirm this by looking for the following in the Certutil output:

    Cert Hash(sha1): a5 79 2f 21 82 99 4d f2 31 83 00 81 2c 84 85 3c 20 b7 5e 08
    No key provider information
    Missing stored keyset

    The normal cause of this problem is that the certificate request was generated on one machine and we have installed the certificate on a different machine. 

    When we generate a certificate request, the client generates a private key and signs the request with it.   When we receive the certificate from the CA, we can verify that the certificate is based on the request that was generated by the client. 

    So the first step in resolving the issue is verifying which machine the certificate request was generated on.   We can then go to that machine and run the following command to associate the certificate with private key container:

    C:\>Certutil -RepairStore MY 0
    ================ Certificate 0 ================
    Serial Number: 334205f9000000000022
    Subject:
        CN=MachineName.Contoso.com
    Non-root Certificate
    Cert Hash(sha1): a5 79 2f 21 82 99 4d f2 31 83 00 81 2c 84 85 3c 20 b7 5e 08
      Key Container = 574d09d6-9ea4-4a64-9a2a-dc1dfabd97c9
      Provider = Microsoft Enhanced Cryptographic Provider v1.0
    Private key is exportable
    Signature test passed
    CertUtil: -repairstore command completed successfully.

    We have now associated the certificate with the private key. If this command fails then it means that the private key was not located in the machine store. If we can’t locate the private key container then we will need to request a new certificate. Also, if the private key is marked as exportable we can export the certificate to the appropriate machine. If not we need a new certificate.

    Certificate Validation Errors

    Certificate validation is the process of verifying that the information contained in the certificate is authentic and that the certificate can only be used for its intended purpose and that the certificate is trusted.

    If we have a validation issue we will see one of the following errors at the very bottom of the Certutil output:

    Example 1:
    A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. 0x800b0101 (-2146762495)
    ------------------------------------
    Expired certificate

    Example 2
    The certificate is revoked. 0x80092010 (-2146885616)
    ------------------------------------
    Certificate is REVOKED
    Leaf certificate is REVOKED (Reason=6)

    Example 3

    A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. 0x800b0109 (-2146762487)
    ------------------------------------
    Verifies against UNTRUSTED root

    Example 4
    An internal certificate chaining error has occurred. 0x800b010a (-2146762486)
    ------------------------------------
    419.3000.0: 0x800b010a (-2146762486)
    Incomplete certificate chain
    Cannot find certificate:
        CN= Contoso Issuing CA, DC=Contoso, DC=Com

    Example 5
    The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614)
    ------------------------------------
    Revocation check skipped -- no revocation information available
    Certificate is valid

    Example 1, “Expired certificate”, simply means that the certificate is beyond its validity period. Now it’s possible that the system clock has been changed to an invalid date. Changing it to the correct current time will resolve the issue. However, if this is not the case then we will need to get a new certificate.

    PLEASE NOTE: You cannot renew a certificate once it has expired.

    Example 2 “Certificate is REVOKED”, means that the certificate has been revoked and therefore a new certificate needs to be issued.

    For examples 3 & 4 i.e. the “UNTRUSTED root” and “Revocation” errors, troubleshooting is a little more involved. The “UNTRUSTED root” error means that one of the certificates in the chain is missing from the “Intermediate Certification Authorities” container for Intermediate certificates or from the “Trusted Root Certification Authorities” for root certificates. The “Revocation” error means that either the CRL is not cached locally on the client and/or we are unable to download the CRL from one of the publication points.

    Fortunately, troubleshooting these errors is straightforward. First we need to dump the certificate to a file. The syntax is as follows:

    CertUtil -store CertificateStoreName CertId OutputFile

    PLEASE NOTE: For our purposes, valid certificate stores are “My”, “Trusted Root Certification Authorities”, and “Intermediate Certification Authorities”. For more information, please see the following:

    Certificate stores

    http://technet2.microsoft.com/windowsserver/en/library/1c4d3c02-e996-450a-bf4f-9a12d245a7eb1033.mspx?mfr=true

    Example:

    Certutil -store My 0 ProbCert.cer

    The next step would be to verify whether or not the certificate can access the Authority Information Access (AIA) and the Certificate Distribution Point (CDP). If we can get to at least one of the paths for each certificate in the chain, the validation test will pass. The output will look similar to the following:

    Verified Issuance Policies: None
    Verified Application Policies:
        1.3.6.1.5.5.7.3.2 Client Authentication
        1.3.6.1.5.5.7.3.1 Server Authentication
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.

    If we are unable to access one of the paths, we will need to perform additional analysis of the output. In reading the output, we start at the top. Next we perform a search on the following text “CertContext”. The line will look similar to the following:

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0

    In this section we will see the “Subject” of the certificate i.e. the end entity that the certificate was issued to:

    Subject: CN=ComputerName.Contoso.com

    We will also see the Issuer of the certificate:

    Issuer: CN=Contoso Issuing CA, DC=Contoso, DC=com

    Our next step is to locate the following section:

    ----------------  Certificate AIA  ----------------

    This section lets us know where the Issuer’s certificate is located and whether or not the client can access it. Please note that this section can contain multiple paths. The key however is that we only need to be able to access one of the paths. So in our test, the following output is fine:

    ----------------  Certificate AIA  ----------------
    Verified "Certificate (0)" Time: 0
      [0.0] ldap:///CN=Contoso%20Issuing%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=Com?cACertificate?base?objectClass=certificationAuthority

    Failed "AIA" Time: 0
      Error retrieving URL: Error Error response received from gateway 0x800701f6 (WIN32/HTTP: 502)
    http://ContosoIssuingCA.Contoso.com/CertEnroll/
    CONTOSOISSUINGCA.Contoso.com_Contoso%20Issuing%20CA.crt

    As we can see, we are able to access the LDAP path to the AIA. However, we are unable to access the HTTP path. Again, since we can access one of the paths, the validation check passes. If we cannot get to either of the paths, then this will have to be resolved. In this case the proxy is blocking access to the HTTP paths.

    Our next step is to perform a search for the following section:

    ----------------  Certificate CDP  ----------------

    The CDP path is the publication path to the certificate revocation list (CRL). The application performing the validation test checks to see whether or not the certificate has been revoked. Again, if we can access any of the paths, the validation test passes. So again in our test we can get to the LDAP paths so the validation test passes.

    ----------------  Certificate CDP  ----------------
    Verified "Base CRL (64)" Time: 0
        [0.0] ldap:///CN=Contoso%20Issuing%20CA,CN=CONTOSOISSUINGCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=Com?certificateRevocationList?base?objectClass=cRLDistributionPoint

      Verified "Delta CRL (64)" Time: 0
        [0.0.0] ldap:///CN=Contoso%20Issuing%20CA,CN=CONTOSOISSUINGCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=Com?deltaRevocationList?base?objectClass=cRLDistributionPoint

      Failed "CDP" Time: 0
        Error retrieving URL: Error Error response received from gateway 0x800701f6 (WIN32/HTTP: 502)
        [0.1.0] http://ContosoIssuingCA.Contoso.Com/CertEnroll/Contoso%20Issuing%20CA+.crl

      Failed "CDP" Time: 0
        Error retrieving URL: Error Error response received from gateway 0x800701f6 (WIN32/HTTP: 502)
    http://ContosoIssuingCA.Contoso.Com/CertEnroll/Contoso%20Issuing%20CA.crl

    The next section we need to look for is:

    ----------------  Base CRL CDP  ----------------

    This section is for Delta CRLs which may or may not be available depending whether or not Delta CRLs are published. The paths are as follows:

    ----------------  Base CRL CDP  ----------------
      OK "Delta CRL (65)" Time: 0
        [0.0] ldap:///CN=Contoso%20Issuing%20CA,CN=CONTOSOISSUINGCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=Com?deltaRevocationList?base?objectClass=cRLDistributionPoint

      Failed "CDP" Time: 0
        Error retrieving URL: Error Error response received from gateway 0x800701f6 (WIN32/HTTP: 502)
    http://ContosoIssuingCA.Contoso.com/CertEnroll/Contoso%20Issuing%20CA+.crl

      --------------------------------
        CRL 64:

    Again we can get to the LDAP path but not the HTTP path. So, once again our validation test will pass.

    This completes the validation test for this level of the certificate chain. If the issuer of the certificate is a Root Certificate then this completes the validation process. However, if this is a subordinate certificate, then we will go to the next level of the validation test. The section will look similar to the following:

    CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=Contoso Policy CA, DC=Contoso, DC=Com
      Subject: CN=Contoso Issuing CA, DC=Contoso, DC=Com

    So our subject at this level is the issuer from the previous level. Again, we perform the validation test and we need to verify that we can access at least one path in the AIA section and one path in the CDP section.

    Assuming that we have a three tier CA configuration, we finally get to the root.

    Note: We know that we have reached the root because we have a self-signed certificate i.e. the subject name matches the issuer name.

    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=Contoso Root CA, DC=Contoso, DC=Com
      Subject: CN=Contoso Root CA, DC=Contoso, DC=Com
      Serial: 341f8fdd3ffce6934ee3900117eaee4e
      08 85 f3 de 95 3e ac d8 78 f7 3f a8 06 0a 0f 59 bf 39 5a f6
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      Verified "Base CRL (19)" Time: 0
        [0.0] ldap:///CN=Contoso%20Root%20CA,CN=R2DOMDC1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=Com?certificateRevocationList?base?objectClass=cRLDistributionPoint

      Failed "CDP" Time: 0
        Error retrieving URL: Error Error response received from gateway 0x800701f6 (WIN32/HTTP: 502)
    http://r2domdc1.Contoso.com/CertEnroll/Contoso%20Root%20CA.crl

    A Windows Server 2003 Root CA does not chain the root since it’s the final authority. However, by default we include the AIA and CDP paths. Therefore, for the Root CA this can be ignored even if we have errors.

    Note: We can prevent the paths from appearing in the root by configuring a CAPolicy.inf file prior to issuing or renewing the root certificate. For more information, please see the following:

    CAPolicy.inf Syntax

    http://technet2.microsoft.com/windowsserver/en/library/25127c1f-4880-4764-85e8-226ce41588881033.mspx?mfr=true

    So at this point we have validated the entire certificate chain. If we have errors we need to resolve them. Most of the errors will be one of the following:

    1. CA Cert or CRL file is missing from the publication location.
    2. We are unable to access the publication location due to permissions. We will most likely see an access denied error. We need to check both user and machine account permissions.
    3. We are unable to access the AIA or CRL due to proxy settings. Again, we need to check both user and machine proxy settings.

    After fixing the errors, we need to re-run the Certutil –Verify command. If no errors are reported at the bottom of the output, then the certificate is valid.

    ADAM Special Case

    Validating the server certificate for an ADAM instance is exactly the same with one caveat. As stated earlier in the blog, typically ADAM runs under a domain account. The preferred method is to add the certificate to the service account store and NOT the computer store. The only time the certificate should be in the computer store is when ADAM is running under the context of the Network Service account.

    If the service is running under Network Service then we will need to give the account access to the private key container.

    To locate the private key container for a certificate, run the following command:

    Certutil –V –Verifystore MY 0

    Look for the following section in the output:

    CERT_KEY_PROV_INFO_PROP_ID(2):
      Key Container = e08a8f744d85c46b5494c876e5a9c7c2_17012b00-a428-4a32-bb81-3d15f8bc3c10
      Provider = Microsoft RSA SChannel Cryptographic Provider
      ProviderType = c
      Flags = 60
      KeySpec = 1

    This key container value, “e08a8f744d85c46b5494c876e5a9c7c2_17012b00-a428-4a32-bb81-3d15f8bc3c10” is the private key container file. We can find this value under:

    C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

    We need to verify that the ADAM service account has “Read” permissions on the container.

    This concludes the section on validating the server certificate. Next we will look at the client requirements.

    CLIENT REQUIREMENTS

    Unlike the server, the client does not require a client certificate for making the LDAP over SSL connection. However, the client does have to trust the server certificate and has to be able to verify the server’s revocation status. To verify whether or not the client trust the server certificate we need to export the server certificate to the client.

    To export the certificate, run the following command on the server:

    Certutil –Store My 0 ServerCert.cer

    Next we need to copy the ServerCert.cer to the client machine and run the following command:

    Certutil –Verify –Urlfetch ServerCert.cer

    Please note that we will need to validate the output in the same way as we did on the server. Typically we will fail either because the chain doesn’t validate or we can’t access the CRL. The private key will not be relevant.

    Note: Certutil.exe is included in the base OS for Windows Server 2003, Windows Vista, & Windows Server 2008. For Windows XP & Windows 2000 clients, we will need to make a directory and copy the following files from a Windows Server 2003 machine:

    %Windir%\System32\Certutil.exe
    %Windir%\System32\Certadm.dll
    %Windir%\System32\Certcli.dll

    ADDITIONAL CONSIDERATION

    Subject Alternate Name (SAN)

    A Subject Alternative Name (SAN) lets you connect to a domain controller or ADAM instance by using a name other than the computer’s FQDN. The format would be as follows:

    SAN="dns=MemberServer.Contoso.com&dns=ldap.contoso.com"

    There is one caveat. The first name in the SAN has to match the FQDN of the server. The second name doesn’t matter.

    LDAP over SSL Ports

    By default all LDAP over SSL connections to a domain controller go over port 636. This is hardcoded and cannot be changed.

    However, for ADAM we specify the port during installation. To verify which port the ADAM instance is using, we can run the following commands:

    C:\WINDOWS\ADAM>Dsdbutil
    Dsdbutil: list instances

    Instance Name:         PKI
    Long Name:             PKI
    LDAP Port:             389
    SSL Port:              636
    Install folder:        C:\WINDOWS\
    Database file:         C:\Program Files\Microsoft ADAM\PKI\data\adamntds.dit
    Log folder:            C:\Program Files\Microsoft ADAM\PKI\data
    Service state:         Running

    To change the ports, we can modify the following registry keys:

    Final Thoughts

    • Once all errors in the validation process have been resolved on both the client and the server, we should be able to make our LDAP over SSL connections.
    • To test the connection we recommend using LDP.exe which is part of the Windows Support Tools. First try to make a connection on the server itself. If this fails, then verify the server certificate requirements using the earlier documented steps.
    • If this succeeds then we know that the server is configured properly. We can then try running LDP on the client to see if we can make the connection. Again, if it fails, then go through the client certificate requirements.
    • At this point, if we still can’t connect, then most likely the problem is not in the certificate. The problem may be that port
    • We can get a network trace to verify the SSL handshake

    Using these steps should resolve the majority of the LDAP over SSL connectivity issues.

    ADDITIONAL RESOURCES

    938703 How to troubleshoot LDAP over SSL connection problems

    932834 You may be unable to connect to a Windows Server 2003-based domain controller by using LDAP over an SSL connection

    931351 How to add a Subject Alternative Name to a secure LDAP certificate

    911647 Applications that use Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer (SSL) do not perform revocation checking of the server certificate in Windows Server 2003 with Service Pack 1

    321051 How to enable LDAP over SSL with a third-party certification authority

    Appendix A: Configuring LDAP over SSL Requirements for AD LDS

    - James Carr

  • Remote Server Administration Tools Released for Windows Vista SP1 (Hurray!)

    Ned here - this is a quick post that can't wait for the Microsoft.com machine to spin up. :-)

    The long-awaited Remote Server Administration Tools (RSAT) have been released for Windows Vista. These will allow administrators to use their Vista machines to manage their Windows 2000, Windows Server 2003, and Windows Server 2008 infrastructure from the comforts of the cubicle. Come and get 'em.

    Microsoft Remote Server Administration Tools for Windows Vista for x86-based Systems
    http://www.microsoft.com/downloads/details.aspx?FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960&DisplayLang=en

    Microsoft Remote Server Administration Tools for Windows Vista for x64-based Systems
    http://www.microsoft.com/downloads/details.aspx?FamilyID=d647a60b-63fd-4ac5-9243-bd3c497d2bc5&DisplayLang=en

    After you install this, open Control Panel and start Programs and Features. Click Turn Windows Features on or off then scroll down to the Remote Server Administration Tools. From there you can turn on everything, certain things, or... nothing. Your call, unlike the old ADMINPAK.MSI...

    - Ned Pyle

  • RSAT and ADUC: Getting the Terminal Services Tabs to Appear in AD Users and Computers

    Hi, Ned here again. Recently a customer posted a comment asking why the Remote Server Administration Tools for Windows Vista did not appear to match what tabs you’d see on a Windows Server 2008 computer. Specifically, in Active Directory Users and Computers (DSA.MSC) when you looked at the properties of a user, you do not see:

    • Terminal Services Profile
    • Environment
    • Sessions
    • Remote Control

      clip_image002

    Update June 24, 2009 - We have a hotfix for this now and the workaround steps are no longer necessary:

    960890 Some tabs are not available in the properties of a user account in the Active Directory Users and Computers MMC snap-in after you install Remote Server Administration Tools (RSAT) on a computer that is running Windows Vista
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;960890

    If you have been using the unsupported workaround below, make sure to unregister and remove your server DLL's before installing this update.

    We can offer the following workarounds:

    1. You can use your Windows Server 2008 AD Users and Computers snap-in by terminal serving into the remote administration sessions.
    2. You can make your RSAT DSA.MSC work the way you’d expect by taking the following unsupported steps:

    A. Locate a Win2008 Server which has DSA.MSC installed via Server Manager features/roles. The installed OS platform architecture must match your client (so use 32-bit OS server if using 32-bit OS client, and the same for 64-bit).

    B. Locate the following two files:

    %systemroot%\system32\tsuserex.dll
    %systemroot%\system32\en-us\tsuserex.dll.mui

    (NOTE: If not running US English, the path would not be EN-US; it would be the language(s) running on the server)

    C. Copy these two files to the Vista machine running RSAT tools and place them in the same paths.

    D. Run as an administrator:

    regsvr32.exe tsuserex.dll

    E. Start DSA.MSC on the Vista machine and look at a user's properties - the tabs will now be there.

    clip_image004

    Note that in my screenshots you’ll see some other tabs that are also only exposed through turning on Advanced Features:

    clip_image006

    Thanks to Richard from University of Bath for bringing this to our attention here at AskDS!

    - Ned Pyle

  • One-Stop Shop for Auditing in Windows Server 2008 and Windows Vista

    Hi, Ned here again. I am frequently asked by customers (and Microsoft employees!) where they can get to all the useful Windows Server 2008 and Windows Vista audit information. Unlike some of our other components, there’s no clear portal site on TechNet or MSDN that gives you everything in one fell swoop. Today I’ll attempt to aggregate everything so that you don’t have to sift. If you’re a regular reader of this blog, you may recognize some of these from previous posts; others may be new to you.

    KB947226 - Description of security events in Windows Vista and in Windows Server 2008 -

    To begin, the above KB article lists out all of the audit events, by category, by subcategory, by ID number, and finally by message. This is a good method to see the general organization of the new entries, and can be especially useful for an administrator who is looking to determine what audit events will be useful to track. It also has the honor of being perhaps the longest KB article ever written – no 14.4 modems allowed! :-)

    Security audit events for Microsoft Windows Server 2008 and Microsoft Windows Vista -

    For even more details on the audit events, you can download an Excel spreadsheet that contains all of the information of the KB article and allows for easier sorting and filtering. It also has (on the tab ‘Complete Event Messages’) the detailed message data so you know more about what will be returned when the event is triggered.

    clip_image002

    Figure 1

    clip_image004

    Figure 2

    clip_image006

    Figure 3

    clip_image008

    Figure 4

    Note: If you don't have Excel, you can also use the free Excel Viewer.

    KB921469 - How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain -

    The above KB explains how to deploy subcategory-based auditing to all your up-level machines. While the article specifically states Vista, it is totally applicable to Win2008 machines as well.

    KB947223 - Description of the Special Groups feature in Windows Vista and in Windows Server 2008 -

    I recently blogged about Special Groups auditing and how it can be useful for specialty servers; the official KB is included here for the sake of completeness.

    Windows Server 2008 Security Guide (Online) & Windows Server 2008 Security Guide (Downloadable) -
    Windows Vista Security Guide (Online) & Windows Vista Security Guide (Downloadable) -

    The four links above are to the Solution Accelerator series covering security within Vista and 2008. These are about far more than just auditing – they go into an overall process of making sure your attack surface is reduced across the board. They include information, recommendations, and scripts for a variety of security topics, including auditing.

    Windows Server 2008 Auditing AD DS Changes Step-by-Step Guide -

    Because it is so heavily changed from previous operating systems, the Directory Services auditing category was called out for special attention in a TechNet article. It covers the four new subcategories in detail:

    • Directory Service Access
    • Directory Service Changes
    • Directory Service Replication
    • Detailed Directory Service Replication

    It goes through examples, setup, as well as the Attribute Syntax limitations where you can control the lengths of strings being audited for performance versus completeness.

    AUDITPOL.EXE Reference

    Auditpol.exe is a command-line tool included in Vista and 2008 for controlling auditing, especially around the new subcategories. Understanding of this tool is pretty much a requirement for making auditing work in an efficient manner. This article covers all the syntax as well as provides plenty of useful examples.

    Windows Audit Team Blog (search pulling back Vista references)

    I’ve said it before and I’ll say it again – if you want an authoritative answer to a Windows auditing question, this is the place to go. The link above is actually a search URL that returns everything Vista-related, but the overall site deserves immediate bookmarking in your blog viewer of choice.

    Windows Server 2008 Security Resource Kit

    Finally, if you’re not opposed to dropping a little cash, the Security Resource Kit is now available for Windows Server 2008 through all major booksellers. Chapter eight is 30 pages of audit goodness written by the guy that ran the whole show, Eric Fitzgerald.

    As we add more public information I’ll come back and update this post, so feel free to bookmark in your favorite browser and feed reader. If you look through all this and find that there’s something missing, please let me know and I’ll track it down.

    - Ned Pyle