First published on TECHNET on Apr 26, 2015
Setting up NDES using a Group Managed Service Account (gMSA)
Hallo everybody, this is Andy and Dagmar from Austrian Premier Field Engineering (PFE) describing how to implement NDES using a gMSA (instead of a normal domain user account).
When creating a lab on how to implement NDES (Network Device Enrollment Service) on Windows Server 2012 R2, we decided to go for gMSA to be more secure and to get rid of monolithic service accounts that could be misused. Unfortunately it turned out that it was not as straight forward as we expected and we decided to write down the steps and publish them.
Why all the effort? NDES works like a charm when installed with default settings… The answer is short and simple: Security. NDES acts as a registration authority for a CA thereby leveraging the Simple Certificate Enrollment Protocol (SCEP). Because of the way this protocol was designed, the CA has to fully trust the NDES regarding the verification of incoming certificate requests. The result of this design is that the NDES owns an extremely powerful type of certificate (Exchange Enrollment Agent (Offline request) by default) which allows NDES to request certificates with almost any subject from the CA. Therefore, putting as much effort as possible into securing NDES absolutely makes sense.
Be aware that the whole process of securing NDES should comprise a bunch of measures (e.g. enrolling the NDES certificates to a HSM) and that using a gMSA to run it, is only one of the recommended hardening steps. Please refer to this whitepaper focusing on NDES security: http://www.microsoft.com/en-us/download/details.aspx?id=46406&WT.mc_id=Blog_Intune_General_PCIT
Group Managed Service Accounts
(Standalone) Managed Service Accounts were introduced in Windows Server 2008 R2 and are managed domain accounts that provide automatic password management and simplified SPN management, including delegation of management to other administrators but limited to only one server. Group Managed Service accounts were introduced with Windows Server 2012 and provide the same functionality within the domain but also extend their availability to multiple servers.
From the security as well as from the manageability perspective, gMSA are the preferred way to configure services wherever it is supported to use them. For more details regarding gMSA, please refer to https://technet.microsoft.com/en-us/library/hh831782.aspx
NDES Accounts
When setting up NDES you have to decide in which security context the NDES application pool should run. From the NDES wiki (see http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-n... for more details) we learn that the NDES app pool account needs to fulfill the following requirements:
- Must be a member of the local IIS_IUSRS group.
- Must have request permission on the configured CA.
- Must be a domain user account and have Read and Enroll permissions on the configured templates.
- Must have SPN set in Active Directory.
All these requirements can be fulfilled by a gMSA, we simply need to configure the SCEP app pool to run in the security context of the gMSA, perform some additional steps and that’s it. But oooops, it wasn’t so simple then…
Configuration Steps
Many of the steps below are described in more detail in the NDES wiki. We are repeating them here in a summarized way in order to provide a complete guide of all steps required. Wherever gMSA specific steps are required, we describe them in detail.
Let’s assume the following parameters for our lab environment:
- NDES service account: NDESgMSA
- NDES server: ADCSWeb02.fabrikam.com
- Certification authority: CA02
- Web Server certificate (with proper subject and/or SANs set) enrolled to the NDES server
Prerequisites
- Forest prepared for gMSA usage (KDS Root Key created - https://technet.microsoft.com/en-us/library/jj128430.aspx )
- NDES Administrator account (out of scope of this post, see NDES wiki for details)
- NDES Device Administrator account (out of scope of this post, see NDES wiki for details)
Create and configure gMSA
1. Type the following command to create a new gMSA:
New-ADServiceAccount -name NDESgMSA -DNSHostName NDESgMSA.fabrikam.com -PrincipalsAllowedToRetrieveManagedPassword ADCSWEB02$
2. Then configure the gMSA on the NDES host machine:
a. To load the AD PowerShell RSAT feature, type: Add-WindowsFeature RSAT-AD-PowerShell
b. To install the gMSA on ADCSWEB02 type: Install-ADServiceAccount NDESgMSA
c. To verify if the gMSA has been configured properly, type: Test-ADServiceAccount NDESgMSA
Note : The answer has to be true, otherwise it does not make any sense to continue.
3. Next, add the NDESgMSA account to the IIS_IUSRS group on the NDES host machine.
Configure CA Security Settings and Templates
Note : we are assuming for easiness that you are going to use the default templates. We recommend using custom (version 2) templates in production as stated at http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-n... .
1. Grant Read and Enroll permissions on Exchange Enrollment Agent (Offline Request) template to NDESAdmin.
2. Grant Read and Enroll permissions on CEP Encryption template to NDESAdmin .
3. Grant Read and Enroll permissions on IPSec (Offline Request) template to NDESgMSA and DeviceAdmin .
4. Publish all three templates on the Certification Authority.
Install NDES
Unfortunately, the setup wizard does not provide support for running the NDES application pool in the security context of a gMSA. That’s why we are processing the installation using more or less the default settings.
- On the NDES host machine, add the Network Device Enrollment Service as a role service for the Certification Authority role.
- Once the installation has completed, click Configure Active Directory Certificate Services to continue with the configuration of NDEs.
- On the Credentials screen, ensure that the NDES Admin account (which was created as part of the prerequisites) is selected.
- On the Role Service page, select Network Device Enrollment Service and click Next .
- On the Specify the service account page, select Use the built-in application pool identity . Click Next .
- On the Specify CA for Network Device Enrollment Service page, click Select . On Select Certification Authority, select the CA you are going to use with this NDES installation and click OK > Next .
- On the Type the requested information to enroll for an RA certificate page, click Next .
- On the Configure CSPs for the RA page, click Next .
- Finally, click Configure .
Alternatively, using the famous PowerShell:
Add-WindowsFeature Adcs-Device-Enrollment -includeManagementTools
Install-AdcsNetworkDeviceEnrollmentService -ApplicationPoolIdentity -CAConfig "CA02.fabrikam.com\FabrikamIssuingCA" -RAName "Fabrikam NDES RA" -RACountry "DE" -RACompany "Fabrikam" -SigningProviderName "Microsoft Strong Cryptographic Provider" -SigningKeyLength 2048 -EncryptionProviderName "Microsoft Strong Cryptographic Provider" -EncryptionKeyLength 2048
Post-Installation IIS Configuration
- Open Internet Information Service (IIS) Manager .
- Configure a binding for https using the host name and Server Name Indication (SNI)
Note: On Windows Server 2012, IIS supports Server Name Indication (SNI), which is a TLS extension to include a virtual domain as a part of SSL negotiation. What this effectively means is that the virtual domain name, or a hostname, can now be used to identify the network end point. This allows IIS to share IP addresses among SSL websites. However, it should be noted that if this feature is enabled, clients (in this case the mobile device itself or the MDM (Mobile Device Management Tool) not ready for SNI will not be able to contact NDES. Find more details about SNI at http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scal...
- Change SCEP application pool identity to the gMSA
Note that the NDES application pool is named “SCEP application pool” in IIS.
- Change ISAPI Handler order:
Note: The following steps are described in https://support.microsoft.com/en-us/kb/2800975
If you do not configure IIS in the way described by the knowledge base article mentioned above, your NDES installation will work upon first testing. But later you will find out that the device administrator role is unable to request a challenge password at the mscep_admin site (unless being added to the Enterprise Administrators group).
a. Still in IIS MMC, select the Default Web Site.
b. Click View Applications on the Actions pane on the right side.
c. Double-click Handler Mappings on the middle pane.
d. On the Actions pane, click View Ordered List…
e . On the Details pane in the middle, select ExtensionlessUrlhandler-ISAPI-4.0_64bit and click Move Down . Click Yes to move it below the StatifFile item .
f. Repeat steps a to f for the /Certsrv/mscep_admin application.
g. Restart IIS by typing iisreset on an elevated command prompt.
Configure permissions on private keys
Note: again, we assumed for easiness that you are going to use the default templates. If you followed our recommendations and prepared custom templates instead, you can skip this step.
During the initial configuration of NDES, two certificates were requested in the security context of the NDES Admin (account used to install NDES role service) and permissions on the corresponding keys were configured for the built-in app pool identity. However, we need to configure permissions to the keys for the gMSA:
a. Open local computer certificate store ( certlm.msc ) on the NDES machine
b. Right-click the CEP Encryption certificate , select All Tasks > Manage Private Keys
c. Add the NDESgMSA account and add the Read permission.
d. Repeat the steps a – c for the Exchange Enrollment Agent (Offline) certificate.
e. Restart IIS by typing iisreset on an elevated command prompt.
Additional Comments
Starting with Windows Server 2012 R2, NDES supports policy module integration which can provide additional security for the SCEP. This enhancement lets an organization or mobile device management solution address the issue described in CERT Vulnerability Note VU#971035 “Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests.” See http://www.kb.cert.org/vuls/id/971035 for more details on this vulnerability.
Find more details about the NDES Policy Module support at https://technet.microsoft.com/en-us/library/dn473016.aspx