2 Deploying the Connector

Deploying the connector involves the following steps:

• Verifying Deployment Requirements

• Configuring the Target System

• Depending on the release of Oracle Identity Manager that you use, perform the procedures described in one of the following sections:

  • Installing the Connector on Oracle Identity Manager Release 9.1.0 or Later

  • Installing the Connector on Oracle Identity Manager Release 8.5.3.1 Through 9.0.3.x

• Configuring the Oracle Identity Manager Server

2.1 Verifying Deployment Requirements

The following table lists the deployment requirements for the connector.

Item	Requirement
Oracle Identity Manager	Oracle Identity Manager release 8.5.3.1 or later
Target systems	The target system can be any one of the following operating systems that support SSH 2.0: HP-UX 11.11, 11.20 IBM AIX 5L Version 5.2, 5.3 Oracle Enterprise Linux 5.2 Red Hat Enterprise Linux AS 2.1, 3, 4.x, Red Hat Enterprise Linux ES 3, 4.x Solaris 8, 9, 10
External code	JSCAPE SSH/SSH Libraries (SSH factory)
Other systems	OpenSSH, OpenSSL, operating system patches (HP-UX), and SUDO software (only if the SUDO Admin mode is required)
Target system user account	root or sudo user You provide the credentials of this user account while configuring the IT resource. The procedure is described later in this guide. If you do not use a target system user account of the specified type, then an error message similar to the following would be displayed when Oracle Identity Manager tries to exchange data with the target system: SSH_USER_NORIGHTS_FAIL
Character encoding supported by the target system	The target system must support the default C (POSIX) locale. Use the following command to check the locale that the target system supports: locale –a

The supported shell types for various operating systems are given in the following table.

Solaris	HP-UX	Linux	AIX
sh	csh	ksh	csh
csh	ksh	bash	ksh
-	sh	sh	sh
-	-	csh	-

2.2 Configuring the Target System

Configuring the target system involves the steps described in the following sections:

• Platform-Specific Configuration Steps

• Installing External Software

• Public Key Authentication (SSH Key Generation)

2.2.1 Platform-Specific Configuration Steps

This section provides instructions to configure the target system on the following platforms:

• Configuration Steps for Solaris and Linux

• Configuration Steps for AIX

• Configuration Steps for HP-UX

2.2.1.1 Configuration Steps for Solaris and Linux

Perform the following steps for Solaris and Linux environments:

1. Ensure that the /etc/passwd and /etc/shadow files are available on the UNIX server.

2. Create a passwd mirror file on the target server by using a command similar to the following:

   cp /etc/passwd /etc/passwd1
   

   You can specify any destination directory and file name when you run the command. While configuring the IT resource, you specify the name and path of this file as the value of the Passwd Mirror File/User Mirror File parameter of the IT resource for Solaris and Linux.

   Note:

   The administrator account whose credentials you provide as part of the IT resource definition must have read and write permissions on this file.

3. Create a shadow mirror file on the target server by using a command similar to the following:

   cp /etc/shadow /etc/shadow1 
   

   You can specify any destination directory and file name when you run the command. While configuring the IT resource, you specify the name and path of this file as the value of the Shadow Mirror File parameter of the IT resource.

   Note:

   The administrator account whose credentials you provide as part of the IT resource definition must have read and write permissions on this file.

4. For Solaris only:

   If you want to create and use a target system account with the minimum privileges required for connector operations, then perform the procedure described in "Creating a Target System User Account for Connector Operations".

2.2.1.1.1 Creating a Target System User Account for Connector Operations

Oracle Identity Manager uses a target system account for performing reconciliation and provisioning operations. On all supported target systems, this account must be either the root user or sudo user. On Solaris, the role-based access control (RBAC) feature can be applied to create an account and assign to it the minimum privileges required for connector operations. This is an alternative to the use of the root user and sudo user.

Note:

You use the IT resource to specify whether or not you want to use an RBAC user. Parameters of the IT resource are described later in this chapter.

To create a user account with the minimum required privileges:

1. Run the following command to create a role for the user.

   roleadd -d /export/home/ROLE_NAME -m ROLE_NAME
   

   In this command, replace ROLE_NAME with the name that you want to assign to the role, for example, OIMRole.

2. Run the following command to assign a password to the role:

   passwd ROLE_NAME
   

   At the prompt, enter a password for the role.

   See Also:

   Appendix B, "Privileges Required for Performing Provisioning and Reconciliation" for information about the privileges required to run the commands that are used for provisioning and reconciliation

3. Create a profile for the user as follows:

   1. Open the /etc/security/prof_attr file in a text editor and insert the following line in the file:

      PROFILE_NAME:::Oracle Identity Manager Profile:
      

      In this line, replace PROFILE_NAME with the name that you want to assign to the profile, for example, OIMProf.

   2. Save and close the file.

4. Add execution attribute entries in the /etc/security/exec_attr file. Each entry defines a task to be run and the uid that the role will assume when running the task.

   Open the /etc/security/exec_attr file in a text editor, and insert the following lines:

   Note:

   There are seven fields in this file, and the colon (:) is used as the delimiting character.

   On Solaris 10, the value suser can be replaced with solaris.

   Some of the entries contain euid. These instances of euid can be replaced with uid.

   PROFILE_NAME:suser:cmd:::/usr/sbin/usermod:uid=0
   PROFILE_NAME:suser:cmd:::/usr/sbin/useradd:uid=0
   PROFILE_NAME:suser:cmd:::/usr/sbin/userdel:uid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/passwd:uid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/cat:euid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/diff:euid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/sort:euid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/rm:uid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/grep:euid=0
   PROFILE_NAME:suser:cmd:::/usr/bin/egrep:euid=0
   PROFILE_NAME:suser:cmd:::/bin/echo:euid=0
   PROFILE_NAME:suser:cmd:::/bin/sed:euid=0
   

5. Run the following command to associate the profile with the role:

   rolemod -P PROFILE_NAME ROLE_NAME
   

6. Run the following command to create the user:

   useradd -d /export/home/USER_NAME -m USER_NAME
   

7. Run the following command to assign a password to the user:

   passwd USER_NAME
   

8. Run the following command to grant the role to the user:

   usermod -R ROLE_NAME USER_NAME
   

9. To verify the changes that you have made, open the /etc/user_attr file in a text editor and verity that the following entries are present in the file:

   ROLE_NAME::::type=role;profiles=PROFILE_NAME
   USER_NAME::::type=normal;roles=ROLE_NAME
   

2.2.1.2 Configuration Steps for AIX

Perform the following steps for AIX environments:

1. Ensure that the /etc/passwd and /etc/security/user files are available on the server.

2. Create a user mirror file on the server by using a command similar to the following:

   > /etc/mainUserFile1
   

   You can specify any destination directory and file name when you run the command. While configuring the IT resource, you specify the name and path of this file as the value of the Passwd Mirror File/User Mirror File (AIX) parameter of the IT resource for AIX.

   Note:

   • The administrator account whose credentials you provide as part of the IT resource definition must have read and write permissions on this file.

   • For AIX, first-time reconciliation involves reconciliation of all the users present in the target system. This functionality is different from that of other target systems. On other target systems, records of all existing users are fetched from the target system only if you have created the passwd mirror file and the shadow mirror file as empty files.

   • The Update User Login provisioning operation is not supported by default on AIX 4.x and 5.1. However, if you upgrade these versions of AIX to support the useradd, usermod, and userdel commands, then you can perform the Update User Login provisioning operation.

2.2.1.3 Configuration Steps for HP-UX

Perform the following steps for HP-UX environments:

1. If you want to switch to HP-UX Trusted mode, then:

   1. Log in as root and then run the following command:

      /usr/bin/sam
      

      /usr/sbin/sam
      

   2. Select Auditing and Security and then select System Security Policies. A message is displayed asking if you want to switch to the trusted mode.

   3. Click Yes. The following message is displayed:

      System changed successfully to trusted system
      

2. Ensure that the /etc/passwd and /etc/shadow directories are available on the target server.

3. Create a passwd mirror file on the target server by using a command similar to the following:

   cp /etc/passwd /etc/passwd1
   

   You can specify any destination directory and file name when you run the command. While configuring the IT resource, you specify the name and path of this file as the value of the Passwd Mirror File/User Mirror File parameter of the IT resource for HP-UX.

   Note:

   The administrator account whose credentials you provide as part of the IT resource definition must have read and write permissions on this file.

4. Create a shadow mirror file on the target server by using a command similar to the following:

   cp /etc/shadow /etc/shadow1
   

   You can specify any destination directory and file name when you run the command. While configuring the IT resource, you specify the name and path of this file as the value of the Shadow Mirror File parameter of the IT resource.

   Note:

   The administrator account whose credentials you provide as part of the IT resource definition must have read and write permissions on this file.

2.2.2 Installing External Software

This section describes the procedure to install external software.

2.2.2.1 Installing OpenSSH

Follow these steps to install OpenSSH on Solaris 9 or HP-UX.

For Solaris 8 and 9

1. If SSH is not installed on the Solaris server, then install the appropriate OpenSSH.

2. Create a group with the name sshd and group ID 27. Add a user with the name sshadmin to this group.

3. To enable root logins, change the value of PermitRootLogin in the /etc/ssh/sshd_config file as follows:

   PermitRootLogin yes
   

   Note:

   Implement this change only if it does not violate local security policies. If Public Key Authentication is enabled, then you can change the value of PermitRootLogin to without-password.

   Instead of using the root account, if you can use a user account with sudo privileges, then you do not need to perform this step.

For Solaris 10

By default, OpenSSH is installed on Solaris 10. If it is not installed, then install the OpenSSH server from the operating system installation CD. To enable SSH on Solaris 10, make the following changes in the /etc/ssh/ssh_config file:

1. Remove the comment character from the Host * line.

2. To enable root logins, change the value of PermitRootLogin in the /etc/ssh/sshd_config file as follows:

   PermitRootLogin yes
   

   Note:

   Implement this change only if it does not violate local security policies. If Public Key Authentication is enabled, then you can change the value of PermitRootLogin to without-password.

   Instead of using the root account, if you can use a user account with sudo privileges, then you do not need to perform this step.

For HP-UX

If SSH is not installed on the UNIX server, then install the appropriate OpenSSH from the installation media.

For Linux

By default, OpenSSH is installed on Red Hat Advanced Server 2.1 and Red Hat Enterprise Linux 3. If it is not installed, then install the OpenSSH server from the operating system installation CD.

For AIX

If SSH is not installed on the AIX 5.2 server, then from the installation media:

1. Install OpenSSL.

2. Install PRNG.

3. Install OpenSSH.

4. To enable root logins, change the value of PermitRootLogin in the /etc/ssh/sshd_config file as follows:

   PermitRootLogin yes
   

   Note:

   Implement this change only if it does not violate local security policies. If Public Key Authentication is enabled, then you can change the value of PermitRootLogin to without-password.

   Instead of using the root account, if you can use a user account with sudo privileges, then you do not need to perform this step.

2.2.2.2 Installing and Configuring SUDO

If you want to use the SSH connector in the SUDO Admin mode, then perform the following steps to install and configure SUDO:

For Solaris

1. If SUDO is not installed on the Solaris server, then install it from the installation media.

2. Edit the sudoers file on the Solaris server to customize it according to your requirements. This file is located in the following directory:

   /usr/local/etc/
   

   For example, if a group named mqm exists on the Solaris server, and you require all members of the group to act as SUDO users with all possible privileges, then the sudoers file must contain a line similar to the following:

   %mqm ALL= (ALL) ALL
   

   This is only a sample configuration. If you require some other group members or individual users to be SUDO users with specific privileges, then you must edit this file as you did for the sample value mqm.

   This connector uses the following commands:

   • useradd

   • usermod

   • userdel

   • passwd

   • sh

   • cat

   • diff

   • sort

   • rm

   • grep

   • echo

   Therefore, the SUDO user must have privileges to run these commands.

   Caution:

   Do not use the NOPASSWD: ALL option for any SUDO user or group. The connector will not work correctly if the NOPASSWD: ALL is set.

   For information about customizing the sudoers file, refer to:

   http://www.courtesan.com/sudo/man/sudoers.html

3. Edit the same sudoers file so that every time a command is run in SUDO Admin mode, the SUDO user is prompted for the password. Add the following line under the # Defaults specification header:

   Defaults timestamp_timeout=0
   

   This is a prerequisite for this connector to work successfully.

4. Log in to the Solaris computer as root, and enter the following commands:

   chmod 440 /usr/local/etc/sudoers
   chgrp root /usr/local/etc/sudoers
   chmod 4111 /usr/local/bin/sudo
   

5. Create a SUDO user. The SUDO user must be created according to the constraints specified in the sudoers file.

   The SUDO user must always be created with its home directory by using a command similar to the following:

   useradd -g group_name -d /export/home/directory_name -m user_name
   

6. In the sudo user's .profile file, which is created in the sudo user's home directory, add the following lines to set the value of the PATH environment variable:

   PATH=/usr/sbin:/usr/local/bin:/usr/local/etc:/var/adm/sw/products:$PATH 
   export PATH
   

For HP-UX

1. If SUDO is not installed on the HP-UX server, then install the appropriate SUDO from the installation media.

2. Edit the sudoers file to customize it according to your requirements. This file is located in the following directory:

   /usr/local/etc/
   

   For example, if you have a group named mqm on the HP-UX server and you want all members of the group to act as SUDO users with all possible privileges, then the sudoers file must contain the following line:

   %mqm ALL= (ALL) ALL
   

   This is only a sample configuration. If you want to make SUDO users with specific privileges out of other group members or individual users, then edit this file as you did for the sample value mqm.

   This connector uses the following commands:

   • useradd

   • usermod

   • userdel

   • passwd

   • sh

   • cat

   • diff

   • sort

   • rm

   • grep

   • echo

   • modprpw (/usr/lbin/modprpw)

   Therefore, the SUDO user must have the privileges required to run these commands.

   Caution:

   Do not use the NOPASSWD: ALL option for any SUDO user or group. The connector will not work correctly if the NOPASSWD: ALL is set.

   For information about customizing the sudoers file, refer to

   http://www.courtesan.com/sudo/man/sudoers.html

3. Edit the same sudoers file so that every time a command is run in SUDO Admin mode, the SUDO user is prompted for a password. Add the following line under the # Defaults specification header:

   Defaults timestamp_timeout=0
   

   This is an essential prerequisite for the connector to work successfully.

4. Copy the sudoers file that you edited into the /etc directory of the target system. After copying the file, enter the following command:

   dos2ux /etc/sudoers > /etc/sudoers1
   

   Then, change the name of the file from sudoers1 to sudoers.

5. Log in as root, and enter the following commands on the HP-UX computer:

   chmod 440 /etc/sudoers
   chgrp root /etc/sudoers
   chmod 4111 /usr/local/bin/sudo
   

6. Create a SUDO user. The SUDO user should be created according to the constraints specified in the sudoers file.

   The SUDO user should always be created with its home directory by using a command similar to the following:

   useradd -g group_name -d /home/directory_name -m user_name
   

   In addition, in the .profile file, which is created in the home directory, add the following lines to set the appropriate PATH:

   PATH=/usr/sbin:/usr/local/bin:/usr/local/etc:/var/adm/sw/products:$PATH
   export PATH
   

For AIX

1. If SUDO is not installed on AIX 5.2, then install the appropriate SUDO AIX 5.2 version from the installation media.

2. Edit the sudoers file, which is in the /etc directory on the AIX server, to customize the file according to your requirements.

   For example, if you have a group named mqm in the AIX server and require all members of the group to act as SUDO users with all possible privileges, then the sudoers file must contain the following line:

   %mqm ALL= (ALL) ALL
   

   This is only a sample configuration. If you need other group members or individual users to be SUDO users with specific privileges, then edit this file as was done for the sample value mqm.

   This connector uses the following commands:

   • mkuser

   • chuser

   • rmuser

   • lsuser

   • sh

   • cat

   • diff

   • sort

   • rm

   • grep

   • echo

   • sed

   • usermod

   Therefore, the SUDO user must have the privileges required to run these commands.

   Caution:

   Do not use the NOPASSWD: ALL option for any SUDO user or group. The connector will not work correctly if the NOPASSWD: ALL is set.

   For information about customizing the sudoers file, refer to:

   http://www.courtesan.com/sudo/man/sudoers.html

3. Edit the same sudoers file to configure the system, so that every time a command is run through SUDO Admin mode, the SUDO user is prompted for a password. Add the following line under the # Defaults specification header:

   Defaults timestamp_timeout=0

   This is a prerequisite for this connector to work successfully.

4. Create a SUDO user. The SUDO user should be created according to the constraints specified in the sudoers file.

For Red Hat Advanced Server 2.1

1. If SUDO is not installed on the Red Hat Advanced Server 2.1 server, then install the appropriate SUDO. from the installation media.

2. Use the visudo command to edit and customize the /etc/sudoers file according to your requirements.

   Note:

   If you cannot use the visudo command to edit the sudoers file, then:

   1. Enter the following command:

      chmod 777 /etc/sudoers
      

   2. Make the required changes in the sudoers file.

   3. Enter the following command:

      chmod 440 /etc/sudoers
      

   For example, if you have a group named mqm on the Linux server and require all members of the group to act as SUDO users with all possible privileges, then the sudoers file must contain the following line:

   mqm ALL= (ALL) ALL
   

   This example is only a sample configuration. If you need other group members or individual users to be SUDO users with specific privileges, then edit this file as was done for the sample value mqm.

   This connector uses the following commands:

   • useradd

   • usermod

   • userdel

   • passwd

   • sh

   • cat

   • diff

   • sort

   • rm

   • grep

   • echo

   • chage

   Therefore, the SUDO user must have the privileges required to run these commands.

   Caution:

   Do not use the NOPASSWD: ALL option for any SUDO user or group. The connector will not work correctly if the NOPASSWD: ALL is set.

   For information about customizing the sudoers file, refer to:

   http://www.courtesan.com/sudo/man/sudoers.html

3. Edit the same sudoers file to configure the system, so that every time a command is run in SUDO Admin mode, the SUDO user is prompted for a password. Under the # Defaults specification header, add the following line:

   Defaults timestamp_timeout=0
   

   This is a prerequisite for this connector to work successfully.

4. Create a SUDO user as follows:

   1. Enter the following command:

      useradd -g group_name -d /home/directory_name -m user_name
      

      In this command:

      - group_name is the SUDO users group for which there is an entry in the /etc/sudoers file.

      - directory_name is the name of the directory in which you want to create the default directory for the user.

   2. In the .bash_profile file, which is created in the /home/directory_name directory, add the following lines to set the PATH environment variable:

      PATH=/usr/sbin:$PATH
      export PATH
      

For Red Hat Enterprise Linux 3.x and Red Hat Linux 4.x

1. If SUDO is not installed on the Red Hat Enterprise Linux 3.x or 4.x server, then install the appropriate SUDO from the installation media.

2. Use the visudo command to edit and customize the /etc/sudoers file according to your requirements.

   Note:

   If you cannot use the visudo command to edit the sudoers file, then:

   1. Enter the following command:

      chmod 777 /etc/sudoers
      

   2. Make the required changes in the sudoers file.

   3. Enter the following command:

      chmod 440 /etc/sudoers
      

   For example, if you have a group named mqm on the Linux server and want all of the members of the group to act as SUDO users with all possible privileges, then the sudoers file must contain the following line:

   %mqm ALL= (ALL) ALL
   

   This is only a sample configuration. If you want some other group members or individual users to be SUDO users with specific privileges, you must edit this file as was done for the sample value mqm.

   This connector uses the following commands:

   • useradd

   • usermod

   • userdel

   • passwd

   • sh

   • cat

   • diff

   • sort

   • rm

   • grep

   • echo

   • chage

   Therefore, the SUDO user must have the privileges required to run these commands.

   Caution:

   Do not use the NOPASSWD: ALL option for any SUDO user or group. The connector will not work correctly if the NOPASSWD: ALL is set.

   For information about customizing the sudoers file, refer to

   http://www.courtesan.com/sudo/man/sudoers.html

3. Edit the same sudoers file to configure the system, so that every time a command is run in SUDO Admin mode, the SUDO user is prompted for a password. Under the # Defaults specification header, add the following line:

   Defaults timestamp_timeout=0
   

   This is a prerequisite for this connector to work successfully.

4. Create a SUDO user as follows:

   1. Enter the following command:

      useradd -g group_name -d /home/directory_name -m user_name
      

      In this command:

      - group_name is the SUDO users group for which there is an entry in the /etc/sudoers file.

      - directory_name is the name of the directory in which you want to create the default directory for the user.

   2. In the .bash_profile file, which is created in the /home/directory_name directory, add the following lines to set the PATH environment variable:

      PATH=/usr/sbin:$PATH
      export PATH
      

2.2.3 Public Key Authentication (SSH Key Generation)

This section discusses the following topics:

• Configuring Public Key Authentication

• Configuring SSH Public Key Authentication

2.2.3.1 Configuring Public Key Authentication

To configure Public Key Authentication:

Note:

If Public Key Authentication is used, then an RBAC user for a Solaris target mode and the SUDO user for the remaining target systems cannot be used.

1. Copy scripts/privateKeyGen.sh from the installation media directory to any directory on the target system server.

2. Open this script file in a text editor and specify a working directory path other than the default value given in the file.

3. If required, enter the following command:

   For Solaris or Linux:

   dos2unix privateKeyGen.sh privateKeyGen.sh
   

   For HP-UX:

   dos2ux privateKeyGen.sh
   

4. Run the privateKeyGen.sh script on the UNIX server. Provide a secure pass phrase when prompted.

   When these commands are run, the following files are created in the $HOME/.ssh directory:

   • id_rsa: This is a private key file.

   • authorized_keys: This file lists public keys that can be used to log in.

5. When the keys are generated successfully, edit the sshd_config file for Public Key Authentication and test login.

6. After successfully testing login, copy the id_rsa file to the following directory:

   OIM_HOME/xellerate/XLIntegrations/SSH/config
   

   Note:

   This release of the connector has been tested and certified only for RSA keys, and not DSA. In addition, this connector has been tested and certified for only single key configuration and not multiple keys.

2.2.3.2 Configuring SSH Public Key Authentication

To configure SSH Public Key Authentication:

For Solaris

1. Set the following parameters in the /etc/ssh/sshd_config file:

   PubKeyAuthorization yes
   PasswordAuthentication no
   PermitRootLogin yes
   

   Note:

   Change the value of PermitRootLogin to yes only if it does not violate local security policies. If Public Key Authentication is enabled, then you can change the value of PermitRootLogin to without-password.

   Instead of using the root account, if you can use a user account with sudo privileges, then you do not need to perform this step.

2. To restart the SSH server, enter the following commands:

   • /etc/init.d/sshd stop

   • /etc/init.d/sshd start

3. To test login:

   ssh -i /.ssh/id_rsa -l root server_IP_address
   

   This command prompts you for the passkey before setting up the connection.

For HP-UX

1. Uncomment the following lines in the /etc/ssh/sshd_config file:

   PermitRootLogin yes
   PubkeyAuthentication yes
   AuthorizedKeysFile .ssh/authorized_keys
   

   Note:

   Change the value of PermitRootLogin to yes only if it does not violate local security policies. If Public Key Authentication is enabled, then you can change the value of PermitRootLogin to without-password.

   Instead of using the root account, if you can use a user account with sudo privileges, then you do not need to perform this step.

2. To restart the SSH Server, enter the following command:

   /opt/ssh/sbin/sshd
   

3. To test login, enter the following command:

   ssh -i /.ssh/id_rsa -l root server_IP_address
   

   When prompted, enter the passkey to connect to the server.

For Linux

1. Enter the following commands at the UNIX server prompt:

   ssh-keygen -q -f $HOME /.ssh/id_rsa -t rsa 
   cd $HOME/.ssh
   cat id_rsa.pub >> authorized_keys
   chmod 700 authorized_keys
   

   You are prompted to enter a passphrase when you enter these commands. You can press Enter if you do not want to use a passphrase.

2. Add the following line in the /etc/ssh/sshd_config file:

   AuthorizedKeysFile      /.ssh/id_rsa.pub
   

3. Enter the following commands to restart the UNIX server:

   /etc/init.d/sshd stop
   /etc/init.d/sshd start
   

4. Copy the /.ssh/id_rsa file to the following directory:

   OIM_HOME/xellerate/XLIntegrations/SSH/config
   

5. To check if you can connect to the target system using the SSH protocol, directly from the command prompt and without using a password, enter the following command:

   Note:

   The account used to run the OIM application server on UNIX should have the ownership of the id_rsa file.

   ssh -i OIM_HOME/xellerate/XLIntegratrions/SSH/config/id_rsa root - i lhost_ip_address
   

6. When you configure the IT resource, provide the name and full path of the id_rsa file as the value of the Private Key parameter:

   OIM_HOME/xellerate/XLIntegrations/SSH/config/id_rsa
   

For AIX

1. The first step of this procedure depends on the version of AIX that you are using:

   • For AIX 4.3, use the /etc/openssh/sshd_config file to set the following parameters:

     export PATH=$PATH: /usr/local/bin
     Installation path: /etc/openssh/
     sshd -- /usr/local/bin/
     

   • For AIX 5.2, use the /etc/ssh/sshd_config file to set the following parameters:

     export PATH=$PATH: /usr/sbin
     Installation path: /etc/ssh/
     sshd -- /usr/sbin/
     

2. Open the /etc/ssh/sshd_config file, and uncomment the following lines:

   AuthorizedKeysFile .ssh/authorized_keys
   PermitRootLogin yes
   PubkeyAuthentication yes
   

   Note:

   Change the value of PermitRootLogin to yes only if it does not violate local security policies. If Public Key Authentication is enabled, then you can change the value of PermitRootLogin to without-password.

   Instead of using the root account, if you can use a user account with sudo privileges, then you do not need to perform this step.

3. To restart the SSH server, enter the following commands:

   • /opt/ssh/sbin/sshd (For AIX 4.3)

   • /usr/sbin/sshd (For AIX 5.2)

4. To test the login, enter the following command:

   ssh -i /.ssh/id_rsa -l root server_IP_address
   

   When prompted, enter the passkey to connect to the server.

   Note:

   This release of the connector does not support Public Key Authentication provisioning if it is implemented through the SUDO Admin mode. The Public Key Authentication used for system access is available for the root user. This point is also mentioned in the Known Issues list in Chapter 5.

2.3 Installing the Connector on Oracle Identity Manager Release 9.1.0 or Later

Note:

In this guide, the term Connector Installer has been used to refer to the Connector Installer feature of the Oracle Identity Manager Administrative and User Console.

Installing the connector on Oracle Identity Manager release 9.1.0 or later involves the following procedures:

• Running the Connector Installer

• Configuring the IT Resource

2.3.1 Running the Connector Installer

To run the Connector Installer:

1. Copy the contents of the connector installation media into the following directory:

   OIM_HOME/xellerate/ConnectorDefaultDirectory
   

2. Log in to the Administrative and User Console by using the user account described in the "Creating the User Account for Installing Connectors" section of Oracle Identity Manager Administrative and User Console.

3. Click Deployment Management, and then click Install Connector.

4. From the Connector List list, select UNIX SSH RELEASE_NUMBER. This list displays the names and release numbers of connectors whose installation files you copy into the default connector installation directory:

   OIM_HOME/xellerate/ConnectorDefaultDirectory 
   

   If you have copied the installation files into a different directory, then:

   1. In the Alternative Directory field, enter the full path and name of that directory.

   2. To repopulate the list of connectors in the Connector List list, click Refresh.

   3. From the Connector List list, select UNIX SSH RELEASE_NUMBER.

5. Click Load.

6. To start the installation process, click Continue.

   The following tasks are performed in sequence:

   1. Configuration of connector libraries

   2. Import of the connector Target Resource user configuration XML file (by using the Deployment Manager). If you want to import the target system as a trusted source for reconciliation, then see "Configuring the Target System As a Trusted Source".

   3. Compilation of adapters

   On successful completion of a task, a check mark is displayed for the task. If a task fails, then an X mark and a message stating the reason for failure are displayed. Depending on the reason for the failure, make the required correction and then perform one of the following steps:

   • Retry the installation by clicking Retry.

   • Cancel the installation and begin again from Step 0.

7. If all three tasks of the connector installation process are successful, then a message indicating successful installation is displayed. In addition, a list of the steps that you must perform after the installation is displayed. These steps are as follows:

   1. Ensuring that the prerequisites for using the connector are addressed

      Note:

      At this stage, run the PurgeCache utility to load the server cache with content from the connector resource bundle in order to view the list of prerequisites. Refer to "Clearing Content Related to Connector Resource Bundles from the Server Cache" for information about running the PurgeCache utility.

      There are no prerequisites for some predefined connectors.

   2. Configuring the IT resource for the connector

      Record the name of the IT resource displayed on this page. The procedure to configure the IT resource is described later in this guide.

   3. Configuring the scheduled tasks that are created when you installed the connector

      Record the names of the scheduled tasks displayed on this page. The procedure to configure these scheduled tasks is described later in this guide.

When you run the Connector Installer, it copies the connector files and external code files to destination directories on the Oracle Identity Manager host computer. These files are listed in Table 1-1.

Installing the Connector in an Oracle Identity Manager Cluster

While installing Oracle Identity Manager in a clustered environment, you must copy all the JAR files and the contents of the connectorResources directory into the corresponding directories on each node of the cluster. See "Files and Directories on the Installation Media" for information about the files that you must copy and their destination locations on the Oracle Identity Manager server.

2.3.2 Configuring the IT Resource

Note:

Perform this procedure if you are installing the connector on Oracle Identity Manager release 9.1.0 or later.

You must specify values for the parameters of the SSH IT resource as follows:

1. Log in to the Administrative and User Console.

2. Expand Resource Management.

3. Click Manage IT Resource.

4. In the IT Resource Name field on the Manage IT Resource page, enter SSH and then click Search.

5. Click the edit icon for the IT resource.

6. From the list at the top of the page, select Details and Parameters.

7. Specify values for the parameters of the IT resource. The following table describes each parameter:

   Parameter	Description and Sample Value
   Admin UserId	User ID of the administrator root or jdoe Here, jdoe can be the SUDO user ID, for the SUDO Admin mode. Alternatively, on Solaris, it can be the user ID of the account to which you assign the minimum privileges required to perform connector operations. See "Creating a Target System User Account for Connector Operations" for more information.
   Admin Password/Private file Pwd	Password of the administrator Note: For the SUDO Admin mode, the private key is not supported. Specify a password for this mode as the value of the parameter. If a private key is used, then enter the private key passphrase as the value of the parameter. For the Solaris target system, if an RBAC user is used, then enter the RBAC user's password as the value of the parameter.
   Server IP Address	Server IP address
   Port	The port at which the SSH service is running on the server Default value: 22
   Private Key	Private key file name with full path Note: For SUDO Admin administrator, this parameter must be left blank.
   Server OS	Specify one of the following: AIX HP-UX SOLARIS LINUX
   Shell Prompt	# or $
   Whether Trusted System (HP-UX)	YES (for trusted HP-UX System) or NO (for non-trusted HP-UX system)
   Sudo Or RBAC	Enter one of the following values: None: Specifies the root user. Sudo: Specifies the sudo user. RBAC: Specifies the RBAC user. See "Creating a Target System User Account for Connector Operations" for more information.
   Max Retries	Number of times that the connector must retry connecting to the target server if the connection fails Default value: 2
   Delay	Delay (in milliseconds) before the connector attempts to retry connecting to the target system, if the connection fails Default value: 10000
   Timeout	Value of the timeout (in milliseconds) for the connection to the target server Default value: 20000
   Passwd Mirror File/User Mirror File	Name and full path of the password mirror file/user mirror file The SUDO user must have read and write permissions on this file. For example, suppose you run the following command to view the permissions on the mirror file: $ ls -ltr passwd1 The command generates the following output: -rwxr--r-- 1 janedoe mqm 9972 Mar 11 20:35 passwd1 In this output, janedoe is the SUDO user. Sample value for this attribute: /etc/passwd1
   Shadow Mirror File	Name of the shadow mirror file The SUDO user must have read and write permissions on this file. For example, suppose you run the following command to view the permissions on the mirror file: $ ls -ltr shadow1 The command generates the following output: -rwxr--r-- 1 janedoe mqm 9972 Mar 11 20:35 shadow1 In this output, janedoe is the SUDO user. Note: This attribute is not required on AIX. The value of this attribute must not be null or blank, even for an HP-UX trusted system. However, the reconciliation process on an HP-UX trusted system ignores this attribute. Sample value: /etc/shadow1
   Target Date Format	This parameter is used to specify the date format of the target UNIX computer. The default value for this parameter is: MMddhhmmyy This parameter is used for user reconciliation.
   Protocol	Default value: SSH Do not change this default value.
   RBAC Role Name	If you specify RBAC as the value of the Sudo Or RBAC parameter, then enter the name of the role assigned to the RBAC user. Otherwise, do not specify a value for this parameter. See "Creating a Target System User Account for Connector Operations" for more information.
   RBAC Role Passwd	If you specify RBAC as the value of the Sudo Or RBAC parameter, then enter the password of the role assigned to the RBAC user. Otherwise, do not specify a value for this parameter. See "Creating a Target System User Account for Connector Operations" for more information.

   
   

8. To save the values, click Save.

2.4 Installing the Connector on Oracle Identity Manager Release 8.5.3.1 Through 9.0.3.x

Installing the connector on any Oracle Identity Manager release between releases 8.5.3.1 and 9.0.3.x involves the following procedures:

• Copying the Connector Files

• Importing the Connector XML Files

2.4.1 Copying the Connector Files

The connector files to be copied and the directories to which you must copy them are given in the following table.

See Also:

"Files and Directories on the Installation Media" section for more information about these files

File in the Installation Media Directory	Destination Directory
Files in the config directory	OIM_HOME/xellerate/XLIntegrations/SSH/config
ext/sshfactory.jar	OIM_HOME/xellerate/ThirdParty
lib/xliSSH.jar	OIM_HOME/xellerate/JavaTasks OIM_HOME/xellerate/ScheduleTask
Files in the resources directory	OIM_HOME/xellerate/connectorResources
Files in the scripts directory	OIM_HOME/xellerate/XLIntegrations/SSH/scripts
Files and directories in the test directory	OIM_HOME/xellerate/XLIntegrations/SSH
Files in the xml directory	OIM_HOME/xellerate/XLIntegrations/SSH/xml

Note:

In a clustered environment, copy the JAR files and the contents of the connectorResources directory to the corresponding directories on each node of the cluster.

2.4.2 Importing the Connector XML Files

To import the connector XML files:

1. Open the Oracle Identity Manager Administrative and User Console.

2. Click the Deployment Management link on the left navigation bar.

3. Click the Import link under Deployment Management. A dialog box for opening files is displayed.

4. Locate and open the SSHNonTrustedUser.xml file, which is in the OIM_HOME/xellerate/XLIntegrations/SSH/xml directory. Details of this XML file are shown on the File Preview page.

5. Click Add File. The Substitutions page is displayed.

6. Click Next. The Confirmation page is displayed.

7. Click Next. The Provide IT Resource Instance Data page for the SSH IT resource is displayed.

8. Specify values for the parameters of the SSH IT resource. Refer to the following table for information about the values to be specified:

   Parameter	Description and Sample Value
   Admin UserId	User ID of the administrator root or jdoe Here, jdoe can be the SUDO user ID, for the SUDO Admin mode. Alternatively, on Solaris, it can be the user ID of the account to which you assign the minimum privileges required to perform connector operations. See "Creating a Target System User Account for Connector Operations" for more information.
   Admin Password/Private file Pwd	Password of the administrator Note: For the SUDO Admin mode, the private key is not supported. Specify a password for this mode as the value of the parameter. If a private key is used, then enter the private key passphrase as the value of the parameter. For the Solaris target system, if an RBAC user is used, then enter the RBAC user's password as the value of the parameter.
   Server IP Address	Server IP address
   Port	The port at which the SSH service is running on the server Default value: 22
   Private Key	Private key file name with full path Note: For SUDO Admin administrator, this parameter must be left blank.
   Server OS	Specify one of the following: AIX HP-UX SOLARIS LINUX
   Shell Prompt	# or $
   Whether Trusted System (HP-UX)	YES (for trusted HP-UX System) or NO (for non-trusted HP-UX system)
   Sudo Or RBAC	Enter one of the following values: None: Specifies the root user. Sudo: Specifies the sudo user. RBAC: Specifies the RBAC user. See "Creating a Target System User Account for Connector Operations" for more information.
   Max Retries	Number of times that the connector must retry connecting to the target server if the connection fails Default value: 2
   Delay	Delay (in milliseconds) before the connector attempts to retry connecting to the target system, if the connection fails Default value: 10000
   Timeout	Value of the timeout (in milliseconds) for the connection to the target server Default value: 20000
   Passwd Mirror File/User Mirror File	Name of the password mirror file/user mirror file. The user must have read and write permissions on this file. The sample value for this parameter is: /etc/passwd1 This parameter is used for user reconciliation.
   Shadow Mirror File	Name of the shadow mirror file The SUDO user must have read and write permissions on this file. For example, suppose you run the following command to view the permissions on the mirror file: $ ls -ltr shadow1 The command generates the following output: -rwxr--r-- 1 janedoe mqm 9972 Mar 11 20:35 shadow1 In this output, janedoe is the SUDO user. Note: This attribute is not required on AIX. The value of this attribute must not be null or blank, even for an HP-UX trusted system. However, the reconciliation process on an HP-UX trusted system ignores this attribute. Sample value: /etc/shadow1
   Target Date Format	This parameter is used to specify the date format of the target UNIX computer. The default value for this parameter is: MMddhhmmyy This parameter is used for user reconciliation.
   Protocol	Default value: SSH Do not change this default value.
   RBAC Role Name	If you specify RBAC as the value of the Sudo Or RBAC parameter, then enter the name of the role assigned to the RBAC user. Otherwise, do not specify a value for this parameter.
   RBAC Role Passwd	If you specify RBAC as the value of the Sudo Or RBAC parameter, then enter the password of the role assigned to the RBAC user. Otherwise, do not specify a value for this parameter.

   
   

9. Click Next. The Provide IT Resource Instance Data page for a new instance of the SSH Server IT resource type is displayed.

10. Click Skip to specify that you do not want to define another IT resource. The Confirmation page is displayed.

    See Also:

    If you want to define another IT resource, then refer to Oracle Identity Manager Administrative and User Console Guide for instructions.

11. Click View Selections.

    The contents of the XML file are displayed on the Import page. You may see a cross-shaped icon along with some nodes. These nodes represent Oracle Identity Manager entities that are redundant. Before you import the connector XML file, you must remove these entities by right-clicking each node and then selecting Remove.

12. Click Import. The connector file is imported into Oracle Identity Manager.

2.5 Configuring the Oracle Identity Manager Server

Configuring the Oracle Identity Manager server involves the following procedures:

Note:

In a clustered environment, you must perform this step on each node of the cluster.

• Changing to the Required Input Locale

• Clearing Content Related to Connector Resource Bundles from the Server Cache

• Enabling Logging

2.5.1 Changing to the Required Input Locale

Changing to the required input locale (language and country setting) involves installing the required fonts and setting the required input locale.

You may require the assistance of the system administrator to change to the required input locale.

2.5.2 Clearing Content Related to Connector Resource Bundles from the Server Cache

While performing the instructions described in the "Copying the Connector Files" section, you copy files from the resources directory on the installation media into the OIM_HOME/xellerate/connectorResources directory. Whenever you add a new resource bundle in the connectorResources directory or make a change in an existing resource bundle, you must clear content related to connector resource bundles from the server cache.

To clear content related to connector resource bundles from the server cache:

1. In a command window, change to the OIM_HOME/xellerate/bin directory.

   Note:

   You must perform Step 1 before you perform Step 2. An exception is thrown if you run the command described in Step 2 as follows:

   OIM_HOME/xellerate/bin/batch_file_name
   

2. Enter one of the following commands:

   • On Microsoft Windows:

     PurgeCache.bat ConnectorResourceBundle
     

   • On UNIX:

     PurgeCache.sh ConnectorResourceBundle
     

   Note:

   You can ignore the exception that is thrown when you perform Step 2.

   In this command, ConnectorResourceBundle is one of the content categories that you can remove from the server cache. Refer to the following file for information about the other content categories:

   OIM_HOME/xellerate/config/xlConfig.xml
   

2.5.3 Enabling Logging

When you enable logging, Oracle Identity Manager automatically stores in a log file information about events that occur during the course of provisioning and reconciliation operations. To specify the type of event for which you want logging to take place, you can set the log level to one of the following:

• ALL

  This level enables logging for all events.

• DEBUG

  This level enables logging of information about fine-grained events that are useful for debugging.

• INFO

  This level enables logging of messages that highlight the progress of the application at a coarse-grained level.

• WARN

  This level enables logging of information about potentially harmful situations.

• ERROR

  This level enables logging of information about error events that may allow the application to continue running.

• FATAL

  This level enables logging of information about very severe error events that could cause the application to stop functioning.

• OFF

  This level disables logging for all events.

The file in which you set the log level depends on the application server that you use:

• BEA WebLogic Server

  To enable logging:

  1. Add the following line in the OIM_HOME/xellerate/config/log.properties file:

     log4j.logger.OIMCP.TELNETSSH=log_level
     

  2. In this line, replace log_level with the log level that you want to set.

     For example:

     log4j.logger.OIMCP.TELNETSSH=INFO
     

  After you enable logging, log information is displayed on the server console.

• IBM WebSphere Application Server

  To enable logging:

  1. Add the following line in the OIM_HOME/xellerate/config/log.properties file:

     log4j.logger.OIMCP.TELNETSSH=log_level
     

  2. In this line, replace log_level with the log level that you want to set.

     For example:

     log4j.logger.OIMCP.TELNETSSH=INFO
     

  After you enable logging, log information is written to the following file:

  WEBSPHERE_HOME/AppServer/logs/SERVER_NAME/SystemOut.log
  

• JBoss Application Server

  To enable logging:

  1. In the JBOSS_HOME/server/default/conf/log4j.xml file, add the following lines if they are not already present in the file:

     <category name="OIMCP.TELNETSSH">
        <priority value="log_level"/>
     </category>
     

  2. In the second XML code line, replace log_level with the log level that you want to set. For example:

     <category name="OIMCP.TELNETSSH">
        <priority value="INFO"/>
     </category>
     

  After you enable logging, log information is written to the following file:

  JBOSS_HOME/server/default/log/server.log
  

• Oracle Application Server

  To enable logging:

  1. Add the following line in the OIM_HOME/xellerate/config/log.properties file:

     log4j.logger.OIMCP.TELNETSSH=log_level
     

  2. In this line, replace log_level with the log level that you want to set.

     For example:

     log4j.logger.OIMCP.TELNETSSH=INFO
     

  After you enable logging, log information is written to the following file:

  ORACLE_HOME/opmn/logs/default_group~home~default_group~1.log