dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
3106

addp009
Premium Member
join:2003-03-08
Kitchener, ON

addp009

Premium Member

IOS and Active Directory intergration using Radius

I have a router that is providing a few services. I'd like to integrate user authentication into active directory via radius for VPN remotes, authentication proxy and console access. But I need to be able to set different profiles on MS ISA so it can return the proper attributes for the services and only allow a subset of users to access the different services (ie, a VPN users should not have console access to the router, and etc).

So far, I haven't been able to find a way to setup the AAA authentication lists to send a unique identifier that I can match and sort into different profiles on MS IAS.

Any ideas?
meta
join:2004-12-27
00000

meta

Member

I have never been able to successfully do that on a router.
On the ASAs however, you can use something called DAP (dynamic access policies) to match a group attribute returned by the AAA server. In that case, you would use AD (dont need RADIUS) to match a users global/universal group membership in a domain. So you would just greate a group called something like VPN_USER and join the users to it in AD. Then on the ASA you would match that group attribute and only permit users to login that authenticated and the domain controller replied with them being a member of that group.

refused
join:2005-10-10

refused to addp009

Member

to addp009
on the IAS/radius server, for your VPN group, use the "called-station-id" attribute and set its argument to your external IP that your VPN clients connect to. doing that will set that VPN group on your radius server to only authenticate connection requests to that external IP, no other IP's (routers internal interface, other routers, etc). this will eliminate that group from authenticating other connection requests to other interfaces/routers. this is assuming you dont have ssh/telnet or http access to that external interface/IP that your vpn clients connect to.

Angralitux
join:2004-05-20
DO

Angralitux to meta

Member

to meta
you sure can get it to work. You may get some clues on this old thread, I was looking to authenticate users connecting PPTP VPN to a router.

»[Info] anyone used MS IAS as a RADIUS for cisco devices?

is pretty much useless for what you're looking to, but you may get some ideas.

addp009
Premium Member
join:2003-03-08
Kitchener, ON

addp009

Premium Member

Thanks guys,

I actually found solution that works. I created loopback interfaces, then use aaa group server radius groups, set the radius server and a source interface to one of the loopbacks.
On the radius server, create clients based on the loopback interface addresses, then create policies matching on Client Friendly Name or Client Address (which are the loopbacks addresses)

aaa group server radius vpnradius
 server-private 10.0.0.2 auth-port 1645 acct-port 1646 key <deleted>
 ip radius source-interface Loopback0
!
aaa authentication login vpnclientauth group vpnradius local
 

refused
join:2005-10-10

refused

Member

thats good you got it working, but its possible to do it without creating another interface. my suggestion is basically the same idea of what you did, except using a different attribute on the radius server, and without having to create the loopback interface. just a heads up.
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to addp009

MVM

to addp009
Mind putting up your whole config please? Just for future reference?

Regards

GM85
Click, Click
join:2002-07-02
Canada

1 edit

GM85 to addp009

Member

to addp009
The way we do it is using the NAS-Port-Type

After doing a few packet captures, we noticed that the Authentication Proxy uses a X.75 as the NAS-Port-Type, and Console Access and VPN use Virtual (VPN) as the NAS-Port-Type.

We have a policy to check NAS-Port-Type X.75 to authenticate users against the Auth Proxy.

Next, we have a policy that matches Virtual (VPN) and Async (Modem). This is for connecting to the console / Telnet / SSh. As it's for the Administrators, it also checks against our "Network Admin" group. If it's a match, it returns "shell:priv-lvl=15" to Log the user in as a privilege 15 user.

The next policy checks for a NAS-Port-Type of Virtual (VPN) and checkes to see if the user as a member of our VPN group. If they are, it authenticates the user, but returns no prvilege level (so users can log in via VPN.... but they don't have any privilege to try to log into the console)

Of course this also means the administrators have VPN access too.... they just log into the VPN with a privilege level of 15 (but of course that has no meaning when logging into the VPN)