Windows Server 2019 ADCS on Azure VMs as global PKI service

Here is an example Two-Tier PKI solution developed to provide services for OSX, Windows, and Linux clients globally. The solution is based on ADCS and an external HSM/Root CA.

Hello,

Thank you so much for posting here.

We mainly focus on the problems or issue about on-premises Active Directory. To deploy the two-tier architecture PKI, we could refer to the below document.

https://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx

But according to our description, we will make the deployment of PKI on Azure Windows VMs with an offline standalone root CA and six Enterprise issuing subCAs deployed in six Azure regions. So sorry that we are not professional with Azure. If we have any concerns, we could turn to Azure-Active-Directory forum to see whether they could provide further assistance (Select the tag of Azure-Active-Directory).

As for the CES and CEP, we could check whether the below document could help.

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/certificate-enrollment-web-services/ba-p/397385#:~:text=CES%20is%20another%20web%20service,not%20connected%20to%20the%20domain.

https://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx

Thank you so much for your understanding and support.

Best regards,
Hannah Xiong

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

I deployed a global PKI solution providing these capabilities. My recommendation is to utilize a VIP in front of the exposed web services load balanced to the different servers providing the web services in each region. One caveat to this approach is that Microsoft's IIS is not suitable as a transparent proxy. We had to rely on a separate solution to provide the required transparent proxying. The other recommendation I would make is that I'd separate the web services to different IIS servers. You can stack all of the different (NDES, CES, CEP) onto a single box, however, you will find that management and troubleshooting complexity is greatly increased if you do.

Let me try to address your other concern regarding which CA will provide the PKI services. A certificate issued by a Windows CA will always try to utilize the issuing CA for any certificate services. With this in mind, we developed a process to provide initial enrollment utilizing scripts to request on behalf of the recipient. The certificates were then delivered via a one time use Google code. Once initial enrollment was performed any subsequent certificate services would be performed at the initial issuing CA. We need to keep in mind that CEP/CES are secure gateways to the internal ADCS services, any logic is performed through GPO's and certificate policies defined on published templates within the issuing CA.

Shawn,

I had planned to use separate web servers for the CDP and AIA, OCSP. No revocation lists will be published in the rootCA per best practices and only configured and published in the Enterprise Subordinate Issuing CAs I had already considered using separate and additional web servers for the CES and CEP. Yep, an two different Azure internal LB VIPs would be used as the DNS RR for both the CRL and Web Enrollment i.e. crl.contoso.com and pki.contoso.com for example.

I plan to use the exact same certificate templates for all issuing CAs globally. Both manual and auto enrollment will be configure for non AD aware or joined servers and for AD aware and joined servers, respectively. Yes, I am aware auto enrollment is configured for user and server certificates through GPOs. When using multiple globally disperse Enterprise issuing subCAs, I am determining if I need to publish the CDP and AIA for every subCA to the share on the web servers intended for revocation lists. Simple enough to do but cannot find much documentation about this topic when using multiple subCAs. As you mentioned, if load balancing the CES, CEP, and NDES, which subCA it picks for certificate enrollment is based upon AD DS sites for AD joined servers but it seems that servers not joined to AD using manual enrollment randomly select the closest subCA from what I've been able to determine. I am testing in a lab and will see if that is the case.

Thanks,
Gary

Shawn,

For my design, I have separated the AIA, CRL, and OSCP onto separate web servers. NDES is also on a separate group of web servers. Both are load balanced. Since The NDES servers must be publicly available, they will be load balanced either with Azure Front Door w/ WAF or an internal LB that is front ended by a AppGW w/WAF. Ultimately NetScalars will replaced the native Azure LBs. The Certification Authority Web, Certificate Enrollment Web, and Certificate Enrollment Policy Web services will be installed on all Enterprise Subordinate Issuing CAs. Azure AD MFA with the NPS extension will be configured on the domain controllers since putting both first and second authentication in the same place is a best practice. The ECC encryption algorithm will be used for everything. Not absolutely sure that iOS and Android will support ECC or if NDES can be configured with ECC but will vet in my lab. Certificate templates will be configured to use ECC by changing compatibility to Windows 7/Windows Server 2008 R2. Will published common set of certificate templates to AD where applicable for autoenrollment and create common set of certificate templates not published to AD for those services and servers that require manual enrollment. Must carefully see how AD site topology and GPOs are configured when using autoenrollment and create special AD OUs to organize where GPOs are applied. After all this is working, will look to tackle Windows Hello for Business configuration. Have documented everything from planning, design, deployment step-by-step, and operations and security operations in a 250 page document.