cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3993
Views
0
Helpful
17
Replies

VPN AutH with ISE

I am using ISE as Auth server for vpn clients, everything works fine when I am using anyconnect on mobile phone, the user gets connected instantly and in ISE logs it shows correct AUTH and AUTHZ policies but when I am trying to connect the same user over a laptop then ISE denies the user request and in ISE logs it shows the correct AUTH policy but in AUTZ it hits default which has deny access profile.

Is this a known issue?

If anyone knows the solution then kindly let me know

ISE 2.3

ASA 9.7.1

17 Replies 17

Marvin Rhoads
Hall of Fame
Hall of Fame

We would need to know the conditions in the policy you expect the user to match when on wired device and compare them against the observed Authorization details from the RADIUS Live Log.

well I have specified Radius port type virtual for All_User_ID_Store which contains my AD, this if for Auth policy and it hits this policy.

Then I have created a group for vpn users and defined the users locally with password from AD.

In authZ conditions it is as follow

If Identity Group Name=Allow_VPN_USERS & Radius NAS IP Address=ip_add_of_ASA(defined IP address here)

then permit access

default policy deny acccess

Also one more thing I would like to add here is that in Radius logs on ISE for mobile devices it does not takes endpoint profile, but in case of laptop it takes 

it as workstation, but I have not defined these machines here, I just want to authenticate the user on base of his username, later on I will be doing posture validation.

 

So the user on remote mobile device is working but the same user on remote laptop (both cases on same VPN) does not work?

 

When you compare the Authorization detail report from RADIUS live logs is ISE seeing the username correctly in both cases?

Please check attached images, for cellphone it does not gets any endpoint profile but for laptop it says Microsoft-Workstation

Well you're getting Authentication Failed and thus it drops to the default Authorization rule.

 

We would normally expect an unauthenticated user to be denied access.

The same user is getting authenticated on the mobile device and then going to the correct authorization policy, why is it just going other way around for laptops

Does the user hit the same tunnel-group (connection profile) in both cases? Are you entering your credentials via the AnyConnect UI dialog box?

 

You could capture the LDAP traffic between your PSN and AD to verify the correct password is being sent to AD.

Yes, both requests are going to same connection profiles and yes I am entering credentials via UI.
Can you elaborate on how to verify the LDAP traffic from ISE?

When I am testing the user credentials againt the AD from ISE, it gives success, also I have imported all the groups from the AD.

Under Monitor > Troubleshoot > Diagnostic Tools do a tcpdump / packet capture from your PSN. Restrict it to just traffic to your AD server (e.g., host x.x.x.x). Start the capture, run a (failed) authentication  and then stop the capture and open up the traffic in Wireshark.

Hi,

Sorry for late response, credentials are correct and I have also verified them by test user against the AD from ISE.

 

Ok I have done a small change, in the AUTHZ policy in conditions I removed user identity group and just kept NAS_IP_ADDRESS and it worked, so I guess it has something to do with the user group

Ok, thanks for the update.

 

It's odd that the same user would be found to be a group memeber when on m,obile device and not found to be group member when on laptop.

 

I'd look at the details of ExternalGroups under Other Attributes in the Authentication Details report. It should report which SID(s) it found the user to be a member of. (You can see values for the SIDs vs. group name when you do the server-based Authentication test.)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: