Especially for BYOD, where you don't have full control over the client, you don't want to use PEAP/MSCHAPv2 as you have a big risk leaking the user's AD credentials. It's not only someone gaining access to the WLAN.
I've seen this error in some support cases and the issue is that AD rejects access to the ClearPass computer account. You may check the following:
- Make sure there are no account restrictions set in AD on the computer accounts
- Disable account expiry and password changes on the computer account from AD
- Leave the domain and join it again
And open a TAC case if this doesn't help.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------
Original Message:
Sent: Aug 11, 2025 03:41 AM
From: n0thinx
Subject: Clearpass - Active Directory Issue 0xc0000022
Hi Herman,
For laptop that already joined domain we already use EAP-TLS, but for BYOD we use EAP-PEAP.
When we use EAP-TLS, it works smooth, but when using EAP-PEAP this error happens :
All of the Clearpass can communicate with All AD Servers.
As you mention forest, are the ClearPass servers joined to different domains (in the same forest)? -> sorry i maybe gave wrong information, i mean clearpass servers join in same domain but different servers.
For the user permissions, is there any requirements for enabled ? because i use non "Administrator" account but can create Computer Account.
Original Message:
Sent: Aug 11, 2025 03:04 AM
From: Herman Robers
Subject: Clearpass - Active Directory Issue 0xc0000022
There are two different things here: the domain join and the AD Authentication source.
The domain join needed/used only for MSCHAPv2 (PEAP) authentication, and is deprecated because it's security is broken. For WLAN/802.1X you should change to EAP-TLS or TEAP (with EAP-TLS) instead if you care about security. The domain join is similar to a computer joined to the domain, and it will use any of the published domain controllers and if I'm correct it will favor the fastest responding but it may end up with an AD server far away. By setting the password servers you can steer which servers are used, but again only needed for PEAP/MSCHAPv2 authentication which is deprecated. The account that you used to join to the domain should have enough permissions to join the ClearPass to the domain (create a computer account for the ClearPass server), but after that the computer account is used and the account that you joined the account with is no used anymore.
The AD authentication source is used for authorization and typically for group membership checking. It uses LDAP (or better LDAPS over TLS) and is used for authorization, or some authentication scenarios where the cleartext password is available, for example in captive portal. The authentication source uses the servers as configured, a primary server and 1 or more backup servers, which are checked in order. The LDAP conneciton is made with the account configured in the authentication source, and it should be active and have read access into the relevant parts of the AD.
What your next step would be is to verify that the publisher and subscriber can both communicate to the required servers. And with LDAP, and Kerberos (basically: any) in case of PEAP/MSCHAPv2 (which is deprecated and should not be used).
As you mention forest, are the ClearPass servers joined to different domains (in the same forest)? In that case you should use the global catalog for the (LDAP) Authentication Source.
Because a multi-domain configuration with AD can be challening or hard to understand, you may need to work with your ClearPass partner and/or TAC to start with the correct design.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: Aug 10, 2025 08:57 AM
From: n0thinx
Subject: Clearpass - Active Directory Issue 0xc0000022
Hi All,
Currently i have an issue which is annoying for me.
So we have an setup of 2 Clearpass ( Cluster ) and 2 AD. If i check the "show domain", the output like this
Clearpass Pub -> Connect to AD in Site A
Clearpass Sub -> Connect to AD in Site B
I separate the user for join domain "clearpassadmin" user and "clearpassquery" user for authentication sources.
If i point the radius server to Clearpass Pub the connection was normal, but if i point the radius server to Clearpass Sub the connection was broken and this log appears.
Is there any people experience with this issue ? since the AD was in one forest, the clearpass was in same cluster and the username for join domain was same.
-------------------------------------------