Skip to main content
Fortilover
Explorer III
July 16, 2026
Question

Authentication errors against WiFi (WPA3 Enterprise Only) with LDAP Servers (LDAPS connection)

  • July 16, 2026
  • 3 replies
  • 94 views

Dear Fortinet Community.

We have a small problem reagrding the authentication for WiFi against ldap. To be honest we have 2 problems and found workarounds that lead us to new problems. And at the moment I get a bit crazy and now I thought. Come back to my professional frieds in the fortinet community as they always have good hints to solve all the issues we have faced in the past.

But first of all the environment we have for you:

Firewall: Fortigate 401F (Version: 7.4.12)
WiFi: WPA 3 Enterprise Only
WiFi Access Points: FortiAP 231G (Version 7.4.7 0802) & FortiAP 2314G (Version newest... have not installed it yet)
Authentication: WPA 3 Enterprise Only against LDAP with ldaps (two methods. 1. With user on firewall or with remote ldap group)
LDAP Server: connected via LDAPS using userPrincipalName

What was the first problem?

1) The ldap does not answered fast enough.
So we tried to change global parameters like remoteauthtimeout to 30 and ldapconntimeout to 5000
We see that the WiFi connection searched longer under Windows 11. So we see something changed but at the end it did not work good enough. We see authentication errors and believe me... we type in the password correct. :)

2) The Authentication does not work if the person has a special character like an "ö" in its password.
This is a thing we can assure to 100%. As long as the user account has an ö in its password the authentication will not work

What did we do?

1) We tried to store the useraccount directly on the firewall.
2) We have used a remote group in the AD

The ldap server is configured like we use it for SSL VPN. In SSL VPN the authentication works perfectly fine. Even with MultiFactor.
But when I try to connect to WiFi we experience errors. In the current situation we have the user locally and locally saved via LDAPS connected LDAP Servers. With both situations we experience authentication errors. We then found out that it works if we change the password to not use special characters like an ö. A # works.

What is really interesting is the fact that we do not have this issue when authentication in SSL VPN via Web or Tunnel Mode. Here we can use LDAP users that have a special character like an ö.

So lets make it short. We have problems with authentication against WPA 3 Enterprise only WiFi when there is an ö in the password.
No matter if locally stored users from LDAP or by using a remote group in the ldap.
We use as clients windows 11 newest version. We use newest drivers. we use newest DELL Laptops.

So do you have any hints for us? Any ideas to solve the authentication issues?

This scenario is what I would like to use.

1) Windows 11 newest DELL Laptop (DELL Pro 16 Plus)
2) Authentication against LDAP with LDAPS using userPincipalName (works if I test it in the LDAP Server configuration even with ö in the password)
3) Using WPA 3 Enterprise Only
4) Using WIDS profile (default)
5) Using SSID in manual mode (Operation profile)
6) Using DTLS policy DTLS
7) Using WiFi certificate (Fortinet_WiFi)
8) Using WiFi CA certificate (Fortinet_WiFI_CA)

...

We have read a lot of things in the forum and the internet about that issue. I can tell you that it seems to be connected to special characters in the password. But this problem does not occure in SSL VPN authentication with the same LDAP Server and so on. Does anyone know what is the problem? We have read, it could be a UTF8 thingy... But I could not find a paramter for that in the configuration even on CLI.

Any suggestion or help would be much appreciated.

With kindest Regards
FortiLover

3 replies

AEK
SuperUser
SuperUser
July 16, 2026

Hello FortiLover

Regarding Q2 it reminds me an issue that I had 2Y before on FAC, with a user having “ç” character in his id.

Regarding WiFi authentication, I’m not aware about such issue if you use RADIUS (e.g. Windows NPS). This is actually the first time I see LDAP(S) used as backend authentication for WiFi.

 

AEK
Fortilover
Explorer III
July 17, 2026

Hi @AEK.

Thank you very very much for reply.

To be honest... We have got the hints to use the LDAP authentication from our supplier and consultants. And after some test (around 3-4 weeks with only one account... it was mine) we thought it worked well :) But after the first roll out in the testphase we have been confronted with several issues we could not explain... Like described before we are to 90% sure that it is related to 2 problems. 

1) UTF thingys
2) Windows OS. 

New findings since yesterday: What we have seen yesterday is the fact that the authentication with an ö in the password works on android devices. But android devices have other problems windows don't have :) Android devices don't like @ in the username :) So all in all I think the Fortigate is a bit buggy at this point and I wish this will be checked again for future feature releases. 
When I see that the GUI in the fortigate give me the opportunity to use a group with users, that could be related to AD, I like to use the option... :) So it is a homogeneous construct like it is used for SSL VPN.

Yeah what shall I say :) We will sit together in the team again and will see what will be the future in WiFi for us. Probably we use just locally created users because this works fine I would say... But all in all I think and it is no front to say: The FortiOS is buggy as hell at this point :)

If anyone else has been confronted with such issues or has some clever tips for us it would be much much appreciated :)

With kindest Regards
FortiLover

New Member
July 17, 2026

We experienced something similar with enterprise Wi-Fi authentication, although our issue wasn't related to special characters. Since SSL VPN works correctly with the same LDAP server, iptv it really points to the wireless authentication path rather than LDAP itself. I'd be interested to know whether switching to a RADIUS backend completely avoids this behavior.

Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.
Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!