1: it supplies an alternative approach for MFA ( username user.cert and optionally a password )
2: no need to roll out a big MFA token soultion
3: it allows you to restrict a user.cert and profile for system admin logins
4: provides an option to lock down users from accessing a FGT to only just HTTPS but this still access via SSH for other users ( a PKI user can not access a fortigate via SSH )
5: works great if you have an existing PKI structure and have no restrictions for sign user.certificates
6: you could pre-sign users certificates for a future date and duration and revoke users access
Here's the summary steps of the deployment for pki-users deployments fortigates.
1: upload the CAroot for the user.certificates that will be sign ( very important the CAroot certificate(s) must be installed on the fortigates they will access )
note: you can have multiple CAroot-certificates install, but the root.certificate needs to be upload into the local fortigate CA storage. You might have multiple CAs that signs various users certificates or foreign CAs that you most import as required.
see this diagram of a approach for Enterprise and Contractor or Vendor, where you have multiple CAs that issues user.certificate for various roles , each users could have a unique role ( access profile for that user )
2: sign the user(s) certificates against the CAroot/key or have the user obtain a signed certificate.
3: issues certificates to the system-admin users and profile and grant accessprofiles
4: The user needs to import the cert+key into it's OS user.certificate list , typically this is in a pkcs format ( macosx, windows, must browsers, etc....)
5: The fortigate need a user-peer defined with just at minimum the CAroot-CAcertificate selected and optionally you can apply the CN and SUBJ fields to that PKI user peer details to scrutinize the user.certificates even more.
6: next you need need a user-group set for "firewall" with the pki peers added
7: finally you set the system-admin user names in the fortigate and set the define mode as peer-auth and the peer-group.
Here's a few snapshots of the above actions;
{ defining my pki details;
cn with 2nd factor password required ( optional but advise ) }
You can also defined more grainular the subject details from the certificate also;
TIP: use openssl x509 and the -subject to find the subject details
{ peer-group }
{ cli cfg details for my user }
or
with IE select the correct certificate to present;
Now we login via the HTTPS webgui and present the certificate and 2nd factor password if applied and if you did everything correctly you should be logged in
Using this approach, you could give your remote_contractors a user.certificate or have him supply his own certificate and you upload the CAroot for his user.certificate.issuer
If you control the user.certificate from your own CA signing structure, you could sign a user.certificate for duration XYZ , and never have to worry about restricting access a future date.
You could even sign a certificate for a future date and duration, and pre-issue access for a set of users and known that they can't access the systems until the date is valid. This is great when working with outside consultants or technology partners that needs access for projects.
If a certificate is compromised you can pre-empt the access and revoke the certificate /remove the pki user/ or CAroot.crt as an option.
Try to keep your own certificate simple. You subject field could only contain a CN only
e.g
Use the cli cmd debug application https -1 to troubleshoot the login process via WebGUI
If the status response is "1" than you have successfully login via two-factor and with the certificate.
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
No comments:
Post a Comment