Many companies use Windows servers as the main component of their IT infrastructures. If those companies want to use digital certificates for their network, they set up a public key infrastructure (PKI). PKIs deploy and manage certificates, which can be used for network security, device authentication, and much more.
Active Directory Certificates Services (AD CS) is Microsoft’s on-premise PKI solution that has been around for some time. However, AD CS can be tricky and many IT admins have run into several problems when managing PKI and certificates.
Organizations running on Microsoft environments can use a Microsoft Certificate Authority (CA) to leverage Active Directory (AD) and AD CS to distribute certificates to all your domain-connected devices through group policies. Although, if you have have managed devices through an MDM, you don’t necessarily need AD CS to provision certificates to devices.
Nevertheless, here are some best practices to follow if your organization uses AD CS.
Issuing AD CS Certificates to BYODs
AD CS only works natively with Microsoft Group Policy (GPO) to deploy certificates on AD-managed devices, leaving BYODs with no onboarding solution. Because of this, organizations often find enrolling and configuring BYOD devices for AD CS certificates to be a major pain point.
We recommend using onboarding software, like SecureW2’s JoinNow solution. This allows any BYOD devices to safely and easily self-service their devices to enroll for AD CS certificates.
Issuing AD CS Certificates on Managed Devices
Most MDMs will have issues trying to push out certificates on their devices because AD CS only natively integrates with GPO. Fortunately, you don’t have to manually setup each and every one of your devices for a certificate, because a technology called SCEP.
Simple Certificate Enrollment Protocol (SCEP) is one of the most commonly used methods of auto-enrolling managed devices for certificates. It allows managed devices to communicate directly with a PKI without requiring any human interaction. Below is a diagram of how the SecureW2 SCEP Gateway API can be used to push out AD CS certificates to Managed Devices.
You can also use Microsoft’s WSTEP protocol to achieve a similar outcome through GPO. Many customers enjoy the flexibility that our Gateways offer them so they can easily support all their devices, regardless of the MDM.
Don’t Use Default AD CS Certificate Templates
Before using AD CS certificate templates, you need to create a plan so you’re only deploying templates that are necessary. These templates are designed as building blocks for you to duplicate. Only modify the duplicated templates and leave the main ones alone because you cannot create new ones.
Mark the duplicates with some sort of identifier, like the name of your organization so you can easily identify them and group together.
Enterprise Admins are able to manage certificate templates by default. To change this, you need to create a security group and adjust role separations so only admins you have approved can have access. This is essential because misconfiguring your security settings can enable any end user to access any type of certificate or even create their own certificate, opening the door for theft.
AD CS Certificate Lifecycle Management
Expiration Notification
In Group Policy, you can set up an Auto-Enrollment Policy, so that your AD-Domain managed devices will renew your certificate before expiration. The downside is this policy only works for AD managed devices. SecureW2 can integrate with all MDMs, so you can deploy this policy on all devices.
SecureW2’s software will email the user when a certificate is close to expiration. At least six email notifications will be sent out in intervals, starting at 60 days out and ending 1 day before certificate expiration. Certificates can be easily renewed without any interruption.
Certificate Renewal Process
Microsoft provides certificate auto-enrollment that can be configured with GPO. This allows devices to automatically enroll for a new certificate when the current one is about to expire. In order for this to work, you need to configure an auto-enrollment policy and certificate templates. Templates need to be set with the correct permissions, such as Read and Enroll, for this to work. Use security groups if you are granting template permissions. Once the templates have been configured, add them to your Enterprise CA so autoenrollment can begin.
However, the auto-enrollment process can only be done with GPO and AD CS certificate templates. If you have any non AD devices or MDMs, SecureW2’s software can integrate with any MDM (Jamf, Airwatch, Mobile Iron..etc) and push out renewal policies.
Configuring AD CS Certificate Expiration
Microsoft CA’s use templates for certificate validity and the 2000 and 2003 servers don’t allow validity template modification.
With SecureW2, certificate templates can be configured so certificates stay valid for any number of years. You could easily set up group policies so when users enroll for a certificate automatically issue 4 year certificates to students, and 8 year certificates to faculty and staff.
Using Private Keys in AD CS
AD CS – Storing Private Keys
In order to store private keys on AD CS, you will need a Key Recovery Agent. You can have one issued with a certificate template. The template also can be used to archive the private keys.
All private keys are backed by a Hardware Security Module (HSM) at SecureW2, which protects and manages your digital keys in the most secure way. HSMs vastly improve the security of a PKI and are essential when protecting your network with certificates.
AD CS – Exporting Private Keys
AD CS gives you the option to “Mark Private Key as Exportable” which should always be turned off. If it’s turned on, any user who has access can export that particular private key. If you don’t have your security groups set up, any user on the network can access this. Do not have this option turned off unless you have a good reason.
However, configuring this correctly in AD CS doesn’t ensure that all devices can’t export their private keys. That’s why SecureW2 developed technology that prevents private keys from being exported from devices, ensuring that certificates aren’t in the wrong hands and that every certificate represents an accurate identity.
Configuring AD CS with Microsoft Azure
Azure only has limited access to AD CS, so you’ll only be able to use a standalone CA for integration purposes, so one will need to be installed if not already. After the standalone CA is installed, the root CA will need to be imported as a trusted authority for your domain. Group Policy Management will need to be installed in order to import the root CA if you haven’t done so. With all these in place, you are able to configure the settings to integrate Azure on AD CS.
Building on AD CS can seem counterintuitive since Azure is cloud-based and AD CS requires on-prem AD domain hardware. If you’re wanting to migrate to the cloud, check out our Azure integration page for WPA2-Enterprise.
Deploying AD CS Certificates with SecureW2
While AD CS is a useful tool for AD-domain PKI management, organizations that aren’t completely built on Microsoft environments will face numerous issues. Employing these practices will make AD CS easier, but integrating your network with SecureW2 is a cost-effective solution that enhances user experience and network security.
