IT Connect

Information technology tools and resources at the UW

Active Directory Certificate Services (AD-CS)

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

Background

The UW has two other certificate service options, provided by the Certificate Services service. Those options 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
  • The UW CA provides client certificates trusted by some UW services including UW Enterprise web services and some directory services, available via a self-service interface

Both of those 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.

This service option has the following notable differences:

  • Initially 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, UWWI is 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 should and will 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. User certificates are a likely extension of this service option in the next year to enable multi-factor solutions on the Windows platform. We also suspect allowing non-Windows clients (to provide an automated request solution) and cross-forest are possible future extensions. Submit a request at help@uw.edu with UWWI 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_windowsinfrastructure_adcs_<ou>_computers_autoenroll, where <ou> is your delegated OU name. Note that u_windowsinfrastructure_<ou>_oucontacts are member managers of this group, with UWWI retaining administrator privileges. Also note that this group has a membership dependency on u_windowsinfrastructure_<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 Windows 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 UWWI 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. However, in general you will be doing the following:

  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_windowsinfrastructure_adcs_<ou>_computers_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 certificate CA named netid-root-CA is AD published, meaning domain-joined computers trust it by default. This is currently madine.netid.washington.edu. This CA is offline to provide greater security but is brought online at least once a year to republish the certificate revocation list (CRL).

An AD integrated issuing (enterprise subCA) is AD published, meaning domain-joined computers trust it by default and it can issue certificates. This is currently cracken.netid.washington.edu.

If you need to get a copy of the CA certs, they are 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 those which are domain-joined which leverage the secure-channel trust provided within a forest.

More Details

netid-root-CA

CDP config:

CRL publishing schedule: 1 year

Publish 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 Delta CRLs to this location:

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