u/rpodric

Here's a look at it, showing exactly where it's buried in Defender and how it's configured:

https://i.imgur.com/OOKiwWA.png

Has anyone here gotten it to work to enforce use of Edge/Edge for Business when accessing M365 properties? If so, please tell me what you did.

Yes, it's in Preview, but for a year or two. Its only job is to do the one thing that I can't get it to do, which is to put up a message about needing to use Edge.

What I've done:

-The above screen as you see in the screenshot

-CA policy: Target resources on "All resources" (confirmed working by Entra ID sign-in logs showing Applied); Conditions: Windows/Mac, Client app Browser; Session: Use CA App Control (Use custom policy)

-MDCA session policy: under the Conditional Access section and is a "Monitor only" type. Currently no "Matching activities" set (have tried many before), but its log shows that it's matching. I don't think that Matching activities is needed in this context.

The result: Chrome and Firefox (desktop) reach M365 apps with no prompt or block but with abundant indicators in the rewritten URLs that the reverse-proxy (mca.ms) is active. When troubleshooting, I even tried Edge for Business, which of course is NOT supposed to hit the proxy. It was as if I was using Chrome.

It's very much like this "Edge for Business protection" straight up doesn't work or things just aren't getting that far. I hope I'm just doing something wrong.

Testing in E5

Update: Finally got it to work, with no changes to the above configuration. The reason:

- One thing I didn't mention above, is that I started testing on our normal tenant, Business Premium. When I realized early on that a MDCA session policy was needed, I found that the specific kind wasn't even available in straight Business Premium. At that point, I switched over to a separate tenant that had E5, and used it for all future testing.

- I continued testing with the same PC...but that machine was AAD registered with our normal tenant. I never thought about that, as the browser testing was going on by my logging in to the browser, of course, with E5-appropriate credentials. Turns out though, that the machine is registered/joined very much matters.

-The machine can be AAD registered or joined. But whichever one it is, it MUST agree with the tenant you're trying to access with the browser, regardless of how you're logging in with the browser. I only discovered this when testing with a brand-new VM and found everything to be magically working. Then I began to think about what was different, and it dawned on me.

Fix: Arrow navigation doesn’t work in Carousel widgets when Reduced Motion is enabled (#33613)

That's true. The manual advancement portion of the bug is indeed fixed now. Unfortunately, Autoplay, which was a central part of the stated problem, is not. Yes, it's better than it was: it didn't work at all before. But now the timing setting is ignored.

It's easy to notice: if you have the Windows "Settings -> Accessibility -> Visual effects -> Animation effects" toggled off (or it's off by default for you, which it is for some), then Elementor's "Autoplay Speed" in Slider Options is ignored on the published site and defaults to 3000 (3s), Swiper's default.

If you run this in the browser console after loading the page, the problem is laid out:

document.querySelectorAll('.swiper').forEach(el => {

if (el.swiper) {

console.log(el.swiper.params.autoplay);

}

});

With animation off:

{enabled: false, delay: 3000, waitForTransition: true, disableOnInteraction: true, stopOnLastSlide: false, …}

With animation on:

{enabled: true, delay: 5000, waitForTransition: true, disableOnInteraction: true, stopOnLastSlide: true, …}

In both cases, Elementor is set the same way: 5000.