SAML Users Authenticate but Cannot See the NC2 Cluster
Contoso uses Microsoft Entra ID SAML for Prism Central 2024.1 and Active Directory LDAP for Prism Element. A single NC2 cluster in eu-west-1 is registered to Prism Central. Sixty users are in four Entra groups: NC2-Admins, NC2-Ops, NC2-ReadOnly, and NC2-AppOwners. Members of NC2-Ops can complete SAML login but land on a page that shows no clusters; the local admin account sees the NC2 cluster normally. The SAML assertion sends group claims in an attribute named groups, while Prism Central role mappings reference memberOf. Entra is configured to emit group object IDs, not display names. NC2-Ops currently has a global Viewer role, and the team expected that to be enough. A security review also asks how the NC2 service should call AWS APIs without giving engineers broad IAM permissions.
1. Diagnose why NC2-Ops users see no clusters and describe the verification steps and fix.
Read the worked answer
The symptom is authorization, not authentication: SAML login succeeds, so the trust and user identity are working, but Prism Central is not applying a role to the user. The most likely cause is a claim mismatch. Prism Central role mappings reference memberOf, while Entra emits groups; even if the attribute name were corrected, the values are group object IDs rather than the display names the mappings may expect. Prism Central must map the exact claim value it receives. Fix by either changing the Entra group claim to emit a value that matches the configured role mapping, or changing the Prism Central role mapping to use the object ID claim and the correct attribute name. Also confirm the users are direct members of the group, because nested groups may not be emitted. Verify with a SAML trace, then test a non-admin login and check effective roles at global and cluster scope. Do not use the local admin account as the workaround.
2. Design a least-privilege role mapping for the four groups and a safe break-glass process.
Read the worked answer
Map roles to job function, not to individual convenience. NC2-Admins should receive a Prism Central administrative role at global scope, but not the built-in Super Admin unless they also manage identity and security. NC2-Ops should receive a cluster-scoped administrative role only on the NC2 cluster, so they can operate VMs and storage without changing global identity or AWS-linked settings. NC2-AppOwners should receive a project-scoped role for their application project, which limits them to their VMs and templates. NC2-ReadOnly should receive a global Viewer role. Keep one local break-glass account with MFA, vaulted credentials, and alerting on login; it should not be a daily account. Review role mappings quarterly and after any Entra group rename, because claim values and object IDs can drift.
3. How should the NC2 service obtain AWS permissions without granting engineers broad IAM rights?
Read the worked answer
Separate the service identity from human identity. NC2 should use a dedicated IAM role or service-linked role trusted by the NC2 service principal, with an external ID if the trust model supports it, and permissions scoped to the actions NC2 needs for EC2 bare-metal instances, networking, CloudFormation, and supporting resources. Engineers should not receive those permissions directly; they should use federated SSO into the NC2 console or a read-only AWS role for troubleshooting. Put a permissions boundary on the service role, deny long-lived access keys, and monitor CloudTrail for changes to the role trust policy. If a deployment fails, grant temporary scoped permissions to the service role, not permanent admin to the team. This preserves least privilege while still allowing NC2 to manage the cluster lifecycle.