IS Decisions logo

IS Decisions Blog

Windows login Active Directory (AD) security

Ten ways Active Directory (AD) fails to secure Windows login, including no multi-factor authentication (MFA) on Windows computers with AD domain membership.

Published February 18, 2021
Windows login Active Directory (AD) security

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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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

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!

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

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.

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

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.

Fill Active Directory security gaps with UserLock

There's a 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.

Try UserLock for free

3400+ organizations like yours choose UserLock to secure access for Active Directory identities and meet compliance requirements.

Download a free trial