Skip to main content

Considerations for Secure Credential Distribution in SCCM/MECM

Where can credentials be configured in Microsoft Configuration Manager, where do they end up on clients, and how should you configure these credentials so that they do not contribute to privilege escalation attacks in Active Directory?

At DEF CON 30, I talked about how certain credentials configured in Configuration Manager end up accessible to client software in plaintext and how to reimplement the cryptography used to protect these in transit[1]. Prior to this talk, a lot of previous work had also been published discussing these credentials and how to grab them off a system running an SCCM client.[2][3][4]

In my experience, many production deployments of Configuration Manager make use of features that require credentials to be configured to function, and these credentials are often granted administrative access in Active Directory, or to hosts joined to the same domain. This administrative access, for the most part, is overly permissive and not explicitly required. This is the key issue that contributes to this attack path being attractive to exploit in the first place; as such, it is worth documenting how to avoid this issue in an environment with SCCM installed.

Basics to Understand

  1. The Management Points (MPs) in a Configuration Manager site are the central source of truth for the configuration that gets sent to clients. Clients need to authenticate themselves to a management point to be able to prove that they are authorised to access this information.
  2. Once authenticated, clients request policy assignments from Management Points and can download the policies assigned to them.

These policies contain settings that enable the various features of Configuration Manager to work. One notable example of this, is that if a client, in an operating system deployment (OSD) scenario, is configured to join a domain, there will be a policy available to this client that will contain the credentials used to perform this domain joining

By imitating a client, and asking for the relevant policies, an attacker would be able to extract credentials that are distributed to clients in this way; this is, in effect, what PXEThief[5] does after it obtains a valid OSD certificate, or what sccmwtf/SharpSCCM[6][7] does after registering a new valid certificate with SCCM. This is important to understand, as it is the main reason why this is not a vulnerability that MS can patch. In order to implement the functionality that the client provides, it needs access to credentials, and there can be no way that these credentials are transmitted where the client will not need to end up with cleartext access to them.

Credentials sent to the client

There are three main places where configured credentials are sent to Configuration Manager clients (that I know of):

  • Any configured Network Access Accounts
  • Task Sequence steps that need credentials
  • Collection Variables

As a side note, it is worth remembering that the content of any package, application or script distributed to client computers via Configuration Manager will be accessible to those computers, by design. The contents of these packages are accessible on disk, and, functionally, clients need to be able to authenticate to Distribution Points (DPs) to download and execute this content locally. Thus, if any of these include hardcoded or embedded credentials or certificates, these can be exposed by analysing the distributed content. Ideally avoid hardcoding credentials with any level of privilege in these kinds of packages.

Exposure of credentials for Network Access Accounts, Task Sequences, and Collection Variables

These three types of credentials are distributed as policies to applicable ConfigMgr clients, as described below in Table 1:

Table 1: Exposure of Client-exposed Credentials Configured in Configuration Manager
Where are these credentials configured?
Network Access Accounts

Network Access Accounts are a site-wide setting that is set by right-clicking on the Site under Site Configuration (\Administration\Overview\Site Configuration\Sites) and selecting the sub-option Configure Site Components -> Software Distribution Component. The Network Access Accounts configured for the site can be set in the Network Access Account tab; the specific screen where this is set is shown in Figure 1. The interesting thing to note about these is that multiple accounts can be set here and all of these will be sent to every authenticated ConfigMgr client.

Figure 1: Network Access Account Configuration
Task Sequence Accounts

For Task Sequences, credentials can be configured in individual Task Sequences[see 8 for an example]. Task Sequence creation and editing can be reached from the \Software Library\Overview\Operating Systems\Task Sequences path in the SCCM console. From here, new Task Sequences can be created from the Create New Task Sequence button in the top ribbon, or can be edited by selecting the desired Task Sequence and using the Edit context option.

  1. “Task sequence domain join account”

Task sequences can be deployed to domain join a machine. This is typically included as part of the automation of Operating System Deployment that can be set up in Configuration Manager. As with every onsite AD domain join, credentials with the appropriate rights need to be provided to a machine to allow it to authenticate to a domain controller to perform this task. The specific task sequence step where this can be configured can be seen in Figure 2.

Figure 2: Configuration of the Task Sequence domain join account
  1. Credentials for storing captured OS images on a network share

One of the features that Configuration Manager supports is the ability to image a machine (with all its installed software, patches, and configuration) and save the resultant image to a network drive to serve as the base image for a new Windows installation. Authenticated network shares are supported, since credentials can be configured in this Task Sequence step that will be used to save the captured image to the specified file share. This is shown in Figure 3.

Figure 3: Configuration of the Task Sequence Capture OS Account
  1. Local administrator credentials for the machine

When deploying a new machine using Task Sequences in Configuration Manager, it is possible to enable and set the default local administrator password on the machine. Specifically, this is the password for the RID 500 local Administrator account. The relevant Task Sequence step where this can be done is shown in Figure 4.

Figure 4: Configuration of Local Administrator account during a Task Sequence
  1. “Task sequence run as account”

As with the “runas” command on a standard Windows workstation, it is possible to log into a new machine that is being built, as a domain user, and run commands under their authenticated context[9]. It is possible to do this for standard Windows commands and PowerShell scripts. Configuration for this functionality is shown in Figure 5.

Figure 5: Configuration for running a Windows command during a Task Sequence
  1. “Task sequence network folder connection account”

As part of the deployment of a machine, it may be advantageous to connect to a file share and copy, access, or write to a file used in the execution of a future Task Sequence step. To allow this, Configuration Manager supports the ability to specify network folder connection accounts that will be used to connect to a specified network share[10]; an example of the relevant Task Sequence step is shown in Figure 6.

Figure 6: Configuration for connecting to a network share during a Task Sequence
Collection Variables

Configuration Manager allows configuration settings (such as Task Sequences), updates, and software packages to be applied to specific groups of systems or users. In Configuration Manager, groups of users or systems are called Collections.[11]

One of the configuration settings that can be applied to these collections is custom environment variables that are only exposed to members of the collection; these are called Collection Variables.

Nothing specifically requires that these variables be credentials, but they can be used for this purpose and, in transit, they are encrypted by Configuration Manager in the same way as credentials.

As an example, collection variables for devices can be configured from the properties dialog of a collection displayed on the device collection settings screen, \Assets and Compliance\Overview\Device Collections, in the Configuration Manager console. This can be seen in Figure 7.

Figure 7: Collection variables configuration screen for the “All Mobile Devices” collection

Configuration advice

For each of these scenarios, specific and careful configuration can eliminate most of the risk associated with using these Configuration Manager features, without impacting their usefulness too adversely.

The key principle to note about many of the security concerns raised concerning these Configuration Manager features relate to the privileges granted to the Active Directory accounts used. If privileged accounts are exposed through these features, then exposure of the credentials can lead to widespread compromise in the AD environment(s) in which Configuration Manager is installed.

Therefore, one of the key elements of addressing this is understanding how each of these features uses its accounts, so that configured accounts can be made to have the least privileges possible.

General Configuration Advice
  • Take care of which Configuration Manager features you use and only use the ones you know you need.
  • Use dedicated accounts for each unique feature in Configuration Manager. This will allow you to assign these accounts the minimum permissions that they need, promoting the principle of least privilege.
  • Make sure all Configuration Manager accounts have unique passwords (you don’t want your NAA leaking the credentials to your SCCM administrator account through password reuse!).
Network Access Account Configuration Advice

Key Points for Network Access Account Configuration

  • Kill the NAA in your environment and use Enhanced HTTP instead.
  • Make sure to change the credentials or disable the account(s) used for the NAA after making the switch to Enhanced HTTP[12] to make sure that artifacts of the old password lying around on the network are not useful.
  • If you must use the NAA, make sure it does not have any administrative rights to any systems in the environment.

Detailed discussion of these points follows.

Using Enhanced HTTP in place of the NAA

Of all the ways of disclosing credentials discussed earlier, Network Access Accounts are a special case. For the most part, they can be eliminated entirely without affecting any commonly used Configuration Manager functionality in a modern deployment. This is because they have been deprecated by Microsoft in favour of Enhanced HTTP.

We can understand why this is possible by analysing what the NAA is used for and the alternative mechanism that Microsoft has provided. The NAA is used to download content (software, scripts, etc) from Distribution Points. DPs authenticate clients attempting to download this content, using NTLM or Kerberos authentication against an HTTP endpoint. For clients running on domain-joined machines, this is not an issue, as the Configuration Manager client is running under the SYSTEM context and can simply use the computer’s machine account for this authentication. However, for a client running in WinPE, which is naturally not domain-joined, it must use the NAA for AD authentication.

Enhanced HTTP has removed the requirement for NTLM or Kerberos authentication and replaced it with a token-based authentication scheme that does not rely on domain credentials at all. (My best guess, at the time of writing, is that Enhanced HTTP relies on the certificate distributed to the WinPE environment to generate the token or to somehow ask the MP for the token. This is an area open for reversing and reimplementation, just like the certificate authentication used for downloading policies from MPs.) By enabling Enhanced HTTP on DPs, this alternative authentication scheme becomes available, and all approved Configuration Manager clients can use it instead of the NAA to download content.

  1. Configuring Enhanced HTTP

Enhanced HTTP is set on a per site basis. After navigating to the Site Screen under \Administration\Overview\Site Configuration\Sites, rightclick on the site and select Properties. On the properties screen, select the Client Computer Communication tab and enable the option Use Configuration Manager-generated certificates for HTTP site systems. This option is shown in Figure 8.

Figure 8: Enabling Enhanced HTTP through the Site properties dialogue
  1. After switching to Enhanced HTTP, delete all the entries for NAAs and then change the password for these accounts or disable them

As discussed by SpectreOps, the NAA is stored in the WMI repository on all machines running ConfigMgr clients. This repository can be accessed by any user with administrative access on a host running a Configuration Manager client (refer to [4] for the gory details). Even after deleting credentials from the Site’s Network Access Account configuration, it appears that it is not likely or guaranteed that the credentials will be deleted from the local WMI repository on hosts. This is related to how WMI works and, as of publishing this blog post, Microsoft had not resolved this issue. As a result, any legitimate credentials configured as a Network Access Account should be considered exposed and should be treated the same as any other service account that is known to be compromised. Changing the credentials and/or disabling the account is an effective remediation. If concerned that unauthorised parties may have abused these credentials, some investigation can also be performed on the use of the account to determine whether any malicious activity was performed using the account.

  1. If you must use the NAA, least privilege it as soon as possible

There are some scenarios where the NAA must still be used; these are shown in Figure 9:

Figure 9: Actions that require the NAA – Source:[16]

If your installation of Configuration Manager falls into one of these scenarios, evaluate whether this functionality is required and if it is, follow the configuration advice MS gives at Most critically, this specifically involves stripping all administrative access from the NAA. The account only needs to be a valid, low privilege, domain account and can be restricted to only be able to authenticate to the SCCM DPs.

Task Sequence Accounts Configuration Advice
1.  “Task sequence domain join account”

This account only needs the permission to create a computer account in a specified OU. The specifics around how computer accounts should be handled after they are joined to the domain is context-specific, but it is likely a good idea to establish a defined process around this that will cater for ensuring that the device ends up in the right OU with the right GPOs applied to it for its purpose in the business. As part of this process, entries could potentially be made to ensure the device is appropriately noted in the organisation’s asset register.

Additionally, in certain scenarios when a device is joined to a domain, the account used to perform this action is granted Owner permissions over the object, which grants this account Full Control of the domain computer object. I have commonly seen this to be the case in production environments that make use of automated domain joining through Configuration Manager Task Sequences. This configuration can be leveraged to compromise the computers deployed in this way through the use of Resource-Based Constrained Delegation[13] or reading the LAPS password of the machine[14]. Given that the cleartext password for the “Task sequence domain join account” is exposed in the policies available to PXE clients, it is not appropriate to allow this account to maintain Owner rights (or All Extended Rights) over the computer accounts it joins to the domain. This privilege should rather reside with a privileged account or group, which has less exposure. The Domain Admins group would, generally, be appropriate to set as the Owner of all domain computer objects in the AD database, since members of this group should have minimal or no credential exposure across the network for Active Directory to be considered secure.

2. Credentials for storing captured OS images on a network share

Privileges for the OS image capture account should be restricted to being able to write to the configured network share and should be granted no other rights. It should only be a member of the default Domain Users group, and ideally is only able to authenticate to the file server intended to store captured images. As a defense-in-depth measure, OS images captured to a network share should be quickly moved to a more secure location, inaccessible to this account, to prevent the captured images being overwritten with backdoored images.

3. Local administrator credentials for the machine

Setting the local administrator account password on a machine using the SCCM functionality that supports this is, in general, a bad idea. Use of this functionality will re-enable the RID 500 local administrator account and will set it to a common password on all the computers built using the relevant Task Sequence. This would allow it to more easily be discovered and abused for lateral movement – most notably using Pass-the-Hash techniques[15]. A far better technique to manage local administrator passwords would be to use LAPS[14], or one of the PAM solutions that support management of local accounts on workstations; this is better because both solutions should allow setting unique passwords on each workstation on the network, which prevents abuse of the RID 500 local administrator account for lateral movement.

4. “Task sequence run as account”

This is general purpose functionality that accepts an arbitrary account as input and needs whatever permissions the specified command requires to complete successfully. Specific recommendations around restricting the privileges of the account are thus hard to provide. However, it should be remembered that the plaintext password of the configured account is exposed to authorised SCCM clients. Appropriate configuration thus requires the account to be granted the least privileges possible and, specifically, it should not have any kind of administrative rights to any systems or applications. Where possible, the “run as” functionality in SCCM should not be used at all and any account previously used for this purpose should be considered exposed and potentially compromised.

5. “Task sequence network folder connection account”

The purpose of connecting to a network share during Task Sequence execution is dependent on the purpose of the file share that you are connecting to. Whether it is for reading from or writing to files on the share, it is worth considering the principle of least privilege here too. The account used for this Task Sequence step should only be granted permissions to the target shared folder and should not have any administrative rights or any interactive sign-in rights to any systems or applications in the environment.

Collection Variables Configuration Advice

Collection variables offer a large degree of flexibility in distributing environment variables to certain groups of computers. These can be configured with arbitrary strings, including credentials. As a rule, it should be kept in mind that the cleartext of these Collection Variables can be obtained from endpoints, as well as by downloading and decrypting policies from Configuration Manager MPs. Thus, where possible, credentials should not be stored in these variables at all and alternate distribution mechanisms should be considered, particularly ones that allow for changing passwords on a regular basis, such as a PAM solution.


Configuration Manager continues to be a powerful and useful tool that allows administrators to operationally manage the large scale onsite Active Directory environments used by many companies. It needs careful and considerate configuration, however, to prevent disclosure of sensitive credentials for certain types of accounts. This, especially, needs to be considered for the credentials discussed in this blog post, as they are known to be distributed to large numbers of Configuration Manager clients. Appropriate set up for these accounts would ensure that these credentials:

  • are always granted the least privileges possible,
  • are unique accounts for each Configuration Manager feature, and
  • have unique passwords set on each account.

Following these configuration guidelines will help prevent Configuration Manager deployments from introducing insecurity into the environments they are used in.