I suspect most of the code can be used verbatim (ideally some refactoring to reduce duplication, some common class, that probably still lives in wmf-config, but whatever).

Really, the only part that probably needs updating is this, as we don't want to do an ldapname look up (I'd guess):

		$username = $block->getTargetName();
		$resp = wmfPhabClient( $wmgPhabricatorApiToken, 'user.ldapquery', [
			'ldapnames' => [ $username ],
			'offset' => 0,
			'limit' => 1,
		] );

Yeah. And a check to only process users that have a mediawikiwiki should deal with most performance concerns I have.

Is there a suitable hook in CentralAuth already?

https://phabricator.wikimedia.org/conduit/method/user.mediawikiquery/ is the API to call with a SUL account username.

T222209: Cleanup logging and curl use in wikitech post-block hooks could also be addressed when implementing this. Code could be extracted from https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/wikitech.php and moved to a file that can be used from more than just wikitech.

In T338384#8911697, @taavi wrote:

Is there a suitable hook in CentralAuth already?

Doesn't seem so.

But then if there is a risk of abuse of technical spaces, wouldn't you want to block the user on wikitech (which does log them out from Phabricator) anyway?

In T338384#9226941, @Tgr wrote:

wouldn't you want to block the user on wikitech (which does log them out from Phabricator) anyway?

If an LDAP/wikitech account was linked to the Phabricator account that would probably make sense; most of the time there is not (but only a SUL account).

Note:

• After T17294: Allow globally blocking of accounts we should also handle global account blocks
• Remove a user's session without disabling the account is not enough since user can log in Phabricator via https://phabricator.wikimedia.org/login/email/ even if the SUL account is globally locked

Update:

• Unlike disabling LDAP accounts and global locks (which Tgr suggest to completely migrate to global blocks), local and global blocks can be time-limited and MediaWiki currently does not provide ways to notify block expiration. In addition if account is to be reenabled once block expired, we should make sure not to reenable accounts disabled before such blocks, otherwise any MediaWiki admins (if we disable account based on MediaWiki.org block, currently we does not) can reenable a WMF banned user.

If this "disables" the phab account, will a new story of "CentralAuth unlocks should enable linked Phabricator account" be also addressed?

If anyone wanted to write custom code to query global locks on connected SUL accounts before UPDATEing a Phab user's sessionKey, per past discussions in https://secure.phabricator.com/T4806 that should likely go into loadUserForSession() in https://phabricator.wikimedia.org/source/phabricator/browse/wmf%252Fstable/src/applications/auth/engine/PhabricatorAuthSessionEngine.php

aklapper opened https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/merge_requests/87

Log out Phab user when their SUL account is globally locked

Note we should also consider unlocks - e.g. Last week WMF locked more than 30k compromised account. Imagine we also disabled the linked Phabricator account, and later someone is unlocked, they will be confused that their Phabricator account is still disabled.

Right, I was thinking of only logging out the Phab user (less work for admins because no manual re-enabling) instead of disabling their account (but that is way clearer communication to anyone instead of "why do I always get logged out"). I'm a bit torn.

How often do we remove global locks? Are there any percentages available?

Even if removal of global locks is not often, the issue is most stewards (plus WMFOffice) are not Phabricator admins, so they can not reenable Phabricator accounts. Also, they may not be aware that there are Phabricator account to be reenabled.

Also global blocks for accounts currently exists and is planned to completely replace global locks (T373388). Unlike global locks, global blocks can be temporary.

There is no way to store why a Phab account got disabled so there is not much sense in adding code to check at Phab login if a SUL account is locked or not.

But at least it is known who is disabling the Phabricator account (example), and thus we can exclude accounts disabled by an admin (including PhabBanBot).

Note that our Antivandalism code does not leave an entry that it disabled a Phabricator account (patches welcome to change that behavior).

In T338384#10712366, @Aklapper wrote:

Note that our Antivandalism code does not leave an entry that it disabled a Phabricator account (patches welcome to change that behavior).

Actually https://gerrit.wikimedia.org/r/plugins/gitiles/phabricator/antivandalism/+/refs/heads/wmf/stable/src/herald/AntiVandalismAction.php#420 added a log with a very specific story type (AntiVandalismFeedStory), and we probably can query this. This is different from those accounts disabled by admins.

Oh true, it is listed in the "global" feed but not in the per-user page feed.

IIRC Tyler mentioned that Bitu can block Gerrit accounts; check maybe there's something similar for Phab accounts too?

In T338384#11019978, @Aklapper wrote:

IIRC Tyler mentioned that Bitu can block Gerrit accounts; check maybe there's something similar for Phab accounts too?

Bitu current supports blocking/disabling Gerrit, GitLab, and Phabricator accounts that are linked to a Developer account when it is disabled. This was the old Wikitech blocking ported to Bitu when Wikitech was separated from Developer accounts in October 2024. https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/bitu/+/refs/heads/master/src/bitu/wikimedia/jobs.py#99