Jenkins 8,793 separates two questions under Manage Jenkins > Security. The security realm answers who are you?: Jenkins' own user database, or through plugins LDAP, Active Directory, SAML, OpenID Connect, GitHub 29 or Microsoft Entra ID. The authorization strategy answers what may you do?: "Anyone can do anything" and "Legacy mode" (never use them), "Logged-in users can do anything", matrix-based strategies (the matrix-auth plugin, 3.3) or roles (role-strategy). The setup wizard of Setup Wizard chose the local database and "Logged-in users can do anything", so every account on this controller was an administrator.
In production, use your company directory (SAML or OpenID Connect), so leavers lose access at once, and keep one local break-glass administrator. Jenkins tells an anonymous client exactly why it was refused, and /whoAmI shows what it knows about you:
J=http://localhost:32080; VIEWER="viewer:$VIEWER_TOKEN"
curl -s -D - -o /dev/null $J/api/json | grep -E '^(HTTP|X-You-Are-Authenticated|X-Required)'
curl -s -u "$VIEWER" $J/whoAmI/api/json | jq -c '{name, authorities}'HTTP/1.1 403 Forbidden
X-You-Are-Authenticated-As: anonymous
X-Required-Permission: hudson.model.Hudson.Read
{"name":"viewer","authorities":["authenticated"]}viewer and developer are test users with API tokens; a directory realm would add its groups to authenticated.