ADCS

ADCS allows organizations to establish and manage their own PKI to ensure secure communications, authentication and data protection.

ADCS is made of these main components

• CA: Certification Authority, an entity that issues and manages certificates. There can be multiple CAs, organized in a hierarchy to add more layers of "movement" between the end user and the main CA

• Certificate Templates: these templates define settings for a certificate and dictate who can enroll in one, with which permissions and all the other critical information used to successfully push out a valid certificate

• CES: Certificate Enrollment Server, its main role is allowing end users to renew certificates via HTTPS requests by setting up web endpoints for certificate enrollment

• Certificate Enrollment Policy Web Server: allows users to view information about the enrollment policy of a specific certificate

• CA Web Enrollment: empowers hosts that are not domain-joined or running other OSs to renew certificates

• NDES: Network Device Enrollment Service, allows offline network devices to obtain certificates

Certificate Authorities (CAs)

CAs are pivotal entities in the ADCS infrastructure as they issues and manages certificates.

CAs can be organized in hierarchies, with a root CA managing intermediate CAs; this configuration allows to add more "layers" between the users and the root CA.

The root CA issues itself a self-signed certificate using its private key, this certificate called the "root CA certificate" will then be used to sign the certificates requested by the PKI users. The root CA certificates are stored in four main locations:

1. Certification Authorities container: This section defines top-tier root CA certificates, forming the foundation of trust within AD CS environments. Represented as AD objects with the certificationAuthority objectClass, each CA's certificate data resides within this container. Windows machines universally incorporate these root CA certificates into their Trusted Root Certification Authorities store, forming the basis for certificate trust verification.

2. Enrollment Services container: Dedicated to Enterprise CAs enabled within AD CS, this space hosts AD objects for each Enterprise CA. These objects encapsulate key attributes such as pKIEnrollmentService objectClass, cACertificate data, dNSHostName defining the CA's DNS, and certificateTemplates outlining the certificate configurations. Clients within AD interact with these Enterprise CAs to request certificates, adhering to the settings specified in certificate templates. The certificates issued by Enterprise CAs are deployed to the Intermediate Certification Authorities store on Windows machines.

3. NTAuthCertificates AD object: This element defines CA certificates pivotal for authenticating to AD. Identified by the certificationAuthority objectClass, it contains cACertificate properties defining a series of trusted CA certificates. Windows devices in AD networks integrate these CAs into their Intermediate Certification Authorities store. Authentication to AD using certificates necessitates client certificates being signed by one of the CAs listed within NTAuthCertificates.

4. AIA (Authority Information Access) container: Hosting AD objects representing intermediate and cross CAs, this repository aids in validating certificate chains. Each CA, denoted by the certificationAuthority objectClass, contains cACertificate data representing its certificate. These intermediate CAs are deployed to the Intermediate Certification Authorities store on Windows machines, crucial for seamless certificate chain validation within the PKI hierarchy.

Certificates and Certificate Templates

ADCS uses X.509 certificates with the following formats

• PEM: this is the equivalent of a base64-encoded DER certificate, it can store multiple keys with no password protection

• DER: raw PEM certificate

• PFX / P12 (PKCS#12): can store a number of private keys with password protection

• P7B (PKCS#7): used to store multiple chain certificates but not private keys

CAs use certificate templates to look up certificate settings when issuing new certificates for users.

Each certificate (and certificate template) has some main attributes"

• Subject: the entity to which the certificate is issued

• Issuer: usually the CA

• SAN: Subject Alternative Name

• Validity Period

• EKU: Extended Key Use, defines where the certificate can be used

• OID: Object Identifier, indicates the purpose / usage scenarios of a certificate

• Public Key

• NotBefore and NotAfter value to define the certificate's lifespan

• Serial number

• SubjectAlternativeName to specify alternative names associated with the Subject

• Basic constraints to determine whether the certificate is for a CA or a end user and its usage constraints

The following are some common OID used to abuse ADCS misconfigurations

OID	Certificate use
1.3.6.1.5.5.7.3.1	Server Authentication
1.3.6.1.5.5.7.3.2	Client Authentication
1.3.6.1.5.5.7.3.3	Code Signing
1.3.6.1.5.5.7.3.4	Secure Email
1.3.6.1.5.2.3.4	PKINIT Client Authentication
1.3.6.1.4.1.311.20.2.2	Smart Card Logon
2.5.29.37.0	Any Purpose

Enrollment Process and Requirements

Assuming there is at least a CA in the infrastructure, authenticated users can create CSRs (Certificate Signing Request), the CA determines if the client has the right permissions to enroll in the requested certificate, if the permissions match a certificate is generated and signed using the CA's private key before being returned to the user.

Issuance requirements are another important aspect to control enrollment requests. We can access these requirements from the certsrv.msc console (Certificate Templates > Manage > Issuance Requirements).