Before reporting an issue

[x] I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

admin/ui

Describe the bug

When using Fine-Grained Admin Permissions, a user who has only the Users:view and Users:reset-password scopes can successfully reset another user’s password in the Admin Console, but a red toast appears: “Error resetting password: HTTP 403 Forbidden.” The password has been changed; the 403 is produced by a secondary request the console makes to update the credential’s user label, which requires Users:manage.

Relevant server log excerpt (note the failing endpoint and permission check):

jakarta.ws.rs.ForbiddenException: HTTP 403 Forbidden

at org.keycloak.services.resources.admin.fgap.UserPermissionsV2.requireManage(UserPermissionsV2.java:109)
at org.keycloak.services.resources.admin.UserResource.setCredentialUserLabel(UserResource.java:895)

This causes a misleading error message for least-privileged operators whose intent is only to reset passwords.

Version

26.4.0

Regression

[x] The issue is a regression

Expected behavior

No error toast after a successful password reset when the caller has Users:reset-password.

Actual behavior

• Password reset succeeds.
• UI shows a red toast: “Error resetting password: HTTP 403 Forbidden.”
• Server stack trace points to UserResource.setCredentialUserLabel(...) failing with UserPermissionsV2.requireManage(...).

How to Reproduce?

1. Create a realm role (name arbitrary).
2. Map realm-management → query-users to that role (so the Users page is accessible).
3. Enable Fine-Grained Admin Permissions for the realm.
4. Create FGAP Permissions for Resource: Users:
5. Permission A: Scope = view + reset-password, Policy = Role (the realm role from step 1).
6. Assign that realm role to a test operator and log into the Admin Console as that user.
7. Open a user → Credentials → click Reset password and set a new password.

Observation:

• The password changes (refresh confirms it).
• A red toast appears with HTTP 403.
• Network tab / logs show the reset call succeeds (200/204), followed by a call to setCredentialUserLabel that returns 403.

Anything else?

Workaround: Grant Users:manage (broader than desired, not ideal for least-privilege).