first of all, before I start asking stupid noob questions, I wish all of you a happy new year
Before I start asking my question, I just want u to let know, that I'm completely new to the Juniper stuff - so please excuse, if my question is a noob-one (although I didn't find anything in the knowledge base)
Currently I have an issue with an IC6500, which was bought a time ago by one of our customers to authenticate WiFi User (the current solution will be switched off soon). The goal is to authenticate WiFi User against their User Certificate and the AD Account. Unfortunately I already have some Problems with the AD authentication...
When we ran into problems, we decided to set up the solution step by step, to verify what the problem is. We also decided to start with the authentication via Web Interface, to check if the problem is with the Wireless System Communication and/or is a general one.
We currently use several Cisco APs and WLCs to associate clients. The new IC6500 will be used to check if the client has a valid client certificate and forward the User Credentials to the corporate AD Server. After successfully authentication, the client will be allowed to connect to the WLAN.
First Test - Authentication via IC6500 Webpage:
We set up the authentication via the IC6500 Webpage (SignIn page). After some tests, everything worked fine. The client Certificate was checked and the user credentials were forwarded to the corporate AD Server. So everything (e.g.. communication to the AD Server) should be fine.
Second Test - Authentication via 802.1x and WiFi:
This is, where we ran into problems. Certificate authentication didn't work at all. Authentication against the AD Server didn't work, too. But if I set up a user locally (on the IC6500) the user is authenticated and could log into the WLAN. Which in my opinion means, that the WLC / IC6500 communication is working properly.
Now, before we want to proceed with the two Factor Authentication, we want to set up just the AD Authentication. The client uses the built-in MS (MS Vista) WiFi Client. We want to use 802.1x PEAP / MSchapv2. But everytime we connect to the WLAN, the IC refuses our authentication request (internal Authentication error). According to the debug files, the "drop" comes from the AD Server.
Does anyone had had similar issue and can point me to the right direction...as written above - the communication itself with the different subsystems seems to be ok, because in one scenarios everything is working (SignIn page) and the WLC IC communication seems to be ok, too (WLAN Authentication against local IC User). It must be something with the payload of the AD Authentication from the client....
Thx in advance!
Can you post your user access log?
If your user can login through the web portal then there shouldn't be an issue with the AD server, your user access log will rule out some of the common mistakes.
You could always try setting up the AD server as an LDAP server rather than the Active Directory preset, I prefer working with AD in this way.
thx 4 your reply.
please find attached the debug files - those should be the correct ones (I'm not at the customer premises this week, but I found these debug files on my HDD).
About your remark (AD/LDAP): We tried both - the initial test (via Webpage login) was done only with ldap. So it's not 100%ly proven, that the AD is working properly (although we could see our IC6500 as AD host...so it seems to work).
2010-12-23 12:53:02 - ic - [0.0.0.0] DOMAIN\DE-66249(CLIENT_Realm-Cert - WLAN) - Primary authentication failed for DOMAIN\DE-66249/DOMAIN_AD from 00-21-6a-15-59-60
2010-12-23 12:53:02 - ic - [0.0.0.0] DOMAIN\DE-66249(CLIENT_Realm-Cert - WLAN) - Login failed using auth server DOMAIN_AD (Samba). Reason: Failed
That normally indicates that the AD server rejected the credentials and looks healthy.
The username being passed is DOMAIN\DE-66249, is that right? (particularly the domain name)
yesw - DOMAIN is correct, because I replaced the real Domain name with that one
I gonna cheeck this with the AD Group again, but I doubt that they'll find something (as said before - authenticatioin via AD is working with the SignIn page and w/o 802.1x PEAP and WLC...and I tried it several times, so there shouldn't be a problem with misstyping.
Ok, there is a setting in the sign in policy weather to pass on the domain name or remove it, you could try adjusting that.
You can check your AD is working properly by editing the server and browsing the Server Catalog, you should get a list of all the groups in the domain, if this works then there is certainly no issue with the AD server.
Does the AD server itslef show anything in the logs, like login failed?
Hi. Is there a resolution to this? I am having a similar issue except I am working with wired 802.1x authentication. MY AD server authentication is working fine when hitting the UAC via web interface. However, when doing wired 802.1x authentication with windows native supplicants (EAP-PEAP,MSCHAP-V2) it fails with the same log entry as above. OAC client with EAP-PEAP/MSCHAP-V2 also fails the same. OAC client using EAP-TTLS/EAP-JUAC works just fine.
I tried various combination of W2K3 server and W2K8 R2 server in LDAP,LDAPS, and AD server mode with the same results.
According to the log, username is not being validated at the server. Server is rejecting the username.
You can try checking strip domain name from windows username located under the Auth Servers under authentication.
Authentication -----> Auth Servers ----> <your Auth Server (AD in this case or LDAP)> Remove Domain from Windows user names?
Check the box below.
I also suggest you to check if CHAP alone works with out 802.1x Authentication.
If your client is unable to authenticate using CHAP alone on the Server, you might me missing store passwords using reverse encryption in AD password policies.
Siince, in the last post one poster reported that EAP-TTLS/EAP-JUAC works fine, I suspect this reverse passwod encryption setting to be off.
It must be enabled to perform any authentication related to MSCHAP.
Please post if this doesnt work. Let us know if it works as well
Hope it helps.
Well, this log is quite "usual" when you hit a new setup for me.
What I do usually is try to delete the IC account in AD, then recreate a new auth server in IC to force resubscription of IC in AD.
Be sure to check your NTP also, can lead to failed authentication for a few sec delay, and the displayed log would be the one seen here, no specific message from AD, just a fail.
Also, could try setting up your AD server as an LDAP auth server in IC, solved some problems sometimes.