Nested Contractor Groups and a Kiosk Session Bypass
A healthcare provider runs one Okta org with 22,000 employees and 4,500 contractors. Contractors live in a separate AD domain and sign in to the same Okta org. The org uses Identity Engine. The global session policy has a catch-all rule with a 12-hour session and no MFA; a higher-priority rule requires MFA for the Corporate network zone. The EHR application’s sign-on policy has three rules in this order: (1) Corporate zone, require MFA; (2) group Contractors-All, require MFA; (3) catch-all, allow. The Contractors-All Okta group has 12 direct members, but the 4,500 contractors are members through nested AD groups. Contractors report that after signing in at a corporate kiosk they can access the EHR from home without MFA; logs show the same Okta session is reused. Security wants MFA for all EHR access, an 8-hour maximum session for office users, and a 1-hour maximum for contractors.
1. Why does the Contractors-All rule fail, and why do contractors bypass EHR MFA after using a corporate kiosk?
Read the worked answer
The rule fails because Okta policy group conditions do not reliably expand AD nested groups unless nested-group import has been enabled and flattened into direct membership. Contractors-All has only 12 direct members, so 4,488 contractors never match rule 2. They fall through to rule 3, which allows access without MFA. The corporate-zone rule also does not save them once they are off the corporate network.
The kiosk detail explains the session reuse. The global session policy creates a 12-hour Okta session with no MFA. When the contractor later opens the EHR from home, Okta may see a valid IdP session and the app may reuse its own session cookie, so the user is not forced through a fresh authentication. The app policy’s catch-all allow rule does not require MFA even if the session is old.
The fix is not simply moving rule 2 higher. First make the group membership correct: enable nested-group import or create an Okta group rule that assigns all contractors by an AD attribute such as department or employeeType. Then verify membership with the group’s member count and a test user. Finally, change the EHR policy so the fall-through is a deny or a require-MFA rule, not allow.
2. Redesign the global session and EHR app sign-on policies to meet the MFA and session requirements. Specify rule order and the settings that matter.
Read the worked answer
Global session policy: put contractor rules above office rules. For the flattened Contractors group, set a maximum session of 1 hour and a short idle timeout, and require MFA at session establishment. For the office users group, set an 8-hour maximum session. Keep a catch-all that is restrictive, not permissive. Because contractors use shared kiosks, disable persistent sessions for that group where the product setting allows it, and document that users must sign out at the kiosk.
EHR app sign-on policy: rule 1, Contractors group, require MFA with frequency set to every sign-in, not once per session; set an idle timeout of 15 minutes. Rule 2, Everyone, require MFA every sign-in. Rule 3, catch-all, deny. Putting the contractor rule first ensures the stricter rule wins if a user is in both groups. Requiring MFA at the app layer prevents a long-lived IdP session from being reused for EHR access.
Finally, verify the global session policy does not undermine the app policy. If the global session policy allows a 12-hour session for everyone, the app policy still needs to force MFA every sign-in. Test with a contractor who signs in at the kiosk, closes the browser, and then tries the EHR from an external network.
3. How would you test and monitor the corrected policies so this bypass does not recur?
Read the worked answer
Build a small test matrix: one direct contractor, one nested-only contractor, one office employee, and one user in both groups. For each, test from the corporate zone and from an external network, with a fresh browser and with a reused session. Check the System Log for the policy evaluation event and confirm which rule matched. Do not accept a successful login as proof; the log must show the intended rule.
Use the group membership API or the admin console to confirm the Contractors group contains all 4,500 users, not 12. If you use a group rule, run its evaluation and inspect the membership count before changing the policy. Add a recurring check that alerts if the contractor group membership drops below an expected threshold.
For monitoring, stream System Log events to the SIEM and alert on EHR access without an MFA event, on policy evaluations that match the catch-all, and on contractor sign-ins with sessions older than 1 hour. Review these alerts weekly for the first month. Also add a change-control step: any policy change to the EHR app must include a test user from each group and a screenshot of the matched rule, not just a configuration export.