Lithnet Access Manager
PricingRequest a trial or quoteDownloads
v2.0
v2.0
  • Home
  • What's new in Access Manager v2
  • How does Lithnet Access Manager help prevent lateral movement?
  • Access Manager Editions
  • Licensing
  • Change log
  • Installation
    • Getting started
    • System Requirements
    • Downloads
    • Upgrading from Access Manager v1
    • Installing the Access Manager Server
      • Creating a service account for the Access Manager Service
      • SQL installation options
      • Installing the Access Manager Service
      • High availability options
        • Load balancing Access Manager
        • Installing Access Manager in a Failover Cluster
    • Installing the Access Manager Agent
      • Choosing between the Microsoft and Lithnet agents for LAPS support
      • Installing the Access Manager Agent on Windows
      • Installing the Access Manager Agent on Linux
      • Installing the Access Manager Agent on macOS
  • Configuration
    • Setting up Authentication
      • Setting up authentication with ADFS
      • Setting up authentication with Azure AD
      • Setting up authentication with Okta
      • Setting up smart card authentication
      • Setting up integrated windows authentication
    • Deploying Features
      • Setting up Microsoft LAPS for Active Directory
      • Setting up Microsoft LAPS for Azure Active Directory
      • Setting up Lithnet LAPS
        • Preparing the AMS directory
        • Setting the AMS directory for Lithnet LAPS clients
        • Setting up Lithnet LAPS for Azure AD joined and registered devices
        • Setting up Lithnet LAPS for domain-joined devices
        • Setting up Lithnet LAPS for macOS and Linux
        • Setting up Lithnet LAPS for standalone Windows devices
      • Setting up BitLocker access
      • Setting up JIT for computers
      • Setting up JIT for roles
    • Importing authorization rules
      • Import Microsoft LAPS permissions from Active Directory
      • Importing BitLocker permissions from Active Directory
      • Importing local administrator group membership from domain-joined Windows devices
      • Import mappings from a CSV file
      • Importing rules from the Lithnet LAPS web app
      • Performing an offline discovery of local admins
  • Help and support
    • Frequently asked Questions
    • Troubleshooting
    • Quick start guides
      • Getting started with Windows LAPS and Lithnet Access Manager
      • Getting started with Windows LAPS for Active Directory
      • Getting started with Windows LAPS for Azure Active Directory
    • Support Articles
      • KB000001: The Access Manager Agent cannot connect and logs a token-validation-failed error
      • KB000002: Users retain their admin rights after their JIT period expires
      • KB000003: Configuring the Access Manager Agent to manage an account other than 'root' on Linux
      • KB000004: Creating a log file to troubleshoot installation issues with the Access Manager Service
      • KB000005: Access Manager stops working after applying the November 2022 Windows update
      • KB000006: Migrating the Access Manager Database
      • KB000007: Adding JIT groups via Group Policy doesn't work with NTLM Disabled
      • KB000008: AMS is unable to JIT into privileged groups such as Domain Admins
    • Advanced help topics
      • Ports and traffic flows
      • Internet access requirements
      • Access evaluation in Access Manager Service (AMS)
      • Recovering from a lost encryption certificate
      • Script-based authorization
      • Customized auditing with PowerShell notification channels
      • Variables available in audit notification channels
      • Setting up audit templates
      • Backup and Restore
      • Event ID reference
    • PowerShell reference
      • Add-AmsDeviceRegistrationKeyGroup
      • Add-AmsGroupMember
      • Export-AmsServerDiagnostics
      • Get-AmsActiveDirectoryJitOptions
      • Get-AmsComputerAuthorizationRule
      • Get-AmsDevice
      • Get-AmsDeviceRegistrationKey
      • Get-AmsGroup
      • Get-AmsGroupMembers
      • Get-AmsHostConfig
      • Get-AmsJitSchedulerJob
      • Get-AmsLocalAdminPassword
      • Get-AmsLocalAdminPasswordHistory
      • Get-AmsRoleAuthorizationRule
      • New-AmsComputerAuthorizationRule
      • New-AmsDeviceRegistrationKey
      • New-AmsGroup
      • New-AmsRoleAuthorizationRule
      • Remove-AmsComputerAuthorizationRule
      • Remove-AmsDevice
      • Remove-AmsDeviceRegistrationKey
      • Remove-AmsDeviceRegistrationKeyGroup
      • Remove-AmsGroup
      • Remove-AmsGroupMember
      • Remove-AmsJitSchedulerJob
      • Remove-AmsRoleAuthorizationRule
      • Set-AmsActiveDirectoryJitOptions
      • Set-AmsComputerAuthorizationRule
      • Set-AmsDevice
      • Set-AmsDeviceRegistrationKey
      • Set-AmsGroup
      • Set-AmsHostConfig
      • Set-AmsRoleAuthorizationRule
    • Application help pages
      • Access Manager Directory configuration page
      • Access Manager Directory Devices page
      • Access Manager Directory Groups page
      • Lithnet LAPS configuration page (Access Manager Directory)
      • Access Manager Directory Registration Keys page
      • Lithnet LAPS configuration page (Active Directory)
      • Microsoft LAPS configuration page
      • Active Directory configuration page
      • Auditing page
      • Authentication configuration page
      • Computer authorization rules page
      • Role authorization rules page
      • Azure Active Directory configuration page
      • BitLocker configuration page
      • Database configuration page
      • Effective access page
      • Email configuration page
      • IP Address detection configuration page
      • Just-in-time access configuration page
      • Licensing configuration page
      • Rate limit configuration page
      • Host configuration page
      • User interface configuration page
      • Security page
    • Getting Support
Powered by GitBook
On this page
  • 1. Secure the built-in administrator account
  • 2. Removing everyone from the local administrators group

Was this helpful?

How does Lithnet Access Manager help prevent lateral movement?

PreviousWhat's new in Access Manager v2NextAccess Manager Editions

Last updated 1 year ago

Was this helpful?

Lateral movement is a technique used by attackers, where after gaining initial access to one system, they obtain credentials that allow them to move into other hosts on the network.

Windows systems are particularly prone to lateral-movement based attacks. It is not uncommon for desktop support staff to be administrators of all workstations, and server admin staff to be an administrator of every server. In some environments, the local admin password is the same on every machine. These configurations make it trivial to exploit a Windows environment.

Ransomware operators love this type of environment.

In most cases, large-scale ransomware attacks are successful because they manage to steal credentials of accounts that are admins on large numbers of computers.

So, how do we defend against these types of attacks?

1. Secure the built-in administrator account

While every computer has its own local administrator account, if the password is the same it is effectively a single account - one that has access to every machine, and is not tied to AD. It is not audited in any AD logs, and there are no controls on its usage. It makes for a very attractive target for an attacker. If they obtain access to it, it is very easy for them to move through the environment undetected. All that is needed for ransomware success is the compromise of a single machine with this password.

This is why Microsoft LAPS is so important. It randomizes the password on each individual machine and changes it regularly, ensuring that if one machine is compromised and its local admin password exposed, that local admin password cannot be used to access other machines on the network.

Unfortunately, accessing the Microsoft LAPS password is not the most user-friendly experience. You need to install a thick client, or use the advanced attribute editor of the Active Directory Users and Computers tool. For technicians out in the field this can be problematic, as they may be at a customer site without their own computer.

Fortunately, Lithnet Access Manager Service (AMS) provides mobile-friendly web-based access to LAPS passwords so that they can be accessed from any device with a browser. Combined with the ability to support modern authentication protocols like OpenID Connect, you can protect access to these passwords with multifactor authentication.

The Enterprise Edition of Access Manager includes the Lithnet Access Manager Agent (AMA) which can be used to manage the local admin password where Microsoft LAPS isn't or can't be used. It does not require Active Directory to operate, and therefore allows us to support macOS, Linux, non-domain joined Windows devices, as well as Azure AD joined and registered devices. You can of course also use it on Active Directory joined devices, and benefit from the other advanced features of the agent.

The AMA also helps in scenarios where machines are rolled back from a snapshot or restored from a backup. Using Microsoft LAPS can be problematic in this case. If the machine account password has been changed since the snapshot was taken, no one can log onto the machine with a domain account. If the LAPS password was rotated since the snapshot was taken, then not even the local administrator can log in. AMA can store the previous passwords in the directory, and record when they were in use, so you can easily get back into the computer in this scenario.

For added protection, it is highly recommended that you . This will ensure that the local admin password cannot be used over the network at all. It will only work for local logins.

2. Removing everyone from the local administrators group

So if we have secured the local admin password, what other lateral movement risks remain? If you think back to the attack scenario, where an attacker is looking for credentials on a machine they have compromised, what happens if an admin is logged on to the machine at the time? If that user has admin rights on other machines, then the attacker may be able to steal hashes, Kerberos tickets, and in some cases the plain-text password. They can then move into other systems with those stolen credentials.

There are lots of things you can do to help mitigate these attacks, not all of them easy or 100% foolproof. We do encourage you to research and implement as many defenses as you can to prevent lateral movement attacks. You need to choose the ones that make sense for your environment.

One of the simplest to achieve technically, that has a high degree of effectiveness, is to simply not have any permanent members of the local administrators group.

While this sounds scary, Access Manager takes the technical complexity away from making such a change. Your administrators of course, will need to adapt to a new way of working, so getting appropriate buy-in from senior management is important. Like the other mitigations, it's not foolproof, and it's not perfect. It is however a relatively low complexity solution, that offers a high value.

The difference here is that they are entitled to be an administrator of the computers you specify in the Access Manager configuration tool, but they only get promoted to administrator when they need and request it.

This means that at any single point in time, you have relatively few users with admin rights across your fleet of computers, drastically reducing the ability for an attacker to spread across the fleet.

It is important to note at this point, that Access Manager is not a fully-fledged Privileged Access Management (PAM) tool. There are no approval workflows. You determine in advance who can access which computer, and they can self-grant those privileges at any time. There are plenty of commercial PAM solutions out there if you want to control who and when people can access certain resources. We're not trying to fix that problem. We just want our admins to be admins only when they need to do admin work.

The theory behind this approach, quite simply, is that if a computer is compromised, and the user is a local admin on that computer but nowhere else, then lateral movement with that account becomes very difficult. So instead of having all your admins as members of the local administrators group, you assign them 'just-in-time access' (JIT) rights in Access Manager. When they need to access a computer, they visit the Access Manager website, request JIT access to the computer, and Access Manager will grant them the appropriate rights for the length of time you allow. They can then log on to the server, and perform whatever work they need to, just as they did before. You can read more about exactly .

deny local accounts access to the computer over the network
how Access Manager performs just-in-time access