6 ms·

It looks like enforcing 2fa in an org (finally!) means anyone who doesn't have 2fa will be booted out (included whoever may be paying for it at the time) with a

by mstade 10y ago

It looks like enforcing 2fa in an org (finally!) means anyone who doesn't have 2fa will be booted out (included whoever may be paying for it at the time) with an email explaining why. I'm afraid to tick the box because of this. :o/

jedberg 10y ago
Contact everyone, tell them they have a week, then tick the box. If they didn't do it within the week it's either not important to them or they'll add it right quick after you tick the box.
- mwarkentin 10y ago
  We have some "shared" users for things like bots, etc.. wonder how to deal with that since we don't want to enable MFA for them. Otherwise I'd be all over this..
  - RyJones 10y ago
    This is a huge issue for us at the Linux Foundation. Infra accounts make enforcing MFA for orgs impossible Even if I could do classes of accounts. Owners and admins, MFA required. Users (bots) that just update CI status, not required.
    - sciurus 10y ago
      For CI bots I think in the future you will be able to build an "integration" instead of using a user account. From the blog post "We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to." https://developer.github.com/changes/2016-09-14-Integrations-Early-Access/ https://developer.github.com/changes/2016-09-14-Integrations... https://developer.github.com/early-access/integrations/ https://developer.github.com/early-access/integrations/
    - WorldMaker 10y ago
      Also mentioned in the announcement is that bots and integrations won't need their own user accounts or to impersonate users in the (near?) future.
  - gregshap 10y ago
    For bot accounts, you either generate a personal access token for that account or (probably better) use SSH. Not so different from human users who have 2FA activated and use the command line to interact with github. https://help.github.com/articles/providing-your-2fa-authentication-code/ https://help.github.com/articles/providing-your-2fa-authenti...
- mstade 10y ago
  You're right, and I'll be sending out the emails tomorrow. Thanks!
captn3m0 10y ago
Currently, we tell every new employee on joining the org to enable it, and review it a week later to ensure that they followed through. It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later). I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).
- Kudos 10y ago
  The bot user probably doesn't need to actually be in your org though, convert them to outside collaborators.

by mstade 10y ago

jedberg 10y ago

Contact everyone, tell them they have a week, then tick the box. If they didn't do it within the week it's either not important to them or they'll add it right quick after you tick the box.

mwarkentin 10y ago
We have some "shared" users for things like bots, etc.. wonder how to deal with that since we don't want to enable MFA for them. Otherwise I'd be all over this..
- RyJones 10y ago
  This is a huge issue for us at the Linux Foundation. Infra accounts make enforcing MFA for orgs impossible Even if I could do classes of accounts. Owners and admins, MFA required. Users (bots) that just update CI status, not required.
  - sciurus 10y ago
    For CI bots I think in the future you will be able to build an "integration" instead of using a user account. From the blog post "We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to." https://developer.github.com/changes/2016-09-14-Integrations-Early-Access/ https://developer.github.com/changes/2016-09-14-Integrations... https://developer.github.com/early-access/integrations/ https://developer.github.com/early-access/integrations/
  - WorldMaker 10y ago
    Also mentioned in the announcement is that bots and integrations won't need their own user accounts or to impersonate users in the (near?) future.
- gregshap 10y ago
  For bot accounts, you either generate a personal access token for that account or (probably better) use SSH. Not so different from human users who have 2FA activated and use the command line to interact with github. https://help.github.com/articles/providing-your-2fa-authentication-code/ https://help.github.com/articles/providing-your-2fa-authenti...
mstade 10y ago
You're right, and I'll be sending out the emails tomorrow. Thanks!

captn3m0 10y ago

Currently, we tell every new employee on joining the org to enable it, and review it a week later to ensure that they followed through. It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later). I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).

Kudos 10y ago
The bot user probably doesn't need to actually be in your org though, convert them to outside collaborators.