search

Yvand / LDAPCP

A claims provider to connect SharePoint Subscription / 2019 / 2016 with Active Directory and LDAP directories in federated authentication
https://ldapcp.com
Apache License 2.0
57 stars 25 forks source link

LDAPCP and securitytoken.svc timeout when .Net Helper is enabled under augmentation #180

Closed lacoba-icc closed 1 year ago

lacoba-icc commented 1 year ago

Dear Yvan,

Recently we started facing an issue with LDAPCP on SharePoint 2019 when groups augmentation is enabled and the .Net Helper checkbox is active. That functionality has been working fine until yesterday. In essence, when the .Net Helper for an specific domain is active, the users cannot access the Sharepoint sites as Sharepoint returns a timeout error:

Claims Saml Sign-In: Could not get local token for trusted third party token. Exception: 'System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9989989. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. ---> System.Net.WebException: The operation has timed out
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) - -- End of inner exception stack trace --- at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason) at System.ServiceModel.Channels.HttpChannelFactory1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

Whenever we deactivate the .Net Helper, it works and no issues.

Are you aware of any recent issue introduced by any OS patch that could affect like that? Issue started just yesterday and so far we identified two patches installed:

https://support.microsoft.com/en-us/topic/june-13-2023-kb5027219-os-build-14393-5989-e99f2865-6f1a-41e4-9583-c0d00be7468d https://support.microsoft.com/en-au/topic/june-13-2023-kb5027123-cumulative-update-for-net-framework-4-8-for-windows-10-version-1607-and-windows-server-2016-7eccbe2e-67f4-4878-9f3a-fde1d13080f2

Please, let me know if further details are required. Thanks!

Yvand commented 1 year ago

@lacoba-icc thank you for reporting this, nope I'm not aware of any issue introduced by those updated. I will test them, but on your side, if possible, can you please repro the issue and capture SharePoint logs while it happens, and filter on Product/Area "LDAPCP"

Thanks!

lacoba-icc commented 1 year ago

Thanks Yvan for replying back! So far we saw the message below: [LDAPCP] Unexpected error occurred while getting AD groups of xxx@domain.org in LDAP://domain.org using UserPrincipal.GetAuthorizationGroups(). This is likely due to a bug in .NET framework in UserPrincipal.GetAuthorizationGroups (as of v4.6.1), especially if user is member (directly or not) of a group either in a child domain that was migrated, or a group that has special (deny) entities.: System.DirectoryServices.AccountManagement.PrincipalOperationException: While trying to retrieve the authorization groups, an error (1722) occurred., Callstack:

As the logs contain some sensitive information, can I send them to you in a different way? Thanks!

Yvand commented 1 year ago

@lacoba-icc sorry I don't have a convenient location where you can safely drop the logs. Can I suggest that you merely find and replace the domain in the LDAP connection string? It should be enough to scrub the logs

lacoba-icc commented 1 year ago

@Yvand thanks for the update. Please find enclosed the logs filtered by LDAPCP. Let me know if further details are required. Thanks a lot! LDAPCPv2.csv

lacoba-icc commented 1 year ago

@Yvand sorry, just to give you an update. Discussing it with one colleague seems the problem could be related with the fact that traffic on port 445 was blocked towards the domain controllers. Colleagues reverted the change and seems the LDAPCP is working fine again when doing the augmentation. Port got blocked on the firewall due a security requirement.

Does it makes sense that LDAPCP requires port 445 enabled for that functionality to work? I thought ports 389, 636, 88, 53 are more than enough. Thanks a lot!

Yvand commented 1 year ago

@lacoba-icc interesting , so this repro 100% with all users? Can you try to repro in PowerShell using the script https://www.ldapcp.com/docs/help/troubleshooting/#replay-augmentation-in-powershell ?

Yvand commented 1 year ago

@lacoba-icc I didn't know that LDAPCP needed the port 445 to be opened on the DC for augmentation, but I can guess it is related to how it authenticates to get AD group membership. This is suggested in this article:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#net-logon

lacoba-icc commented 1 year ago

Hi @Yvand , thanks for replying back.

We are doing further tests but indeed, seems issue is related with port 445 when it gets blocked. For now I think we can close that issue because is indeed related with the net logon required ports. Thanks a lot for your assistance! :)