Network Access Accounts are evil….

Most of the System Center Configuration Manager Environments do have a Network Access Account defined and I’ve found many that are using a privileged account for that (some with Domain Admin as NAA)…
It’s time to explain why Network Access Accounts (NAA) are evil.

What is a NAA doing ?

The Network Access Account is used by client computers when they cannot use their local computer account to access content on distribution points. For example, this applies to workgroup clients and computers from untrusted domains. This account might also be used during operating system deployment when the computer installing the operating system does not yet have a computer account on the domain. (

So it’s only there to authenticate against the DP’s if the System Account is not valid. For that reason, the account must just be a Domain User and nothing else. It does not need to have any special rights, it must just be a valid account.

What is now the problem with an NAA ?

When a CM12 Agent is joined to a Site, one of the first policies it gets is the NAA. The Policy is stored in the WMI Namespace “rootccmpolicyMachineActualConfig” in the Class “CCM_NetworkAccessAccount”. With the following PowerShell, you can dump the NAA’s (there can be more than one):

Get-Wmiobject -namespace “rootccmpolicyMachineActualConfig” -class “CCM_NetworkAccessAccount”

The result will look like:
NetworkAccessPassword :

"<![CDATA[E600000001000000D08C9DDF0115D1118C7A00C04FC297 EB0100000084634746C4ACAD42BF62321AB60FD66700000000020000

NetworkAccessUsername :

"<![CDATA[E600000001000000D08C9DDF0115D1118C7A00C04FC297 EB0100000084634746C4ACAD42BF62321AB60FD66700000000020000

As you see, the Username and Password is “encrypted” and should be save for “normal” users….
But: The CM Agent must be able to decode the strings… and if you know how the CM Agent is doing that, then you know how to decode the Username and Password. I will not publish any details here, but it’s possible with a few lines of code (e.g. PowerShell) to get the values in clear text.

That means: every machine with a CM12 Agent that is attached to a CM Site has that Username and Password… and bad Guys can take that Username and Password if they have access to the machine (I have to mention that you need local Admin rights to get the details…). Or they can assign the CM Agent on a machine to your CM12 Site and they will get a Username and Password for your Domain ….

What can be done to reduce the risk?

1) Never use a privileged Account as NAA; Use a NAA that is Domain User only with disabled Interactive logon is the recommended option. (

2) Manually approve each CM12 Agent or at least trust only Agents from your Domain (Default value). Do not auto approve all Agents.

3) Do not use a NAA (see next section…)

Is is possible to NOT use a NAA?

Yes, a NAA is only there to authenticate against the DP’s if the Machine is not in the Domain (e.g. during OSD). If you enable anonymous access on your DP’s, authentication is no longer required on the DP and the NAA is not required.image

Enabling Anonymous access on the DP’s has some side effects that you must be aware of:


  • No authentication Problems during OSD, from Workgroup or untrusted domains
  • Windows Installer Source update can be used in untrusted domains or workgroups (msiexec does not need to authenticate to get the files from the DP)
  • You can auto approve all your CM Agents (No Risk, because no NAA)
  • No NAA required


  • Everyone has access to the content of your DP’s (if they know the URL).
  • You cannot Audit access on the DP, you just get the IP of the Agent but no Username.

What is recommended ?

There is no true or false, you have to discuss this with your security officer…

I prefer the „anonymous” access on the DP’s because it makes processes simpler (no locked NAA Accounts or other authentication problems during OSD ) and you can enable auto approval for all Agents…