I assume the FortiGate is directly talking to the LDAP to authenticate the users, is that right? (i.e. this is not going through FAC)
If so, which authentication method are the wireless clients configured to use? Realistically speaking, only EAP-TTLS with PAP inside is expected to work (try it if you haven't yet! :) ).
MSCHAPv2 based methods, such as EAP-PEAP are unlikely to work, since they require the LDAP server to be willing to give the user's plaintext password, or its NT-Hash, to the FortiGate (this is the limitation the KB article you linked alludes to). MS AD LDAP is known to never allow this under any circumstances, and I would hope that your OpenLDAP variant also is not willing to give out such sensitive information.
I didn't try to EAP-TLLS with PAP.. normally I tried with the default method EAP_PEAP .. Tomorrow I will try :) I hope work .. my only problems is with iPhone iOS that I don't know if can I change between MSCHAPv2 to PAP.. will see..
You can either try to figure out how to force those Apple clients to request EAP-TTLS(PAP) (seems like some MDM settings do exist for it), or you will have to go back to RADIUS and EAP-PEAP(MSCHAPv2).
As far as FortiAuthenticator goes, it by default has the exact same limitation. When utilizing a general remote LDAP server as the user back-end, only EAP-TTLS(PAP) is assured to work.
It can support MSCHAPv2 (~> PEAP), but this is implemented by joining the FAC to the Windows AD domain (so unlikely to be relevant to your OpenLDAP environment), which allows it to verify the MSCHAPv2 credentials provided by the supplicant through SMB-based communication to the domain controller.
The crux of the issue is that the LDAP protocol does not support MSCHAPv2 authentication. As a consequence any originally EAP or RADIUS authentication that then proxies further to LDAP has to deal with, or avoid, this limitation in one way or another, as it is not possible to translate the MSCHAPv2 payloads into a usable LDAP bindRequest.