A

Active Directory Logon Control: 8 ways AD fails IT and how to fix them

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.

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.

Eight Holes in Windows Active Directory Login Controls

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

With UserLock: Set restrictions by Group and OU
This saves considerable time and allows IT to set a centralized access control policy across the organization.

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

With UserLock: Identify an Initial Access Point from a nested session
Authorize access based on whether a session is a new point of entry or from an existing session.

3. No Concurrent logon control

Simply put, there is no centralized means within AD to track each and every place a user logs on.
When Jimmy maps a drive to Server5, technically, there’s a logon at server 5. 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.

With UserLock: Limit or prevent concurrent sessions
Restrict a user account to access only one computer/device at a time.

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

With UserLock: Force logoff outside of authorized timeframes
Disconnect a user when they are logged on at the console.

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

With UserLock: Immediately respond to alerts on access events
Interact remotely with any session, open or locked, to force log-off, lock or reset.

6. 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!

With UserLock: Warn users of suspicious credential use
Alert users in real-time to access events (successful or not) involving their account credentials.

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

With UserLock: Send previous logon notifications
Inform users of previous connection events involving their credential.

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