Users in SQL not accepted, AD works.

[Alan DeKok]

On Jan 9, 2024, at 5:51 PM, it at wehle.dev wrote:
>> And again... reading the debug output will tell you what it's doing, and why.
> I did read it, I just do not understand every single line of it and do^Wdid not have an idea how to exactly tell it to do what I want. That's why I'm here. After all, the previous log shows:

  You don't need to understand every line.  But you've posted about 4 different debug logs, all showing the same issue.  The server sends an Access-Challenge, and... nothing.

  I've said what the fix is.

> (42) sql: Executing select query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'guest1234' ORDER BY id
> (42) sql: User found in radcheck table
> 
> So the user was found. The issue is that it continues to check for the user via ntlm_auth, which - of course - fails:
> 
> (42) mschap: ERROR: External script says: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)
> (42) mschap: ERROR: MS-CHAP2-Response is incorrect
> (42) eap_mschapv2:     [mschap] = reject

  So you configured it to run SQL *and* ntlm_auth.  That's why it's running both.

> MSCHAP fails despite(?) the data from sql being present. 

  Yes, because its ignoring the results from SQL.  And using ntlm_auth.  Because that's what it's been configured to do.

>> The debug output will tell you what's changed. Read it.
> That's what I'm trying, but it's unclear to me why mschap uses ntlm-auth after sql already succeeded and provided a Cleartext-Password:

  Because that's what it's been configured to do.

  There is nothing in the configuration which says "if there's already a password, skip the mschap module"

> Looking at the mschap config it says
> #  If ntlm_auth is configured below, then the mschap
> #  module will call ntlm_auth for every MS-CHAP
> #  authentication request.  If there is a cleartext
> #  or NT hashed password available, you can set
> #  "MS-CHAP-Use-NTLM-Auth := No" in the control items,
> #  and the mschap module will do the authentication itself,
> #  without calling ntlm_auth.
> 
> Since I ran out of ideas what else to do, I changed my config from this:
>                sql
>                mschap
> 
> To this:
>                sql
>                if (ok) {
>                        update control {
>                                MS-CHAP-Use-NTLM-Auth := "No"
>                        }
>                }
>                mschap
> 
> And that fixes it.

  Exactly.  Reading the documentation is beneficial.  This isn't about "running out of ideas", it's about carefully reading the configuration documentation.

  The issue with RADIUS is that people expect it to work like DNS "map 8.8.8.8 to dns.google."  Or DHCP "assign leases from a pool 192.168.10/24".

  Instead, it's about 1,000 times more complex.  There's certificates, passwords, databases, etc.  The DNS / DHCP way of "do something simple and it works" just doesn't apply here.  Worse, using the DNS / DHCP approach is misleading, and perhaps harmful.

>> That wait means that the client isn't configured to know about the server CA, as I said before.
> Sorry if I was unclear here, but the delay was done by me. I waited between the requests to ensure that the communication completely finished before I sent another request with a different set of credentials.

  If the server doesn't send Access-Accept or Access-Reject, then the problem is that the client is refusing to continue the conversation.  In this case, because the MS-CHAP data is wrong.

> Also, while I perfectly understand that I should use the provided scripts, that's something that we actively decided against in the past. Yes, that might be stupid and not helpful, but it was the only way to get Android to not reject our server certificate due to "certificate is self signed" (see f.e. https://community.ui.com/questions/Wifi-certificate-and-android-greater11-solution/582374d9-00f2-4ca6-9d7b-7fa0932d7513 or https://www.securew2.com/blog/android-11-server-certificate-validation-error-solution ). That's why we changed our configuration to use LetsEncrypt; I am aware that this certificate does not fulfill all requirements for certain setups, but again, I do not understand (and I seem to miss the explanation for that in the linked article) why it would work in some cases and fail in others while not changing anything within the configuration.

  The certificates from LetsEncrypt should be fine.  That isn't the issue.

  The issue is that the Android system does not (by default) trust the LetEncrypt root CA for EAP / WiFi.  So it has to be explicitly configured.

  Alan DeKok.