When authenticating Active Directory users using a username and password, the credentials are used to obtain a Kerberos Ticket Granting Ticket (TGT) from Active Directory. If the Management Console for Unix server is running on a machine that is joined to a domain in a managed Active Directory forest (either on Windows or using Authentication Services on Unix or Mac), a Kerberos service ticket is also obtained for the host account. This second step is necessary to ensure that the TGT has not been falsified and to map any Domain Local Groups to the server's domain.
If the server has not been joined, or is joined to a different forest than the one being managed, an attacker could subvert the logon security by spoofing fake responses from Active Directory (for example, by hijacking DNS to point to a rogue Active Directory service). This is because the security guarantees of the Kerberos protocol require proof of a shared key between Active Directory and the server, before it can be proven that a given TGT is valid; and this proof requires obtaining a service ticket encrypted in the server's key.
|
Note: While you can run the Management Console for Unix server on a computer that is not joined to the forest, One Identity recommends that you run the Management Console for Unix server on a machine joined to the Active Directory forest you are managing to ensure that Active Directory users can be securely authenticated |
SSL/TLS encryption of HTTP traffic between the server and web browser, and integrity checking of data received from the Management Console for Unix server is required to ensure that:
For this reason, Management Console for Unix is configured to require all connections to the browser be secured with the SSL/TLS protocol. (See Disabling SSL/TLS Encryption.) When installed, Management Console for Unix will initially be configured with a newly generated self-signed certificate. Because the authenticity of this certificate cannot be verified, your browser will usually display a warning message whenever you launch the mangement console. To rectify this situation, you can install a custom key pair for SSL/TLS.
You can obtain a trusted certificate from a third-party Certificate Authority. Each authority has its own instructions, but all require you to generate a Certificate Signing Request (CSR). (See Exporting Data using the -certreq command for details about generating a CSR using the PKCS#10 format.)
Optionally you can use a tool (such as, keytool or OpenSSL) to manually generate the public/private key pair and the certificate you need. You can also obtain a certificate and key pair from your Enterprise Certificate Authority.
|
Note: See jetty:// How to configure SSL for details about using OpenSSL to generate a certificate. |
To install a custom SSL/TLS certificate and key pair using keytool
|
Note: See keytool - Key and Certificate Management Tool for more information about using keytool. |
Generate a private key in the keystore file using the keytool command:
keytool -genkeypair -storetype JKS -alias <aliasName> -keyalg RSA -keysize 2048 -validity <numberOfDaysForCertificateToBeValid> -keystore <keystoreName>
|
Note: On Mac 10.5, use the keygen option instead of the genkeypair command. |
Enter the keystore password and provide the other specifications it asks for (or click enter to accept the default). When it asks, "what is your first and last name?" enter the Management Console for Unix server's resolvable host name, such as
computer.test.com
|
Note: Optionally, you can include this option in the above keytool command: -dname "CN=hostName" where hostName is the Management Console for Unix server's resolvable host name. If the host name does not match the Management Console for Unix server's resolvable host name, your browser might indicate a security problem with the certificate that states the presented certificate was issued for a different web site's address. |
Verify the newly created keystore file:
keytool -list -v -keystore <keystoreName>
Enter the keystore password when prompted.
Export the certificate from the keystore:
keytool -export -alias <aliasName> -keystore <keystoreName> -rfc -file <certificateName>.cer
Enter the keystore password when prompted.
Create the truststore using the keytool command line utility.
|
Note: If you want to use the keystore as the truststore, you can skip step #2. However, if you do, in step #5 below, you must use the keystorePassword for both the jetty.keystorePassword and jetty.trustPassword; and, you must use the keystorePath for both the jetty.keystorePath and jetty.truststorePath. |
Import the certificate into the truststore file:
keytool -import -alias <aliasName> -file <certificateName>.cer -keystore <truststoreName>
Verify the newly created trust store file
keytool -list -v -keystore <truststoreName>
(See Start/Stop/Restart Management Console for Unix Service for details.)
(See Setting Custom Configuration Settings for general information about customizing configuration settings for the mangement console.)
Modify the following Jetty Settings:
-Djetty.keystorePath=C:\ProgramData\Quest Software\Management Console for Unix\resources\keystore -Djetty.keystorePassword=<password> -Djetty.keyPassword=<password> -Djetty.truststorePath=C:\ProgramData\Quest Software\Management Console for Unix\resources\keystore -Djetty.trustPassword=<password>
where <password> is your plain text password or, if obfuscated (as explained below), is something similar to:
OBF:1tvp1saj1y7z1sar1tvd
|
Note: Optionally you can obfuscate your SSL keystore password so it is not stored in plain text by running the following command from your installation directory:
The output of gen_secure_password.exe lists
Note: Jetty only supports obfuscation (OBF) of SSL keystore passwords; the others can be ignored. |
Save the custom.cfg file.
Start the Management Console for Unix service.
For more information, see the Jetty documentation at: How to Configure SSL.
To import certificates to trusted domains on Windows platforms
The certificate import wizard starts.
|
Note: You can also import certificates into a trusted domain by means of your browser. |
© 2023 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy