Active Directory Group Move Removes Auditor Role from 180 Users
Your company uses Guardium v11.2 with LDAP authentication against Active Directory. The AD group CN=Guardium Auditors,OU=Security,DC=corp,DC=example is mapped to the Guardium role Auditor. About 180 users rely on this mapping; 12 users also have a local Auditor role assigned manually. The AD team renames the group to CN=GRD-Auditors and moves it to OU=Compliance,OU=Security,DC=corp,DC=example. After the change, users can authenticate with their AD password but the report menu is missing for most of them. The Guardium LDAP configuration still points to the old group base DN. A few users with manual roles still see reports. The identity team plans to move to SAML SSO next quarter. Explain how to restore access without assigning 180 individual roles, and what to change now to avoid a repeat during the SSO cutover.
1. What is the root cause, and which Guardium objects need updating?
Read the worked answer
Root cause is a DN mismatch. The AD group's distinguished name changed, but Guardium still maps the old DN to the Auditor role and may still search under the old group base. Update the LDAP group-to-role mapping to CN=GRD-Auditors,OU=Compliance,OU=Security,DC=corp,DC=example; update the group base DN/search filter if the new OU is outside the old search scope; then resynchronize and have users re-login. Do not assign 180 manual roles. Keep the 12 manual roles temporarily as a bridge, but plan to remove them after the group mapping is proven, to avoid orphaned access.
2. How would you validate the fix for a sample of users and avoid lockout?
Read the worked answer
Use a pilot user who is a member of the new group and has no manual role. Run an LDAP search from the Guardium host or an LDAP browser to confirm the new DN and membership; use Guardium's LDAP test connection; then log in as the pilot and verify report access. Check a user who is not in the group to confirm no unintended access. Keep a local break-glass admin. After the pilot, resynchronize and sample 5-10 users across OUs. Review the audit log for login and role changes.
3. What should be done before SAML SSO so role mapping does not depend on the LDAP DN?
Read the worked answer
Before SAML SSO, define which IdP attribute carries group membership (for example, a groups or memberOf claim), map those values to Guardium roles, and test in a staging tenant with pilot users. Do not make the SAML assertion depend on the old LDAP DN. Document the mapping and keep a fallback local admin. Ensure the IdP sends the attribute on every assertion and that Guardium role mapping is based on the claim, not on a directory lookup that could be removed.