AD CS + Azure Hybrid PKI Architecture: Extending On-Premises CA to the Cloud

Windows Hello for Business (WHfB) in hybrid certificate trust mode requires AD CS to issue authentication certificates to users.

How It Works

1. User registers Windows Hello biometric/PIN on Entra-joined or hybrid-joined device
2. Entra ID issues a partial certificate (user key attestation)
3. The device requests a full authentication certificate from AD CS via the certificate enrollment endpoint
4. AD CS issues a certificate using the “Windows Hello for Business Authentication” template
5. User authenticates to on-premises resources using the WHfB certificate

Template Configuration

# Duplicate the "Smartcard Logon" template
# Rename to "WHfB Authentication"

# Template settings:
# Subject Name: Build from Active Directory (UPN)
# Cryptography: Key Storage Provider, ECDSA P-256 or RSA 2048
# Application Policies: Smart Card Logon + Client Authentication
# Issuance Requirements: Authorized signature (enrollment agent)
# Security: "Authenticated Users" - Enroll

# Publish template
Add-CATemplate -Name "WHfBAuthentication" -Force

Certificate Enrollment Policy (CEP) for WHfB

# Install CEP/CES role services for WHfB
Install-WindowsFeature ADCS-Enroll-Web-Pol, ADCS-Enroll-Web-Svc

# Configure CEP with certificate authentication
Install-AdcsEnrollmentPolicyWebService -AuthenticationType Certificate `
  -SSLCertThumbprint (Get-ChildItem Cert:\LocalMachine\My | 
    Where-Object { $_.Subject -match "cep.company.com" }).Thumbprint

# Configure CES
Install-AdcsEnrollmentWebService -AuthenticationType Certificate `
  -CAConfig "CA-Server\Company-CA" `
  -SSLCertThumbprint (Get-ChildItem Cert:\LocalMachine\My | 
    Where-Object { $_.Subject -match "ces.company.com" }).Thumbprint

Pattern 4: Microsoft Intune Cloud PKI

Intune Cloud PKI (generally available since 2024) provides a Microsoft-managed CA that issues certificates without any on-premises infrastructure.

When to Use Cloud PKI vs. Connector

Cloud PKI Setup

# In Intune admin center:
# 1. Tenant administration > Cloud PKI > Create

# Root CA configuration:
CA Type: Root CA
Name: "Company Cloud Root CA"
Validity: 10 years
Key size: RSA 4096 or ECC P-256
Hash: SHA-256

# Issuing CA configuration:
CA Type: Issuing CA
Name: "Company Cloud Issuing CA"
Validity: 6 years
Signing CA: (select root created above)
Key size: RSA 2048 or ECC P-256

# 2. Create SCEP profile pointing to Cloud PKI
# The SCEP URL is automatically generated — no NDES needed

Trust Distribution for Cloud PKI

# Export Cloud PKI root certificate from Intune admin center
# Distribute to on-premises systems that need to trust Cloud PKI certs

# For domain-joined machines (GPO):
# Computer Configuration > Policies > Windows Settings > 
#   Security Settings > Public Key Policies > Trusted Root CAs

# For NPS/RADIUS servers:
# Import Cloud PKI root into NPS server's trusted root store
Import-Certificate -FilePath "CloudPKI-Root.cer" -CertStoreLocation Cert:\LocalMachine\Root

# For Linux systems:
sudo cp cloud-pki-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Pattern 5: Azure Key Vault Integration

Azure Key Vault serves as a certificate store and can integrate with AD CS for issuance or use its own integrated CAs.

Key Vault as Certificate Store for AD CS-Issued Certs

# Import AD CS-issued certificate into Key Vault
az keyvault certificate import \
  --vault-name "company-keyvault" \
  --name "api-gateway-cert" \
  --file "api-gateway.pfx" \
  --password "export-password"

# Configure auto-renewal with Key Vault integrated CA
az keyvault certificate create \
  --vault-name "company-keyvault" \
  --name "webapp-cert" \
  --policy @cert-policy.json

cert-policy.json for DigiCert integration:

{
  "issuerParameters": {
    "name": "DigiCert",
    "certificateType": "OV-SSL"
  },
  "keyProperties": {
    "exportable": true,
    "keyType": "RSA",
    "keySize": 2048,
    "reuseKey": false
  },
  "secretProperties": {
    "contentType": "application/x-pkcs12"
  },
  "x509CertificateProperties": {
    "subject": "CN=api.company.com",
    "subjectAlternativeNames": {
      "dnsNames": ["api.company.com", "api-dr.company.com"]
    },
    "validityInMonths": 12
  },
  "lifetimeActions": [
    {
      "trigger": { "daysBeforeExpiry": 30 },
      "action": { "actionType": "AutoRenew" }
    }
  ]
}

Key Vault + App Service Integration

# Bind Key Vault certificate to App Service
az webapp config ssl import \
  --resource-group "production-rg" \
  --name "company-webapp" \
  --key-vault "company-keyvault" \
  --key-vault-certificate-name "webapp-cert"

# Enable auto-sync (App Service picks up renewed certs automatically)
az webapp config ssl bind \
  --resource-group "production-rg" \
  --name "company-webapp" \
  --certificate-thumbprint "$THUMBPRINT" \
  --ssl-type SNI

Cross-Trust Scenarios

Single Root, Multiple Issuing CAs

The cleanest hybrid architecture uses a single offline root CA that signs multiple intermediates:

• AD CS Issuing CA — Windows domain certificates
• Cloud PKI Issuing CA — Intune-managed device certificates
• Vault/step-ca Issuing CA — Application and service certificates

All certificates chain to the same root, so trust distribution is a one-time operation.

# Sign Cloud PKI intermediate CSR with on-prem root
# (Export CSR from Intune Cloud PKI settings)
certutil -sign cloud-pki-int.csr cloud-pki-int.cer

# Sign Vault intermediate CSR with on-prem root
certutil -sign vault-int.csr vault-int.cer

# Both intermediates now chain to your existing root
# All existing trust stores already trust the root = zero client changes

# Monitor Intune Certificate Connector health
$connectorStatus = Get-WinEvent -LogName "Microsoft-Intune-CertificateConnectors/Operational" -MaxEvents 1
if ($connectorStatus.LevelDisplayName -eq "Error") {
    Send-Alert -Message "Intune Certificate Connector error detected"
}

# Monitor AD CS certificate expiry
$expiringCerts = certutil -view -restrict "NotAfter<=$(Get-Date).AddDays(30)" -out "CommonName,NotAfter"
if ($expiringCerts.Count -gt 0) {
    Send-Alert -Message "$($expiringCerts.Count) certificates expiring within 30 days"
}

# Monitor CRL publication
$crl = certutil -verify -urlfetch "issuing-ca.crl"
if ($LASTEXITCODE -ne 0) {
    Send-Alert -Message "CRL verification failed for issuing CA"
}

# Firewall rules for hybrid PKI
# Intune Connector → AD CS: TCP 135, 49152-65535 (RPC)
# Intune Connector → Internet: TCP 443 (Intune service)
# App Proxy Connector → NDES: TCP 443
# App Proxy Connector → Internet: TCP 443 (Azure relay)
# Vault → AD CS Root (signing only): TCP 443 (restricted, temporary)

# Entra ID Conditional Access Policy
Name: "Require compliant device for certificate enrollment"
Assignments:
  Users: All users
  Cloud apps: Microsoft Intune Enrollment
Conditions:
  Device platforms: All platforms
Grant:
  Require device to be marked as compliant
  Require multifactor authentication