Solved: ACS Server 4.2 Design Question - role based - is it a limitation?

willgraham · ‎08-30-2010

Currently, I have the ACS server set up like this.

An ACS group maps to an Active Direct Group in AD. For example, the ACS group ROUTER_ACCESS maps to AD group called $f(gbr)raccess. If the user tries to log into a router and he has that group in his AD profile he will be accepted and if not rejected.

If for example, I want to revoke,permit access to certain devices I can use NARS (eg accept connections from router and switch devices).

That works - however this apparently is not the best way i doing things.

The best way is have a AD group per device group.

Eg To get access to router you need the group $g(t)routers in your AD profile

To get access to switch you need the group $g(t)switch in your AD profile

Now we hit the problem - The ACS will use the first group in your AD profile to pass/fail your request.

So lets say John has group $g(t)routers and $g(t)switch in his AD profile. When he tries to login a switch, the ACS tries to use $g(t)routers because it is the first ACS AD group in his profile. Subsequently it fails, meaning the ACS will not search through multiple AD policies.

I hope this makes sense.

Anyway, I can't get it work because it keeps failing!

Nate Austin · ‎09-07-2010

Hi Will,

It is a limitation of how ACS 4.x performs operations. It defines everything based on your local user group on ACS as opposed to your AD groups - so the group mapping comes first and then everything else comes afterwards.

If you are using Radius (this does not apply to TACACS) you might be able to use the Network Access Profile functionality to override certain access. So for instance you can say if the user is in this local group but the authentication comes from a certain device type you can pass down different attributes. However in terms of blocking access, it still relies on the local group you are a member of. It can do additional LDAP group checks but I'm not sure if that will solve your problem.

ACS 5.x takes that to a new level - the entire platform is built like the Network Access Profiles - so you can make rules as granular as you'd like - ie: If you are in a specific AD group (don't need to map - we can pull the external groups) and it comes from a router then pass down one authorization set with a Pass. If it is a different AD group (or a different device type) then send a fail.

Thanks,

Nate

View solution in original post

bradleyordner · ‎09-01-2010

I also have found this to be an issue. It seems to work like an Access List...where once it matches a group it doesn't look any further.

Does anyone have this same problem, or is this design wrong?

Nate Austin · ‎09-07-2010

Hi Will,

It is a limitation of how ACS 4.x performs operations. It defines everything based on your local user group on ACS as opposed to your AD groups - so the group mapping comes first and then everything else comes afterwards.

If you are using Radius (this does not apply to TACACS) you might be able to use the Network Access Profile functionality to override certain access. So for instance you can say if the user is in this local group but the authentication comes from a certain device type you can pass down different attributes. However in terms of blocking access, it still relies on the local group you are a member of. It can do additional LDAP group checks but I'm not sure if that will solve your problem.

ACS 5.x takes that to a new level - the entire platform is built like the Network Access Profiles - so you can make rules as granular as you'd like - ie: If you are in a specific AD group (don't need to map - we can pull the external groups) and it comes from a router then pass down one authorization set with a Pass. If it is a different AD group (or a different device type) then send a fail.

Thanks,

Nate

willgraham · ‎09-07-2010

Thanks Nathaniel,

I'll upgrade to version 5.x and let you know the outcome.

Will

Nate Austin · ‎09-08-2010

Hi Will,

Well, 5.x isn't a free upgrade to 4.x. Its essentially a new product, rewritten from scratch, runs on a different OS (Linux-based instead of Windows-based), and requires a new appliance to run on. So its not something you can just upgrade to.

Thanks,

Nate

willgraham · ‎09-08-2010

That's correct - it's getting built in ESX version 4.0 VMWARE as we speak. I will start from scratch and work my way to the system we currently have.