Active Directory Certificate Services (AD-CS)

Last updated: August 28, 2024
Audience: IT Staff / Technical

This page documents the capabilities provided by the Microsoft Infrastructure related to certificate services.

Background

The UW has other certificate service options, provided by the Certificate Services service. The options provided which are not deprecated include:

  • The InCommon Certificate Authority (CA) which provides Web server SSL certificates appropriate for an external customer base that are trusted by all major browsers, available via a self-service interface

These other options require the customer to create a certificate request, submit it manually, wait some period of time (usually less than an hour), manually retrieve the signed cert and install it. Issued certificates expire and must be manually requested again–they do not renew.

The AD-CS service option has the following notable differences:

  • Intended for Windows computers that are domain-joined to the NETID domain, with a certificate request process that is entirely automated. For more details on this, see the How to Use this Service Option section.
  • Certificates automatically are renewed before they expire. For more details on this, see the Support section.
  • For Windows computers that are domain-joined, this CA is automatically trusted. Use with other computers and services will require manually adding the CA cert to establish trust. For more details on this, see the Infrastructure Details section
  • SHA256 algorithm (RSA 2048 bit) used to sign certs

Initially, we are releasing a single general purpose computer certificate template for auto-enrollment, which is good for client or server authentication, with digital signature and key encipherment, and a common name derived from the computer’s dnsHostname attribute value.

While the initial offering of this service option is limited in scope to delegated OU customers, we believe that scope could expand. AD-CS will consider issuing any certificate type and in addition to the standard set of certificate templates that Microsoft provides, we are willing to consider custom certificate templates. Allowing non-Windows clients  and cross-forest are possible future extensions. Submit a request at help@uw.edu with AD-CS in the subject line to discuss future possibilities.

NOTE: UW-IT reserves the right to revoke any certificate to protect the UW’s interests. We plan to revoke any certificate issued to a CN with netid.washington.edu in it. Naming a computer with netid.washington.edu as the DNS suffix violates the computer naming guidance for computers joined to the NETID domain.

How to Use This Service Option

Each delegated OU can choose to optionally add computers in their OU to a group for which they are the member managers. Membership in the group will trigger the Windows certificate agent to look for certificate templates they are allowed to auto-enroll for. The certificate agent then submits a request for the cert(s), the CA approves/signs the cert(s), and the certificate agent stores the cert in its certificate store.

We’ve limited which certificates are available so that initially only the single certificate described above is available. We’ve also designed this offering so that you can only choose to opt-in computers in your own OU–no one else can opt your computers in.

To get a certificate issued, a delegated OU admin would add computers to u_msinf_delou_<ou>_computers_adcs-autoenroll, where <ou> is your delegated OU name. Note that u_msinf_<ou>_oucontacts are member managers of this group, with UW-IT retaining administrator privileges. Also note that this group has a membership dependency on u_msinf_<ou>_computers, which is the set of all computers in your OU.

For more detailed technical information on how the certificate enrollment process works, see the Troubleshooting Help section.

Support

The UW Microsoft Infrastructure service supports the AD-CS certificate authorities used to provide this capability. You support the client computers using this capability. We have extensive troubleshooting guidance below which we encourage you to use. You can and should submit a request to help@uw.edu with AD-CS in the subject line if you have a certificate problem you need help with, however, if the problem is on the client-side, our assistance is limited.

Troubleshooting Help

A lot happens under the covers to enable the magic of automated certificate enrollment, and to be comprehensive would mean this section would be very lengthy.

Note that there are three key components which enable the magic of automated certificate enrollment:

  • Computer is Windows with certificate services running
  • Computer is domain joined
  • Computer is in one of the u_msinf_delou_<ou>_computers_adcs-autoenroll
    • Note: this group grants adequate permissions (AutoEnroll)
    • Note: this group allows the group policy object linked to NETID domain root entitled “AD-CS Auto-enrollment” to enable Windows settings that allow the computer to request & auto-renew any certificate template for which that computer has the AutoEnroll permission

Some general help:

  1. Use the Certificates MMC to review existing certs. You can also choose the new certificate wizard to manually see what errors might be exposed.
  2. Enable cert logging on the client
  3. Manually trigger the cert enrollment process
  4. Check logs for error messages
  5. Use the error to identify the problem and fix it

To enable cert logging:

In HKCU\Software\Microsoft\Cryptography\Autoenrollment and HKLM\Software\Microsoft\Cryptography\Autoenrollment, create a new DWORD value named AEEventLogLevel and set its value to 0.

To manually trigger auto-enrollment:

gpupdate /force

To check logs for error messages:

In the Application event log, refresh the log to see what happens during autoenrollment.

Two computer autoenrollment messages (start, stop) should occur first, followed by two user autoenrollment messages (start, stop) in 30 sec. – 2 minutes. Any issued certs should appear in the log as Event ID 18’s or 19’s. Stop and Start messages are event IDs 2 and 3.

To dig deeper, we recommend reviewing:

 

as they are two excellent detailed descriptions oriented at troubleshooting that get at what might go wrong.

Known Problems and Workarounds

Problem
Background
Workaround(s)
The client computer may not have auto-enrollment enabled By default, any computer that is added to one of the u_msinf_delou_<ou>_computers_adcs-autoenroll groups will have a GPO at the NETID domain root applied which enables this.
  1. Your computer may not have been rebooted since it was added to the group. Reboot.
  2. Some OUs block GPO inheritance which means you will need to either apply a similar GPO or manually enable that setting. See http://social.technet.microsoft.com/wiki/contents/articles/3048.troubleshooting-certificate-autoenrollment-in-active-directory-certificate-services-ad-cs.aspx.
  3. Some computers have group policy problems which you will need to resolve. Or the group policy hasn’t yet applied.
The client has connectivity issues reaching the issuing CA or AD which prevent a cert request/enrollment A restrictive firewall or not being connected to the UW network will mean the client is unable to contact the NETID domain for certificate templates or the netid-issuing-CA to request and receive a cert.
  1. Use a VPN to get on a UW network which does have connectivity to the NETID domain and the netid-issuing-CA.
  2. If a firewall is the problem (see http://blogs.technet.com/b/askds/archive/2007/11/06/how-to-troubleshoot-certificate-enrollment-in-the-mmc-certificate-snap-in.aspx for how you’d determine that), then reconfigure the firewall.
  3. Wait until you are on a UW network which has connectivity and plan your UW network connectivity so renewals can regularly happen.

 

Infrastructure Details

This is a 2-tier certificate authority with an offline root CA.

An AD root CA named netid-root-CA is AD published, meaning domain-joined computers trust it by default. This is currently shroud.netid.washington.edu. This CA is offline to provide greater security but is brought online to republish the certificate revocation list (CRL).

An AD integrated issuing CA named netid-issuing-CA is AD published, meaning domain-joined computers trust it by default and it can issue certificates. This is currently fulcrum.netid.washington.edu.

If you need to get a copy of the CA certs, they are available at:

Note: our older/retired CA certs are also still available at:

At this time, we are not providing AD-CS web services (this provides a web service API to request and retrieve certs which enables non-Windows and cross-forest client scenarios). This means clients are limited to those which are domain-joined and leverage the secure-channel trust provided within a forest.

More Details

netid-root-CA

CDP config:

CRL publishing schedule: 5 years

Publish CRLs and Delta CRLs to this location:

http://thrawn.uw.edu/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

AIA config:

ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>

http://thrawn.uw.edu/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

netid-issuing-CA

CDP config:

CRL publishing schedule: 1 week

Publish delta CRLs: 1 day

Publish CRLs and Delta CRLs to this location (no line break):

ldap://CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,
CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

http://thrawn.uw.edu/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

AIA config:

ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>

http://thrawn.uw.edu/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt