Set up Microsoft PKI (ADCS) for SystoLOCK via PowerShell

Windows domains operate normally without Active Directory Certificate Services (AD CS), provided that no Public Key Infrastructure (PKI) functionality is required. However, SystoLOCK depends heavily on PKI, this means you must deploy and correctly configure a Certification Authority (CA) before installing SystoLOCK. Therefore, in this guide, I will be discussing the steps to “Set up Microsoft PKI (ADCS) for SystoLOCK via PowerShell”. Please, see , How to Install ROOT CA Enterprise and NPS Wifi Certificate, and how to Install and configure Active Directory Certificate Services.

Note: Important: After you install a CA role, you cannot rename the underlying server. Always finalize the server hostname and domain configuration before installing the CA to avoid reinstallation. Here are some guide for this “Post OS installation: Configure the properties of Windows Server, how to Install Windows Server 2025 via iDRAC Virtual Media or PXE, and how to Convert Windows Server Datacenter to Standard: Install Windows Server via iDRAC Virtual Media“.

Microsoft AD CS supports two deployment modes: Standalone CA and Enterprise CA. SystoLOCK supports only the Enterprise CA mode, as it integrates directly with Active Directory and provides certificate templates and auto-enrollment capabilities. Only Enterprise CAs can issue templates. Standalone CAs won’t show these templates.

If you attempt to install SystoLOCK Server without a properly configured AD CS instance, the installation process will fail.

Install a New, Domain-Wide Windows CA

If you already have an existing CA, you can use it and do not need to install a new one for SystoLOCK. You can also use the SystoLOCK setup to configure a local CA directly on the SystoLOCK Server. SystoLOCK recommends this approach because it allows you to separate responsibilities and maintain clearer control between different CAs.

Therefore, select the Local Certificate Authority. But because I have installed the CA via this guide, I have have the opportunity to select the CA during SystoLOCK server installation. You can save yourself the time and disregard this post and use the first option. Please, see this post on “how to protect your Windows Devices with MFA with SystoLOCK“.

But I have decided to install ADCS on the Active Directory. This steps I assume an existing, and centralized PKI infrastructure. This simplifies certificate management across the domain (auto-enrollment, templates, CRLs, etc. and make it easier to enforce organization-wide policies.

We will start of my installing ADCS role.

Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

To serve CRLs from the same server, install IIS

Add-WindowsFeature Web-Server -IncludeManagementTools

Note: If you do not restart your server after running the above command and proceed to configure the new CA. You will get the below error. This is because, the ADCSDeployment module (which provides Install-AdcsCertificationAuthority) is not loaded yet. Restart the server and launch PowerShell as it will fail on CommandPrompt as well.

Install-AdcsCertificationAuthority : The term ‘Install-AdcsCertificationAuthority’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CryptoPr … + ~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (Install-AdcsCertificationAuthority:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException

Post ADCS installation

Upon restart, the ADCSDeployment module will be loaded and you can configure it as shown below from the Server Manager. But, I will continue with PowerShell as also shown below.

After AD CS is installed, type the following command and press ENTER.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 2048 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 3 -Force

In PowerShell, “ErrorId = 0” means no error occurred. While the “ErrorString is empty” means nothing failed. This means the operation completed successfully. sometimes modules or installers return 0 as a generic “success” even if they didn’t actually add/register what you expected. That’s why you should always verify by checking the results

I will recommend a restart of the Server after running the below command.

Please, see the steps in migrating SAP HANA Plugin to Veeam, how to Fix what is taking up my Mac Storage? Delete Snapshots, and how to Convert Windows Server Datacenter to Standard: Install Windows Server via iDRAC Virtual Media.

Configure CRL Distribution Points (CDPs)

To ensure SystoLOCK functions correctly, it’s crucial to configure CRL Distribution Points (CDPs) with HTTP paths, as Windows authentication subsystems may not reliably access LDAP-based CRLs during authentication. While you can retain LDAP URLs if necessary, it’s recommended to prioritize HTTP URLs.

Open the Certification Authority Console as shown below. In Windows, there are numerous ways to launch this. You can also run certsrv.msc to fire up the console.

Access the Extensions Configuration by right-clicking on your CA and then select Properties.

Navigate to the Extensions tab, and select CRL Distribution Point (CDP) from the dropdown if not selected by default. Configure Options for the New HTTP CDP by checking the following boxes for the HTTP entry:

• Include in CRLs. Clients use this to find Delta CRL locations.
• Include in the CDP extension of issued certificates

You will be prompted to restart the ADCS as shown below. Click on Yes.

Note: These placeholders are automatically resolved by the CA when a certificate is issued as they cannot be edited. For example: <ServerFQDN> is replaced with the actual hostname of the CA at issuance time. The placeholder itself is not literal in the issued certificate. It is just a template. This means that when a client or SystoLOCK requests the CRL, the placeholder is already replaced with the correct FQDN of the CA server.

Also, see how to setup a Domain Controller as Recommended by Microsoft, how to add a new Domain Controller to an Existing Domain, and Microsoft Azure Multi-Factor Authentication (MFA). Here is how to install and configure Active Directory Domain Services on Windows Server 2022.

And add CRLs to the Default Website on IIS and make delta-CRLs accessible

The CRL (Certificate Revocation List) and Delta CRLs are generated and stored by the CA. These need to be published via HTTP so that all clients (including SystoLOCK, domain controllers, and workstations) can fetch them.

To do this, run the below commands. The below scrips does create a virtual directory /CertEnroll in IIS that maps to the CRL folder, and the second script, adjusts IIS request filtering so special characters in CRL filenames are allowed.

& C:\Windows\System32\inetsrv\AppCmd.exe add vdir /app.name:"Default Web Site/" /path:/CertEnroll /physicalPath:"C:\Windows\System32\CertSrv\CertEnroll"

& C:\Windows\System32\inetsrv\AppCmd.exe set config "Default Web Site" /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True

Note 1: You must correct the above two scripts, if you are using a web server on a different machine, have different URL path(s) or have any other settings that deviate from default values.

Note 2: If you plan on using SystoLOCK outside your organizational network, be sure to make your CDPs accessible from the internet. This also concerns DNS names in CDP’s URLs.

You can check to see if your CA setup is correct by firing up an empty MMC console and adding “Enterprise PKI” snap-in to it as shown below.

Your output should be similar to the following screenshot and should not include any warning or error signs:

Please, see how to delete a VM and Storage in Proxmox, how to fix “Action required” in Microsoft Authenticator App, and how to Fix AADSTS900144: The request body must contain the parameter.

Automatic Database Cleanup

Once SystoLOCK begins issuing certificates, the CA server stores them in its database, which can eventually consume significant disk space. To prevent storage issues, regularly clean up the CA database. Configure this process by creating a scheduled task on each CA server.

I will be creating the task directly on the CA server by running the following PowerShell script. This script register a recurring scheduled task that runs daily.

$argument = "-command `"&{ certutil -deleterow `$((get-date).AddDays(-1) | get-date -Format (Get-Culture).DateTimeFormat.shortdatepattern) Cert }`""
$action = New-ScheduledTaskAction -Execute 'PowerShell.exe' -Argument $argument
$principal = New-ScheduledTaskPrincipal -UserID "S-1-5-18" -LogonType ServiceAccount
$trigger = New-ScheduledTaskTrigger -Daily -At (get-date)
$task = New-ScheduledTask -Action $action -Principal $principal -Trigger $trigger
Register-ScheduledTask "Clear Certificates" -InputObject $task -Force

Below is the scheduled task created

Note: Alternatively, if you only want to clear expired certificates one time, and you don’t need to create a scheduled task. This command will delete all expired certificates from the CA database that are older than yesterday’s date. You can just run the cleanup command directly in PowerShell on your CA server. But, this is a manual process and not as effective as the scheduled task created above.

certutil -deleterow (Get-Date).AddDays(-1).ToString((Get-Culture).DateTimeFormat.ShortDatePattern) Cert

Please, see how to generate your trial SSL Certificate using DigiCert PKI platform, and how to enable LDAP over SSL with a third-party Certificate such as DigiCert.

Configure Domain Controller Certificate Templates

It is strongly recommended to replace the legacy Domain Controller and Domain Controller Authentication certificates on domain controllers with the modern Kerberos Authentication certificate template.

The Kerberos Authentication template is specifically designed for Active Directory domain controllers and includes the KDC Authentication extended key usage (EKU) in addition to Client Authentication and Server Authentication.

This ensures compatibility with current security best practices, supports secure Kerberos authentication (including smart card logon and PKINIT), and aligns with Microsoft’s deprecation of older domain controller certificate templates. Here is a tab that outlines the specific attributes of the Domain Controller Authentication and Kerberos Authentication templates:

	Domain Controller Authentication	Kerberos Authentication
Key Usage	Client AuthenticationServer AuthenticationSmart Card Logon	Client AuthenticationServer AuthenticationSmart Card LogonKDC Authentication.
Subject Alternate Name	DNS Name : Domain Controller FQDN.	DNS Name : Domain FQDN.DNS Name : Domain NetBios name.

Please, see how to “Import certificates into Trusted Root and Personal certificate store“, and Review of the Synology CC400W Installation and Configuration.

Configure the Templates

To Configure Domain Controller Certificate Templates, run certtmpl.msc to launch the Certificate Templates Console.

Locate Kerberos Authentication in the list and right-click on it. Select Duplicate Template.

In the General tab, give it a meaningful name, In my case, I will be naming it as “DC Kerberos Authentication”.

Also, under General in the certificate template properties, you should select “Publish certificate in Active Directory” if the certificate is intended for domain controllers, users, or computers that need the certificate to be discoverable via AD.

In Compatibility Tab, set the Certification Authority to at least Windows Server 2016. Also, for the Certificate Recipient, I will set this to Windows Server 2016 as this is the highest compatibility available.

Since my Domain Controllers (DCs) are running on Windows Server 2022. I will set the highest available compatibility level, which is Windows Server 2016, in the Kerberos Authentication certificate template. This ensures the certificates leverage the most recent cryptographic features and key usages supported by the template, even though the template cannot explicitly target Windows Server 2022.

Under the Subject Name Tab, select Build from this Active Directory information. Check DNS name and User principal name (UPN). This ensures the certificate contains the proper Subject that maps to the DC account in Active Directory, which is required for Kerberos authentication.

At the Extensions Tab, the “Application Policies” should include the below. If the “KDC Authentication” is missing, Kindly add it as it is required for Kerberos.

• Client Authentication
• Server Authentication
• Smart Card Logon, and
• KDC Authentication

For the Security Tab section, ensure Domain Controllers group has the “Enroll”, and “Autoenroll”.

For the “Supersede Legacy Templates”. You can read more from this Microsoft Guide.

Navigate to the Superseded Templates tab, and add the following legacy templates: “Domain Controller”, and “Domain Controller Authentication”.

Below is the newly created template.

Publish the New Template

Launch the Certification Authority Console (certsrv.msc).

Right-click Certificate Templates and then on “New” and select “Certificate Template to Issue”.

Select your new template (DC Kerberos Authentication).

Next, you will have to “Force Autoenrollment”, by running the command below.

gpupdate /force

To request a new cert, run the command below as well.

certutil –pulse

Verify Kerberos Authentication Certificate

On the domain Controller, look for Kerberos Authentication certificate that has been issued. to do this, run the command below.

certutil -store my

This will access the Local Computer or Current User certificate store (by default, my = Personal store) as shown below. But as you can see, the Kerberos Authentication Cert is missing. Note that, this command will also lists all certificates in that store with the details below:

• Subject Name
• Issuer
• Validity period
• Thumbprint
• Serial number
• Enhanced Key Usage (EKU)

Even when you open the CA console or the MMC.exe console, the KDC Authentication will still be missing. As you can see, I have the right permissions in place and the template correctly duplicated and published. So I can ignore these and search for new reasons for this error.

Note: If this certificate was to be present, Kerberos authentication will use the new certificate and the old ones will phase out automatically since they’re superseded as configured above.

The Fix to a functional “Microsoft PKI (ADCS) for SystoLOCK Server”

Since the template is already published, cannot be republished and can not be seen under manage etc. Also, the CertificateServicesClient-AutoEnrollment was missing in Event Viewer. This could mean that, the autoenrollment feature is not enabled via Group Policy.

Enable Certificate Services Client – Auto-Enrollment

To remediate this, launch Group Policy and enable auto enrolment as shown below. Navigate to the path below.

Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies, Certificate Services Client – Auto-Enrollment

Double click on the policy “Certificate Services Client – Auto-Enrollment” and enable it. As you can see, it was not configured previously.

As you can se below, this policy has been enabled and I have set the checkboxes to “Renew expired certificates, update pending certificates, and remove revoked certificate”, and to “update certificates that use the certificate template”.

Note: Auto Enrollment only triggers after GPO applies and may require a reboot or gpupdate /force with certutil -pulse. These command will force auto enrolment. As you can see, my desired (DC Kerberos Authentication certificate) is now available.

You can also check from the MMC Console or CA console as shown below. The issued certificate should include KDC Authentication, Client Authentication, and Server Authentication etc.

I hope you found this article very useful on how to set up Microsoft PKI (ADCS) for SystoLOCK via PowerShell. Please, feel free to leave a comment below.