Users in SQL not accepted, AD works.

[Alan DeKok]

On Jan 9, 2024, at 3:29 PM, it at wehle.dev wrote:
>> It's easy to set up a testing system. Or, run the same server on a different port from the command line.
> Well, that part is easy yes, but I still had to setup a second WLAN and network access to the second server which I didn't have time for yesterday, sorry. Anyway, done. :-)

  That's good.

>> The devices are doing EAP-TLS because they've been configured to do EAP-TLS.
> Alright, so what I just did: I set up a new WLAN with a new SSID. I then connected with my client (again, Windows 10) to it, without any manual configuration of the WLAN or anything; just selecting the entry in the wireless network settings. I used the credentials stored in SQL. No surprises here, it fails again.

  Why did it fail?  The FreeRADIUS debug output will tell you.

> 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 devices have no idea which database is configured for FreeRADIUS.
> Since the client doesn't handle the two usernames differently and it does not know about the database, it would be my understanding that both accounts should work iff both databases work the same way?

  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.

>> Configure the devices properly. The wiki page I linked to explains this in detail.
> I'm not configuring the devices any different when switching from one configuration to the other. Why does it work with one set of credentials and not with the other set?

  Because you need to understand how the server works before creating a complex configuration.

> My default TLS configuration uses PEAP with LetsEncrypt certificates and that worked without any issues for the last few months, so I would assume that this configuration works in general - so what is it that is changed by including the SQL module?

  The debug output will tell you what's changed.  Read it.

> Is there any difference when SQL is used rather than NTLM that could explain this?

  It depends.

> I attached the full log for the test I described above. The "********************************* Waited for 1-2 minutes" were added by me, where I waited a while; also, they separate the individual stages of the test described above?

  That wait means that the client isn't configured to know about the server CA, as I said before.  This is documented in the Wiki, at the URL I posted.  If you read it, you can fix the issue.

> I'm sorry for being so focused on the server configuration rather than the clients despite your clear recommendations, but I just do not yet understand how this is a client issue ...

  Reading the documentation and following instructions is likely to get the problem fixed.  It's also likely to explain why "client does not have the correct CA" is a client issue.

  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.

  If this isn't clear, then there's little more I can do to help.

  Alan DeKok.