Security

 View Only
last person joined: 21 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

Security implications of ClearPass AD domain join

This thread has been viewed 2 times
  • 1.  Security implications of ClearPass AD domain join

    Posted Dec 18, 2018 07:39 PM

    My customer has ClearPass in a Protected security zone and wishes to add an AD domain in lower security Corp zone as an authentication source. The customer prefers to do this via LDAP only because they feel that by joining ClearPass to Corp domain will expose the Protected domain (or ClearPass itself) to unauthorised access or attack from the lower security zone. The basis for this concern comes from the "domain join" concept. As we know, when a Windows workstation joins a domain, that workstation is now managed by the domain, e.g. domain admins have full admin access to the workstation. Clearly we would not want to do this.

    I am aware (and have confirmed in testing) that using LDAP only, will not support MSCHAP based authentications such as EAP-PEAP, hence the desire to do domain join. In order to address the customer's security concerns, I am seeking a clear explanation of exactly what ClearPass "domain join" actually means, addressing;

    a) Does it confer any rights or access by the domain (e.g. domain admins) to ClearPass?

    c) Does it expose ClearPass (or the higher security zone in which is sits) to any attack vector?

    c) Are the protocols/ports required through the firewall all initiated from the ClearPass (high) side, i.e. no low to high rules?

    d) Is joining ClearPass in a "high" zone to a domain in a "low" zone considered good security practise (compared to LDAP only)

    e) Can you provide some insight into actually what is going on when ClearPass "joins" a domain, if it's not becoing "part of the domain" in the sense that the domain manages it, then some technical explanation of how/why it is different.

     

    And a related question..

    A possible workaround has been suggested of directing AD auths via NPS RADIUS instead of directly to AD. This is not an option I prefer due to the added overhead of configuring and maintining an extra server in the authentication chain, however I would like to understand if this imposes any further limitations on the solution. For example, does ClearPass support additional policy features using a AD authentication source that are not supported using RADIUS authentication source, or does it make not difference?

    Thanks!

     



  • 2.  RE: Security implications of ClearPass AD domain join

    EMPLOYEE
    Posted Dec 18, 2018 07:49 PM

    We generally don't recommend you use legacy EAP methods like PEAP. Strong methods like EAP-TLS should be used.

     

    That being said, here's the answers to your questions:

    a) No, it joins as a computer account like any other machine

    b) No different from any other client device joined to the domain

    c) ClearPass initiates the sessions

    d) Not sure we can make that judgement for you

    e) The process is no different than a Windows machine joining the domain. There are various Microsoft articles floating around that cover this.

     

    I don't see any security value in proxying to NPS vs direct from ClearPass.



  • 3.  RE: Security implications of ClearPass AD domain join

    Posted Jan 06, 2019 05:30 PM

    Thanks for taking the time to reply. Re your answer (b) that a ClearPass server when joined to a Windows domain is "no different than any other client device joined to the domain". This effectively rules out the proposed solution as we do not want the joined device to be managed by or exposed to any possible access from the domain to which it is joined.