Selecting the identity for the IIS Network Device Enrollment Service (NDES) application pool.

If one installs a Network Device Enrollment Service (NDES), one is faced with the question under which identity the IIS application pool should be operated. In the following, the individual options are examined in more detail in order to facilitate a selection.

The Network Device Enrollment Service (NDES) provides a way for devices that do not have an identifier in Active Directory (for example, network devices such as routers, switches, printers, thin clients, or smartphones and tablets) to request certificates from a certification authority. For a more detailed description, see the article "Network Device Enrollment Service (NDES) Basics„.

Assumptions

We base our decision-making on the following general conditions:

• NDES is installed on a separate server (not together with a certificate authority or other roles on the same server).
• No other roles are installed on the NDES server.
• It is possible that there are several certification authorities in the network to which different NDES servers are connected.

The possibilities

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

In total, there are three ways in which the IIS application pool can be configured.

• Using the IIS Application Pool Identity
• Using a domain account
• Using a Group managed Service Account (gMSA)

Details: IIS Application Pool

Using the IIS application pool has the following advantages:

• Virtually no configuration is required for setup.
• There is no need to change the password regularly, since the password of the underlying computer account is renewed automatically. This rules out attacks such as kerberoasting from the outset.
• Kerberos authentication against the fully qualified hostname of the NDES server is possible. If no alias is used, no service principal name needs to be used.

For NDES, however, the use of the IIS application pool identity is not recommended according to Microsoft's official reading. Why this is unproblematic in practice is explained below.

However, the recommended configuration is to specify a user account, which requires additional configuration

Network Device Enrollment Service Guidance (Microsoft Corporation)

The same statement is made by the configuration wizard for the NDES role:

However, in return, the IIS Management Console explicitly recommends using the IIS application pool. So what is true?

The recommendation not to use the IIS application pool identity for NDES is justified by the fact that other application pools that may exist on the same server and also use the respective application pool identity would also fall back to the computer account when accessing other hosts (i.e., in the specific NDES case, the connected certificate authority) and would thus be authorized to apply for certificates accordingly. Thus, other IIS application pools running on the same server would also be eligible for Certificate Enrollment for the configured Device template authorized.

The use of the IIS application pool identity is primarily intended for isolating various applications on the local host. However, since it is recommended to install NDES away from the certificate authority and without other roles on a dedicated server, this aspect does not matter in practice. Apart from that, it is recommended, configure the device template accordinglyto accept only certification requirements that are consistent with the corresponding Registration Authority Certificate (if configured correctly, only the identity of the "SCEP" application pool has access to its private key).

Clustering is not possible using the IIS application pool identity. However, since NDES does not support clustering anyway, this is also not relevant in practice.

A possible, albeit minor, disadvantage may be that the computer account of the NDES server must be authorized on the device certificate templates for Certificate Enrollment. Accordingly, any reinstallation or move of the NDES role to another server causes the need to re-authorize the new server on the device template, which would not be necessary with the other two options.

The IIS application pool must per script The user must be authorized to access the private keys of the Registration Authority certificates, which is not necessary with the other two options (there it can be controlled via certificate templates). Thus, no automatic application and renewal of the RA certificates is possible with on-board means (autoenrollment). However, since the NDES service has to be restarted after the certificate renewal anyway, this does not matter in practice. Similarly, it is not possible with on-board means to obtain the Registration Authority certificates specifically from the correct certification authority, since the selection is made randomly if there are several certification authorities with connected SCEP servers in the environment. However, both tasks can be performed by one scriptwhich is executed on a regular basis, can be automated.

Details: Domain account

A domain account must be actively managed, i.e. the password must be changed regularly. For Kerberos authentication to work, a service principal name (SPN) must be registered, which in turn can enable Kerberoasting.

Clustering is possible with domain accounts, but is not supported by NDES anyway.

A domain account may tempt to store the same service account on multiple NDES servers, which in turn may reduce overall security.

However, there are cases which require a domain account for NDES. For example the connector for Microsoft Intune works only if NDES uses a domain account.

Details: Group-managed Service Account (gMSA)

gMSA we have the integrated application pool identity the advantage that no regular manual password change is required. The gMSA manages its password automatically. Thus, attacks such as Kerberoasting are excluded from the outset.

Clustering is possible with a gMSA, but is not supported by NDES anyway.

Provided NDES is used in conjunction with Microsoft Intune, however, the use of a gMSA is not supported.

While the NDES role can be configured to run using a GMSA, the Intune Certificate Connector was not designed nor tested using a GMSA and is considered an unsupported configuration.

Conclusion

The least setup and operational effort is caused by using the IIS application pool identity for NDES. But then no other roles and services should be operated on the SCEP server.

The "most optimal" option is the group-managed service account, but it also entails the greatest setup effort and cannot be used in all cases.

Related links:

• Network Device Enrollment Service (NDES) Basics
• Configuring the Network Device Enrollment Service (NDES) to work with a Group Managed Service Account (gMSA).
• Configuring the Network Device Enrollment Service (NDES) for use with an alias.
• Configure Device Template for Network Device Enrollment Service (NDES)
• Using custom Registration Authority (RA) certificate templates for the Network Device Enrollment Service (NDES).
• The Certificate Connector for Microsoft Intune throws the error message "ArgumentException: String cannot be of zero length" during configuration.

External sources

• Network Device Enrollment Service Guidance (Microsoft Corporation)
• Application Pool Identities (Microsoft Corporation)
• Understanding identities in IIS (Microsoft Corporation)
• Service Accounts Step-by-Step Guide (Microsoft Corporation)
• New in IIS 7 - App Pool Isolation (Ken Schaefer)