01-02-2019 02:15 PM
01-02-2019 02:15 PM
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.
01-03-2019 08:05 AM
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?
01-03-2019 08:21 AM
The quarantined attribute indicates TRUST_ATTRIBUTE_QUARANTINED_DOMAIN
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.
01-03-2019 08:31 AM
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...
01-03-2019 09:06 AM
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 (22.214.171.124) 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...
01-04-2019 01:39 PMSolution
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
$cred = Get-Credential
$connLmk = New-Object System.DirectoryServices.Protocols.LdapConnection "DomainName"
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.
01-06-2019 02:46 AM
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.