Until Windows Server 2008 shipped, every Domain Controller had a readable and writable copy of the Active Directory schema, domain naming context and configuration naming context. This statement changed when we introduced the Read Only Domain Controller (RODC) role with Windows Server 2008. The RODC creates several new configuration scenarios for Active Directory integrated applications.

With this blog post I want to explain a situation where a Windows Server 2003 Enterprise CA setup fails with error Element not found. 0x80070490. The setup error occurs when the intended Windows Server 2003 CA computer maintains a secure channel with a Windows Server 2008 RODC. In this case, the CA setup code cannot write new objects into the Active Directory configuration naming context. In Windows Server 2008 the CA setup code was updated to always make a connection to a writable Domain Controller in the beginning and then stick with that Domain Controller for all the operations done during setup.

To work around the Windows Server 2003 CA setup limitation, you could use the nltest.exe command from the Windows Support tools. To do so, make sure that a writable domain controller exists in the site that the Windows Server 2003 CA computer belongs to. If no writable domain controller is configured for the site, you must work with your Active Directory Enterprise administrator to change the site configuration so that a writable domain controller becomes available in the CA’s site.

To fix the problem, open a command prompt on the intended Windows Server 2003 CA to execute the following commands with local administrator permissions.

As a first step, query the DNS for a list of writable domain controllers in the domain. In this sample I use contoso.com as domain name.

nltest /dnsgetdc:contoso.com /WRITABLE

Next, reset the secure channel that is currently used between the Windows Server 2003 and the RODC.

nltest /sc_reset

Finally, verify if the secure channel is now set up with a writable domain controller.

nltest /sc_query:contoso.com

If the intended CA computer is now connected to a writable domain controller, restart the CA setup.

I am excited to announce the public availability of the Cross-forest Certificate Enrollment with Windows Server 2008 R2 whitepaper.

The product team worked hard to make this breakthrough functionality happen in Windows Server 2008 R2. Now is the time to evaluate cross forest certificate enrollment in your test environment. If you have specific feedback on the whitepaper, feel free to add your comments to this blog entry.

From the abstract:
Windows Server 2008 R2 allows enterprises to issue digital certificates from an enterprise Certification Authority (CA) to the clients that are members of a different Active Directory (AD) forest. This process is called cross-forest certificate enrollment. This white paper will explain how the cross-forest certificate enrollment works. It will also provide deployment guidance for new and existing Active Directory Certificate Services (ADCS) deployments. The paper will cover strategies for consolidating existing certificate templates that may be already in use in the enterprise. It will present choices for ongoing management of the cross-forest certificates deployment. A PowerShell script is also provided to facilitate management tasks related to setting up and maintaining cross-forest certificate enrollment environment.

Today I want to comment on the quite popular Microsoft Knowledgebase article How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server. I am referring to version 6.0 of the article with a review date of November 18th, 2008. You should be aware that the article has documentation bugs that need to be fixed. Until we are publishing a corrected version, you should consider the following information when applying the steps from the article.

1. In Step 6 L, the article asks you to delete all certificate templates. This is misleading information because it is only appropriate when you have already deleted ALL CAs in the Active Directory Forest. If there are still enterprise CAs in operation, certificate templates must not be deleted.
2. The article does not point out to identify all of the CA objects in Active Directory (under the KRA container, for example), so some may be left around. To clean up after a CA that left objects around in Active Directory, run the following commands to see what AD objects remain:
   
   certutil –ds {CACommonName}
   certutil –ds {CAMachineNetBiosName}
   
   For example, if the common name of the CACommonName is called CorpCA01 and the CAMachineNetBiosName is CACorpServer you would perform the following commands:
   
   certutil –ds CorpCA01
   certutil –ds CACorpServer
   
   Once you look over the list of DNs displayed, and are satisfied they are all related to the abandoned CA, you can change -ds to -dsDel and repeat the commands to delete the CA's objects with enterprise administrator permissions.
   
3. In Step 6 M, the article says to delete the NTAuthCertificates object. This is wrong information because this object should never be deleted - only CA certificates should be deleted from its cACertificate attribute. Use the following command to see the full ldap path to your NtAuthCertificates object in your Active Directory.

certutil -ds -v NtAuthCertificates

With enterprise administrator permissions you can use the following command to delete certificates from within the NTAuthCertificates store:

certutil –viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,...,DC=...,DC=com?base?cACertificate"

The -viewdelstore verb invokes the certificate selection U/I on the set of certificates in the specified attribute. You can view cert details, and cancel out of the selection dialog to make no change. If you select a certificate, it will be deleted when the U/I closes and the command completes execution.

To clean up the NTAuthCertificates you can also use the PKIview MMC snap-in. It is part of the Windows Server 2003 Resource Kit Tools and the Microsoft Remote Server Administration Tools in Windows Server 2008 and Windows Vista.

Those of you who are interested in biometrics should look at the following documents:

• Introduction to the Windows Biometric Framework (WBF)
• New Windows Biometric Framework and Driver Model
• Windows 7 Beta WDK

Consider that you are sending an encrypted eMail to a recipient who has multiple certificates stored in Active Directory. The key question is: Which certificates are selected by Outlook 2003/2007?

When sending an encrypted eMail, Outlook actually requires two certificates. One certificate is owned by the recipient and one is owned by the sender. The recipient’s certificate is used by the sender for encrypting the eMail which is sent out. The sender’s certificate is used by the sender to encrypt the eMail that is stored in the Sent Items folder in Outlook.

For background information about digital certificates and Active Directory Attributes see the General PKI Planning Considerations on Microsoft TechNet.

Finding a valid certificate owned by the recipient

To find a valid certificate owned by the recipient, Outlook verifies if any certificates are stored in the userSMimeCertificate attribute in Active Directory. If so, Outlook examines the PKCS#7 blobs to find out if Outlook is the one that published them. In that case, there is an extra signed attribute that indicates which is the default certificate. If the certificate marked as default is found in the userSMimeCertificate attribute, it is chosen. If the default certificate is not found, the first valid certificate in the store is selected. In case the userSMimeCertificate attribute stores no certificates, Outlook queries the userCertificate attribute in Active Directory. The first non expired certificate that carries the Secure Email OID 1.3.6.1.5.5.7.3.4 in the Enhanced Key Usage and has the appropriate key usage is used. In case of message encryption, the Key Usage must be equal to Key Encipherment (20) while for message signing the Key Usage must match Digital Signature (80).

Finding a valid certificate owned by the sender

Outlook accepts the certificate that the user selected in the Security Settings unless the certificate is invalid. If the certificate is invalid, Outlook tries to find the certificate that is closest to the bad one. The selection code looks for a valid certificate from the same issuer (in case the certificate in the Security Settings just got renewed) and if one is found, it puts it into the Security Settings. If the Outlook profile contains no valid Security Settings or there are no Security Settings at all, then the Security Settings are (re)created with certificates that have the longest time before expiration and are dual purpose. Basically Outlook picks the certificate that will expire last and if there are multiple of those it picks the one that can be used for signing and encryption.

Forcing Outlook to create the Security Settings

See the following Microsoft Knowledge Base articles to automatically configure Outlook for S/MIME support:

• Outlook 2007 post-Service Pack 1 hotfix package: January 28, 2008 (http://support.microsoft.com/kb/941275)
  • Note: there might be a more recent hotfix package including this functionality
• After you obtain an S/MIME certificate, no button is available to sign or to encrypt e-mail messages in Outlook 2003 (http://support.microsoft.com/kb/948076)