IAS Radius question

fightclub34

Right now we have radius setup for all of our switch logins we have the privilege set on ias side to be 15 so your at privilege level when you log in. We are allowing access to the switch by AD group and we have about 7 people in that group mainly for changing vlans, etc.

We have an ASA, Core switch, Routers that i want to setup with AAA and use the same radius server but i cannot figure out on the IAS side how to keep people from the switch group out of these devices. IAS works from top to bottom if it doesnt find a match on the first policy it goes to the second policy so it will end up using the switch group. IS there a way to differentiate devices/polices to limit who can get into certain groups.

We also have VPN groups setup for radius authentication. If you are currently in the VPN group you can get into all of our switches. I have tried changing the order of the policies nothing seems to fix this.

sprkymrk

On the IAS side, use the "Client IP Address equals" as the first policy condition, ahead of the "Windows Group equals" as a second policy condition - within the same policy rule.

So on the policy for the firewall, it would be:
Client IP Address equals 192.168.1.1 AND
Windows Group equals Domain\FirewallAdmins

This way the policy only comes into effect if they are accessing the firewall, then secondly only if they are a member of the FirewallAdmins group. You have a policy per device. We manage several dozen network devices with this method.

fightclub34

This would definitely work. the only problem is we have about 60 switches that would be alot of policies and work on the radius server

cisco_trooper

fightclub34 wrote: »

This would definitely work. the only problem is we have about 60 switches that would be alot of policies and work on the radius server

You can use wildcards in that IP address. So if your 60 switches IP vary from your firewall IPs in someway you could get around that by using a wildcard.

fightclub34

ASA is .4 all other devices range from .10 - 100 it looks like you can use a subnet mask not an actual wildcard mask. Is there anyway to omit a low range and apply the same policy to the .10 - 100

cisco_trooper

fightclub34 wrote: »

ASA is .4 all other devices range from .10 - 100 it looks like you can use a subnet mask not an actual wildcard mask. Is there anyway to omit a low range and apply the same policy to the .10 - 100

by wildcard i didn't mean a wildcard mask. you can use a wildcard character, in this case I BELIEVE it is a *

So if your asa is .4 i would match that ip specifically to .4.

I don't know if you can do a range or not with these. you can maybe match on .1* .2* .3* .4* and so on. You'll still end up with 10 policies that way, but that is still better than 60.

If you are flexible with your management IPs, and you have the time (who does?) then just for future simplicity you may change the third octet of your switch IPs to something different from your firewalls so you can just wildcard a whole range, for ex: 172.16.1.* for your switch policy.

cisco_trooper

You can also use the calling station id, which is the IP address of whoever is logging into the device. If you have just a few people, set DHCP reservations for these guys, and then you can use their IP addresses as a condition to match for a policy. this obviously prevents them from logging in to the devices from other locations, which COULD present a problem in some situations/environments.

sprkymrk

Or better yet, just use the "Client IP Address equals" AND "Windows Group equals" for the firewall policy as your first policy.

Then simply use a "Windows Group is" for your other policies, omitting the "Client IP Address equals" for your switches.

cisco_trooper

sprkymrk wrote: »

Or better yet, just use the "Client IP Address equals" AND "Windows Group equals" for the firewall policy as your first policy.

Then simply use a "Windows Group is" for your other policies, omitting the "Client IP Address equals" for your switches.

Even better.

sprkymrk

@cisco_trooper

Actually I have never used the "caller station id" method, but that's a handy tip I have filed away for future reference.

fightclub34

Ok thanks guys this is awesome. My last pitfall is i have mgmt users on the asa for configurations and i also have vpn groups that use radius. So right now my vpn users could actually access the device because they pass the radius group. Any ideas for this one

cisco_trooper

fightclub34 wrote: »

Ok thanks guys this is awesome. My last pitfall is i have mgmt users on the asa for configurations and i also have vpn groups that use radius. So right now my vpn users could actually access the device because they pass the radius group. Any ideas for this one

Create a separate policy for the VPN users. Create a VPN group in AD. You will match on the Windows Group as before. A couple other conditions you can match on are the NAS-IP-Address, which will be the firewall IP address, NAS-Port-Type, which will be VPN, Authentication-Type, which will be PAP. In the VPN access policy you won't be passing any shell privelege level stuff like you have probably done for the other policies you have.