13 ms·
Google auth UX is quite hostile. For example, if your group admin enables 2A requirement, you can't login if it your account doesn't already have 2A, and you ca
by smsm42 6y ago
Google auth UX is quite hostile. For example, if your group admin enables 2A requirement, you can't login if it your account doesn't already have 2A, and you can't set up 2A if you are not logged in, of course. So the workflow goes like this: enable 2A requirement. Wait for people to scream, disable 2A, let them log in and hopefully enable 2A. Enable again, let the next group of people whose sessions by now expired to discover they can't log in, disable. Etc. until hopefully everybody enables it. That seems to be the officially endorsed process: https://support.google.com/a/thread/6090262 https://support.google.com/a/thread/6090262
Sane approach would be to let people log in and immediately require them to set up 2A and then continue with their logged in lives, but I guess that was too hard.
- toast0 6y agoIf your org is small, you can run a report to see who hasn't enabled 2FA and then yell at them. They made it better for new users a while ago (you can now configure a grace perioid), but I don't know/remember if this helps for existing users. If you've got users you can't cutoff who don't setup 2fa, then you need to make an exception group. You can run automation to send nag emails if there's people in it, etc. But then don't merge with another company with g suite, cause merging accounts isn't supported and you'll have a mess.