Active Directory (AD) is more than just a repository of IDs and passwords; it’s the center of just about every bit of security in your network. Going beyond the rudimentary managing of permissions, AD establishes policies and controls over what privileges accounts have, and how those account can be used.
But when it comes to keeping a tight rein on when, where, how, and whether an account can logon, AD is simply missing the mark.
Ten Holes in Windows Login Active Directory Security
Logons are one of the key actions in every external attack, making them a prime focus for IT to both monitor, as well as act upon. Even in cases of insider attacks, suspicious logon activity can be a leading indicator of malicious activity. And yet, all AD has to offer is workstation and time restrictions that are 17 years old.
It’s high time that organizations mature their thinking around logon access controls that need to be in place. Security best practices recommend them and compliance standards mandate them.
The following is a list of ways AD’s built-in access controls around logons fails IT – each one represents a security gap that keeps organizations today from being compliant and, potentially, puts them at risk.
To put some of these controls in place requires either very creative scripting to get a portion of the functionality above working, or you need to be looking for a 3rd party solution – such as UserLock - that focuses on the most pivotal point in any security risk: the logon.
1. Multi-Factor Authentication of Windows login, Remote Desktop, VPN connections and IIS sessions
There’s no facility in native Active Directory that allows granular multi-factor authentication to be implemented for logging on to Windows computers with Active Directory domain membership or standalone terminal servers.
With UserLock: Enable customized and granular MFA
With UserLock MFA enabled, users may have to authenticate themselves in two successive stages to access the corporate network. After Windows Active Directory credentials, the second level of authentication can be through Authenticator applications or hardware tokens such as YubiKey or Token2. The circumstances can be customized to ensure a more frictionless access.
2. Single Sign-On to Cloud Applications
Single sign-on, to the user, is a godsend. No more wasting time putting in passwords to individual cloud applications, no more trying to remember a fistful of different username/password combinations. However cloud / SaaS applications are run outside of the firewall, where they have been beyond the reach of on premise AD.
3. No Setting of restrictions by group and OU
There’s no facility to establish logon time and workstation restrictions based on these logical users subset mechanisms, despite a wide range of compliance standards calling for it.
4. No Identifying an initial access point from a nested session
This is especially needed in situations where a threat actor (whether internal or external) is horizontally moving within your network. Being able to target the initial endpoint would help kill the entire chain of access.
5. No Concurrent logon control
Simply put, there is no centralized means within AD to track each and every place a user logs on.
To DIY this, you’d need to centralize the logs of every single endpoint and server in the network, monitoring and cross-referencing every logon in some sort of database. Oh, and you’d need to also keep track of logoffs to keep the concurrent logon number accurate!
This problem, by the way, is only made worse by the lack of forcing logoffs – if a user forgets to logoff, the concurrent logon count remains higher than it should.
6. No Forcing logoff when allowed logon time expires
AD can establish when users can log on (and not allow logon outside those times), but doesn’t have the ability to kick someone off your network.
If a user is not allowed to log on after 5pm it stands to reason she shouldn’t be still logged on after 5pm.
You can ‘MacGuyver’ an answer from a mix of a task scheduled within GPOs and a logoff script, but even with this solution, it’s not a dynamic answer that ensures each user is logged off at their appropriate time.
7. No Response to events and forcing a remote logoff
Beyond using PowerShell to force a user to logoff, IT needs to “sneakernet” their way to the endpoint in question. There are many good reasons you want to perform a forced remote logoff and is nonetheless required for major compliance regulations.
8. No Warning users themselves of suspicious credential use
Informing the user of irregular use of their own credentials empowers the user to act as part of your security team. Who better to know when a logon was inappropriate than the user themselves!
9. No Sending previous logon notifications
Just letting the user know the last time they logged on would improve security. It’s also a must for NIST 800-53 compliance. But, without centralized tracking of every logon, this simply isn’t possible natively.
10. No Temporary controls
Assuming you could do all the previous cool stuff around logons, the last control would be the ability to enforce any and all of the aforementioned controls on a temporary basis.
With UserLock: Apply temporary controls
Set for a defined time period. No users are left with access rules beyond their immediate need.
With the need to establish and maintain security in a way that ensures protection against external attacks, insider threats, as well as adherence to compliance-related data security standards, Active Directory access controls around logons are severely lacking.
With UserLock, IT can implement effective logon controls that have proven impossible or extremely cumbersome to achieve through native Windows AD features alone. With no modifications made to Active Directory or its schema, UserLock works alongside Active Directory to extend, not replace, logon security.