This is about a problem between the Role-based Authorization Strategy plugin when used with the Microsoft Entra ID (previously Azure AD) plugin.

I think the problem is on the RBAS side, but I'm not sure of that.

We are using the Microsoft Entra ID (previously Azure AD) plugin as our security realm, and we do NOT use groups - the AAD plugin "Disable graph integration" is selected (this is because of the way our organisation uses AAD, and is not something that I can change).

The Role-base plugin release 657.v398b_8a_279c49 (Jul 7, 2023) included https://github.com/jenkinsci/role-strategy-plugin/pull/230 (for JENKINS-68755), which added support for explicit assignment of permissions to users and groups, rather than to whatever matches the name.

After updating, we see (as expected) a Jenkins administrative monitor that says:
"There are several permissions declared in Role Based Strategy plugin configuration, that are ambiguous. Classify them correctly with 'USER:username' or 'GROUP:groupname'."

Users can continue log in and work as normal, but if I update the Role Based Strategy plugin configuration to grant permissions to USER:First.Last@example.com rather than First.Last@example.com as previously, then the user loses all access. An attempt to log in is rejected with the message
Access Denied 123456dd-f2ad-123e-1234-123456789abc is missing the Overall/Read permission

The basic problem area is easy enough to understand. For Azure Active Directory, users log in with their email, but AAD refers to them by a cryptic Object ID. RBAS is possibly conflating the two.

Here's what the user's record in Jenkins looks like, as seen at https://jenkins.example.com/user/123456dd-f2ad-123e-1234-123456789abc/

Azure Active Directory
User Unique Principal Name: First.Last@example.com
Email: First.Last@example.com
Object ID: 123456dd-f2ad-123e-1234-123456789abc
Tenant ID: xxxxxxxx-yyyy-zzzz-aaaa-bbbbbbbbbbbb
Jenkins User ID: 123456dd-f2ad-123e-1234-123456789abc

And that user at https://jenkins.example.com/whoAmI/

Name:	123456dd-f2ad-123e-1234-123456789abc
IsAuthenticated?:	true
Authorities:	

    "authenticated"
    "123456dd-f2ad-123e-1234-123456789abc"
    "First.Last@example.com"

Note that previously, when we set up users' RBAS permissions in Jenkins, we granted permissions based on the User Unique Principal Name (email). That doesn't work if you prefix it with USER:.
Is the solution as simple as looking at all authorities for the user, not just the Name?

This looks related to the problem reported in JENKINS-72423, and seems to match this comment by mawinter69:

I suspect that the userid you enter in rbac is actually not what Jenkins internally uses. I know this from Azure AD, where you log on with e.g. an email, but the actual userid you need to add in rbac is something different (a cryptic uid).
...
This page shows the actual Jenkins userid and the groups, the user is a member of. You need to use this userid in rbac.

The drawback with that (not tested by me) workaround is that the page showing who has been assigned what role would become a list of meaningless strings rather than understandable emails.

Is it possible to allow "USER:email" as an identifier for RBAS?

We have been here before - back in Feb 2022, we had a similar breakage, where user emails were not accepted as identifiers by RBAS. In that case, the fix was on the Azure plugin side - there's a very good discussion and explanation at https://github.com/jenkinsci/azure-ad-plugin/issues/190. That should be the starting point for anyone looking at this.

Sorry I don't know enough about the code (and am not a Java programmer) to suggest a PR, but I'm happy to provide more information, or run a debug build of the plugin.