ACS v5.5 authorization rules 320 limit

[rfitheridge]

I am about embark on a large service provider ACS migration / installation and I suspect I am going to need more than 320 authorization rules, which is the limit stated in ACS v5.5 release notes.

Is the limit for the maximum number of rules for an Access Service, or for the ACS totally?

[jrabinow]

Why do you think you will require so many rules?

Can you give details on the nature of the rules so can see if there is any other way to achieve this

[rfitheridge]

Hi jrabinow,

This is for a service provider for TACACS device admin.  I know there are 1200+ device groups one for each customer, and I am suspecting that a large number of the customers will have a user group with permission to their device group.  Hence needing more than 320 authorization rules.

I can see a way forward if I split the devices groups up, I could then use multiple access services to be able to use less than 320 rules per access service.

I am just not clear if the authorization rules limitation is system wide or per access service.

[mohanak]

The limitation is for total acs

http://www.cisco.com/c/en/us/td/docs/net_mgmt/cisco_secure_access_control_system/5-5/release/notes/acs_55_rn.html#90057

Table 13 Limitations in ACS Deployments

Object Type	ACS System Limits
ACS Instances	22
Hosts	150,000
Identity Groups	1,000
Active Directory Group Retrieval	1,500
Network Devices	100,000
Network Device Groups	12
Device Hierarchies	6
All Locations	10,000
All Device Types	350
Services	25
Authorization Rules	320
Conditions	8
Authorization Profile	600
Service Selection Policy (SSP)	50
Network Conditions (NARs)	3,000
ACS Admins	50
	9 static roles
dACLs	600 dACL with 100 ACEs each

[rfitheridge]

I questioned it partly because the release notes did not prepend Authorization Rules with 'All'; whereas Locations and Device Types do.

Any ideas how to get lets say 500 user groups to be able to only access their own (one of 1200+) device groups?

[cmaitland]

It appears we are running into this same issue.  Did you ever find a solution?  We are migrating from 4.2 to 5.x and have 400+ user groups in our current ACS instance.  Meaning 400+ different customers need access to their own devices only.  I see no way to do this unless we can either raise this limit, or have a better mechanism (regex NDG to user group mappings).  If someone has some advice, can they please post.  Thanks!

[rfitheridge]

Hello cmaitland,

the key is the results.  The amount of different results pretty much governs the amount of rules needed. If the user groups have the same results say CmdAuthSetReadOnly, all of your customers can go in a single rule.  To do it in the Access Rule use this style of boolean in a Compound Condition.

(

(IdentityGroup:Cust-A AND NDG:Cust-A)

OR

(IdentityGroup:Cust-B AND NDG:Cust-B)

OR

(IdentityGroup:Cust-C AND NDG:Cust-C)

)

Result = CmdAuthSetReadOnly

Hope that helps

[cmaitland]

How many compound conditions could you set?  This seems equally unmanageable and i'm getting an error when I tried more than 5 ORs like you mentioned.

[rfitheridge]

I have over 20 identity groups /customers in one compound condition, some with one NDG and some with two or three. I have observed no limit.  No errors. ACS v5.5.

rossf

[cmaitland]

Thanks for all your input.  Apparently after the first batch of adds (3 in my case), I can't do another bulk add.  I went back through one at a time and was able to add more customers, but not more than one (NDG and Group) at a time.

[rfitheridge]

As the rule editor is a pig.  The way I found that was most time efficient was to add all of the OR statements (Identity Groups), then add all of the AND statements (NDG) to each Identity Group.

What version are you on - just so I know to avoid it?

[cmaitland]

We are deploying 5.6 since this is a new instance.  I haven't tested it yet on 5.5, but we also have that instance for a smaller one where we didn't have to worry about the rule limitations.  I also found that was the best way to do it when I generated a new rule.  It took me some time to figure out where to click using the other method when adding new statements so they stayed flat instead of "treeing".

I'm also a little perplexed as to how this works but somehow it does.  I still think it's going to be unmanageable for us though, as 80+ customers need enable and about 300+ need read-only.  Pretty sure that will make these rules a disaster as well any way I implement it.

I'll post again if I get any feedback from our Cisco team.

[sekhabbaz]

The limit of 320 is not hardcoded, its whats recommended by Cisco.

How ever i suggest you gladly follow it :D 

Using a VM with 4 CPU , 8gb RAM and 750gb drive i tested some of ACS limits.  
When u pass 300 each Authorisation profile save will take up to 5 min and GUI will get a little slower. 
At 500 profiles each save will take up to 10 min. Considering that this was without any load towards the ACS server, things can only get worse :P . 

How many complex profiles did u end up with and how many compound conditions were u able to squeeze into them ? 

Question is: Will the 320 limit be the same with more complex profiles  ? 

[rfitheridge]

I ended up with a system with 120 rules, 6 rules with Compound conditions, one of those rules has 125 conditions.       (42 seconds to save.)

Once I got over 80 rules, I found the GUI to be slow loading the screen and saving.

So not a hard limitation, that's interesting.  Of course you run into issues if you need support and you have a system that is built exceeding the system limits.

[sekhabbaz]

Hi rfitheridge!
Impresive, i found the small condition window to be anoying enough to make me stop at 20 compound conditions.

Can you confirm that you are able to edit a condition in the midle of the 125 without ACS messing up the order or stability issues ?

Also, does the 125ith condition have any noticeble delay in auth response ?

Thx for the reply ! :)