Certificate Enrollment using Active Directory Certificate Services
In this article, we will discuss Certificate Enrollment using Active Directory Certificate Services. Active Directory Certificate Services (AD CS) is a Microsoft product that performs public critical infrastructure (PKI) functionality, supports personalities, and provides other security functionality in a Windows environment. It creates, approves, and rejects public key endorsements for inward tasks of an association.
As per Microsoft, AD CS is a “Server Role that enables you to construct public key infrastructure (PKI) and give open key cryptography, computerized authentication, and advanced mark abilities for your association.”
Active Directory Certificate Services (AD CS)
Microsoft’s AD CS provides a platform to build and implement digital certificates. AD CS is linked to Active Directory, a Windows server that acts as a database. Microsoft has periodically released new servers to stay up to date with the expanding certificate environment. AD CS PKI role can integrate with AD domain servers to set up auto-enrollment configuration policies.
Certificates have proven to be more secure and easier to use than passwords. Microsoft realized this and deployed AD CS to help Microsoft environments take advantage of certificate benefits. NDES uses the SCEP gateway so devices without credentials are able to enroll for certificates. End users can request multiple certificates with one or no passwords.
Certificate Enrollment
Digital certificates are used to protect things like web servers through device authentication and data encryption. Many organizations choose to narrow the scope of the certificates they manage rather than take on the task of securing everything. Manually issued certificates get all the attention (i.e. SSL/TLS certificates), while auto-enrollment certificates are easily overlooked.
Auto-enrollment automates the issuance of certificates to the Microsoft certificate store on Windows PCs and servers. Active Directory Certificate Services (ADCS) is enabled by Group Policy (GPO), which allows users and devices to enroll for certificates. In most cases, there’s no user interaction required. It also allows certificates to be automatically renewed and updated.
Importance of Certificate Enrollment
Certificate auto-enrollment must be part of your overall PKI planning if you want to avoid future problems down the line.
You must be able to report on the security profile for your entire certificate landscape, which of course includes auto-enrolled certificates. As cryptographic standards evolve, there is a constant need to audit your issued certificates and identify any that are out-of-policy or using outdated keys or algorithms. Having the ability to quickly identify and re-issue these non-compliant certificates in bulk can prevent disruptive situations that require remediation.
Group policies drive the issuance and usage of auto-enrolled certificates, requiring regular changes and updates over time. In a high-volume PKI environment, a minor misconfiguration can lead to a large-scale issue. This is where setting issuance thresholds on your Microsoft CA and continuously monitoring your certificate landscape can help you get in front of rogue or non-compliant certificates.
The impact of an expired certificate can range from a minor inconvenience for a single user to a widespread or mission-critical application outage. Auto-enrolled certificates sometimes fail to renew, which can be difficult to catch. This is where monitoring tools can provide alerts about upcoming expirations and prevent downtime that could affect the patient’s life.
Active Directory Certificate Services Installation Requirements
Some of the Active Directory Certificate Services best practices to installation AD CS are mentioned below:
- The administrator who does enrollment must be a member of the Enterprise Admins group and must have Request Certificates permissions on the target certification authority (CA).
- That computer must be a member of the domain.
- An AD DS forest with at least a Windows Server 2008 R2 schema.
- For automatic renewal of certificates across AD DS forests, the CA must be installed on a computer running Windows 8 or Windows Server 2012.
- If the CA is configured for client certificate authentication, the server must be running at least Windows Server 2008.
- For automatic renewal of certificates across AD DS forests, the CA must be installed on a computer running Windows 8 or Windows Server 2012.
- A Server Authentication certificate was installed for HTTPS.
Certification Authority Configuration
If the CA role service is installed on a local computer, then the local computer is automatically selected as the CA.
- It can be configured to work with an enterprise CA on the same or on a different computer running at least Windows Server 2003.
- The Certificate Enrollment cannot be configured to work with a stand-alone CA, so an enterprise CA is required.
- A CA on a computer running Windows Server 2003 will not work as the targeted CA of an enrollment service that is configured for client certificate authentication.
- Running the enrollment service in renewal-only mode requires a CA on at least Windows Server 2008 R2.
Authentication Type
Clients communicating with the Certificate Enrollment must use one of the following authentication types:
- Windows integrated authentication, also known as Kerberos authentication
- Client certificate authentication, also known as X.509 certificate authentication
- Username and password authentication
- If you want to enable key-based renewal, you must enable client certificate authentication for the Certificate Enrollment.
- Anonymous authentication to the services is not supported.
Key-Based Renewal
Key-based renewal mode is a feature introduced in Windows Server 2012 that allows an existing valid certificate to be used to authenticate a certificate renewal request. This enables computers that are not connected directly to the internal network the ability to automatically renew an existing certificate. To take advantage of this feature, the certificate client computers must be running at least Windows 8 or Windows Server 2012.
Service Account Configuration
During Certificate Enrollment configuration, you have the option to specify one of the following types of accounts as the service account:
- The user account that acts as the service account (recommended)
- Built-in application pool identity of the Internet Information Services (IIS) installation on the local computer.
Configuring a specific user account as the service account is the recommended configuration. The user account that is to be configured as a service account must be:
- A domain account in the domain in which the Certificate Enrollment computer is a member.
- A member of the local IIS_IUSRS group.
- Configure with a service principal name (SPN) or Kerberos authentication is selected.
Server Certificate Selection
The Certificate Enrollment and the Certificate Enrollment Policy must use Secure Sockets Layer (SSL) for communication with clients (by using HTTPS). Each service must have a valid certificate that has an enhanced key usage (EKU) policy of Server Authentication in the local computer certificate store.
Suppose you have not yet provided an SSL certificate to the server that is hosting the Certificate Enrollment. In that case, you can do so by following the instructions in the article Configure SSL/TLS on a Web site in the domain with an Enterprise CA.
Certificate Enrollment using Active Directory Certificate Services
There are many components involved in running a certificate-based network. You need to establish trusted servers and certificate authorities (CA), make sure devices can enroll for certificates, authenticate users, manage the certificate life cycle, and much more. Microsoft offers their own CAs so Microsoft-based environments can implement a Public Key Infrastructure (PKI).
After reading this article, now you know the introduction, importance, and the guide to Certificate Enrolment using Microsoft’s Active Directory Certificate Services.
