ADCS / New CA / Chicken or Egg?
Hello, I am fairly knowledgeable about PKI and ADCS, but have a few question about AD behavior after we created a new sub CA. We have a two tier PKI with an offline root, and two subordinate CAs. These have been around for several years, and we have had minimal problems. Our CAs are nearing the end of their lifecycle, so we recently provisioned a new sub CA. We installed the role on the new server, got the offline request signed by the root, and completed the install. I am assuming that when you install the CA certificate onto a new enterprise subordinate CA, it goes ahead and publishes a bunch of stuff to the various AD containers relating to PKI (Certificate Authorities, Enrollment Services, NTAuth, CDP, AIA, etc. This is probably why you need EA permissions on the domain to complete the install.) Anyway, we completed the install and started the CA service. Immediately, the DCs auto-enrolled for the Kerberos Authentication Template. This is not necessarily a bad thing, as we use Smart Card Login (SCL) and the DCs need to have a certificate issued by the new CA. Almost immediately, we began seeing an error when attempting to RDP or login stating "An Untrusted Certification Authority was detected while processing the domain controller certificate used for authentication" and users were kicked back to login. UN/PW/2FA worked, so we were not totally sunk. The issue gradually cleared itself up over the course of a few hours. My theory is that not all workstations and servers immediately got the new CA cert, which would have been propagated through routine GP updates, and that when windows saw domain controllers presenting untrusted domain controller certs, they balked at it. Either that, or the clients were seeing an untrusted cert in NTAuth. So what is the best way to mitigate this? Remove all certificate templates from the new CA before you turn the service on? Let the new CA cert propagate around before you start issuing DC certs? Thank you for the insight!Active Directory Certificate Services with Azure Key Vault Virtual HSM
Hi all (an I hope also Microsoft folk in the security and AD CS arenas), With Azure adoption etc and the GA a while ago of Azure Key Vault virtual HSM it seems to me that it would make a significant enhancement of AD CS security to use Azure Key Vault virtual HSM to host the AD CS server certificate keys. Most third party (virtual) HSMs come with instructions, agents, custom key service providers etc to enable the external hosting and access from the windows host to the certificate key. I can only find (quite old) information for SQL which adds a custom KSP to SQL seemingly rather than to the OS. Has anyone else had a go at or implemented this yet?Error configuring ADCS from PowershellDSC
PowerShell DSC resource MSFT_ScriptResource failed to execute Set-TargetResource functionality with error message: Setup could not add the Certification Authority’s computer account to the Cert Publishers security group. This Certification Authority will not be able to publish certificates in Active Directory. To fix this, an administrator must manually add the Certification Authority’s computer account to the Cert Publishers security group in Active Directory. Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS) Setup could not add the Certification Authority’s computer account to the Pre-Windows 2000 Compatible Access security group. Certificate Managers Restrictions feature will not work correctly on this Certification Authority. To fix this, an administrator must manually add the Certification Authority’s computer account to the Pre-Windows 2000 Compatible Access security group in Active Directory. Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS) Setup was unable to install or update the default certificate templates. Ensure you have write permissions on the "Certificate Templates" container in the forest root domain, then manually install the default certificate templates using the command: certutil -installdefaulttemplates. Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED) + CategoryInfo : InvalidOperation: (:) [], CimException + FullyQualifiedErrorId : ProviderOperationExecutionFailure + PSComputerName : Rootca.mylabcore.lo
