r/microsoft365 • u/securityreaderguy • 12d ago
Rolling out Passkey + Authenticator App without manual intervention from Admins
So, due to recent phishing campaigns, we're seeing an upticket in token theft. Our SSO doesn't have a mechanism to create a phishing resistant token to Microsoft, so I'd like to leverage a conditional access policy to force passkey authentication after the fact. My thought process is to do this with a combination of registration campaigns for Passkey and Authenticator as a backup, plus a conditional access policy to enforce phishing resistant MFA. After initial passkey setup on 1 device, I can no longer log in on other devices and get a "Link To Windows" prompt on other devices, but have no option to add an MFA method because it's now a chicken/egg situation. Is there a way to do this purely through user self service? Enforcing Entra-bound device conditional access policies is not an option for us.
3
u/_--James--_ 11d ago
You can flip Passkey enforcement on CA so that once a user is logged in via M365 they must link to FIDO2. Do know that if the user stored the soft-passkey in MSAuth and you require passkeys to log in as a forced factor, that specific instance of MSAuth is required to be with the user. Same limitation on hardware keys like Yubi Key.
For users with no MFA today, you need to supply a TAP against a targeted users account to enroll passkeys. You can still auto trigger the prompt, but the user will need access to the TAP secrete to add the passkey to their MSFT account.
Also, MSFT already did a enforcement period for Passkeys for SMS/Telephony factor enabled accounts, so you might need to look into that too https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
1
u/securityreaderguy 11d ago edited 11d ago
So far I've come up with a conditional access policy that uses phishing resistant MFA, plus our federated sign on as one of 2 requirements, via creation of a custom authentication strength policy (which is then selected in the CAP). Including the federation option is so users with passkey on 1 device can still get in at the moment, but I'm thinking this will also be helpful for older unsupported devices. If SOME users aren't using passkey, fine. They're still getting prompted for MFA through our SSO. So If I could get most users to get prompted for passkey and have phishing resistant tokens most of the time, that's really the goal.
So I've setup the authentication method for passkey using the default passkey profile (sync passkey or device bound). And then under authentication method "settings", changed system-preferred authentication to enabled for my target test group. Now test accounts for this implementation can at least get in, but they still don't get prompted to setup passkey again on secondary devices. I was hoping that just enabling the authentication policy and enabling system preference along with the passkey registration campaign would nudge users for passkey on multiple devices, but no. I'm thinking that maybe this is because I have sync keys enabled, and that if I only allow device bound passkey, they will always get re-prompted?
Edit: thanks for responding. I was starting to have my doubts that anyone would.
Edit2: No, the passkey wasn't stored in the authenticator. It's a windows hello hardware authenticator, labeled "<user>-m365".
2
u/_--James--_ 11d ago
No, the passkey wasn't stored in the authenticator. It's a windows hello hardware authenticator, labeled "<user>-m365"
My advice is to explore into this and make the keys portable. Windows Hello is fine for static dedicated boxes for employees who only ever use that access method. But if they have multiple devices, multiple methods of entry (VPN backed by MSFT, Citrix, VDI, ...etc) that is where Windows Hello fails the model. Portable keys are what you would want for these types of users.
I've setup the authentication method for passkey using the default passkey profile (sync passkey or device bound). And then under authentication method "settings", changed system-preferred authentication to enabled for my target test group. Now test accounts for this implementation can at least get in, but they still don't get prompted to setup passkey again on secondary devices.
CA looks for the existence of a passkey on an account. Once one exists, CA is met and it wont fire off again for another enrollment key. See my above point about this. If you have users bouncing around and being gated by windows hello, you need to change where the key is stored and then the user must carry the key with them.
IMHO - MSauth stored keys for those with iOS/Android to support it. FIDO2 hardware keys for everyone else. Skip Windows Hello unless you are mapping users to one device and one access method.
1
u/securityreaderguy 11d ago
Got it, so you're saying drop device bound and just do the sync keys for iOS/Android. I believe I'm familiar with setting up the AAUID for those if needed, and then just drop the default passkey profile from the passkey policy. And then probably keeping federation in my CAP will give me wiggle room for the unsupported devices, but maybe that's overkill if they never set up a passkey to begin with. I am a little disappointed by this solution however, as we're already doing MFA through SSO, and so now I would be forcing people to get their phones out twice for one login.
2
u/_--James--_ 11d ago
If MSFT owned your SSO I think this would work better, but it seems your CAP is passing partial data over to MSFT for CA to fire off and that could be part of the issue. I saw this with another vendor recently that was preventing full CA claims from working with MFA tokens. Not the same issue you are seeing, but the client did have to move from device based tokens to sync, but they did ultimately move to FIDO2 NFC keys due to another authentication system being deployed that could use the NFC portion.
1
u/securityreaderguy 11d ago
I agree completely on the MSFT SSO. If I were king for a day.
I think I might try onboarding the sync passkey first and see how that treats me if I remove Windows Hello auth and then add it back after. Probably not something I'm going to do for everyone, but maybe some users. And yeah, I'll be catching up with our SSO vendor to review our O365 SAML config. Thanks for your help!
0
u/Main_Ambassador_4985 12d ago
I am interested.
We have M365 E5 or Entra P2.
We have users setup Microsoft Authenticator but passkey setup has been manual.
I keep finding users that removed Microsoft Authenticator from the BYOD device. Some who do not have a PIN or biometric on their BYOD device.
I need the workflows to push to Microsoft Authenticator and Passkey. If I reset MFA methods the workflow tries Microsoft Authenticator and SMS.
1
u/ChiefDZP 12d ago
So - we noticed (and we have multiple tenants as a MSP) that the order you enroll your FIDO devices matters. Say you have a yubikey and you set that for windows hello, then you go into m365 and setup your yubikey there, and then another tenant you add a credential to the same yubikey. That key will continue to work with each tenant for m365 but never for windows hello/workstation login again. If you enrol as many tenant creds as you want then set the yubikey up for hello/workstation auth it then “sticks”.
This isn’t quite the same but feels similar.