Forum Discussion
Federation Issues - No protocol handlers?
Hi All,
It's been a number of years since I've federated a domain with Entra, i'm flipping this back in a home environment to complete some testing. Would appreciate some troubleshooting thoughts.
What from memory was a quick task, I've spent waaaaay to long on this today. I've rebuilt the environment a number of times with the same outcome.
- Install ADFS (Enabled the sign-in page).
- Install WAP.
- Generate Let's Encrypt certificate and provide to the servers.
- Port Forward 443 to the WAP server.
- Use Entra Connect to Federate the domain (AD FS Config looks good and generated as Microsoft Office 365 Identity Platform)
- WAP is configured via AAD Connect (Blank but seems alright talking back to ADFS)
I can hit https://adfs.domain.com/adfs/ls/idpinitiatedsignon.aspx and authenticate with UPN internally/externally.
I can hit https://adfs.domain.com/FederationMetadata/2007-06/FederationMetadata.xml internally/externally.
I also setup IAMShowcase to test (SAML 2.0 Test Service Provider) and published the app via the WAP, worked fine for SP and IDP initiated flows.
Interestingly enough, I am chucked the following error from the ADFS redirection with M365 authentication:
Error details: MSIS7065: There are no registered protocol handlers on path /adfs/ls/ to process the incoming request.
This raises an error on the ADFS server ID#364, I've rebuilt a few times and havent been able to find much in troubleshooting. Would love to hear if someone else has seen something similar, i'm at a bit of a loss here.
Encountered error during federation passive request.
Additional Data
Protocol Name:
Relying Party:
Exception details:
Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Get-MgFederatedDomainFederationConfiguration -Identity Domain.com
ActiveSignInUri : https://adfs.domain/adfs/services/trust/2005/usernamemixed
IssuerUri : http://domain/adfs/services/trust/
MetadataExchangeUri : https://adfs.domain/adfs/services/trust/mex
PassiveSignInUri : https://adfs.domain/adfs/ls/
PreferredAuthenticationProtocol : wsFed
SignOutUri : https://adfs.domain/adfs/ls/
I'm running into the same issue with v2.4.27.0 of Entra Connect. v2.3.8.0 works fine.
Still working on this one, but I’ve noticed that the active endpoint works fine, Teams/OneDrive etc all login as expected. Anything using a passive endpoint fails.
Please check on follow:
- IdP Initiated Sign-On Page: Ensure that the IdP-initiated sign-on page is enabled. You can do this by running the following PowerShell command:
Set-AdfsProperties -EnableIdPInitiatedSignonPage $trueVerify by
Get-AdfsProperties- Protocol Handlers: Make sure that the protocol handlers are correctly registered for the path /adfs/ls/. You can check this in the ADFS management console under the "Authentication" tab.
- Relying Party Trusts: Ensure that the relying party trusts are correctly configured and that they are not pointing to an incorrect endpoint.
- Firewall and Ports: Double-check that your firewall settings and port forwarding are correctly configured to allow traffic to the ADFS server.
- Event Logs: Look at the ADFS event logs for more detailed error messages that might give additional clue.
I've seen a couple of these over the past few weeks, looks like something changed, possibly on MS side. I haven't bothered to test it on my own though, nor have I seen a solution being mentioned anywhere.
If you do feel like wasting more time on this, here are few things to test. First, try configuring the RPT outside of AAD Connect, as that seems to be the common denominator in all similar threads I've seen. If nothing changes, enable trace logging on the AD FS server and check one failure event, hopefully it will spill out the actual issue. A Fiddler trace wouldn't hurt either.
Thanks VasilMichev,
Comforting in a way that I'm not the only one, I'll play further with the config over the next few days and see what else I can find.
Thanks for the tips and direction of troubleshooting VasilMichev I have identified the issue in further detail after manually configuring the RPT without success.
It looks like some of the components on the redirection URL are missing - wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline, when I add them back into the URL internally, I can authenticate and redirect back to M365 as expected. I can auth externally through the WAP when I do this, but it gets stuck in a loop, I'm thinking the WAP doesn't like me modifying the URL on the fly.
Not sure why this isn't provided in the redirection from M365 as expected, I'm guessing without this, the query won't hit the RPT and you end up with the same error as if you went straight to /adfs/ls. Might be a service side thing, maybe for recently federated tenants, still looking to see what I can dig up on this.
An example of the before URL - https://adfs.domain.com/adfs/ls/?wctx=LoginOptions%3D3%26&cbcxt=&username=test.user%40domain.com&mkt=en-US&lc=
An example of the after URL - https://adfs.domain.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=LoginOptions%3D3%26&cbcxt=&username=test.user%40domain.com&mkt=en-US&lc=
Interesting. Are you certain it's M365 that's not providing the parameters, might also be something on the WAP side? In fact, have you tried this without WAP - the less moving parts involved, the better.
On M365 side, are you getting the same experience regardless on which workload you initiate the login? I.e. do you have the same experience when accessing the "home" page vs OWA vs SharePoint or any other "passive" one? If the issue is on M365 side, it would be nice to understand whether it's purely on Entra side, or dependent on the resource.
In any case, might want to open a service request for this one. I tried pining some folks, hoping to get additional info, but no dice :(
