4 min read
Windows gives you several ways to control which computers can be logged onto with a given account. Leveraging these features is a critical way to defend against persistent attackers. By limiting accounts to appropriate computers you can:
- Enforce written policies based on best practice
- Slow down or stop lateral movement by attackers
- Protect against pass-the-hash and related credential harvesting attacks
The first place to start using this mitigation technique is with privileged accounts. And the easiest way to restrict accounts to specified computers is with the allow and deny logon rights. In Group Policy, under User Rights, you will find an “allow” and “deny” right for each of Windows’ five types of logon sessions:
- Local logon (i.e. interactive logon at the console)
- Network logon (e.g. accessing remote computer’s file system via shared folder)
- Remote Desktop (i.e. Terminal Services)
- Service (when a service is started in the background, its service account is logged on in this type of session)
- Batch (i.e. Scheduled Task)
Of course, if an account has both “Logon locally” and “Deny logon locally,” the deny right will take precedence. By careful architecture of OUs, group policy objects and user groups, you can assign these rights to the desired combinations of computers and users.
But because of the indirect nature of group policy and the many objects involved it, can be complicated to configure the rights correctly. It’s easy to leave gaps in your controls or inadvertently prevent appropriate logon scenarios.
In Windows Server 2012 R2, Microsoft introduced Authentication Policy Silos. Whereas logon rights are enforced at the member computer level, silos are enforced centrally by the domain controller. Basically, you create an Authentication Policy Silo container and assign the desired user accounts and computers to that silo. Now those user accounts can only be used for logging on to computers in that silo. Domain controllers only enforce silo restrictions when processing Kerberos authentication requests – not NTLM. To prevent users accounts from bypassing silo restrictions by authenticating via NTLM, silo’d accounts must also be members of the new Protected Users group. Membership in Protected Users triggers a number of different controls designed to prevent pass-the-hash and related credential attacks – including disabling NTLM for member accounts.
For what it’s worth, Active Directory has one other way to configure logon restrictions, and that’s with the Logon Workstations setting on domain user accounts. However, this setting only applies to interactive logons and offers no control over the other logon session types.
Detecting Logon Violation Attempts
You can monitor failed attempts to violate both types of logon restrictions. When you attempt to logon but fail because you have not been granted or are explicitly denied a given logon right, here’s what to expect in the security log.
| Which Security Log | Event ID | Notes |
| Local computer being attempted for logon | 4625
Logon Failure | Failure reason: The user has not been granted the requested logon type at this machine.
Status: 0xC000015B |
| Domain Controller | 4768
Successful Kerberos TGT Request | Note that this is a successful event. To the domain controller this was as a successful authentication. |
As you can see there is no centralized audit log record of logon failures due to logon right restrictions. You must collect and monitor the logs of each computer on the network.
On the other hand, here are the events logged when you attempt to violate an authentication silo boundary.
| Which Security Log | Event ID | Notes |
| Local computer being attempted for logon | 4625
Logon Failure | Failure reason: User not allowed to logon at this computer
Status: 0xC000006E |
| Domain Controller | 4820 Failure | A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions.
The silo is identified |
| 4768 Failed Kerberos TGT Request | Result Code: 0xC |
An obvious advantage of Authentication Silos is the central control and monitoring. Just monitor your domain controllers for event ID 4820 and you’ll know about all attempts to bypass your logon controls across the entire network. Additionally, event ID 4820 reports the name of the silo which makes policy identification instant.
Restricting privileged accounts is a key control in mitigating the risk of pass-the-hash and fighting modern attackers. Whether you enforce logon restrictions with user rights on local systems or centrally with Authentication Silos make sure you don’t just use a “fire and forget” approach in which you configure but neglect monitoring these valuable controls. You need to know when an admin is attempting to circumvent controls or when an attacker is attempting to move laterally across your network using harvested credentials.
