username-case-sensitivity global

[Basti]

Hello, is it possible to disable remotely LDAP global sensitivity?

https://kb.fortinet.com/kb/documentLink.do?externalID=FD50400

we have a lot of user and for every user disable via cli is really crazy....

thanks in advance

[srajeswaran]

You may use some scripts to disable the option for all user. or using some text editor to edit the config file to add the additional line and then apply it.

[xsilver_FTNT]

Short intro:

-------------

LDAP is case insensitive.

RADIUS can be made case insensitive per defined server ..

config user radius

edit <RADIUS-SERVER-NAME>

set username-case-sensitive disable

end

LOCAL users on FortiOS are by default, as in any unix system, case sensitive.

Therefore  if you do have local users, like that "r1" local user in mentioned KB. Where user type is radius or ldap.

Then .. 

- if the user is just ldap type, then it makes no sense to have him as local. And I would suggest to set ldap server as member of the user group instead of such users. So FortiGate will ask directly to LDAP server which is case insensitive.

- if that user is type radius, then as stated above you have the option to make RADIUS requests case insensitive per server config. Again, having users local on FortiGate will make them case sensitive so add that server as member to user group instead of users and if you need to have those users case insensitive then apply server setting mentioned in intro.

- if that user is either of types ldap or radius, and has set two-factor ! Because there is provided some sort of 2FA (token) and required 2FA authentication. Then this user starts to have ability to 'set username-case-sensitivity'. On per user basis only. There is no global setting AFAIK.

REASONS - USUAL MISCONFIG

-----------------------------------

some admins do have user group used in VPN or policy set with members including such locally defined users, usually with two-factor set. BUT they sometimes include LDAP/RADIUS server there as additional member. Just with idea that those users without token will authenticate via LDAP member, and those with token will be forced to use it because they are members individually. Simply because local users do have precedence.

Wrong. If the local user is defined as "tester" but user types "Tester" or "teSter" as his username, then he will NOT match to local user, but as there is mentioned fallback LDAP for example, which is case insensitive, then user will authenticate just fine against server itself. Actually avoiding any 2FA usage!

That's what admin probably do not want to happen.

Solutions:

-----------

- never ever combine locally defined remote (type ldap/radius) users with remote servers in one group

- unless you truly know what you are doing and all the implications, then never ever "set all-usergroup enabled" under radius server

- if you desperately need to have users and server mixed in one group and can not avoid it, then "set username-case-sensitivity disable" to enhance match ability of FortiOS to catch local user no matter the login name letters case

CLI and crazy?

----------------

Why don't you use any reasonable text editor, even something like Microsoft's Notepad do have ability to find+replace.

So ..

show user local | grep "type ldap" -f

copy from SSH console to text editor

as it is unimportant where you will set it then ..

search for

"

set type ldap

"

and replace it with

"

set type ldap

set username-case-sensitivity disable

"

simply to add one line

apply to all suitable users

you can remove any other lines .. to prevent token re-provision for example

copy enhanced text from editor back to SSH console to overwrite actually existing users with enhanced set.

done

quick jig for few minutes, I guess

[crpb]

Hi there,

@xsilver_FTNT Thank your for that explanation.

For anyone else who has a bit _larger_ userbase and want to set an option for, say all of them, here is my oneliner i just put together for such a task from an Linux-Shell or even WSL-Shell with the option 'set ssh-public-key1 "ssh-rsa ......" set in 'config system admin' 'edit youradminuser'.

I used variables so one could easily change the option for another Firmware-Release where the command differs or even a different option like authtimeout/auth-concurrent-override/... .

I haven't tested it with a password-prompt!

export USEROPTION="set username-case-sensitivity disable" # depends on the Firmware-Release
export FILTEROPTION="set type ldap" #i used an 'set two-factor fortitoken' for my case.
ssh USERNAME@HOSTNAME -o remotecommand="show user local | grep '$FILTEROPTION' -f" |sed "s/.*config user local/config user local/" | sed '/set type ldap/,/next/{//!d}' | sed 's/^[ \t]*//g' | sed "s/set type ldap.*/$USEROPTION/g"

I separated the 'sed'-invocations so you could test the individual outputs one after another.

The first one just replaces "YOURFORTIGATENAME # config user local" to "config user local".

The second one remove all lines between 'set type ldap' and 'next'.

The third one removes all whitespaces and tabs from the beginning of each line.

The fourth replaces the 'set type ldap' with the String from `export USEROPTION` - Our Command to set for each matched User.

As a result you should get something like

```

config user local

edit "username1" set username-case-sensitivity disable next edit "username2" set username-case-sensitivity disable next ... end

```

Either copy from output or pipe ` > filename.txt` to a file for making changes/checking the output.

The only option that should also be printed is 'set status disable' if I didn't miss anything 8-).

And for Radius, just replace ldap with radius in the second and fourth sed-command.

[Altheman]

Putting all of this responsibility onto the customer is crazy. Why not make this a global option in FortiGate CLI and option in FortiManager. Even in FortiManager when creating the user you have to go to the CLI Configuration of the individual FortiGate and find the local user database and check the disable box. Is there some place we can have customers vote on this. Just use a script or use RADIUS is not an answer. Especially for those managing several FortiGates and user databases with multiple admins creating users. The time of COVID where even more workers are going remote this should be a priority for FortiGate developers.

[xsilver_FTNT]

TBH if you are admin of large FGT deployment and you are ...

- not using FortiTokens, then if you have all users defined locally on FGT and not connected FGT to some user management like AD/LDAP, then you probably do so in terribly ineffective way!

Use LDAP inside FGT as authentication server and point all firewall user group definitions to that server.

Docs:

https://docs.fortinet.com/document/fortigate/7.2.1/administration-guide/401976/ldap-servers

You can use so called "group match" feature of FortiOS to pair firewall user group with LDAP (AD for example) or even RADIUS (via AVP Fortinet-Group-Name in Access-Accept). This way you can simply manage all the group membership from LDAP/RADIUS without ever touching local user definitions of users on FGT, ever.

Docs-LDAP group match:

https://docs.fortinet.com/document/fortigate/7.2.1/administration-guide/475491/tracking-users-in-eac...

KB-RADIUS group match (older but still valid):
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Authentication-Remote-server-group-match-o...

If you use just users, and AD as user base/source, then maybe you can think of FSSO instead of manual logins through FGT, as well.

- having FortiTokens, and large FGT deployment and user base, then you might think of FortiAuthenticator. As it's centralized IAM (Identity and Access Management). Which can automatically sync users from LDAP (even AD). Automatically distribute various FortiTokens (hardware and software, for hardware it's obviously just pair to user and physical delivery of token to user is onto admin's shoulders ;) ). And then you can have users assigned to groups on AD, manage their role assignment from AD (well any LDAP as user sync uses LDAP filters), and then pair FGT via RADIUS to FortiAuthenticator, which can be set to send proper group tag to utilize above mentioned "group match" on FGT to assign user to proper group on FGT.

Docs-FortiAuthenticator:

Remote User Sync Rules: 
https://docs.fortinet.com/document/fortiauthenticator/6.4.5/administration-guide/215969/remote-user-...

LDAP for your AD/LDAP:

https://docs.fortinet.com/document/fortiauthenticator/6.4.5/administration-guide/569230/ldap

RADIUS service for connected FGT (but could be more then just FGT as RADIUS is quite generic protocol so even 3rd party can use that auth method and AD users can log there):

https://docs.fortinet.com/document/fortiauthenticator/6.4.5/administration-guide/294825/radius-servi...

So in the end there is nothing hard on user management even with case sensitivity.

Because if you point user group on FGT to LDAP, and LDAP does authentication while it is case insensitive, then you'll get what you want. Your users will authenticate regardless if they think their name is like jOhn, joHN, boB, BoB or bOb.

If you still need some tedious work on FGT, then you might consider doing the same a different way. 

Similarity to cars .. yes, you can still push the car, but it's much easier to use its engine  at full potential and drive it.

TBH I'm not the fan of case insensitive login names as I still think the users are not dumb enough, yet, to not remembering their own names. And admins can make it easier if they are, by making all usernames lowercase, or first-letter-uppercase, or something like that simple rule.

[crpb]

A few Months ago i even discovered an easy Option.

You could also Update it via the Best-Practices Scanner

https://docs.fortinet.com/document/fortigate/7.2.0/best-practices/search?q=SH09.8

Security Fabric -> Security Rating -> Security Posture

Click on the Disable "Username Sensitivity Check" and in the right pane will come an List of User's that are not configured and you can Update it with just a few Clicks.

cheers,

~crpb

[xsilver_FTNT]

Thanks crpb,

but if you have large user base directly on FGT, while your company uses AD/LDAP or any RADIUS capable IAM (Identity and Access Management) tool. Then you are probably doing it terribly ineffectively. And might be better to have users authenticated from FGT directly towards AD/LDAP/RADIUS and so firewall user groups will contain one of those IAM servers instead of tons of locally defined users.

It might be, as noted in warning, that you use FGT and local users because of 2FA and FortiTokens. And then it is must to have them locally defined, unless you are going to use FortiAuthenticator to do so for you globally. Which is the way if you do have tons of users with tokens.

So either way you should not have tons of locally defined users which needs extra care because they are unable (or dumb, or lazy) to remember case sensitive username.