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 a key action in every external attack, making them a prime focus for IT to both monitor, as well as act upon. And login security is a core focus of a zero trust security model, "never trust, always verify."

Even in cases of insider attacks, suspicious logon activity can be a leading indicator of malicious activity. And yet, all native AD login security has to offer is workstation and time restrictions...that are 19 years old.

It’s high time organizations mature their thinking around logon access controls. 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 third-party Windows access security solution — such as UserLock — that focuses on the most pivotal point in any security risk: the logon.

Native Active Directory doesn't have the ability to allow granular implementation of multi-factor authentication (MFA) for Windows logins to computers with Active Directory domain membership or to standalone terminal servers.

With UserLock: Enable customized and granular MFA
When you deploy UserLock MFA, you make sure only the right people get access to your AD network. Your users will need to pass Windows two-factor authentication, providing two factors — their Windows password and a second factor — to access the corporate network.

After Windows Active Directory credentials, the second factor of authentication can be through Authenticator applications or hardware tokens such as YubiKey or Token2. You can even layer on top of UserLock's Windows 2FA with access controls based on contextual circumstances, or role-based access restrictions, to ensure a more frictionless access.

Single sign-on (SSO) for Active Directory, 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're traditionally beyond the reach of on premise AD.

With UserLock: Continue to use on premise Active Directory credentials to seamlessly access cloud resources

No need to consolidate or integrate all user identities into a new directory. UserLock SSO continues to use on-premise Microsoft Active Directory as the authoritative user directory. It supports both SAML 2.0 and OIDC protocols to enable federated authentication of Microsoft 365 and other cloud applications.

Native AD doesn't allow you 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 Windows access control policy across the organization.

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.

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

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.

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.

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.

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.

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.