Blog - Title

March, 2008

  • 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

  • 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

  • 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

  • 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

  • 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

  • Update Released to Disable Scalable Network Pack

    Ned here. The Microsoft Enterprise Network Team blog has posted information about a new update released for Windows Server 2003:

    New update available for Windows Server 2003 SP2 systems to disable Scalable Networking Pack features

    It is highly recommended that you deploy this hotfix if you are having any of the following issues:

    • When you try to connect to the server by using a VPN connection, you receive the following error message:
      Error 800: Unable to establish connection.
    • You cannot create a Remote Desktop Protocol (RDP) connection to the server.
    • You cannot connect to shares on the server from a computer on the local area network. 
    • You cannot join a client computer to the domain.
    • You cannot connect to the Exchange server from a computer that is running Microsoft Outlook.
    • Inactive Outlook connections to the Exchange server may not be cleaned up.
    • You experience slow network performance. 
    • You may experience slow network performance when you communicate with a Windows Vista-based computer.
    • You cannot create an outgoing FTP connection from the server.
    • The Dynamic Host Configuration Protocol (DHCP) server service crashes.
    • You experience slow performance when you log on to the domain.
    • Network Address Translation (NAT) clients that are located behind Windows Small Business Server 2003 or Internet Security and Acceleration (ISA) Server experience intermittent connection failures. 
    • You experience intermittent RPC communications failures.
    • The server stops responding.
    • The server runs low on nonpaged pool memory

    This hotfix only modifies the registry and does not alter any drivers or other system files. ALternatively, you can follow the workaround steps in the article to update your third party network drivers or make the registry changes by hand. The Scalable Network Pack features are not enabled by default in Windows Vista or Windows Serevr 2008.

    - Ned Pyle

  • 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