AMS Configuration is not detecting AD forest trust

[mascr]

Describe the bug
AMS Configuration is not detecting the trusted domain.

The trust between two domains is configured as an external non-trasitive forest trust.

To Reproduce
Steps to reproduce the behavior:

1. Create two WS19-DCs
2. Establish external trust
3. Install AMS on third VM with WS19
4. Create new rule with 'Authorization/'Add'/Target type:Container
5. Here you see AD1.LOCAL and AD2.LOCAL
   -->
6. Create new rule with 'Authorization/'Add'/Target type:Computer
7. Only the AD the AMS Server belongs to is listed
   -->

Expected behavior
Domain with external forest is detected by AMS Configuration and listed

Screenshots

Access Manager installation

DC.AD1.LOCAL -> OS: WS19 Standard; Forest: 2016
DC.AD2.LOCAL -> OS: WS19 Standard; Forest: 2016

AMS.AD1.LOCAL -> OS: WS19 Standard

• Version: 1.0.7925

Logs
2021-07-12 17:17:45.8005| INFO|Lithnet.Licensing.Core.LicenseManager|No license information was found on the system
2021-07-12 17:17:53.8540|TRACE|Lithnet.AccessManager.DiscoveryServices|Local DCLocator: Finding domain controller for domain AD1.LOCAL with flags 0
2021-07-12 17:17:53.8629|TRACE|Lithnet.AccessManager.DiscoveryServices|Local DCLocator: Found DC DC.AD1.LOCAL for domain AD1.LOCAL, with flags 0
2021-07-12 17:17:54.5770| WARN|Lithnet.AccessManager.Server.ApplicationUpgradeProvider|Could not get version update

[ryannewington]

Thanks for the detailed report @mascr

What is the trust direction? Is ad1 trusting ad2 or vice versa?

[mascr]

It's vice versa @ryannewington

See here for details

[ryannewington]

That's very odd. I'll have to set this specific scenario up in my lab (I have just about every other trust type except this!) and get back to you

[ryannewington]

@mascr

Ok, so there are a couple of things in play here. We're not seeing this forest in the UI, because its not reported by windows in the list of forest trusts. It's technically a trust between two domains. That part is easy enough to solve, we can ask separately for the external domain trusts.

However there are some properties of external trusts that are a bit more difficult to work around. First, they are NTLM only. We extensively rely on Kerberos and S4U, so the authorization engine in AMS is having a hard time here. The second issue is that AMS does its object searches through global catalogs, and relies of forest referrals to traverse the trust graph to find computers and users. There are no such referrals for external trusts. Presumably because they were designed to connect NT domains to 2000-style domains, and as such, there is not expected to be an LDAP server on the other end of the trust.

So I think at the moment, we're looking at this being behaviour-by-design, based on the fact we are using Windows to do the heavy lifting for us in this space. It may possible to add logic to support external trusts, if this is a blocking issue for your deployment.

[mascr]

@ryannewington Thanks for your detailed explanation.

At the moment it is a blocking issue. If the logic is hard to implement, do you see a workaround?

If I join the AMS-VM to AD2.LOCAL it's working for computers in AD2. Maybe the external-trust-logic could threat these trusts as 'new' domains (and asks the catalog of those DCs directly). Msft-LAPS has minimum requirements for 2003 domains anyway

[ryannewington]

The immediate, albeit terrible workaround, would be to have an AMS instance in each domain.

I'll need to do a bit more research into the internals of what Windows is doing. At the moment, when a user enters a computer name in the UI, we throw it over to windows, via one of the Win32 APIs, which magically 'finds' the computer - no matter which forest it is in, and allows us to process it from there. AMS itself doesn't need to know or understand trusts directly as Windows does all the resolution and referral chasing in the background.

In the external trust scenario, when we ask windows to find the object, it just returns a 'no such object' object error. It's not traversing the trust boundary, again most likely assuming its an NT domain on the other side and there's no directory to query. So my suspicion is we'd have to completely implement our own resolution logic.

This will take some time to investigate further. I'll put some time aside, but to set expectations, we're working on finalizing some major new features at the moment, so it if it is resolvable, it will be after we release that.

There's another option that will be available soon that I just thought of - Our Lithnet LAPS agent will soon support LAPS without the need for an Active Directory. Passwords will be stored in the AMS service itself, alleviating the need for the trust entirely. That might be an option to consider.

[mascr]

Is everything calling https://github.com/lithnet/access-manager/blob/fd138b2a6f5d20fd64f07446818df54ce5df878d/src/Lithnet.AccessManager/Lithnet.AccessManager/ActiveDirectory/ActiveDirectory.cs#L403 to find computers?

An option could be to ask for these external trusts and if a computer is not found you could then search in these external trusts or directly if DNSName is provided. To get computers via LDAP/Powershell I'm doing:

# VARS
$Computername = 'MyComputer' # Set to Computername
$Dom = 'LDAP://DC=AD2,DC=local' # Set to 'RootDSE\defaultNamingContext' of external trust domain

$Root = New-Object DirectoryServices.DirectoryEntry $Dom   
# Create selector
$Selector = New-Object DirectoryServices.DirectorySearcher 
$Selector.SearchRoot = $root
$Selector.PageSize = 1000
$Selector.Filter = '(objectClass=computer)'
# Get all computer objects in domain
$ADobject = $Selector.findall()
# Filter all computer objects to get target
$Computer = $ADobject | Where {$_.Properties.name -eq $Computername}

I rely heavily on the LAPS password stored in AD and I've written many lines to query the password in different contexts. The coming feature sounds super cool - LAPS without AD attribute. But for now it won't be an option for me because to many functions rely on the AD attribute.

I haven't written many lines in C# but taken from the examples you could do

String strPath = "LDAP://DC=AD2,DC=LOCAL";  

// Create a 'DirectoryEntry' object with the given path.  
DirectoryEntry myDE = new DirectoryEntry(strPath);  
myEntry=myEntries.Find("CN=Sample",myDE.SchemaClassName);

[ryannewington]

I'd avoided using LDAP to find objects, because we have customers with many domains and forests, and searching them all is very time consuming. However, to solve this case, there's going to have to be some additional manual resolution logic. I know how to find them, but its determining when. Given that users expect to be able to type in 'short' names, there's no hint as to what domain it may be in. So every name that can't be resolve locally, we're going to have to start walking the forest for external trusts. Then comes the issue if there's a computer within the forest with the same name as a computer in the external domain. We'd never see the external one based on that logic. Lot's of scenarios to work through. I'll do some more experimentation and see what can be done.