Security

Hi

We are deploying an instant solution on several schools and the teacher's SSID has 802.1x authentication to a remote radius server.

We've been testing using a domain user and non-domain computers, some of the tests work but most of them don't and checking the radius server logs i found that the reason to refuse the authentication is error code 265 which is "The certificate that the user or client computer provided to NPS as proof of identity chains to an enterprise root certification authority that is not trusted by the NPS server". Nonetheless when we do tests with an android phone it works everytime.

We are not using certificates on the server and the clients are configured not to validate them. I'm sure is not a configuration problem in the radius server because i do a similar test in the management center (where the server is) with my non-domain pc (and APs from another brand) and works everytime.

What can i do to diagnose the cause of this problem since we are not using certificates? I upload the reject event to se if there's anything else there i haven't seen.

Thanks.

Attachment(s)

log.txt   1 KB 1 version

Anybody has any idea about what could be happening?

Thanks for your help.

which radius server are you using?

are you using windows clients? how have you setup their dot1x credentials. you might without wanting to have them setup to send a certificate instead of a username. are they set to EAP (PEAP) and not smartcard or other certificate?

Hi

Thanks for your reply, yes I'm using windows clients and as far as i can see they're properly setup with the same parameters as my laptop (which is authenticating without problem).

I attach an image of such parameters, sorry it's in spanish but you can see i haven't setup credentials.

Thanks for your help.

If you go to "Configure" next to Microsoft: Protected EAP, is it set to MS-CHAPv2?

Hi cappalli

Yes it's set to MS-CHAPv2 as you can see here

ok, so your laptop with these settings is working fine, but the domain computers aren't?

i would really have a good look at the settings then, is it possible they use different settings in practice or ....?

and compare the NPS logs, does your succesful attempt and their failed attempt hit the same services?

The computers used in the tests aren't in the domain either...but i can't understand why my laptop works everytime and the others just sometimes (the configuration is exactly the same).

I checked the logs and the difference between a succesful attempt and a failed one are these sentences in the access-request event:

<EAP-Friendly-Name data_type="1">Microsoft: Secured password (EAP-MSCHAP v2)</EAP-Friendly-Name>
<MS-Extended-Quarantine-State data_type="0">0</MS-Extended-Quarantine-State>

Also i have noticed that sometimes the authentication-type in the events sometimes is 11 (PEAP) sometimes 5 (EAP) and sometimes 4 (MSCHAP v2), but i haven't seen a link between this and failures because i've seen successful attemps with both 11 and 4. I believe the appearance of type 4 is because i had a network policy like the one in the attached picture.....to test if this affectede something i removed MSCHAP v2 from the EAP method but the problem is still there.

Thanks for your help

if the config is really the same and sometimes it works and sometimes not im pretty much out of ideas.

you could do packet captures and try to find an issue from there, but that will be complicated im afraid. it might be worth it just to check if you see something different, perhaps another system involved or ...?

a little Aruba promo: this is the reason I hate NPS and love Aruba ClearPass, with ClearPass the reason why would (most likely) be clear and with NPS you get into a situation where you are stuck and unable to find a cause.

Thanks for your help.

I'm a bit puzzled by the fact that the authentication type changes between 11 and 4, and both present succes events during trials and failure just for type 11. (I determined type 5 was present during a test i did so it's not important).

What could be the reason for this?

i believe that is related to the fact that you are using both PEAP and MSCHAPv2 to do authentication. so it might be logical you see both in the logs, can you see the combination together (after each other or such)?

is the NPS server used by others or can you really do a single request determine the related logs and do that for both a good and bad request? might be worth it do that and share those. with NPS it is useful to check both the NPS log and the event logs.

do you have multiple services on the NPS server?

I haven't found a combination of both types in a single authentication process for a device. Nonetheless i have seen one device send a request using type 4 and the next one with type 11.

I can't do a single request, the server is been used in the whole organization and multiple requests happen per second. I've checked the event viewer but the only events i found there are requests from non-authorized clients and warnings when the server can't connect to the domain controller.

There aren't any other services in this server, active directory is in a different one.

I upload a succesful and a failed log both with auth-type 11.

Attachment(s)

Fail.txt   2 KB 1 version

Success.txt   3 KB 1 version

did you just search for those two? because they seem from different radius clients (APs? controllers?). are the settings on that side the same?

Yes, they are from different virtual controllers but configurations are
exactly the same. When I mean successful and failed attempts they're not
necessarily from the same virtual controller but they should behave in the
same way.

they should behave the same way, but they don't. if you compare them you see differences beyond the 265 result.

why would that be the case? i would focus on getting a succesful and failed auth in a controllered method and preferably on the same AP / VC and comparing those.

Well looks like we finally managed to make it work, and that the authentication type is always 4 (MSCHAPv2), which is the one that always works.....the workaround was no other than to configure the windows PC to validate certificates from the default trusted CAs and enable termination on the instant solution.

Even though i'll keep looking for a reason why those PCs didn't work without certificates and mine does, the NPS server was never setup to use them and there is not even a CA enabled in it or in the domain server.

ok, that is good for you.

enabling termination on the AP is an intereseting step. have you ever checked the MSCHAPv2 settings on the NPS server. it might be there is no certificate available to do start the PEAP session. but still i can't understand why it would work on some and not on others with the same settings.

can't really imagine that trusting the server cert would allow access where it didn't before.