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:
Computer Configuration\Windows Settings\Local Policies\User Rights Assignment
Deny access to this computer from the network
Guests, Local account (*)
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.
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.
Hi Aaron, you refer to "pass the hash" techniques and refer to 2871997, where two Registry keys are referenced: DisableRestrictedAdmin and DisableRestrictedAdminOutboundCreds. In an earlier post (Security baselines for Windows 8.1, Windows Server 2012 R2 and Internet Explorer 11 - FINAL) you talk about the downloadable Security Baselines that include an Administrative Template called PTH. I get a bit confused here. It would seem that installing the security updates alone is not enough, one would also have to create the Registry keys. However, the ADMX does not feature the keys mentioned above but e.g. LocalAccountTokenFilterPolicy. I am missing further information on when to implement the PTH template and wonder why there is no template for the settings mentioned above. Did I miss out on some other article/white paper/instruction, or is there a lack of information here? (I did read the contents of the "documentation" folder of the Security Baselines article, and the Word document called "Blocking local accounts" looks kind of identical to this blog entry.)
[Aaron Margosis] The security guidance we released doesn't include recommendations either to enable or disable restricted admin, as that will be environment-dependent and you might also need to temporarily enable it on specific systems, which might be difficult if enforced through policy. We do recommend always disabling WDigest and locking down LocalAccountTokenFilterPolicy, and the PTH.ADMX (and corresponding US-English ADML) includes settings for both of those. WDigest is disabled by default in 8.1 and 2012 R2, but needs to be explicitly disabled on Win7, Win8, Server 2008 R2 and 2012.
The Word doc "Blocking local accounts" should be identical to this post. The Account Lockout document should match the account lockout blog post, too.
Would it be possible to get information which users are under S-1-5-113: NT AUTHORITY\Local account security identifier impact? Does Builtin\Users fall under Local account identifier?
[Aaron Margosis] Local user accounts, not groups.
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.
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.)
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.