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
  • Within the same domain
  • Within the same forest
  • Across forests with a two-way trust
  • Access across a forest with a one-way trust

Was this helpful?

  1. Help and support
  2. Advanced help topics

Access evaluation in Access Manager Service (AMS)

AMS uses the Windows built-in authorization subsystem to determine if a user is authorized to access a resource.

When a user requests access to a computer, AMS will obtain an 'identification token' from the domain where the computer resource is located. This identification token will contain the group membership of the user, from the perspective of the computer that is being accessed. All groups that are visible from the computer's domain will be included in the token. This is similar to a token a user would get had they logged onto that computer directly.

This means that depending on the location of the resource the user is accessing, you'll need to place your access control rules accordingly.

Within the same domain

When the requesting user and computer are in the same domain, the user's access token will contain all the domain local, global, and universal groups memberships from that domain. No special consideration is needed in this case.

Within the same forest

When the requesting user and computer are in different domains in the same forest, the user's access token will contain global and universal groups from the forest, as well as domain local groups from the domain where the computer is located.

Domain local groups from the user's home domain are not present. Therefore, a user must be granted access to the resource via a global or universal group from that forest

Across forests with a two-way trust

If the user and computer are in different forests, provided there is a two-way trust in place then the user will have their group membership built in the other forest. The user will need to be a member of a domain local group in that domain in order to gain access.

Access across a forest with a one-way trust

When a one-way forest trust is in place, access control must work a little differently. Let's call the forest containing AMS the RED, and the forest containing the computer is GREEN.

The GREEN forest must of course trust the RED forest. Access Manager will not work if there is no trust to the target forest.

In this scenario, the GREEN forest trusts the RED forest, but the RED forest does not trust the GREEN forest. Users from the RED forest are able to log in to the GREEN forest and access objects within. Users from the GREEN forest can't access resources within the RED forest.

AMS uses Kerberos S4U2Self in order to obtain the 'identification token' mentioned earlier. Unfortunately, S4U is not supported across a one-way trust. When AMS detects a request that would cross a one-way trust, it modifies the way it performs the access checks.

When a user from the RED forest tries to obtain access to a computer from the GREEN forest, AMS will use the user's home domain (rather than the computer's domain) to build the access token. This means that any group membership that the user may have in the GREEN forest is not seen at all when evaluating access to a resource in the GREEN forest.

In order to support users from the RED forest accessing computers in the GREEN forest, you must ensure that a group from the RED forest is present on the ACL granting access to the computers in the GREEN forest.

PreviousInternet access requirementsNextRecovering from a lost encryption certificate

Last updated 11 months ago

Was this helpful?