Posture Conditions and Requirements

Objective

In this lesson you will configure posture conditions (anti‑malware/anti‑virus, patch management, disk encryption) and assemble those into posture requirements that ISE uses to determine endpoint compliance. You will also prepare the endpoint script locations and verify the posture workflow end‑to‑end. This matters in production because posture enforcement prevents non‑compliant endpoints from accessing sensitive resources — e.g., a laptop with out‑of‑date OS patches or disabled antivirus should be quarantined until remediated.

Real‑world scenario: an enterprise uses posture to make sure contractors and employees have corporate antivirus definitions, the latest critical patches, and full‑disk encryption before allowing access to internal systems. Enforcement is done by ISE posture checks and by redirecting noncompliant clients to a remediation portal.

---

Quick Recap

Refer back to the topology used in Lesson 1 (no new network devices are required for this lesson). This lesson reuses the same ISE Primary and Secondary PSNs and the NAD (network access device/switch) from earlier lessons. We will use the following FQDNs and IP that appear in the lab reference during verification and troubleshooting:

• ISE Primary PSN: ise-p.lab.com (auth/status referenced)
• ISE Secondary PSN: ise-s.lab.com (auth/status referenced)
• Redirection / probe target IP seen in agent logs: 10.52.14.254

No new physical devices are added in this lesson.

---

Device Table

Device	Role	Notes
ise-p.lab.com	ISE Primary PSN	Handles posture script distribution and posture evaluation
ise-s.lab.com	ISE Secondary PSN	Backup PSN for session sharing
NAD (switch)	Network Access Device	Performs web redirect for client provisioning/remediation
Endpoint (Windows/Linux)	Posture Agent host	Receives posture scripts and runs checks

---

Key Concepts (theory + practical)

• Posture Conditions vs Requirements

  • Condition = a single check (e.g., "Is corporate AV present?", "Are critical patches installed?", "Is disk encrypted?").
  • Requirement = a logical grouping of conditions used by the access policy (e.g., "Compliant if AV=pass AND Patch=pass AND DiskEncrypt=pass").
  • Why it matters: grouping condenses multiple checks into a single compliance decision used by access rules.

• Script‑based posture checks and the agent download flow

  • ISE can push scripts to the agent; the client stores them in well‑known locations (examples: %LOCALAPPDATA%\Cisco... on Windows, /opt/cisco/anyconnect/... on Linux).
  • The agent probes PSNs and redirection targets; PSNs reply with posture requirements. In the logs you will see the probe targets and PSN responses (e.g., redirection target 10.52.14.254, auth‑status path /auth/status).

• Script integrity and trust (SHA‑256)

  • Scripts are validated by hash (SHA‑256) so tampered scripts are rejected. When authoring or distributing scripts you must publish/verify the hash.

• HTTP redirection and the NAD role

  • The switch/NAD must permit web redirection for remediation portals. On Cisco switches, enabling only the redirect web functionality while keeping other web services off reduces attack surface (use ip http active-session-modules none).

• Session sharing and troubleshooting

  • Session context is shared across PSNs so posture can be executed by a PSN even if authentication occurred on another node. Use agent logs / DART and NAD show commands to trace which PSN handled the posture request and which session ID was returned.

---

Step-by-step configuration

Step 1: Enable the HTTP redirect helper on the NAD (switch)

What we are doing: Enable the minimum HTTP server functionality on the switch to support web redirection for posture remediation pages and disable extra HTTP modules to reduce attack surface. This allows the NAD to issue HTTP redirect responses that send non‑compliant clients to the Client Provisioning or remediation portal.

configure terminal
 ip http server
 ip http active-session-modules none
end
write memory

What just happened:

• ip http server enables the HTTP server on the switch so it can respond to HTTP-based redirection for web authentication and client provisioning.
• ip http active-session-modules none disables non-essential HTTP modules but keeps the active‑session redirect functionality. This reduces the risk introduced by enabling the HTTP server while preserving the redirect capability required for posture remediation flows.

Real-world note: Many customers are wary of enabling the full HTTP server on NADs; enabling only the redirect module is a common compromise to allow posture redirection while minimizing exposure.

Verify:

show running-config | include ip http
ip http server
ip http active-session-modules none

Expected output explanation: The show running-config filtered output displays the two configuration lines we added. If present, the switch will perform HTTP-based redirections needed for posture remediation.

---

Step 2: Place posture scripts in agent script locations and verify hashes

What we are doing: Create the standard script folders on endpoints (Windows and Linux examples) and copy the posture check scripts there. We then verify the SHA‑256 hash so ISE/PSNs can validate the script integrity. This step matters because posture scripts must exist in trusted locations with expected hashes for the agent to run them.

Windows (PowerShell) example:

# create destination directory (Client localapp data path)
New-Item -ItemType Directory -Force -Path "$env:LOCALAPPDATA\Cisco\Cisco Anyconnect Secure Mobility Client\scripts"

# copy script (example local source)
Copy-Item -Path C:\ise_scripts\check_antivirus.ps1 -Destination "$env:LOCALAPPDATA\Cisco\Cisco Anyconnect Secure Mobility Client\scripts\check_antivirus.ps1"

# show SHA256
Get-FileHash "$env:LOCALAPPDATA\Cisco\Cisco Anyconnect Secure Mobility Client\scripts\check_antivirus.ps1" -Algorithm SHA256

Linux example:

sudo mkdir -p /opt/cisco/anyconnect/iseposture/scripts
sudo cp /home/admin/check_antivirus.sh /opt/cisco/anyconnect/iseposture/scripts/check_antivirus.sh
sha256sum /opt/cisco/anyconnect/iseposture/scripts/check_antivirus.sh

What just happened:

• On Windows we created the agent's script folder under %LOCALAPPDATA% and copied the posture script into that folder. The Get-FileHash command computes the SHA‑256 digest used to confirm script integrity.
• On Linux we created the /opt/cisco/anyconnect/iseposture/scripts folder and copied the script; sha256sum computes the SHA‑256 digest.

Real-world note: Enterprises commonly store approved posture scripts centrally and maintain a signed hash list. If the hash on the endpoint doesn’t match the expected SHA‑256 value configured on the PSN, the script will be rejected.

Verify (example outputs): Windows PowerShell expected output:

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          3f2b9c4e6b5b8a96b2d9f5a2f1e4b3c9d8123456789abcdef0123456789abcdef       C:\Users\alice\AppData\Local\Cisco\Cisco Anyconnect Secure Mobility Client\scripts\check_antivirus.ps1

Linux expected output:

3f2b9c4e6b5b8a96b2d9f5a2f1e4b3c9d8123456789abcdef0123456789abcdef  /opt/cisco/anyconnect/iseposture/scripts/check_antivirus.sh

---

Step 3: Define posture conditions and requirements on ISE (conceptual GUI actions) and verify via PSN auth-status

What we are doing: In the ISE Admin GUI you will create three posture conditions: Anti‑Malware/Anti‑Virus (AM), Patch Management (PM), and Disk Encryption (FW/Hardware attribute). Then you will create a Posture Requirement that requires all three conditions to pass for the endpoint to be marked “Compliant”. This grouping is what the access policy evaluates.

• Typical GUI actions (conceptual; performed in ISE Admin Web UI):
  • Policy > Posture > Posture Conditions: create new condition for Antivirus (type: AM), Patch (type: PM), Disk Encryption (type: Hardware Attributes or disk encryption).
  • Policy > Posture > Posture Requirements: create new requirement named "Corporate‑Baseline" and add the three conditions with logic: must pass all.

Why this matters: Conditions are how ISE codifies what “healthy” means for your network. Requirements let you reuse the same set of conditions across many policy sets.

Real-world note: Use clear, auditable names for conditions (e.g., "AM_CorporateAV_UpToDate") so SOC teams can quickly map remediation actions to posture failures.

Verify (pulling PSN auth status): The agent probes PSNs and PSNs expose auth/status endpoints used during posture. Use a simple HTTP request to the PSN auth status path to view the posture evaluation result (PSN is referenced with the path /auth/status in agent logs).

Linux curl example to check PSN auth/status:

curl -v http://ise-p.lab.com/auth/status

Example expected HTTP response body (complete):

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 235

{
  "sessionId": "0x1A2B3C4D",
  "posture": {
    "requirements": {
      "Corporate-Baseline": "COMPLIANT"
    },
    "conditions": {
      "AM_CorporateAV_UpToDate": "PASSED",
      "PM_CriticalPatches": "PASSED",
      "DiskEncryption_FVE": "PASSED"
    }
  },
  "psn": "ise-p.lab.com"
}

What just happened:

• The curl retrieves the posture evaluation returned by the PSN. The JSON payload shows the named posture requirement and the per‑condition results. Seeing "COMPLIANT" under the requirement confirms that the grouping and evaluation are working as intended.

---

Step 4: Author posture scripts with proper exit codes and verify execution

What we are doing: Posture scripts must return well‑defined exit codes so ISE can interpret results. The agent and PSN expect script exit codes in the 0–255 range; ISE predefined codes are < 0 and user‑defined are > 0 (the reference indicates exit code behavior). We will create a simple script that exits 0 (pass) or 1 (fail), set correct permissions, and run it locally to verify the exit code.

Linux example script creation:

sudo tee /opt/cisco/anyconnect/iseposture/scripts/check_disk_enc.sh > /dev/null <<'EOF'
#!/bin/bash
# simple check: look for /dev/mapper/* (example placeholder)
if mount | grep -q "/dev/mapper"; then
  echo "Disk encryption: detected"
  exit 0
else
  echo "Disk encryption: not detected"
  exit 1
fi
EOF

sudo chmod 755 /opt/cisco/anyconnect/iseposture/scripts/check_disk_enc.sh
/opt/cisco/anyconnect/iseposture/scripts/check_disk_enc.sh
echo "Exit code: $?"

Windows PowerShell example (check_antivirus.ps1) snippet:

# Sample simplistic script: existence of corporate AV registry key (placeholder)
$key = "HKLM:\SOFTWARE\CorporateAV"
if (Test-Path $key) {
  Write-Output "Corporate AV present"
  exit 0
} else {
  Write-Output "Corporate AV not present"
  exit 1
}

What just happened:

• The script checks for a simple indicator (mounted LUKS device or registry key). If the condition is met the script returns 0 (success/passed). If not, it returns 1 (failed). ISE interprets these exit codes when the client runs the script during posture.

Real-world note: Real posture scripts are more sophisticated and must be signed/hashed. Always document script behavior and maintain hashes in a secure repository.

Verify (example output):

Disk encryption: detected
Exit code: 0

On Windows PowerShell when run interactively you would see:

Corporate AV present
# PowerShell process exit code is 0 when the process ends normally with exit 0

---

Step 5: Confirm session handling and use NAD show commands for troubleshooting

What we are doing: Use NAD show commands to confirm the access session was created/updated for the endpoint and to inspect device tracking to map the session to a MAC/IP and to find which PSN handled posture. This is useful when troubleshooting redirect chains or when the agent probes multiple targets.

show access-session

Example expected output (complete minimal sample):

Session ID: 0x1A2B3C4D
Users: alice
Endpoint IP: 10.0.0.10
Endpoint MAC: 00:1A:2B:3C:4D:5E
Authentication: 802.1X
Auth status: ACCESS_ACCEPT
Authorization: POSTURE - COMPLIANT
PSN: 10.52.14.254 (ise-p.lab.com)
Session created: 2024-01-16 02:05:17

Also check device tracking database:

show ip device tracking database

Example expected output:

IP Address      MAC Address         Interface        Last Seen
10.0.0.10       00:1A:2B:3C:4D:5E  GigabitEthernet1/0/24  2024-01-16 02:06:05

What just happened:

• show access-session exposes the session state and shows whether the endpoint was allowed or quarantined by posture. It also identifies the PSN that responded (in this example, 10.52.14.254 / ise-p.lab.com).
• show ip device tracking database corroborates the endpoint's IP/MAC and the switch port where it was seen, which is valuable when matching NAD logs to agent logs.

Real-world note: If the agent DART shows probing to multiple targets (see Step 3 log snippet), use the session ID returned by the PSN to search ISE logs and tie together client and NAD information.

---

Verification Checklist

• Check 1: NAD is configured for redirect — run show running-config | include ip http and expect ip http server and ip http active-session-modules none.
• Check 2: Posture scripts present on the endpoint — verify with sha256sum or Get-FileHash and compare to the trusted hash configured on PSN.
• Check 3: PSN returns posture evaluation — curl http://ise-p.lab.com/auth/status should return JSON showing requirement status (e.g., "Corporate‑Baseline": "COMPLIANT" or "NONCOMPLIANT").
• Check 4: NAD has an access session for the endpoint — show access-session shows session ID and PSN that processed posture (e.g., 10.52.14.254).

---

Common Mistakes

Symptom	Cause	Fix
Client never redirected to remediation portal	ip http server not enabled or NAD blocks HTTP redirects	Enable ip http server and ip http active-session-modules none on the NAD; ensure HTTP traffic is permitted between client and NAD
Script hash mismatch or script rejected by PSN	Incorrect SHA‑256 or script modified after publishing	Recompute SHA‑256 on the script, update PSN configuration with correct hash, publish only verified scripts
Posture shows "Unknown" for a condition	The agent couldn’t download or execute the script (network or permissions issue)	Verify script presence and permissions in agent paths, check PSN and client connectivity, review agent DART logs for download errors
Session appears but PSN shows different results than expected	Client probed different PSN or redirected to wrong target	Use DART/agent logs to examine probe targets (e.g., redirection target 10.52.14.254), search ISE logs for the session ID to find which PSN handled the check

---

Key Takeaways

• Posture is built from conditions (single checks) and requirements (logical groups). Requirements drive the access decision in ISE access policies.
• Scripts used for posture must reside in the agent’s standard script directories and be verified by SHA‑256 hashes to ensure integrity.
• The NAD must support HTTP redirection for remediation flows; enable only the necessary HTTP functionality (ip http active-session-modules none) to reduce exposure.
• Use NAD show commands (show access-session, show ip device tracking database) and PSN auth/status endpoints to correlate agent behavior (DART) with ISE evaluations when troubleshooting.

Tip: Maintain a versioned repository of posture scripts and documented expected exit codes. This reduces false positives and improves traceability during audits.

---

End of Lesson 3 of 6 — next lesson will cover implementing remediation portals and redirect chaining details so endpoints can self‑remediate and rejoin the network automatically.