Physical or virtual X.509 certificates
Although they are contained in the same menu structure as other authentication provider technologies, the use of X.509 certificates in senhasegura complements an MFA step. The certificate will be linked to the senhasegura user's account, making it mandatory to use this certificate to login.
The administrator will have the option to make the use of the certificate mandatory in the following scenarios:
Mandatory login on the senhasegura Web platform;
Mandatory senhasegura RDP Proxy sessions;
Mandatory senhasegura Terminal Proxy sessions;
In order for certificate support be enabled, it is necessary that our support team to be contacted so that the CA can be recognized by the senhasegura instance, and the CA chain can be configured to used at the web interface login.
Enabling mandatory settings
Force all users to use digital certificates
Through the menu Settings ➔ System Parameters ➔ Security you will have access to the option Force the use of digital certificate for all users.
This option will require users to log in using an X.509 certificate. At the first login, the certificate used will be linked to the user, and from this point on, all subsequent logins will require the use of this linked certificate.
Through the menu Settings ➔ System parameters ➔ Security, the option "Force secure connection (SSL) in the execution of password change?" is set by default to "Yes" and should be changed to "No" as a standard procedure, not to impact the device password change process.
Force use of digital certificate in proxy sessions
Through the menu Settings ➔ System Parameters ➔ System Parameters you have access to the Security section. In this screen you have access to the fields Force authentication with certificate for RDP Proxy and Force authentication with certificate for SSH/Telnet Proxy.
When activating any of these options, the user must log in to the web interface using a valid X.509 certificate before logging in to a proxy session.
Configure behavior
To configure user behavior according to metrics and options, access the menu Settings ➔ System parameters ➔ System parameters ➔ User Behavior:
The suspected minimum score (1 to 15)*: from which score will be considered suspicious.
Session settings
Number of days of history*: for how many days the history of user behavior will be kept.
Variation rate (%)*: Variation of session settings.
Submit high-risk sessions for audit?*: Submit sessions to be audited if marked as Yes
It is mandatory to select at least one auditor to send sessions for auditing and will also be necessary to create a register of standard auditors.
To do so, access the PAM ➔ Settings ➔ Access ➔ Default Auditors menu.
To configure which commands will be audited and the criticality level go to PAM ➔ Settings ➔ Access ➔ Audited Commands.
Weight check
Access on Unusual Destination: Define how many accesses are considered unusual made from an unknown destination.
Unusual source access: Define how many accesses come from an unusual source.
Unusual credential access: Define how many accesses were made using an unusual credential.
Access at unusual times: Define how many accesses were made at unusual times.
Access with unusual duration: Define how many accesses were made having an unusual duration.
Password view settings
Number of days of history*: for how many days the history of user behavior will be kept.
Change rate (%)*: Change in password views.
Weight check
Unusual Source Preview*: Set how many unusual source views are unexpected behavior.
Unusual credential preview*: Set the number of unusual credential previews that are considered as unexpected behavior.
View at unusual times*: Set the number of views at unusual times is unexpected behavior.
Unusual password change*: Set how many unusual password views are unexpected behavior.
To Block Sessions and Block Sessions and User, through the settings listed below, they can be marked with the Yes flag, which will make these options set as active, and if it is with the No flag will be inactive:
- Actions for sessions with unusual time
- Actions for sessions held at unusual times
- Actions for sessions with an unusual origin
- Actions for sessions held for unusual destinations
- Actions for sessions with unusual credentials
Auditing logins via certificate
Certified Certification Authorities
For a CA to be considered reliable for senhasegura , a senhasegura professional must have manually configured the server to accept the CA. Still, the administrator can decide whether to revoke the use of the CA.
Through the menu Settings ➔ Authentication ➔ Digital Certificate ➔ Authorities you have access to the certificate authorities approved as issuing login certificates.
You can view your details or inactivate an authority. In this case, all certificates from this CA will be prevented from logging on to the platform.
Listing used certificates
Through the menu Settings ➔ Authentication ➔ Digital certificate ➔ Certificates the administrator can view details of the certificate and which user account senhasegura is linked. Through this screen, the administrator can even revoke the use of a certificate. In this case, the user must link a new certificate to login.
It is important to remember that if the administrator wants to block a user's access, he must inactivate the access account. Revoking a certificate will not revoke the access account.
Certificate usage log
Through the menu Settings ➔ Authentication ➔ Digital certificate ➔ Certificates you have access to a detailed report of the events that a user has used an X.509 certificate.