Likely Conduit queries:

1. Use phid.lookup to get the phids for WMF-NDA, acl*security, acl*sre-team (could be cached or just defined as constants).
2. Use project.query to get the member lists of the aforementioned policies (they need to be searched as projects to get member lists).
3. Use user.search to get a list of users (via their phids) that have MFA enabled and those that do not ("mfa" : true vs "mfa" : false as a constraint) and possibly disabled users ("isDisabled" : true).
4. Use the unstable feed.query endpoint to get a list of recent actions by the user to determine recent activity. More properly, we should probably look at recent activity on security-protected or security-tagged tasks, but I think that would be expensive and wonky to do via Conduit.

At least some of these queries will require an API token belonging to a privileged Phabricator user.

I had a weekly MariaDB query to warn about missing 2FA. I also occasionally run DB queries on missing user activity and remove folks from acl projects.
I disabled that query in https://gerrit.wikimedia.org/r/c/operations/puppet/+/1117489 because non-public T304792 has not seen momentum.

I guess I want to express that I could easily set this up (though DB and not Conduit, because easier). But I believe non-public T304792 needs to be solved first.
Furthermore, see T306708: Establish a workflow that scales for requesting Phab 2FA resets which I consider a blocker for T304792 as I'm not keen on spending more time in spontaneous 1:1 video calls to reset 2FAs...

In T391150#10714904, @Aklapper wrote:

because non-public T304792 has not seen momentum.

I feel like the Security-Team, especially given the recent security incident, can justify the enforcement case for T304792. We could do something similar to T237696, where we list affected accounts, sub them, set a time period (week, two weeks, whatever) and then disable accounts which are out of compliance.

And in a perfect world, we could develop some kind of dashboard to both track and automate this and other audits (T254201).

Just making a note pre-emptively about making sure my access for Fandom security release management (and checking for reports in our bug bounty program with HackerOne) is maintained, as my account was caught up in the clean up in last year's one. Though I have MFA and will have commented here so I assume wouldn't be included.

In T391150#10718241, @Grunny wrote:

Just making a note pre-emptively about making sure my access for Fandom security release management (and checking for reports in our bug bounty program with HackerOne) is maintained, as my account was caught up in the clean up in last year's one. Though I have MFA and will have commented here so I assume wouldn't be included.

Any legitimate users with security access who have MFA enabled and/or have recent activity within Phabricator should be fine.

Would it be more effective to have an offboarding workflow where HR/legal informs someone that staff has left and needs to be removed from the WMF-NDA group (unless they signed a volunteer NDA) rather than passively scanning for inactive users in that group?

In T391150#10718459, @Dzahn wrote:

Would it be more effective to have an offboarding workflow where HR/legal informs someone that staff has left and needs to be removed from the WMF-NDA group (unless they signed a volunteer NDA) rather than passively scanning for inactive users in that group?

I think we can have both. Security-Team does this during our own offboarding process. I believe SRE might as well, through theirs? @MoritzMuehlenhoff would likely know the answer to that. There are also a handful of folks who are volunteers who have Phab security access, so WMF departures wouldn't alert on those cases.

I have over 100+ users mostly in WMF-NDA and one in acl*sre-team that does not have 2FA. I will create a private phab task and subscribe 20 users at a time, resulting in around 6 tickets, instead of creating individual tickets or a massive ticket with 100+ subscribers. If there are no objections to this method, I will do this next week.

@Jly: In general yes, though I'd really like to see T306708 sorted out first - it won't scale if there is a drastically increased amount of folks who'll contact me (a single individual) in random places to request resetting their Phabricator 2FA after they lost their second device. Especially when I am on vacation. :P
Please also check (non-public) T305577, and ideally clearly communicate deadlines and consequences so I don't end up with a bunch of folks all complaining to that @Aklapper guy in case their access got removed at some future point. Thanks so much! <3

@Jly has refreshed the previous audit task (see: T305577#10758812). We've already gotten a few responses, which is great. Unfortunately, we'll likely need to verify MFA for users who have added it (as a Phab admin, I can help with that) and reach out to folks who have removed their usernames from the list about why they did so.

In T391150#10751984, @Aklapper wrote:

@Jly: In general yes, though I'd really like to see T306708 sorted out first - it won't scale if there is a drastically increased amount of folks who'll contact me (a single individual) in random places to request resetting their Phabricator 2FA after they lost their second device. Especially when I am on vacation. :P

We'll have to see where this lies priority-wise once the Security Team has a new, permanent manager in place. In the interim, I'm happy to help with 2fa issues as a Phab admin, in whatever way I can. But long-term, I think we'll want to explore adopting something similar to what JLam proposed (T306708#9415882) with more formal roles/responsibilities in place.

Thanks Scott!

Folks, I'd like to propose a cut-off date for this in 3 months, which I will notify in T305577. Users who still have not enabled 2FA will be removed from WMF-NDA. I want to check especially with the Phab admins whether it's doable and agree on the timeline. Ideally, I'd like the timeframe to be shorter, but I want to give sufficient time for all users e.g. for people who are away, etc.

We would need T306708 to be resolved before removing people from WMF-NDA.

In T391150#10763358, @Dzahn wrote:

We would need T306708 to be resolved before removing people from WMF-NDA.

I don't see that as a blocker for removal from WMF-NDA at all. I would doubt that WMF Legal does either.

Alright, so who would handle the requests to be added back?

In T391150#10765844, @Dzahn wrote:

Alright, so who would handle the requests to be added back?

The plan is to give folks ample time (at least a couple of months per @Jly's comment in T391150#10762129) to add Phab 2fa to their affected account(s). Anyone who is removed from WMF-NDA, but is later willing to enable or re-enable Phab 2fa, can submit a Phab task and tag the Security-Team and Trust-and-Safety and we'll manage those in our weekly security clinic. Which solves the workflow problem for this specific task/audit, which is why I don't view T306708 as a blocker at this time.

Gotcha! That sounds good. Thanks @sbassett

In T391150#10718489, @sbassett wrote:

I think we can have both. Security-Team does this during our own offboarding process. I believe SRE might as well, through theirs? @MoritzMuehlenhoff would likely know the answer to that.

Our offboarding process already covers both cases. The process is only documented on Office Wiki: https://office.wikimedia.org/wiki/SRE/Offboarding_from_production

The script which removes access for Phabricator is found here: https://github.com/wikimedia/operations-puppet/blob/production/modules/openldap/files/offboard-user.py#L409

There are also a handful of folks who are volunteers who have Phab security access, so WMF departures wouldn't alert on those cases.

This is also covered by the same process: If access for external folks is removed (e.g. researchers whose projects have ended), the same process is applied as for staff.

In T391150#10767422, @MoritzMuehlenhoff wrote:

Our offboarding process already covers both cases. The process is only documented on Office Wiki: https://office.wikimedia.org/wiki/SRE/Offboarding_from_production

Ok. Looks like that doc was created in 2024? Even if SRE's process has existed for longer than this, it still might not cover everyone who currently has WMF-NDA access, as some of those accounts may have been granted this access several years prior. And I don't think it would ever cover MFA enablement, which is our current concern. Once the current MFA audit (T305577) is complete, I imagine this will be in a much more accurate and manageable state that likely doesn't require routine audits.

This is also covered by the same process: If access for external folks is removed (e.g. researchers whose projects have ended), the same process is applied as for staff.

Sure, but some of these folks are volunteers who may or may not have a current NDA on file with Legal and may not have been temporary employees or granted specific project access by the WMF, e.g. folks in groups like acl*security_volunteer and acl*security_steward. I've typically seen these groups manually audited in the past and am not aware of them feeding into various HR feeds, etc., unless you can confirm otherwise.

acl*security_steward removals are managed by the https://gitlab.wikimedia.org/repos/stewards/onboarding-system script now, and activity is checked through the yearly reconfirmation process. However, the bot does not have access to verify 2FA on Phabricator.