Network Access Accounts are evil….

Roger Zander

• 3 min read

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. (https://technet.microsoft.com/en-us/library/hh427337.aspx)

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 "root\ccm\policy\Machine\ActualConfig" in the Class "CCM_NetworkAccessAccount". With the following PowerShell, you can dump the NAA’s (there can be more than one):

Get-Wmiobject -namespace "root\ccm\policy\Machine\ActualConfig" -class "CCM_NetworkAccessAccount"

The result will look like:
NetworkAccessPassword :

"<![CDATA[E600000001000000D08C9DDF0115D1118C7A00C04FC297
EB0100000084634746C4ACAD42BF62321AB60FD66700000000020000
0000001066000000010000200000004C1F2CBCE7813F4FBB4195391F
C1C36552FAE0BE1F2699BD8F7DE7082E79DEA6000000000E80000000
02000020000000D48AB5F8132C94035373AA9144AACEA17D7DE378E3
B9B4CBA8D30CF241C46CF0100000001BA268A390F4D108A482DD1414
FA2C2140000000641BCEFB43B525C54E279AB52583F440671C446970
E393630853BCF3EB72F6E7895436888D11B3C14D3578A3890866039D
8CB5E85B84C5046D54063BDE45C6B5]]>"

NetworkAccessUsername :

"<![CDATA[E600000001000000D08C9DDF0115D1118C7A00C04FC297
EB0100000084634746C4ACAD42BF62321AB60FD66700000000020000
000000106600000001000020000000B2228B890D478889DC5E7BD212
9AD78E8FEDA750928E366AA3AA0AB8A013F732000000000E80000000
020000200000004EF3230113F278B03BB8623887F1817F1F8A1BB0C8
2FDD6B3A95D34FD52A56A510000000B444E88362956E2C5D3AFBAB14
F9EAC1400000006D6BC523E04FEDEBBD347246A003AAC28EF18B84C8
C0237BDFF4F3DB9B83958FB6448A47BF035C9FD48A86E1A7B6455028
C96325499BF75EE8052CEB98071F92]]>"

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. (https://technet.microsoft.com/en-us/library/hh427337.aspx)

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

  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:

Pros:

  • 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

Cons:

  • 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…

Sign up for more like this.

Enter your email
Subscribe