Blog - Title

March, 2008

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

    Ned here - this is a quick post that can't wait for the 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

    Microsoft Remote Server Administration Tools for Windows Vista for x64-based Systems

    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

  • 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:

    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/
    • 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/

    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 domain wanted access to a file server in the user would have a TGT for, and

    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.


    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.

    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.

    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 -;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 -;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

    Kerberos Authentication in Windows Server 2003

    MIT’s references for Kerberos

    The Kerberos Consortium

    Kerberos RFC

    - Rob Greene

  • 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.


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


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

    • Certificate Contains the Server Authentication OID:
    • 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
    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: Client Authentication 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:


    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: 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
    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


    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: Client Authentication 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:


    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)

    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)

    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)

        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)

    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

    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:

      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.


    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:



    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:


    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:

    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.


    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

  • 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.


    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.


    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

  • 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.


    Figure 1


    Figure 2


    Figure 3


    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

  • 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


    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;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:


    (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.


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


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

    - Ned Pyle

  • New KB Articles February 23-29

    Here are the new Directory Services-related KB articles for the week.

    I came across something this week that reminded me of the improvements that were made to SMB signing in Vista/2008. The SMB protocol is used for network file transfer in Windows, and there are policy settings to control if SMB communications are digitally signed. But prior to this fix, depending on the setting on the client and server, it could result in no communication at all. But now since that fix is available as a hotfix for XP/2003 (KB 916846), and is included in 2003 SP2, XP SP3, Vista, and 2008, communication failures caused by SMB signing mismatches should soon be a thing of the past.

    KB Title


    Error message when you run a script that is encoded by using Script Encoder (Screnc.exe) in Windows Server 2003 or in Windows XP


    When you try to access a local resource over a VPN connection, you are always prompted for authentication in Windows Vista


    Information about programs that are known to experience a loss of functionality when they run on a Windows Vista Service Pack 1-based computer


    Windows Vista may disconnect client communications that use TCP port 1723


    You receive an error message when you try to upgrade the WSv preview build installed on Windows Server 2008 RC0 or on Windows Server 2008 RC1 to the Windows Server 2008 RC1 build with Hyper-V beta or to the release version of Windows Server 2008


    Error message when you try to log on to a Windows Server 2008-based RODC: "There are currently no logon servers available to service the logon request"


    Active Directory objects may not be replicated from the restored server after an authoritative restore on a Windows Server 2003-based domain controller


    The "netsh firewall add portopening," "netsh firewall set portopening," and "netsh firewall set service" commands do not work on a computer that is running certain editions of Windows Vista


    You may not have automatic access to BitLocker-encrypted non-operating-system volumes after you roll back Windows Vista Service Pack 1 to the release version of Windows Vista


    Intrusion detection software (IDS) may issue a warning of a replay attack when you try to use a nonexistent domain user account to log on to a domain from a Windows-based client computer


    Changes to remote administration in Windows Server 2008


    In Windows Server 2008 and in Windows Vista, the "Do not search files" user policy setting does not work as expected


    After you create Active Directory Domain Services (AD DS) in Windows Server 2008, you notice that the credential roaming schema differs from Windows Server 2003


    When you use a WMI script to query the Win32_PerfFormattedData_NTDS_NTDS class on a Windows Server 2003-based domain controller, the script returns a 0x80041010 error


    Windows Vista-specific folder redirection policies are removed from a GPO when you connect to an AGPM server component that is installed on a Windows Server 2003-based member server


    How to use the Backup program to prestage data before DSFR synchronization in Windows Server 2003 R2


    The Repadmin.exe tool does not report existing lingering objects in Windows Server 2003


    After you apply a GPO to redirect a folder to a network share on Windows XP-based or on Windows Server 2003-based client computers, the redirected folder is empty

    - Craig Landis

  • Special Groups Auditing via Group Policy Preferences

    Ned here again. Today I’m going to talk about a new feature of Windows Server 2008 and Windows Vista called Special Groups auditing. While we’re in here, I’ll run through how we can use the new Group Policy Preferences (GPP) client-side extensions to make deploying this fast and easy. We’ll also see some of the new information available about auditing in general. Let’s get started.

    What are Special Groups?

    Special Groups (SG) are a way for administrators to know when certain security groups are added to a user’s token at logon. This way if you need to keep track of highly privileged accounts that are accessing resources, you have an easy event to correlate in your Security event logs. Why would we want to do this? Well, let’s say we have a file server dedicated to the Human Resources department. You also have a set of users that do server-related maintenance work, called “Datacenter Operators”. Your HR department wants to have an audit trail of any ‘super’ users that log on to their server. You have all your audit events being collected automagically to a central SQL server using something like Audit Collection Services in System Center Operations Manager 2007. If we create a new registry value and populate it with the list of Security Identifiers (SID’s) that match our important groups, we now get a special kind of security audit event that’s very easy to track.

    To make this work, we need two things in place:

    1. The Special Logon subcategory of the main audit category Logon/Logoff must be enabled.
    2. The registry must be populated with

    SpecialGroups=<REG_SZ semicolon-separated SID value list>

    Step 1 is done for you out of the box – by default, Special Logon is enabled for success in Windows Server 2008 and Windows Vista. If you need to enable it for some reason, you can use AUDITPOL /SET or follow KB921469 to deploy it through group policy. Here’s what it looks like in AUDITPOL:


    Step 2 is a bit trickier though. We will need to get the SID’s for groups that we want to track, then somehow apply them to computers; maybe thousands of computers. In the past we’d probably go the custom ADM route – but Group Policy Preferences make this soooo much easier – let’s segue for a moment.

    Group Policy Preferences

    Group Policy Preferences are a new piece in Windows Server 2008 to customize machine settings in ways not covered by the canned group policies. You can modify the registry, copy files, create mapped drives, add printers, change local user passwords, and much more. If you still need a logon script or a custom ADM after you start using GPP, you’re probably doing it wrong. :-)

    Mike Stephens has already posted some useful info on GPP earlier. He also called out the GPP whitepaper that you will definitely want to read if you want to understand the power of this new product. What you may not already know is that you can now download the GPP client-side extensions for Windows XP, Windows Server 2003, and Windows Vista. You currently need a Windows Server 2008 computer in order to have the right Group Policy Management Console (GPMC) snap-in to create preferences, but never fear – we should be releasing the Remote Server Administration Tools pack for Vista SP1 by the end of March.

    Doing the needful

    So enough theory – let’s make some electrons move. Here is a step-by-step scenario where we configure Special Groups using Group Policy Preferences for the HR department servers:

    1. We already know the groups we want to consider ‘special’. We can download the PSGETSID tool and use it to get the SID’s we will be setting, like so:


    2. Now we have our four SID’s for these important high privilege groups:


    3. We open GPMC.MSC on our Windows Server 2008 machine, and create (or reuse) a new policy that we link at the Human Resources OU. We open the policy for edit, and navigate into ‘Computer Configuration’, then the new ‘Preferences’ section. We expand ‘Windows Settings’, then ‘Registry’. Now we can add our new registry values that we need. Right-click on ‘Registry’ like so and select ‘New’ and ‘Registry Item’.


    4. We set our action to ‘Update’ so that it creates the value if not there or updates the value if it already exists. We select our exact key path and the value name. Then we take our list of SID’s that PSGETSID gave us and plug it in, using semicolons to separate them, like below:


    5. We could stop here. Let’s get fancier. What if we keep all computers related to the HR department in that OU, including workstations? Nobody told us that they wanted this auditing in place on the client machines, and we want this setting to just apply to the right machines. Click the ‘Common’ tab and select ‘Targeting’.


    6. Now we’re talking – check out all this filtering we can do!


    7. In this case we’re going to select ‘Operating System’ must be Windows Server 2008 and we only want this to apply to the two HR file servers they asked us about (yes, technically I don't need the OS check if I assume that these two servers are 2008 - but I'm not an assumer). From looking at the above you can probably think of a zillion other things you might set as criteria. Don’t go crazy here, the more criteria you set, the more processing you add to the GPP calculations being done on the machine getting policy. Keep it simple.


    8. Now we refresh group policy on one of our target HR servers. Our registry now has:


    9. We logon to this server as a user that’s a member of at least one of these special groups and open our Security Event Log:


    Heck yeah – worked like a champ. Anytime a user logs on to this server and is a member of one our special groups, we’ll have this easy and unique Event 4964 to follow. We don’t have to parse through the event logs looking at all the regular LOGON events that occurred, correlating them to individuals, and that makes life easier for everyone.

    One last neat feature – let’s say you want to take this new registry setting and give it to a colleague that manages a different environment in your company. In the preference policy editor, Select your registry setting and drag it onto your desktop – an XML file will be created with those settings. Open it in Internet Explorer:


    Slick. Lost your setting? Drag that XML back into the editor – your settings are back. Double slick.

    Want to learn more about all the new security audit events? Read “Description of security events in Windows Vista and in Windows Server 2008”. Want even more? Head over to the “Windows Server 2008 Security Guide” and “Windows Server 2008 Security Resource Kit” (which contains a chapter by audit guru Eric Fitzgerald).

    - Ned Pyle