Proposal to the error: While trying to retrieve the authorization groups, an error (5) occurred. about ldapcp

[Yvand]

When this exception occurs, you should see that LDAPCP attempts to get group membership using a different method (with a LDAP query).
If that fallback goes well, you should see a message like this:
"[LDAPCP] Domain {1} returned {2} groups for user {3}. Lookup took {4}ms on LDAP server '{5}'"
Do you see it?

[engineererr]

I was too euphoric about my solution..

I could reproduce the error by powershell and after the AD guy gave me the permissions the error vanished from powershell. The error is still there in the solution. My guess was that your solution and my powershell console use different assembly versions.

I see the fallback. This one works fine.

My main problem still exists: I can't get the groups recoursively. My user is in group A and group A is in group B. I give group B access to the site but the user won't get permission. I see in the logs that group B is not listed.

Is it a known limitation that I can only give permission to a group that the user belongs directly to?

[Yvand]

The PrincipalOperationException exception is thrown because of a bug in .NET (in System.DirectoryServices.AccountManagement.dll).
It is expected to be fixed in both.NET 4.6.2 and .NET 4.7.1, which should ship with the January 2018 updates of .NET.
Once the fix is installed, nested groups should work fine.
Until then, all user membership operations which get this exception will fallback to LDAP query, which does not get the nested groups, as you noticed.
Technically it's possible to update LDAPCP to get nested groups but it would be quite a big work to do (e.g. handle special cases like when group is not in the same domain).

[engineererr]

Hallo @Yvand

Do you have any news on this one?
Is the bug fix already released? Do you have planned to build against the new framework-version soon?

Thank you very much
Kai

[Yvand]

Hello @kurky91, yes, fix is now available, but not easy to find.
The key description is "TokenGroupSet now supports unresolvable SIDs by returning a principal with the original SID"
Here are the links:

• Windows Server 2008: https://support.microsoft.com/en-us/help/4054981
• Windows Server 2012: https://support.microsoft.com/en-us/help/4054979
• Windows Server 2012 R2: https://support.microsoft.com/en-us/help/4054980
• Regarding Windows Server 2016, it should be fixed by https://support.microsoft.com/en-us/help/4057142 but I'mm not sure since the description is missing...

As soon as you install one of the fix above, the issue should be fixed, LDAPCP does not need to be recompiled or updated.

[engineererr]

Hello @Yvand

The problem still persists on Windows Server 2016. I just updated to .NET Framework 4.7.2.
The server has the newest Update installed: https://support.microsoft.com/en-us/help/4480977

In this particular environment, I have deployed a fork of your LDAPCP to read claims and save them to UPS. I could do code changes.

Do you have a suggestion?

Thank you very, veeery much

[Yvand]

Hello @kurky91
After you installed the .NET update, what is the error recorded in ULS logs?
Can you confirm if you can reproduce it using this script (to run on SharePoint server):

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$username = read-host -prompt "Enter a username"
$ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain
$user = [System.DirectoryServices.AccountManagement.UserPrincipal]::FindByIdentity($ct, $username)
$groups = $user.GetAuthorizationGroups()
foreach($g in $groups) {
  $g.SamAccountName
}

[engineererr]

Hello @Yvand

Yes, I can reproduce the error with your script.

[engineererr]

Hello @Yvand

Do you think the error is not solvable at the moment?
If so.. then we keep our workaround inplace: a script that resolves all the groups and adds those groups seperately.

Thank you
Kai

[Yvand]

hi @kurky91 sorry for my late reply
Can you check the version of "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll" on the SharePoint server?
You very likely face a .NET bug that was fixed some time ago, can you update .NET to latest version and run the PowerShell script again?

[engineererr]

Thanks for your reply, @Yvand

I think this DLL is as new as possible, right?

[mathiasstocker]

Hello @Yvand - Can you give us any update on this topic?

[Yvand]

Hi @mathiasstocker this issue was closed a long time ago and I missed to follow up with the new comments.
Do you also reproduce the issue when you run the PowerShell script I provided here?
If so, it is a bug in .NET framework that is normally fixed, but somehow you still repro it.

In LDAPCP, you can avoid it by not checking the box "Use .NET API" in "Augmentation" section in LDAPCP global config page. This will fallback to a simple LDAP query instead of using .NET helpers, but the drawback is that it does not get nested groups.

[Yvand]

I reopen this oooooold issue because I'm confident that I fixed it in ab7131c
It happened because the code was executed as the impersonated account IUSR, which got an access denied.
The fix is to execute this code as the application pool account