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

Author Uwe Gradenegger Posted on Categories Network Device Enrollment Service (NDES), Certificate usage Tags Certificate template, Internet Information Services (IIS), Registration Authority (RA), Group managed service account (gMSA)

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 certification 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 rule sets to 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 be downloaded via GitHub and used free of charge. Professional maintenance is also offered.

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

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 certification authority) and would thus be authorized to request certificates. Thus, other IIS application pools running on the same server would also be authorized to request certificates for the configured device template .

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 certification authority and without other roles on a dedicated server, this aspect does not matter in practice. Apart from that, it is recommended to configure the device template accordingly to accept only certificate requests that were signed 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 be granted access to the private keys of the Registration Authority certificates by script , which is not necessary with the other two options (there it can be controlled via certificate templates). Thus, no automatic enrollment and renewal of the RA certificates is possible with built-in tools (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 built-in tools 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 automated by a script that is executed on a regular basis.

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 one 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)

Like the integrated application pool identity, gMSAs have 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.

External sources