Lithnet Access Manager
PricingRequest a trial or quoteDownloads
v3.0
v3.0
  • Home
  • How does Lithnet Access Manager help prevent lateral movement?
  • Access Manager Editions
  • Licensing
  • What's new in Access Manager v3
  • Change log
  • Installation
    • Getting started
    • System Requirements
    • Downloads
    • Upgrading from Access Manager v1
    • Upgrading from Access Manager v2
      • Considerations for migrating from Access Manager v2
    • 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 the Access Manager Agent
      • Enabling agent support on the AMS server
      • 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 Microsoft Entra ID
      • Setting up authentication with Okta
      • Setting up smart card authentication
      • Setting up integrated windows authentication
    • Deploying Features
      • Setting up RapidLAPS
      • LAPS
        • Setting up Microsoft LAPS for Active Directory
        • Setting up Microsoft LAPS for Entra
        • Setting up Lithnet LAPS
      • Just-in-time Authentication (JIT)
        • Setting up JIT for computers
        • Setting up JIT for roles
      • Setting up BitLocker access
        • Setting up access to BitLocker keys stored in Active Directory
        • Setting up BitLocker recovery key backup and access using the Access Manager Agent
    • 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
      • 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 Microsoft Entra
      • Getting started with RapidLAPS
    • Product lifecycle
    • Choosing between the Lithnet and Microsoft agent for LAPS
    • 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
      • KB000009: Access Manager may return an out-of-date LAPS password, or no password at all
      • KB000010: The Access Manager agents fail to register on macOS 15 (Sequoia)
      • KB000011: Users report delays in obtaining just-in-time access via AD
      • KB000012: Troubleshooting Windows authentication in the Access Manager Web App
      • KB000013: Access Manager cannot be installed on Windows Server 2016 with TLS 1.0 disabled
    • Advanced help topics
      • Creating an Entra app registration or Access Manager
      • Setting up agent policies
      • Managing word lists
      • Password history retention
      • 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
      • Group policy configuration
    • PowerShell reference
      • Add-AmsDeviceRegistrationKeyGroup
      • Add-AmsGroupMember
      • Add-AmsIdpClaimMapping
      • Clear-AmsIdpClaimMapping
      • Export-AmsServerDiagnostics
      • Get-AmsActiveDirectoryJitOptions
      • Get-AmsActiveDirectoryJitGroupCreationRule
      • Get-AmsComputerAuthorizationRule
      • Get-AmsDevice
      • Get-AmsDeviceRegistrationKey
      • Get-AmsFveRecoveryKey
      • Get-AmsGroup
      • Get-AmsGroupMembers
      • Get-AmsHostConfig
      • Get-AmsIdpClaimMapping
      • Get-AmsJitSchedulerJob
      • Get-AmsLocalAdminPassword
      • Get-AmsLocalAdminPasswordHistory
      • Get-AmsRoleAuthorizationRule
      • Get-AmsServiceConfig
      • New-AmsActiveDirectoryJitGroupCreationRule
      • New-AmsComputerAuthorizationRule
      • New-AmsDeviceRegistrationKey
      • New-AmsGroup
      • New-AmsRoleAuthorizationRule
      • Remove-AmsActiveDirectoryJitGroupCreationRule
      • Remove-AmsComputerAuthorizationRule
      • Remove-AmsDevice
      • Remove-AmsDeviceRegistrationKey
      • Remove-AmsDeviceRegistrationKeyGroup
      • Remove-AmsGroup
      • Remove-AmsGroupMember
      • Remove-AmsJitSchedulerJob
      • Remove-AmsRoleAuthorizationRule
      • Set-AmsActiveDirectoryJitGroupCreationRule
      • Set-AmsActiveDirectoryJitOptions
      • Set-AmsComputerAuthorizationRule
      • Set-AmsDevice
      • Set-AmsDeviceRegistrationKey
      • Set-AmsGroup
      • Set-AmsHostConfig
      • Set-AmsRoleAuthorizationRule
      • Set-AmsServiceConfig
    • Application help pages
      • Host configuration page
      • App Configuration
        • AMS License configuration page
        • Authentication configuration page
        • Email configuration page
        • Rate limit configuration page
        • IP Address detection configuration page
        • User interface configuration page
        • Auditing page
        • Security page
        • Database configuration page
      • Access Manager Agent
        • Access Manager Agent - Agent registration page
        • Agent Policies
          • Access Manager Agent - Windows polices page
          • Access Manager Agent - macOS polices page
          • Access Manager Agent - Linux polices page
          • Access Manager Agent - Legacy AMSv2 policies page
        • Access Manager Agent - Password settings page
        • Access Manager Agent - Devices page
        • Access Manager Agent - Groups page
      • Directory Configuration
        • Active Directory configuration page
          • Microsoft LAPS configuration page
          • Lithnet LAPS configuration page (Active Directory)
          • Just-in-time access configuration page
          • BitLocker configuration page
        • Microsoft Entra configuration page
      • Authorization Rules
        • Computer authorization rules page
        • Role authorization rules page
      • Effective access page
    • Getting Support
Powered by GitBook
On this page
  • Summary
  • Upgrading the Access Manager Server
  • Before you upgrade
  • Method 1: In-place upgrade
  • Method 2: Deploying to a new server, using existing configuration
  • Upgrading the Access Manager Agent
  • Create new v3 agent policies
  • Deploy Windows agents
  • Deploy macOS agents
  • Deploy Linux agents

Was this helpful?

  1. Installation

Upgrading from Access Manager v2

PreviousUpgrading from Access Manager v1NextConsiderations for migrating from Access Manager v2

Last updated 10 months ago

Was this helpful?

Summary

Upgrading your environment from version 2 to version 3 of Access Manager requires some careful planning as things have changed.

We recommend reviewing the document to understand more about the changes introduced.

Upgrade the AMS server before upgrading the AMS agents

The v3 agent can only communicate with a v3 server. Ensure that you upgrade the server to v3, before upgrading the agents to v3.

The v3 server can host both v2 and v3 agents.

Upgrading the Access Manager Server

Before you upgrade

Update your license

If you are an Access Manager enterprise edition customer, ensure that you have applied an AMSv3 license to your instance of AMS before you perform the upgrade. Contact if you have not been issued an AMSv3 license key.

All AMSv3 licenses are compatible with the AMSv2 server; this way, licences can be installed in advance of the upgrade.

You do not need an AMSv3 license to perform the upgrade - however, if you proceed without it, the server will be downgraded to community edition after the update.

Migrate your service principal name (SPN)

When user authentication was configured to use integrated windows authentication, Access Manager v2 employed the use of kernel-mode authentication. This required that the SPN for the web site be registered against the AMS computer object.

In AMSv3, the Access Manager service uses user-mode authentication, and as such, the SPN must be moved to the AMS service account.

First use the setspn -q command to query for the presence of the AMS SPN. The SPN will be in the format of HTTP/servername. In this example, replace ams.dev.lithnet.local with the external host name configured for your application.

C:\> setspn -q HTTP/ams.dev.lithnet.local
Checking domain DC=dev,DC=lithnet,DC=local
CN=AMS1,CN=Computers,DC=dev,DC=lithnet,DC=local
        HTTP/ams.dev.lithnet.local

Existing SPN found!

If the SPN was not found, then this step is not required.

If the SPN is found, and it is associated with the computer object, it must be removed using setspn -D

C:\> setspn -D http/ams.dev.lithnet.local AMS1

Once it has been removed, you can add it to the AMS service account

C:\> setspn -S http/ams.dev.lithnet.local svc-lithnetams

Method 1: In-place upgrade

The in-place upgrade process from Access Manager v2 to v3 is very straight forward. You can simply install the new version of AMS over the top, and the application will update the database and relevant configuration settings.

If you are using AMS in a highly available load-balanced configuration:

  1. Stop the 'Lithnet Access Manager' service on all nodes in the farm.

  • Once a node has been upgraded, the Access Manager can be safely restarted.

  • However, note that v2 nodes and v3 nodes must not be operating at the same time.

As a best practice precaution, we recommend taking a backup of the server and database before performing the upgrade.

Method 2: Deploying to a new server, using existing configuration

There is no direct path available for exporting configuration from one server, and importing it into another.

Once your copy of the server is up and running, you can then perform an in-place upgrade to AMSv3.

Upgrading the Access Manager Agent

Before deploying the v3 Access Manager agent, you'll need to first update the Access Manager server. The v3 agent can only communicate with a v3 server.

Create new v3 agent policies

AMSv3 agents require new policies to be created.

View the following guides for configuring your policies for the various supported features:

Deploy Windows agents

The Windows agent can be deployed directly over the top of the existing v2 agent as an in-place upgrade.

Active Directory-joined Windows hosts

Active Directory-joined Windows hosts no longer store their passwords in Active Directory. As such, when upgrading these agents to v3, you must now specify the server name as part of the installation. You can use the following command line to install the agent in Active Directory authentication mode, replacing the server name with your own server.

msiexec /i Lithnet.AccessManager.Agent.msi /qn AUTHMODE=1 SERVER=ams.lithnet.local 

Deploy macOS agents

There are no special considerations to make when deploying the macOS agent.

Deploy Linux agents

The Access Manager agent package has been renamed from LithnetAccessManagerAgent to LithnetAccessManagerAgent3 to prevent auto updates to v3 before the server has been upgraded to v3.

The LithnetAccessManagerAgent3 supersedes the previous agent, and migrates the config, so the upgrade process should be seamless.

For RPM-based distributions, make sure you specify the --allowerasing flag.

# Upgrade the agent (from version 2 to version 3)
sudo dnf install LithnetAccessManagerAgent3 --allowerasing

For DEB-based distributions, make sure you specify the --autoremove argument flag.

# Upgrade the agent (from version 2 to version 3)
sudo apt install lithnetaccessmanageragent3 --autoremove

Upgrade AMS on each node at a time by running the .

If you want to migrate configuration from a different server, then you should first install AMSv2 on the new server. Then take a backup of the existing server's database, and restore using the procedure documented in the .

For more information, read the guide on .

Follow the steps in the to install the new agent over the top of the old agent.

Please read the guide for full details.

migration considerations
Lithnet support
'Access Manager Service' installer
backup and restore guide
Setting up Lithnet LAPS
Setting up RapidLAPS
Setting up BitLocker backup
installing the Access Manager agent on Windows
macOS installation guide
Linux installation guide