03-14-2011 03:20 AM - edited 02-21-2020 05:13 PM
Hi all,
I was wondering if it's possible on the ACS or ASA to restrict access to a policy group depending on the IP address they are coming from? For example, if I wanted users from home to connect to the outside interface of the firewall to authenticate with a token but if they are in the office to connect to the internal interface and just use LDAP. Both these options are working but this doesn't seem to stop someone from home authenticating off LDAP from home. I know that Radius has the Caller-ID field which has the IP address of the device authenticating. I was wondering if it's possible to use this information either on the ASA or ACS to add the control I need. Any ideas?
Regards,
Mike
Solved! Go to Solution.
03-20-2011 03:22 AM
Hi Michael,
you have multiple options:
- the ASA indeed sends 2 attributes to the Radius server that contain the ip address of the client. This is from "debug radius" when I connect from a client with ip 192.168.0.98:
Radius: Type = 31 (0x1F) Calling-Station-Id
Radius: Length = 14 (0x0E)
Radius: Value (String) =
31 39 32 2e 31 36 38 2e 30 2e 39 38 | 192.168.0.98
...
Radius: Type = 66 (0x42) Tunnel-Client-Endpoint
Radius: Length = 14 (0x0E)
Radius: Value (String) =
31 39 32 2e 31 36 38 2e 30 2e 39 38 | 192.168.0.98
Now if you can configure ACS to generate a different response based on the value of Calling-Station-Id or Tunnel-Client-Endpoint, I don't know (well I'm pretty sure you can but it has been a while since I did anything fancy on ACS) You may want to ask this in the AAA forum.
- if you want the ASA to make the decision, you can do this using CSD (Cisco Secure Desktop - requires a license). CSD allows to create separate policies based on endpoint (client) attributes such as anti-virus version installed, but also including client ip address. You may have to use this in combination with DAP (dynamic access policy) to allow/deny access to a certain group based on CSD endpoint criteria.
- but for the specific scenario you describe, you might be able to solve this by simply specifying the interface in the authentication-server-group.
I.e. if you currently have
tunnel-group from-inside general-attributes
authentication-server-group MyLDAP
then change this to:
tunnel-group from-inside general-attributes
authentication-server-group (inside) MyLDAP
This will cause LDAP to be used only for connections from the inside. Other connections will use LOCAL (so anyone with an account on the ASA will still be able to connect from outside to this group - to prevent that you can create a new aaa server group with a non-existing server, and use that for outside authentication).
Or maybe merge your 2 existing groups into one, with
tunnel-group from-anywhere general-attributes
authentication-server-group (inside) MyLDAP
authentication-server-group (outside) MyTokenServer
hth
Herbert
03-20-2011 03:22 AM
Hi Michael,
you have multiple options:
- the ASA indeed sends 2 attributes to the Radius server that contain the ip address of the client. This is from "debug radius" when I connect from a client with ip 192.168.0.98:
Radius: Type = 31 (0x1F) Calling-Station-Id
Radius: Length = 14 (0x0E)
Radius: Value (String) =
31 39 32 2e 31 36 38 2e 30 2e 39 38 | 192.168.0.98
...
Radius: Type = 66 (0x42) Tunnel-Client-Endpoint
Radius: Length = 14 (0x0E)
Radius: Value (String) =
31 39 32 2e 31 36 38 2e 30 2e 39 38 | 192.168.0.98
Now if you can configure ACS to generate a different response based on the value of Calling-Station-Id or Tunnel-Client-Endpoint, I don't know (well I'm pretty sure you can but it has been a while since I did anything fancy on ACS) You may want to ask this in the AAA forum.
- if you want the ASA to make the decision, you can do this using CSD (Cisco Secure Desktop - requires a license). CSD allows to create separate policies based on endpoint (client) attributes such as anti-virus version installed, but also including client ip address. You may have to use this in combination with DAP (dynamic access policy) to allow/deny access to a certain group based on CSD endpoint criteria.
- but for the specific scenario you describe, you might be able to solve this by simply specifying the interface in the authentication-server-group.
I.e. if you currently have
tunnel-group from-inside general-attributes
authentication-server-group MyLDAP
then change this to:
tunnel-group from-inside general-attributes
authentication-server-group (inside) MyLDAP
This will cause LDAP to be used only for connections from the inside. Other connections will use LOCAL (so anyone with an account on the ASA will still be able to connect from outside to this group - to prevent that you can create a new aaa server group with a non-existing server, and use that for outside authentication).
Or maybe merge your 2 existing groups into one, with
tunnel-group from-anywhere general-attributes
authentication-server-group (inside) MyLDAP
authentication-server-group (outside) MyTokenServer
hth
Herbert
03-21-2011 01:51 PM
Thanks Herbert. Your response was really useful.
Regards,
Mike
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide