Skip to main content

JUpdate

 Status Update:

Root cause identified. Grafana SSO login fails with "User sync failed" after Keycloak authentication succeeds.

Keycloak authenticates the user correctly. Grafana then fails when creating its own local copy of that user. Grafana logs confirm this:

logger=user.sync level=error msg="Failed to create user" error="user not found" auth_module=oauth_generic_oauth
logger=authn.service level=error msg="Failed to run post auth hook" error="[user.sync.internal] unable to create user: user not found"

The cause is duplicate email addresses. All users sourced from the GTAC LDAP provider share a single email address. Keycloak permits duplicate emails; Grafana requires every user to have a unique one. The first account created claims that email, and every subsequent user collides with it and is rejected.

Two secondary config issues were also found in grafana.ini:

  • login_attribute_path = username does not match Keycloak's standard claim (preferred_username), so Grafana was falling back to email as the username as well.
  • login_maximum_lifetime_duration = 1m forces re-authentication after 1 minute (lowercase m = minutes). Confirming whether this was intentional.

We do not have access to the GTAC LDAP provider, so the fix is scoped entirely to Keycloak and Grafana. No LDAP changes are required.

Suggested Fix (summary):

  1. Remove the email claim from the Keycloak grafana client only, by changing the email client scope from Default to Optional. No other application and no user record is affected.
  2. Configure Grafana to derive a unique email per user from the username via email_attribute_path = join('', [preferred_username, '@grafana.local']). This value exists only in Grafana's internal user table. The real LDAP/Keycloak email is unchanged.
  3. Correct login_attribute_path, name_attribute_path, and role_attribute_path to match the actual Keycloak claims.
  4. Update existing Grafana accounts holding the shared email so they no longer block new SSO account creation.
  5. Once verified, disable the local login form and enable auto-login for SSO-only access.

Rejected alternatives: disabling Keycloak's Duplicate Emails realm setting (risks breaking the LDAP sync) and oauth_allow_insecure_email_lookup (could log different users into the same Grafana account).

Next Steps:

  1. Validate that preferred_username is unique per user using the Keycloak client Evaluate tab. This is a gating check; the fix depends on it. — Owner: [name], ETA: [date]
  2. Back up grafana.ini and grafana.db.
  3. Apply the Keycloak client scope change and the grafana.ini updates in the test environment.
  4. Clean up the existing Grafana accounts using the shared email.
  5. Restart Grafana and validate with two separate SSO users in isolated browser sessions.
  6. On successful validation, enable SSO-only login and confirm an SSO user holds the Grafana Admin role before disabling the local login form.
  7. Schedule the production change window once test results are confirmed.

Comments

Popular posts from this blog

Joke of Day

Home / Blog / 35 Cybersecurity Jokes to Make Any Security Geek Chuckle (or Groan) 35 Cybersecurity Jokes to Make Any SecurityGeek Chuckle (or Groan) Posted on September 8, 2020 Last updated on December 13, 2024. Good IT jokes are few and far between, especially when it comes to cybersecurity. That’s why we put on our creativityhats to brainstorm joke after joke – with a break to pull in a few of our favorites from the web – for the ultimate result: themotherlode (or should we say mother board ?) of cybersecurity jokes and puns. P.S.: we side with Alfred Hitchcock on thisone: puns are the highest form of literature. Everyone deserves an eye-catching intro to break the ice at the start of a meeting or spice up a PowerPoint – gotta keepthe CEO’s attention somehow! And no joke is complete without the perfect graphic. Feel free to grab ours and includethem in your next newsletter, quarterly presentation, or for a workday pick-me-up. Without further ado, we present… Our Favorite Cybersecurit...

Jira 6

  BRIEF Look at open-source AI security tools we can run safely on secdesk01, and decide whether any are worth adopting. DESCRIPTION Our scanners only catch what they have a pattern for. That means noise we have to sift through, and logic flaws they miss entirely. AI tools can reason about what they're seeing instead of just pattern-matching. This ticket is about finding out whether that helps us — using open-source tools we run ourselves, so our code and findings never leave our environment. Two things to investigate, both run sandboxed against Juice Shop on secdesk01: 1. Offensive — AI agents that test like a person would. They drive a terminal or browser, chain steps together, and find flaws that need context to spot. Because they send real attack traffic, they must be locked in with no route off the VM. Tools to look at: PentAGI, Strix, PentestGPT, Nebula, CAI. 2. Guardrails — the fencing that makes the above safe. Limits on what an agent is allowed to touch, blocking o...