Active Directory - Page 2 - Uwe Gradenegger

Installation of the default certificate templates fails with error message "This security ID may not be assigned as the owner of this object."

Assume the following scenario:

For the first time, a certification authority (Enterprise Certification Authority) integrated into Active Directory is to be installed in the network.
The rights to install the certificate authority have been delegated to a separate security group or account for security reasons, so no Enterprise Administrator login is required. Put another way: The user used is not a member of the Enterprise Administrators group in the Active Directory forest.
Since this is the first certification authority in the network, no Standard certificate templates installed in the Active Directory. When opening the certificate template management console (certtmpl.msc), one is prompted to install it.
The installation fails with the following error message:

Windows could not install the new certificate templates. This security ID may not be assigned as the owner of this object.

Root certificates are imported on domain members into the certificate store for intermediate certificate authorities

Some will have noticed that the certificate store for intermediate CAs usually also contains certificates for root CAs.

As a rule, this behavior is not critical. In certain cases however, this can also cause problems with applications.

Basics: Replacing (Superseding) Certificate Templates

With the introduction of version 2 certificate templates along with Windows XP and Windows Server 2003, the option was introduced for a certificate template to replace one or more others.

This makes it possible to replace issued certificates with those of another certificate template, or to consolidate multiple certificate templates into a single one.

The local certificate store for trusted root certificate authorities is not synchronized from Active Directory

Assume the following scenario:

A certification authority hierarchy is established in the network and the root certification authority is mapped in the configuration partition of the Active Directory forest.
Domain members are configured to run the autoenrollment process to update trusted root certificate authorities from the Configuration partition.
However, this process does not work for some clients. The root CA certificates are not automatically downloaded and entered into the local trust store.
As a consequence certificate requests can failbecause, for example, the certification authority hierarchy is not trusted.

From Zero to Enterprise Administrator through Network Device Enrollment Service (NDES) - and What to Do About It

In the following, I would like to present a highly dangerous PKI configuration, perhaps not necessarily known to the general public, which can probably be encountered quite frequently in this way in corporate networks.

I show how, by exploiting various unfortunate circumstances in the Windows PKI, it is possible to elevate privileges from mere network access to complete Active Directory takeover.

The initial point of attack in this example is the Network Device Enrollment Service (NDES).

Certificate request fails with error message "The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)."

Assume the following scenario:

An attempt is made to request a certificate from a certificate authority (Enterprise CA) integrated into Active Directory for a user or computer.
The certificate request fails with the following error message:

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE).

Configure a certificate template to use the Microsoft Platform Crypto Provider to enable private key protection through a Trusted Platform Module (TPM).

Since Windows 8, it has been possible for private keys for certificates to be protected with a - if available - Trusted Platform Module (TPM). This ensures that the key is truly non-exportable.

The process for setting up a certificate template that uses a Trusted Platform module is described below.

Signing certificates bypassing the certification authority

Time and again in discussions about the security of a certification authority, it comes up that abuse of the certification authority could be contained by its security settings.

However, the fact that the integrity of a certification authority is directly tied to its key material and can therefore also be compromised by it is not obvious at first glance.

one must think of the certification authority software as a kind of management around the key material. For example, the software provides a Online interface for Certificate Enrollment takes care of the authentication of the enrollees, the automated execution of signature operations (issuing certificates and Brevocation lists) and their logging (Certification Authority Database, Audit log, Event log).

However, signature operations require nothing more than the private key of the certification authority. The following example shows how an attacker, given access to the certification authority's private key, can generate and issue certificates without the certification authority software and its security mechanisms being aware of this.

With such a certificate, it would even be possible in the worst case, take over the Active Directory forest undetected.

When installing an Active Directory integrated certificate authority, the error message "Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)" appears.

Assume the following scenario:

A certification authority (Enterprise Certification Authority) integrated into Active Directory is installed via Windows PowerShell.
Delegated permissions are used to install the certificate authority. Thus, the installing user is not a member of the Enterprise Administrators group.
After running the Role Configuration Wizard, one or more of the following error messages is displayed on the command line:

Setup could not add the Certification Authority's computer account to the Pre-Windows 2000 Compatible Access security group. Certificate managers Restrictions feature will not work correctly on this Certification Authority. To fix this, an administrator must manually add the Certification's Authority's computer account to the Pre-Windows 2000 Compatible Access security group in Active Directory. Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Warning: Setup could not add the certification authority's computer account to the cert Publishers Security Group. This Certification Authority will not be able to publish certificates in Active Directory. To fix this, an administrator must manually add the Certification Authority's computer account to the Cert Publishers security group in Active Directory.  Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Installation of a certificate authority certificate fails with error message "Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)".

Assume the following scenario:

A certification authority (Enterprise Certification Authority) integrated into Active Directory is installed.
Delegated permissions are used to install the certificate authority. Thus, the installing user is not a member of the Enterprise Administrators group.
After the certification authority certificate is issued by the parent certification authority, it is installed to complete the role configuration.
The installation of the certificate authority certificate fails with the following error message:

Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

The display name of a certificate template is not resolved. Only the object identifier (OID) of the certificate template is displayed.

Assume the following scenario:

For a certificate template, only the object identifier is shown, but not the display name and/or
Queries against the certificate authority database contain only the object identifier for the certificate template ("CertificateTemplate" field), but not the display name.

Is there a dependency of the Network Devices Registration Service (NDES) with the NTAuthCertificates object?

The Network Device Registration Service (NDES) has two Registration Authority Certificates. With the enrollment agent certificate, certificate requests are signed and one can use the Configure NDES device template accordingly so that certificates are also only issued if the submitted certificate requests also have a corresponding signature..

Do you plan to use the Certification Authority connected to the NDES remove from the NTAuthCertificates objectThe question may arise as to whether mutual dependencies need to be taken into account here - after all, this requires Enroll on Behalf Of (EOBO) the presence of the certificate authority certificate in NTAuthCertificates.

Overview of Active Directory events relevant for PKI

The following is an overview of the events generated on domain controllers in the Windows Event Viewer that are relevant to the public key infrastructure.

Force domain controller (or other participants) to use an online responder (OCSP)

By default, Windows systems, even if an online responder (OCSP) is configured, will be sent to a certain number of OCSP requests fall back to a (if available) brevocation list, because this is usually more efficient in such a case. However, this behavior is not always desired.

For example, if one uses smart card logins, one might want to know if Logins were executed with unauthorized issued certificates. In conjunction with the deterministic good of the online responder you can thus create an (almost) seamless Audit trail create for all smartcard logins.

Details of the event with ID 32 of the source Microsoft-Windows-Kerberos-Key-Distribution-Center

Event Source:	Microsoft Windows Kerberos Key Distribution Center
Event ID:	32 (0x80000020)
Event log:	System
Event type:	Warning
Event text (English):	The Key Distribution Center (KDC) uses a certificate without KDC Extended Key Usage (EKU) which can result in authentication failures for device certificate logon and smart card logon from non-domain-joined devices. Enrollment of a KDC certificate with KDC EKU (Kerberos Authentication template) is required to remove this warning.
Event text (German):	The Key Distribution Center (KDC) uses a certificate without Extended Key Usage (EKU) for the KDC. This can lead to authentication errors during device certificate enrollments and smart card enrollments of devices without domain affiliation. Enrollment of a KDC certificate with KDC EKU (Kerberos authentication template) is required to eliminate this warning.