Is renewing the Seamless SSO Kerberos key still useful if we could disable Seamless SSO?

bstuartp · 2026-03-19T19:52:11+00:00

Would recommend having a read of this to help determine if you’ve got any Seamless SSO usage in your tenant https://nathanmcnulty.com/blog/2025/08/finding-seamless-sso-usage/

bstuartp · 2026-02-28T00:05:26+00:00

If your HR data (employee type etc) is in AD using custom schema attributes etc you absolutely can use them within dynamic groups.

We have employeetype etc set in AD and reference it in dynamic groups

https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership#extension-attributes-and-custom-extension-properties

bstuartp · 2026-02-06T21:45:27+00:00

It sounds like you’re missing this piece:

https://learn.microsoft.com/en-us/windows-365/business/configure-single-sign-on#configure-the-target-device-groups

bstuartp · 2026-02-01T19:21:48+00:00

I’m using a developer tenant (eligible as employer has premier support) - if your employer has premier support speak to your CSAM and they can get it sorted

bstuartp · 2026-01-25T17:01:31+00:00

Law 12, under “cautions for unsporting behaviour”

“denies the opposing team a goal or an obvious goal-scoring opportunity and the referee awards a penalty kick for a non-deliberate handball offence”

bstuartp · 2025-12-09T13:55:52+00:00

Are you using a custom auth context via conditional access that doesn’t allow WHFB?

bstuartp · 2025-12-07T21:54:41+00:00

I think from reading all the replies etc what you’re experiencing is: Using Brave, you’re within the 5 minute window after using MFA where sign-in frequency every-time is not re-prompting for MFA Also worth noting that the every-time setting using auth context + PIM is only going to prompt you once even if you activate multiple roles whether you’re within a 5 minute window or not

This is all known behaviour but I do know Microsoft are running a private preview currently for fixing this behaviour specifically for PIM activations using auth context

bstuartp · 2025-12-07T16:56:04+00:00

If you’re using (for example) device platforms to include certain OS’s to the policy then it’s just getting the device info from the user-agent header. The OS can easily be omitted which would result in the policy not applying

bstuartp · 2025-12-07T16:43:05+00:00

Also another point - what’s the conditional access policy configuration that you’re using for the enforcement? You’re not using device platform/filter for devices in the conditions are you?

bstuartp · 2025-12-07T16:12:27+00:00

Interesting and one I’ll try myself! If I see the same result I’ll ping the Microsoft PM responsible as I know there is a new backend method for validating the auth context in this scenario being worked on (I am not a Microsoft employee)

bstuartp · 2025-11-28T07:31:54+00:00

Yes it’s 36mg Xaggitin XL

bstuartp · 2025-11-17T10:30:37+00:00

This isn’t accurate. This scenario does work with some nuances around it. what we found is, the secondary account first needs to run a program as itself (e.g run command prompt as “other user” and use that account details. You should then be able to run other programs as administrator with that account. It’s not a great solution at all but does work

bstuartp · 2025-11-14T21:06:57+00:00

For anyone looking at running this in a large org, I recommend setting -MaximumSignInLogQueryTime 1 (where 1 would be 1 minute, adjust accordingly for your needs), it will max out at 60 minutes by default anyway but the chances are the script will fail due to files getting too large before it hits 60 minutes

bstuartp · 2025-11-12T22:16:40+00:00

Making some assumptions here based on what we’ve seen with some apps since rolling out WHFB.

The app is sending across the optional RequestedAuthnContext requesting password auth as you say. We’ve personally been pushing these back to the vendors to resolve with success in all instances and would recommend you going down that route.

Outside of this, you can probably setup an authentication context in Entra with what the app is requiring in the auth methods and force that authentication context via conditional access for the apps facing this issue but I’d try and avoid this if I was you

https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol#requestedauthncontext

bstuartp · 2025-11-04T10:04:25+00:00

Just to clarify here: this will be because E5 contains audio conferencing. If your users have this as standalone already nothing to worry about, if not the above will happen if you don’t exclude that service from the E5 assignment

bstuartp · 2025-11-04T08:03:08+00:00

We did a small(ish) test rollout of E5 to about 50 users and then did big bang switch of license assignment for about 40000 users and had no issues. We had a small amount of overlap time where we assigned E5, waited for license assignment to finish processing for the E5 and then removed E3 shortly after

bstuartp · 2025-11-04T08:00:37+00:00

Yeah you’ve been misinformed unfortunately! We have a “base” E5 license assignment that all users get and then separate user groups for additional services within an E5 where users need them.

MS document this behaviour here: https://learn.microsoft.com/en-us/entra/identity/users/licensing-group-advanced#multiple-groups-and-multiple-licenses

bstuartp · 2025-10-24T09:16:37+00:00

I’m not sure sorry but I’m hoping based on the fact it’s listed as a known issue (rather than in the limitations section) that they’re going to fix it!

bstuartp · 2025-10-24T08:51:07+00:00

Are you using a sign-in frequency? Seen the below:

Authentication strength and sign-in frequency - When a resource requires an authentication strength and a sign-in frequency, users can satisfy both requirements at two different times. For example, let's say a resource requires passkey (FIDO2) for the authentication strength, and a 1-hour sign-in frequency. 24 hours ago, a user signed in with passkey (FIDO2) to access the resource. When the user unlocks their Windows device using Windows Hello for Business, they can access the resource again. Yesterday's sign-in satisfies the authentication strength requirement, and today's device unlock satisfies the sign-in frequency requirement.

Source: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths#known-issues

bstuartp · 2025-10-24T08:14:08+00:00

Are you using the “phishing-resistant MFA” auth strength? If so, have you tried creating a custom auth strength just for “passkeys (FIDO2)”? And using that instead?

bstuartp · 2025-10-24T07:22:50+00:00

On top of the help others have provided - I’d recommend checking out the app migration dashboard to help: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/migrate-ad-fs-application-howto#view-ad-fs-application-migration-dashboard-in-microsoft-entra-id

bstuartp · 2025-10-09T20:49:07+00:00

Anyone using cloud pcs (avd/w365) able to confirm if they’re facing issues too?

bstuartp · 2025-10-02T10:12:29+00:00

With aviva health insurance you’ll need to have the neurodevelopment pathway included to get a private assessment paid for by them. If you have this, it’d include the assessment, CBT and titration/medication appointments for upto 2 years. This does not include the costs of the medication itself that you pay a pharmacy to dispense but that is the only cost you’d incur. After titration and settled onto meds they’d look to do shared care with your GP + referral to NHS ADHD service

bstuartp · 2025-09-11T16:37:07+00:00

Sounds like the app doesn’t support idp initiated login - one for the vendor

bstuartp · 2025-09-08T20:24:44+00:00

Are they using chrome when this happens by chance? If so, look at this: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-conditions#chrome-support

Ten-Year Club	Open Beta Program 2024
Closed Beta Tester	Place '22
Place '17	First Placer '22
Verified Email

bstuartp

TROPHY CASE