Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Learn More

Firefox 92 causes cross domain authentication errors

  • Không có trả lời
  • 1 gặp vấn đề này
  • 6 lượt xem
more options

I currently run several environments for Dynamics 365 products. Our clients can choose to use our authentication (ADFS 4.0) or we set up a SSO option for them (normally also ADFS of some flavor). The piece that is similar between both is that the domain they authenticate to would not be the same as the application they are necessarily using. For example my clients have a mixture of on premise and cloud deployments but if they are SSO only pull their tokens from one domain.

Anyways the real TLDR as I can determine is as follows:

Has anyone seen a problem with firefox 92 stripping out headers? My scenario is I have an AD FS server that I use for single sign on with a domain name that is different from the application that it federated with. When I attempt to login using Firefox, the traffic flows as: 1. Hit the app url and get 302 redirected to the IDP 2. enter credentials at the IDP and get redirected to the app url 3. the app has an internal and external claims URL, so the internal claims url 302 redirects me to the external url 4. FF brings up the external url, but does NOT pass the MSISAuth and MSISAuth1 cookies from the IDP 5. The app thinks I've not authenticated, so it 302 redirects me back to the IDP 6. The IDP sees the MSISAuth and MSISAuth1 cookies, so it knows it authenticated me and it 302 redirects me back to the app wash, rinse, repeat for 5 times until AD FS realizes that I've done this 5 times, then it throws an error at me to stop the loop. This was working fine in FF 91 and it currently works in Chrome and Edge. The expected flow is almost the same, except that the app get's the cookies presented to it from AD FS. I was thinking this was something to do with Enhanced Tracking Protection. When I selected Custom and unchecked all the options (I think this disables ETP) I still get the cookies stripped from the header. I re-enabled ETP with standard protections and manually added the URLs using the steps outlined at https://bugzilla.mozilla.org/show_bug.cgi?id=1432644#c27. Is this a bug where FF doesn't honor the settings to disable ETP in V92? The reason I was thinking that ETP was to blame is the IDP has a domain of IDP.example and the app has the URL's of internalclaim.app and externalclaim.app.

I feel like I am missing something obviously here but I can't find it. If I create a CRM deployment using the same domain as our ADFS servers it works fine. If I use what our public designation is, it fails. SSO obviously fails. It only started after upgrading to 92 and that is consistent amount all of our clients. I have tried to go through every advance config that was touched with the 92 upgrade and nothing there seems to help. We compared our UAS to a friend of ours who is not having issues since the 92 release and they look the same. If this was a system 92 problem I would expect the internet to be exploding by now but it is not. It makes me think there is something I am missing in our fundamental set up but for the life of me I can't identify a missing update, compatibility issue, known issue blah blah blah. Edge, Chrome, Safari they all still work fine. It is just the Firefox 92 update that all of a sudden killed our authentication.

I currently run several environments for Dynamics 365 products. Our clients can choose to use our authentication (ADFS 4.0) or we set up a SSO option for them (normally also ADFS of some flavor). The piece that is similar between both is that the domain they authenticate to would not be the same as the application they are necessarily using. For example my clients have a mixture of on premise and cloud deployments but if they are SSO only pull their tokens from one domain. Anyways the real TLDR as I can determine is as follows: Has anyone seen a problem with firefox 92 stripping out headers? My scenario is I have an AD FS server that I use for single sign on with a domain name that is different from the application that it federated with. When I attempt to login using Firefox, the traffic flows as: 1. Hit the app url and get 302 redirected to the IDP 2. enter credentials at the IDP and get redirected to the app url 3. the app has an internal and external claims URL, so the internal claims url 302 redirects me to the external url 4. FF brings up the external url, but does NOT pass the MSISAuth and MSISAuth1 cookies from the IDP 5. The app thinks I've not authenticated, so it 302 redirects me back to the IDP 6. The IDP sees the MSISAuth and MSISAuth1 cookies, so it knows it authenticated me and it 302 redirects me back to the app wash, rinse, repeat for 5 times until AD FS realizes that I've done this 5 times, then it throws an error at me to stop the loop. This was working fine in FF 91 and it currently works in Chrome and Edge. The expected flow is almost the same, except that the app get's the cookies presented to it from AD FS. I was thinking this was something to do with Enhanced Tracking Protection. When I selected Custom and unchecked all the options (I think this disables ETP) I still get the cookies stripped from the header. I re-enabled ETP with standard protections and manually added the URLs using the steps outlined at https://bugzilla.mozilla.org/show_bug.cgi?id=1432644#c27. Is this a bug where FF doesn't honor the settings to disable ETP in V92? The reason I was thinking that ETP was to blame is the IDP has a domain of IDP.example and the app has the URL's of internalclaim.app and externalclaim.app. I feel like I am missing something obviously here but I can't find it. If I create a CRM deployment using the same domain as our ADFS servers it works fine. If I use what our public designation is, it fails. SSO obviously fails. It only started after upgrading to 92 and that is consistent amount all of our clients. I have tried to go through every advance config that was touched with the 92 upgrade and nothing there seems to help. We compared our UAS to a friend of ours who is not having issues since the 92 release and they look the same. If this was a system 92 problem I would expect the internet to be exploding by now but it is not. It makes me think there is something I am missing in our fundamental set up but for the life of me I can't identify a missing update, compatibility issue, known issue blah blah blah. Edge, Chrome, Safari they all still work fine. It is just the Firefox 92 update that all of a sudden killed our authentication.