Forum Discussion
Server 2019 ADFS LDAP Errors After Installing January 2022 Patch KB5009557
As it stands now, it appears that KB5009557 breaks 'something' with the connection between ADFS and AD. When this happens you are unable to SSO until the ADFS server is rebooted (sometimes it ta...
So I may have potentially fixed it. The issue seemed to only happen with the Sharepoint relying party, but was definitely tied to KB5009557.
On our fully patched ADFS server (to now also include the February cumulative patches), I was able to reproduce the error and do a capture. I also saw a few extra errors pop in that I hadn't paid attention to before. Within that group of errors, one of them related to not being able to reach the global catalog server of our parent domain (Error 247). I ignored those initially as I didn't think any of our apps would need to enumerate the parent domain, but Sharepoint apparently wants to?
In the capture, I noticed we were getting:
ErrorCode: KDC_ERR_ETYPE_NOSUPP (14)
That error led me to this MS docs site:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/unsupported-etype-error-accessing-trusted-domain
Under 'Method 3', we didn't have the option, "The other domain supports Kerberos AES Encryption" selected. So I went in and checked that box on both the parent and child domain.
Here is a snippet from that section:
1.) In Active Directory Domains and Trusts, navigate to the trusted domain object (in the example,contoso.com). Right-click the object, select Properties, and then select Trusts.
2.) In the Domains that trust this domain (incoming trusts) box, select the trusting domain (in the example, child.domain.com).
3.) Select Properties, select The other domain supports Kerberos AES Encryption, and then select OK.
4.) On the Trusts tab, click OK.
5.) Navigate to the domain object for the trusting domain (child.contoso.com).
6.) Repeat steps 1 - 4 to make sure that the trust configuration for this domain mirrors the trust configuration for the other domain (in this case, the incoming and outgoing trust lists include contoso.com).
Seemingly, as soon as I did that the ADFS errors went away. So far, we've gone a decent amount of time without seeing the same errors for our Sharepoint RP, but of course we'll see.
My only guess is that Sharepoint was looking for something in the parent domain and 'occasionally' would attempt to negotiate down to an unsupported kerberos encryption type.
I'm not fully declaring victory, but hopefully it helps someone.
On our fully patched ADFS server (to now also include the February cumulative patches), I was able to reproduce the error and do a capture. I also saw a few extra errors pop in that I hadn't paid attention to before. Within that group of errors, one of them related to not being able to reach the global catalog server of our parent domain (Error 247). I ignored those initially as I didn't think any of our apps would need to enumerate the parent domain, but Sharepoint apparently wants to?
In the capture, I noticed we were getting:
ErrorCode: KDC_ERR_ETYPE_NOSUPP (14)
That error led me to this MS docs site:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/unsupported-etype-error-accessing-trusted-domain
Under 'Method 3', we didn't have the option, "The other domain supports Kerberos AES Encryption" selected. So I went in and checked that box on both the parent and child domain.
Here is a snippet from that section:
1.) In Active Directory Domains and Trusts, navigate to the trusted domain object (in the example,contoso.com). Right-click the object, select Properties, and then select Trusts.
2.) In the Domains that trust this domain (incoming trusts) box, select the trusting domain (in the example, child.domain.com).
3.) Select Properties, select The other domain supports Kerberos AES Encryption, and then select OK.
4.) On the Trusts tab, click OK.
5.) Navigate to the domain object for the trusting domain (child.contoso.com).
6.) Repeat steps 1 - 4 to make sure that the trust configuration for this domain mirrors the trust configuration for the other domain (in this case, the incoming and outgoing trust lists include contoso.com).
Seemingly, as soon as I did that the ADFS errors went away. So far, we've gone a decent amount of time without seeing the same errors for our Sharepoint RP, but of course we'll see.
My only guess is that Sharepoint was looking for something in the parent domain and 'occasionally' would attempt to negotiate down to an unsupported kerberos encryption type.
I'm not fully declaring victory, but hopefully it helps someone.