¶ Before You Begin
Windows domains works well without AD CS, as long as you don't require any PKI functionality. SystoLOCK relies heavily on PKI, so a properly configured certification authority (CA) must be in place before installing SystoLOCK. If you attempt to install SystoLOCK Server without AD CS properly configured, SystoLOCK setup will fail.
Microsoft AD CS comes in two flavours: standalone and enterprise. Only enterprise CA is supported by SystoLOCK. Please, also bear in mind that after you install a CA, the underlying server cannot be renamed, so make that changes aforehand.
Another important aspect to consider is CA topology: a single CA will suffice for SystoLOCK, but if you are about to install your first CA, you might want to consider a more complex CA hierarchy. A good overview of possible options is available at Microsoft Docs
There are three basic scenarios you can provide an AD CS server for SystoLOCK: new dedicated instance(s), an existing instance and a new domain-wide instance.
If you operate in a multi-domain hierarchy, make sure you belong to
Enterprise Adminssecurity group to be able to configure certificate authorities. Alternatively, configure Delegated Instllation as suggested by Microsoft.
¶ 1 Install a SystoLOCK-Dedicated CA (recomended)
The server setup will offer you to silently install and configure a local CA on you on your future SystoLOCK server. This is a recommended path as it allows you to separate control between various CAs.
If you want this CA to be subordinate to an existing CA, you can run your server setup with DELAYDEPLOYMENT parameter set to yes and then execute New-SystoLOCKCA.ps1 from C:\Program Files\Systola\SystoLOCK\Authentication Server\Scripts, specifyiung -ParentCA for an online singing of the CA certificate (the specified CA will be contacted) or -RequestPath for an offline singing (the request will be written to the path specified). After CA is installed, run Systola.SystoLock.Server.Configurator.exe from C:\Program Files\Systola\SystoLOCK\Authentication Server to continue with the server installation.
If you decide to go for this recommended solution, you can skip this document up to Configure DC certificates
¶ 2 Use an Existing CA
If you already have an AD CS instance in your domain, you can use it for SystoLOCK, only make sure its CDPs are configured according to the description below.
¶ 3 Install a New, Domain-Wide Windows CA
The easiest way to install a CA is by using PowerShell. The examples below illustrate the simplest setup. For a complete guidance on how to install a CA, please refer to Microsoft documentation and PowerShell Reference on Install-AdcsCertificationAuthority.
First you need to install the new role. Start PowerShell on the prepared server and type:
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
If you plan to serve CRLs from the same server, install IIS:
Add-WindowsFeature Web-Server -IncludeManagementTools
After installing the new role(s), configure the new CA by typing:
Install-AdcsCertificationAuthority -CAType EnterpriseRootCa `
-CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
-KeyLength 2048 -HashAlgorithmName SHA256 `
-ValidityPeriod Years -ValidityPeriodUnits 3 -Force
Change any parameters, like hashing algorithm, to accommodate your needs.
Once installed and configured, you can open your new CA's MMC console and continue configuring it there.
If you operate from a subdomain in a multi-domain hierarchy, make sure to adjust security descriptors on at least
Certificate TemplatesandOIDcontainers within theCN=Public Key Services,CN=Services,CN=Configuration,DC=<ForestRootDomain>to allowFull accessto theDomain Adminsof the local domain. Also grantEnrolrights toSystoLOCK Servicegroup andNetwork Serviceon theComputertemplate or its successor.
¶ Configure CDPs
Take special care in configuring proper CRL distribution points (CDP) as Windows authentication subsystems will check for these CRLs during authentication and will not always be able to use LDAP endpoints (default settings) for that. Consequently, be sure to include HTTP paths in instead of LDAP as shown:
Also refer to Microsoft's Root Certificate Requirements for Use With Domain Sign-in.
You can leave LDAP-based CRL pointers if you know that you need them, as long as you provide the http-based URLs as well.
¶ You can use PowerShell to configure CDPs:
Get-CACrlDistributionPoint `
| ? { $_.uri -like "http*" -or $_.uri -like "ldap*" -or $_.uri -like "file*" } `
| Remove-CACrlDistributionPoint -force
Add-CACrlDistributionPoint -Uri "http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl" `
-AddToCrlIdp:$false -AddToFreshestCrl:$true `
-AddToCertificateCdp:$true -Confirm -Force
# AIA configuration is optional, but advisable
$HttpUri = Get-CAAuthorityInformationAccess | ? { $_.uri -like 'http*' } | select -ExpandProperty uri
Get-CAAuthorityInformationAccess | Remove-CAAuthorityInformationAccess -Force
Add-CAAuthorityInformationAccess -Uri $HttpUri -AddToCertificateAia -Force
Restart-Service CertSvc
& certutil -CRL republish
Get-CACrlDistributionPoint `
| ? { $_.uri -like "http*" -or $_.uri -like "file*" } `
| Remove-CACrlDistributionPoint -force
Add-CACrlDistributionPoint -Uri "http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl" `
-AddToCrlIdp:$false -AddToFreshestCrl:$true `
-AddToCertificateCdp:$true -Confirm -Force
# AIA configuration is optional, but advisable
$HttpUri = Get-CAAuthorityInformationAccess | ? { $_.uri -like 'http*' } | select -ExpandProperty uri
Get-CAAuthorityInformationAccess | Remove-CAAuthorityInformationAccess -Force
Add-CAAuthorityInformationAccess -Uri $HttpUri -AddToCertificateAia -Force
Restart-Service CertSvc
& certutil -CRL republish
¶ And add CRLs to the Default Website on IIS and make delta-CRLs accessible:
& 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
Correct the above scripts accordingly 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.
Errors in the above scripts (0x80070057, ERROR_INVALID_PARAMETER, etc.) may be an indication of a previously abandoned, incomplete CA configuration, in which case it is advisable to recursevly cleanup any references to missing instances under
CN=Public Key Services,CN=Services,CN=Configuration,DC=<yourdomain>
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. Your output should be similar to the following screenshot and should not include any warning or error signs:
SystoLOCK may not function properly if there are any lines with a non-OK status in the above snap-in.
¶ Configure Automatic Database Cleanup
Once SystoLOCK starts issuing certificates, these remain in the databse of the CA servers and may with time create a problem with disk space. It is recommended to cleanup the CA database on a regular basis. This can be done with a scheduled task that is to be created on each CA server.
You can create the appropriate task on the CA server by running the following PowerShell script:
$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
After creating the task, adjust any options to your needs. The task above would run every day and cleanup all certificates, expired a day earlier.
¶ Configure Domain Controller Certificate Templates
It is highly advisable to replace the legacy Domain Controller Authentication or Domain Controller certificates on your domain controllers with the new Kerberos Authentication certificates.
Refer to the article on LDAP389 on how to do this.
If you do so, make sure you include Domain Controller and Domain Controller Authentication templates in the list of superseeded templates. The same goes for any template you use for the computer objects: they should include Computer template in the list of superseeded templates.