Posture Policy Conditions per AD Group in Cisco ISE
Short answer
C Configure a Simple Condition per AD group and reference it under the posture policy's Other Conditions so each group gets distinct compliance checks.
Question
compliant. What must be done to accomplish this task?
Key Takeaways
The question tests ISE posture policy condition types, and the trap is confusing posture "service conditions" (Windows/macOS service checks) with "simple conditions" that can evaluate AD group membership.
In Cisco ISE, a posture policy's Other Conditions can reference a Simple Condition that matches AD group membership, letting each Windows 10 AD group meet a different set of compliance requirements. This page establishes why option C is the correct configuration and why service conditions are the wrong tool.
Common mistake: The most common wrong answer is B: "service conditions" sound like a policy-scoping mechanism, but in ISE Posture a Service Condition checks whether a Windows service or macOS daemon is running — it cannot map an AD group to a posture requirement.
Expert Analysis
Why the Answer Is Correct
In Cisco ISE a posture policy is built from posture requirements plus optional Other Conditions, and the Other Conditions can reference Simple Conditions from the Simple dictionary. Those Simple Conditions can test identity/AD group membership, so creating one Simple Condition per AD group and calling it in the posture policy is exactly what lets each Windows 10 AD group face different compliance checks. This is option C. As Cachaman wrote after lab testing, "You can MAP AD groups to simple conditions", and NikoTomas stated flatly that "Correct is C". Cname explained the key distinction: a Simple Condition "can reference AD group membership and be used under Other Conditions in a Posture Policy." That is the supported ISE design for per-group posture differentiation.
Why the Other Options Are Wrong
Option A treats AD groups as something you put into posture requirements, but posture requirements are the checks themselves (antivirus running, file exists, registry value, etc.) and their remediation actions; they do not select users by AD group. Option B says "create service conditions to map each one", which is the trap: ISE Service Conditions are posture checks for whether a Windows service or macOS daemon is running, not a way to bind an AD group to a posture requirement. Option D moves the grouping into the authorization policy, but authorization policies evaluate posture status and assign authorization profiles; they do not define which posture conditions a given AD group must satisfy. The group-to-condition mapping belongs in the posture policy's Other Conditions, so C remains the only workable answer.
Community Comment Notes
The thread is split, but the reasoning favors C. Cachaman reported lab proof, and NikoTomas declared C correct while dismissing A and B. Cname gave the cleanest technical distinction: Simple Conditions handle AD group membership, while Service Conditions only check whether a service is running. The B voters (YmerG, madcloud, NullNull88, and XBfoundX) seem to latch onto madcloud's phrase "create service conditions" under posture policy, which misuses the term service condition. denverfly's D choice also misplaces the logic, because the authorization policy consumes posture results rather than producing per-AD-group posture conditions.
Exam Strategy
Memorize the ISE condition dictionaries: Simple Conditions can test AD group membership, while Service Conditions test service/daemon state. On exam questions about per-group posture differences, look for a Simple Condition referenced in the posture policy's Other Conditions, not a service condition or an authorization rule.
Frequently Asked Questions
Why is option B's service condition wrong for mapping AD groups to posture requirements?
Where in the posture policy does the AD group Simple Condition get applied?
Discussion 11 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 11
-
YmerG 👍 6 Answered BI would go for B
-
NikoTomas 👍 4Correct is C: "Configure a simple condition for each AD group and use it in the posture policy for each use case." --- NOT correct answers: A: “Change the posture requirements...” = this has nothing to do with AD groups, posture requirements are about conditions (firewall is running, file exists, etc...) and their expected remediation actions. B: “...create service conditions to map each one to its posture requirement” – Service Conditions? – they verifies that Win service or macOS daemon is running. Nothing to do with AD groups. D: “Use the authorization policy within the policy set...” – Authorization policy just uses posture attribute (“is compliant”), which refers to Posture policy as standalone entity, where requirements per AD group can be configured. ebook SISE: “The posture policies determine which requirements are mandatory and for whom” – i. e. NOT Authorization policy.
-
Cachaman 👍 3 Answered CC Just tested this in my lab. You can MAP AD groups to simple conditions. Work Centers / Posture / Policy Elements / Conditions / Dictionary Simple /Simple conditions. Then you call or use the simple condition in the posture policy "Other Conditions". B does not makes sense, beacuse a Service Condition will check windows services not AD groups
-
madcloud 👍 3B is right answer. This is configured under policy ==> posture ==> posture policy. Chose identity groups and under other conditions , create service conditions
-
c67983d 👍 2 Answered CISE Posture Policies allow you to define "Other Conditions", including AD group membership, by referencing Simple Conditions. To make different posture checks per AD group, you: Create a Simple Condition that includes the specific AD group. Then use this in the Posture Policy as an "Other Condition" to bind the AD group to a specific set of posture requirements (e.g., AV, firewall). This is how you apply group-specific compliance rules.
Show 6 more comments
-
XBfoundX 👍 2For me in this case is B, here they are saying that each AD group have to meet different condictions to be compliant. This means that each group must have different condictions for be compliant. Btw you can do the reverse thing, you can create a policy with all the AD groups and then if they are complaint they can get access to the network (but is not reccommaned at all)
-
NullNull88 👍 2B, service conditions
-
ArchyinVa 👍 1 Answered C### Correct Answer C. Configure a simple condition for each AD group and use it in the posture policy for each use case. ### Explanation In Cisco ISE, posture policies dictate what requirements an endpoint must satisfy to be deemed compliant. Understanding how the policy components fit together clarifies why C is the correct implementation: 1. Posture Policy Structure: A Posture Policy rule consists of: Rule Name Identity Groups / Conditions: Where criteria such as user groups, Active Directory groups, or endpoint identity groups are evaluated. Operating System: Target OS (e.g., Windows 10). Compliance Module Requirements: The specific checks (anti-malware, disk encryption, registry keys, services) that must be passed. 2. Differentiating by AD Group: In Cisco ISE, an Active Directory group membership check is created as a Simple Condition (e.g., AD1:ExternalGroups EQUALS domain.local/Users/Finance). By configuring a simple condition for each AD group and adding it to the condition/identity field of separate posture policy rules (use cases), Cisco ISE applies different posture requirements to each group. ### Why Other Options Are Incorrect A is incorrect: Posture requirements define what check to perform on the endpoint (e.g., "CrowdStrike must be running"). Requirements do not evaluate user identity or AD groups; identity is matched at the posture policy rule level. B is incorrect: "Service conditions" in Cisco ISE posture refer to checking whether an underlying Windows/OS daemon or service is running on the client machine. They are not used to map AD user groups to requirements. D is incorrect: Authorization policies evaluate the overall session and assign network permissions (VLAN, dACL, SGT, redirection) based on posture tokens/status (Compliant, Non-Compliant, Unknown). They do not group AD groups directly with posture policies—posture policy matching occurs separately within the ISE Posture engine.
-
denverfly 👍 1 Answered DThe correct answer is: Use the authorization policy within the policy set to group each AD group with their respective posture policy. The authorization policy within the policy set allows you to group different AD groups with their respective posture policies. This means that you can create a single policy set that contains all of your posture policies, and then use the authorization policy to specify which AD groups should be assigned to each posture policy.
-
Cname 👍 1 Answered CThe strongest point is the distinction between Simple Conditions and Service Conditions: • Simple Condition → can reference AD group membership and be used under Other Conditions in a Posture Policy. • Service Condition → checks whether a Windows service/macOS daemon is running or not. It does not mean an ISE “policy service” condition. So B is misleading because of the term service conditions.
-
leostor 👍 1Service Condition is related to the Posture....am I wrong? Service Conditions—A condition that checks if a service is running or not running on the client.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.