SAML Loop and SCIM Deprovisioning After a UPN Suffix Change
An organization with 8,500 employees uses Workspace ONE Access as its identity broker. Azure AD is the third-party IdP over SAML, and SCIM 2.0 provisions users and groups into Access. After IT changed the primary UPN suffix from corp.local to corp.com, about 400 users began bouncing between Access and Azure AD with a 'We couldn't sign you in' error, and the loop never completes. SCIM deprovisioned 120 of those users within an hour, removing their entitlements. In parallel, 60 shared kiosk accounts in distribution centers cannot authenticate. Kiosks use certificate-based authentication with a certificate whose subject CN is the account's old UPN. Conditional access requires MFA and a compliant device, and kiosks cannot perform interactive MFA. The IdP SAML assertion uses the NameID format 'persistent' and the UPN claim from on-premises AD. Access directory sync still shows the old domain for 90 accounts.
1. Diagnose the SAML loop and the SCIM deprovisioning. What evidence distinguishes an identifier mismatch from a signing or clock problem?
Read the worked answer
SAML loop. Capture a browser SAML trace for one affected user. If the loop is an identifier problem, the AuthnRequest and Response will be valid, signed, and within the time window, but the NameID or UPN claim will not match any Access directory user, so Access sends the user back to Azure AD. A signing or clock problem produces a different error at the assertion validation step, usually a signature validation or NotBefore/NotOnOrAfter failure, not a clean redirect loop.
The persistent NameID format is opaque and does not carry the UPN. If Access is configured to derive the user name from NameID, it cannot resolve users after the UPN change; if it uses the UPN claim, the claim now carries corp.com while 90 Access directory records still show corp.local. Both produce the same loop. Compare the assertion values with the Access user record and the directory sync log for the same user.
SCIM deprovisioning. Check the SCIM audit log for the 120 users. If SCIM matches on userName, the UPN change looks like a new user: the connector creates a new record and deactivates the old one, or a downstream rule removes entitlements from the old record. Verify the connector's matching attribute and whether externalId is populated with an immutable value such as objectGUID. If the log shows updates followed by deactivations, the cause is matching, not authorization.
2. Design an authentication path for the 60 kiosk accounts that satisfies the business need without granting them broad conditional-access exemptions.
Read the worked answer
Kiosks cannot perform interactive MFA, and shared accounts should not be treated like normal users. Separate them from the workforce identity path rather than adding a blanket exclusion.
Recommended design. Authenticate kiosk accounts directly to Access with certificate-based authentication, using an access policy scoped to the kiosk user group and the distribution-center network ranges. Keep those accounts out of the Azure AD SAML federation so they do not trigger the conditional-access MFA requirement. Issue new certificates with the current UPN in the subject and SAN, and map the certificate to the Access account through a stable attribute rather than the CN alone.
Compensating controls. Restrict the kiosk policy to named locations or specific UAG egress addresses; grant only the kiosk application entitlements; set short session timeouts and re-authentication intervals; disable interactive logon for the shared accounts outside the kiosk flow; and log all kiosk authentications to the SIEM with account and device identifiers.
Alternative. If Azure AD certificate-based authentication is available and can satisfy the MFA requirement for these accounts, federate them and use a named-location condition plus a kiosk-specific conditional-access policy. This keeps one identity plane but requires careful scoping so the exemption cannot be reached from user devices.
Do not exempt the kiosk group from conditional access without a network restriction; that converts a kiosk convenience into a bypass for anyone who obtains the shared credential.
3. Sequence the fixes so that users are restored quickly without re-triggering deprovisioning. What would you do first, and what would you delay?
Read the worked answer
First: stop the damage. Pause the SCIM connector or switch it to read-only so no further deprovisioning occurs. Identify the 120 deprovisioned users from the audit log and restore their Access records and entitlements from the most recent known-good export or backup. Do not re-run a full sync until the matching attribute is corrected, or the same deprovisioning will repeat.
Second: fix identifiers. Change the SCIM matching attribute to an immutable value, populate externalId with objectGUID, and align the SAML NameID with the same stable identifier or with a UPN claim that matches Access. Correct the 90 stale directory records and run a scoped sync for a pilot group of ten users before syncing the full 8,500.
Third: user access. For the 400 looping users, verify one pilot user can complete the round trip, then communicate a single reset instruction. Avoid asking users to clear cookies as a permanent fix; that masks the identifier mismatch.
Delay: the kiosk certificate reissue can follow the workforce fix if kiosks have a local fallback. Rushing new certificates while the identity matching is unstable risks issuing certs that map to the wrong records. Schedule kiosk reissue after the pilot sync is clean, and test one distribution center before all sites.