Blocking Remote Use of Local Accounts

The use of local accounts for remote access in Active Directory environments is problematic for a number of reasons. By far, the biggest problem is that when an administrative local account has the same user name and password on multiple machines, an attacker with administrative rights on one machine can easily obtain the account’s password hash from the local Security Accounts Manager (SAM) database and use it to gain administrative rights over the other machines using “pass the hash” techniques.

Our latest security guidance responds to these problems by taking advantage of new Windows features to block remote logons by local accounts. Windows 8.1 and Windows Server 2012 R2 introduced two new security identifiers (SIDs), which are also defined on Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012 after installing KB 2871997:

S-1-5-113: NT AUTHORITY\Local account

S-1-5-114: NT AUTHORITY\Local account and member of Administrators group

The former SID is added to the user’s access token at the time of logon if the user account being authenticated is a local account. The latter SID is also added to the token if the local account is a member of the BUILTIN\Administrators group. These SIDs can grant or deny access to all local accounts or all administrative local accounts – for example, in User Rights Assignments to “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services”, as we recommend in our latest security guidance. Prior to the definition of these SIDs, you would have had to explicitly name each local account to be restricted to achieve the same effect.

In the initial release of the Windows 8.1 and Windows Server 2012 R2 guidance, we denied network and remote desktop logon to “Local account” (S-1-5-113) for all Windows client and server configurations, which blocks all remote access for all local accounts.

We have since discovered that Failover Clustering relies on a non-administrative local account (CLIUSR) for cluster node management and that blocking its network logon access causes cluster services to fail. Because the CLIUSR account is not a member of the Administrators group, replacing S-1-5-113 with S-1-5-114 in the “Deny access to this computer from the network” setting allows cluster services to work correctly while still providing protection against “pass the hash” types of attacks by denying network logon to administrative local accounts.

While we could keep the guidance as it is and add a “special case” footnote for failover cluster scenarios, we will instead opt to simplify deployments and change the Windows Server 2012 R2 Member Server baseline as follows:

Policy Path	Computer Configuration\Windows Settings\Local Policies\User Rights Assignment
Policy Name	Deny access to this computer from the network
Original Value	Guests, Local account (*)
New Value	Guests, Local account and member of Administrators group (*)

(*) The guidance also recommends adding Domain Admins and Enterprise Admins to these restrictions except on domain controllers and dedicated admin workstations. DA and EA are domain-specific and can’t be specified in generic GPO baselines.

Note that this change applies only to the Member Server baseline and that the restriction on remote desktop logon is not being changed. Organizations can still choose to deny network access to “Local account” for non-clustered servers.

Note also that the restrictions on local accounts are intended for Active Directory domain-joined systems. Non-joined, workgroup Windows computers cannot authenticate domain accounts, so if you apply restrictions against remote use of local accounts on these systems, you will be able to log on only at the console.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  September 04, 2014
  So, does this value mean, "Guests, Local account[s], members of Administrators group", or does it mean "Guests, Local accounts who are members of Administrators group"? The former makes remote administration challenging. The later would still allow administrators with domain credentials which is a common need but also allow local account who are not administrators (which may be a different -- though, lesser -- problem). [Aaron Margosis]  It means the latter.  S-1-5-113 ("Local account") refers to all local accounts.  S-1-5-114 ("Local account and member of Administrators group") refers to administrative local accounts.  Neither has any impact on domain accounts.  BTW, you can see these new pseudo-groups in the security editor "Select User or Group" dialogs.

• Anonymous
  October 23, 2014
  Would it be possible to get information which users are under S-1-5-113: NT AUTHORITYLocal account security identifier impact? Does BuiltinUsers fall under Local account identifier? [Aaron Margosis]  Local user accounts, not groups.

• Anonymous
  October 30, 2014
  I need to know the german names for the new SIDs to enter these Accounts in my GPOs. [Aaron Margosis] According to colleagues, the names are Lokales Konto and Lokales Konto und Mitglied der Gruppe "Administratoren".  However, the GPOs show those names only for display purposes; the security template, which is a Notepad-editable file, stores the SIDs.  You can hand-edit the files and put in *S-1-5-113 or *S-1-5-114.  The GPOs will then show the localized name(s) for your system. Hope this helps.
  

• Anonymous
  February 27, 2015
  Is the setting 'UAC Remote Restrictions' (KB951016) enabled by default? Is it trivial to bypass UAC remote restrictions? How is UAC Remote Restrictions different from blocking local admin accounts in group policy? [Aaron Margosis] By default there is no LocalAccountTokenFilterPolicy value in the registry, so the restrictions described by the KB article are enforced.  We recommend explicitly enforcing that default through Group Policy.  That way if anything sets the value to "1" to remove the restrictions, the next GP refresh should restore the desired behavior. The new policies introduced in 8.1 and 2012R2 and on downlevel systems with KB 2871997 allow even better enforcement, blocking the logon entirely instead of just restricting it, and also applies to the built-in "-500" admin account, which LocalAccountTokenFilterPolicy might or might not (depending on whether UAC's admin approval mode is applied to that account.)
  

• Anonymous
  March 23, 2015
  This post really lit a lightbulb about local account AND member of administrators group. Thanks
  Also I'm really impressed by your contributions to the comments and queries raised by your readers. Kudos.
  

• Anonymous
  October 20, 2015
  Hi, does this also reliably disable the remote logon via the builtin local SID 500 administrator account?
  Reading http://www.pwnag3.com/2014/05/what-did-microsoft-just-break-with.html it looks like this policy does does not apply to this special account. [Aaron Margosis] No, the author of that post completely misunderstood what he was looking at. UAC token filtering is responsible for what he's seeing and it's been like that since Vista came out. KB2871997 doesn't add any blocks against local accounts automatically -- it adds two new SIDs that you can use, but it doesn't apply them to any policies.

• Anonymous
  November 03, 2015
  The comment has been removed

• Anonymous
  July 08, 2016
  "Deny access to this computer from the network for non-domain local accounts" is not compatible with Web Deploy, because it uses a local admin account for IIS Management :-(Any advice?For search engines and other users:A tracing deployment agent exception occurred that was propagated to the client. Request ID 'b96b5193-080c-4fc9-b7d9-71a1766052f5'. Request Timestamp: '2016-07-07 16:15:27'. Error Details:Microsoft.Web.Delegation.DeploymentAuthorizationException: Not able to log on the user '.\WDeployConfigWriter'. ---> System.Runtime.InteropServices.COMException: Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0x80070569)[Aaron Margosis] I haven't done web dev in a long time, but a couple of colleagues offered links that show how to use domain accounts instead of local for this purpose:Installing and Configuring Web Deploy on IIS 7How to use Web Deploy for administration of Application Pools by Non Administrators

  • Anonymous
    July 10, 2016
    Hi Aaron: Thanks for quick reply :-)I checked these 2 links, but they only describe the normal functionality of WebDeploy (giving domain users that are non-admins access to IIS), but no information how to change the service accounts used by WebDeploy :-/[Aaron Margosis] Do you need to change those? The baseline doesn't deny service or batch logon to local accounts. Does IIS also try to perform network logons with those accounts?
    • Anonymous
      July 12, 2016
      I am not sure who does logon (looks like Web Management Service?), but I can supply the security event log entry:An account failed to log on.Subject: Security ID: CONTOSO\someUser Account Name: someUser Account Domain: CONTOSO Logon ID: 0x84141C7Logon Type: 8Account For Which Logon Failed: Security ID: NULL SID Account Name: WDeployConfigWriter Account Domain: SERVER04Failure Information: Failure Reason: The user has not been granted the requested logon type at this machine. Status: 0xC000015B Sub Status: 0x0Process Information: Caller Process ID: 0x2614 Caller Process Name: C:\Windows\System32\inetsrv\WMSvc.exeNetwork Information: Workstation Name: SERVER04 Source Network Address: - Source Port: -Detailed Authentication Information: Logon Process: Advapi Authentication Package: Negotiate Transited Services: - Package Name (NTLM only): - Key Length: 0
    • Anonymous
      August 29, 2016
      According to http://www.windowsecurity.com/articles-tutorials/misc_network_security/Logon-Types.html, Logon Type 8 is NetworkCleartext. And WebDeploy needs an admin account to perform its duties.

• Anonymous
  August 26, 2016
  The comment has been removed

• Anonymous
  May 02, 2017
  How can I add this user group. I tried several times and had no success.