When automating AD CS, it’s critical to create dedicated service accounts with least-privilege permissions tailored for each role and integration. Here’s an exact breakdown of service accounts and their appropriate permissions, aligned to security best practices for certificate issuance, management, and device integration.
Core AD CS Service Accounts
Account | Type/Configuration | Least-Privilege Permissions |
CA Service Account | Local SYSTEM account or virtual account (NT SERVICE\CertSvc) by default | No change; runs with system-level privileges and does not require domain access |
NDES/SCEP Service Account | Dedicated domain user (not admin), e.g., svc_ndes | - Member of local IIS_IUSRS group on NDES server |
Certificate Enrollment Policy Web Service | Domain user or gMSA (group Managed Service Account) for scalable automation | - “Read” and “Enroll” on published certificate templates used for automation |
Auto-Enrollment Agent Account | (For GPO-driven automation, uses computer/user context) | - “Autoenroll” and/or “Enroll” permission on relevant certificate templates |
Intune Connector or MDM Integration Account | Group Managed Service Account (gMSA) preferred for connector service | - “Enroll” on device certificate templates |
Configuration Notes for Least-Privilege
• Never use Domain Admins for service accounts tied to certificate automation or NDES integration.
• Remove logon rights for service accounts; grant only “Logon as a service” where required.
• For connector integrations (Intune, MDM, third-party CLM), use gMSA whenever possible for key rotation and isolation.
• Limit template permissions to specific accounts/computers needing certificate issuance.
• Always review template permissions using the Certification Authority MMC and the certificate template security tab.
• For applications consuming certificates via web enrollment, use application pools running under dedicated accounts and restrict those accounts to “Enroll” only for specific templates.
Example: NDES/SCEP Domain Service Account Setup
- Create a domain user (e.g., svc_ndes).
- Add to local IIS_IUSRS group on the NDES server.
- In the Certificate Authority, assign "Request Certificates" and "Read/Enroll" on the NDES template.
- Deny interactive logon rights.
- If using load-balanced names, assign a Service Principal Name (SPN) to the account.
These practices ensure that every AD CS automation component operates using dedicated accounts with only the minimum permissions required, protecting your PKI environment from escalation and unauthorized access while supporting scalable CLM workflows