Security

last person joined: 7 hours ago 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

DACL and AD user groups

This thread has been viewed 0 times
  • 1.  DACL and AD user groups

    Posted Dec 13, 2018 03:46 AM

    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?



  • 2.  RE: DACL and AD user groups

    EMPLOYEE
    Posted Dec 13, 2018 06:24 AM

    What types of clients are these?



  • 3.  RE: DACL and AD user groups

    Posted Dec 13, 2018 06:30 AM

    Did not quite get the question. Are you talking about endpoints? What difference does it make?



  • 4.  RE: DACL and AD user groups

    EMPLOYEE
    Posted Dec 13, 2018 06:45 AM

    If these are Windows clients, you could use the Windows firewall and group policy to enforce that ip traffic.  Your other method looks difficult.



  • 5.  RE: DACL and AD user groups

    Posted Dec 13, 2018 07:22 AM

    Well, let's say it a mix of domain and non domain devices. The filtering must be done at the network layer.



  • 6.  RE: DACL and AD user groups

    EMPLOYEE
    Posted Dec 13, 2018 07:48 AM

    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.

     

     



  • 7.  RE: DACL and AD user groups

    Posted Dec 13, 2018 08:08 AM

    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.



  • 8.  RE: DACL and AD user groups

    Posted Jul 28, 2019 05:03 AM

    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.



  • 9.  RE: DACL and AD user groups

    Posted Jul 28, 2019 05:23 AM

    Hi,

     

    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.

     

    Aivars