I have an open TAC case on the topic for more than a month without any tangible progress and my known contacts in Aruba are not responding to my e-mails, so as a last resort I am reaching out to the community for help.
I have a similar CP configuration request from 2 different customers. I have been asked to provide the solution to limit the user access to the services/servers in the same vlan. If I would design the networks, there would not be a problem like this, but at least for now things are as they are.
Servers are scattered thru out the subnet and their IPs cannot be summarized. The customer wants to selectively (a la carte) define server availability to particular user(s). We are talking about ~10 servers. The preferable way of user classification is by assigning users to different AD groups – a group membership means access permit to 1 particular server.
My first choice is to do radius access lists (DACL) from Clearpass to access switches. The problem is that all the possible ACL entree combinations will make too many profiles to be manageable. The answer to that would be to “compile” ACLs on the fly, including proper lines or permits/denys in one profile. The question is – how to achieve it?
At first, I tried to use multiple enforcement profiles, each containing a single ACL line in the enforcement policy rules. The problem is that only one - first profile, containing filter-rules, is used by Clearpass. The rest profiles show up in access tracker summary but attributes are never sent. According to TAC this is expected and by design.
I can use unused attributes on the domain controller and assign permit/deny statements and use these later on in DACLs, however from the admin point of view, this is not the best way of managing user rights.
I also tried to convert AD member of authorization attribute value to multiple other attributes (permit/deny) by making SQL authorization source to internal CP DB but it does not work. It seems that it is impossible to use authorization attributes in such query. I can use attributes from radius request, but from AD. From my point of view looks like one possible attribute calculation step is missing.
Any ideas is this even possible and how?