topic Re: ISE posture with distributed deployment in Network Access Control

ISE posture with distributed deployment

Tmsna — Wed, 29 Aug 2018 15:28:45 GMT

Hi Guys,

Quick question.

At the moment I have only one ISE which I'm using it to do authentication and posture for AV over Wired, wireless and VPN.

I will need to deploy a distributed environment and I'm not sure how to configure the posture piece.

At the moment the posture XML file is poiting to the IP of ISE. I tried to change it to the FQDN but it didn't work.

Do you have any idea how to achieve this?

Albert

Re: ISE posture with distributed deployment

hslai — Thu, 30 Aug 2018 13:26:55 GMT

In case you are able to save the profile with FQDN as the DiscoveryHost, then please ensure the endpoints able to resolve the FQDN to a valid IP address during posture discovery. If deployed with Cisco Umbrella or WebSec, ensure the DNS lookup working for this query and not blocking the access to the site.

In case the editor not permitting you to save the field using FQDN, please open a TAC case to investigate.

Re: ISE posture with distributed deployment

Tmsna — Thu, 30 Aug 2018 13:42:48 GMT

Hi hslai,

Thanks for your reply.
I can see that the endpoint are able to resolve the FQDN of ISE, but it only works with IP.
When I check the logs of DART, I can see that the endpoint is trying to access to ISE using private IP on port 8905, FQDN and enrol.cisco.com:8905.
I'm still learning on ISE and I'm not sure where the issue is.

I'm not using Umbrella or Websec in our lab.

Albert

Re: ISE posture with distributed deployment

hslai — Thu, 30 Aug 2018 16:19:42 GMT

Take a look at ISE Posture Style Comparison for Pre and Post 2.2 - Cisco.

Since you are seeing the endpoint trying to access FQDN, the one specified as DiscoveryHost in the agent profile, please follow how the attempt flows. It should go like this:

http://DiscoveryHost:80

-> Redirect to the ISE PSN that authenticates this endpoint session

-> Able to access ISE PSN and download the posture requirements, etc.

Re: ISE posture with distributed deployment

Tmsna — Thu, 30 Aug 2018 16:22:48 GMT

And how is this going to work in a distributed environment?
For instance, two ISE(one primary and one secondary)

Re: ISE posture with distributed deployment

hslai — Thu, 30 Aug 2018 16:27:54 GMT

DiscoveryHost needs not be one of the PSNs at all. It needs only be a site that would trigger URL redirect based on the redirect ACL.

For example, I set it in my lab to point it to my AD web site.

Re: ISE posture with distributed deployment

Tmsna — Thu, 30 Aug 2018 16:36:48 GMT

I'm not sure how this is going to work.
At the moment on the switch I don't have any URL redirection ACL; I have one only in the ASA:
ACL:
Deny ip any host (AV server)
Permit tcp any any eq 80
Permit tcp any any eq 443
Deny ip any any

This is my profile for Wired posture:
[cid:image001.png@01D44087.F78D4420]

This is my profile for VPN posture:
[cid:image002.png@01D44087.F78D4420]

If it is wrong, can you help to design in the correct way?
Also I want to specify that the posture is working fine at the moment.

Re: ISE posture with distributed deployment

paul — Thu, 30 Aug 2018 21:32:02 GMT

You need to ensure that posture is reported to the correct PSN that authenticated the user. The best way to do this is get posture discovery working correctly. In this way, it doesn't matter if you have 2 PSNs or 20. I don't use the posture discovery host. I like posture discovery to work with a fresh install of the posture module no customization required. The two methods that are easy to intercept are:

Port 80 to the default gateway.
Port 80 to enroll.cisco.com.

My stock posture discover ACL for wired is:

ip access-list extended POSTURE-DISCOVERY
permit tcp any 10.0.0.1 0.255.255.0 eq 80
permit tcp any host 72.163.1.80 eq 80
deny ip any any

This assumes the client is a 10.x.x.x network and .1 is their typical default gateway. 72.163.1.80 is enroll.cisco.com. This will get you to the right PSN everytime even for a fresh installed posture module with no customization.

Re: ISE posture with distributed deployment

Tmsna — Thu, 30 Aug 2018 21:37:48 GMT

Just to specify, I believe this access list is configured in all your switches and you recall this Acl in the posture profile. Is it correct?
Sorry for all my questions, but I still don’t understand how this should work and I cannot find any good documentation about this.

Thanks anyway 🙂

Re: ISE posture with distributed deployment

paul — Thu, 30 Aug 2018 21:44:48 GMT

Yes the ACL is part of my standard template on my switches. In the posture unknown state you reference this ACL for the client provisioning portal redirect. You don't care about the client provisioning portal, but that is how you apply the redirect for posture discovery.

Here is my general rule of thumb when not using the client provisioning portal to distribute the posture module (I never use the client provisioning portal):

The redirect ACLs only job is to assist the posture module in discovery the PSN to report posture to. Just have it redirect port 80 to the default gateway or enroll.cisco.com. For wired you can use funky masks like I showed to accommodate both. For wireless you can't use funky masks, so just use enroll.cisco.com and/or put in the GW of the WLC clients. For VPN I just use enroll.cisco.com typically. You can use a discovery host as well, but that requires you to customize the posture module on install.

If you want to restrict access preposture (unknown state) then you use DACLs on wired/VPN or apply ACLs on wireless. Don't use the redirect ACL to restrict access.

Re: ISE posture with distributed deployment

Tmsna — Thu, 30 Aug 2018 22:20:48 GMT

Thanks for your explanation. At the moment I’m applying a dACL to wired and VPN with posture status unequal to compliant and in this ACL I’m allowing only access to ISE, DC servers and AV server.

If I configure enroll.cisco.com in the redirect ACL, I believe I need to allow this connection also in the dACL. Am I correct?

Also for me it is not a problem to customize the XML file for posture, because the users can download it when they connect with Anyconnect via VPN.
Would you be able to explain how the discovery host customized is configured? if I don’t use the IP of ISE, what IP should I use?

Re: ISE posture with distributed deployment

Tmsna — Thu, 30 Aug 2018 23:07:17 GMT

Please let me know if it sounds good to you.

i will configure an xml file adding the IPs of my two ISE in the entry of call home list. In theory this setup should work in case primary ISE fails and the secondary will take its place.

Re: ISE posture with distributed deployment

paul — Fri, 31 Aug 2018 00:02:48 GMT

Yep that is correct. You need to allow the traffic through the DACL to get redirected. So you can just allow the enroll.cisco.com and the default gateway if you want.

You can pick an IP as the discovery host. You just need the client to make a call to that IP on port 80 so you can redirect it. It is the same concept as the enroll.cisco.com.

I just like getting posture discovery working correctly then I don't require any special XML files to be deployed. The call home servers are fine but they don't necessarily get you to the PSN that authenticated the user right away. Let's say you get authenticated by PSN2 and the posture module talks to PSN1 because it is first in the Call Home list. It will then redirect the posture module over to PSN2. At least I am pretty sure how that feature works. Like I said I just prefer to get posture discovery working then you get to the right PSN every time the first time.

Re: ISE posture with distributed deployment

Tmsna — Fri, 31 Aug 2018 08:36:06 GMT

Hi Paul,

Thanks for all your help.
I've tested now with redirection.
In the ACL on the ASA I've permitted tcp any any eq 80 and 443; instead on the dACL I've allowed permit tcp any any eq 80
My last question is: When I tested with this setup, I have always the webpage open of ISE for client provisioning.
Is it possible to have this setup without the opening of this webpage?

Because when I have user call home list, I don't have the CPP.
Albert

Re: ISE posture with distributed deployment

Tmsna — Fri, 31 Aug 2018 08:49:14 GMT

Also I would like to specify that the posture is working on Wired and VPN, but on wired I don't have any ACL for redirection configured on the switch and it is still working.

I've checked all configuration (ISE as well) and I've deleted the IP of ISE from any call home list entry.

I'm not sure why this is happening.

Re: ISE posture with distributed deployment

paul — Fri, 31 Aug 2018 12:33:07 GMT

You need to understand how the discovery piece of posturing works to answer some of you questions. This link has it all explained:

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html

Post 2.2 there are two stages to posture discovery. Stage 1 is the legacy methods that require posture redirection or require that you have reported posture before:

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.

So when you say your client works on wired without redirection and Call home list. That is because of #4. You have reported posture before so you aren't running a valid new client test. If you want to test a fresh client then delete your posture config file and stop and start the service. Again if I am in a Cisco environment, I prefer to use stage 1 methods with redirection to ensure the fastest possible policy server discovery.

Stage 2 was added for environment that don't support URL redirection or I guess if you don't want to configure it.

Probe 1 - During first probe AC 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. 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. If session is not found PSN initiates MNT node query. This request contains clint IPs/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 posture module tries PSN FQDNs which are located in ConnectionData.xml. You can find this file in C:\Users\\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\. Posture module retrievs this file at time of first posture attempt. File contains list of ISE PSNs FQDN. Content of the list might be dynamically updated during next connection attempt. End goal of the probe is to get FQDN of current session owner. Implementation is identical to Probe 1 with the only difference in probe destination selection.

Re: ISE posture with distributed deployment

hslai — Sat, 01 Sep 2018 00:20:13 GMT

Paul:- Thanks a lot for helping out.

Albert:- In case still unable to resolve your issues after reading the doc, please open a Cisco TAC case, so TAC may help reviewing your configurations and checking the AnyConnect DART files.

Re: ISE posture with distributed deployment

andre.ortega — Tue, 06 Aug 2019 16:42:39 GMT

Hello there,

in case of a distributed deployment, should I create a profile for each site, with specific list of PSNs?

For example:

Site A = Profile A = Call home PSN1 and PSN2

Site B = Profile B = Call home PSN3 and PSN4

Or could I have only one profile with all PSNs on Call Home list (PSN1, PSN2, PSN3 and PSN4)?