Hello Internet! Last week, Ned said there wouldn’t be a Mail Sack this week because he was going to be out of town. Well, the DS team was sitting around during our “Ned is out of our hair for a few days” party and we decided that since this is a Team Blog after all, we’d go ahead and post a Friday Mail Sack. So even though the volume was a little light this week, perhaps due to Ned’s announcement, we put one together all by ourselves.
So without further ado, here is this week’s Ned-less Mail Sack.
Certificate Template Supersedence
Q: I’m using the Certificate Wizard in OCS to generate a certificate request and submit it to my Enterprise CA. My CA isn’t configured to issue certificates based on the Web Server template, but I have duplicated the Web Server template and modified the settings. My new template is configured to supersede the Web Server template.
The request fails. Why doesn’t the CA issue the certificate based on my new template if it supersedes the default Web Server template?
A: While that would be a really cool feature, that’s not how Supersedence works. Supersedence is used when you want to replace certificates that have already been issued with a new certificate with modified settings. In addition, it only works with certificates that are being managed by Windows Autoenrollment.
For example, the Administrator has enabled Autoenrollment in the Computer Configuration of the Default Domain Policy:
Further, the Administrator has granted the Domain Computers group permission to Autoenroll for the Corporate Computer template. Appropriately, every Windows workstation and member server in the domain enrolls for a certificate based on this template.
Later, the Administrator decides that she needs to update the template in some fashion – add a new certificate purpose to the Enhanced Key Usage, change a key option, whatever. Our intrepid Admin duplicates her Corporate Computer template and creates a new Better Corporate Computer template. In the properties of this new template, she adds the now obsolete Corporate Computer template to the Superseded Templates list.
The Admin clicks Ok to commit the changes and then sits back and waits for all of the workstations and member servers in the domain to update their certificate. So how does that work, exactly?
On each workstation and member server, the Autoenrollment server wakes up about every 8 hours and checks to see if it has any work to do. As this occurs on each Windows computer, Autoenrollment determines it is enabled by policy and so checks Active Directory for a list of templates. It discovers that there is a new template for which this computer has Autoenrollment permissions. Further, this new template is configured to supersede the template a certificate it already has is based upon.
The Autoenrollment service then archives the current certificate and enrolls for a new certificate based on the superseding template.
In summary, supersedence doesn’t change the behavior of the CA at all, so you can’t use it to control how the CA will respond when it receives a request for a certain template. No, supersedence is merely a hint to tell Autoenrollment on the client that it needs to replace an existing certificate.
Active Directory Web Services
Q: I’m seeing the following warning event recorded in the Active Directory Web Services event log about once a minute.
Log Name: Active Directory Web Services
Source: ADWS
Date: 4/8/2010 3:13:53 PM
Event ID: 1209
Task Category: ADWS Instance Events
Level: Warning
Keywords: Classic
User: N/A
Computer: corp-adlds-01.corp.contoso.com
Description:
Active Directory Web Services encountered an error while reading the settings for the specified Active Directory Lightweight Directory Services instance. Active Directory Web Services will retry this operation periodically. In the mean time, this instance will be ignored.
Instance name: ADAM_ContosoAddressbook
I can’t find any Microsoft resources to explain why this event occurs, or what it means.
A: Well…we couldn’t find any documentation either, but we were curious ourselves so we dug into the problem. It turns out that event is only recorded if ADWS can’t read the ports that AD LDS is configured to use for LDAP and Secure LDAP (SSL). In our test environment, we deleted those values and restarted the ADWS service, and sure enough, those pesky warning events started getting logged.
The following registry values are read by ADWS:
Key: HKLM\SYSTEM\CurrentControlSet\Services\<ADAM_INSTANCE_NAME>\Parameters
Value: Port LDAP
Type: REG_DWORD
Data: 1 - 65535 (default: 389)
Key: HKLM\SYSTEM\CurrentControlSet\Services\<ADAM_INSTANCE_NAME>\Parameters
Value: Port SSL
Type: REG_DWORD
Data: 1 - 65535 (default: 636)
Verify that the registry values described above exist and have the appropriate values. Also verify that the NT AUTHORITY\SYSTEM account has permission to read the values. ADWS runs under the Local System account.
Once you've corrected the problem, restart the ADWS service. If you have to recreate the registry values because they've been deleted, restart the AD LDS instance before restarting the ADWS service.
Thanks for sending us this question. We’ve created the necessary internal documentation, and if we see more issues like this we’ll promote it to the Knowledge Base.
Final Note
Well…that’s it for this week. Please keep posting your comments, observations, topic ideas and questions. And fear not, Ned will be back next week.
Jonathan “The Pretender” Stephens