Security

Reply
Occasional Contributor I

Security implications of ClearPass AD domain join

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!

 

Guru Elite

Re: Security implications of ClearPass AD domain join

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.


| Tim Cappalli | Aruba Security | @timcappalli | timcappalli.me |

NOTE: Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba or Hewlett Packard Enterprise.
Occasional Contributor I

Re: Security implications of ClearPass AD domain join

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.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: