Security

Hi all

 

 

I'm trying to figure out if there's a way to get our wifi clients to authenticate with PEAP against a stored password in a SQL database... We store their passwords in an MD5 hash in a database and I have a working query to retrieve that password. I've put an authentication source together for this and can see it's working through debug logs, so that side of things is fine.

 

However, I can't figure out how to get clients authenticating. The reason I want to use PEAP rather than a captive portal is that I want this CPPM service to test a few different authentication sources out and apply profiles based on the matching source. Those sources are AD and other RADIUS servers (which works fine).

 

I've tried a number of things... a standalone service with PAP as the method, a service with EAP-PEAP as the method and EAP-MD5 as the inner method, ... no matter what I do, I can't get clients (in particular, I'm testing with an iPhone) to authenticate at all, against an SQL database with a hashed password for the user.

 

Should there be a way to do this? At one stage, I had it working by using a Cleartext password against this SQL database, although that was a few weeks ago now and I can't remember how. But I just can't get it working with an MD5 password. I'd assume that the password, when received from the client, could simply be hashed and compared against the result from the SQL server, but I'm not an expert in 802.1x/PEAP/EAP and so there's probably a good reason this isn't working.

 

Appreciate any help!

 

Brett

According to the protocol compatibility chart here:  http://deployingradius.com/documents/protocols/compatibility.html

 MD5 will only work if the passwords are cleartext...

Just like PEAP will only work of the passwords are nt_hash or cleartext...

Thanks Colin

 

 

I was hoping there would be a way to grab the supplied password from the user and hash it before comparing with the database but I now gather that these protocols are not that simple. Will come up with an alternative!

 

Brett.

Brett,

 

Maybe someone has had the same experience and has a solution...

Were you able to figure anything out to make this work?  I am having the same issue.

Afraid not, I tried many different things. I don't totally understand what happens under the covers after a user hits "Connect" when they type their password in, but I can only assume it is instantly encrypted in some sort of irreversable manner which then cannot be hashed to compare with another hash stored in a database. I'm no cryptologist though :)

 

Brett

You'd likely need to use EAP-TTLS. PEAPv0/EAP-MSCHAPv2 relies on NTLM
hashes.

If only iOS worked natively with EAP-TTLS! :)

It does. You just need to install a network configuration profile.

Yes, when I say natively, I mean that a user can just join it without needing MDM or a visit to IT. I have 2,000 students I wanted to be able to connect by using their MD5 login, rather than a plaintext version of it I've captured from the LMS and stored in a seperate database, but for now the latter is going to have to suffice until we give all these students AD/O365 logins.

 

Major feature request: O365 (Azure AD) as an authentication source without needing something like Okta in the middle.

We support Azure AD today as part of Onboard workflows.





Short explanation: Azure AD (and G Suite and others) do not store NTLM
hashes of credentials therefore PEAPv0/EAP-MSCHAPv2 will never be supported.
PEAPv0/EAP-MSCHAPv2 is slowly dying as more modern and secure protocols take
over (which is a VERY good thing).

Understood... however, I've been using this with some success:

 

https://github.com/jimdigriz/freeradius-oauth2-perl

 

If I'm not mistaken, ClearPass is based on FreeRADIUS under the covers, so maybe a concept like this could be refined and implemented within CPPM?

You'd still need EAP-TTLS for that. Also, you now have an authentication
process that is dependent on cloud connectivity which can cause serious
issues. Another issue is that storing credentials on devices is becoming
very poor security practice.