DirectoryServicesCOMException - Unexpected error occurred while getting domain names information

[Yvand]

Randomly, LDAPCP fails to get domain names information and records the following error:

07/18/2019 13:58:53.78	w3wp.exe (0x22A0)	0x1AE8	LDAPCP	Configuration	1337	Unexpected	[LDAPCP] Unexpected error occurred while getting domain names information for LDAP connection LDAP://contoso.local/DC=contoso,DC=local: System.DirectoryServices.DirectoryServicesCOMException: An operations error occurred.  , Callstack:   
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)    
at System.DirectoryServices.DirectoryEntry.Bind()    
at System.DirectoryServices.DirectoryEntry.get_AdsObject()    
at System.DirectoryServices.PropertyCollection.Contains(String propertyName)    
at ldapcp.OperationContext.GetDomainInformation(DirectoryEntry directory, String& domainName, String& domainFQDN)    
at ldapcp.LDAPCP.SetLDAPConnection(Uri currentContext, LDAPConnection ldapConnection)

As a consequence, entities that use dynamic domain name tokens are missing the domain name.
For example, entity value will be "\groupName" instead of "contoso.local\groupName"

[Yvand]

Good news, I found the root cause and upcoming version 14 will fix it. If you are interested, here are the details about the bug:

Context

The issue occurs when LDAPCP uses the LDAP (AD) connection of the SharePoint server.
At some point LDAPCP gets the domain name by reading the LDAP property “distinguishedName” from the object DirectoryEntry:

LDAPCP/LDAPCP/LDAPCPConfig.cs

Line 1290 in a5c1646

if (directory.Properties.Contains("distinguishedName"))

Reading this property triggers an authenticated LDAP call to the AD server, using the creds of the application pool account (LDAPCP does privilege elevation).

Root cause

But this privilege elevation was missing in 2 entry points: in LDAPCP.GetClaimTypeForUserKey() and LDAPCP.GetUserKeyForEntity().
So from those methods, connection to AD server was attempted as “NT AUTHORITY\IUSR” (the default anonymous account), which of course failed: lsass was issuing a Kerberos TGS to SPN “krbtgt/NT AUTHORITY” (assuming NT AUTHORITY was an AD domain name).
This is what caused the DirectoryServicesCOMException.

Solution

I added the missing privilege elevation in method LDAPCP.GetUserKeyForEntity():

LDAPCP/LDAPCP/LDAPCP.cs

Lines 1953 to 1956 in a5c1646

	SPSecurity.RunWithElevatedPrivileges(delegate ()
	{
	initSucceeded = Initialize(null, null);
	});

But doing so in LDAPCP.GetClaimTypeForUserKey() is not possible: it causes a StackOverflowException.
So to fully fix the issue I implemented a different way to read the domain name in this scenario, and little other improvements.
The commits that fix the bug are those with #87 in their title:

• 653e1d9
• 8b024e2
• c7daef4
• a5c1646
• dee7f5e

Upcoming version 14 will contain the fix. I will publish it as soon as possible, with hopefully a pre-release today if unit tests pass.

[Yvand]

The pre-release that fixes this bug is https://github.com/Yvand/LDAPCP/releases/tag/14.0.20190821.952