Cisco 300-715 SISE common mistakes
Cisco 300-715 SISE · Understand the traps and how to avoid them.
Treating the identity store order in an identity sequence as a priority ranking and expecting ISE to fall through to the next store when the first store answers with an explicit reject.
Candidates conflate 'store is unreachable' with 'store rejected the user'. ISE only advances through an identity sequence when a store is unavailable or returns no result; a definitive reject from an active store ends authentication, and the order in the sequence is the order of evaluation, not a preference list.
What to do instead
Memorise the distinction between 'store not reachable' and 'user not found / wrong password'. Build a mental test matrix: store down, store up but unknown user, store up but bad password, and predict the outcome for each position in the sequence. Remember that advanced options such as 'if user not found continue' change the behaviour deliberately and must be verified against the actual sequence configuration.
Assuming Active Directory group membership is evaluated from a cached copy or from the directory the user authenticated against, rather than from the join point and group mapping actually configured.
Candidates learn 'AD groups become ISE identity groups' as a slogan and never trace the path: join point, directory groups, then the identity group mapping or the AD group condition used in the policy set. When a policy does not fire, they blame the rule instead of the missing join or the unmapped group.
What to do instead
Trace the whole chain explicitly for one user: which join point serves the domain, whether the group is included in the selected groups, and which identity group or AD group condition the rule references. Practise writing the authorisation condition both ways (ISE identity group versus AD group attribute) and know which one survives a change of domain.
Building a policy set that matches only on the identity group and forgetting that the same identity group exists in more than one policy set, then expecting the first policy set to win because it appears higher in the list.
Policy sets are evaluated top down and the first set whose conditions all match is used; nested rules inside that set are then evaluated top down. Candidates read the list as a menu and assume the most specific set is chosen automatically, so overlapping conditions silently route traffic to the wrong set.
What to do instead
Before writing rules, sketch the policy set conditions on paper and identify which sets can match the same session. Use distinct conditions (device type, protocol, SSID, location) to make sets mutually exclusive, and test with the policy set evaluation order in mind. When debugging, confirm which policy set matched before examining the rules inside it.
Treating profiler policies as if a single matching policy assigns the endpoint profile, and expecting a high-confidence profile to appear immediately after the first probe.
Profiling is a scoring exercise: multiple conditions across multiple policies contribute certainty values, and the endpoint is assigned to the profile with the highest total score once the minimum certainty is met. Candidates test with one probe, see no profile, and conclude profiling is broken.
What to do instead
Learn the model as 'conditions add certainty, profiles compete, highest score wins'. When a profile does not appear, list which probes the endpoint actually sends and whether the corresponding conditions are enabled. Verify with the endpoint's profiling history rather than guessing, and remember that a change of profile can trigger a CoA that re-runs authorisation.
Configuring an authorisation result that pushes a downloadable ACL or VLAN but forgetting that the change only takes effect on reauthorisation, then reporting that the policy 'did not apply'.
The initial authorisation happens once at session start. Changing a policy, a profile, or a group does not retroactively alter an existing session unless a CoA is issued. Candidates test by editing the rule while the endpoint is connected and see no change.
What to do instead
Always reconnect the endpoint or issue a manual CoA from the endpoint's session details after changing an authorisation result. Know which events trigger automatic reauthorisation (profiling change, posture change, some group changes) and which do not. When troubleshooting, check the session's authorisation timestamp before assuming the policy is wrong.
Mixing up the roles of the client provisioning portal, the guest portal, the sponsored guest portal, and the BYOD portal, and assigning the wrong portal to the wrong use case in a scenario question.
All four are 'web portals' with similar configuration pages, so candidates memorise names rather than the flow each one performs: self-registration for guests, sponsor-created accounts, device registration and certificate enrolment for employees, and supplicant/agent provisioning for wired or wireless onboarding.
What to do instead
For each portal, write one sentence describing who authenticates, what identity store is used, and what the endpoint receives at the end (network access, a guest account, or a certificate). Then map common scenario phrases such as 'visitor sponsored by reception' or 'employee registers a personal phone' to the correct portal before reading the answer options.
Assuming a guest user who successfully logs into the guest portal is automatically authorised for the guest VLAN, without checking that the portal's login successful page and the authorisation policy are linked.
Portal authentication and network authorisation are separate steps. The portal sets a session attribute and redirects; the authorisation policy must then match on the guest state or endpoint identity group to return the guest result. Candidates stop at 'login worked'.
What to do instead
Trace the post-login path: which endpoint identity group the guest is placed in, which authorisation rule matches that group, and what result it returns. Practise reading a guest flow end to end, including the redirect ACL and the pre-login versus post-login authorisation results.
Confusing the Security Group Tag with the Security Group ACL, and expecting an SGACL to be enforced on a device that only supports SGT imposition.
TrustSec separates classification (assigning an SGT), transport (SGT Exchange Protocol or inline tagging), and enforcement (SGACL download and enforcement). Candidates treat 'TrustSec is enabled' as a single switch and cannot explain why traffic is tagged but not filtered.
What to do instead
Learn the three planes separately and ask, for any scenario, which plane is missing: is the SGT assigned, is it carried to the enforcement device, and is an SGACL bound to the source-destination pair? Remember that enforcement requires a device with SGACL capability, and that the default SGACL behaviour (permit or deny) matters when no rule matches.
Configuring TACACS+ command authorisation sets but forgetting that the device must be told to use them, or expecting a shell/exec authorisation to cover configuration-mode commands.
TACACS+ authorisation is requested per command set, and the network device decides which authorisation type to request. Candidates configure the ISE side fully and never check the device's AAA authorisation commands, so every command is permitted by default or all commands are denied.
What to do instead
For each scenario, verify both halves: the device sends authorisation requests for exec and for commands, and ISE returns the intended command set. Know the difference between a permit-all default and a deny default on the device, and test with a read-only account and a full-access account to confirm the sets behave as designed.
Deploying a second node or a new policy service without checking certificate trust, NTP, and DNS across nodes, then diagnosing the resulting failures as policy bugs.
Node registration, portal HTTPS, and secure communication between services depend on synchronised time and trusted certificates. Candidates focus on the feature they are testing and skip the deployment prerequisites, so symptoms appear in unrelated places such as portal redirects or replication.
What to do instead
Before any integration test, run a short baseline checklist: time synchronisation on every node, DNS resolution in both directions, and certificate trust for the admin, portal, and any pxGrid or MDM connection. When a symptom looks like a policy problem, confirm the baseline first, then narrow to the feature.