Configuring Informatica Domain Security with Kerberos and SSL

Challenge

Enterprise data must be protected in a way that complies with external laws and regulations as well as internal organizational policies and standards. As a hub for data movement throughout the enterprise, the Informatica Data Integration platform must comply with Enterprise Data rules. This Best Practice document describes approaches that can be taken to harden security on the Informatica Domain to enable Informatica Administrators to ensure the Domain meets these rules and policies.

Description

This document discusses implementation best practices for several Informatica security features.

• File Permissions
• Enabling SSL on all Domain communications
• Enabling Kerberos Domain authentication
• Use of Operating System Profiles (OS Profiles)

File Permissions

By default, Informatica installation files may be created with write privilege to the group. This might be an undesired configuration, as it allows any users in this group to modify the Informatica installation files. The Informatica node configuration file and the encryption key used to encrypt sensitive information (prior to writing it to files or storing it in the database) are stored under the isp/config directory. Simple modifications to file system permissions can be made to prevent tampering with files and stealing of the encryption key.

General File Permissions

To remove write access to all users other than the user running the node, the following command can be run from the root directory of the Informatica installation:

[infa_user@server]$ chmod -R go-w *
chmod: cannot read directory `isp/config': Permission denied

With the default permission on isp/config, the chmod command will be unable to modify permissions on files and directories under isp/config. This is expected and will be addressed in the next section.

File Permissions on isp/config

The isp/config directory contains sensitive information. The nodemeta.xml file in the directory contains the configuration information for the node. The siteKey file in the isp/config/keys directory contains the encryption key that is used to encrypt all passwords stored in files and database tables. In a secure Informatica installation it is important that these files can only be accessed by the user running the Informatica node.

Directory isp/config

As a best practice, the user running the Informatica node should have read, write and access privilege to this directory, and no other users should have access.

[infa_user@server]$ chmod 700 isp/config

Directory isp/config/keys

The isp/config/keys directory stores the siteKey encryption key file that is used to encrypt all sensitive information in the Informatica Domain. If Kerberos Authentication is being used then keytab files used to log in to the Active Directory domain are also stored here. Access to this directory should be restricted to the user running the Informatica node.

[infa_user@server]$ chmod 700 isp/config/keys

File isp/config/keys/siteKey

The siteKey file contains the encryption key used to encrypt all sensitive information in the Informatica Domain. Access to this file should be restricted to just the user running the Informatica node.

[infa_user@server]$ chmod 400 isp/config/keys/siteKey

When complete, file and directory permissions under isp/config should look like this:

[infa_user@server]$ ls -alR isp/config
isp/config:java
total 16
drwx------ 3 infa_user infa_userinfa_group 4096 Sep 24 13:45 .
drwxr-xr-x 6 infa_user infa_userinfa_group 4096 Sep 24 13:42 ..
drwx------ 2 infa_user infa_userinfa_group 4096 Sep 24 13:42 keys
-rw------- 1 infa_user infa_userinfa_group 1665 Sep 24 13:45 nodemeta.xml

isp/config/keys:
total 12
drwx------ 2 infa_user infa_userinfa_group 4096 Sep 24 13:42 .
drwx------ 3 infa_user infa_userinfa_group 4096 Sep 24 13:45 ..
-r-------- 1 infa_user infa_userinfa_group   75 Sep 24 13:42 siteKey

Enable SSL on the Domain

By default, network communications between the Informatica client tools and the Informatica Services, and communications between the Informatica Services, are unencrypted. It is possible to configure the Informatica Domain so that all network communication is encrypted. This provides protection for sensitive information such as:

• User login credentials (no user passwords are sent to the Informatica services at user login if Kerberos authentication is used)
• Database connection configuration, including usernames and passwords
• Data sent to the Designer during a mapping debugging session
• Configuration information, data, sensitive error messages sent to the Workflow Monitor during session log retrieval
• Any logic developed using the Informatica client tools

Enabling SSL

To enable SSL on the Domain connect to the Admin Console and go to Manage > Services and Nodes > Domain Navigator > Select Domain > Properties > General Properties. Click Edit > Check “Enable Secure Communication”, click OK.

Upon checking this box, clicking on OK will cause another window to pop up asking to confirm the change and informing the user that the changes must be manually applied to each of the nodes using infasetup command line program. And then, the domain must be restarted for the changes to take effect. Click on Yes, Save Changes.

Now, stop all nodes in the domain. On each node cd to the isp/bin directory under the Informatica installation and execute infasetup.sh updategatewaynode (or updateworkernode as appropriate) -tls true.

[infa_user@server]$ pwd
/opt/app/Informatica/isp/bin

[infa_user@server]$ ./infasetup.sh updategatewaynode –tls

Command ran successfully.

Restart all nodes in the domain. To verify that SSL has been enabled for the Domain navigate to a node port using HTTPS (by default the node port is 6005) and it should connect successfully. This verifies that SSL is enabled. The browser will return a warning indicating that the server certificate is untrusted.

Note that at this point the Informatica node process on each node is using the standard Informatica keystore provided in <Installation>/services/shared/security/infa_keystore.jks/pem  Informatica recommends that a custom keystore be used instead of the standard Informatica keystore.  Information on how a custom keystore can be created and deployed is provided later in this document.

If HTTPS was enabled on the Admin console during install, then it will be using a keystore generated during the install process on the node where the Admin Console is running, or a custom keystore chosen during the install process. If a keystore was generated during the install then it will be located at <Installation>/tomcat/conf/Default.keystore.

Enable SSL for Mapping Debugger and/or Session on Grid (SOnG)

By default, data that travels between the session process and the PowerCenter mapping debugger, and data that travel between PowerCenter SonG session instances on different nodes, are not encrypted, even when SSL is enabled on the Domain. Encryption of data for these can be enabled by checking the “Enable Data Encryption” property of the Integration Service. This property is available through the Admin Console. Click on the Integration Service and edit the “PowerCenter Integration Service Properties” section. Once “Enable Data Encryption” has been checked click OK. The change takes effect immediately, and there is no need to restart the Integration Service.

For different environments, enabling Data Encryption may or may not be required. It is best to only enable Data Encryption if it is needed. Data Encryption adds an additional processing cost to SonG sessions.

In production and similar higher environments, developers should not have access, and there should be no requirement to run mapping debugger. In those environments, the mapping debugger can be disabled on each Integration Service. This is done through the Admin Console by selecting the Integration Service Properties tab, select Edit in the “Advanced Properties” section, unselect the checkbox by “Allow Debugging”, and click OK. If SonG is required then data encryption should only be enabled if organization policy requires that data be encrypted as it is sent between the nodes. The Informatica production nodes are often located close together in data centers where access to the network segments is restricted. It may be acceptable to allow unencrypted data to travel between the Informatica nodes.

In development and similar lower environments, it is likely that mapping debugger will be used extensively. Data Encryption should be used there if organizational policy requires that data not travel across the network to developer machines without being encrypted.

Creating a Custom Keystore for use with Domain SSL Communication

Informatica administrators will likely have existing procedures for creating signed keystores for each Informatica node. These are used to enable HTTPS on the Admin Console and web enabled Domain Services.

The keys contained in the Informatica administrator generated keystores are generally signed by a certifying authority. These keystores can also be used to enable SSL on the Informatica Domain.

To enable SSL on the Informatica nodes there are four files that need to be created and copied to the Informatica servers:

• jks – private key and associated certificate in java keystore format
• pem – primary key and associated certificate in openssl PKCS#8 and openssl X509 PEM encoded formats respectively
• jks –certificates of certificate signing authorities in java keystore format
• infa_truststore.pem – certificates of certificate signing authorities in openssl X509 PEM encoded format

Create the Server Private Key

The openssl genpkey utility can be used to generate a private key/public key pair. The private key and public key will be stored in the file specified in the -out parameter. This file should be treated as sensitive as it contains the server’s private key.

[infa_user@server]$ openssl genpkey -algorithm RSA -out server.key.pem -aes-256-cbc -pkeyopt rsa_keygen_bits:4096
.................................................++
...................................++
Enter PEM pass phrase:
Verifying – Enter PEM pass phrase:

Generate a Certificate Signing Request

A Certificate Signing Request is used to request that the certificate just generated be signed by a certified signing authority. The openssl req utility can be used to generate the Certificate Signing Request.

[infa_user@server]$ openssl req -sha256 -new -key server.key.pem -out server.csr.pem
Enter pass phrase for server.key.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:State
Locality Name (eg, city) [Default City]:City
Organization Name (eg, company) [Default Company Ltd]:Organization
Organizational Unit Name (eg, section) []:Organizational Unit
Common Name (eg, your name or your server’s hostname) []:server
Email Address []: example@organization.com
 
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Submit the Certificate Signing Request (file server.csr.pem in the example above) to a certifying authority.  The certifying authority should respond with a digitally signed version of the server certificate.  They may also provide certificates for the root and intermediate signing authorities used in the signing chain.  These signing chain certificates are required in subsequent steps.

Sometimes, for development purposes, a self-signed certificate may be used.  The following shows the openssl syntax to create a self-signed certificate valid for 365 days.

[infa_user@server]$ openssl x509 -req -days 365 -in server.csr.pem -signkey server.key.pem -sha256 -out server.cert.pem
Signature ok
subject=/C=US/ST=State/L=City/O=Organization/CN=server
Getting Private key
Enter pass phrase for server.key.pem:

Create a PKCS#12 keystore using the Private Key and Signed Certificate

Once the signed certificate is received back from the certifying authority a PKCS#12 keystore can be created using the openssl pkcs12 utility. The PKCS#12 keystore is used as an intermediary step. The final goal is to create a java keystore. It is not possible to create a java keystore from the private key and certificate files using either openssl or keytool utilities. Openssl can however create a PKCS#12 keystore from the files and keytool can then create a java keystore from the PKCS#12 keystore.

Several files are used in this step:

• cert.pem – the signed certificate file received from the certifying authority, or the self-signed certificate file
• key.pem – the private key file created earlier
• ca-chain.cert.pem – a file containing the chain of certificates used by the certifying authority, i.e. the root certifying authority certificate and any intermediate certifying authority certificates in PEM encoded openssl X509 format. If a self-signed certificate is used, then this file isn’t required.

The PKCS#12 keystore is created in file server.p12 in this example.  If a self-signed certificate is used, then remove the “-chain”, “-Cafile” and “-caname” options from the command below.

[infa_user@server]$ openssl pkcs12 -export -chain -in server.cert.pem -inkey server.key.pem -out server.p12 -name server -Cafile ca-chain.cert.pem -caname root
Enter pass phrase for server.key.pem:
Enter Export Password:
Verifying – Enter Export Password:

Note that the PKCS#12 keystore should be treated as sensitive as it contains the server’s private key.

Create the infa_keystore.jks File

The java keytool utility is used to create a java keystore version of the information in the PKCS#12 keystore. This file is called infa_keystore.jks and will be used by the Informatica node and all non-PowerCenter services (e.g., Model Repository Service, Data Integration Service, etc). to terminate SSL connections from clients. It can also be used by the Admin Console and other web based Informatica services. As with other files that contain the server’s private key, treat this file as sensitive. The password used when creating infa_keystore.jks should be the same as the password used when creating the server private key.

[infa_user@server]$ keytool -importkeystore -destkeystore infa_keystore.jks -srckeystore server.p12 -srcstoretype PKCS12 -deststoretype JKS -alias server
Enter destination keystore password:
Re-enter new password:
Enter source keystore password: 

The password used is “changeit”

The Keystore generated should contain the private key and the related cert. Please validate using the command below:

keytool -list -v -keystore infa_keystore.jks|grep -i -e alias -e entry

The PKCS#12 keystore file can be deleted once the JKS keystore creation step is complete. File infa_keystore.jks should be treated as sensitive as it contains the server’s private key.

Create the infa_keystore.pem File

The infa_keystore.pem file is used by the Informatica PowerCenter Repository Services and PowerCenter Integration services to terminate SSL connections. It is created by concatenating the server private key and server certificate files.

[infa_user@server]$ cat server.key.pem server.cert.pem > infa_keystore.pem

The server.key.pem file can be deleted once the infa_keystore.pem and infa_keystore.jks files are created. File infa_keystore.pem should be treated as sensitive as it contains the server’s private key.

Create the infa_truststore.pem File

The file infa_truststore.pem is used to validate that any Informatica client to server or server to server SSL connections are being established with trusted parties. On the Informatica server this file is used by the services to validate that they are connecting with valid nodes and services within the same Informatica domain. On the Informatica client side this file is used by client utilities to validate that they are connecting with legitimate Informatica nodes and services. If self-signed certificates are not used then infa_truststore.pem need just contain the certificates for the root certifying authority and any intermediate authorities that signed the server certificates. If self-signed certificates are used then infa_truststore.pem should contain individual certificates for all Informatica nodes to which connections will be established. The file infa_truststore.pem can be created by concatenating individual certificate files.

If custom certificates are used on any of the Informatica servers then a corresponding custom infa_truststore.pem file is required on the Informatica client machines. In addition, it is necessary to set the environment variable INFA_TRUSTSTORE on the client machines to point to the directory that contains the infa_truststore.pem file. This is true even if the default location is used for the infa_truststore.pem file.

Create the infa_truststore.jks File

The infa_truststore.jks file contains the same information as the infa_truststore.pem file in java keystore format. It is used by all services except PowerCenter (e.g., the Informatica node, the Model Repository service and the Developer client). It is created by importing each root and intermediate signing authority certificate if signed certificates are used, or by importing each individual server certificate if unsigned certificates are used.

If importing a root certifying authority certificate or an individual server certificate then the user will be asked whether they choose to trust the certificate.

[[infa_user@server]$ keytool -importcert -alias root -file root.cert.pem -keystore infa_truststore.jks -storepass pass2038@infaSSL
Owner: EMAILADDRESS= example@organization.com, CN=Organization, OU=Organizational Unit, O=Organization, L=City, ST=State, C=US
Issuer: EMAILADDRESS= example@organization.com, CN=Organization, OU=Organizational Unit, O=Organization, L=City, ST=State, C=US
Serial number: c01c5195ffa787bc
Valid from: Tue Sep 23 10:28:31 GMT-05:00 2014 until: Fri Sep 20 10:28:31 GMT-05:00 2024
Certificate fingerprints:
         MD5:  A0:A1:BD:0E:12:D9:8B:9A:C9:40:4D:22:E4:56:0F:F5
         SHA1: E6:B5:D1:7B:5A:25:66:6A:70:C6:4E:16:D3:48:0C:86:F4:90:7B:AC
         SHA256: B6:5D:D2:18:BD:CE:CA:3E:6F:43:CD:83:9D:FA:16:92:23:2A:99:B0:EA:76:BA:6A:42:20:AB:02:CA:1F:1F:9D
         Signature algorithm name: SHA256withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9F 33 5D 73 C6 01 4C 6A   73 37 44 82 1B 3B 00 04  .3]s..Ljs7D..;..
0010: 72 57 D0 39                                        rW.9
]
]
 
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
 
#3: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
  Key_CertSign
  Crl_Sign
]
 
#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9F 33 5D 73 C6 01 4C 6A   73 37 44 82 1B 3B 00 04  .3]s..Ljs7D..;..
0010: 72 57 D0 39                                        rW.9
]
]
 
Trust this certificate? [no]:  y
Certificate was added to keystore

Root signing authority certificates should be imported first. If this is done, intermediate signing authority certificates will be automatically trusted and will import without requesting that the user approve the import.

[infa_user@server]$ keytool -importcert -alias inter -file intermediate.cert.pem -keystore infa_truststore.jks -storepass pass2038@infaSSL
Certificate was added to keystore 

It is recommended that the password “pass2038@infaSSL” be used for the infa_truststore.jks file.  This is the default password used by Informatica for this file.  If a different password is used then the INFA_TRUSTORE_PASSWORD environment variable must be set to allow client tools to access the file.  The infa_truststore.jks file does not contain any sensitive information and all users should have read access to this file on the Informatica servers

Configure the Nodes to use New infa_keystore/infa_truststore

The Informatica Domain should be stopped before changing the keystore and truststore files. Once the Domain is down, on each node in the domain, replace the infa_keystore.jks/pem and infa_truststore.jks/pem files with the custom files created above. All four files will be in services/shared/security under the Informatica install. Prior to restarting nodes in the Domain use the “infasetup.sh updateGatewayNode” and “infasetup.sh updateWorkerNode” commands to update the node configuration with the new keystore password and truststore password. Note that it is necessary to update the truststore password even if the new truststore uses the same password as the default Informatica truststore.

[infa_user@server]$ ./infasetup.sh updategatewaynode -nk /opt/app/Informatica/10.5.2/services/shared/security -nkp changeit -nt /opt/app/Informatica/10.5.2/services/shared/security -ntp pass2038@infaSSL
Command ran successfully

Configure the Admin Console to Use New infa_keystore.jks

The Admin Console can use the same keystore that is used for node and service communications. If certifying authority signed certificates are used in the keystore then having the Admin Console use the same keystore will eliminate user browser warnings. If self-signed certificates are used then using the same keystore for the Admin Console and the node will mean that users who navigate to the node port initially will receive one rather than two browser warnings.

[infa_user@server]$ ./infasetup.sh updategatewaynode -hs 6013 -kf /opt/app/Informatica/services/shared/security/infa_keystore.jks -kp changeit
Command ran successfully. 

Client-side Truststore Files

If custom keystore and truststore files are used then all client workstations will require copies of the infa_truststore.pem and infa_truststore.jks files to allow them to connect to the Domain. The two files should be copied to the clients\shared\security directory under the Informatica client install, replacing the files there. The environment variable INFA_TRUSTSTORE should be set to the full path to the directory where the files were placed. If a password other than the default password of “pass2038@infaSSL” is used with infa_truststore.jks, then that password needs to be encrypted using the pmpasswd utility and the environment variable INFA_TRUSTSTORE_PASSWORD should be set with the encrypted version of the password.

Here is an example of using the pmpasswd utility to get an encrypted version of the truststore password:

[infa_user@server]$ (export LD_LIBRARY_PATH=$INFA_HOME/server/bin; $INFA_HOME/server/bin/pmpasswd mypass -e CRYPT_SYSTEM)

Informatica PowerMart Password Encryption Utility, 64-bit
Copyright (c) Informatica Corporation 1993-2020
All Rights Reserved.

Encrypted string -->IxYbmRX6o2U5sDibn3Tg4Q==<--
Will decrypt to  -->mypass<--

Example:

set INFA_TRUSTSTORE=C:\Users\user\Desktop\Projects\certs

set INFA_TRUSTSTORE_PASSWORD='IxYbmRX6o2U5sDibn3Tg4Q=='

Keystore and Truststore File Security

By default, the infa_keystore.jks/pem and infa_truststore.jks/pem files are placed in the services/shared/security directory under the Informatica installation. Permissions on this directory are set up by the installer so that the user who installed the node and any users in its default group have write and access privilege to the directory. The user who installed the node and any users in its default group have read and write access to the keystore and truststore files. All other users are denied access to the directory. Here is an example of the default configuration:

[root@server]$ ls -altr security
total 24
-rw-rw-r-- 1 infa_user infa_userinfa_group 1346 Sep 24 13:38 infa_truststore.pem
-rw-rw-r-- 1 infa_user infa_userinfa_group 1028 Sep 24 13:38 infa_truststore.jks
-rw-rw---- 1 infa_user infa_userinfa_group 3180 Sep 24 13:38 infa_keystore.pem
-rw-rw---- 1 infa_user infa_userinfa_group 2318 Sep 24 13:38 infa_keystore.jks
d-wx-wx--- 2 infa_user infa_userinfa_group 4096 Sep 24 13:38 .
drwxrwxr-x 8 infa_user infa_userinfa_group 4096 Sep 24 13:40 ..

This configuration has three disadvantages:

• Users in the node user’s default group can read and change the keystore files. Security of the SSL communication depends on keeping these files secured.
• Users in the node user’s default group can change the truststore files.
• Users who are not the node user and who are not in the node user’s default group cannot access the infa_truststore.jks/pem files. This means they can’t run the pmcmd, pmrep and infacmd.sh command line utilities if SSL is enabled, without first creating their own infa_truststore.jks/pem files. 

To address this, Informatica recommends that the following actions are taken:

• Change the permission on the security directory so that read and access (r-x) is enabled for the group and all users. Disable write access to the group and all users.
• Change the permissions on the infa_keystore files so that they are readable only by the user running the Informatica node and are not writable or executable by any user.
• Change permission on the infa_truststore files so that they are readable by all users and not writable by any user.

An example of this configuration looks like this:

[root@server]$ ls -altr security
total 24
-r--r--r-- 1 infa_user infa_userinfa_group 1346 Sep 24 13:38 infa_truststore.pem
-r--r--r-- 1 infa_user infa_userinfa_group 1028 Sep 24 13:38 infa_truststore.jks
-r-------- 1 infa_user infa_userinfa_group 3180 Sep 24 13:38 infa_keystore.pem
-r-------- 1 infa_user infa_userinfa_group 2318 Sep 24 13:38 infa_keystore.jks
dr-xr-xr-x 2 infa_user infa_userinfa_group 4096 Sep 24 13:38 .
drwxrwxr-x 8 infa_user infa_userinfa_group 4096 Sep 24 13:40 ..

Enable Kerberos in the Domain

Kerberos is a computer network authentication protocol based on tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. It provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

Informatica supports Microsoft Active Directory Kerberos authentication to the Informatica Domain from the PowerCenter and Developer client tools and from the web browser. Enabling this function eliminates Informatica native accounts and removes the need for the Informatica Domain to pass user credentials to LDAP servers, thus greatly reducing risk of password theft. In addition, if customers mandate use of additional login factors, such as smartcards or tokens, and have incorporated support for these factors in their Windows logon protocols, then Informatica inherits support for the factors. Informatica clients use the Kerberos tickets created during the Windows logon process to log on to the Informatica services.

Prerequisite Steps

Prior to enabling Kerberos on the domain there are some prerequisite steps that need to be completed.

Create krb5.conf File

The krb5.conf file contains Kerberos configuration information. The krb5.conf file should be placed in services/shared/security under the Informatica installation. Permissions on this file should be set so that all users can read it and no user can modify it.

[infa_user@server]$ ls -altr krb5.conf
-r--r--r-- 1 infa_user infa_user 600 Sep 24 12:55 krb5.conf

Kerberos supports use of several different encryption protocols.  It is encouraged to restrict Kerberos encryption to use AES128 and/or AES256 encryption protocols.  The “default_tkt_enctypes”, “default_tgs_enctypes” and “permitted_enctypes” entries in the “[libdefaults]” section of the krb5.conf file can be used to restrict the encryption types allowed.  Please refer to the Kerberos documentation for information for details on use of these values.

By default, Kerberos communication will be done using UDP. This can lead to occasional failures that manifest as failed user logins or failed workflows. To force all Kerberos communication to use TCP the entry “udp_preference_limit = 1” can be added to the “libdefaults” section of the krb5.conf file.

Active Directory administrators should be able to provide the values for other organization specific krb5.conf configuration items. An example krb5.conf file is shown below. It is recommended that multiple kdc entries are made. These allow the Kerberos libraries to seamlessly retry requests to alternate Active Directory Domain Controllers should requests fail, network packets get dropped, etc.

[libdefaults]
default_realm = AD.EXAMPLE.COM
forward = true
forwardable = true
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
udp_preference_limit = 1
 
[realms]
AD.EXAMPLE.COM = {
admin_server = ad.example.com
kdc = ad.example.com
}
 
[domain_realm]
 ad.example.com = AD.EXAMPLE.COM
 .ad.example.com = AD.EXAMPLE.COM 

Active Directory Accounts

Kerberos authentication can be enabled at the NODE or PROCESS level. Kerberos enabled at the PROCESS level provides the highest level of security, but may be more difficult to manage from a logistical perspective, particularly if an Informatica Domain contains many nodes and/or has many services.

An Informatica Domain with Kerberos enabled at the NODE level requires a separate Active Directory user for each node process, node running a web process and for each OS Profile user. In addition, an Active Directory user is required for LDAP access.

An Informatica Domain with Kerberos enabled at the PROCESS level requires the same accounts as mentioned above but also requires a separate Active Directory account for each service on each node that service will run on and for each Gateway node where the Admin Console will run.

Each Active Directory account that is used for the node, web process, Admin Console (if PROCESS level is used) or service (if PROCESS level is used) must have a Service Principal Name (SPN) configured in the account. The account should also have a User Principal Name (UPN) that is configured with the same value as the SPN. Users used to access LDAP or for OS Profiles do not require SPNs.

Keytab files enable password-less Kerberos login. Informatica Kerberos Authentication requires that a keytab file be provided for each Active Directory user. The following table shows the account types and the required SPN and keytab naming conventions.

For all Active Directory users, the Active Directory administrators must ensure that “Account is sensitive and cannot be delegated” is not checked for the user. This option can be found in Active Directory on the user properties “Account” tab in the “Account options” section.

The Informatica Domain uses Kerberos Delegation and this requires specific configuration on some of the Active Directory users created for use in the Informatica Domain. For Informatica releases prior to 10.5.1, Full Delegation had to be used.  From 10.5.1 forward, either Full Delegation, Traditional Constrained Delegation or Resource Based Constrained Delegation can be used.  Please refer to the Informatica documentation on configuring the various delegation types in Active Directory.

If the intention is that AES128 and/or AES256 encryption should be used for Kerberos tickets (and this is recommended) then all users in Active Directory that have an associated SPN should have “This account supports Kerberos AES 128 bit encryption” and/or “This account supports Kerberos AES 256 bit encryption” enabled on the “Account tab”-“Account options” section.

The following are sample ktpass commands to create a keytab file for an account that requires an SPN (node, admin console, web app or service) and an account that does not require an SPN (LDAP or OS Profile). These commands would be run by Active Directory administrators on an Active Directory server, after the accounts have been created.

Note that the “-crypto all” instructs ktpass to add entries to the keytab file in all available encryption types. For security purposes, it is recommended that only AES128 and/or AES256 are used. To create a keytab file using ktpass that has entries for either AES128 or AES256 using “-crypto AES128-SHA1” or “-crypto AES256-SHA1” respectively. Ktpass does not provide a method to create a keytab file with both AES128 and AES256 and no other encryption types. If this is desired then the MIT Kerberos utility “ktutil” can be used to either remove extra entries from a keytab file created with the “-crypto all” option, or to combine AES128 and AES256 encrypted keytab files created by two separate executions of ktpass.

Ktpass command for user requiring SPN
 
ktpass -out <Keytab file> -mapuser <AD User> -pass <AD User password> -ptype KRB5_NT_PRINCIPAL -princ <SPN>@<REALM> -crypto all
e.g.
ktpass -out infa_node01.keytab -mapuser infa_node01 -pass <AD User password> -ptype KRB5_NT_PRINCIPAL -princ isp/node01_Example/Domain_Example@REALM.EXAMPLE.COM -crypto all 
 

Ktpass command for user not requiring SPN
 
ktpass -out <Keytab file> -mapuser <AD User> -pass <AD User password> -ptype KRB5_NT_PRINCIPAL -princ <AD User>@<REALM> -crypto all
e.g.
ktpass -out infa_ldapuser.keytab -mapuser ldap_example -pass <Ad User password> -ptype KRB5_NT_PRINCIPAL -princ ldap_example@REALM.EXAMPLE.COM -crypto all 

If an incorrect SPN is created for an Active Directory account then it is necessary to delete that SPN from that account. Running ktpass with the corrected SPN will create an additional SPN and will not delete the incorrect SPN. Informatica will not be able to use the AD account if it has more than one SPN. Use “setspn -L <username>” to view all SPNs associated with an account. Active Directory administrators should run “setspn -D <Bad SPN> <username>” to delete any bad SPNs. Once all bad SPNs are deleted, the ktpass command should be rerun. This will ensure that the User Principal Name (UPN) is set correctly and will generate a new keytab file with the correct SPN.

Verifying Active Directory Accounts

It is important that each of the Active Directory accounts that requires an SPN has only one SPN, that the SPN matches the naming convention above, that the User Principal Name (UPN) for the account matches the SPN and that the SPN is unique in the Active Directory.

Verify the SPN Associated with an Account

The “setspn -L” utility can be used in a Windows command task to list all the SPNs associated with the user provided. This can generally be run by any Windows user on the Active Directory domain on any Windows workstation in that domain. The SPN returned should match the expected naming convention. There should only be one SPN returned, or two SPNs if one is in the format <Expected SPN> and the second is in the format <Expected SPN>@<REALM>. If the returned SPN(s) aren’t in the expected format or if they that don’t meet the expected SPN naming, the account will need to be corrected by an Active Directory administrator before it could be used successfully with Informatica.

Use setspn -L (in a windows command task) to see what SPNs are associated with a user (setspn -L <user>)
 
C:\Users\Administrator>setspn -L infa_node01
Registered ServicePrincipalNames for CN=infa_node01,CN=Users,DC=ad,DC=example,DC=com:
        isp/node01_Example/Domain_Example

Verify that the SPN is only in Use in One Account

Active Directory versions since 2012 R2 do not allow duplicate SPNs.  In the unlikely event that an older version of Active Directory is being used, the “setspn -Q” utility can be used in a Windows command window to verify that the SPN in question is only associated with one user. This can generally be run by any Windows user on the Active Directory domain on any Windows workstation in that domain. The command will return a list of all the accounts that have SPNs that match the SPN provided. If more than one account is returned, or if the account returned does not match the expected account then an Active Directory administrator will need to correct this before the account can be used successfully. Correcting this usually involves removing the SPN from the second account and may also require that the UPN of that account be changed. It is acceptable if two SPNs are returned for the account if one is in the format <Expected SPN> and the other is in the format <Expected SPN>@<REALM>.

Use setspn -Q (in a windows command task) to see what users are associated with an SPN (setspn -Q <SPN>)
 
C:\Users\Administrator>setspn -Q isp/node01_Example/Domain_Example
Checking domain DC=ipsps,DC=informatica,DC=com
CN=infa_node01,CN=Users,DC=ad,DC=example,DC=com
        isp/node01_Example/Domain_Example

Verify that the UPN is only in Use in One Account

Active Directory versions since 2012 R2 do not allow duplicate UPNs.  In the unlikely event that an older version of Active Directory is being used, the Get-ADUser utility can be used in Windows PowerShell with the Active Directory module loaded to verify that the UPN in question is associated with only one user. The command can be used to return a list of all the accounts that match the UPN provided. If more than one account is returned, or if the returned account does not match the account expected then an Active Directory administrator will need to correct this before the account can be used successfully. A situation where more than one account has the same UPN will occur if an SPN is assigned to the wrong account in error using ktpass. If this happens than that user’s UPN is also set incorrectly at that time.

Usually the Get-ADUser utility needs to be run on an Active Directory Domain Controller. On a Windows Active Directory Domain Controller start the “Active Directory Module for Windows PowerShell”.

PS C:\Users\Administrator> Get-ADUser -Filter {userPrincipalName -eq ' isp/node01_Example/Domain_Example@AD.EXAMPLE.COM'}

DistinguishedName : CN=infa_node01,CN=Users,DC=ad,DC=example,DC=com
Enabled           : True
GivenName         :
Name              : infa_node01
ObjectClass       : user
ObjectGUID        : f1f61bb0-ffba-4ba3-8f1f-b19d60af1116
SamAccountName    : infa_node01
SID               : S-1-5-21-3993879487-2454797208-3681979272-1137
Surname           : infa_node01
UserPrincipalName : isp/node01_Example/Domain_Example@AD.EXAMPLE.COM

Verify the SPN Contained in the keytab File

The klist command line utility can be used to list the SPNs contained in a keytab file. This command is part of the MIT Kerberos package and can run on a variety of platforms including Windows and many varieties of Linux/Unix. Note that there is a built in Windows “klist” command that is useful in viewing a user’s Kerberos tickets, but does not allow for viewing keytab file contents. There will be a separate entry for each encryption type available in the keytab file.

Use klist to see the SPNs in the keytab file (klist -e -k -t <keytab_file>)
 
[infa_user@server]$ klist -e -k -t infa_node01.keytab
Keytab name: FILE:infa_node01.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   5 12/31/69 19:00:00 isp/node01_Example/Domain_Example@AD.EXAMPLE.COM (des-cbc-crc)
   5 12/31/69 19:00:00 isp/node01_Example/Domain_Example@ AD.EXAMPLE.COM (des-cbc-md5)
   5 12/31/69 19:00:00 isp/node01_Example/Domain_Example@ AD.EXAMPLE.COM (arcfour-hmac)
   5 12/31/69 19:00:00 isp/node01_Example/Domain_Example@ AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   5 12/31/69 19:00:00 isp/node01_Example/Domain_Example@ AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

Verify that it is Possible to Connect Successfully Using the keytab File

The kinit command line utility can be used to test authentication to Kerberos using a keytab file. This command should be run on the Informatica server. Note that before running the command it is necessary to set the environment variable KRB5_CONFIG to point to the krb5.conf file. Read access on this file is also required. If a successful connection to Kerberos with kinit cannot be established then the account won’t work with the Informatica Domain.

Use kinit to  verify that the keytab file can be used to establish a Kerberos connection (kinit -V -k -t <keytab_file> <SPN>)
 
[infa_user@server]$ kinit -V -k -t infa_node01.keytab isp/node01_Example/Domain_Example
Using default cache: /tmp/krb5cc_515
Using principal: isp/node01_Example/Domain_Example@AD.EXAMPLE.COM
Using keytab: infa_node01.keytab
Authenticated to Kerberos v5

Once a successful Kerberos authentication has been performed, use the kdestroy command to remove the connection cache.

Use kdestroy to remove a connection created by kinit
 
[infa_user@server]$ kdestroy

Copy keytab Files to the Server

Once it has been verified that the keytab files are working correctly they should be copied to the isp/config/keys subdirectory of the Informatica installations. The naming convention for the keytab files is important and must match that described in the table above. For each node, copy the keytab file for that node. If the node will run any web based services (Admin Console, Analyst Service, etc.) then the web keytab file for that server is also required. If the node will be a gateway node then then the LDAP keytab is required. If Kerberos has been enabled at the PROCESS level, then also copy keytab files for each service that will run on that node and copy Admin Console keytab files to all gateway nodes.

Permissions should be set on the keytab files so that they are readable only by the user that runs the Informatica node.

Enable Kerberos on Nodes

Enabling Kerberos is done at the command line using the infasetup.sh utility found in the isp/bin directory under the Informatica install. Shut down all nodes in the Domain before beginning this process. It is important to decide whether Kerberos Authentication should be enabled at the NODE or the PROCESS level.

Once Kerberos is enabled any Informatica Native users will no longer be active. This includes the native Administrator user. For this reason, it is necessary to identify an Active Directory user that will take on the Administrator role. This user is specified in the command to enable Kerberos in the first node. It is best if the user chosen is a human user and not a service account. To access Informatica through the Admin Console and other GUI client tools the user will need to be logged into a Windows client machine. The example below uses “infauser” as the Administrator and is setting Kerberos at the NODE level.

[infa_user@server]$ ./infasetup.sh switchtokerberosmode -ad infauser -srn AD.EXAMPLE.COM -urn AD.EXAMPLE.COM -spnSL NODE
Command ran successfully.

Once Kerberos mode has been enabled through the update to the first node, another command must be run on all other nodes to inform them about the switch to Kerberos. For gateway nodes, the “updategatewaynode” command should be used, for worker nodes the “updateworkernode” command should be used.

[infa_user@server]$ ./infasetup.sh updategatewaynode -krb true -srn AD.EXAMPLE.COM -urn AD.EXAMPLE.COM
Command ran successfully.

Start the Informatica Nodes

Start up the first node and verify that the Administrator Console starts successfully. The Administrator Console login experience will be different once Kerberos is enabled. For users that exist in the default Security Domain, they will be directed directly into the Admin Console, with no login screen. For users not in the default Security Domain, they will be directed to a screen that allows them to choose a Security Domain.  They will choose a Security Domain, click Log In and continue into the Admin Console.

Two new security domains will have been added through the process to enable Kerberos. The first is called _infaInternalNamespace. This is an internal Informatica security domain and will contain only the default Administrator user account used when the infasetup.sh switchtokerberosmode command was run. It is not possible to add additional users to this security domain or to delete it. It will only be visible in the Security Domain dropdown to this Administrator user. The default admin user can be changed by running the infasetup.sh UpdateKerberosAdminUser utility if necessary.

A second security domain with the name of the Kerberos Default Realm will also be created. It cannot be deleted. By default, it will not contain any users or groups. It is possible to add users and groups to this Security Domain using LDAP query syntax, if desired.  Additional security domains can also be created.

Operating System Profiles (OS Profiles)

Operating System Profiles, or OS Profiles, allow Informatica tasks to execute as operating system users other than the user that is running the Informatica node and services. Use of OS Profiles is an important security feature in a shared Informatica environment. OS Profiles allow Informatica Administrators to create isolated execution environments for individual projects or users. If OS Profiles are not enabled then all processes execute as the user that runs the Informatica node. This allows developers who can write and execute command tasks to execute any arbitrary code as the user that runs the Informatica node. Examples of activities that developers could engage in if OS Profiles are not used are:

• Deleting Informatica installation directories and/or files
• Tampering with/replacing Informatica installation files
• Stealing the siteKey file containing the encryption key used to encrypt passwords stored in the Informatica Domain and repository databases and configuration files
• Stealing the nodemeta.xml file that contains encrypted versions of the keystore, truststore and domain database passwords
• Stealing the infa_keystore.jks/pem files that contain the private key used to terminate SSL requests

Stealing the keytab files that allow password-less authentication to Kerberos.

Keytab File for OS Profile User

A valid Active Directory account is required for each OS Profile user. The user does not require an SPN, but it does need to have a keytab file generated to allow password-free authentication to the Active Directory Domain. Ensure that the OS Profile user does not have the “Account is sensitive and cannot be delegated” check box checked in Active Directory. If this box is checked sessions run using this OS Profile user will fail with the error “REP_12400 Repository Error (Unable to get the delegated client credentials. Verify with the Kerberos administrator that the delegation option is enabled for the service principal associated with the Repository Service <PowerCenter Repository Service>. After you enable the delegation option, restart the Repository Service for the changes to take effect.) This error may change in later versions.

Create Directory to Store OS Profile keytab Files, Cache Files and keystore/truststore Files

OS Profile users require a Kerberos credential cache file to execute sessions. This credential cache file needs to be readable by the OS Profile user. The credential cache file should be created by the user running the Informatica node, rather than by the OS Profile user. This removes the requirement that the keytab file be readable by the OS Profile user and allows the Informatica Admin to secure that file so that it can’t be accessed by the OS Profile user. For security reasons, the credential cache file should not be accessible by other users.

Under the default configuration, OS Profile users do not require access to a keystore file. However, if “Enable Data Encryption” is enabled on the Integration Service, and mapping debugger is used or if that Integration Service is connected to a grid, then the OS Profile configuration must include keystore configuration. If SOnG is used then the OS Profile user also requires a custom infa_truststore.pem file that contains the certificates in the standard infa_truststore.pem file and the certificate associated with the OS Profile user’s own infa_keystore.pem file. Below are a set of example commands to create the OS Profile user’s custom infa_keystore.pem and infa_truststore.pem files.

Create a private key
 
[infa_user@server]$ openssl genpkey -algorithm RSA -out osp.key.pem -aes-256-cbc -pkeyopt rsa_keygen_bits:4096 ............................................................................................................++
...............................................++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
 
Create a self-signed certificate
 
[infa_user@server]$ openssl req -new -x509 -key osp.key.pem -out osp.cert.pem -days 1095
Enter pass phrase for osp.key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:State
Locality Name (eg, city) [Default City]:City
Organization Name (eg, company) [Default Company Ltd]:Organization
Organizational Unit Name (eg, section) []:Organizational Unit
Common Name (eg, your name or your server's hostname) []:infa_osp_user
Email Address []: example@organization.com
 
Concatenate the private key and certificate files to create the keystore
[infa_user@server]$ cat osp.key.pem osp.cert.pem > infa_keystore.pem
 
Concatenate the certificate file and standard truststore file to create the truststore
 
[infa_user@server]$ cat osp.cert.pem /opt/app/Informatica/services/shared/security/infa_truststore.pem > infa_truststore.pem
 
Remove the intermediate files
 
[infa_user@server]$ rm osp.key.pem osp.cert.pem

Informatica recommends creating a new directory called os_profiles under the root Informatica installation directory. The permissions on this directory should be “drwxr-xr-x” so that it is accessible by all users, but is only writable by the user running the Informatica node. Create a new OS group with the same name as the OS Profile user, and add the OS Profile user and the user that runs the Informatica node to this group. If more OS Profiles are anticipated than allowed groups per user, then use ACLs instead of groups to configuration directory security.  Under the os_profiles directory, create a sub-directory for each OS Profile user, with the directory name being the OS Profile user’s name. The directory should be owned by the user that runs the Informatica node and the group should be the new group associated with the OS Profile user. The directory permissions should be “drwxrws---“. Place the OS Profile user’s keytab file in the isp/config/keys directory under the Informatica installation. The keytab file should be owned by the user running the Informatica node and its permissions should be “-rw-------“.

[infa_user@server]$ ls -alR
.:
total 16
drwxr-xr-x  3 infa_user infa_user      4096 Sep 25 11:10 .
drwxr-xr-x 17 infa_user infa_user      4096 Aug 21 09:14 ..
-rwxr-xr-x  1 infa_user infa_user      1066 Sep 25 10:16 create_kerberos_cache.sh
drwxrws---  2 infa_user infa_osp_user 4096 Sep 25 11:05 infa_osp_user
 
./infa_osp_user:
total 116
drwxrws--- 2 infa_user infa_osp_user  4096 Sep 25 11:05 .
drwxr-xr-x 3 infa_user infa_user       4096 Sep 25 11:10 ..
-rw-rw---- 1 infa_user infa_osp_user  1403 Sep 25 11:00 infa_osp_user.ccache
-rw-r----- 1 infa_user infa_osp_user 85354 Sep 25 11:00 infa_osp_user.ccache.log
-rw-r----- 1 infa_user infa_osp_user  5609 Sep 25 11:04 infa_keystore.pem
-rw-r----- 1 infa_user infa_osp_user  6541 Sep 25 11:05 infa_truststore.pem

Create Kerberos Login Cache File Script and Schedule

The Informatica OS Profiles process requires that the OS Profile user’s Kerberos credential cache exist before any OS Profiles tasks are executed. To achieve this, it is recommended that the user running the Informatica node have a cron task to create the OS Profile user’s credential cache on some frequency. Note that the default Kerberos ticket life is 10 hours in Windows, though some organizations may use a shorter ticket life than that. The cron task should execute on a frequency to prevent the Kerberos tickets from expiring.

Below is an example script that could be scheduled using cron. The script takes the OS Profile username as its single command line parameter and uses the Kerberos kinit command line utility to establish a Kerberos session for that user. It authenticates to the Active Directory server using a keytab file and creates a credential cache file in the OS Profile user’s cache directory.

[infa_user@server]$ cat create_kerberos_cache.sh
#!/bin/bash
 
# Set custom variables
INFA_HOME=/opt/app/Informatica               # Root directory of Informatica installation
OSP_HOME=${INFA_HOME}/os_profiles                  # Root of OS Profile directories
KEYTAB_HOME=${INFA_HOME}/isp/config/keys           # Directory where keytab files are stored
KRB5_HOME=${INFA_HOME}/service/shared/security     # Directory containing krb5.conf file
KRB5_REALM=AD.EXAMPLE.COM                   # Kerberos Realm
 
# Get OS Profile user
export USER=$1
if [ -z "${USER}" ]; then
    echo "Please provide the OS Profile user as a command line argument, aborting..."
    exit 1
fi
 
# Set location of Kerberos configuration file
export KRB5_CONFIG=${KRB5_HOME}/krb5.conf
 
# Create the credential cache
echo "$(date +"%Y-%m-%d %T"): Creating credential cache for user ${USER}" >> ${OSP_HOME}/${USER}/${USER}.ccache.log
kinit -V -f -k -t ${KEYTAB_HOME}/${USER}.keytab -c ${OSP_HOME}/${USER}/${USER}.ccache ${USER}@${KRB5_REALM} >> ${OSP_HOME}/${USER}/${USER}.ccache.log 2>&1
chmod g+rw ${OSP_HOME}/${USER}/${USER}.ccache

The script could be placed in a location accessible by the user running the Informatica node, (e.g., the os_profiles directory under the Informatica installation directory). It should be owned by the user running the Informatica node and executable by that user. No other user should be able to write to this file.

The following is a sample crontab entry that would recreate the Kerberos credential cache file hourly at the top of the hour.

00 * * * * /opt/app/Informatica/os_profiles/create_kerberos_cache.sh infa_osp_user

Import OS Profile User into Informatica Domain

For OS Profiles to work in a Kerberos enabled Informatica domain it is necessary that each OS Profile operating system user is also a valid Informatica Domain user. To do this, ensure that the user is imported into one of the LDAP Security Domains. The OS Profile user requires no privileges or permissions in the Domain, so it is recommended that the OS Profile users not be included in any groups to which Domain privileges or permissions are granted. Instead they can be imported using a filter that identifies them individually by name.

Create OS Profile in Informatica Domain

OS Profiles are created in a similar fashion as earlier Informatica releases. In a Domain that is Kerberos enabled each OS Profile user requires that several environment variables be set in the OS Profile configuration.