A new automated X.509 certificate enrollment and issuance capability is now available to delegated OU customers.
What and When:
Delegated OU customers can use the group service to cause a X.509 certificate to be automatically issued to a Windows computer in their delegated OU. Other than adding the computer to the group, there is no manual effort required, and the certificate will be automatically renewed when it approaches its end date.
The Certificate Authority which issues the certificate is not signed by a publicly trusted root CA but is trusted by all computers joined to the NETID domain. This CA meets the same kinds of use cases as the “UW CA”, but there is no labor involved in certificate deployment and none of the ugly certificate expiration problems, so we believe you’ll find this highly useful as an IT cost-savings measure.
What You Need to Do:
If you’d like to make use of this new capability, we’d recommend you read https://wiki.cac.washington.edu/x/_69NB, especially the ‘How to Use this Service Option’ section.
More Information:
Behind the scenes, the group membership change triggers application of a domain GPO which enables auto-enrollment on that computer, and grants the autoenroll permission to a specific certificate. The client computer does a little dance with AD to find issuing CAs and templates it has permissions for, and requests all certificates for which it is entitled via an RPC connection to the CA. The CA automatically approves/issues the requested cert and the client computer places the cert in its local certificate store.
It’s pretty neat stuff that seems like magic compared to the highly manual certificate process involved with the UW CA and InCommon CA that consumes lots of time.
There’s lots more information at the customer documentation URL above.
As noted previously, if you have another use case you’d like to explore, let us know.
We are exploring a couple use cases for the future, including a custom template paired with auto-enrollment, possibly leveraging this new infrastructure to enable a multi-factor authentication solution like Microsoft Passport, and will also consider adding a web service enrollment agent which would allow non-Windows and non-domain joined computers to get in on the automated goodness. J
Brian Arkills
UW Windows Infrastructure Service Manager
UW-IT
From: Brian Arkills Sent: Friday, December 18, 2015 9:57 AM To: ‘uwwi-announce@uw.edu’ <uwwi-announce@uw.edu> Subject: new domain GPO
A new group policy object at the root of the NETID domain is being created. This GPO will only apply to computers which are opted into applying it.
What and When:
Today UWWI will create a new GPO called ‘AD-CS Auto-enrollment’ at the domain root.
This GPO will enable auto-enrollment for the certificate services client. This GPO will only apply to computers which:
- Are members of the group u_windowsinfrastructure_adcs_autoenroll
- Do not have GPO inheritance blocking.
What You Need to Do:
Nothing. There is no immediate impact to you.
At this time, none of your computers are affected. You may choose to opt your computers into this as part of the emerging Active Directory Certificate Services (AD-CS) service option. More on this is forthcoming.
More Info:
The specific setting in this GPO is:
Computer/Policies/Windows Settings/Security Settings/Public Key Policies/Certificate Services Client – Auto-Enrollment Settings/
Automatic certificate management=Enabled
Enroll new certificates, renew expired certificates, process pending certificate requests and remove revoked certificates=Enabled
Update and manage certificates that use certificate templates from Active Directory=Enabled
Enabling this client computer setting is required to provide the AD-CS service option with auto-enrollment. We’ve purposely scoped this change so you retain management of your computers; you need to take an action for this computer configuration to affect you. Our goal is to respect your autonomy in how you manage your computers. However, it makes a lot of sense to have a single toggle which enables a desired outcome, so we’ve designed this mechanism in such a way that your intention and the desired outcome is directly connected.
Put in a more concrete way, in the future, you may choose to have some of your computers automatically get a certificate by adding them to a group. By adding them to this group, you’ll be allowing this GPO to configure the client-side setting and allow access to a specific certificate template. The end result will be that those computers will automatically end up with a certificate. J
If you have computers in an OU which blocks inheritance, there are workarounds that are in our customer documentation, so no worries.
We’re pretty close to releasing this new service option, and will be sending a little more info to the uwwi-discuss@uw.edu mailing list for eager folks to kick the tires. You can expect further details here soon. For your benefit, below I’ve included the prior change we made to enable this emerging service option.
If you have questions about this change, please send an email to help@uw.edu with “UWWI AD-CS autoenrollment change” in the subject line.
Brian Arkills
UW Windows Infrastructure Service Manager
UW-IT
From: Brian Arkills Sent: Monday, November 2, 2015 1:09 PM To: ‘uwwi-announce@uw.edu’ <uwwi-announce@uw.edu> Subject: Certificate services for delegated OUs
The UW Windows Infrastructure has deployed a public key infrastructure consisting of a 2 tier certificate authority, whose initial purpose is to provide automatic certificate enrollment and certificate deployment for delegated OU computers running Windows.
What and When:
On 10/16/2015, UWWI deployed an Active Directory published root certificate authority named netid-root-CA. Being AD published means that domain-joined computers trust it by default.
On 10/23/2015, UWWI deployed an Active Directory integrated issuing certificate authority named netid-issuing-CA. Being AD integrated means that:
- domain-joined computers trust it by default,
- domain users and computers can request and retrieve certificates from it, leveraging the secure channel trust already in place
- issued certificates can be published to the appropriate AD object (which enables a variety of uses)
- certificate revocation lists are published to AD, enabling domain-joined computers to reliably determine whether a given certificate is still valid
Like the UW Services CA, these certificate authorities are not publicly trusted. This limits their usefulness to UW internal purposes—for example, you wouldn’t use this CA to enable HTTPS for a public website.
In the near future, on a per OU basis, we’ll provide a group which OU admins will be member managers for. You can add computers as members to this group to direct them to automatically enroll for a “Computer” certificate, with client authentication and server authentication uses. Unlike most other certs you’ve used, these certs automatically get renewed, and require no further human involvement. More details on the nature of these certs is available below. More details on this coming capability will be shared when this is ready.
What You Need to Do:
At this time nothing. We wanted to let security conscious customers know that we changed the certificate authority trust of domain-joined computers intentionally as part of a planned release. We’ve mentioned this intention several times over the last year, and the deployment of capabilities is now approaching.
We’ll let you know when we have enabled this new capability for your OU. At that time, you can add computers to a group and get automatic certificate enrollment to these computers.
More Info:
This capability was added due to strong customer interest in lowered costs for certificate management. Based on customer need analysis, there were enough internal-only uses and cost-savings to move forward, even though this may make the UW certificate story a little more complicated. Given how handy an AD integrated CA is, we believe there will be more use cases identified and future capabilities–in fact, there is currently customer interest in exploring three other use cases. More information on these use cases and future capabilities will be coming over the next few months.
Do be aware that for UW internal use cases you may need to ask a service to trust the netid-root-CA and netid-issuing-CA in order to leverage the client authentication capability. For example, the Groups Web Service does not currently trust these certificates.
If you need to get a copy of the CA certs, they are available at:
http://thrawn.uw.edu/CertEnroll/cracken.netid.washington.edu_netid-issuing-CA.crt
http://thrawn.uw.edu/CertEnroll/madine.netid.washington.edu_netid-root-CA.crt
Additional details on the “Computer” certificate:
Validity: 1 year
Renewal: 6 weeks
Private key is not exportable
Minimum key size of 2048
Subject name is based on dnsHostname attribute of AD computer object
Additional technical details on the two new certificate authorities:
Both are implemented in a manner such that if we later needed to, we can meet FIPS compliance, although at this time we are not using a HSM module for private key storage. The root CA is designed to be an “offline” CA hosted in Azure, brought online at least once a year to republish the certificate revocation list (CRL). Hosting this CA in Azure allows us to save costs since it is offline most of the time, and their hosting practices are as good or better than ours (e.g. they have rolling audits to meet various regulatory certifications). We are hoping that in the future Microsoft provides a virtual HSM capability for AD-CS integrated with its Azure Key Vault.
Brian Arkills
UW Windows Infrastructure Service Manager