At glance, it seems /r/a/accounts might be a mistake that shoudl be /r/accounts, given the examples and documentation:

https://gerrit.wikimedia.org/r/Documentation/rest-api-accounts.html#set-active

In particular since the simple examples for anonymous read queries such as https://gerrit.wikimedia.org/r/accounts/?q=name:Krinkle work as-is. Upon closer inspection, I understand that /a/ is an optional prefix that puts the API in authenticated mode, where HTTP authentication username/password is accepted. This seems to check out. My personal account doesn't have the rights to enable/disable accounts, but at least the API appears to exist at this address since it yields HTTP 401 and not 404:

$ curl -X PUT 'https://gerrit.wikimedia.org/r/a/accounts/fomafix/active' -i -u 'krinkle:***'
HTTP/1.1 401 Unauthorized

I tried doing the same with the production credentials from wikitech/labweb's private settings, using the dedicated bot account for the purpose (managed by @thcipriani it seems). And this indeed yields an HTTP 404:

$ curl -X PUT 'https://gerrit.wikimedia.org/r/a/accounts/fomafix/active' -i -u '***'
HTTP/1.1 404 Not Found

But, not because the API doesn't exist. Rather the reason is in the body, and it has to do with the input given:

HTTP/1.1 404 Not Found

Account 'fomafix' only matches inactive accounts.
To use an inactive account, retry with one of the following exact account IDs:
 562: Fomafix <fomafix@googlemail.com>

I tried the following:

$ curl PUT /r/a/accounts/fomafix/active
HTTP 404
Account 'fomafix' only matches inactive accounts.

$ curl PUT /r/a/accounts/Fomafix/active
HTTP 404
Account 'Fomafix' only matches inactive accounts.

$ curl PUT /r/a/accounts/fomafix@googlemail.com/active
HTTP 404
Account 'fomafix@googlemail.com' only matches inactive accounts.

$ curl /r/a/accounts/Fomafix+<fomafix@googlemail.com>/active
HTTP 404
Account 'Fomafix <fomafix@googlemail.com>' only matches inactive accounts.

$ curl /r/a/accounts/562:+Fomafix+<fomafix@googlemail.com>/active
HTTP 404
Account '562: Fomafix <fomafix@googlemail.com>' only matches inactive accounts.

$ curl /r/a/accounts/562/active
HTTP/1.1 201 Created
""

So, it appears it currently only works via Gerrit's own account number (which afaik is not known to LDAP).

The wmfGerritSetActive() function is invoked by MediaWiki hooks BlockIPComplete and UnblockUserComplete. The hooks are being passed the MediaWiki username normalized with strtolower.

As Timo found out, is confused by the all lower case id fomafix and hint at using a more specific one:

Account 'fomafix' only matches inactive accounts.
To use an inactive account, retry with one of the following exact account IDs:
562: Fomafix <fomafix@googlemail.com>

It is essentially expecting Fomafix.

I think it is an aftermath of us switching Gerrit LDAP system to use lower case (ldap.localUsernameToLowerCase):

If set, it must be ensured that the local usernames for all existing accounts are converted to lower case, otherwise a user that has a local username that contains upper case characters will not be able to login anymore.
The local usernames for the existing accounts can be converted to lower case by running the server program LocalUsernamesToLowerCase.
Please be aware that the conversion of the local usernames to lower case can’t be undone.
For newly created accounts the local username will be directly stored in lower case.

Which caused a bit of havoc at the time (T197083, T216605 and child tasks, upstream https://bugs.chromium.org/p/gerrit/issues/detail?id=9256 ).

When looking at the All-Users.git repository in refs/meta/external-id, there are two local accounts:

$ git grep -i gerrit:fomafix
07/9fa52b1cb259788fe8c2549b62ae444faaf324:[externalId "gerrit:Fomafix"]
e6/525681d15714c1b8fe6dcfe96d4ade27c9ee9d:[externalId "gerrit:fomafix"]

Accoss all accounts there are 199 with an upper case letter:

$ git grep 'gerrit:.*[A-Z]'|wc -l
199

Which I guess would end up facing a similar problem.

If I remember properly we have to delete the account the local accounts (gerrit: prefixed) which have upper case letters when they have an equivalent in all lower case. Maybe the LocalUsernamesToLowerCase script takes care of that. It says:

The program will automatically remove duplicates where the username differs only in case but all other attributes are identical.

From /a/accounts/Fomafix/external.ids

{
  "identity": "mailto:fomafix@googlemail.com",
  "email_address": "fomafix@googlemail.com",
  "trusted": true,
  "can_delete": true
},
{
  "identity": "username:fomafix",
  "trusted": true
},
{
  "identity": "gerrit:Fomafix",
  "trusted": true,
  "can_delete": true
},
{
  "identity": "gerrit:fomafix",
  "email_address": "fomafix@googlemail.com",
  "trusted": true,
  "can_delete": true
}

My understanding is gerrit:Fomafix should be deleted.

We should had all accounts fixed via T216605 which used the following script:

It finds any local username (gerrit:XXX) which have an upper case letter and convert it to all lower case IF there is not an existing lower case user already. The script should be adjusted to support deleting the dupe mixed case account.

Looking at my own account, via https://gerrit.wikimedia.org/r/settings/#Identities I see gerrit:marcoaurelio the only identity (including other emails I have used for patch attribution). Since this (WikitechGerritBan) is still erroring, is there any unresolved issues that need to be addressed before fixing this Task?