I’m currently using NetworkManager to setup my wireless connections. The computer is joined to Windows AD but using a local account to login. NPA uses just the computers domain status to authenticate. The connection options are as follows:
Security: WPA2 Ent
Auth: PEAP
Inner Auth: MSCHAPv2
PEAP Version: auto
Username: My AD account
Password: My AD account
Cert: Filled in
When trying to connect I see the request from the RADIUS client on the AP but get an error code of 265 with the reason being *The certificate chain was issued by an authority that is not trusted.
*
Any idea what I could be missing here?
Login with your Windows Domain User account and try again…
By being logged in with a Domain User account, you should then be automatically set up to trust whatever CA is being used.
We are using the computers as displays in our lunchroom so we initially set them up with a local account. It wasn’t until after the initial configuration we decided to change routes and have them authenticate with NPA.
Same error after logging in and trying to connect on my AD account.
First, I’m not sure what NPA authentication is…
It might be my Googling skills, but I don’t seem to be getting any search results…
Before going any further, I’d recommend you double-check whether your RADIUS server is authenticating by username/password, certificate, something else or a combination. I’d hate to go too much further recommending steps without knowing <for sure> what your wireless is using for authentication.
So, for example if you have any Windows machines set up successfully then try to understand how those boxes are authenticating because something similar would be set up on your openSUSE.
One of the things about Linux as hosts in an AD Domain is that you can and should add them to the Domain, but they don’t become fully members of the Domain hosts like Windows machines… After all, you should never be able to manage a Linux box using Domain policy the same way you would be able to manage a Windows box (at least, by default. There are 3rd party solutions that install extensions that allow you do that, and if necessary or if you wish you should look into those. A few are free/open source but others are commercial). I would <expect> that if you used YaST to add your openSUSE to the Domain, that would be sufficient to solve your problems (You might need to connect temporarily using a non-802.1x connection to do this).
Once joined to the Domain, you <must> then login with a Domain User account, not a local user account on your openSUSE unless you configure your network connection to use its own credentials.
If adding your openSUSE to the Windows Domain won’t solve your 802.1x problem, then you can try the suggestions/methods suggested in the last post of that arstechnica forum thread.
I started playing with the policy to see if I could get anywhere with that. Looks like NPS doesn’t reconize it as a domain computer thus denying access. I setup a policy to auth on AD credentials and so far that seems to work. For now I guess it is what it is. Thank you for the help!
