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?
What types of clients are these?
Did not quite get the question. Are you talking about endpoints? What difference does it make?
If these are Windows clients, you could use the Windows firewall and group policy to enforce that ip traffic. Your other method looks difficult.
Well, let's say it a mix of domain and non domain devices. The filtering must be done at the network layer.
If you know the AD group of these wired devices, that would mean that you are doing wired 802.1x. The classic way to address this is to put them into a different subnet based on wired 802.1x authentication/AD group and put an ACL on that subnet to do what you want. The way you mention above could be difficult for others to troubleshoot later down the line.
EDIT: It would be good to hear if others have implemented something similar to you.
As I wrote in the initial post, it would be inpractical to make all possible access combinations. That is true for all static configurations like ACLs, CP enforcement profiles, FW security zones etc. The question about ease of DACL troubleshooting is disputable to say the least. From my point of view they are no better or worse that static ACLs. The good thing about them is that there is a single management point.
Anyway, the question was - is it possible to make it work using CP, dot1x and DACL.
I regret that this reply is quite old to the thread, but we also tried to engineer a dynamic dacl based on various matches of roles but found that there was no way to dynamicly build a dacl.
I raised a feature request on this matter in the innovation zone - https://innovate.arubanetworks.com/ideas/SEC-I-1114. If you are still interested, please vote for the idea.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.