Microsoft Always On VPN administrators have two choices when deploying enterprise PKI certificates using Intune; PKCS and SCEP. I prefer using PKCS because it is easier to configure and manage. Also, PKCS requires no inbound connectivity, simplifying the deployment and reducing the organization’s public attack surface. Provisioning certificates using Intune is inherently risky. However, there are some steps administrators can take to mitigate much of this risk.
Note: The techniques described in this article also apply to the NDES server when using SCEP certificate deployment in Intune, with one exception noted below.
PKCS Security
The service account is the most critical aspect of configuring the Intune Certificate Connector for PKCS securely. The service account has permission to enroll for an exceedingly dangerous published certificate template. Specifically, the PKCS certificate template has the deadly combination of supplying the subject information in the request, and the Client Authentication enhanced key usage (EKU). Further, the scenario does not allow administrative approval to be enabled on the certificate template. If an attacker were to gain access to this certificate template, they could enroll as any principal they chose, including a domain administrator, and their request would be processed automatically. Subsequently, they could authenticate to Active Directory using only the certificate without knowing the account’s password.
Service Account
Using a Group Managed Service Account (GMSA) would be ideal in this scenario. However, the Intune Certificate Connector does not support using GMSA when using PKCS. With that, administrators must use a regular domain service account instead, which introduces additional risk. To enhance the overall security of the solution, consider performing the following PKCS service account hardening tasks when using the Intune Certificate Connector to issue PKCS certificates with Intune.
Standard User
The service account should be a standard domain user with no special privileges. The service should be dedicated to PKCS and not shared with other services in the enterprise. Create the account from scratch (do not duplicate another account!), and use a long, complex password. Document this password securely. In addition, ensure the PKCS service account is not a member of any other security groups. It does not require local administrator access, either.
Account Hardening
After creating the service account, click the Log On To button on the Account tab and ensure the account can only log on to the server(s) where you have installed the Intune Certificate Connector.
Next, check the box next to Account is sensitive and cannot be delegated in the Account options section.
In addition, select the option Deny access in the Network Access Permission section of the Dial-In properties page.
Finally, uncheck Enable remote control on the Remote control properties page.
Local Access Rights
Open the Local Group Policy Editor (gpedit.msc) on each server where you installed the Intune Certificate Connector. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Enable the following policy settings for the PKCS service account.
- Deny access to this computer from the network
- Deny log on as a batch job
- Deny log on locally
- Deny log on through Remote Desktop Services
Optionally these settings can be enforced on the Intune Certificate Connector server using Active Directory group policy.
Important Note: When implementing these settings for hardening an NDES server do not specify the Deny log on as a batch job user rights assignment.
Disclaimer
I am not an Active Directory security expert! The guidance provided here is based on my many years of Windows administrative experience, conversations with Identity and Access security professionals, and published guidance found on the Internet. If you have suggestions to further improve service account security, don’t hesitate to let me know! Please share in the comments, below.
Additional Information
Overview of the Certificate Connector for Microsoft Intune
Configure and use PKCS Certificates with Microsoft Intune
Microsoft Intune Certificate Connector Service Account Requirements
9 Tips for Preventing Active Directory Servie Accounts Misuse
Jon
/ September 17, 2023What is the reason one would choose SCEP over PKCS today?
Richard M. Hicks
/ September 17, 2023SCEP is required if you are deploying devices in kiosk mode where there is not primary or assigned users. Other than that, PKCS works in pretty much every other scenario to my knowledge.
Grimster
/ February 2, 2024This has traditionally been the response regarding user-less devices, more recently Microsoft documentation is starting to indicate otherwise: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-pfx-configure
Select a type:
User certificates can contain both user and device attributes in the subject and subject alternative name (SAN) of the certificate.
Device certificates can only contain device attributes in the subject and SAN of the certificate. Use Device for scenarios such as user-less devices, like kiosks or other shared devices.
This selection affects the Subject name format.
Richard M. Hicks
/ February 2, 2024Good to know. Thanks!
Phil L
/ November 3, 2023This is a great article! PKCS worked like a champ as usual. Interesting scenario that I’m seeing. On some systems, multiple users are logging in and the first user is successful in receiving the certificate, the second user is showing an error and the user is then unable to login to wi-fi. Anything I should be looking for? I actually see the certificate issued on the server.
Richard M. Hicks
/ November 3, 2023Thanks! I have no idea why a second user would have issues receiving a certificate. That’s odd, for sure. If you are seeing the certificate issued on the CA, then I suspect it’s an Intune issue. What, specifically, that would be I don’t know. Do the event logs on the endpoint indicate anything?