Hi daj,
Q:What might be the reason for this.
A: if it's on FortiGate and users are remote type so they do actually further authenticate for example against LDAP on MSFT AD, then usual mistake & reason is in FortiGate's case sensitivity.
In details:
- if you have ldap type user name 'johndoe' with token assigned
- and such user is member of firewall group where there is user 'jonhndoe' and actual LDAP server as members
- then when user authenticate and as user name uses 'Johndoe' (UPPERCASE j), then those 'johndoe' and 'Johndoe' are completely different users for FortiGate. But as LDAP is also member, then login process fail to find local user (the one with token) and fall back to another group member, the LDAP. And as user is LDAP type it successfully authenticate through the LDAP.
SOLUTIONs for above:
a) user FortiAuthenticator as centralized authentication back-end which can deal with case sensitivnes
b) split firewall group members and do NOT mix pure LDAP with token users, or in more advanced scenario set group match on that LDAP the way that users with the token will not be considered members anymore, so mentioned 'johndoe' either authenticate with the proper casing and token or 'He shall not pass!' .. at all.
