Securing network transport in IdentityIQ

[#1]

• Overview
• Enabling SSL connections between IdentityIQ and Active Directory
• Test LDAPS configuration
• On Windows DC configured for LDAPS authentication
• On the IdentityIQ Server
• In IdentityIQ
• Securing IQService transport
• SSH key authentication
• On the Windows Server

Overview

The configuration of network transport security in Identity IQ is often a source of confusion. There are several documents available that address the issue, but the documentation is scattered, so a discussion of common concerns around transport encryption in Identity IQ might be helpful.  These issues include SSL, TLS, and SSH.

First, it's important to realize that Identity IQ only provides minimal encryption. Some passwords and other items are encrypted by Identity IQ, but transport encryption is provided by the application server based on some libraries available in the JRE. Strictly speaking, SSL/TLS is a third-party service not provided by Identity IQ. IIQ sort of rides on top of the service provided by the application server, and beyond enabling SSL in an application definition, there isn't much configuration related to SSL/TLS that can be done in IIQ. SSH is provided by an SSH server running on a remote host. SSH key authentication can be configured in IIQ through the application definition.

Also, SSL is commonly used to refer to both SSL and TLS.  SSL has several security flaws and is largely being superceded by TLS. The chart below lists the transport protocols available in recent releases of the JRE.  Configuration of these protocols is done in the application server and varies by product and version. See the documentation for application server for details.

JDK 8

(March 2014 to present)

TLSv1.2 (default)

TLSv1.1

TLSv1

SSLv3

JDK 7

(July 2011 to present)

TLSv1.2

TLSv1.1

TLSv1 (default)

SSLv3

JDK 6

(2006 to end of public updates 2013)

TLS v1.1 (JDK 6 update 111 and above)

TLSv1 (default)

SSLv3

Enabling SSL connections between IdentityIQ and Active Directory

There are two common methods for implementing SSL in Active Directory.  The first is to use a self-signed certificate generated by Active Directory Certificate Services.

Another method is to use a third-party certificate provided by a recognized certificate authority.  Details for importing a third-party certificate into Active Directory are available at https://support.microsoft.com/en-us/kb/321051.

Before proceeding to configure or test IIQ over SSL, it is advisable to test AD LDAPS to make sure the DC is accepting secure connections  A simple test using Microsoft's LDP.exe is listed below, but this test could be done with any available LDAP browser.

Test LDAPS configuration

1. Open a command prompt and type ldp (if it is installed on the system). The LDP application appears.

2. Select Connection > Connect. The Connect dialog box appears.

3. In the Server text box, type the name of your AD server. For this example, type 2003ADsrv.

4. In the Port text box, type 636.

5. Enter a username/password to bind to AD.  Most AD user accounts can bind.  You don't need elevated permissions to perform this task.

6. Select the SSL check box.  Click OK.

Once you have confirmed that the DC is accepting LDAPS connections, you can proceed as follows:

On Windows DC configured for LDAPS authentication

1. Start>Run>mmc

2. File>Add/Remove Snap-in

3. Choose Certificates>Add

4. Choose Computer account>Next

5. Choose Local Computer>Finish

6. Click Ok

7. Expand Certificates

8. Choose Trusted Root Certificates

9. Expand Certificates

10. Locate the root certificate for your domain and select it

11. Right-click, choose All Tasks>Export

12. Click Next

13. Choose No, do not export the private key. Click Next

14. Choose DER encoded binary X.509 (.cer)

15. Choose a file name. I will use examplerootca. The file will be saved in the Documents directory and will be called examplerootca.cer

On the IdentityIQ Server

16. Copy the certificate file (examplerootca.cer) to the IIQ Server. Place it in $JAVA_HOME\jre\lib\security

17. Make $JAVA_HOME\jre\lib\security the current working directory. It's very important that you are in this directory before you run the commands below

18. Run command: keytool –import –keystore cacerts -alias <string> -file <certificate file name>

19. Run command: keytool –list –keystore cacerts. Verify that the certificate was added to the truststore. You should be able to find the alias string you created in Step 18

20. Restart Tomcat

Note: Although the command uses the term "keystore" the certificate will actually be stored in the truststore. The keystore is used for certificates for a particular entity, but here we are importing a trusted root certificate. Trusted root certificates are stored in the truststore.

In IdentityIQ

Please configure your application using a hostname rather than an ip address. An ip address will only work if the certificate contains a Subject Alternative Name listing the ip address. If for some reason DNS cannot resolve the hostname, you can add a mapping for the hostname in the hosts file on the IIQ Server.

21. Login to IdentityIQ

22. Choose Define>Applications. Open the application you’d like to edit

23. Choose Configuration. Enable "SSL" checkbox

24. Click Test Connection. After successful connection, click Save

Securing IQService transport

TCP transmissions between IIQ and IQ Service are encrypted out of the box using a 128-bit AES encryption. SailPoint stores default keys for IQ Service in a Microsoft API-based facility and no configuration is required if you plan to use the provided keys.

SSH key authentication

Several IIQ Connectors support the use of secure shell sessions to connect to *nix servers.  In SSH key authentication, a username and password for logins are replaced with a certificate that authenticates the connection.  SSH must be installed on the host server for key authentication to work.

To configure IIQ to SSH key authentication, follow these steps:

On the Windows Server

1. Download Git from:

https://git-scm.com/downloads

2. Install Git. Accept all defaults

3. Open Git Bash (Start->All Programs->Git->Git Bash)

4. Type in the following:

ssh-keygen -t rsa –b 1024

5. When prompted, enter password. Accept default value for key name. Two files will be created in c:\users\username\.ssh—id_rsa (private key) and id_rsa.pub (public key)

6. Using WinSCP copy id_rsa.pub from c:\users\username\.ssh to /home/username/.ssh. Use text as the transfer mode.

ON THE SSH SERVER

7. Login to SSH server

In /home/username/.ssh, run:

cat id_rsa.pub >> authorized_keys

8. Set directory and file permissions as:

chmod 755 /home/username

chmod 700 /home/username/.ssh

chmod 644 /home/username/.ssh/*

9. Set directory and file ownership as:

chown username:groupname /home/username/.ssh

chown username;groupname /home/username/.ssh/*

10. Restart SSH server

In IdentityIQ

11. Enter the following for the Unix Settings under the Configuration tab

Unix Server Host: SSH Server FQDN

SSH Port: Port SSH server is running on. Default is 22

User Name: Name of user account on SSH server

Password: Password of user on SSH server

Not a root user: leave blank for SSH authentication

Private Key File Path: c:\users\username\.ssh\id_rsa

Passphrase for Private Key: Password assigned when you generated the key pair

12. Click Test Connection

13. On successful connection, click save

Additional Documentation:

Active Directory Getting Started Guide

IQService architecture - Network ports and Firewalls

Redundancy for IQService Agents and Synchronizing Encryption Keys

Note: Configuration of third-party systems such as Active Directory and the JRE are beyond the scope of SailPoint Support. This post represents a "best effort" to help with a common issue.  It should be tested thoroughly in a development environment before deployment.