Users in SQL not accepted, AD works.

[it at wehle.dev]

Hi Alan,

thank you for your reply and patience with me.

> > I then did the very same thing with the credentials stored in AD. WLAN is immediately connected and everything works.
> >  I then disconnected, made the system forget the credentials and tried to connect again with the guest-credentials. Again, doesn't work.
>  I don't know what "guest credentials" are.
> 
>  And again, the FreeRADIUS debug output will tell you why the server sent an Access-Reject.
The debug output shows two sets of credentials. One of the uses a username called "guest1234", so that's what I was refering to.

>  That depends.
> 
>  If you configure FreeRADIUS to use AD, and put a user / password into AD, then a bunch of things will just work.
> 
>  OR, if you configure FreeRADIUS to use SQL, and put a user / password into SQL, then a bunch of things will just work.
> 
>  But if you configure FreeRADIUS to use *both* AD and SQL, then you also have to tell it where the user is. In most cases, a "no such user" lookup will result in failure.
> 
>  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:

(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

Also, the step before says:

(41)       [sql] = ok
...
(41) eap_mschapv2:   authenticate {
(41) mschap: Found Cleartext-Password, hashing to create NT-Password
(41) mschap: Creating challenge hash with username: guest1234
(41) mschap: Client is using MS-CHAPv2
(41) mschap: Executing: /usr/bin/ntlm_auth ...
...
(41) eap_mschapv2:     [mschap] = reject
(41) eap_mschapv2:   } # authenticate = reject
(41) eap_mschapv2: MSCHAP-Error:  E=691 R=1 C=283fd425912588c711f0aa0a90fae2e3 V=3 M=Authentication rejected
(41) eap_mschapv2: Found new challenge from MS-CHAP-Error: err=691 retry=1 challenge=283fd425912588c711f0aa0a90fae2e3
(41) eap_mschapv2: ERROR: MSCHAP Failure

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

>  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:
(41) mschap: Found Cleartext-Password, hashing to create NT-Password
(41) mschap: Creating challenge hash with username: guest1234

At this point, I assume(d) that mschap should not call ntlm_auth itself. 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.

>  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.

> This is documented in the Wiki, at the URL I posted. If you read it, you can fix the issue.
I read this document several times. But it still does not explain why the very same settings would work with ntlm_auth and not with sql. After all, the server did not even restart between using the two different credentials. And the way I understand the text ("The server certificate has to have special OIDs in it, or else the Microsoft clients will silently fail.") it should fail in BOTH cases, not just when sending it credentials that are stored in sql.

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 debug output you posted (multiple times) shows the same issue of the server waiting, the the client refusing to continue doing EAP. This isn't a server issue. The client is misconfigured.
Well, the configuration above fixed the issue and it works flawlessly on the client. So I still am not sure how my client was wrongly configured but if you could please explain this in more depth rather than pointing at the same article again, I would be really grateful as I could then try to fix my setup.

Thank you very much
Sebastian