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

ClearPass EAP-PEAP 6.9.9 Certificates & Its Domain Relationship

This thread has been viewed 18 times
  • 1.  ClearPass EAP-PEAP 6.9.9 Certificates & Its Domain Relationship

    Posted May 25, 2022 06:25 PM

    Dear all,

    After reading this clearpass Certificates 101 from our dear Danny, I have quite a lot to ask:
    1. Is there any updated version of Certificates 101 for 6.9.x and above ?
    2. What are the parameters that I should match between AD and clearpass, to be able to generate a proper ClearPass server certificates ?
    3. In EAP-PEAP setup, should I also 'ask' the customer's existing AD to sign the clearpass-generated CSR ? But actually my customer doesnt have CA at the moment. What should I better do ? Should I go with just a self-signed ?
    4. And at the first place, should the clearpass joined to the customer's domain (whose users coming from those domains) ?
    5. Lastly, how should I generate a database and HTTPS server cert for the sake of being able to NOT use -V option when Making Subscriber ? Because I was not able to perform the make subscriber without the -V option, and with -V option I was able to do it successfully.

    Ok, back to the questions:
    - One is, is there an updated version of 6.9.x above ? Because as we all have been deploying, there are 4 type of server certificates that we can generate now, instead of 2 as of 6.3.x.
    - Particularly to my deployment case, I always kinda have this issue of "AD status: {Device Timeout}" with %hs something something, which I was able to resolve by disjoin and rejoining back the clearpass to our customer's domain.
    - For my clearpass, I generate self-signed cert to all four kind of cert that 6.9.x now supports. We have EAP-PEAP deployment, which I don't think we need a CA to sign the cert. In the endpoint itself, existing, the adapter does not have the "Verify server cert" option checked. The fact that with this kind of setup it is working in other institutions in the same cluster, makes me more convinced that it will work consistently as well in my new setup. Which now I honestly doubt.
    - I have just changed the clearpass DNS to a newly setup local AD derived from their AD in the WAN, and then I encounter this "AD status: {Device Timeout}" again. Last time around, I started facing this issue probably because:
    a) I join clearpass to domain first, then
    b) I generated a new server cert.
    c) The issue then solved after I disjoin and rejoining back to domain.
    d) This makes me believe that the self-signed cert is actually also used in EAP-PEAP authentication although in the endpoint, the "Verify server cert" is unchecked.
    - But now, it does not work again after changing the DNS IP in clearpass. FYI, their AD also acts as DNS server.
    - So, with all that info, what actually should I check in the AD so I can follow the same parameters to generate a proper cert ? Because now, I dont know until what extent this setup will work consistently.

  • 2.  RE: ClearPass EAP-PEAP 6.9.9 Certificates & Its Domain Relationship

    Posted May 26, 2022 08:03 AM
    I will let Danny answer, but here are my guesses:'

    If you are using EAP-PEAP and are using a domain, you should have an enterprise CA installed.  This would mean that any server certificate that your CA generates would be trusted by all of your domain clients.  ClearPass would generate a CSR and your domain CA would use that to create a radius server ceritifcate.
    A HTTPs certificate, on the other hand for guest traffic should be signed by a public CA that is trusted by all clients, because those are not part of your domain and do not trust it.  Lately, IOS devices will not attach to guest networks successfully if the https certificate is not generated by a public certificate authority that it has not trusted:

    Long Story short:
    - You need a radius server certificate generated by your domain CA on ClearPass, so that your domain clients will automatically trust it for EAP-PEAP.  The better security posture is to move on from EAP-PEAP to EAP-TLS which is more secure and easy to distribute to domain clients using autoenrollment
    - You need a public https server certificate for your controller and for clearpass so that IOS devices will connect to your guest network without issues.
    - Joining the domain is only necessary for EAP-PEAP to authenticate the username/password combination for users.  If you move on to EAP-TLS, you will not need to do this:  user devices will use domain-distributed certificates and then look up AD group membership via LDAP.

    I hope any of that even helps.

    Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    HPE Design and Deploy Guides:

  • 3.  RE: ClearPass EAP-PEAP 6.9.9 Certificates & Its Domain Relationship

    Posted Jun 12, 2022 11:31 PM
      |   view attached
    Hi Colin and All,

    I would like to update you that my issue on this has been solved by allowing TCP-UDP/135 port between the clearpass and the AD.
    • It says "UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations."

    • My issue again at the first place:
    • Alerts tab shows "AD status Device Timeout The Specified I/O operation on %hs was not completed before the time-out period"
    • Persistent and obvious symptom: When doing "show domain" in clearpass CLI, (since my authentication = EAP-PEAP and clearpass servers joined to domain) it takes intermittently looong time to show and the domain sometimes shows OFFLINE sometimes shows ONLINE (but sometimes it also can be quickly showing). My colleague googled the internet by searching for the error message and found the TCP-UDP/135 needs to open. When we tried opening it, this "show domain" output starts to take instantly to show.
    It is somehow unfortunate that in the Port Requirements.pdf (attached), it does not show anywhere that this port TCP-UDP/135 is required.

    I need to tell you guys that our customer's AD setup are like multi-layered, they have local and WAN domain controllers. We dont know what ports they opened at the WAN side, but we can control what we can open at the local side. Once we open this port 135 to the Domain Controller @ WAN side, it starts to work, but when opening only to the local side, it's still not working (seem not enough, still need to open to WAN side).

    I dont know how AD DC mechanism works.... but.... in the end, it seems that this 135 port is lacking in your Port Requirements document. Or is it actually the "WMI scan" row equal to this issue ?

    Anyone knows how and when this 135 is taking into account during the authentication would be so much appreciated so we all can improve (I guess).​
    And how it works in a multi-layered domain structure. (it is not parent-child, the local just replicating what it has in WAN side).


    Port Requirements.pdf   297 KB 1 version