Recover an ADCS platform from compromise
Published May 21 2024 09:30 AM 4,170 Views
Microsoft

The crucial role of backup and restore in ADCS

Active Directory Certificate Services (ADCS) serves as a pivotal part within identity and access management (IAM), playing a critical role in ensuring secure authentication and encryption. These functionalities are integral for fostering trust across the enterprise application and service ecosystem. In modern organizations, the significance of Active Directory Certificate Services has grown exponentially, fortifying digital identities, communication channels and data. Given its pervasive role, the potential loss of this service due to systemic identity compromise or a ransomware attack could be catastrophic. Microsoft advocates platform owners adopt an "assume breach" mindset as an initiative-taking measure against these sophisticated cybersecurity threats to ensure and preserve confidentiality, integrity, and availability of IAM based services. 

 

As part of an "assume breach" approach, organizations must prioritize comprehensive backup and restore strategies within their ADCS infrastructure. These strategies are paramount for ensuring swift recovery and restoration of essential certificate services following a cyberattack or data breach. By keeping up-to-date backups and implementing effective restoration procedures, organizations can minimize downtime, mitigate potential damage, and uphold operational continuity amidst evolving security challenges. 

 

Let us look at some of the services and features of an ADCS platform which organizations are dependent on: 

 

  • Certificate enrollment and renewal: ADCS facilitates automated enrolment and renewal processes, ensuring prompt issuance and rotation of cryptographic keys to maintain security. 
     
  • Key archival and recovery: Organizations can utilize ADCS to archive private keys associated with issued certificates, enabling authorized personnel to recover encrypted data or decrypt communications when necessary. 
     
  • Certificate revocation and management: ADCS provides mechanisms for revoking and managing certificates in real-time, allowing organizations to promptly respond to security incidents or unauthorized access attempts. 

 

  • Public Key Infrastructure (PKI) integration: ADCS seamlessly integrates with existing PKI infrastructures, enabling organizations to use established cryptographic protocols and standards to enhance security across their networks. 
      
  • Enhanced security controls: ADCS offers advanced security controls, such as role-based access control (RBAC) and audit logging, empowering organizations to enforce granular access policies and keep visibility into certificate-related activities.

Now that we know what this service offers, imagine your organization as a fortified stronghold, wherein Active Directory Certificate Services and Active Directory Domain Services form the bedrock of the Identity and Access Management infrastructure. In case of a cybersecurity breach penetrating this stronghold, the backup and restoration process acts as a crucial defensive measure. It is not merely about restoring ADCS services: it is about swiftly and effectively rebuilding the stronghold. This guarantees the continuation of trust relationships and the seamless operation of vital IT services within the stronghold, such as remote access VPNs, consumer web services, and third-party self-service password reset tools—each of which are essential components for operational continuity, customer experience and business productivity. Without effective backup measures, the stronghold is vulnerable, lacking the protective mechanisms akin to a portcullis or moat. 

 

The significance of thoroughly assessing all backup and recovery procedures cannot be overstated. This is akin to conducting regular fire drills, ensuring that the IT team is adept and prepared to respond to crises effectively. IT administrators must have the requisite knowledge and readiness to execute restoration operations swiftly, thereby upholding the integrity and security of the organization’s IT environment. Additionally, recognizing the potential exploitation of ADCS for keeping persistence underscores the imperative for vigilance in monitoring and securing ADCS components against unauthorized manipulation or access.  

What are the key elements for a successful backup and recovery?

From a technical perspective, Active Directory Certificate Services (ADCS) backups must cover the foundational pillars of the service. These include the private key, the Certificate Authority (CA) database, the server configuration (registry settings) and the CAPolicy.inf file. Let us explain each in detail:

  • CA private key: The most critical logical part of a CA is its private key material. This key is stored in an encrypted state on the local file system by default. The use of devices like Hardware Security Modules (HSMs) is encouraged to protect this material. The private key is static, so it is recommended to create a backup directly after the deployment and to store it in a safe, redundant location.

  • CA database: By default, this repository holds a copy of all issued certificates, every revoked certificate, and a copy of failed and pending requests. If the CA is configured for Key Archival and recovery, the database will include the private keys for those issued certificates whose templates are configured for the feature.

  • Server configuration: These are the settings and configurations that dictate ADCS operations. From security policies to revocation lists settings, safeguarding the server configurations ensures that the ADCS can be restored with identical functionality.

  • CAPolicy.inf: The CAPolicy.inf file is used during the setup of ADCS and then during CA certificate renewal. This file may be used to specify default settings, prevent default template installation, define the hierarchy, and specify a Certificate Policy and Practice Statement.

How is ADCS backed up?

A practical approach to performing a backup involves utilizing 'certutil,' a command-line tool integrated into the Windows operating system. This tool offers a range of functions tailored for managing certificates and certificate services. Other methods encompass employing the graphical user interface (GUI) or PowerShell. To start a backup of the CA database using 'certutil,' adhere to the outlined example below:

 

 

 

certutil -backupdb -backupkey "C:\BackupFolder"

 

 

 

The command syntax is as follows:

 

  • backupdb: Starts the backup process for the database.
  • backupkey: Safeguards the private key of the CA (requires providing a password).
  • C:\BackupFolder: Specifies the path where the backup will be stored. It is important to use a secure location, ideally on a separate drive or device. Note: this folder must be empty.

Running this command starts the creation of a backup encompassing the CA database and the CA's private key, thereby guaranteeing the safeguarding of the fundamental elements of the CA. Safeguarding these components is imperative, as malevolent actors may exploit the backup for nefarious purposes.

 

In addition to preserving the CA Database and the CA's private key, for comprehensive restoration onto a new server, it is crucial to back up the registry settings associated with ADCS using the following command:  

 

 

 

Reg export “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration” C:\BackupFolder\CAConfig.reg

 

 

 

All settings on the earlier location of the CA database, as well as configurations related to certificate validity settings, CRL and AIA extensions, can be utilized during the recovery process.

 

If the source CA utilizes a custom CAPolicy.inf, it is advisable to replicate the file to the identical backup location. The CAPolicy.inf file is typically found in the %windir% directory (default location being C:\Windows).

How can the service be restored?

Remove ADCS role(s)

If the source server is still available and a CA Backup is available, remove the CA role from it. This is required for Enterprise CAs that are domain-joined. If present, remove the “Web Server” based roles/features before the Certification Authority role.

 

Remove the source server from the domain

Reusing the same host name on the destination server requires that the source server either be renamed or removed from the domain and the associated computer object removed from Active Directory before renaming and joining the destination server to the domain.

 

Adding ADCS role(s)

After ensuring that the destination server has the correct hostname and is successfully integrated into the domain, continue to assign the CA role to it. If the destination server is already part of the domain, it needs Enterprise Admin permission to configure the ADCS role as an Enterprise CA.

Before advancing, transfer the backup folder to a local drive, and, if accessible, move the original CAPolicy.inf file to the %windir% folder on the destination server.

  • Launch the Add Roles wizard from Server Manager.
  • Review the “Before You Begin” page, then select Next.
  • On the “Select Server Roles” page, select Active Directory Certificate Services, then Next, then Next again on the Intro to ADCS page.
  • On the “Select Role Services” page, ensure only Certificate Authority is selected, then click Next. (Do not choose any other roles)

Configuring ADCS:

Now configure a clean ‘empty’ CA. This is done prior to restoring the configuration and database content:

  • Select the choice to “Configure Active Directory Certificate Services on this server.”
  • Confirm that the correct credentials are in place depending on the installation: Local Admin for Standalone CA, Enterprise Administrator needed for Enterprise certification authority.
  • Check the box for “Certification Authority.”
  • Select the desired option based on the source CA configuration (“Standalone” or “Enterprise”) on the “Specify Setup Type” page, then click “Next.”
  • Select “Root” or “Subordinate CA” on the “Specify CA Type” page, then click “Next.”
  • Select “Use existing key” on the “Set Up Private Key” page, then click “Next.”
  • Import the Private key from the backup folder copied previously. Select the key and click “Next.”
  • Configure the desired path on the “Configure Certificate Database” page, then select “Next,” then “Install.”

At this point we have restored the CA and have an empty database with default server settings.

  • Open “Certificate Authority” manager from Server Manager or from Administrative Tools.
  • Expand “Certificate Authority (Local)” right click “CAName,” and select “All Tasks,” and click on “Restore CA.”
  • Click “OK” to stop the service.
  • Select “Next” on the “Welcome to the Certification Authority Restore Wizard.”
  • Check only “Certificate Database” and “Certificate Database Log,” click “Browse” and target the backup folder. "C:\BackupFolder", click “Next” and click “Finish” then wait until the restore completes.
  • Click “Yes” to continue and start the service.
  • Expand “Certificate Authority (Local)” right click “CAName” and select “Issued Certificates” to verify the database was restored.

Restore registry settings:

After the database is restored, import the configuration settings that were backed up from the source CA’s registry.

  • Create a registry backup of the destination server:

 

 

Reg export “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration” C:\BackupFolder\DestinationCAConfig.reg

 

 

  • Locate the “C:\BackupFolder\CAConfig.reg” file and double click on it to merge the settings, click “Yes” to continue and then “OK” on the Registry Editor confirmation window.
  • Restart the ADCS Service to verify the restored settings.
  • After everything is verified, restart the server to ensure it belongs to the “Cert Publishers” group.

Verify server status:

  • Open “Certificate Authority” manager from Server Manager or from Administrative Tools.
  • Expand “Certificate Authority (Local),” then “CAName” right click “Revoked Certificates” select “All tasks” then “Publish.” Select “OK” at the popup.
  • Run ADCSView.msc to verify the health of the destination CA server.

Test certificate issuance:

With the CA restored, test certificate issuance to ensure full functionality.

  • Publish any templates that were published before and ensure the CA issues certificates are issued as expected.

Note! We recommend an assessment be conducted on all certificate templates to confirm security settings and to reduce the number of templates if possible.

Conclusion

This article highlights the necessity of setting up and upholding a robust "back-and-restore" strategy as a primary defence mechanism against cyber threats. it becomes much more likely that recovery for ADCS will not be successful, and a complete rebuild will be required.

In addition to this, adopting a defence-in-depth approach is equally imperative. This involves implementing supplementary protective measures such as endpoint detection and response through Defender for Endpoint (MDE), or monitoring user and entity behaviour analytics with Microsoft Defender for Identity (MDI). These measures empower cybersecurity operatives to swiftly respond across multiple phases of MITRE ATT&CK, thereby safeguarding the organization’s digital ecosystem, particularly the pivotal identity and access management services.

Integrating the strategic management of ADCS (Active Directory Certificate Services) with these advanced security solutions further strengthens organizational defences against the continually evolving landscape of cyber threats. This strategy augments the resilience of the cybersecurity framework and ensures the continuity and integrity of organizational operations, particularly during the transition to a more secure ADCS infrastructure.

In conclusion, the adoption of a robust backup and restoration strategy, complemented by a multi-faceted defence framework that integrates ADCS management with innovative security solutions, creates a formidable shield against cyber threats. This approach bolsters cybersecurity resilience and fortifies organizational continuity and operational integrity in the dynamic landscape of evolving security challenges.

Version history
Last update:
‎May 28 2024 09:08 AM
Updated by: