A payment processor protects card data with ISE. Finance analysts authenticate both over the remote-access VPN and at office desk ports, and only sessions that arrive through the VPN concentrators while the user belongs to the AD group CardOps may receive the restricted authorization profile that opens the card-subnet ACL. Which condition should the administrator build for that authorization rule?

Policy logic in ISE is built from conditions that read attributes out of dictionaries, and an authorization rule fires only when its condition evaluates true for the session. Because the requirement has two independent parts, the user must belong to the CardOps directory group and the session must arrive on a VPN concentrator, the correct design joins both attributes in a single compound condition using an AND, pulling the group from the identity dictionary and the device from the device dictionary. Matching on group membership alone would also match the analyst's desk-port sessions, so office users would receive the card-subnet ACL. Matching only on the concentrator would grant the restrictive profile to anyone who reaches the VPN, including users outside CardOps. Splitting the requirement into two separate rules is the classic compound-condition mistake, because each rule still satisfies only half and both rules hand out the same result, widening access instead of tightening it. One exam caveat: ISE ships a large library of built-in conditions, and a local condition is simply one you compose yourself, so either form works as long as both attributes are evaluated together. A practical check: run the policy simulation tool with a CardOps user on a desk port and confirm the rule does not match.