Microsoft's official enterprise support blog for AD DS and more
Hi Rob here, I am a Support Escalation Engineer in Directory Services out of Charlotte, NC, USA. We work a lot of Kerberos authentication failure issues. Since Kerberos is typically the first authentication method attempted, it ends up having authentication failures more often. One of the great things about Windows is that the product seems to just work without too much customization that is needed by the customer. However I wanted to create a blog to try and demystify how Kerberos authentication works. I plan on writing several Kerberos blogs in the near future to include Kerberos Delegation aka Double-hop, how to troubleshoot Kerberos authentication.
There are some general terms that you might not be familiar, so let's run through them quickly.
Principal Names:
Kerberos defines two different types of accounts (or Principals). The two different names given to these types of accounts are User Principal Name (UPN), and Service Principal Name (SPN). We would typically relate these two types of principals to Active Directory users and computers.
Only user accounts have a UPN defined on their account. When looking at a user account if you click on the Account tab, the UPN is derived from the combining of the two fields listed for “User logon name”. A User Principal Name must be unique across the entire forest otherwise when the KDC goes to look up the Users Account via UPN it will get back more than one account and cause authentication failures for all users that have the same UPN. The UPN of an Active Directory object is an attribute of the object, and can only hold a single value. The attribute name is userPrincipalName. An example of a UPN is: rob@contoso.com.
Service Principal Names MUST be unique across the entire Active Directory forest, and can be assigned to either User accounts or Computer accounts. Only computer accounts automatically have Service Principal Names defined.
Service Principal Names define what services run under the accounts security context. For example some of the services that a computer might have are File server / CIFS (Common Internet File System), if it is a domain controller it is going to have an LDAP SPN, and Active Directory Replication SPN, and FRS SPN. Service Principal Names can be defined on user accounts when a Service or application is running under that users Security context. Typically these types of user accounts are known as “Service Accounts”. It is very import that you understand that Service Principal Names MUST be unique throughout the entire Active Directory forest.
Some typical scenarios when a user account has a Service Principal Name defined are:
Some tools that can be used to list the Service Principal names on an Active Directory object are: LDP, LDIFDE (These two are great utilities if you want to query LDAP for all objects that have the SPN defined on them.), next is ADSIEdit, or SetSPN. The last two are great utilities if you want to see what SPNs are registered on a given object.
Kerberos tickets:
KDC (Key Distribution Center): The KDC is a service that should only be running on a domain controller. The service name is “Kerberos Key Distribution Center”. Basically the KDC is the service that is responsible for authenticating users when Kerberos is used. The KDC implements two server components. Authentication Server (AS), and Ticket Granting Server (TGS).
Authentication Server (AS): The KDC role that verifies the identity of the principal and issues the Ticket Granting Ticket (TGT) to the principal upon successful authentication. Holding a valid TGT allows the principal to request a Service ticket from the Ticket Granting Server (TGS). There will be a TGT in the Credentials Cache for each domain the principal has accessed resources in. An example of this would be: a user in contoso.com domain wanted access to a file server in emea.contoso.com the user would have a TGT for contoso.com, and emea.contoso.com
Ticket Granting Server (TGS): The KDC role that issues a service ticket when a principal requests connection to a Kerberos service. You must have a Ticket Granting Ticket (TGT) for the Active Directory domain before you can be issued a service ticket in that Active Directory domain. Although the KDC issues the service ticket it does not talk directly to the service that the principal is requesting the ticket for. Once a service ticket has been issued by the Ticket Granting Server, the service ticket is put into the principal’s credentials cache for later use. When the principal needs to connect to the requested service the service ticket is used from the credentials cache and sent to the service it is attempting to connect to.
There are only two different types for tickets that the KDC issues.
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).
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.
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.
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.
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.
6. After authentication succeeds The Service responds back to the client with a KRB_AP_REP.
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.
We are going to cover Kerberos Delegation in detail in another blog entry.
Tools used to view and troubleshoot Kerberos:
KerbTray: This is a great utility GUI based utility that shows up in the system tray that allows you to view all your Kerberos tickets as well as being able to purge them. The purge feature is done by right clicking the green ticket in the system tray and selecting “Purge Tickets”. The Purge Tickets options delete all Kerberos tickets.
http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&DisplayLang=en
KList: This is a great command line tool that lists Kerberos tickets as well as being able to purge Kerberos tickets. The nice thing about this tool is that you can selectively purge Kerberos tickets rather than deleting all tickets like the KerbTray utility does.
http://www.microsoft.com/downloads/details.aspx?FamilyID=1581e6e7-7e64-4a2d-8aba-73e909d2a7dc&DisplayLang=en
Network Captures: Network capturing utilities can be indispensable when troubleshooting a Kerberos authentication issue. As we say here “the truth is on the wire”. Most network capture utilities have very good Kerberos parsers included. Some of our favorites here are Network Monitor 3, WireShark, and Ethereal.
Kerberos Event logging: The operating system by default does not create event log entries for Kerberos authentication events. You can however turn this feature by reviewing the following KB article:
262177 How to enable Kerberos event logging - http://support.microsoft.com/default.aspx?scid=kb;EN-US;262177
You would enable this feature on the client machines and any other machines participating in Kerberos delegation.
Note: I would caution you on enabling this feature. There are some events that you will see that are really not Kerberos errors – such as 0x12 KDC_ERR_CLIENT_REVOKED, 0xD KDC_ERR_BADOPTION, or 0x34 KRB_ERR_RESPONSE_TOO_BIG. We have had cases where the customer enabled this from a previous case and never turned it back off. Since they were now sensitive to all Kerberos errors they have opened up a new case just to be asked to turn off the logging because the events were not really errors.
Kerberos Dependencies:
There are some basic dependencies that need to be in place for Kerberos Authentication to succeed.
For Kerberos to function correctly, the supporting infrastructure must be sound. Since Passwords are used to encrypt data within Tickets it is imperative that when a user or computer changes their password that Active Directory replication is able to send these changes throughout the environment.
Proper name resolution is required. For Kerberos to function it has to be able to resolve the proper IP Addresses for the KDC as well as the Service Principal you are attempting to access. Both DNS and NetBIOS name resolution must be setup correctly. Many cases identified as Kerberos issues were caused by bad records in DNS, broken WINS replication, or HOSTS/LMHOSTS files with invalid data. DNS SRV records for _kerberos will need to be in place, for both the _tcp and _udp DNS sub-domains. Check the configured DNS suffixes and search order as well. A typical problem that we find is that the DNS Zone has been configured for WINS Lookup. When this happens the wrong DNS FQDN is found for the service the user is attempting to connect to, which then causes the application to ask for a service principal for the wrong FQDN.
All machines participating in Kerberos authentication need to be within 5 minutes of time. By default Windows will use the Windows Time (w32time) service, but can use a third party NTP client. We don’t care what time it is as long as all computers in the forest agree to within 5 minutes of one another.
We need to ensure that we have good connectivity. TCP and UDP port 88 must be open from clients to domain controllers. A common problem is that routers will arbitrarily fragment UDP packets; when this happens the Kerberos ticket request packets are discarded by the KDC. Windows Vista and Windows Server 2008 now default to using TCP for kerberos ticket requests. Typically you work around this issue by implementing the following KB article:
244474 How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;244474
LDAP queries will be made by the DC / KDC for Service Principal Name records. Duplicate computer names, usernames, etc, or manually registered duplicate SPN's anywhere in the forest can cause Kerberos errors. There is an event that is created when this happens, but it is only logged on the domain controller that attempted to find the service principal. It is a Kerberos Event 7.
Other Kerberos information:
How the Kerberos Version 5 Authentication Protocol Works http://technet2.microsoft.com/WindowsServer/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx
Kerberos Authentication in Windows Server 2003 http://technet2.microsoft.com/windowsserver/en/technologies/featured/kerberos/default.mspx
MIT’s references for Kerberos
http://web.mit.edu/kerberos/
The Kerberos Consortium
http://www.kerberos.org
Kerberos RFC
http://www.ietf.org/rfc/rfc1510.txt http://www.ietf.org/rfc/rfc4120.txt
- Rob Greene
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.
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:
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 3Managing Power with Group Policy: Part 2 of 3Managing Power with Group Policy: Part 3 of 3
-Mike Stephens
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.
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.
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.
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.
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.
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.
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.
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:
For an easy way to validate whether or not the machine has a valid certificate, we can run the following command:
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:
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.
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:
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:
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:
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:
Our next step is to locate the following section:
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:
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:
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:
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:
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:
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:
Next we need to copy the ServerCert.cer to the client machine and run the following command:
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:
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
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
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 Systemshttp://www.microsoft.com/downloads/details.aspx?FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960&DisplayLang=enMicrosoft Remote Server Administration Tools for Windows Vista for x64-based Systemshttp://www.microsoft.com/downloads/details.aspx?FamilyID=d647a60b-63fd-4ac5-9243-bd3c497d2bc5&DisplayLang=enAfter 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
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:
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 Vistahttp://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:
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.
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
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:
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.