Privileged Access
Management
for Windows
Active Directory Domain

Privileged Access Management (PAM) is primarily seen as being used to protect the most privileged of accounts – Windows local administrator accounts, domain admin accounts, Active Directory service accounts, and anything that has rule over a major part of the network environment. But the real value of PAM is realized when it’s used to protect any account with access to critical data, applications, and systems.

In this article, we’ll look at how UserLock helps organizations to protect both.

How to Secure any Account with Privileged Access

Every user has attributed access rights and privileges and is some sort of privilege user.

PAM is obviously used by most organization to protect notably privileged accounts, such as domain and local administrator-type accounts. And yet, in reality, any standard account with access to data that is sensitive, protected, or otherwise valuable (think financial data, intellectual property…) should somehow be equally monitored and, in some cases, denied access should certain criteria be met.

However the use of a traditional PAM solution can’t easily be extended all the way down to every last “non-privileged” user account – it adds a burden upon the user as an additional security step, as well as on IT – as you’d need yet an even lower level account for the non-privileged to use to authenticate to PAM.

While UserLock doesn’t retain credentials in a vault, providing access to them when requested, it does provide an organization with a protective layer at the logon, ensuring the account isn’t being misused or is compromised.

Using Gartner’s words, it makes it easy for IT to “secure, manage, and monitor” non-privileged access without unnecessarily burdening the user. What’s more by having a layer of security around the use of accounts that are not traditionally considered “privileged” aligns with most organization’s desire to protect accounts with access to critical data, applications, and systems.

UserLock enhances non-privileged access security by:

  • Enabling Multi-Factor Authentication
    Administrators can customize the circumstances under which MFA is asked, to avoid prompting the user for a second factor on every connection.
  • Restricting Logons with Access Policies
    Limit when an account can logon, from which machines or devices, using only approved session types, etc. helping to reduce the risk of inappropriate use.
  • Delivering Visibility into Non-Privileged Account use
    Traditional PAM solutions can be configured to notify IT when privileged accounts are used. IT needs that same level of real-time visibility into the use of any account, so they are aware of anomalous account behavior.
  • Responding to suspicious access events
    Automated or alert-based response allows an administrator to instantly react and perform corrective actions by remotely locking, logging of or resetting any user session.

How to Enhance the Security of all Privileged Account Use

To make PAM effective, you really need to secure the logon first.

Consider the security requirements behind PAM. If we break down the Gartner definition as our requirement set, there are 3 clear points:

  1. "To provide privileged access"
    You need to ensure the right users have appropriate elevated access to do their job.
  2. "Meet compliance requirements"
    Having an auditable way to prove only approved access was granted.
  3. "Secure, manage and monitor privileged accounts and access"
    Keep the accounts locked up, define who can access them, know when they’re used, and be able to respond if accounts are misused.

All of these requirements pivot on a single factor that lies outside of PAM itself – the user needs to authenticate themselves first. But many PAM solutions rely on the Windows logon credentials to establish which policies apply and which accounts are accessible to that user. So to make PAM effective, you really need to secure the logon first.

Now, if your PAM solution takes Microsoft at its word that you’re you, it’s a problem. Take the following scenarios in which an internal account is misused:

  • A malicious insider using another user’s credentials
    Nearly half of all employees share their credentials with fellow employees1. And it’s not just low-level roles in the organization; employees from key departments like legal, HR, IT, Finance, are included. Should an internal employee decide to perform a malicious act, they could logon, be authenticated by a PAM solution, and be given access to one or more privileged accounts.
  • An external attacker compromises a user’s credentials
    Nearly half of all data breaches involve hacking. And the number one tactic used in hacking is stolen credentials2, which makes this scenario all too real. If a PAM solution either does not support or isn’t configured to rotate privileged passwords after each use, and a privileged user logs onto an endpoint, the privileged account credential is stored in the endpoint’s memory. External attackers who obtain an account with local admin rights can extract the credentials from the endpoint’s memory and use it to move laterally within the organization.

In short, if access to a privileged account is given solely based on it being the correct user account, your PAM is insecure. What’s needed is an additional layer of security to stop this kind of credential misuse before PAM ever comes into the picture.

UserLock implements protection not necessarily found in traditional PAM solutions.

  • Enabling Multi-Factor Authentication
    Used to enhance security around privileged account use by ensuring that only authorized personnel have access to privileged accounts.
  • Restricting privileged account use
    Logons by privileged accounts onto Windows-based machines can be made to fall subject to their own set of restrictions that sit on top of any restrictions PAM enforces. E.g. Out rightly restricts domain admin accounts to troubleshoot workstations.
  • Restricting low-level account use
    By limiting which machines, IP addresses and session types an account can log on from, as well as restrict the number of concurrent sessions, organizations can better ensure that the low-level user is logged on from an approved workstation and reduces the likelihood of the low-level account being used by anyone other than the account owner.
  • Monitoring of all logon activity
    Logon Management can identify when unusual logons of a privileged account occur and can be configured to notify IT personnel.
  • Respond to privileged credential misuse
    Should a PAM not include session management (so privileged accounts are used directly on endpoints and not go through a proxy), UserLock can be used by IT to review the user activity, lock the session, logoff the account, and even disable the account’s ability to logon at all.

Limit the risk associated with any kind of privileged access

Many risks come as a result of privileged access. These risks can come from external attacks or malicious insiders within an organization. Either way, the risks make it important to ensure the security of privileged access at all times.

So, as you either plan for a future implementation of PAM, or are looking for ways to improve the security of the PAM solution you have – and you wish to extend the security as far down the “non-privileged” path as is possible, consider looking at securing the logon by utilizing UserLock.

With multi-factor authentication and access management, UserLock makes it easy for IT to secure non-privileged account access and simultaneously augments IT’s ability to secure, restrict and respond to privileged account use.

1 IS Decisions, Insider Threat Persona Study (2017)
2 Verizon, Data Breach Investigations Report (2018)

Download this Report in PDF

PDF Version - 160 KB

Ready to get started with UserLock?

Get a free trial