So I was trying to find all the users in an Active Directory domain that had a manager. Naturally I turned to PowerShell and the Get-ADUser cmdlet.

First I tried this:

Get-ADUser -Properties Manager -Filter { manager -like “*” }

That threw this error:

Get-ADUser : Operator(s): The following: ”Eq’, ‘Ne” are the only operator(s) supported for searching on extended
attribute: ‘Manager’.

OK, so we can only use the operators eq (equals) and ne (not equals) when working with what the Active Directory PowerShell module defines as extended properties. But these only work if you are interested in specific values. I wanted to find any user that had a manager defined, regardless of who it was. So I could not use eq or ne.

So then I did this:

Get-ADUser -Properties Manager -Filter * | where { $_.manager -ne $null }

Which works, but returns every user from Active Directory and then PowerShell does the filtering. Not optimal code. I could have left if there, but you know…

This is what I ended up with:

Get-ADUser -Properties Manager -LDAPFilter “(manager=*)”

This uses the power of filtering within the directory service.

Introduction

The subject of delegating permissions in Active Directory for management of computer objects has been covered many times in many forums. I wanted to try to collect all that information as well as add some refinements of my own.

Rights vs. permissions

In the olden days, back when I was just a wee lad and Windows NT was new, the ability to join a computer to a domain was controller by a user right called Add workstations to domain. This user right is only valid on domain controllers. Any use who had this right could join computers to a Windows NT domain. The user right still exists and is in use even on Windows Server 2012 R2 Domain Controllers running Active Directory domains. When users join their computers to the domain using their own credentials they do it using this user right. It is, in fact, the only option available to them, since no regular users are granted any permissions over computer objects in Active Directory by default.

Back in the NT era this right was granted to the Users group and there was no limit to how many computers any give user could add to the domain. When Windows 2000 came along and with it Active Directory the user right was changed to apply to the Authenticated Users security principal and any one user could only add 10 computers to a domain by default. But the preferred way for Active Directory was to use permissions in the directory service to control object creation, modification and deletion…

Active Directory has a very fine grained permissions set allowing you to set permissions for objects as well as their properties. These permissions work the same way as the rest of the authorization model in Windows does by using Access Control Lists (ACL) with security principals and their permissions listed in individual Access Control Entries (ACE). Permissions can be granted anywhere in the hierarchy and inherited down to objects and containers. Granting permissions in Active Directory to someone or something is often called delegation. Computer objects are of course also included in these permissions and we can create much better delegation of control than we could with just a global user right.

We’ll cover three delegation of control scenarios regarding computer object management in this post:

1. Allowing a security principal to join (add) a computer to a domain
2. Allowing a security principal to join and re-join a computer to a domain
3. Allowing a security principal to rename a computer in a domain
4. Allowing a security principal to move computer objects in a domain

You can of course combine any of these.

Creating a computer object and changing its properties is what is required to join a computer to the domain. The container could be the Computers container or any other OU or container, including the domain itself but I do not recommend that.

When a computer joins an Active Directory domain without specifying a path, it is placed in the Computers container. The Computers container is not an OU and so it cannot have Group Policy Objects linked to it or have sub containers or OUs. If you are fine with all computer objects being created in this container you can delegate the permissions below to the Computers container

1. Allowing a security principal to join (add) a computer to a domain

First out is the most common scenario; join a computer to an Active Directory domain. As stated earlier it is not necessary to delegate this to regular users since the very few cases where they join their own computers to a domain should be covered by the Add workstation to domain user right. One exception to this is if you want to tighten down security and remove all security principals from this user right. In that case, if you still want to allow regular users to be able to join computers to a domain you have to delegate permissions to them. The more common case is that whatever deployment solution you use adds the computers to the domain. This is by far the best solution since very few users have any idea what a domain is.

A best practice is to create a service account used only for adding computers to the domain. This account should be clearly labeled, have a strong password and not have any other rights or permissions in you directory except the ability to join the domain. That being said the procedure below works for any security principal you want to delegate permissions to join the domain for.

1. Identify the security principal that you want to delegate permissions for
   This can be any security principal; user, group etc.
2. Identify the container or OU where you want to allow users to manipulate computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and finally hit Next
   
8. The Permissions window opens
   Select Property-specific and select Read All Properties. This is actually redundant since this permissions are already granted to the Authenticated Users principal, but the delegation of control wizard will not let you continue without selecting something on this screen.
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:

    saferoad.com/Computers

The groups, users, or computers to which you
have given control are:

    Domain Join Account (SvcJoinComputerToDom@saferoad.com)

They have the following permissions:

    Read All Properties

For the following object types:

    Computer

2. Allowing a security principal to join and re-join a computer to a domain

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and Delete selected objects in this folder, and finally hit Next
   
8. The Permissions window opens
   Select Property-specific and select these individual permissions:
   – Reset Password
   – Read and write Account Restrictions
   – Validated write to DNS host name
   – Validated write to service principal name 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:

    <domain>/Computers

The groups, users, or computers to which you
have given control are:

    Domain Join Account (SvcJoinComputerToDom@<domain>)

They have the following permissions:

    Reset password
    Read and write account restrictions
    Validated write to DNS host name
    Validated write to service principal name

For the following object types:

    Computer

3. Allowing a security principal to rename a computer in a domain

Here goes no. 3…

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects and hit Next 
   
8. The Permissions window opens
   Select Property-specific and select Write All Properties.
   Scroll down an add these individual permissions as well:
   – Validated write to DNS host name
   – Validated write to service principal name 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   
   

   Delegation of Control Wizard Summary

   You chose to delegate control of objects
   in the following Active Directory folder:

       saferoad.com/Computers

   The groups, users, or computers to which you
   have given control are:

       Domain Join Account (SvcJoinComputerToDom@saferoad.com)

   They have the following permissions:

       Write All Properties
       Validated write to DNS host name
       Validated write to service principal name

   For the following object types:

       Computer

4. Allowing a security principal to move computer objects in a domain

The last one is a little more involved as it requires changing permissions on both the source container/OU and the destination. The destination container/OU requires the same permissions as in scenario 1 so set those. Follow these steps to configure the source container/OU:

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder, select Computer objects and , select Delete selected objects in this folders, hit Next 
   
8. The Permissions window opens
   Select Property-specific and select Write All Properties. 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:

    saferoad.com/Computers

The groups, users, or computers to which you
have given control are:

    Domain Join Account (SvcJoinComputerToDom@saferoad.com)

They have the following permissions:

    Write All Properties

For the following object types:

    Computer

More information

There is an interesting distinction between joining a domain by exercising the user right Add workstation to the domain and using delegated permissions. If you join by the user right the owner of the resulting computer object is the Domain Administrators group, but if you join by delegated permissions the owner is the user who actually performed the join. Also if a principal has both the user right and delegated permissions, delegated permissions take precedent and are used to join the computer to the domain. A recommended best practice her would be to remove all principals from the user right and just rely on permissions. You do that by applying a policy to your domain controllers where no principal has the user right:



The location of the user right is:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment

You could also increase the default quota of 10 computer accounts added to the domain per user, but I do not recommend that. I essence you are copying the settings from Windows NT to your Active Directory domain and do not take advanced of the advanced delegation model in Active Directory. For completion here is how to change the quota:

From any editor capable of displaying and changing individual attributes of Active Directory objects; display the properties of the domain NC. Locate the ms-DS-MachineAccountQuota property and change it to your desired value:



Links

Here are a few links for further info:

• How to Grant Permission to Move Computer Accounts to a User or Group
• Add workstations to domain user right
• Domain Users Cannot Join Workstation or Server to a Domain
• Default limit to number of workstations a user can join to the domain
• Error message when non-administrator users who have been delegated control try to join computers to a Windows Server 2003-based or a Windows Server 2008-based domain controller: “Access is denied”

Introduction

From time to time someone may want to access your Active Directory Directory Service with LDAP. Usually from a system or location that you view as unsecure or untrustworthy. Examples are printers that do directory lookups to send scanned documents by e-mail and external systems where a provider needs information about your users to provide them service. The querying party is often an open source implementation of an LDAP client. Here is some advice about how to configure such a setup.

Connecting

All Active Directory Domain Controllers provide LDAP over TCP and UDP ports 389, and Secure LDAP (LDAP-S) over TCP port 636, by default. If there is a firewall between your Domain Controller and the connecting system you will have to allow and/or forward the required ports. For any connection you should always use LDAP-S, especially for connections that traverse untrusted networks, e.g. the Internet. For recent versions of Windows Server the host firewall is enabled by default and the inbound rules for LDAP and LDAP-S are automatically enabled when the server is promoted to a domain controller. Depending on your network firewalls you may have to enable Allow edge traversal. You do this from the properties of the rule in the Windows Firewall with Advanced Security console:

Selecting a DC

Choosing which DC the LDAP client connects to is either configured by you or located automatically. A Windows machine that is a member of a domain knows how to find LDAP servers in its domain, which it does by querying DNS. A lot of Active Directory discovery is done by DNS in Windows. A Windows client will typically query DNS for A (host) records for its own domain to find which servers are writable LDAP servers. All RW DCs register an A record for the domain name to indicate they are LDAP servers. Alternatively a Windows client can also query for SRV (service) records for _ldap._tcp.dc._msdcs.<DNS domain name>. The DC Locator component, implemented by the NETLOGON service on a Windows machine performs these queries. When a Windows client wants to log on to a domain it uses SRV records. But the fact that a Windows machine that is joined to a domain can find LDAP servers by using DNS does not mean that an application running on it can do the same, or take advantage of the information found by the DC Locator component. Very often an application that uses LDAP implements its own LDAP configuration and service discovery. Typically LDAP servers are either found by querying DNS for either A, CNAME, TXT or SRV records as specified by you, or LDAP servers a statically configured. If the connecting system is on your internal network then the best option would be for it to use DNS to discover LDAP servers based on the DNS name of the domain. That way the system will continue to function even if you introduce new or retire old domain controllers. If that is not possible try using an A record as an alias; like ldap.<DNS domain name>. The you can statically configure your LDAP client to connect to that name. If any change occurs in your directory service, all you have to do is update the alias. You can even have more than one record for the same alias and DNS will serve them up randomly. If the connecting system is outside your network and does not have access to your internal DNS zones, you are left with statically configuring it using either an IP address or an FQDN which is resolvable outside of your network.

Some more info:

• How Domain Controllers Are Located in Windows
• How Domain Controllers are Located Across Trusts

Certificates

The domain controller needs a certificate to be able to supply LDAP-S. You can in theory use a certificate signed by any authority, including a self signed one, as long as the connecting party either trust the signer or ignores certificate errors. The following KB article goes into details about the specific LDAP certificate requirements for domain controllers:

• How to enable LDAP over SSL with a third-party certification authority

It is not possible to configure a specific certificate for LDAP if there are several to choose from. The aforementioned KB article explains the certificate selection process that the DC uses.

It is also a good idea to provide the connecting party with a base DN from which to start a search, although you cannot stop them from changing it.

Account

After the connection is established the connecting party needs to authenticate to access the directory. The most common form of authentication in this scenario is a username and password combination. Since Active Directory is its own authentication provider you will need to create an account in AD and provide the connecting party with the domain, username and password information. This account will be an implicit member of the Authenticated Users group when it is logged on and thus have the same access rights in the directory as the Authenticated Users principal has. Unless you have changed your directory considerably Authenticated Users will have read access to most of your Active Directory. Changing this is not a trivial task and would require you to change the very basic authorization settings of your directory, and since these settings are enforced on a schedule by the DS you will have to create your own way of making them stay changed.

Any user account you opt to use will also be a member of the Domain Users group. This grants it certain rights in your domain that you might not want such an account to have. For example a member of Domain Users can log on to computers in your domain by power of the fact that Domain Users is a member of the Users group on every member computer in the domain. I recommend creating a new global security group, called NO_PRIVILEGE for example, and add the account to that group, and at the same time removing the account from Domain Users. By doing this you will revoke any permissions Domain Users has from the account. You cannot just remove it from Domain Users, since every user account in Active Directory must have a primary group associated with it. The NO_PRIVILEGE group will  become that new primary group once Domain Users membership is revoked.

Testing

To test if your setup work I recommend an LDAP browser or explorer. Windows includes one called LDP.EXE and it is quite good, but since it cannot ignore certificate errors, it might not work in all scenarios. Here are a couple of alternatives:

• LDAP Admin
  Open Source
• LEX – The LDAP Explorer
  Commercial license

I find that LDAP Admin servers all my needs. It even alerts you to certificate errors and lets you view the certificate and continue if you so choose.

To test if the required ports are open and forwarded you can also use the PortQry utility from Microsoft. Here is an example command to check for LDAP-S:

.PortQry.exe –n <my DC FQDN> -p TCP -e 636

Tip

To ignore certificate errors in LDAP on open source systems I recommend doing a search for TLS_REQCERT and LDAPTLS_REQCERT.

Introduction to auto-enrollment

Auto-enrollment is a useful feature of Active Directory Certificate Services (AD CS). It allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. The subject does not need to be aware of any certificate operations, unless you configure the certificate template to interact with the subject. A subject in this case can be either a user account or a machine account. (And just a reminder; certificate auto-enrollment is only possible with version 2 certificate templates and these are only available with a Windows Server 2003 Enterprise based Certificate Authority or newer, and a domain with the Windows Server 2003 schema or newer.)

Auto-enrollment is configured through Group Policy and can be set for both types of subjects; users and computers. The location in a GPO is:

• Computer: Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesCertificate Service Client – Auto-enrollment
• User: User ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesCertificate Service Client – Auto-enrollment

The dialog box is identical and looks like this when enabled:

Just for reference, here is how this dialog looked in Windows XP/Windows Server 2003:

Back then it was located under User/Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesAutoenrollment Settings.

While in the computer part of the GPO you will also notice another setting which deals with auto-enrollment:

Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesAutomatic Certificate Request Settings

This settings configures which types of certificates a computer should automatically enroll for; Computer, Domain Controller, Enrollment Agent (Computer) or IPSec. This setting has no value by default, instead you have to complete a short wizard to add a value to it by right-clicking and selecting New: Automatic Certificate Request. This will bring up the wizard:

  

The steps above will lead to the following setting:

The first setting mentioned, Certificate Service Client – Auto-enrollment, controls whether and how auto-enrollment should be performed. This setting, on the other hand, specifies which certificate template to request certificates for. In some cases the client know which templates it wants certificates from, and only needs to be told to auto-enroll. Other times you have to specify this setting as well to tell the client about the certificates templates you want it to auto-enroll based on. The Automatic Certificate Request Settings key is only available in a domain based GPO, not in local policy. For detailed information about this setting look here:

• Create an automatic certificate request for computers in a Group Policy object
• Automatic certificate request policy

Auto-enrollment of certificates is triggered by one of these events:

• Computer reboot and subsequent Group Policy application/refresh
• Interactive logon and subsequent Group Policy application/refresh (Winlogon.exe calls userinit.exe that performs the auto-enrollment based on Group Policy.)
• Group Policy refresh, either periodic or forced
• certutil.exe –pulse command

By default there are no auto-enrollment settings configured in a Windows domain. Neither the Default Domain Policy nor the Default Domain Controllers Policy contain auto-enrollment settings so none of your computer or user accounts will automatically enroll for any certificates. There are, however, a few exceptions to this rule. One, of which, are  Domain Controllers.

Enhanced event logging for auto-enrollment

To understand certificate auto-enrollment it helps to enable enhanced logging. By default, auto-enrollment logs errors/failures and successful enrollments in the Application Event log on the client machine.

To enable enhanced logging of auto-enrollment processes, the following registry values must be created:

User Auto-enrollment

HKCUSoftwareMicrosoftCryptographyAutoenrollment

Create a new DWORD value named AEEventLogLevel; set value to 0.

Machine Auto-enrollment

HKLMSoftwareMicrosoftCryptographyAutoenrollment

Create a new DWORD value named AEEventLogLevel, set value to 0.

Note All failures and errors are automatically logged. It is not necessary to enable the registry key to turn on failure logging.

Certificate templates

According to TechNet: Enterprise certification authorities (CAs) use certificate templates to define the format and content of certificates, to specify which users and computers can enroll for which types of certificates, and to define the enrollment process, such as auto-enrollment, enrollment only with authorized signatures, and manual enrollment. Associated with each certificate template is a discretionary access control list (DACL) that defines which security principals have permissions to read and configure the template, as well as to enroll or auto-enroll for certificates based on the template. The certificate templates and their permissions are defined in Active Directory® Domain Services (AD DS) and are valid within the forest. If more than one enterprise CA is running in the Active Directory forest, permission changes will affect all enterprise CAs.

Read the whole text here.

Domain Controller related certificate templates

Domain controllers are interested in the following certificate templates, but depending on the DCs operating system version and the CA’s OS version it depends on what they prefer:

Name	Description	Key Usage	Subject Type	Applications used for enhanced key usage	Application policies or enhanced key usage
Domain Controller	Used by domain controllers as all-purpose certificates and is superseded by two separate templates: Domain Controller Authentication and Directory E-mail Replication	Signature and encryption	DirEmailRep	Client authentication Server authentication	4.1
Domain Controller Authentication	Used to authenticate Active Directory computers and users	Signature and encryption	Computer	Client authentication Server authentication Smart card logon	110.0
Directory E-mail Replication	Used to replicate e-mail within AD DS	Signature and encryption	DirEmailRep	Directory service e-mail replication	115.0
Kerberos Authentication	New in Windows Server 2008, this template is similar to the Domain Controller Authentication template and offers enhanced security capabilities for Windows Server 2008 domain controllers authenticating Active Directory users and computers	Signature and encryption	Computer	Client authentication Server authentication Smart card logon KDC authentication	110.0

The Kerberos Authentication template deserves special mention. Again, from TechNet:

Kerberos Authentication Template

The purpose of the Kerberos Authentication template is to issue certificates to domain controllers, which present the certificates to client computers during user and computer network authentication. Certificates issued via this new template contain two specific attributes. Rather than relying on the DNS name of the computer, applications can verify the following:

• The enhanced key usage extension of the certificate contains Key Distribution Center (KDC) authentication.
• The domain name is in the subject alternative name extension of the certificate.

By the authority of the issuing CA, these attributes prove that the computer presenting the certificate is a domain controller for the domain contained in the subject alternative name. This new template is recommended for domain controllers running Windows Server 2008. For domain controllers running Windows Server 2003, the Domain Controller Authentication template or the Kerberos Authentication template can be used.

Client computers running Windows Vista, Windows Server 2008 or later can be configured to check for the new enhanced key usage entry by enabling strong KDC validation on the following registry entry:

HKLMSYSTEMCurrentControlSetControlLsaKerberosParameterskdcvalidation

The default value of 0 disables strong KDC validation. To enable strong KDC validation, set this DWORD value to 2.

The following table shows which certificate template can be used for CAs running different versions of Windows, based on which version of Windows the domain controller is running.

Domain Controller	Windows2000 Server-based CA (version 1 only)	Windows Server 2003-based CA	Windows Server 2008-based CA
Windows 2000 Server (enroll for version 1 templates only)	Domain Controller	Domain Controller	Domain Controller
Windows Server 2003	Domain Controller	Domain Controller or Domain Controller Authentication Directory E-mail Replication	Kerberos Authentication or Domain Controller Authentication Directory E-mail Replication
Windows Server 2008	Domain Controller	Domain Controller or Domain Controller Authentication Directory E-mail Replication	Kerberos Authentication Directory E-mail Replication
Windows Server 2012	Domain Controller	Domain Controller or Domain Controller Authentication Directory E-mail Replication	Kerberos Authentication Directory E-mail Replication

Note

If the CA administrator has not manually assigned the Domain Controller Authentication and Directory E-mail Replication certificate templates to a Windows Server 2003–based CA or a Windows Server 2008–based CA, domain controllers running Windows Server 2003 still use the default Domain Controller certificate template. If a Windows Server 2008–based CA is available and configured to issue the Kerberos Authentication template, a domain controller running Windows Server 2003 or Windows Server 2008 will enroll for a Kerberos Authentication certificate, even if it already has a Domain Controller Authentication certificate.

The Kerberos Authentication certificate template is fully backward-compatible with the previous domain controller templates; for example, when the domain controller has a Kerberos Authentication certificate, smart card logon can be performed even with a client computer running Windows 2000 Professional.

The following table shows the default templates in Windows Server 2008 and Windows Server 2003.

Template name	Windows 2000 Server	Windows Server 2003	Windows Server 2008/2012
Directory E-mail Replication			X
Domain Controller	X	X	X
Domain Controller Authentication		X
Kerberos Authentication			X

Domain Controller auto-enrollment behavior

It depends when Domain Controllers auto-enroll for the different certificates listed in this post. All domain controllers are hard coded to automatically enroll for a certificate based on the Domain Controller template if it is available for enrollment at a certificate authority in the forest. Hard coded in this case means it is in the code, it is not configured in any local or domain based policy. This is one of the few cases where Windows will auto-enroll for a certificate without auto-enrollment being configured in Group Policy. If the Domain Controller certificate template is not available and enhanced logging for auto-enrollment is enabled you will see the following event in the Application log of a domain controller:

Event ID: 47

Message: Certificate enrollment for Local system could not enroll for a DomainController certificate.  A valid certification authority cannot be found to issue this template.

Unless you configure auto-enrollment; that is that. The DC will not auto-enroll for any other certificate on its own. However, if you do enable auto-enrollment, preferably at the domain level so the settings applies to all computers/users in your domain, the behavior changes.

To enable auto-enrollment you need to configure a domain GPO like this:

This will enable auto-enrollment, renew, update and remove certificates and do all these for certificates based on templates.

Now since auto-enrollment is enabled, the Domain Controllers change their behavior. After a new auto-enrollment is triggered we will the the following events (in reverse order) in the Application log of enhanced logging is enabled:

Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a KerberosAuthentication certificate.  A valid certification authority cannot be found to issue this template.

Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a DomainControllerAuthentication certificate.  A valid certification authority cannot be found to issue this template.

Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a DirectoryEmailReplication certificate. A valid certification authority cannot be found to issue this template.

Event ID: 57
Message: The “Microsoft Platform Crypto Provider” provider was not loaded because initialization failed.

Event ID: 56
Message: Certificate enrollment for Local system for the template DomainController was not performed because this template has been superseded.

Let’s look  at these from bottom to top:

ID 56 indicates that the DC has now switched from the hard coded behavior of requesting a certificate based on the Domain Controller template. Since auto-enrollment is now enabled it knows that that certificate template has been superseded. The next events with ID 47 informs us that although the DC would now like to use the new templates, they are not available on any CA in the forest.

As we can see from a previous table in this post, all CAs have the Domain Controller template in their default template list, meaning they can all support the “legacy” hard-coded behavior of any DC to request a certificate based on that template. However, as we have seen, when auto-enrollment is enabled the DC’s preference changes to prefer templates that supersede this template. The Domain Controller E-mail Replication (v2) and Domain Controller Authentication (v2) templates both supersede the Domain Controller (v1) template, and if they are available a DC prefers those. The Kerberos Authentication certificate is even more preferred by DC and they will enroll for a certificate based on this template even if they already have a certificate based on either the Domain Controller (v1) template or the Domain Controller Authentication (v2) template. The Kerberos Authentication certificate is fully backwards compatible with the other templates and can be used for smart card logon. So lets enable the templates and see how the DC’s behavior changes.

First lets enable the legacy Domain Controller template:

On the CA: certutil.exe -SetCAtemplates +DomainController
On the DC: certutil-exe –pulse

This will change nothing since the DC is now configured for auto-enrollment as knows that the Domain Controller Template is superseded. The DC will log a warning that the Domain Controller template has been superseded and the the Domain Controller Authentication, Directory E-mail Replication and Kerberos Authentication templates are all unavailable. So let’s enable the next template; Domain Controller Authentication:

On the CA: certutil.exe -SetCAtemplates +DomainControllerAuthentication
On the DC: certutil-exe –pulse

The DC will now successfully auto-enroll for and receive a certificate based on this template. A new event will be generated in the Application log:

Event ID: 19
Message: Certificate enrollment for Local system successfully received a DomainControllerAuthentication certificate with request ID <#> from certification authority <CA Name>.

Warnings are still generated for the Directory E-mail Replication and Kerberos Authentication template based certs. They are still unavailable.

OK, let’s enable the next template; Directory E-mail Replication:

On the CA: certutil.exe -SetCAtemplates +DirectoryEmailReplication
On the DC: certutil-exe –pulse

The DC will now successfully auto-enroll for and receive a certificate based on this template. A new event will be generated in the Application log.

Event ID: 19
Certificate enrollment for Local system successfully received a DirectoryEmailReplication certificate with request ID <#> from certification authority <CA name>.

Again, there will be warnings for the Kerberos Authentication template certificate.

Last template: Kerberos Authentication:

On the CA: certutil.exe -SetCAtemplates +KerberosAuthentication
On the DC: certutil-exe –pulse

The DC will now successfully auto-enroll for and receive a certificate based on this template, even though it already has certificates based on the Domain Controller Authentication and Directory E-mail Replication templates. A new event will be generated in the Application log:

Event ID: 19
Certificate enrollment for Local system successfully received a KerberosAuthentication certificate with request ID <#> from certification authority <CA name>.

Still, there will be a warning about the Domain Controller template being superseded. This will happen as long as enhanced logging is enabled.

Now the DC will have three certificates based on the Domain Controller Authentication, Directory E-mail Replication and Kerberos Authentication templates. And just to make this perfectly clear; the DC will request always request a certificate based on each of these three templates if they are available.

Tips and tricks

• If your want to check the status of the certificates on your DC; run certutil.exe –DCInfo. It will enumerate all your DCs and check their certificates.
• To reinstall the default certificate templates that come with your version of Windows Server into the Configuration NC; run certutil.exe –InstallDefaultTemplates. Note: this will not set up any CAs to issue any templates, just reinstall the template definitions into your Active Directory forest. To list your current templates from Active Directory; run certutil.exe –Templates.

More information

• Certificate Autoenrollment in Windows XP
• Certificate Autoenrollment in Windows Server 2003
• Troubleshooting (Certificate Autoenrollment in Windows Server 2003)
• Windows XP: Certificate Status and Revocation Checking
• How to troubleshoot Certificate Enrollment in the MMC Certificate Snap-in
• Best Practices Analyzer for Active Directory Certificate Services: Configuration
• Certutil
• How Certificates Work

Oh, and in case you are wondering, the other exception to the default “no auto-enrollment” behavior is EFS, which will always attempts to enroll for the Basic EFS template. The EFS driver generates an auto-enrollment request that Auto-enrollment tries to fulfill.