Uwe Gradenegger - Page 48 - Uwe Gradenegger

Configure the Certificate Enrollment Policy Web Service (CEP) to work with a domain account.

The following describes how to set up a Certificate Enrollment Policy Web Service (CEP) that the service runs under a domain account.

Configure the Certificate Enrollment Policy Web Service (CEP) to work with a Group Managed Service Account (gMSA).

For security reasons, it may make sense to operate the CEP with a Group Managed Service Account (gMSA) instead of a normal domain account. This option offers the charming advantage that the password of the account is changed automatically, and thus this step does not have to be done manually, which is unfortunately forgotten far too often.

Use Authentication Mechanism Assurance (AMA) to secure administrative account logins.

Authentication Mechanism Assurance (AMA) is a feature designed to ensure that a user is a member of a security group only if they can be shown to have logged in using a strong authentication method (i.e., a smart card). If the user logs in via username and password instead, he or she will not have access to the requested resources.

Originally intended for access to file servers, however, AMA can also be used (with some restrictions) for administrative logon. Thus, for example, it would be conceivable for a user to be unprivileged when logging in with a username and password, and to have administrative rights when logging in with a certificate.

Signing in via smart card fails with error message "Signing in with a security device isn't supported for your account."

Assume the following scenario:

A user has a Smartcard Logon certificate and logs on to the Active Directory domain with it.
The login fails. The following error message is returned to the user's computer:

Signing in with a security device isn't supported for your account. For more info, contact your administrator.

View and clear the certificate enrollment policy cache for the Certificate Enrollment Policy Web Service (CEP).

After a certificate enrollment policy is configured and used by a subscriber, the results are cached locally (Enrollment Policy Cache).

If changes are now made to the infrastructure, for example by publishing or removing a new certificate template on a certification authority accessible via Certificate Enrollment Web Service (CES), these changes are not immediately visible to subscribers due to the cache.

For this reason, it may be helpful to view or clear the cache.

Deleting a Manually Configured Certificate Request Policy (Enrollment Policy)

When working with Certificate Enrollment Web Services and manually entering certificate enrollment policies on client computers, one encounters the phenomenon that there is no way to edit or delete them in the Certificate Management Console.

The creation of a certificate enrollment policy for the Certificate Enrollment Policy Web Service (CEP) fails with the error message "This ID conflicts with an existing ID."

Assume the following scenario:

A Certificate Enrollment Policy Web Service (CEP) is implemented in the network.
An enrollment policy is configured.
Testing the connection fails with the following error message:

The URI entered above has ID: "{{GUID}}". This ID conflicts with an existing ID.

Certificate request basics via Certificate Enrollment Web Services (CEP, CES)

With Windows Server 2008 R2 and Windows 7, a new functionality for certificate enrollment has been introduced: The Certificate Enrollment Web Services, which are mapped by two server roles:

Certificate Enrollment Policy Web Service (CEP)
Certificate Enrollment Web Services (CES)

The following is a description of the background to these roles, how they work, and the possible deployment scenarios.

Basics of manual and automatic certificate requests via Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call / Distributed Common Object Model (RPC/DCOM) with the MS-WCCE protocol

The following describes the process that runs in the background when certificates are requested manually or automatically in order to achieve the highest possible level of automation.

Manually running the autoenrollment process

By default, all domain members automatically replicate the Public Key Services object he Active Directory forest through the autoenrollment process. The triggers for this are:

When the user logs in (for computers, when the computer account logs in, i.e. at system startup).
By timer every 8 hours.
When updating group policies, assuming there has been a change.

If you do not want to wait for the autoenrollment to be triggered automatically, you can start it manually. The different ways to run the autoenrollment process are described below.

Associate a universal security group with an Object Identifier (OID) in the Active Directory directory service (Authentication Mechanism Assurance).

Authentication Mechanism Assurance (AMA) provides the ability to tie membership in a security group to enrollment with a smart card certificate containing a specific Object Identifier (OID).

If the user does not log in with the smartcard certificate, but with user name and password, he is also not a member of the security group.

The following describes how to establish the connection between the certificate and the security group.

Configuring a Secure Socket Layer (SSL) Certificate Template for Web Server

Below is a guide to configuring a web server template with recommended settings.

Allowed Relative Distinguished Names (RDNs) in the Subject of Issued Certificates

In principle, the RFC 5280 the use of arbitrary strings in the subject string of a certificate. Common fields in the standard are X.520 described. The Length restrictions are also recommended by the ITU-T. The abbreviations commonly used today are mainly taken from the RFC 4519.

However, Microsoft Active Directory Certificate Services only allows certain RDNs by default.

The following Relative Distinguished Names (RDNs) are accepted by the Active Directory Certificate Services (ADCS) certificate authority by default:

Inspect a certificate request (CSR)

Often, before submitting a certificate request to a certification authority - or before issuing the certificate - you want to verify that it contains the desired values.

The following describes how to achieve this.

Subsequently change the Subject Distinguished Name (DN) of a certificate request (CSR)

Sometimes it is necessary to change the Subject Distinguished Name (also called Subject, Subject DN, Applicant or Subject) of a certificate request before issuing the certificate.

Under certain circumstances, this is certainly possible, as described below.