The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes new functionality in Identity Service Engine (ISE) 2.2 that allows ISE to support a posture flow without any kind of redirection support on either a Network Access Device (NAD) or ISE. This document also compares the posture flow in ISE 2.2 to the posture flow in ISE versions earlier than 2.2.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
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.
Posture is a core component of Cisco ISE. Posture as a component can be represented by three main elements:
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.
This image shows 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:
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:
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:
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:
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:
Figure 1-3
Step 19.Anyconnect ISE posture process is launched.
Anyconnect ISE Posture module starts in any of these situations:
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:
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 information 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:
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:
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
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:
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.
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.
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.
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.
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.
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 .
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.
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
Figure 3-4
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
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.
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-8
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-9
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-10
Those settings should be edited in portal configuration for non-redirection scenario:
Initial access for client when posture status is not available needs to be restricted. This could be achieved in multiple ways:
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:
This is an example of DACL without remediation servers:
Figure 3-11
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-12
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-13
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.
Basic verification of the flow may consist of three main steps:
Step 1. Authentication flow verification
Figure 4-1
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.
For posture process troubleshooting, those ISE components have to be enabled in debug on the ISE nodes where posture process can happen:
For the client side troubleshooting you can use:
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?
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.
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
Revision | Publish Date | Comments |
---|---|---|
1.0 |
24-Aug-2021 |
Initial Release |