Before you enable a different authentication method, be aware of the following:
If your environment contains multiple Sentinel servers, all servers must use the same authentication method. If the servers use different authentication methods, some Sentinel features, such as distributed search, remote alerts, and Data Federation, do not work.
When you enable MFA, Sentinel is not compatible with the following software:
Secure Configuration Manager 6.2
Change Guardian 4.2.1
Identity Manager
Sentinel and Cisco ISE pxGrid Integration utility
When you enable MFA, the installation processes for the following components prompt you for an OAuth client ID and OAuth client secret:
Remote Collector Manager
Remote Correlation Engine
When you map the LDAP user to the Sentinel user, ensure the LDAP user DN field in Sentinel contains the full DN of the LDAP user in the same case. For example, if the LDAP DN in LDAP directory is CN=doej,CN=Users,DC=mycompany,DC=com, the LDAP user DN field must also contain CN=doej,CN=Users,DC=mycompany,DC=com.
For any Sentinel administrator, ensure the logon name contains no spaces between the first name and last name. For example, JohnSmith. If the logon name has a space, such as John Smith, the administrator will not be able to install the following:
Remote Collector Manager
Remote Correlation Engine
When you enable MFA, using a previously downloaded .jnlp file to launch either Sentinel Control Center or Solution Designer is disabled for security reasons. Instead, use the web console to launch Sentinel Control Center or Solution Designer. For more information, see Sentinel Control Center or Accessing the Solution Designer.
If you are using Sentinel in FIPS mode, Kerberos authentication is not supported.
When you enable MFA, the following utility scripts must specify the OAuth client ID and OAuth client secret:
backup_util.sh
convert_to_fips.sh
configure.sh
rest_client.sh
To retrieve the OAuth client ID and OAuth client secret, go to the following URL:
https://Hostname:port/SentinelAuthServices/oauth/clients
Where:
Hostname is the host name of the Sentinel server.
Port is the port Sentinel uses (typically 8443).
The specified URL uses your current Sentinel session to retrieve the OAuth client ID and OAuth client secret.
You can create any number of client IDs and clients. To create a new client ID and client secret, use a RESTful API to send a POST request with the following settings:
Header: application/json
URL: https://Hostname:port/SentinelAuthServices/oauth/clients
Where:
Hostname is the host name of the Sentinel server.
Port is the port Sentinel uses (typically 8443).
Payload:
{
appname:"<appname>"
}
To delete a client ID and client secret, use a RESTful API to send a DELETE request to the following URL:
https://Hostname:port/SentinelAuthServices/oauth/clients/<clientID>
Where:
Hostname is the host name of the Sentinel server.
Port is the port Sentinel uses (typically 8443).
<clientID> is the client ID you want to delete.
When you run the backup_util.sh script, use the mapped LDAP logon credentials of the Sentinel administrator wherever the user name and password are required.For example:
./backup_util.sh -m backup -s -A -b -c -e -i -l -r -w -u myusername -p mypassword -f fullbackup_up.tar.gz
Where myusername and mypassword are the mapped LDAP credentials for the Sentinel administrator.
If you create a backup of Sentinel configurations when either MFA or Kerberos is enabled, you must restore the backup on the same computer.
When you enable Kerberos, logging into Windows also logs you in to Sentinel. When you launch Sentinel, your browser bypasses the Sentinel login window and automatically proceeds to the Sentinel landing page. When users log out of Sentinel, they can log back in at any point in time during the same Windows session by specifying the Sentinel URL.