Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

Azure Advanced Thread Protection Sensor service failed to start multi-forest DC

Copper Contributor

I have had this running on the primary domain with 4 sensors working fine for a week.  I have now attempted to add a new domain from another forest and Sensor repeatedly fails to start logging the following errors.

 

2019-01-02 22:08:06.6076 Error DirectoryServicesClient+<CreateLdapConnectionAsync>d__33 Microsoft.Tri.Infrastructure.ExtendedException: CreateLdapConnectionAsync failed [DomainControllerDnsName=xxxx.yyyy.prod]
   at async Task<LdapConnection> Microsoft.Tri.Sensor.DirectoryServicesClient.CreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing)
   at async Task<bool> Microsoft.Tri.Sensor.DirectoryServicesClient.TryCreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing)
2019-01-02 22:08:06.6126 Error DirectoryServicesClient Microsoft.Tri.Infrastructure.ExtendedException: Failed to communicate with configured domain controllers
   at new Microsoft.Tri.Sensor.DirectoryServicesClient(IConfigurationManager configurationManager, IDomainNetworkCredentialsManager domainNetworkCredentialsManager, IMetricManager metricManager, IWorkspaceApplicationSensorApiJsonProxy workspaceApplicationSensorApiJsonProxy)
   at object lambda_method(Closure, object[])
   at object Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate()
   at void Microsoft.Tri.Infrastructure.ModuleManager.AddModules(Type[] moduleTypes)
   at ModuleManager Microsoft.Tri.Sensor.SensorService.CreateModuleManager()
   at async Task Microsoft.Tri.Infrastructure.Service.OnStartAsync()
   at void Microsoft.Tri.Infrastructure.TaskExtension.Await(Task task)
   at void Microsoft.Tri.Infrastructure.Service.OnStart(string[] args)

 

There is a two way trust.  Output from nltest /domain_trusts looks like this

 

AAAAA aaaaa.corp (NT 5) (Direct Outbound) (Direct Inbound) ( Attr: quarantined )

 

I have tried many things to ensure the foreign security principle has LDAP access and went as far as testing adding it to the Administrators group and nothing changes the error.

 

Any help greatly appreciated.

 

James

 

6 Replies

Hi,

Sound like it might be either a Trust or networking issue, have you checked the guidance on https://docs.microsoft.com/en-us/azure-advanced-threat-protection/atp-multi-forest including the opened ports that must be opened?

The quarantined attribute indicates TRUST_ATTRIBUTE_QUARANTINED_DOMAIN

https://msdn.microsoft.com/en-us/library/cc223779.aspx

“If this bit is set, the trusted domain is quarantined and is subject to the rules of SID Filtering as described in [MS-PAC] section 4.1.2.2.”

Just for troublshooting - can you remove the quarantine  and see if things start to work, it will give a clue if we are on the right direction, and continue from there.

This is not a stand alone sensor so network and ports are not relevant.  Trust issue is my suspicion which is why I included trust configuration details... Eli Ofek just replied with a more relevant response...

Its a production environment so I will need to really understand the change and potential risks before testing but I will investigate this.  It would be good if there were more details on exactly what trust configuration is required and what rights the trusted account needs to have...  Reading your reference (4.1.2.2) the QuarantinedExternal trust boundary should only filter SIDs that are not part of the Trusted Domain.  Since the ATP Directory Services user is a member of the trusted domain I can't really understand how this would be the issue.

 

I have also seen your post about the preview version expanding support for different trust configurations so maybe the developer working on that could shed more light on the subject...

 

 

best response confirmed by James_W (Copper Contributor)
Solution

Tried the Quarantine bit and no change.  Then tried many things that would add no value to this post  so will leave them out and I will skip to the revelation... Started playing with Powershell trying to reproduce the error and  oddly the same .NET libraries which were failing worked fine 

 

[System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.Protocols")

[System.Reflection.Assembly]::LoadWithPartialName("System.Net")

 

$cred = Get-Credential

$connLmk = New-Object System.DirectoryServices.Protocols.LdapConnection "DomainName"

$connLmk.Bind($cred)

 

Then conversations with a colleague led us down the path to requiring Kerberos (which makes some sense in a security product)… The default behavior of the library is to negotiate... Adding

 

$connLmk.AuthType = 'Kerberos'

 

Reproduced the error we were seeing in the Sensor logs.  So now the question was why Kerberos was not working over the trust which was up and valid and working fine with NTLM... After reading a lot I decided to take a shortcut and changed the trust type to a Forest Trust because in my case the trusted domain was a single domain forest so no real difference.  

 

Once I made that change both my repo and the sensor started working.

 

 

Yes, we did lock down the LDAP connection to force Kerberos only.

We were aware it will be more sensitive to configuration issues, but as you mentioned, as a security product we felt it's better to handle some of those than falling back to NTLM automatically and not be fully secured.

I was already aware that that problem is kerberos failing, but this could happen for many reasons due to odd configurations.

 

1 best response

Accepted Solutions
best response confirmed by James_W (Copper Contributor)
Solution

Tried the Quarantine bit and no change.  Then tried many things that would add no value to this post  so will leave them out and I will skip to the revelation... Started playing with Powershell trying to reproduce the error and  oddly the same .NET libraries which were failing worked fine 

 

[System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.Protocols")

[System.Reflection.Assembly]::LoadWithPartialName("System.Net")

 

$cred = Get-Credential

$connLmk = New-Object System.DirectoryServices.Protocols.LdapConnection "DomainName"

$connLmk.Bind($cred)

 

Then conversations with a colleague led us down the path to requiring Kerberos (which makes some sense in a security product)… The default behavior of the library is to negotiate... Adding

 

$connLmk.AuthType = 'Kerberos'

 

Reproduced the error we were seeing in the Sensor logs.  So now the question was why Kerberos was not working over the trust which was up and valid and working fine with NTLM... After reading a lot I decided to take a shortcut and changed the trust type to a Forest Trust because in my case the trusted domain was a single domain forest so no real difference.  

 

Once I made that change both my repo and the sensor started working.

 

 

View solution in original post