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 takes several times).
We started getting errors (I'll paste the error below) after installing 5009557, and as soon as it pops up, you will get them continually until a reboot. However if/when the reboot does fix it, it will only be temporary as it seems that at some point (maybe when the kerberos ticket needs to be refreshed??) that it will break again. Right now our heavy hitter is our Sharepoint relying party so that will be shown in the error below.
On one occasion ADFS did break when I rebooted a few domain controllers.
We are currently using a gMSA and not a traditional service account. We have validated that other systems are able to query the domain via LDAP connections successfully with a gMSA after installing the January patches. This is only affecting the ADFS servers. The ADFS servers are still able to retrieve the gMSA password from the domain.
Our domain is healthy. No replication errors or any other issues. We do not have any one-way trusts etc.
So far the only thing that has worked for us is to uninstall KB5009557, which of course we don't want to do for security reasons.
What hasn't worked:
Updating the krbtgt password in proper sequence.
Installing OOB patch KB5010791.
I see that KB5009616 was released on 01/25 and it does mention a few kerberos items but the only thing related to ADFS is:
"Addresses an issue that might occur when you enable https://docs.microsoft.com/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-logging and an invalid parameter is logged. As result, Event 207 is logged, which indicates that a failure to write to the audit log occurred."
Which isn't our issue. Anyone know if this patch from the 25th resolves it? We're going to install it on one of our ADFS servers as a test.
Below is the error seen when the connection between ADFS and AD breaks:
Encountered error during federation passive request.
Additional Data
Protocol Name:
wsfed
Relying Party:
urn:sharepoint:prod
Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0018: Query ';tokenGroups,sAMAccountName,mail,userPrincipalName;{0}' to attribute store 'Active Directory' failed: 'The supplied credential is invalid.
Error code: 49
Server response message:
'. ---> Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapServerUnavailableException: The supplied credential is invalid.
Error code: 49
Server response message:
---> System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.
at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential)
at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection()
at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings)
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.ClaimsPolicy.Language.AttributeLookupIssuanceStatement.OnExecuteQueryComplete(IAsyncResult ar)
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Microsoft.IdentityServer.ClaimsPolicy.Language.PolicyEvaluationException: POLICY0018: Query ';tokenGroups,sAMAccountName,mail,userPrincipalName;{0}' to attribute store 'Active Directory' failed: 'The supplied credential is invalid.
Error code: 49
Server response message:
'. ---> Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapServerUnavailableException: The supplied credential is invalid.
Error code: 49
Server response message:
---> System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.
at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential)
at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection()
at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings)
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.ClaimsPolicy.Language.AttributeLookupIssuanceStatement.OnExecuteQueryComplete(IAsyncResult ar)
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapServerUnavailableException: The supplied credential is invalid.
Error code: 49
Server response message:
---> System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.
at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential)
at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection()
at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings)
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.ClaimsPolicy.Language.AttributeLookupIssuanceStatement.OnExecuteQueryComplete(IAsyncResult ar)
System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.
at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential)
at Microsoft.IdentityServer.GenericLdap.Channel.ConnectionBaseFactory.GenerateConnection()
at Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.Ldap.LdapConnectionCache.CacheEntry.CreateConnectionHelper(String server, Boolean isGC, LdapConnectionSettings settings)
1 Reply
- 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.
