What Accounts Should I Be Using?

Something which I have seen recently on a few occasions is that customers using the same credentials for ConfigMgr Client Push account and the Network Access Account. Sometimes, for simplicity sake the account is even a member of Domain Admins. It’s actually really important that these two needs are not covered by the same user account and even more so that they are not Domain Admins!

  The ConfigMgr Client Push Account (https://technet.microsoft.com/en-us/library/bb632779.aspx)

 For ConfigMgr client push to work, the ConfigMgr Site Server needs to connect to the ADMIN$ share of the prospective client computer. Once it has done this the ConfigMgr server will then copy down CCMSETUP.EXE and set that to operate as a service. CCMSETUP then starts and manages the rest of the installation. In order to do this the ConfigMgr Client Push Account needs to have local admin permissions on the prospective client computer.

  The Network Access Account (https://technet.microsoft.com/en-us/library/bb680398.aspx)

 Now that we have the client software installed, the client will download its policy and store it in WMI. Something that is very likely to happen is that we will want to distribute some software to the client computer. When a client is a member of a Microsoft Active Directory Directory Services domain then it will authenticate to a Distribution Point through its computer account and access the content. What happens however if the client is a member of a non-trusted domain, or is a workgroup member, or in a Windows PE build because we are deploying an operating system using System Center Configuration Manager at this time? Well, that’s what the Network Access Account is there for. We download those credentials as policy and store them in encrypted format as part of the client’s policy.

 Really all we need to do is create an account within Active Directory Directory Services and grant no additional access permissions to it. The account should not be able to logon interactively and it should not be able to add computers to the domain. It certainly should be in no other groups than Domain Users.

 So, what’s the problem?

 If someone is able to connect to WMI and read these credentials from WMI then under normal circumstances all they will have learned are the names of an account with mediocre permissions. If you have elevated the Network Access Account then the attacker could use this account to try and access more useful data.

 This post was contributed by Jason Wallace, a Premier Field Engineer with Microsoft Premier Field Engineering, UK

Comments

• Anonymous
  January 01, 2003
  James Thanks for that question. You are quite right - the ConfigMgr client is a service which executes in the security context of Local System so no matter how you choose to install it you'll need to be an administrator. In the case of a DC the only way that you CAN do this is to make it a domain admin.  My basic point however that the CPA and NAA should not be the same account remains. Now it's a personal preference but I would suggest that one is very careful indeed in putting either a ConfigMgr client or a ConfigMgr server on a Domain Controller. In the case of ConfigMgr 2007 I would suggest a totally different site and judicious use of Access Control Lists. From time to time I am asked whether for a small office a ConfigMgr server can be installed on a DC. Firstly I question whether with Branch Cache we even need a site server in a small branch but if we do then why not take advantage of the Hyper-V licensing and separate out the workloads onto 2 VMs? Jason

• Anonymous
  January 01, 2003
  While I can completely understand the Network Access requirement - what about if I want to be able to perform client push to a domain controller? By it's very nature the client push account would need to be a member of Domain Admins (or have equivalent permissions), would this not be a recommended configuration then?