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 (13)

  1. 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.

  2. cascomp says:

    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.

  3. gpo says:

    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.

  4. Peter says:

    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.

  5. tony says:

    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.)

  6. Jeff25 says:

    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.

  7. MA says:

    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.

  8. DB says:

    I'm struggling to understand how the member server can be managed if the DA group is added to this policy? Only through use of the builtinAdministrators group? If that's the case, how can this be practically done? I can only envision setting up another sec group with the appropriate accounts of those in charge of managing these servers and then setting another GPO that adds this group to the builtinAdministrators group for all servers in the scope of these GPOs. Am I on track here or still missing something?

    [Aaron Margosis] Domain Admin accounts should be used only to administer Active Directory and domain controllers. See http://www.microsoft.com/pth.

  9. TheTester says:

    “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 7

    How to use Web Deploy for administration of Application Pools by Non Administrators

    1. TheTester says:

      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?
      1. TheTester says:

        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: 0x84141C7

        Logon Type: 8

        Account For Which Logon Failed:
        Security ID: NULL SID
        Account Name: WDeployConfigWriter
        Account Domain: SERVER04

        Failure Information:
        Failure Reason: The user has not been granted the requested logon type at this machine.
        Status: 0xC000015B
        Sub Status: 0x0

        Process Information:
        Caller Process ID: 0x2614
        Caller Process Name: C:\Windows\System32\inetsrv\WMSvc.exe

        Network 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

      2. TheTester says:

        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.

  10. Fczajka says:

    Hi Aaron,

    I understand what it is you are doing, what I don’t get is why I would want to implement something like this in the first place. The reason MS rules the business world is exactly what you are cutting out here: ease of administrative access to the machines I have to manage. I have followed recommended security processes back to the NT 4.0 days and this really leaves me scratching my head. What you are saying as practical result is that local accounts can not access remote resources on network. When my server falls out of the domain, but policy is still enforced I can not reset the machine accounts password. I guess I could kill the profile (i.e. more hoops) and then login again to fix the issue. Not what I think of when speaking ease of administration when comparing to Linux/Unix/Apple based solutions. Matter of fact this moves the Windows world much closer to those from an administrative POV.

    Next you recommended that DA/EA be removed from the Member Servers local Administrators group. So now what? Do I have a “SO” account for DCs, a “SO” account for Member servers, a “SO” account for Workstations, and finally a “User” account for non-administrative functions? I know I can use Domain policy to do, but aren’t we just heaping layers upon layers of policy that really hard to trace when you are troubleshooting an issue?

    Smart password management on you machines in general sounds like a much better solution. Heck I scripted cusermgr.exe back in the day to update 13000 desktops and 1200 servers accounts 20 call centers back in late 90’s to update my member servers every 30 days and desktops every 60 days (an audit requirement). I have worked with a certain firm (after the fact) who lost a massive number of HDD’s from a “pass the hash” attack. Even they understand that their admin accounts need access to machines across the network. I was impressed with the multiple solutions implanted to harden their environment.

    I fully understand the security implications both ways, I am just not sure if this is a wise recommendation from MS prospective.

    [Aaron Margosis] A few things: when this post was written, LAPS had yet to be released and it was very common for all machines in an environment to share a common administrative local account/password. Compromise of any computer could then easily lead to compromise of all machines without having to acquire the credentials of a privileged domain account such as a domain admin. With LAPS or another solution to randomize the passwords of administrative local accounts, it’s much less important to block the remote use of local accounts.

    This guidance doesn’t recommend taking DA/EA out of the Administrators group. It does recommend denying the types of logons that can expose those privileged credentials (i.e., all logon types except for network logon). DA/EA accounts should be used only to administer DCs and AD. See our Pass the Hash / Credential Theft whitepapers for more information: http://www.microsoft.com/pth

    Final point: ease of administration is one of the reasons everyone always used to run as admin. As threats evolve, we have to change how we work. Credential hygiene — not exposing privileged credentials on less-trusted and higher-risk systems — has become a critical necessity.