A manufacturer keeps 2,000 employee accounts in Active Directory and 80 shared machine accounts only in the ISE internal store, and several legacy user names exist in both stores with Active Directory authoritative. Which identity source arrangement should ISE apply to each session?
Select an answer to reveal the explanation.
Short Explanation
Set an identity source sequence to check Active Directory first, so duplicate usernames match the authoritative account. If you don’t find an account there, ISE can check its internal store—like checking the main directory before a backup list.
Full Explanation
The correct arrangement places Active Directory first because it is authoritative for employee accounts and for legacy names that exist in both stores. ISE should consult its internal store when the requested account is not found in Active Directory, allowing the 80 shared machine accounts to authenticate without creating them in AD. Checking the internal store first is a plausible local-first design, but a matching legacy username could be resolved against the non-authoritative local record, contrary to the stated precedence requirement. Using Active Directory for every session and treating shared machines as MAB endpoints is a common network-access design, but it bypasses the machine accounts that are explicitly maintained in ISE’s internal store; MAB does not authenticate those internal identities. Consulting the internal store only after an AD authentication failure also sounds like a fallback design, but a rejected password is not the same as an account not being found. It can improperly allow a local duplicate identity to be considered after AD has rejected credentials, rather than preserving AD authority. Exam caveat: identity-source sequences commonly proceed to the next source on “user not found,” not on every authentication failure; exact behavior depends on the configured policy and failure handling. Practical check: test a shared machine account and a legacy duplicate username, then verify in ISE authentication details which identity store handled each request and what result triggered any fallback.