This chapter is divided into the following sections:
Section 2.1, "Files and Directories on the Installation Media"
Section 2.2, "Determining the Release Number of the Connector"
Section 2.4, "Installing the Connector on Oracle Identity Manager Release 9.1.0.x or Release 11.1.1"
Section 2.5, "Configuring the Oracle Identity Manager Server"
The files and directories on the installation media are listed and described in Table 2-1.
Table 2-1 Files and Directories on the Installation Media
| File in the Installation Media Directory | Description |
|---|---|
|
configuration/UNIX SSH-CI.xml |
This XML file contains configuration information that is used during connector installation. |
|
ext/sshfactory.jar |
This file contains the JSCAPE libraries. These libraries are used to open an SSH session with the target server. During connector deployment, this file is copied to the following location:
|
|
lib/xliSSH.jar |
This JAR file contains the Java classes that are required for provisioning and reconciliation in SSH. During connector deployment, this file is copied to the following location:
|
|
Files in the resources directory |
Each of these resource bundles contains language-specific information that is used by the connector. During connector installation, these resource bundles are copied to the following location:
Note: A resource bundle is a file containing localized versions of the text strings that are displayed on the Administrative and User Console. These text strings include GUI element labels and messages. |
|
scripts/privateKeyGen.sh |
This file is used to generate the private key in SSH. |
|
scripts/sudoers |
This file contains the SUDO user specifications and configurations. |
|
test/config/config.properties |
This file is used to specify the parameters and settings required to connect to the target system by using the testing utility. |
|
test/config/log.properties |
This file is used to specify the log level and the directory in which the log file is to be created when you run the testing utility. |
|
config/userAttribute_NonAIX_prov.properties |
This file contains the parameters required for dynamic provisioning on non-AIX platforms. |
|
config/userAttribute_AIX_prov.properties |
This file contains the parameters required for dynamic provisioning on AIX platform. |
|
config/userAttribute_NonAIX_recon.properties |
This file contains the parameters required for dynamic reconciliation on non-AIX platforms. |
|
config/userAttribute_AIX_recon.properties |
This file contains the parameters required for dynamic reconciliation on AIX platform. |
|
test/scripts/SSH.bat test/scripts/SSH.sh |
This file contains the script required to run the client for running test calls from the Oracle Identity Manager server. |
|
xml/SSHNonTrustedUser.xml |
This XML file contains definitions for the following SSH User components of the connector:
|
|
xml/XellSSHUser.xml |
This XML file contains the configuration for the Xellerate User (OIM User) and the definition of the trusted source reconciliation schedule task. You must import this file only if you plan to use the connector for trusted source reconciliation. |
|
xml/SSHConnectorRequestDatasets.xml |
This file contains the request datasets for the connector. You import this file by using the Deployment Manager. |
Note:
If you are using Oracle Identity Manager release 9.1.0.x, then the procedure described in this section is optional.
If you are using Oracle Identity Manager release 11.1.1, then skip this section.
You might have a deployment of an earlier release of the connector. While deploying the latest release, you might want to know the release number of the earlier release. To determine the release number of the connector that has already been deployed:
In a temporary directory, extract the contents of the following JAR file:
OIM_HOME/xellerate/JavaTasks/xliSSH.jar
Open the manifest.mf file in a text editor. The manifest.mf file is one of the files bundled inside the xliSSH.jar file.
In the manifest.mf file, the release number of the connector is displayed as the value of the Version property.
Configuring the target system involves the steps described in the following sections:
Section 2.3.3, "Creating a Target System User Account for Connector Operations"
Section 2.3.4, "Public Key Authentication (SSH Key Generation)"
This section provides instructions to configure the target system on the following platforms:
Perform the following steps for Solaris and Linux environments:
Ensure that the /etc/passwd and /etc/shadow files are available on the UNIX server.
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.
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.
Perform the following steps for AIX environments:
Ensure that the /etc/passwd and /etc/security/user files are available on the server.
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.
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.
Perform the following steps for HP-UX environments:
If you want to switch to HP-UX Trusted mode, then:
Note:
If you are converting the target system to the trusted system, then please make sure that no shadow file exists on the target after it is converted to trusted system.You can use pwunconv command to get rid of the shadow file, if it exists.
Log in as root and then run the following command:
/usr/bin/sam
/usr/sbin/sam
Select Auditing and Security and then select System Security Policies. A message is displayed asking if you want to switch to the trusted mode.
Click Yes. The following message is displayed:
System changed successfully to trusted system
Ensure that the /etc/passwd and /etc/shadow directories are available on the target server.
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.
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.
Follow these steps to install OpenSSH on Solaris 9 or HP-UX.
If SSH is not installed on the Solaris server, then install the appropriate OpenSSH.
Create a group with the name sshd and group ID 27. Add a user with the name sshadmin to this group.
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.
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:
Remove the comment character from the Host * line.
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.
If SSH is not installed on the UNIX server, then install the appropriate OpenSSH from the installation media.
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.
If SSH is not installed on the AIX 5.2 server, then from the installation media:
Install OpenSSL.
Install PRNG.
Install OpenSSH.
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.
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. However, on Solaris, you can either create a sudo user or apply the role-based access control (RBAC) feature to create an account and assign to it the minimum privileges required for connector operations.
To create a target system user account with the minimum permissions required to perform connector operations, perform the procedure described in one of the following sections:
Section 2.3.3.1, "Creating a Target System User Account for Connector Operations on Solaris"
Section 2.3.3.2, "Creating a Target System User Account for Connector Operations on HP-UX"
Section 2.3.3.3, "Creating a Target System User Account for Connector Operations on AIX"
As mentioned earlier, on Solaris, you can either create a sudo user or apply the RBAC feature to create an account and assign to it the minimum privileges required for connector operations. Depending on your requirement, perform the instructions described in one of the following sections:
Section 2.3.3.1.1, "Creating a Sudo User for Connector Operations"
Section 2.3.3.1.2, "Creating an RBAC User Account for Connector Operations"
If you want to create a sudo user and use the SSH connector in the SUDO Admin mode, then perform the following steps:
If SUDO is not installed on the Solaris server, then install it from the installation media.
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:
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.
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
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
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
In the sudo user's .bashrc, .cshrc, or .kshrc file, which is created in the sudo user's home directory, add the following line to change the prompt end character from $ (dollar sign) to # (pound sign):
PS1="[\\u@\\h:\\w]#"
The encrypted passwords in the shadow file contain # (dollar sign), which matches the default prompt end character. You must change the prompt end character to ensure that changes made to the shadow file are reconciled correctly.
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 an RBAC user account:
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.
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 A, "Privileges Required for Performing Provisioning and Reconciliation" for information about the privileges required to run the commands that are used for provisioning and reconciliation
Create a profile for the user as follows:
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.
Save and close the file.
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
Run the following command to associate the profile with the role:
rolemod -P PROFILE_NAME ROLE_NAME
Run the following command to create the user:
useradd -d /export/home/USER_NAME -m USER_NAME
Run the following command to assign a password to the user:
passwd USER_NAME
Run the following command to grant the role to the user:
usermod -R ROLE_NAME USER_NAME
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
If you want to create a sudo user and use the SSH connector in the SUDO Admin mode, then perform the following steps:
If SUDO is not installed on the HP-UX server, then install the appropriate SUDO from the installation media.
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
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.
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.
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
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
In the sudo user's .bashrc, .cshrc, or .kshrc file, which is created in the sudo user's home directory, add the following line to change the prompt end character from $ (dollar sign) to # (pound sign):
PS1="[\\u@\\h:\\w]#"
The encrypted passwords in the shadow file contain # (dollar sign), which matches the default prompt end character. You must change the prompt end character to ensure that changes made to the shadow file are reconciled correctly.
If you want to create a sudo user and use the SSH connector in the SUDO Admin mode, then perform the following steps:
If SUDO is not installed on AIX 5.2, then install the appropriate SUDO AIX 5.2 version from the installation media.
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:
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.
Create a SUDO user. The SUDO user should be created according to the constraints specified in the sudoers file.
In the sudo user's .bashrc, .cshrc, or .kshrc file, which is created in the sudo user's home directory, add the following line to change the prompt end character from $ (dollar sign) to # (pound sign):
PS1="[\\u@\\h:\\w]#"
The encrypted passwords in the shadow file contain # (dollar sign), which matches the default prompt end character. You must change the prompt end character to ensure that changes made to the shadow file are reconciled correctly.
If you want to create a sudo user and use the SSH connector in the SUDO Admin mode, then perform the following steps:
If SUDO is not installed on the Red Hat Advanced Server 2.1 server, then install the appropriate SUDO. from the installation media.
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:
Enter the following command:
chmod 777 /etc/sudoers
Make the required changes in the sudoers file.
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:
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.
Create a SUDO user as follows:
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.
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
In the sudo user's .bashrc, .cshrc, or .kshrc file, which is created in the sudo user's home directory, add the following line to change the prompt end character from $ (dollar sign) to # (pound sign):
PS1="[\\u@\\h:\\w]#"
The encrypted passwords in the shadow file contain # (dollar sign), which matches the default prompt end character. You must change the prompt end character to ensure that changes made to the shadow file are reconciled correctly.
If you want to create a sudo user and use the SSH connector in the SUDO Admin mode, then perform the following steps:
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.
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:
Enter the following command:
chmod 777 /etc/sudoers
Make the required changes in the sudoers file.
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
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.
Create a SUDO user as follows:
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.
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
In the sudo user's .bashrc, .cshrc, or .kshrc file, which is created in the sudo user's home directory, add the following line to change the prompt end character from $ (dollar sign) to # (pound sign):
PS1="[\\u@\\h:\\w]#"
The encrypted passwords in the shadow file contain # (dollar sign), which matches the default prompt end character. You must change the prompt end character to ensure that changes made to the shadow file are reconciled correctly.
This section discusses the following topics:
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.
Copy the scripts/privateKeyGen.sh file from the installation media directory to any directory on the target system server.
Open this script file in a text editor and specify a working directory path other than the default value given in the file.
If required, enter the following command:
For Solaris or Linux:
dos2unix privateKeyGen.sh privateKeyGen.sh
For HP-UX:
dos2ux privateKeyGen.sh
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.
When the keys are generated successfully, edit the sshd_config file for Public Key Authentication and test login.
After successfully testing login, depending on the Oracle Identity Manager release that you are using, copy the id_rsa file to one of the following directories:
For Oracle Identity Manager release 9.1.0.x:
OIM_HOME/xellerate/XLIntegrations/SSH/config
For Oracle Identity Manager release 11.1.1:
OIM_HOME/server/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.
To configure SSH Public Key Authentication:
For Solaris
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.
To restart the SSH server, enter the following commands:
/etc/init.d/sshd stop
/etc/init.d/sshd start
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
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.
To restart the SSH Server, enter the following command:
/opt/ssh/sbin/sshd
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
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.
Add the following line in the /etc/ssh/sshd_config file:
AuthorizedKeysFile /.ssh/id_rsa.pub
Enter the following commands to restart the UNIX server:
/etc/init.d/sshd stop /etc/init.d/sshd start
Depending on the Oracle Identity Manager release that you are using, copy the /.ssh/id_rsa file to the following directory:
For Oracle Identity Manager release 9.1.0.x:
OIM_HOME/xellerate/XLIntegrations/SSH/config
For Oracle Identity Manager release 11.1.1:
OIM_HOME/server/XLIntegrations/SSH/config
To check if you can connect to the target system using the SSH protocol, directly from the command prompt and without using a password, depending on the Oracle Identity Manager release that you are using, 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.
For Oracle Identity Manager release 9.1.0.x:
ssh -i OIM_HOME/xellerate/XLIntegratrions/SSH/config/id_rsa root - i lhost_ip_address
For Oracle Identity Manager release 11.1.1:
ssh -i OIM_HOME/server/XLIntegratrions/SSH/config/id_rsa root - i lhost_ip_address
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:
For Oracle Identity Manager release 9.1.0.x:
OIM_HOME/xellerate/XLIntegrations/SSH/config/id_rsa
For Oracle Identity Manager release 11.1.1:
OIM_HOME/server/XLIntegrations/SSH/config/id_rsa
For AIX
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/
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.
To restart the SSH server, enter the following commands:
/opt/ssh/sbin/sshd (For AIX 4.3)
/usr/sbin/sshd (For AIX 5.2)
/usr/sbin/sshd (For AIX 6.1)
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 6, "Known Issues."
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.x or release 11.1.1 involves the following procedures:
To run the Connector Installer:
Copy the contents of the connector installation media directory into the following directory:
Note:
In an Oracle Identity Manager cluster, copy this JAR file to each node of the cluster.
For Oracle Identity Manager release 9.1.0.x: OIM_HOME/xellerate/ConnectorDefaultDirectory
For Oracle Identity Manager release 11.1.1: OIM_HOME/server/ConnectorDefaultDirectory
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 the following guide:
For Oracle Identity Manager release 9.1.0.x:
Oracle Identity Manager Administrative and User Console Guide
For Oracle Identity Manager release 11.1.1:
Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager
Depending on the Oracle Identity Manager release you are using, perform one of the following steps:
For Oracle Identity Manager release 9.1.0.x:
Click Deployment Management, and then click Install Connector.
For Oracle Identity Manager release 11.1.1:
On the Welcome to Identity Manager Advanced Administration page, in the System Management region, click Install Connector.
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 in Step 1.
If you have copied the installation files into a different directory, then:
In the Alternative Directory field, enter the full path and name of that directory.
To repopulate the list of connectors in the Connector List list, click Refresh.
From the Connector List list, select UNIX SSH RELEASE_NUMBER.
Click Load.
To start the installation process, click Continue.
The following tasks are performed in sequence:
Configuration of connector libraries
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 Section 2.5.1, "Configuring the Target System As a Trusted Source."
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 1.
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:
Ensuring that the prerequisites for using the connector are addressed
Note:
At this stage, run the Oracle Identity Manager PurgeCache utility to load the server cache with content from the connector resource bundle in order to view the list of prerequisites. See Section 2.5.3, "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.
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.
Configuring the scheduled tasks that are created when you installed the connector
Note:
In Oracle Identity Manager release 11.1.1, a scheduled job is an instance of a scheduled task. In this guide, the term scheduled task used in the context of Oracle Identity Manager release 9.1.0.x is the same as the term scheduled job in the context of Oracle Identity Manager release 11.1.1.
See Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about scheduled tasks and scheduled jobs.
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 2-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 Section 2.1, "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.
The sshfactory.jar file contains the JSCAPE libraries. These libraries are used to open an SSH session with the target server. To copy the sshfactory.jar file, perform one of the following procedures depending on the version of Oracle Identity Manager:
If you are using Oracle Identity Manager release 9.1.0.x, then copy the ext/sshfactory.jar file from the installation media to the OIM_HOME/xellerate/ThirdParty directory.
Note:
In an Oracle Identity Manager cluster, copy this JAR file into the ThirdParty directory on each node of the cluster.
If you are using Oracle Identity Manager release 11.1.1, then:
Run the Upload JARs utility to post the ext/sshfactory.jar file from the installation media to the Oracle Identity Manager database. This utility is copied into the following location when you install Oracle Identity Manager:
Note:
Before you run this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.
For Microsoft Windows:
OIM_HOME/server/bin/UploadJars.bat
For UNIX:
OIM_HOME/server/bin/UploadJars.sh
When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Manager administrator, URL of the Oracle Identity Manager host computer, context factory value, type of JAR file being uploaded, and the location from which the JAR file is to be uploaded. To upload the sshfactory.jar file, specify 3 as the value of the JAR type.
See Also:
Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for detailed information about the Upload JARs utility.
You must specify values for the parameters of the SSH LINUX IT resource as follows:
Log in to the Administrative and User Console.
If you are using Oracle Identity Manager release 9.1.0.x, expand Resource Management, and then click Manage IT Resource.
If you are using Oracle Identity Manager release 11.1.1, then:
On the Welcome page, click Advanced in the upper-right corner of the page.
On the Welcome to Oracle Identity Manager Advanced Administration page, in the Configuration region, click Manage IT Resource.
In the IT Resource Name field on the Manage IT Resource page, enter SSH LINUX and then click Search.
Click the edit icon for the IT resource.
From the list at the top of the page, select Details and Parameters.
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
Here, |
|
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: |
|
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:
|
|
Shell Prompt |
|
|
Whether Trusted System (HP-UX) |
|
|
Sudo Or RBAC |
Enter one of the following values:
|
|
Max Retries |
Number of times that the connector must retry connecting to the target server if the connection fails Default value: |
|
Delay |
Delay (in milliseconds) before the connector attempts to retry connecting to the target system, if the connection fails Default value: |
|
Timeout |
Value of the timeout (in milliseconds) for the connection to the target server Default value: |
|
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:
The command generates the following output:
In this output, Sample value for this attribute: |
|
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:
The command generates the following output:
In this output, 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: |
|
Target Date Format |
This parameter is used to specify the date format of the target UNIX computer. The default value for this parameter is:
This parameter is used for user reconciliation. |
|
Protocol |
Default value: Do not change this default value. |
|
RBAC Role Name |
If you specify RBAC as the value of the |
|
RBAC Role Passwd |
If you specify RBAC as the value of the |
To save the values, click Save.
Depending on the Oracle Identity Manager that you are using, copy the files in the config directory of the installation media to the following directory on the Oracle Identity Manager host computer:
For Oracle Identity Manager release 9.1.0.x:
OIM_HOME/xellerate/XLIntegrations/SSH/config
For Oracle Identity Manager release 11.1.1:
OIM_HOME/server/XLIntegrations/SSH/config
Configuring the Oracle Identity Manager server involves the following procedures:
Section 2.5.1, "Configuring the Target System As a Trusted Source"
Section 2.5.3, "Clearing Content Related to Connector Resource Bundles from the Server Cache"
Section 2.5.5, "Configuring Oracle Identity Manager for Request-Based Provisioning"
While configuring the connector, the target system can be designated as a trusted source or target resource. If you designate the target system as a trusted source, then during a reconciliation run:
For each newly created user on the target system, an OIM User is created.
Updates made to each user on the target system are propagated to the corresponding OIM User.
If you designate the target system as a target resource, then during a reconciliation run:
For each account created on the target system, a resource is assigned to the corresponding OIM User.
Updates made to each account on the target system are propagated to the corresponding resource.
Note:
Skip this section if you do not want to designate the target system as a trusted source for reconciliation.
Configuring trusted source reconciliation involves the following steps:
Import the XML file for trusted source reconciliation, XellSSHUser.xml, by using the Deployment Manager. This section describes the procedure to import the XML file.
Note:
Only one target system can be designated as a trusted source. If you import the XellSSHUser.xml file while you have another trusted source configured, then both connector reconciliations would stop working.
Specify values for the attributes of the SSH UserTrusted Reconciliation task scheduled task. This procedure is described later in this guide.
To import the XML file for trusted source reconciliation:
Open the Oracle Identity Manager Administrative and User Console.
If you are using Oracle Identity Manager release 9.1.0.x, then:
Click the Deployment Management link on the left navigation bar.
Click the Import link under Deployment Management. A dialog box for opening files is displayed.
If you are using Oracle Identity Manager release 11.1.1, then:
On the Welcome page, click Advanced in the upper-right corner.
On the Welcome to Oracle Identity Manager Advanced Administration page, in the System Management region, click Import Deployment Manager File. A dialog box for opening files is displayed.
Locate and open the XellSSHUser.xml file, which is in the xml directory of the installation media. Details of this XML file are shown on the File Preview page.
Click Add File. The Substitutions page is displayed.
Click Next. The Confirmation page is displayed.
Click Import.
In the message that is displayed, click Import to confirm that you want to import the XML file and then click OK.
Note:
In an Oracle Identity Manager cluster, you must perform this step on each node of the cluster. Then, restart each node.
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.
Note:
In an Oracle Identity Manager cluster, you must perform this step on each node of the cluster. Then, restart each node.
When you deploy the connector, the resource bundles are copied from the resources directory on the installation media into the OIM_HOME/xellerate/connectorResources directory for Oracle Identity Manager release 9.1.0.x, and Oracle Identity Manager database for Oracle Identity Manager release 11.1.1. Whenever you add a new resource bundle to 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:
In a command window, perform one of the following steps:
If you are using Oracle Identity Manager release 9.1.0.x, then switch to the OIM_HOME/xellerate/bin directory.
If you are using Oracle Identity Manager release 11.1.1, then switch to the OIM_HOME/server/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:
For Oracle Identity Manager release 9.1.0.x:
OIM_HOME/xellerate/bin/SCRIPT_FILE_NAME
For Oracle Identity Manager release 11.1.1:
OIM_HOME/server/bin/SCRIPT_FILE_NAME
Enter one of the following commands:
Note:
You can use the PurgeCache utility to purge the cache for any content category. Run PurgeCache.bat CATEGORY_NAME on Microsoft Windows or PurgeCache.sh CATEGORY_NAME on UNIX. The CATEGORY_NAME argument represents the name of the content category that must be purged.
For example, the following commands purge Metadata entries from the server cache:
PurgeCache.bat MetaData
PurgeCache.sh MetaData
For Oracle Identity Manager release 9.1.0.x:
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. This exception is different from the one mentioned in Step 1.
In this command, ConnectorResourceBundle is one of the content categories that you can delete from the server cache. See the following file for information about the other content categories:
OIM_HOME/xellerate/config/xlconfig.xml
For Oracle Identity Manager release 11.1.1:
On Microsoft Windows: PurgeCache.bat All
On UNIX: PurgeCache.sh All
When prompted, enter the user name and password of an account belonging to the SYSTEM ADMINISTRATORS group. In addition, you are prompted to enter the service URL in the following format:
t3://OIM_HOST_NAME:OIM_PORT_NUMBER
In this format:
Replace OIM_HOST_NAME with the host name or IP address of the Oracle Identity Manager host computer.
Replace OIM_PORT_NUMBER with the port on which Oracle Identity Manager is listening.
See Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about the PurgeCache utility.
Depending on the Oracle Identity Manager release you are using, perform the procedure described in one of the following sections:
Section 2.5.4.1, "Enabling Logging on Oracle Identity Manager Release 9.1.0.x"
Section 2.5.4.2, "Enabling Logging on Oracle Identity Manager Release 11.1.1"
Note:
In an Oracle Identity Manager cluster, perform this procedure on each node of the cluster. Then, restart each node.
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 might 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:
IBM WebSphere Application Server
To enable logging:
Add the following line in the OIM_HOME/xellerate/config/log.properties file:
log4j.logger.OIMCP.TELNETSSH=log_level
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:
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>
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:
Add the following line in the OIM_HOME/xellerate/config/log.properties file:
log4j.logger.OIMCP.TELNETSSH=log_level
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
Oracle WebLogic Server
To enable logging:
Add the following line in the OIM_HOME/xellerate/config/log.properties file:
log4j.logger.OIMCP.TELNETSSH=log_level
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.
Note:
In an Oracle Identity Manager cluster, perform this procedure on each node of the cluster. Then, restart each node.
Oracle Identity Manager release 11.1.1 uses Oracle Java Diagnostic Logging (OJDL) for logging. OJDL is based on java.util.logger. 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:
SEVERE.intValue()+100
This level enables logging of information about fatal errors.
SEVERE
This level enables logging of information about errors that might allow Oracle Identity Manager to continue running.
WARNING
This level enables logging of information about potentially harmful situations.
INFO
This level enables logging of messages that highlight the progress of the application.
CONFIG
This level enables logging of information about fine-grained events that are useful for debugging.
FINE, FINER, FINEST
These levels enable logging of information about fine-grained events, where FINEST logs information about all events.
These log levels are mapped to ODL message type and level combinations as shown in Table 2-2.
Table 2-2 Log Levels and ODL Message Type:Level Combinations
| Log Level | ODL Message Type:Level |
|---|---|
|
SEVERE.intValue()+100 |
INCIDENT_ERROR:1 |
|
SEVERE |
ERROR:1 |
|
WARNING |
WARNING:1 |
|
INFO |
NOTIFICATION:1 |
|
CONFIG |
NOTIFICATION:16 |
|
FINE |
TRACE:1 |
|
FINER |
TRACE:16 |
|
FINEST |
TRACE:32 |
The configuration file for OJDL is logging.xml, which is located at the following path:
DOMAIN_HOME/config/fmwconfig/servers/OIM_SERVER/logging.xml
Here, DOMAIN_HOME and OIM_SERVER are the domain name and server name specified during the installation of Oracle Identity Manager.
To enable logging in Oracle WebLogic Server:
Edit the logging.xml file as follows:
Add the following blocks in the file:
<log_handler name='telnetssh-handler' level='[LOG_LEVEL]' class='oracle.core.ojdl.logging.ODLHandlerFactory'> <property name='logreader:' value='off'/> <property name='path' value='[FILE_NAME]'/> <property name='format' value='ODL-Text'/> <property name='useThreadName' value='true'/> <property name='locale' value='en'/> <property name='maxFileSize' value='5242880'/> <property name='maxLogSize' value='52428800'/> <property name='encoding' value='UTF-8'/> </log_handler>
<logger name="OIMCP.TELNETSSH" level="[LOG_LEVEL]" useParentHandlers="false">
<handler name="telnetssh-handler"/>
<handler name="console-handler"/>
</logger>
Replace both occurrences of [LOG_LEVEL] with the ODL message type and level combination that you require. Table 2-2 lists the supported message type and level combinations.
Similarly, replace [FILE_NAME] with the full path and name of the log file in which you want log messages to be recorded.
The following blocks show sample values for [LOG_LEVEL] and [FILE_NAME]:
<log_handler name='telnetssh-handler' level='NOTIFICATION:1' class='oracle.core.ojdl.logging.ODLHandlerFactory'> <property name='logreader:' value='off'/> <property name='path' value='F:\MyMachine\middleware\user_projects\domains\base_domain1\servers\oim_server1\logs\oim_server1-diagnostic-1.log'/> <property name='format' value='ODL-Text'/> <property name='useThreadName' value='true'/> <property name='locale' value='en'/> <property name='maxFileSize' value='5242880'/> <property name='maxLogSize' value='52428800'/> <property name='encoding' value='UTF-8'/> </log_handler> <logger name="OIMCP.TELNETSSH" level="NOTIFICATION:1" useParentHandlers="false"> <handler name="telnetssh-handler"/> <handler name="console-handler"/> </logger>
With these sample values, when you use Oracle Identity Manager, all messages generated for this connector that are of a log level equal to or higher than the NOTIFICATION:1 level are recorded in the specified file.
Save and close the file.
Set the following environment variable to redirect the server logs to a file:
For Microsoft Windows:
set WLS_REDIRECT_LOG=FILENAME
For UNIX:
export WLS_REDIRECT_LOG=FILENAME
Replace FILENAME with the location and name of the file to which you want to redirect the output.
Restart the application server.
Note:
Perform the procedure described in this section only if you are using Oracle Identity Manager release 11.1.1 and you want to configure request-based provisioning.
In request-based provisioning, an end user creates a request for a resource by using the Administrative and User Console. Administrators or other users can also create requests for a particular user. Requests for a particular resource on the resource can be viewed and approved by approvers designated in Oracle Identity Manager.
The following are features of request-based provisioning:
A user can be provisioned only one resource (account) on the target system.
Note:
Direct provisioning allows the provisioning of multiple target system accounts on the target system.
Direct provisioning cannot be used if you enable request-based provisioning.
To configure request-based provisioning, perform the following procedures:
Note:
You can perform this procedure instead of the procedures described in Section 2.5.5.2, "Copying Predefined Request Datasets" and Section 2.5.5.3, "Importing Request Datasets into MDS".
See Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for detailed information about importing objects from an XML file using the Deployment Manager.
A request dataset is an XML file that specifies the information to be submitted by the requester during a provisioning operation. These request datasets specify information about the default set of attributes for which the requester must submit information during a request-based provisioning operation.
To import a request dataset XML file by using the Deployment Manager:
Log in to the Oracle Identity Manager Administrative and User Console.
Click the Deployment Management link on the left navigation bar.
Click the Import link under Deployment Management.
A dialog box for opening files is displayed.
Locate and open the request dataset XML file, SSHConnectorRequestDatasets.xml, which is in the xml directory of the installation media.
Details of this XML file are shown on the File Preview page.
Click Add File.
The Substitutions page is displayed.
Click Next.
The Confirmation page is displayed.
Click Import.
Close the Deployment Manager dialog box.
The request dataset is imported into Oracle Identity Manager.
Predefined request datasets are shipped with this connector. The following are the predefined request dataset available in the DataSets directory on the installation media:
ProvisionResourceSSH User.xml
ModifyResourceSSH User.xml
Copy these files from the installation media to any directory on the Oracle Identity Manager host computer. It is recommended that you create a directory structure as follows:
/custom/connector/RESOURCE_NAME
For example:
E:\MyDatasets\custom\connector\SSHStd
Note:
Until you complete the procedure to configure request-based provisioning, ensure that there are no other files or directories inside the parent directory in which you create the directory structure. In the preceding example, ensure that there are no other files or directories inside the E:\MyDatasets directory.
The directory structure to which you copy the dataset files is the MDS location into which these files are imported after you run the Oracle Identity Manager MDS Import utility. The procedure to import dataset files is described in the next section.
Depending on your requirement, you can modify the file names of the request datasets. In addition, you can modify the information in the request datasets. See Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for information on modifying request datasets.
You can configure request-based provisioning by importing the request datasets into into the metadata store (MDS) by using the Oracle Identity Manager MDS Import utility.
To import a request dataset definition into MDS:
Ensure that you have set the environment for running the MDS Import utility. See Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager for detailed information about setting up the environment for MDS utilities.
Note:
While setting up the properties in the weblogic.properties file, ensure that the value of the metadata_from_loc property is the parent directory of the /custom/connector/RESOURCE_NAME directory. For example, while performing the procedure in Section 2.5.5.2, "Copying Predefined Request Datasets," if you copy the files to the E:\MyDatasets\custom\connector\SSHStd directory, then set the value of the metada_from_loc property to E:\MyDatasets.
In a command window, change to the OIM_HOME\server\bin directory.
Run one of the following commands:
On Microsoft Windows
weblogicImportMetadata.bat
On UNIX
weblogicImportMetadata.sh
When prompted, enter the following values:
Please enter your username [weblogic]
Enter the username used to log in to the WebLogic server
Sample value: WL_User
Please enter your password [weblogic]
Enter the password used to log in to the WebLogic server.
Please enter your server URL [t3://localhost:7001]
Enter the URL of the application server in the following format:
t3://HOST_NAME_IP_ADDRESS:PORT
In this format, replace:
HOST_NAME_IP_ADDRESS with the host name or IP address of the computer on which Oracle Identity Manager is installed.
PORT with the port on which Oracle Identity Manager is listening.
The request dataset is imported into MDS.
To enable the Auto Save Form feature:
Log in to the Design Console.
Expand Process Management, and then double-click Process Definition.
Search for and open the SSH User process definition.
Select the Auto Save Form check box.
Click Save.
Run the PurgeCache utility to clear content belonging to the Metadata category from the server cache. See Section 2.5.3, "Clearing Content Related to Connector Resource Bundles from the Server Cache" for instructions.
The procedure to configure request-based provisioning ends with this step.