This section covers the prerequisites your environment must meet before you enable any of the supported authentication methods.
Before you configure the Sentinel server to use either MFA or Kerberos, complete the following:
The Sentinel DNS name is case-senstive. Ensure you specify the DNS name with the correct case each time the configuration procedure request it.
Ensure that your environment uses LDAP authentication and Active Directory. For more information about configuring LDAP authentication, see LDAP Authentication Against a Single LDAP Server Or Domain.
NOTE:After you configure your environment to use MFA, theand fields are required. As a result, existing Sentinel users will not be able to log in to Sentinel. You must update all users with valid email ID and User DN.
When you create new users, ensure that they have a valid email ID and User DN.
(Conditional) If the Sentinel server is not a member of the enterprise domain, you need to update the /etc/hosts file with the fully qualified domain name (FQDN) of the Sentinel server.
After you enable MFA or Kerberos, the Sentinel admin will not be able to create ‘local’ users. The admin will be able to create only ‘directory’ users. This prerequisite gives the admin the permissions to create new ‘directory’ users.
In the /etc/opt/novell/sentinel/config directory, open the osp-configuration.properties file and ensure the following property values:
Where LDAPProviderName is the name attribute of your LDAP provider. For example, the name attribute for Active Directory is sAMAccountName.
Where LDAPDirectoryType is the directory type of your LDAP provider. For example, the directory type for Active Directory is AD.
Where AdminContainerDN is the container DN for the admin user in Sentinel. For example, CN=Users,DC=mycompany,DC=com.
Where LDAP_IP is the IP address of the LDAP server.
Where LDAP_Port is the port number for the LDAP connection. The default SSL port number is 636 and the default non-SSL port number is 389.
Where true/false specifies whether LDAP uses SSL.
(Conditional) If this value is true, you must use the keytool command to import the LDAP server certificate into the /etc/opt/novell/sentinel/config/.webserverkeystore.jks file.
/opt/novell/sentinel/jdk/jre/bin/keytool -importcert -alias <AliasName> -file <FileName>.cer -keystore /etc/opt/novell/sentinel/config/.webserverkeystore.jks
<AliasName> is the new alias name you want to assign to the certificate in the Sentinel keystore.
<FileName> is the name of the certificate file you want to import.
Where UserContainerDN is the container DN for the users in Sentinel. For example, CN=Users,DC=mycompany,DC=com.
Where AdminDN is the DN for the admin user in Sentinel. For example, CN=Administrator,CN=Users,DC=mycompany,DC=com.
Where LDAPAdminPassword is the encrypted password for the LDAP server administrator.
NOTE:To encrypt the password, run the encryptpwd script as the novell user:
./encryptpwd -e LDAPAdminPassword
The script is located in the /opt/novell/sentinel/bin directory.
In the /etc/opt/novell/sentinel/config directory, open the configuration.properties file and complete the following steps:
Where LDAP_DN_ForSentinelAdminUser is the mapped LDAP DN for the admin user in Sentinel.
NOTE:When you install Sentinel, the installation process creates the admin user by default as an out-of-the-box user. To enable MFA or Kerberos authentication and use the admin user again, you must map the admin user to a corresponding LDAP DN. Once you enable Kerberos authentication, you cannot use the out-of-the-box admin user to log in to Sentinel. Instead, you must use the mapped LDAP DN to log in to Sentinel.
(Conditional) If you are using Sentinel in High Availability (HA) mode, Add sentinel.ha.cluster.hostname=FQDN_Virtual_Hostname.
Where FQDN_Virtual_Hostname is the FQDN of the HA virtual IP address in all nodes of the HA cluster.
On every computer your users will use to access Sentinel, go to C:\Windows\System32\Drivers\etc and complete the following steps:
Open the hosts file.
Add the following entry:
Sentinel_IP FQDN_Sentinel_server Hostname
Sentinel_IP is the IP address of the Sentinel server.
FQDN_Sentinel_server is the FQDN of the Sentinel server.
Hostname is the host name of the Sentinel server.
127.0.0.1 rbpm.mycompany.com rbpm
MFA and Kerberos Ensure that all Sentinel users (including the admin) have a valid registered email ID in LDAP. To add a registered LDAP email ID to every Sentinel user account, use thetab in Sentinel.
OAuth Ensure that all Sentinel users (including the admin) have a valid registered email ID with the same email provider as the OAuth IDP. For example, if you use Google, all users must have valid gmail IDs.
If Sentinel uses MFA, Kerberos, or OAuth, and needs to integrate with an LDAP server that uses SSL, complete the following:
Import the certificate file for AD and LDAP to the Sentinel server keystore.
In a command prompt, go to /opt/novell/sentinel/jdk/jre/bin and use the following command:
./keytool -importcert -file FileName.cer -keystore /etc/opt/novell/sentinel/config/.webserverkeystore.jks -alias AliasName
FileName is the name of the certificate file you want to import.
AliasName is the new alias name you want to assign to the certificate in the Sentinel keystore.
Go to the /etc/opt/novell/sentinel/config directory and complete the following steps:
Open the osp-configuration.properties file.
Ensure the following:
Log in to the Sentinel server as the novell user, then run the following command:
After you have completed all the prerequisites, restart Sentinel. Use the following command:
(Conditional) If you are using Sentinel in High Availability (HA) mode, complete the following steps:
Log in to the active node of the HA cluster and run the following command:
csync2 -x -v
(Conditional) If the cluster does not start correctly, perform the following steps:
Manually copy the /etc/corosync/corosync.conf file from node01 to node02, or run the csync2 -x -v on node01, or manually set the cluster up on node02 through YaST.
(Conditional) If the csync2 -x -v command you run in the previous step fails to synchronize all the files, perform the following procedure:
Clear the csync2 database (in the /var/lib/csync2 directory) on all the nodes.
Run the following command on all servers to update the csync2 database to match the filesystem, but without marking anything as needing to be synchronized to other servers:
csync2 -cIr /
Run the following command to find all the differences between authoritative server and remote servers, and mark for synchronization:
Run the following command to reset the database to force the current server to be winner on any conflicts:
csync2 -fr /
Run the following command to start a synchronization to all the other servers:
csync2 -xr /
Run the following command to verify that all the files are synchronized:
This command will not list any files if the synchronization is successful.
Run the following command on node02:
For SLES 11 SP4:
For SLES 12 SP1 and later:
systemctl start pacemaker.service
(Conditional) If the xinetd service does not properly add the new csync2 service, the script will not function properly. The xinetd service is required so that the other node can sync the cluster configuration files down to this node. If you see errors like csync2 run failed, you may have this problem.
To resolve this issue, execute the kill -HUP `cat /var/run/xinetd.init.pid command and then re-run the sleha-join script.
Run crm_mon on each cluster node to verify that the cluster is running properly. You can also use 'hawk', the web console, to verify the cluster. The default login name ishacluster and the password is linux.