Share This Post

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. (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 “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 : <PolicySecret Version=”1″><![CDATA[E600000001000000D08C9DDF0115D1118C7A00C04FC297EB0100000084634746C4A
CAD42BF62321AB60FD667000000000200000000001066000000010000200000004C1
F2CBCE7813F4FBB4195391FC1C36552FAE0BE1F2699BD8F7DE7082E79DEA60000000
00E8000000002000020000000D48AB5F8132C94035373AA9144AACEA17D7DE378E3B
9B4CBA8D30CF241C46CF0100000001BA268A390F4D108A482DD1414FA2C214000000
0641BCEFB43B525C54E279AB52583F440671C446970E393630853BCF3EB72F6E7895
436888D11B3C14D3578A3890866039D8CB5E85B84C5046D54063BDE45C6B5]]></PolicySecret>

NetworkAccessUsername : <PolicySecret Version=”1″><![CDATA[E600000001000000D08C9DDF0115D1118C7A00C04FC297EB0100000084634746C4
ACAD42BF62321AB60FD66700000000020000000000106600000001000020000000B
2228B890D478889DC5E7BD2129AD78E8FEDA750928E366AA3AA0AB8A013F7320000
00000E80000000020000200000004EF3230113F278B03BB8623887F1817F1F8A1BB
0C82FDD6B3A95D34FD52A56A510000000B444E88362956E2C5D3AFBAB14F9EAC140
0000006D6BC523E04FEDEBBD347246A003AAC28EF18B84C8C0237BDFF4F3DB9B839
58FB6448A47BF035C9FD48A86E1A7B6455028C96325499BF75EE8052CEB98071F92]]></PolicySecret>

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…

Share This Post

2 Comments

  1. Here’s why NAA’s are great: 🙂

    – If you have a disjointed namespace. That is, if your FQDNs do not match up with your AD domains (e.g. instead of myserver.addomain.com it’s myserver.mychicagooffice.contoso.com). With disjointed namespaces, Kerberos authentication can easily fail by not having the proper DNS lookups. NAAs are essential.

    – Anonymous is a terrible security idea, sorry. Unless you want all of your software walking out the door. That might work for a small shop I guess.

  2. Are you Monitoring the IIS logs on all your DP’s to identify Users who Access a DP directly? Domain Users have read Access anyway, so an NAA does not really protect your Software. And if you can get the NAA with Password from a Machine, why not just use this account to get the files ?

Leave a Reply