Forum Discussion
Azure Advanced Thread Protection Sensor service failed to start multi-forest DC
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.
MicrosoftThe 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.
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...
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.
- EliOfek
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.