04-05-2017 11:59 PM
First of all I'm pretty new to ClearPass but have spent a while testing Machine Authentication (EAP PEAP) and Certificate Authentication (EAP TLS) and MAC auth, all of which work fine in the Lab.
In the productive enviroment (different AD and Clients) I am attempting machine authorization using EAP PEAP (Cert Auth will be used later)
The PCs are already joined to the Domain and can be seen within the AD.
The interfaces are configured for 802.1x authorization using 'Microsoft: Protected EAP (PEAP)', settings are only the Authentication method: 'Secured password (EAP-MSCHAP v2)' and Enable Fast Reconnect. Additional settings: Specify authentication mode: 'Computer authentication'.
The Service configured within CPPM has authentication method set to 'EAP PEAP' and as athentication source the respective AD. The applicable Roles and Policies etc. are also setup.
The AD bind works fine (we also tried changing the bind user to one with full read and write over the whole AD but this made no difference to the problem). We also confirmed that all ports between the switch and the AD are open.
This setup works fine in my Lab but at the customer site is not working, I get a MSCHAP authenticaton error:
Radius:Microsoft:MS-CHAP-Error E=691 R=1.
Can anybody here point me in the right direction, as it works fine in the Lab I feel it's probably a problem with the productive Active Directory but I have no idea as to what it may be. Any help or clues would be much appreciated, Thanks!
Solved! Go to Solution.
04-06-2017 05:09 AM
Hi Pavan, thanks for your reply. I think I found the problem and was able to replicate it in the Lab. Just to answer your question though, yes the CPPM was bound to the Domain. I could also seach the AD tree via CPPM and the CA certificate was installed.... BUT... the CPPM web server certificate had not been requested/installed. I replicated this in the Lab and had exactly the same error. After requesting and installing the Web Server certificate, authentication started working straight away. So I presume that is the problem, we thought we could get away with not installing the web server certificate straight away but it appears not...