- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Often in smaller setups where a central authentication server is not used, organizations may wish to use "Check Point Passwords" to authenticate users (also called Internal Password or FireWall-1 Password).
These passwords are limited to 8 characters or less--at least in versions prior to R80.40 (possibly with JHF).
This is by design as it's best practice to use a centrally managed authentication source (like RADIUS/TACACS+ or even AD) and "Internal Password" is more meant for demos/testing.
However, some organizations do not want to maintain a central authentication server.
However, there is a little known feature that you can use to support longer, stronger passwords without resorting to a centrally managed authentication server.
That is to define users using "OS Password" authentication.
What that tells the gateway is to authenticate to the underlying OS (in this case Gaia), which supports longer, stronger passwords.
See screenshot below:
Obviously, you don't want to give typical users access to the WebUI of Gaia to review or change the configuration.
This is where Gaia's robust Role-Based Access comes in.
You should create a role that only allows them to do one thing: change their user account password.
Which is actually an enhancement compared to Check Point Passwords
Assign that new role to users as you create them.
Screenshot of what the role looks like in the Gaia WebUI below:
The main caveat to this approach is each (physical) gateway will need to have the user defined in Gaia.
This means in a cluster, both members will need to have the user defined (unless you're using Cloning Groups).
This also means, if you have multiple gateways/clusters, end users will need to change their passwords on each gateway/cluster.
NOTE: I've only done perfunctory testing of this, and it may have some other caveats that I haven't outlined here.
I recommend thoroughly testing this before you deploy in production.
Feedback is welcome.
Edit: Added note about R80.40 supporting longer passwords.
Great tip Dameon!
Regards.
That’s a good improvement.
if you also rely on cloning groups you may have users synced between cluster members which helps to maintain them.
Very true, thus the comment I made above about Cluster Sync.
I guess I meant cloning groups...will fix
Any suggestion / recommendation on how to achieve 2FA, we have Vasco Token. Challenge/goal that the 1st factor should give Remote Users the option to change 1st password by themselves. Thank you again
Regards,
Dale
Looks like R80.40 (possibly with JHF) supports longer than 8 character "Internal Password" passwords.
Updated the original post to reflect this.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY