Design solutions for identity and access management

Dunbar Shipping runs a single AD DS forest with 12 domain controllers. A red team report shows that members of Domain Admins routinely sign in to ordinary user workstations and file servers to troubleshoot, leaving reusable credentials in memory that the red team harvested for a pass-the-hash attack. The architect must specify a hardening requirement that prevents Tier 0 credentials from being exposed on lower-tier systems in the first place, rather than merely detecting the exposure.

What should you recommend?

1. AAdd Tier 0 accounts to the Protected Users security group and enforce authentication policy silos that allow those accounts to authenticate only to domain controllers and designated Tier 0 hostsProtected Users prevents NTLM, cached credentials, and weak Kerberos encryption for its members, and authentication policy silos restrict where the accounts can obtain tickets, so a Tier 0 credential cannot be used on a user workstation at all.
2. BDeploy Windows LAPS to all workstations and file serversWindows LAPS randomizes local administrator passwords, which stops lateral movement with a shared local account; it does nothing about domain administrators signing in to lower-tier systems.
3. CInstall Microsoft Defender for Identity sensors on all domain controllers to alert on pass-the-hash activityDefender for Identity detects credential theft and lateral movement, but the requirement is to prevent the exposure; detection is a complementary control, not the hardening measure asked for.
4. DRequire smart card logon for every user in the forestUniversal smart card enforcement is a large program that still leaves a Tier 0 logon on a workstation exposing a reusable credential, and it targets the wrong population; the scenario is about administrators on lower-tier hosts.

Northgate Bank onboards 400 contractors each quarter through staffing agencies. Regulators require the bank to verify, before granting network access, that each contractor has passed a background check performed by the agency. The bank wants a verification that is cryptographically signed by the agency, is presented by the contractor from a wallet they control, reveals only the background-check status rather than the full report, and can be revoked by the agency. The bank wants to avoid storing copies of agency records.

What should you recommend?

1. AHave each agency email a signed PDF of the background report, which HR stores in SharePoint before creating the contractor accountA PDF exposes the full report, cannot be revoked once sent, and requires the bank to store agency records, contradicting the data minimization requirement.
2. BAsk each agency to issue a Microsoft Entra Verified ID credential attesting the background-check status, and require contractors to present it during onboarding before their account is enabledVerified ID credentials are issued and signed by the agency, held in the contractor's wallet, selectively disclose only the attested claim, and can be revoked by the issuer, which maps directly to every requirement.
3. CInvite the contractors as B2B guests from the agencies' tenants and rely on the agency to only invite cleared staffB2B establishes who the user is at the agency but carries no verifiable claim about background-check status; the bank would be trusting an informal process rather than a signed attestation.
4. DCreate an entitlement management connected organization for each agency and make the background check a question in the access package requestConnected organizations streamline access requests from partners, but a self-asserted answer on a request form is neither cryptographically signed by the agency nor revocable.

You are reviewing the Conditional Access policies at Fenwick Manufacturing against the Zero Trust principle of verify explicitly. The policies are: (1) require MFA for all users on all cloud apps, excluding two emergency access accounts; (2) exclude the entire Sales group from policy 1 when they connect from the corporate office named location; (3) legacy authentication protocols are not blocked. The CISO asks which single change most directly aligns the design with verify explicitly.

What should you recommend?

1. ARemove the two emergency access accounts from the exclusion list so that every identity is coveredExcluding a small number of emergency access accounts is a documented best practice to avoid tenant lockout; those accounts are protected by other controls and monitoring, so this is not the gap.
2. BRemove the office-location exclusion for the Sales group and add a policy that blocks legacy authentication, so every sign-in is authenticated with MFA regardless of network locationTreating the corporate network as trusted substitutes location for identity verification and leaves legacy protocols, which cannot perform MFA, as a bypass; removing both gaps makes every access request verified explicitly on identity and device signals.
3. CAdd the branch offices as additional trusted named locations so more users receive a consistent experienceExpanding location-based trust widens the gap; Zero Trust assumes the network is hostile and does not treat an IP range as proof of identity.
4. DIncrease the sign-in frequency for policy 1 to 90 days to reduce MFA fatigueA longer sign-in frequency reduces prompts but extends the lifetime of a session without re-verification, which moves away from verify explicitly rather than toward it.

Glenmoor Bank is validating its Conditional Access design against the Zero Trust principle of assume breach. Today all users must perform MFA at sign-in, the sign-in frequency is the default rolling 90 days, persistent browser sessions are allowed, and a previous administrator set the Customize continuous access evaluation session control to Disable in the baseline policy. An internal exercise showed that after HR disabled a departing analyst's account, the analyst's open Exchange Online and SharePoint sessions on a personal laptop continued working for nearly an hour. The bank wants near real-time revocation on critical events and tighter sessions on unmanaged devices, without adding MFA prompts for users on compliant corporate devices.

What should you recommend?

1. ARemove the session control that disables continuous access evaluation, and add a Conditional Access policy that applies a one-hour sign-in frequency and disables persistent browser sessions only when the device filter does not match compliant devicesWith continuous access evaluation active, Exchange Online, SharePoint, and Teams revoke tokens near real time on critical events such as account disable or password reset, and a session-control policy filtered to non-compliant devices tightens unmanaged sessions while leaving corporate devices untouched.
2. BKeep continuous access evaluation disabled so that every token refresh forces a full policy re-evaluationContinuous access evaluation is the mechanism that provides near real-time revocation; leaving it disabled means waiting for the access token to expire, which is what caused the hour-long exposure.
3. CSet a 15-minute sign-in frequency for all users and all appsA very short frequency for everyone imposes constant MFA prompts on compliant corporate devices, which the scenario rules out, and still does not revoke sessions on critical events between prompts.
4. DReduce the access token lifetime to 10 minutes with a configurable token lifetime policyAccess token lifetime can still be set as low as ten minutes with a token lifetime policy, but it applies per application rather than per device, increases token traffic for every user including those on compliant devices, and does nothing about persistent browser sessions; Microsoft recommends continuous access evaluation and Conditional Access session controls instead.