The customer has created a test account and they have confirmed that the account is active and the password is correct but I keep getting this error: MSCHAP: AD status:Reading winbind reply failed! (0xc0000001)
I disabled this but it didn't make a difference
Wondering if anybody has seen this particular error
Is each CP server joined to the AD domain?
Yeah , it just one appliance
Like Capelli said, the physical appliance not being joined to the domain is the most common reason for that error.
Once you join it, the account used does not matter. You should attempt to remove it, and then rejoin it, if possible. I would look to see if your AD authentication source is indeed the instance that was joined to the domain.
I was able to confirm that the AD source was showing up with no issues.
Since the customer provided with a new admin account I suggested that we use the actual Admin account so went ahead and removed the CPPM from the domain and re-add it again but I am still getting the same error.
I am also able to browse
Does the AD account setup in the AD source as the bind account and/or the account used to join the domain have sufficient rights to read user account data in AD?
If there's an issue with joining the domain would I been able to complete the process and see it listed under the authentication source ?
Could it be a firewall issue on the domain controller ?
Besides using port 389 what other ports do I need ?
@cjoseph wrote:Make sure the CPPM computer account was not disabled or removed from the domain.
Let me confirm that.
You may need to open TCP 445 / 137 / 138
There is a predefined firewall ruleset in Windows Server that opens all necessary ports for AD. You can modify the scope of that ruleset for the ClearPass server IP(s)
They are going to update the firewall/antivirus ...
Removed all the firewall rules and the computer account is there as well but still now luck
I would remove it from the domain and add it back.
Golden now .
Removed it from the domain and readded it ...and just in case also rebooted clearpass and we are all set...
The firewall seem to be blocking it..
I am experiencing the same issue.
Our CPPM is currently not joined to any Active Directory domains.
However, it does have some Authentication Sources that are Active Directory domains and they are working without issue.
I am currently trying to add in a new source, but when the users attempt to authentication the same error message is generated.
I have tried few things, like adjusting the bind DN, and toggling "Allow bind using user password", as suggested here and in other posts.
I have read a few other posts in the forums about this error but can't seem to find what could be causing the issue in our case.
Any other suggestions?
Does joining the CPPM to an AD domain require a reboot?
What authentication method are you using with the new source? EAP-TLS or PEAP-MSCHAPv2?
You can join CPPM to a domain without rebooting.
Hopefully I understand correctly, but you are referring to the service portion?
Currently in my test service that has this new auth. source I have EAP-TLS and EAP-MSCHAPv2 because this service handles a couple of different scenarios of logon attempts.
That is good to know that I can join without rebooting. This might be the easiest thing I can try I guess?
If you're using MSCHAPv2, you need to have your servers joined to AD.
oh really eh?
That is probably my issue then!
Okay I will try and join the CPPM to the AD domain and see if that makes a difference.
That explains why this one doesn't work and the other AD sources work because with those we are using EAP-TLS.
Sorry, I am sure that is documented somewhere!
Thank you for your quick response. I will reply back once I have a chance to test.
Just so I am sure, is there any risk in adding the CPPM to AD?
No risks. It's best practice. It just joins like a standard computer.
as per usual your knowledge is a great help!
Will report back the results.
Should we explicitly define the name of a single domain controller in the "Domain Controller" field during the AD join wizard?
You can either do that or use the return from DNS option along with the domain name.
I tried the option 'Use Domain Controller returned by DNS query' but receive the error
Failed to join domain: failed to lookup DC info for domain '<domain name>' over
rpc: Duplicate name on network
This error is being caused by the fact that the DNS query for our domain returns multiple IP's?
In this case maybe I should target just a single Domain Controller.
I looked at the Active Directory as well to make sure there wasn't already an account that existed for the CPPM and it doesn't look like there is one.
OK, yes, just do a single DC. This is only for the domain join. The actual DCs used in authentication are defined in your authentication source.
That solved my problem.
I specified a specific domain controller and I was able to join our CPPM's.
As well now the clients auth. as expected
Thanks for all the help and sorry for all the questions!
Nice, no problem!
Just be sure to add multiple domain controllers to your authentication source with the "Backup server" option.
Yeah that is an awesome feature I was that when I was creating the source for the first time!
I have since added in 2 additional DC's as a backup. Very cool feature!
One thing I did notice with the AD auth. source is that it doesn't seem to like the FQDN of either the domain or of a specific domain controller. We ended up having to use IP's only.
Not sure if that is normal behavior or not.
It is point at the new AD DNS servers.
At first it wasn't. It was still using our old DNS servers. But we modified everything to point at the DNS of our AD servers.
We even went onto the command line of the CPPM and used nslookup to make sure everything would resolve correctly and it was working without an issue.
But for some reason when we use anything other than the IP it says that it cannot connect to the server on port 389.
I wonder if now that the CPPM is apart of the domain it will work correctly?
I should give that a try.
I was wrong.
Even after joining it doesn't let me use the FQDN.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.