ISE Posture Style Comparison for Pre and Post 2.2

Introduction

This document describes new functionality which is added in Identity Service Engine (ISE) 2.2. It allows to support a posture flow without any kind of redirection support on either Network Access Device (NAD) or ISE. To understand new functionality better, this document contains detailed comparison between posture flow in pre ISE 2.2 versions and in ISE 2.2.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Posture flow on ISE
• Configuration of posture components on ISE
• Adaptive Security Appliance (ASA) configuration for posture over Virtual Private Networks (VPN)

Components Used

The information in this document is based on these software and hardware versions:

• Cisco ISE version 2.2
• Cisco ASAv with software 9.6(2)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

Posture is a core component of Cisco ISE. Posture as a component can be represented by three main elements:

1. ISE as a policy configuration distribution and decision point. From the administrator perspective on ISE you configure posture policies (what exact conditions should be met to mark device as a corporate compliant), client provisioning policies (what agent software should be installed on what kind of devices) and authorization policies (what kind of permissions should be assigned to, depends upon their posture status).
   
   
2. Network access device as a policy enforcement point. On the NAD side actual authorization restrictions are applied at time of user authentication. ISE as a policy point provides authorization parameters like Downloaded ACL (dACL)/VLAN/Redirect-URL/Redirect Access Control List (ACL).Traditionally, in order for posture to happen, NADs are required to support redirection (to instruct user or agent software which ISE node should be contacted) and Change of Authorization (CoA) to reauthenticate the user after posture status of the endpoint is determined. 
   
   
3. Agent software as point of data collection and interaction with end user. Cisco ISE uses three types of agent software: AnyConnect ISE Posture Module, NAC Agent, Web Agent. Agent receives information about posture requirements from the ISE and provides report to the ISE regarding requirments status.

Note: This document is based on Anyconnect ISE Posture Module which is the only one that supports posture fully without redirection.

When you consider pre ISE 2.2 flow posture relies on NADs not only for user authentication and access restriction but as well for provisioning of information to the agent software about specific ISE node which has to be contacted. Information about ISE node is returned to the agent software as part of redirection process. 

Historically, redirection support either on NAD or on ISE side was a key requirement for posture implementation. In ISE 2.2 requirement to support redirection is eliminated for both initial client provisioning and posture process.

Client provisioning without redirectioin- In ISE 2.2 you can access Client Provisioning Portal (CPP) directly via portal Fully Qualified Domain Name (FQDN). This is similar to the way you access Sponsor Portal or MyDevice Portal.

Posture process without redirection- During agent instalation from CPP portal information about ISE servers is saved on the client side which makes direct communication possible.

Posture Flow Pre ISE 2.2

This is a step by step explanation of the Anyconnect ISE Posture Module flow before ISE 2.2

Figure 1-1

Step 1. Authentication is a first step of the flow, it could be dot1x, MAB or VPN. 

Step 2. ISE needs to select authentication and authorization policy for the user. In posture scenario selected authorization policy has to contain a reference to the posture status, which initially should be either unknown or not applicable. To cover both this cases, condition with posture status unequal compliant can be used.

Selected authorization profile has to contain information about redirection:

• Web Redirection- For the posture case, web redirection type should be specified as client provisioning (posture).
  
  
• ACL- This section needs to contain ACL name which is configured on NAD side. This ACL is used to instruct NAD which traffic should bypass the redirection and which should be actually redirected.
  
  
• DACL- It can be used together with redirect access-list but you should keep in mind that different platforms process DACL and Redirect ACLs in different order.

For example: ASA always process DACL before redirect ACL. At the same time some switch platforms process it in the same way as ASA and other switch platforms process Redirect ACL first, and later check DACL/Interface ACL if traffic should be dropped or allowed.

Note: After you enable web redirection option in the authorization profile, target portal for redirection has to be selected.

Step 3. ISE returns Access-Accept with authorization attributes. Redirect URL in authorization attributes is automatically generated by ISE. It contains those components:

• FQDN of ISE node on which authentication happened. In some cases dynamic FQDN can be overwritten by Authorization profile configuration (Static IP/Host name/FQDN) in Web Redirection section. If static value is used it should point to the same ISE node where authentication was processed. In case of Load Balancer (LB) this FQDN can point to LB VIP but only in case when LB is configured to tie together Radius and SSL connections.
  
  
• Port- The port value is obtained from the target portal configuration.
  
  
• Session ID- This value is taken by ISE from Cisco AV pair audit session id presented in Access-Request. Value itself is dynamically generated by NAD.
  
  
• Portal ID- Identifier of a target portal on ISE side.

Step 4. NAD applies authorization policy to the session. Additionally, if DACL is configured, it's content is requested before authorization policies are applied.

Important considerations:

• All NADs- Device should have locally configured ACL with the same name as the one received in Access-Accept as redirect-acl.
  
  
• Switches- IP address of the client should be presented in the output of show authentication session interface details command to successfully apply redirection and ACLs. Client IP address is learned by IP Device Tracking Feature (IPDT).

Step 5. Client sends DNS request for the FQDN which is entered in the web browser. At this stage DNS traffic should bypass redirection and correct IP address should be returned by DNS server.

Step 6. Client sends TCP SYN to the IP address which is received in DNS reply. Source IP address in the packet is client IP, Destination IP address is an IP of requested resource. Destination port equals 80, except for cases when direct http proxy is configured in client web browser.

Step 7.NAD intercepts client request and prepares SYN-ACK packet with source IP equal to requested resource IP, destination IP equal to client IP, source port equal to 80.

Important considerations:

• NADs should have http server running on the port on which client sends requests. By default it is port 80.
  
  
• If client uses direct http proxy web server, on NAS http server should run on proxy port. This scenario is outside of the scope of this document.
  
  
• In the cases when NAD does not have a local IP address in client subnet SYN-ACK is sent with NAD routing table (Over management interface usually). In this scenario packet is routed over L3 infrastructure and should be routed back towards the client by a L3 upstream device. If L3 device is a stateful firewall, additional exception needs to be given for such asymetric routing.

Step 8. Client finishes TCP three-way handshake by ACK.

Step 9. HTTP GET for the target resource is sent by a client.

Step 10. NAD returns redirect URL to the client with HTTP code 302 (Page moved), on some NADs redirect can be returned inside of HTTP 200 OK message in location header.

Figure 1-2

Step 11. Client sends DNS request for the FQDN from redirect URL. FQDN should be resolvable on DNS server side.

Step 12. SSL connection over port received in redirect URL is established (default 8443). This connection is protected by portal certificate from ISE side. Client Provisioning Portal (CPP) is presented to the user.

Step 13.Before providing download option to the client, ISE has to pick target client provisioning (CP) policy. Operation System (OS) of the client detected from the Browser user-agent, other information required for CPP policy selection are retrieved from authentication session (Like AD/LDAP groups and so one). ISE knows target session from session id presented in redirect URL.

Step 14. Network Setup Assistant (NSA) download link is returned to client. Client downloads the application.

Note: Normally you might see NSA as part of BYOD flow for Windows and Android but as well this application can be used to install Anyconnect or its components from ISE.

Step 15.User runs NSA application.

Step 16. NSA sends first discovery probe - HTTP /auth/discovery to Default gateway. NSA expects redirect-url as a result.

Note: For connections over VPN on MAC OS devices this probe is ignored as MAC OS doesn't have default gateway on VPN adapter.

Step 17.NSA sends second probe if first one fails. Second probe is an HTTP GET /auth/discovery to enroll.cisco.com. This FQDN has to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com needs to be routed through the tunnel.

Step 18. If any of the probes succeed, NSA establishes SSL connection over port 8905 with information obtained from redirect-url. This connection is protected by ISE admin certificate. Inside of this connection NSA downloads Anyconnect.

Important considerations:

• Prior to ISE 2.2 release SSL communication over port 8905 is a requirement for posture.
  
  
• To avoid certificate warning both portal and admin certificates has to be trusted on client side.
  
  
• In multi-interface ISE deployments interfaces other that G0 can be bound to FQDN different from system FQDN (using ip host CLI command). This might cause problems with Subject Name(SN)/Subject Alternative Name (SAN) validation. As client could be redirected to FQDN of interface G1 for example but for 8905 communication certificate with system FQDN is returned which might not match to FQDN in redirect URL. As a solution for this scenario you might consider adding FQDNs of additional interfaces in admin certificate SAN fields, or you can use wildcard in admin certificate.

Figure 1-3

Step 19.Anyconnect ISE posture process is launched.

Anyconnect ISE Posture module starts in any of these situations:

• After installation,
  
  
• After default gateway value change,
  
  
• After system user login event,
  
  
• After system power event.

Step 20. At this stage Anyconnect ISE Posture Module initiates policy server detection. This is accomplished with series or probes that are sent at the same time by Anyconnect ISE Posture module:

• Probe 1 - HTTP get /auth/discovery to default gateway IP. You should remember that MAC OS devices does not have default gateway on VPN adapter. Expected result for the probe is redirect-url.
  
  
• Probe 2 - HTTP GET /auth/discovery to enroll.cisco.com. This FQDN needs to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com has to be routed through the tunnel. Expected result for the probe is redirect-url.
  
  
• Probe 3 - HTTP get /auth/discovery to discovery host. Discovery host value is returned from ISE during installation in AC posture profile. Expected result for the probe is redirect-url.
  
  
• Probe 4 - HTTP GET /auth/status over SSL on port 8905 to previously connected PSN. This request contains information about client IPs and MACs list for session lookup on ISE side. This proble is not presneted during the first posture attempt. Connection is protected by ISE admin certificate. As a result of this probe ISE can return session ID back to the client if node where probe landed is the same node where user has been authenticated.

Note: As a result of this probe, posture can be done successfully even without working redirection under some circumstances. Successful posture without redirection requires that current PSN which authenticated the session should be the same as previous successfully conected PSN. Keep in mind that prior ISE 2.2 succesful posture without redirection is rather exception than a rule.

Next steps describe posture process in case when redirect URL is received (flow marked with letter a) as a result of one of the probes:

Step 21. Anyconnect ISE Posture module establishes connection to the client provisioning portal using URL retrieved during discovery phase. At this stage ISE makes client provisioning policy validation once again using information from authenticated session. 

Step 22.If client provisioning policy is detected, ISE returns redirect to port 8905.

Step 23. Agent establishes connection to ISE over port 8905. During this connection ISE returns URLs for posture profile, compliance module and anyconnect updates. 

Figure 1-4

Step 24.AC ISE Posture module configuration download from ISE.

Step 25.Updates download and installation if required.

Step 26. AC ISE Posture module collects initial information about the system (like OS version, installed security products, their definition version). At this stage AC ISE posture module involves OPSWAT API to collect infromation about security products. Collected data is sent to ISE. As a reply to this request ISE provides posture requirements list. Requirements list is selected as a result of posture policy processing. To match correct policy, ISE uses device OS version (present in request) and session id value to pick other required attributes (AD/LDAP groups). Session ID value is sent by client as well.

Step 27. At this step client involves OPSWAT calls and other mechanism to check posture requirements. Final report with requirements list and their status is sent to ISE. ISE needs to make final decision about the endpoint compliance staus. If endpoint market as non compliant at this step set of remediation actions is returned. For the compliant endpoint ISE writes compliance status into the session and as well put last posture timestamp to the endpoint attributes if Posture Lease is configured. Posture result is sent back to the endpoint. In case when Posture Reassessment (PRA) time for PRA put by ISE into this packet as well.

In non-compliant scenario take those points into account:

• Some remediation actions (like display text message, link remediation, file remediation and others) are executed by posture agent itself. 
  
  
• Other remediation types (like AV. AS, WSUS, SCCM) requires opswat API communication between posture agent and target product. In this scenario posture agent just sends remediation request to product. Remidiation itself is done by security product directly. 

Note: In case when security product has to communicate with external resources (Internal/External Update servers) you need to ensure that this communication is allowed in Redirect-ACL/DACL.

Step 28.ISE sends COA request to the NAD which should trigger new authentication for the user. NAD should confirm this request by COA ACK. Keep in mind that for VPN case COA push is used, so no new authentication request is sent. Instead ASA removes previous authorization parameters (Redirect URL, Redirect ACL, DACL) from the session and applies new parameters from COA request.

Stpe 29.New authentication request for the user.

Important considerations:

• Typically for Cisco NAD COA reauth is used by ISE, and this instructs NAD to initiate new authentication request with previous session ID. 
  
  
• On ISE side same session ID value is an indication that previously collected session attributes should be reused (Complaint status in our case) and new authorization profile based on those attributes should be assigned.
  
  
• In case of session ID change this connection is treated as a new and full posture process is restarted.
  
  
• To avoid re-posture at each session id change posture lease can be used. In this scenario information about posture status is stored in the endpoint attributes which stays on ISE even if session ID gets changed.

Step 30.New authorization policy is selected on ISE side based on posture status.

Step 31. Access-Accept with new authorization attributes is sent to the NAD.

Next flow describes the scenario when redirect URL is not retrieved (marked with letter b) by any posture probe and previously connected PSN has been queried by the last probe. All steps here are exactly the same as in the case with redirect URL except the replay which is returned by PSN as a result of Probe 4. If this probe landed on the same PSN which is an owner for the current authenitcation session, the replay contains session id value which is later used by posture agent to finish the process. In case when previous connected headend is not the same as current session owner, session lookup fails and empty response is returned to AC ISE posture module. As an ultimate result of this, No Policy Server Detected message is returned to the end user.

Figure 1-5

Posture flow in ISE 2.2

ISE 2.2 supports both old and new style simultaneously. This is the detailed explanation for the new flow:

Figure 2-1

Step 1.Authentication is a first step of the flow, it could be dot1x, MAB or VPN.

Step 2.ISE has to select authentication and authorization policy for the user. In posture scenario selected authorization policy needs to contain a reference to the posture status, which initially should be either unknown or not applicable. To cover both this cases, condition with posture status unequal compliant can be used. For posture with no redirection there is no need to use any Web Redirection configuration in authorization profile. You might still consider using a DACL or Airspace ACL to limit user access at the stage when posture status is not available.

Step 3.ISE returns Access-Accept with authorization attributes.

Step 4. If DACL name is returned in Access-Accept, NAD initiates DACL content download and applies authorization profile to the session after it is obtained.

Step 5. New approach assumes that redirection is not possible so user needs to enter client provisioning portal FQDN manually. FQDN of the CPP portal needs to be defined in portal configuration on the ISE sdie. From the DNS server perspective A-record needs to point to the ISE server with PSN role enabled.

Step 6. Client sends HTTP get to client provisioning portal FQDN, this request is parsed on ISE side and full portal URL is returned back to the client.

Figure 2-2

Step 7.SSL connection over port received in redirect URL is established (default 8443). This connection is protected by portal certificate from ISE side. Client Provisioning Portal (CPP) is presented to the user.

Step 8. At this step two events happen on ISE:

• Single Sign On (SSO) - ISE attempts to lookup previous successful authentication. ISE uses source IP address from the packet as a search filter for live radius sessions. 

Note: Session is retrieved based on match between source IP in the packet and Framed IP address in the session. Framed IP address is normally retrieved by ISE from the interim accounting updates, so it is required to have accounting enabled on the NAD side. As well you should remember that SSO is only possible on the node which owns the session. If for example session is authenticated on PSN 1 but FQDN itself points to PSN2 SSO mechanism fails.

• Client provisioning policy lookup - in case of successful SSO, ISE can use data from authenticated session and User-agent from client browser. In case of unsuccessful SSO user has to provide credentials and after user authentication information is retrieved from Internal and External Identity stores (AD/LDAP/Internal groups), it can be used for client provisioning policy check.

Note: Due to the bug CSCvd11574 you might see error at the time of client provisioning policy selection for non SSO case when external user is a member of multiple AD/LDAP groups added in external identity store configuration. Mentioned defect is fixed starting from ISE 2.3 FCS and fix requires to use CONTAINS in condition with AD group instead of EQUAL.

Step 9. After client provisioning policy selection ISE displays agent download URL to the user. After you click on download NSA, application is pushed to the user. NSA filename contains FQDN of the CPP portal.

Step 10.At this step NSA runs probes to establish connection to the ISE. Two probes are classic ones, and third one is designed to allow ISE discovery in environments without url redirection.

• NSA sends first discovery probe - HTTP /auth/discovery to Default gateway. NSA expects redirect-url as a result.
  
  
• NSA sends second probe if first one fails. Second probe is an HTTP GET /auth/discovery to enroll.cisco.com. This FQDN has to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com has to be routed through the tunnel.
  
  
• NSA sends third probe over CPP portal port to the client provisioning portal FQDN. This request contains information about portal session-id which allows ISE to identify which resources has to be provided.n

Step 11. NSA downloads Anyconnect and/or specific modules. Download process is done over client provisioning portal port.

Figure 2-3

Step 12. In ISE 2.2, posture process is divided into two stages. First stage contains set of traditional posture discovery probes to support backward compatibility with deployments which relays on url redirect.

Step 13.  First stage contains all traditional posture discovery probes. To get more details about the probes please review Step 20 in Pre ISE 2.2 posture flow.

Step 14.Stage two contains two discovery probes which allows AC ISE posture module to establish connection to the PSN where session is authenticated in environments where redirection is not supported. During stage two all probes are sequential.

• Probe 1 - During first probe AC ISE posture module tries to establish with IP/FQDNs from "Call Home List". List of the targets for the probe has to be configured in AC posture profile on ISE side. You can define IPs/FQDNs separated by commas, with colon you can define port number for each Call Home destination. This port needs to be equal to the port on which client provisioning portal is runs. On the client side information about call home servers is located in ISEPostureCFG.xml, this file can be found in folder - C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\

Call home target might not own the session and at this stage session owner lookup needs to happen. AC ISE Posture module instructs ISE to start owner lookup by using special target URL   - /auth/ng-discovery,  request as well contains client IPs and MACs list. After this message is recieved by PSN session lookup is first done locally (this lookup uses both IPs and MACs from the request sent by AC ISE posture module). If session is not found PSN initiates MNT node query. This request contains only MACs list, as a result FQDN of the owner should be obtained from MNT. After this PSN returns owner FQDN back to the client. Next request from client is sent to session owner FQDN with auth/status in URL and list of IPs and MACs.

• Probe 2 - At this stage AC ISE posture module tries PSN FQDNs which are located in ConnectionData.xml. You can find this file in C:\Users\<current user>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\. AC ISE Posture module creates this file after first posture attempt. File contains list of ISE PSNs FQDNs. Content of the list might be dynamically updated during next connection attempts. End goal of this probe is to get FQDN of current session owner. Implementation is identical to Probe 1 with the only difference in probe destination selection.

The file itself is located in folder of current user in case device is used by multiple users. Different user is not able to use information from this file. This might lead users to the chicken and egg problem in enviroments without redirection when Call home targets are not specified.

Step 15. After information about session owner is obtained, all subsequent steps are identical to pre ISE 2.2 flow.

Configure

For this document, ASAv is used as a network access device. All tests are conducted with posture over VPN. ASA configuration for posture over VPN support is outside of the document's scope, for more details refer to: ASA Version 9.2.1 VPN Posture with ISE Configuration Example

Note: For Deployment with VPN users recommned setting is redirection based posture . Config of callhomelist is not recommended . For all non vpn based user  ensure DACL is applied such that they donot talk to PSN where posture is configured . 

Network Diagram

Figure 3-1

Topology above is used in tests. With ASA it possible to easily simulate the scenario when SSO mechanism for Client Provisioning portal fails on PSN side, because of the NAT feature. In case of regular posture flow over VPN, SSO shoud works fine sine NAT is normaly not enforced for VPN IPs when users enter corporate network. 

Configurations

Client Provisioning Configuration

These are the steps to prepare Anyconnect configuration.

Step 1. Anyconnect package download. Anyconnect package itself is not available for direct download from ISE so before you begin, ensure that AC is available on your PC. This link can be used for AC download -  http://cisco.com/go/anyconnect In this document anyconnect-win-4.4.00243-webdeploy-k9.pkg package is used.

Step 2. In order to upload AC package to ISE, navigate to Policy > Policy Elements > Results > Client Provisioning > Resourcesand click Add. Choose Agent resources from local disk. In new window choose Cisco Provided Packages, click browse and select AC package on your PC.

Figure 3-2

Click Submit to finish import.

Step 3. Compliance module has to be uploaded to ISE. On the same page click Add and choose Agent resources from Cisco site. In resource list you should check a compliance module. For this document AnyConnectComplianceModuleWindows 4.2.508.0 compliance module is used.

Step 4. Now AC posture profile has to be created. Click Add and choose NAC agent or Anyconnect posture profile.

Figure 3-3

• Choose type of the profile. AnyConnect should to be used for this scenario. 
  
  
• Specify profile name. Navigate to Posture Protocol section of profile

Figure 3-4

• Specify Server Name Rules, this field cannot be empty. Field can contain FQDN with wildcard which restricts AC ISE posture module connection to PSNs from appropriate namespace. Put star if any FQDN should be allowed.
  
  
• Names and IPs specified here are in use during stage 2 of posture discovery. You can separate names by coma as well port number can be added after FQDN/IP using colon. In case if AC deployed out-of-band (not from ISE client provisioning portal) by using GPO or any other software provisioning system presence of Call Home addresses become essential since this would be only one probe which can reach ISE PSN sucsefully. This mean that in case of Out-Of-Band AC provisioning administrator needs to create AC ISE posture profile using AC profile editor and provision this file along with AC installation.

Note: Keep in mind that presence of Call home addresses is critical for multiuser PCs. Please review Step 14. in Posture flow Post ISE 2.2.

Step 5.Create AC configuration. Navigate to Policy > Policy Elements > Results > Client Provisioning > Resources and click Add, then select AnyConnect Configuration.

Figure 3-5

• Select AC package.
  
  
• Provide AC configuration name.
  
  
• Choose compliance module version.
  
  
• Select AC posture configuration profile from drop-down list.

Step 6. Configure client provisioning policy. Navigate to Policy > Client Provisioning. In case of initial configuration you can fill empty values in policy presented with defaults. In you need to add policy to existing posture configuration, navigate to policy which can be reused and choose Duplicate Above or Duplicate Below. Brand new policy can also be created.

This is the example of the policy used in the document.

Figure 3-6

Choose your AC configuration in result section. Keep in mind, that in case of SSO failure ISE can have only attributes from login to portal. This attributes are limited to information which can be retrieved about user from internal and external identity stores. In this document, AD group is used as a condition in Client Provisioning policy. 

Posture Policies and Conditions

Simple posture check is used. ISE is configured to check status of Window Defender service on the end device side. Real life scenarios can be much more complicated but general configuration steps are the same.

Step 1. Create posture condition. Posture conditions are located in  Policy > Policy Elements > Conditions > Posture. Choose type of posture condition. Below you can find example of Service condition which should check if Windows Defender service is running.

Figure 3-7

Step 2.Posture requirements configuration. Navigate to Policy > Policy Elements > Results > Posture > Requirements. This is an example for Window Defender check:

Figure 3-7

Choose your posture condition in new requirement and specify remediation action.

Step 3. Posture policy configuration. Navigate to Policy > Posture. Below you can find example of policy used for this document. Policy has Windows Defender requirement assigned as mandatory and only contains external AD group name as a condition. 

Figure 3-8

Configure Client Provisioning Portal

For posture without redirection, configuration of client provisioning portal has to be edited. Navigate to  Administration > Device Portal Management > Client ProvisioningYou can either use default portal or create your own. Same portal can be used for both posture with and without redirection. 

Figure 3-9

Those settings should be edited in portal configuration for non-redirection scenario:

• In Authentication, specify Identity Source Sequence which should be used if SSO cannot locate session for the user.
  
  
• According to selected Identity Source Sequence list of available groups is populated. At this point you need to select groups which are authorized for portal login.
  
  
• FQDN of client provisioning portal has to be specified for scenarios when AC needs to be deployed from the client provisioning portal. This FQDN should be resolvable to ISE PSNs IPs. Users should be instructed to specify the FQDN in the web browser during first connection attempt.

Configure Authorization Profiles and Policies

Initial access for client when posture status is not available needs to be restricted. This could be achieved in multiple ways:

• DACL Assignment - during restricted access phase DACL can be assigned to the user to limit access. This approach can be used for Cisco Network Access Devices.
  
  
• VLAN Assignment - before successful posture user can be put in restricted VLAN, this approach should work fine for almost any NAD vendor.
  
  
• Radius Filter-Id - with this attribute, ACL locally defined on NAD can be assigned to the user with unknown posture status. As this is a standard RFC attribute, this approach should work well for all NAD vendors.

Step 1. Configure DACL. Since this example is based on ASA, a NAD DACL can be used. For real life scenarios you might consider VLAN or Filter-ID as possible options.

In order to create DACL navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLsand click Add

During unknown posture state at least those permissions should be provided:

• DNS traffic
• DHCP traffic
• Traffic to ISE PSNs (ports 80 and 443 for possibility to open friendly FQDN of portal. Port on which CP portal is running which is 8443 by default and port 8905 for backward compatibility)
• Traffic to remediation servers if needed

This is an example of DACL without remediation servers:

Figure 3-10

Step 2. Configure authorization profile.

As usual for posture two authorization profiles are required. First one should contain any kind of network access restrictions (Profile with DACL used in this example). This profile can be applied to the authentications for which posture status is not equal to compliant. Second authorization profile might contain just permit acces and can be applied for session with posture status equals to compliant.

To create authorization profile navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.

Example of restricted access profile

Figure 3-11

In this example, default ISE profile PermitAccess is used for session after successful posture status check.

Step 3. Configure authorization policy. During this step two authorization policies should be created. One to match initial authentication request with unknown posture status and second one to assign full access after successful posture process.

It is an example of simple authorization policies for this case

Figure 3-12

Configuration of Authentication policy is not a part of this document but you should keep in mind that before authorization policy processing successful authentication has to happen.

Verify

Basic verification of the flow may consist of three main steps:

Step 1. Authentication flow verification

Figure 4-1

1. Initial authentication. For this step you may be interested in validation which authorization profile has been applied. If unexpected authorization profile has been applied please investigate detailed authentication report. You can open this report by clicking on magnifying glass in Details column. You can compare attributes in detailed authentication report with condition in authorization policy which you expect to match.
   
   
2. DACL download event. This string is presented only in the case when authorization profile selected for the initial authentication contains DACL name.
   
   
3. Portal authentication - this step in the flow indicates that SSO mechanism failed to locate user session. This might happen due to multiple reasons:
   
   • NAD is not configured to send accounting messages or Framed IP address is not present in them.
   • CPP portal FQDN has been resolved to the IP of the ISE node different from the node where initial authentication has been processed.
   • Client located behind the NAT.
4. Session data change, in this particular example session state has changed from Unknown to Compliant.
   
   
5. COA to network access device. This COA should be successful to push new authentication from the NAD side and new authorization policy assignment on ISE side. If COA has failed you can open detailed report to investigate the reason. Most common issues with COA can be:
   • COA timeout - in such case either PSN which has sent request is not configured as a COA client on the NAD side, or COA request has been dropped somewhere on the way.
   • COA negative ACK - indicate that COA has been received by NAD but due to some reason COA operation cannot be confirmed. For this scenario detailed report should contain more detailed explanation.

As ASA has been used as a NAD for this example, you can see no subsequent authentication request for the user. This happens due the fact ISE uses COA push for ASA which avoids VPN service interuption. In such scenario, COA itself contains new authorization parameters, so reauthentication is not needed.

Step 2.Client provisioning policy selection verification - For this you can run a report on ISE which can help you to understand which client provisioning policies were applied for the user.

Navigate to Operations > Reports Endpoint and Users > Client Provisioning and run the report for the date which you need

Figure 4-2

With this report you can verify what client provisioning policy was select and as well in case of failure, reasons should be presented in Failure Reason column.

Step 3.Posture report verification - Navigate to Operations > Reports Endpoint and Users >  Posture Assessment by Endpoint.

Figure 4-3

You can open detailed report from here for each particular event to check for example to which session ID this report belongs, which exact posture requirements were selected by ISE for the endpoint and as well status for each requirement.

Troubleshoot

General information

For posture process troubleshooting, those ISE components have to be enabled in debug on the ISE nodes where posture process can happen:

• client-webapp - component responsible for agent provisioning. Target log files guest.log and ise-psc.log.
• guestacess - component responsible for client provisioning portal component and session owner lookup (when request comes to wrong PSN). Target log file - guest.log.
• provisioning - component responsible for client provisioning policy processing. Target log file - guest.log.
• posture - all posture related events. Target log file -  ise-psc.log.

For the client side troubleshooting you can use:

• acisensa.log -In case of client provisioning failure on the client side this file is created in the same folder to which NSA has been downloaded (Downloads directory for Windows normally),
• AnyConnect_ISEPosture.txt - This file can be found in the DART bundle in directory Cisco AnyConnect ISE Posture Module. All information about ISE PSN discovery and general steps of posture flow are logged into this file.

Troubleshooting of common problems

SSO Related Issues

In case of successful SSO you might see these messages in ise-psc.log, this set of messages indicates that session lookup has finished successfully and authentication on the portal can be skipped.

2016-11-09 15:07:35,951 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: null, MacAddr: null, ipAddr: 10.62.145.121 
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [10.62.145.121], mac Addrs [null]
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = 5 
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session c0a801010002600058232bb8 using ipAddr 10.62.145.121

Text Window 5-1

You can use endpoint IP address as a search key to find this information.

A bit later in the guest log you should see that authentication has been skipped:

2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] guestaccess.flowmanager.step.cp.CPInitStepExecutor -::- SessionInfo is not null and session AUTH_STATUS = 1
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] com.cisco.ise.portalSessionManager.PortalSession -::- Putting data in PortalSession with key and value: Radius.Session c0a801010002600058232bb8
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] com.cisco.ise.portalSessionManager.PortalSession -::- Putting data in PortalSession with key : Radius.Session
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] guestaccess.flowmanager.step.cp.CPInitStepExecutor -::- Login step will be skipped, as the session =c0a801010002600058232bb8 already established for mac address null , clientIPAddress 10.62.145.121
2016-11-09 15:07:36,066 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cpm.guestaccess.flowmanager.processor.PortalFlowProcessor -::- After executeStepAction(INIT), returned Enum: SKIP_LOGIN_PROCEED

Text Window 5-2

In case of not working SSO ise-psc log file contains information about session lookup failure:

2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: null, MacAddr: null, ipAddr: 10.62.145.44 
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [10.62.145.44], mac Addrs [null]
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 10.62.145.44
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = null 
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType == null or is not a virtual NAS_PORT_TYPE ( 5 ).
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- No Radius session found

Text Window 5-3

In the guest.log in such case you should see full user authentication on the portal:

2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Find Next Step=LOGIN
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Step : LOGIN will be visible!
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Returning next step =LOGIN
2017-02-23 17:59:00,780 INFO [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Radius Session ID is not set, assuming in dry-run mode

Text Window 5-4

In case of authentication failures on the portal you need to focus on the portal configuration verification - Which identity store is in use? Which groups are authorized for login?

Troubleshoot Client Provisioning Policy Selection

In case of client provisioning policies failures or incorrect policy processing you can check guest.log file for more details:

2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- In Client Prov : userAgent =Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0, radiusSessionID=null, idGroupName=S-1-5-21-70538695-790656579-4293929702-513, userName=user1, isInUnitTestMode=false
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.common.utils.OSMapper -:user1:- UserAgent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.common.utils.OSMapper -:user1:- Client OS: Windows 7 (All)
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Retrieved OS=Windows 7 (All)
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Updating the idGroupName to NAC Group:NAC:IdentityGroups:S-1-5-21-70538695-790656579-4293929702-513
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- User Agent/Radius Session is empty or in UnitTestMode
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Calling getMatchedPolicyWithNoRedirection for user=user1
2017-02-23 17:59:07,505 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- CP Policy Status =SUCCESS, needToDoVlan=false, CoaAction=NO_COA 

Text Window 5-5

In the first string you can see how information about session is injected in the policy selection engine, in case of no policy match or incorrect policy match you can compare attributes from here with your client provisioning policy configuration. Last string indicates policy selection status.

Troubleshoot Posture Process

On client side you should be interested in investigation probes and their results. This is an example of successful stage 1 probe:

******************************************

Date : 02/23/2017
Time : 17:59:57
Type : Unknown
Source : acise

Description : Function: Target::Probe
Thread Id: 0x4F8
File: SwiftHttpRunner.cpp
Line: 1415
Level: debug

PSN probe skuchere-ise22-cpp.example.com with path /auth/status, status is -1..

******************************************

Text Window 5-6

At this stage PSN returns to AC information about session owner, you can see this couple messages later:

******************************************

Date : 02/23/2017
Time : 17:59:58
Type : Unknown
Source : acise

Description : Function: Target::probeRecentConnectedHeadEnd
Thread Id: 0xBE4
File: SwiftHttpRunner.cpp
Line: 1674
Level: debug

Target skuchere-ise22-2.example.com, posture status is Unknown..

******************************************

Text Window 5-7

Session owners returns to agent all required information:

******************************************

Date : 02/23/2017
Time : 17:59:58
Type : Unknown
Source : acise

Description : Function: SwiftHttpRunner::invokePosture
Thread Id: 0xFCC
File: SwiftHttpRunner.cpp
Line: 1339
Level: debug

MSG_NS_SWISS_NEW_SESSION, <?xml version="1.0" ?>
<root>
 <IP></IP>
 <FQDN>skuchere-ise22-2.example.com</FQDN>
 <PostureDomain>posture_domain</PostureDomain>
 <sessionId>c0a801010009e00058af0f7b</sessionId>
 <configUri>/auth/anyconnect?uuid=106a93c0-9f71-471c-ac6c-a2f935d51a36</configUri>
 <AcPackUri>/auth/provisioning/download/81d12d4b-ff58-41a3-84db-5d7c73d08304</AcPackUri>
 <AcPackPort>8443</AcPackPort>
 <AcPackVer>4.4.243.0</AcPackVer>
 <PostureStatus>Unknown</PostureStatus>
 <PosturePort>8443</PosturePort>
 <PosturePath>/auth/perfigo_validate.jsp</PosturePath>
 <PRAConfig>0</PRAConfig>
 <StatusPath>/auth/status</StatusPath>
 <BackupServers>skuchere-ise22-1.example.com,skuchere-ise22-3.example.com</BackupServers>
</root>
.

******************************************

Text Window 5-8

From the PSN side you can focus on the those messages in guest.log when you expect that initial request came to the node who does not own session:

2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Got http request from 10.62.145.44 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.4.00243)
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- mac_list from http request ==> 00:0B:7F:D0:F8:F4,00:0B:7F:D0:F8:F4
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- iplist from http request ==> 172.16.31.12,10.62.145.95
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Session id from http request - req.getParameter(sessionId) ==> null
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being processed in the for loop ==> 172.16.31.12
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being processed in the for loop ==> 10.62.145.95
2017-02-23 17:59:56,368 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Found Client IP null and corresponding mac address null
2017-02-23 17:59:56,369 ERROR [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- Session Info is null
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Not able to find a session for input values - sessionId : null, Mac addresses : [00:0B:7F:D0:F8:F4, 00:0B:7F:D0:F8:F4], client Ip : [172.16.31.12, 10.62.145.95]
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- clientMac is null/ empty, will go over the mac list to query MNT for active session
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Performing MNT look up for macAddress ==> 00-0B-7F-D0-F8-F4
2017-02-23 17:59:56,539 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Performed MNT lookup, found session 0 with session id c0a801010009e00058af0f7b
2017-02-23 17:59:56,539 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- getting NIC name for skuchere-ise22-cpp.example.com
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- local interface 0 addr 10.48.17.249 name eth0
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- Nic name for local host: skuchere-ise22-cpp.example.com is: eth0
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- getting host FQDN or IP for host skuchere-ise22-2 NIC name eth0
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- hostFQDNOrIP for host skuchere-ise22-2 nic eth0 is skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- PDP with session of 00-0B-7F-D0-F8-F4 is skuchere-ise22-2, FQDN/IP is: skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Redirecting the request to new URL: https://skuchere-ise22-2.example.com:8443/auth/status
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Session info is null. Sent an http response to 10.62.145.44.
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP-WITH-SESSION value is skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- header Location value is https://skuchere-ise22-2.example.com:8443/auth/status

Text Window 5-9

Here you can see that PSN first trying to find session locally, and after failure initiates request to MNT using IPs and MACs list to locate session owner.

A little bit later you should see request from the client on correct PSN:

2017-02-23 17:59:56,790 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [172.16.31.12, 10.62.145.95], mac Addrs [00:0B:7F:D0:F8:F4, 00:0B:7F:D0:F8:F4]
2017-02-23 17:59:56,790 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 172.16.31.12
2017-02-23 17:59:56,791 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = 5 
2017-02-23 17:59:56,792 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address 172.16.31.12
2017-02-23 17:59:56,792 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session c0a801010009e00058af0f7b using ipAddr 172.16.31.12

Text Window 5-10

As a next step PSN performs client provisioning policy lookup for this session:

2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] com.cisco.cpm.swiss.SwissServer -::::- null or empty value for hostport obtained from SwissServer : getHostNameBySession() 
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: c0a801010009e00058af0f7b, MacAddr: 00-0b-7f-d0-f8-f4, ipAddr: 172.16.31.12 
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: c0a801010009e00058af0f7b, IP addrs: [172.16.31.12], mac Addrs [00-0b-7f-d0-f8-f4]
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session using sessionId c0a801010009e00058af0f7b
2017-02-23 17:59:56,795 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -::::- User user1 belongs to groups NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation,NAC Group:NAC:IdentityGroups:Any
2017-02-23 17:59:58,203 DEBUG [http-bio-10.48.30.41-8443-exec-8][] com.cisco.cpm.swiss.SwissServer -::::- null or empty value for hostport obtained from SwissServer : getHPortNumberBySession() 
2017-02-23 17:59:58,907 DEBUG [http-bio-10.48.30.41-8443-exec-10][] cisco.cpm.posture.util.AgentUtil -::::- Increase MnT counter at CP:ClientProvisioning.ProvisionedResource.AC-44-Posture

Text Window 5-11

On the next step you can see process of posture requirements selection. At the end of the step list of requirements prepared and returned to the agent:

2017-02-23 18:00:00,372 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -:user1:::- About to query posture policy for user user1 with endpoint mac 00-0b-7f-d0-f8-f4 
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureManager -:user1:::- agentCMVersion=4.2.508.0, agentType=AnyConnect Posture Agent, groupName=OESIS_V4_Agents -> found agent group with displayName=4.x or later
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- User user1 belongs to groups NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation,NAC Group:NAC:IdentityGroups:Any
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- About to retrieve posture policy resources for os 7 Professional, agent group 4.x or later and identity groups [NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation, NAC Group:NAC:IdentityGroups:Any]
2017-02-23 18:00:00,432 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by agent group with FQN NAC Group:NAC:AgentGroupRoot:ALL:OESIS_V4_Agents
2017-02-23 18:00:00,433 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- The evaluation result by agent group for resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend is Permit
2017-02-23 18:00:00,433 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by OS group with FQN NAC Group:NAC:OsGroupRoot:ALL:WINDOWS_ALL:WINDOWS_7_ALL:WINDOWS_7_PROFESSIONAL_ALL
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- stealth mode is 0
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- The evaluation result by os group for resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend is Permit
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by Stealth mode NSF group with FQN NAC Group:NAC:StealthModeStandard
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Procesing obligation with posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Found obligation id urn:cisco:cepm:3.3:xacml:response-qualifier for posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Found obligation id PostureReqs for posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Posture policy resource id WinDefend has following associated requirements []
2017-02-23 18:00:03,884 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- policy enforcemnt is 0
2017-02-23 18:00:03,904 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- simple condition: [Name=WinDefend, Descriptionnull, Service Name=WinDefend, Service Operator=Running, Operating Systems=[Windows All], Service Type=Daemon, Exit code=0]
2017-02-23 18:00:03,904 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- check type is Service
2017-02-23 18:00:04,069 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -:user1:::- NAC agent xml <?xml version="1.0" encoding="UTF-8"?><cleanmachines>
 <version>ISE: 2.2.0.470</version>
 <encryption>0</encryption>
 <package>
 <id>10</id>
 <name>WinDefend</name>
 <description>Enable WinDefend</description>
 <version/>
 <type>3</type>
 <optional>0</optional>
 <action>3</action>
 <check>
 <id>WinDefend</id>
 <category>3</category>
 <type>301</type>
 <param>WinDefend</param>
 <operation>running</operation>
 </check>
 <criteria>(WinDefend)</criteria>
 </package>
</cleanmachines> 

Text Window 5-12

Later, you can see that posture report was received by PSN:

2017-02-23 18:00:04,231 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -::::- UDID is 8afb76ad11e60531de1d3e7d2345dbba5f11a96d for end point 00-0b-7f-d0-f8-f4
2017-02-23 18:00:04,231 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -::::- Received posture request [parameters: reqtype=report, userip=10.62.145.44, clientmac=00-0b-7f-d0-f8-f4, os=WINDOWS, osVerison=1.2.1.6.1.48, architecture=9, provider=Device Filter, state=, userAgent=Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.4.00243), session_id=c0a801010009e00058af0f7b

Text Window 5-13

At the end of the flow ISE marks endpoint as compliant and initiates COA:

2017-02-23 18:00:04,272 INFO [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureManager -:user1:::- Posture state is compliant for endpoint with mac 00-0b-7f-d0-f8-f4
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- entering triggerPostureCoA for session c0a801010009e00058af0f7b
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture CoA is scheduled for session id [c0a801010009e00058af0f7b]
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture status for session id c0a801010009e00058af0f7b is Compliant
2017-02-23 18:00:04,273 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Issue CoA on active session with sessionID c0a801010009e00058af0f7b
2017-02-23 18:00:04,273 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture CoA is scheduled for session id [c0a801010009e00058af0f7b] 

 Text Window 5-14