Integrating Oracle Identity Governance and Oracle Access Manager Using LDAP Connectors

2 Integrating Oracle Identity Governance and Oracle Access Manager Using LDAP Connectors

Integrate Oracle Identity Governance (OIG) and Oracle Access Manager (OAM) using LDAP Connectors. You can run an automated integration script to complete OIG-OAM integration or perform configuration operations individually. The script utilizes user-supplied values from property files to perform various configurations.

This chapter provides step-by-step instructions for integrating Oracle Access Manager (Access Manager) and Oracle Identity Governance (Enterprise Edition). Use the automated script for integration if your integrated environment includes LDAP Connectors and any third-party access product. Also you can perform this integration incrementally. When you run each task in the automated integration script separately to complete OIG-OAM integration, you can evaluate the result of each successive step. Rerun the step, if required, or proceed to the next step in the sequence until all steps are successfully completed.

Note:

The exact details in this chapter may differ depending on your specific deployment. Adapt information as required for your environment.

The integration instructions assume Identity Governance components have been configured on separate Oracle WebLogic domains, as discussed in About the Basic Integration Topology. For prerequisite and detailed information on how the components were installed and configured in this example integration, see Preparing to Install and Configure Oracle Identity and Access Management in Fusion Middleware Installing and Configuring Oracle Identity and Access Management

If you are deploying Oracle Identity Governance components in an enterprise integration topology, as discussed in About the Basic Integration Topology, see Understanding an Enterprise Deployment in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity and Access Management for implementation procedures.

This chapter contains these sections:

2.1 Overview of Oracle Identity Governance and Oracle Access Manager Integration

This integration scenario enables you to manage identities with Oracle Identity Governance and control access to resources with Oracle Access Manager. Oracle Identity Governance is a user provisioning and administration solution that automates user account management, whereas Access Manager provides a centralized and automated single sign-on (SSO) solution.

This section contains the following topics:

2.1.1 About Integrating Oracle Identity Governance with Oracle Access Manager

In the Oracle Access Manager (OAM) and Oracle Identity Governance (OIG) integration, users have the capability to:

Create and reset the password without assistance for expired and forgotten passwords
Recover passwords using challenge questions and answers
Set up challenge questions and answers
Perform self-service registration
Perform self-service profile management
Access multiple applications securely with one authentication step

See About Password Management Scenarios.

2.1.2 About Oracle Identity Governance and Oracle Access Manager Single-Node Integration Topology

You must configure IdM components, Access Manager and Oracle Identity Governance, in separate WebLogic Server domains (split domain topology), as discussed in About the Basic Integration Topology, and separate Oracle Middleware homes. Otherwise, attempts to patch or upgrade one product may be blocked by a version dependency on a component shared with another. When you install Oracle Identity Governance components in a single WebLogic Server domain, there is a risk that the component (libraries, jars, utilities, and custom plug-ins) you are installing into the domain might not be compatible with other components, thereby resulting in problems across your entire domain.

Access Manager uses a database for policy data and a directory server for identity data. This integration scenario assumes a single directory server. The directory server must also be installed in a separate domain and a separate Middleware home as well.

Note:

The instructions in this chapter assume that you will use Oracle Unified Directory as the identity store.

2.1.3 Prerequisites to Integrating Oracle Identity Governance and Oracle Access Manager

Ensure the required environment is set and made available for the integration.

Note:

You can upgrade the existing 11g and 12c OIG and OAM integrated environments to the latest 12c (12.2.1.4.0) release version. For more information, see Upgrading OIG-OAM Integrated Environments.

In the following sections it is assumed that the required components, as listed in Table 2-1, have already been installed, including any dependencies, and the environment is configured prior to the integration. See Understanding Oracle Identity Management Integration Topologies.

Note:

Use 12.2.1.4.0 binaries for OAM and OIG.
OUD needs to have the changelog enabled for incremental reconciliation from OIG to work. If this is not enabled, the incremental reconciliation will not work. On a replicated OUD instance, cn=changelog is available by default depending on the condition that this instance contains both directory server and replication server components, which is the default. The changelog has no additional cost since the replication is already up.

On a non replicated OUD instance, cn=changelog is not available by default because there is a cost in disk and cpu that should not be paid if it is not useful. This can be easily enabled with the following command:
```
$ dsreplication enable-changelog -h localhost -p 4444 -D "cn=directory manager" -r 8989 -b "dc=example,dc=com"
```

Table 2-1 Required Components for Integration Scenario

Component	Information
Oracle HTTP Server with Oracle HTTP Server WebGate	Oracle HTTP Server with Oracle HTTP Server WebGate is installed. For more information, see Installing Oracle HTTP Server and Configuring the Oracle HTTP Server WebGate.
Oracle SOA Suite	Oracle Identity Governance requires Oracle SOA Suite 12.2.1.4.0, which is exclusive to Oracle Identity and Access Management. SOA Suite is a prerequisite for Oracle Identity Governance and must be installed in the same domain as Oracle Identity Governance. If you use SOA Suite for other purposes, a separate install must be set up for running your own services, composites, BPEL processes, and so on. For more information, see Installing and Configuring the Oracle Identity Governance Software in Installing and Configuring Oracle Identity and Access Management.
Oracle Unified Directory	Oracle Unified Directory is installed. See Installing the Oracle Unified Directory Software in Installing Oracle Unified Directory.
Access Manager	Access Manager is already installed and bundle patch 12.2.1.4.191223 applied or the latest bundle patch available for your release. See: Installing and Configuring the Oracle Access Management Software in Installing and Configuring Oracle Identity and Access Management. For the latest bundle patch, visit the Oracle Identity Management website at: `https://docs.oracle.com/en/middleware/idm/suite/12.2.1.4/bundlepatch.html` Note: If you are upgrading to the 12c (12.2.1.4.0) release version, then the OAM bundle patch 12.2.1.4.200327 applied or the latest bundle patch available for your release. For more information about upgrade, see Upgrading OIG-OAM Integrated Environments.
Oracle Identity Governance	Oracle Identity Governance 12.2.1.4.0 is already installed. See Installing and Configuring the Oracle Identity Governance Software in Installing and Configuring Oracle Identity and Access Management. Note: If you are upgrading to the 12c (12.2.1.4.0) release version, then the OIM bundle patch 12.2.1.4.200505 applied or the latest bundle patch available for your release. For more information about upgrade, see Upgrading OIG-OAM Integrated Environments.

Environmental Variables	Set the environmental variables required for OIG-OAM integration. See Set Up Environment Variables for OIG-OAM Integration.

2.1.4 Roadmap to Integrating Oracle Identity Governance and Oracle Access Manager

Table 2-2 lists the high-level tasks for integrating Access Manager and Oracle Identity Governance with Oracle Unified Directory.

Depending on your installation path, you may already have performed some of the integration procedures listed in this table. For details on the installation roadmap, see Understanding the Installation Roadmap.

Table 2-2 Integration Flow for Access Manager and Oracle Identity Governance

No.	Task	Information
1	Verify that all required components have been installed and configured prior to integration.	See Prerequisites to Integrating Oracle Identity Governance and Oracle Access Manager
2	Install Oracle HTTP Server and configuring the Oracle HTTP Server WebGate with Oracle Access Manager.	See Installing Oracle HTTP Server and Configuring the Oracle HTTP Server WebGate.
3	Integrate Access Manager and Oracle Identity Governance.	See Configuring Oracle Identity Governance and Oracle Access Manager Integration
4	Stop the Oracle WebLogic Server managed servers for Access Manager and Oracle Identity Governance.	See Starting and Stopping Admin Server in Administering Oracle Fusion Middleware
5	Test the integration.	See Validating the Access Manager and Oracle Identity Governance Integration

2.2 Installing Oracle HTTP Server and Configuring the Oracle HTTP Server WebGate

Oracle HTTP Server WebGate is a Web server plug-in that intercepts HTTP requests and forwards them to an Oracle Access Management instance for authentication and authorization.

To install the Oracle HTTP Server and configuring the Oracle HTTP Server WebGate, do the following:

Install the Oracle HTTP Server collocated with an existing WebLogic Server associated with the Oracle Access Management domain.

For more information, see Installing the Oracle HTTP Server Software in Installing and Configuring Oracle HTTP Server.

Note:
Ensure that you select Collocated HTTP Server (Managed through WebLogic server) as the Installation Type during the installation process.
Update the Oracle Access Management domain with Oracle HTTP Server.

For more information about extending the existing Oracle Access Management domain with Oracle HTTP Server, see Configuring Oracle HTTP Server in a Collocated Domain in Installing and Configuring Oracle HTTP Server.

Note:
Ensure that you add the Oracle Access Management machine and assign the Oracle HTTP Server instance to the selected machine in the Assign System Components to Machines screen during the configuration process.
Configure Oracle HTTP Server WebGate for Oracle Access Manager. For more information, see Configuring Oracle HTTP Server WebGate for Oracle Access Manager in Installing WebGates for Oracle Access Manager.

2.3 Configuring Oracle Identity Governance and Oracle Access Manager Integration

The automated script for integration simplifies the process of a connector-based integration between Oracle Identity Governance (OIG) and Oracle Access Manager (OAM) or any third-party access product. You can integrate OIG and OAM with directories such as Oracle Unified Directory (OUD), Oracle Internet Directory (OID) and Active Directory (AD).

This chapter contains the following topics:

2.3.1 Prerequisites for the Connector-based Integration

Prepare the environment ready for the connector-based integration using the automated integration script. Ensure that the system-level requirements are met, 12.2.1.4.0 binaries are installed, OIG-MDS is updated, and the required connector is downloaded.

Verifying the Environment

Check that your operating system is up-to-date with all necessary patches applied.
Mount the binaries you will be using. The applicable Oracle software includes:
- Oracle Database 12c (12.2.x.x)
- JRF 12.2.1.4.0
- Oracle Identity and Access Management 12c (12.2.1.4.0)
- Oracle Unified Directory 12c (12.2.1.4.0) /Oracle Internet Directory 12c (12.2.1.4.0)
- Oracle Fusion Middleware Infrastructure 12c (12.2.1.4.0)
Note:
- Use 12.2.1.4.0 binaries for OAM and OIG.
- Apply OAM bundle patch 12.2.1.4.191223 or the latest bundle patch available for your release before starting the integrating process.
- If you are upgrading OAM-OIG integrated environments from 11g Release 2 (11.1.2.3.0) or 12c (12.2.1.3.0) to the latest 12c (12.2.1.4.0) release version, then apply the following bundle patches:
  - OAM bundle patch 12.2.1.4.200327
  - OIM bundle patch 12.2.1.4.200505
- The Oracle HTTP Server with 12c WebGate must be installed.
Verify that the Oracle Database is connected and accessible.
Verify that the directory of your choice (OUD/OID/AD) is up and running.
Verify that the Oracle Access Manager is up and running.
Verify that the Oracle Identity Governance is up and running.
Verify if the environmental variables are set, as described in Set Up Environment Variables for OIG-OAM Integration.
Ensure that the Oracle Access Manager and Oracle Identity Governance are installed on separate domains.

Note:
The automated integration script, OIGOAMIntegration.sh works with OIG and OAM on separate hosts and domains. It is not required to have OIG and OAM on the same domain.
Ensure that the screen package is installed on your server by running the following command:
```
rpm -qa | grep screen
```
The command returns the value as shown in the following example:
```
screen.x86_64 0:4.1.0-0.23.20120314git3c2946.el7_2
```
If the command does not return information about the screen package version then install the package as follows:
1. Log on to your Linux server as root
2. Run yum install screen to install the screen package (For example, screen.x86_64 0:4.1.0-0.23.20120314git3c2946.el7_2):
```
[root@server]# yum install screen
> Package screen.x86_64 0:4.1.0-0.23.20120314git3c2946.el7_2 will be
installed
Total download size: 552 k
Installed size: 914 k
Is this ok [y/d/N]:

Enter 'y' and press enter.

Downloading packages:
screen-4.1.0-0.23.20120314git3c2946.el7_2.x86_64.rpm

Installed:
screen.x86_64 0:4.1.0-0.23.20120314git3c2946.el7_2
```
Ensure that the OpenLDAP packages are installed:
```
yum install openldap openldap-clients
```
Verify if the version is on your system by entering the command which ldapsearch. The command returns the value as shown in the following example:
```
/usr/bin/ldapsearch
```
Update your $PATH to the LDAP directory server installation directory.

Updating Datasource Related to OIG Metadata Services (MDS) Configuration

Log in to the WebLogic Administrative Console for OIG.
In the left pane, under Domain Structure, expand Services, and then click Data Sources.
Click mds-oim, click the Connection Pool tab.
Update the following property values in the MDS-OIM connection pool:
- Initial Capacity to 50
- Maximum Capacity to 150
- Minimum Capacity to 50
To update the value for Inactive Connection Timeout:

In the same datasource, click Advanced link under the bottom of the page and set the Inactive Connection Timeout value to 10.
Click Save.
Click Activate Changes.

Downloading the Connector

Download the Connector bundle from the artifactory: Download Connector Bundle
- For OID or OUD, download the oid-12.2.1.3.0.zip Connector bundle corresponding to Oracle Internet Directory.
- For AD, download activedirectory-12.2.1.3.0.zip connector bundle corresponding to Microsoft Active Directory User Management.
Note:
For all directory types, the required Connector version for OIG-OAM integration is 12.2.1.3.0.
Unzip the Connector bundle to the desired connector path under OIG Oracle home$ORACLE_HOME/idm/server/ConnectorDefaultDirectory.

For example:
```
/u01/app/fmw/ORACLE_HOME/idm/server/ConnectorDefaultDirectory
```
For AD, install the Active Directory User Management Connector on both, OIG and Connector server.

Note:

Application creation step performs the connector installation. No other install steps are necessary.

Important:

Post OIG-OAM integration, if the LDAP Connector bundle or the Active Directory Connector bundle is used for creating target application instances for other IT resources, then the pre-config.xml corresponding to the directory type must be manually imported from Sysadmin UI before proceeding to create application instance.

For OID:

XML name: OID-pre-config.xml
Location (example): $ORACLE_HOME/idm/server/ConnectorDefaultDirectory/OID-12.2.1.3.0/xml/OID-pre-config.xml

For OUD/ODSEE/LDAPV3:

XML name: ODSEE-OUD-LDAPV3-pre-config.xml
Location (example): $ORACLE_HOME/idm/server/ConnectorDefaultDirectory/OID-12.2.1.3.0/xml/ODSEE-OUD-LDAPV3-pre-config.xml

For AD:

XML name: ad-pre-config.xml
Location (example): $ORACLE_HOME/idm/server/ConnectorDefaultDirectory/activedirectory-12.2.1.3.0/xml//ad-pre-config.xml

For importing pre-config.xml , see Importing Connector XML File.

Assigning Lockout Threshold in LDAP Directory and Oracle Access Manager

The value for maximum number of authentication failures that a user is allowed to attempt before the user's account gets locked, should be the same in the LDAP directory and Oracle Access Manager.

To set the account lockout duration, open the oam-config.xml in the OAM Domain under DOMAIN_HOME/config/fmwconfig and update the LockoutAttempts parameter.

See Also:

OID-Managing Password Policies in Administering Oracle Internet Directory.
OUD-Managing Password Policies in Administering Oracle Unified Directory.
AD-Configuring Account Lockout Policies in Windows 2000 Evaluated Configuration Administrators Guide.

2.3.2 Step-by-step Procedure for OIG-OAM Integration Using Automated Script

The automated integration script, OIGOAMIntegration.sh supports individual execution of OIG-OAM configuration operations. The properties file, ssointg-config.properties located at $ORACLE_HOME/idm/server/ssointg/config/ specifies which individual step is to be executed.

Note:

You must run the OIGOAMIntegration.sh command only on the OIG server.

Prerequisites

Installed all the components listed Prerequisites.

Perform step-by-step configuration of the OIG-OAM integrated environment by executing each integration task separately. At the end of each step, verify the log output and confirm that the configuration operation is completed successfully. If the configuration operation fails, apply appropriate fixes and rerun the step before proceeding to the next step in the integration sequence.

Run OIGOAMIntegration.sh, a top-level automated integration script to perform the following operations required for OIG-OAM integration:

The ssointg-config.properties file (Located at $ORACLE_HOME/idm/server/ssointg/config/) provides the required configuration information for OIG and OAM integration. The configuration operations executed by the automated integration script are managed by the ssointg-config.properties file.

Example ssointg-config File

generateIndividualConfigFiles=false
prepareIDStore=true
configOAM=true
populateOHSRules=true
configureWLSAuthnProviders=true
configureLDAPConnector=true
## configureLDAPConnector takes care of updating container rules
## Additional option is provided in case rules need to be updated again
updateContainerRules=true
configureSSOIntegration=true
enableOAMSessionDeletion=true

2.3.2.1 Preparing IDStore Using Automated Script

Prepare IDStore using the OIGOAMIntegration.sh automated script for OIG-OAM integration, .

Configure the identity store and policy store by creating the groups and setting ACIs to the various containers. Add necessary users and associating users with groups to the identity store. This step is similar to running the IDMConfigTool command, idmConfigTool.sh -prepareIDStore -mode=ALL. See prepareIDStore Command.

Open the prepareIDStore.all.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example prepareIDStore.all.config File

## DIRTYPE values can be [OID | OUD | AD]
IDSTORE_DIRECTORYTYPE
IDSTORE_HOST
IDSTORE_PORT
IDSTORE_BINDDN
IDSTORE_BINDDN_PWD
IDSTORE_USERNAMEATTRIBUTE
IDSTORE_LOGINATTRIBUTE
IDSTORE_SEARCHBASE
IDSTORE_USERSEARCHBASE
IDSTORE_GROUPSEARCHBASE
IDSTORE_SYSTEMIDBASE
IDSTORE_READONLYUSER
IDSTORE_READWRITEUSER
IDSTORE_SUPERUSER _fa
IDSTORE_OAMSOFTWAREUSER
IDSTORE_OAMADMINUSER
IDSTORE_OAMADMINUSER_PWD
IDSTORE_OIMADMINUSER
IDSTORE_OIMADMINUSER_PWD
IDSTORE_OIMADMINGROUP
IDSTORE_WLSADMINUSER
IDSTORE_WLSADMINUSER_PWD
IDSTORE_WLSADMINGROUP
IDSTORE_OAAMADMINUSER
IDSTORE_XELSYSADMINUSER_PWD
POLICYSTORE_SHARES_IDSTORE
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN
## If you are using OUD as the identity store, then the additional properties are:
#IDSTORE_ADMIN_PORT
#IDSTORE_KEYSTORE_FILE
## The value of the IDSTORE_KEYSTORE_PASSWORD parameter is the content of the /u01/config/instances/oud1/OUD/config/admin-keystore.pin
#IDSTORE_KEYSTORE_PASSWORD

The following table describes the parameters that you can set in the prepareIDStore.all.config file.

Table 2-3 Parameters in prepareIDStore.all.config File

Property	Description	Sample Value
`IDSTORE_DIRECTORYTYPE`	Enter the identity store directory type. Valid options are OID, OUD, and AD.	`OID`
`IDSTORE_HOST`	Enter the identity store host name.	`idstore.example.com`
`IDSTORE_PORT`	Enter the identity store port.	`3060`
`IDSTORE_BINDDN`	An administrative user in Oracle Internet Directory, Oracle Unified Directory or Active Directory.	OID: `cn=orcladmin` OUD: `cn=oudadmin` AD: `CN=Administrator,CN=Users,DC=example.com,DC=example,dc=com`
`IDSTORE_BINDDN_PWD`	Enter the Password for administrative user in Oracle Internet Directory, Oracle Unified Directory or Microsoft Active Directory.	`password`
`IDSTORE_USERNAMEATTRIBUTE`	Enter the username attribute used to set and search for users in the identity store.	`cn`
`IDSTORE_LOGINATTRIBUTE`	Enter the login attribute of the identity store that contains the user's login name.	`uid`
`IDSTORE_SEARCHBASE`	Enter the location in the directory where users and groups are stored.	`dc=example,dc=com`
`IDSTORE_USERSEARCHBASE`	Enter the Container under which Access Manager searches for the users.	`cn=users,dc=example,dc=com`
`IDSTORE_GROUPSEARCHBASE`	Enter the location in the directory where groups are stored.	`cn=groups,dc=example,dc=com`
`IDSTORE_SYSTEMIDBASE`	Enter the location of a container in the directory where system-operations users are stored. There are only a few system operations users and are kept separate from enterprise users stored in the main user container. For example, the Oracle Identity Governance reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.	`cn=systemids,dc=example,dc=com`
`IDSTORE_READONLYUSER`	Enter the user with read-only permissions to the identity store.	`IDROUser`
`IDSTORE_READWRITEUSER`	Enter the user with read-write permissions to the identity store.	`IDRWUser`
`IDSTORE_SUPERUSER`	Enter the Oracle Fusion Applications superuser in the identity store.	`weblogic_fa`
`IDSTORE_OAMSOFTWAREUSER`	Enter the user you use to interact with the LDAP server.	`oamLDAP`
`IDSTORE_OAMADMINUSER`	Enter the user you use to access your Oracle Access Management Console.	`oamAdmin`
`IDSTORE_OAMADMINUSER_PWD`	Enter the password for the user you use to access your Oracle Access Management Console.	`password`
`IDSTORE_OIMADMINUSER`	Enter the user that Oracle Identity Governance uses to connect to the identity store.	`oimLDAP`
`IDSTORE_OIMADMINUSER_PWD`	Enter the Password for the user that Oracle Identity Governance uses to connect to the identity store.	`password`
`IDSTORE_OIMADMINGROUP`	Enter the group you want to create to hold your Oracle Identity Governance administrative users.	`OIMAdministrators`
`IDSTORE_WLSADMINUSER`	Enter the identity store administrator for Oracle WebLogic Server.	`weblogic_idm` Note: This is default user name for the administrator user.
`IDSTORE_WLSADMINUSER_PWD`	Enter the password for Identity store administrator for Oracle WebLogic Server.	`password`
`IDSTORE_WLSADMINGROUP`	Enter the identity store administrator group for Oracle WebLogic Server.	`wlsadmingroup`
`IDSTORE_OAAMADMINUSER`	Enter the user you want to create as your Oracle Access Management Administrator. This user is created by the tool.	`oaamAdminUser`
`IDSTORE_XELSYSADMINUSER_PWD`	Enter the password of System administrator for Oracle Identity Goverance. Must match the value in Oracle Identity Governance	`password`
`POLICYSTORE_SHARES_IDSTORE`	Set it to `true` if your policy and identity stores are in the same directory. If not, it is set to `false`.	`TRUE`
`IDSTORE_ADMIN_PORT`	Enter the Administration port of your Oracle Unified Directory instance. If you are not using Oracle Unified Directory, you ignore this parameter.	`4444`
`IDSTORE_KEYSTORE_FILE`	Enter the location of the Oracle Unified Directory `Keystore` file. It is used to enable communication with Oracle Unified Directory using the Oracle Unified Directory administration port. It is called `admin-keystore` and is located in `OUD_ORACLE_INSTANCE/OUD/config`. If you are not using Oracle Unified Directory, you can ignore this parameter. This file must be located on the same host that the `idmConfigTool` command is running on. The command uses this file to authenticate itself with OUD.	`/u01/config/instances/oud1/OUD/config/admin-keystore`
`IDSTORE_KEYSTORE_PASSWORD`	Enter the encrypted password of the Oracle Unified Directory keystore. This value can be found in the file `OUD_ORACLE_INSTANCE/OUD/config/admin-keystore.pin`. If you are not using Oracle Unified Directory, you can ignore this parameter.	`password`

Run the automated script for OIG-OAM integration to seed the directory with Users, Roles, and ob schema extensions.
```
OIGOAMIntegration.sh -prepareIDStore
```
Note:
In case of Active Directory, grant ACLs manually after executing OIGOAMIntegration.sh -prepareIDStore command. See Granting ACLs Manually for Active Directory
You have successfully executed the automated script for preparing the IDStore.

Verifying the Identity Store and Policy Store Configuration

Do the following in your LDAP directory:

Search base for users and groups you specified in the prepareIDStore.all.config file exist in the LDAP directory.
The user container, group container, and the System ID container exist in the LDAP directory.
The systemids container includes the IDROuser, IDRWUser, oamSoftwareUser, and oimadminuser users.
The user container includes the oamadminuser, weblogic_fa, weblogic_idm, and xelsysadm users.
The group container includes the OAMadministreatrs, OIMadminsitrators, BIReportAdminnistrator, Session REST API, and wlsadmingroup, orclFAGroup, and OAAM groups.

Granting ACLs Manually for Active Directory

For Active Directory, after running OIGOAMIntegration.sh -prepareIDStore, perform the following on the AD server machine:

Add ACLs.

dsacls /G cn=orclFAUserReadPrivilegeGroup,<IDSTORE_GROUPSEARCHBASE>:GR
dsacls /G cn=orclFAUserWritePrivilegeGroup,<IDSTORE_GROUPSEARCHBASE>:GW
dsacls /G cn=orclFAGroupReadPrivilegeGroup,<IDSTORE_GROUPSEARCHBASE>:GR
dsacls /G cn=orclFAGroupWritePrivilegeGroup,<IDSTORE_GROUPSEARCHBASE>:GW
dsacls /G cn=orclFAOAMUserWritePrivilegeGroup,<IDSTORE_GROUPSEARCHBASE>:GW

Reset User Password.

dsmod user "CN=weblogic_idm,<IDSTORE_USERSEARCHBASE>" -pwd <password> -mustchpwd no
dsmod user "CN=xelsysadm,<IDSTORE_USERSEARCHBASE>" -pwd <password> -mustchpwd no
dsmod user "CN=oamadmin,<IDSTORE_USERSEARCHBASE>" -pwd <password> -mustchpwd no
dsmod user "CN=OblixAnonymous,DC=interop,DC=example,DC=com" -pwd <password> -mustchpwd no
dsmod user "CN=oamLDAP,<IDSTORE_SYSTEMIDBASE>" -pwd <password> -mustchpwd no
dsmod user "CN=oimLDAP,<IDSTORE_SYSTEMIDBASE>" -pwd <password> -mustchpwd no

Enable user accounts.

dsmod user "CN=weblogic_idm,<IDSTORE_USERSEARCHBASE>" -disabled no
dsmod user "CN=xelsysadm,<IDSTORE_USERSEARCHBASE>" -disabled no
dsmod user "CN=oamadmin,<IDSTORE_USERSEARCHBASE>" -disabled no
dsmod user "CN=OblixAnonymous,DC=interop,DC=example,DC=com" -disabled no
dsmod user "CN=oamLDAP,<IDSTORE_SYSTEMIDBASE>" -disabled no
dsmod user "CN=oimLDAP,<IDSTORE_SYSTEMIDBASE>" -disabled no

2.3.2.2 Configuring OAM Using Automated Script

Configure Oracle Access Manager using the OIGOAMIntegration.sh automated script.

Open the configOAM.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example configOAM.config File

WLSHOST
WLSPORT
WLSADMIN
IDSTORE_HOST
IDSTORE_PORT
IDSTORE_BINDDN
IDSTORE_USERNAMEATTRIBUTE
IDSTORE_LOGINATTRIBUTE
IDSTORE_SEARCHBASE
IDSTORE_USERSEARCHBASE
IDSTORE_GROUPSEARCHBASE
IDSTORE_OAMSOFTWAREUSER
IDSTORE_OAMADMINUSER
PRIMARY_OAM_SERVERS
WEBGATE_TYPE
ACCESS_GATE_ID _IDM
OAM11G_IDM_DOMAIN_OHS_HOST
OAM11G_IDM_DOMAIN_OHS_PROTOCOL
OAM11G_OAM_SERVER_TRANSFER_MODE
OAM11G_IDM_DOMAIN_LOGOUT_URLS
OAM11G_WG_DENY_ON_NOT_PROTECTED
OAM11G_SERVER_LOGIN_ATTRIBUTE
OAM_TRANSFER_MODE
COOKIE_DOMAIN
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN
OAM11G_SSO_ONLY_FLAG
OAM11G_OIM_INTEGRATION_REQ
OAM11G_IMPERSONATION_FLAG
OAM11G_SERVER_LBR_HOST
OAM11G_SERVER_LBR_PORT
OAM11G_SERVER_LBR_PROTOCOL
COOKIE_EXPIRY_INTERVAL
OAM11G_OIM_OHS_URL
SPLIT_DOMAIN
OAM11G_IDSTORE_NAME
IDSTORE_SYSTEMIDBASE

The following table describes the parameters that you can set in the configOAM.config file.

Table 2-4 Parameters in configOAM.config File

Property	Description	Sample Value
`ACCESS_GATE_ID`	Name to be assigned to the WebGate. This is the value specified during OAM configuration.	`Webgate_IDM`
`COOKIE_DOMAIN`	Enter the domain in which the WebGate functions.	`.example.com`
`COOKIE_EXPIRY_INTERVAL`	Enter the Cookie expiration period.	`120`
`IDSTORE_BINDDN`	An administrative user in Oracle Internet Directory, Oracle Unified Directory or Active Directory.	OID: `cn=orcladmin` OUD: `cn=oudadmin` Active Directory: `CN=Administrator,CN=Users,DC=example.com,DC=example,dc=com`
`IDSTORE_GROUPSEARCHBASE`	Enter the location in the directory where groups are stored.	`cn=groups,dc=example,dc=com`
`IDSTORE_HOST`	Enter the identity store host name.	`idstore.example.com`
`IDSTORE_LOGINATTRIBUTE`	Enter the login attribute of the identity store that contains the user's login name.	`uid`
`IDSTORE_OAMADMINUSER`	Enter the user you use to access your Oracle Access Management Console.	`oamAdmin`
`IDSTORE_OAMSOFTWAREUSER`	Enter the user you use to interact with the LDAP server.	`oamLDAP`
`IDSTORE_PORT`	Enter the identity store port.	`389`
`IDSTORE_SEARCHBASE`	Enter the location in the directory where users and groups are stored.	`dc=example,dc=com`
`IDSTORE_SYSTEMIDBASE`	Enter the location of a container in the directory where system-operations users are stored. There are only a few system operations users and are kept separate from enterprise users stored in the main user container. For example, the Oracle Identity Governance reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.	`cn=systemids,dc=example,dc=com`
`IDSTORE_USERNAMEATTRIBUTE`	Enter the username attribute used to set and search for users in the identity store.	`cn`
`IDSTORE_USERSEARCHBASE`	Enter the Container under which Access Manager searches for the users.	`cn=users,dc=example,dc=com`
`OAM_TRANSFER_MODE`	Enter the security mode in which the access servers function. Supported values are OPEN and SIMPLE	`Open`
`OAM11G_IDM_DOMAIN_LOGOUT_URLS`	Set to the various logout URLs.	`/console/jsp/common/logout.jsp, /em/targetauth/emaslogout.jsp`
`OAM11G_IDM_DOMAIN_OHS_HOST`	Enter the load balancer that is in front of Oracle HTTP Server (OHS) in a high-availability configuration.	`sso.example.com`
`OAM11G_IDM_DOMAIN_OHS_PORT`	Enter the load balancer port.	`443`
`OAM11G_IDM_DOMAIN_OHS_PROTOCOL`	Enter the Protocol to use when directing requests to the load balancer.	`https`
`OAM11G_IDSTORE_NAME`	Enter the name of the identity store configured in OAM. This will be set as the default/System ID Store in OAM.	`OAMIDSTORE`
`OAM11G_IDSTORE_ROLE_SECURITY_ADMIN`	Account to administer role security in identity store.	`OAMAdministrators`
`OAM11G_IMPERSONATION_FLAG`	It enables or disables the impersonation feature in the OAM Server.	`true`
`OAM11G_OAM_SERVER_TRANSFER_MODE`	Enter the security mode in which the access servers function. Supported values are OPEN and SIMPLE	`Open`
`OAM11G_OIM_INTEGRATION_REQ`	It specifies whether to integrate with Oracle Identity Governance or configure Access Manager in stand-alone mode. Set to `true` for integration.	`true`
`OAM11G_OIM_OHS_URL`	Enter the URL of the load balancer or Oracle HTTP Server (OHS) fronting the OIM server.	`https://sso.example.com:443/`
`OAM11G_SERVER_LBR_HOST`	Enter the OAM Server fronting your site.	`sso.example.com`
`OAM11G_SERVER_LBR_PORT`	Enter the port that the load balancer is listening on (`HTTP_SSL_PORT`).	`443`
`OAM11G_SERVER_LBR_PROTOCOL`	Enter the Protocol to use when directing requests to the load balancer.	`https`
`OAM11G_SERVER_LOGIN_ATTRIBUTE`	Setting to uid ensures the validation of the username against the uid attribute in LDAP when the user logs in.	`uid`
`OAM11G_SSO_ONLY_FLAG`	Set it to configure Access Manager 11g as authentication only mode or normal mode, which supports authentication and authorization. Default value is `true`. If value is set to `false`, access is denied to protected resources for any users.	`true`
`OAM11G_WG_DENY_ON_NOT_PROTECTED`	Set to deny on protected flag for 10g WebGate. Valid values are `true` and `false`.	`false`
`PRIMARY_OAM_SERVERS`	Enter comma-separated list of your Access Manager servers and the proxy ports they use.	`oamhost1.example.com:5575, oamhost2.example.com:5575`
`SPLIT_DOMAIN`	Set to `true` is required to suppress the double authentication of Oracle Access Management Console.	`true`
`WEBGATE_TYPE`	Enter the WebGate agent type you want to create. 10g is no longer supported in 12c.	`ohsWebgate12c`
`WLSADMIN`	Enter the WebLogic Server administrative user account you use to log in to the WebLogic Server Administration Console in OAM domain.	`weblogic`
`WLSHOST`	Enter the Administration server host name in OAM domain.	`oamadminhost.example.com`
`WLSPORT`	Enter the Administration server port in OAM domain.	`7001`

Stop the policy server. See Starting and Stopping Managed WebLogic Servers and Access Manager Servers.
Run the automated script for OIG-OAM integration to configure OAM.
```
OIGOAMIntegration.sh -configOAM
```
You have successfully executed the automated script for configuring Oracle Access Manager.
Restart the OAM domain servers. See Starting and Stopping Managed WebLogic Servers and Access Manager Servers.

Verifying the OAM Configuration

You can verify the OAM configuration by performing the following steps:

Search for the WebGate name that you specified in the configOAM.config properties file:
1. Log in to the Oracle Access Management Console:
  http://oam_adminserver_host:oam_adminserver_port/oamconsole
2. From the Application Security Launch Pad, click Agents.
  
  The Search SSO Agents page is displayed.
3. In the Search field, enter the WebGate name.
  
  Note:
  This is the value you specified for ACCESS_GATE_ID in the configOAM.config properties file.
4. In the Search Result Table, you can see the agent.
Verify that the name of the identity store you specified in the configOAM.config file is automatically selected as the default store:
- Click the Configuration Lauch Pad and select User Identity Stores.
- In the Default and System Store section, verify that the name of the identity store you specified in the configOAM.config file (For example, OAMIDSTORE) is selected as the Default Store and System Store.

2.3.2.3 Populating OHS Rules Using Automated Script

Populate OHS rules using the OIGOAMIntegration.sh automated script.

To populate OHS rules:

Update the populateOHSRedirectIdmConf.config file (Located at ORACLE_HOME/idm/server/ssointg/config) with the OAM and OIG server details.

OIM_HOST
OIM_PORT
OAM_HOST
OAM_PORT

The following table provides descriptions of the parameters in the populateOHSRedirectIdmConf.config file.

Table 2-5 Parameters in populateOHSRedirectIdmConf.config file

Property	Description	Sample Value
`OAM_HOST`	Enter the URL for OAM server.	`oamhost.example.com`
`OAM_PORT`	Enter the port for OAM Server	`14100`
`OIM_HOST`	Enter the host name for OIG managed server.	`oimhost.example.com`
`OIM_PORT`	Enter the port for OIG Server.	`14000`

Run the OIGOAMIntegration.sh script from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/bin) to populate OHS Rules.
```
OIGOAMIntegration.sh -populateOHSRules
```
Verify that the oim.conf file is generated at ORACLE_HOME/idm/server/ssointg/templates.

Optional: If you want to manage the OAM admin console and SOA using the OHS Server, then you can add the following endpoints to OAM admin console and SOA specific sections in the oim.conf file.

# OAM Admin Console
<Location /oamconsole>
 SetHandler weblogic-handler
 WLCookieName jsessionid
 WebLogicHost <your server host here>
 WebLogicPort <your server port here>
 WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>

# SOA Infrastructure
<Location /soa-infra>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost <your server host here>
    WebLogicPort <your server port here>
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>

# SOA Composer
<Location /soa/composer>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost <your server host here>
    WebLogicPort <your server port here>
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>

# SOA Worklistapp
<Location /integration/worklistapp>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost <your server host here>
    WebLogicPort <your server port here>
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
</Location>

Remove the following parameters in the oim.conf file.
- /Nexaweb
- /xlWebApp
Copy the oim.conf file from the OIG home directory (Located at ORACLE_HOME/idm/server/ssointg/config) to OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf.
Restart OHS Server.

For information about restarting the Oracle HTTP Server instance, see Restarting Oracle HTTP Server Instances in Administering Oracle HTTP Server.

2.3.2.4 Configuring WLS Authentication Providers Using Automated Script

Configure WLS Authentication Providers using the OIGOAMIntegration.sh automated script for OIG-OAM integration.

You must configure the WLS Authentication Providers to set SSO logout for and security providers in OIG domain. So that both the SSO login and OIM client-based login, work appropriately.

For example, after executing OIGOAMIntegration.sh -configureWLSAuthnProviders script, the authenticators order would be as follows:

OAMIDAsserter
OIMSignatureAuthenticator
OIMAuthenticationProvider
LDAPAuthenticator
Depending on the LDAP directory you are using:
- OID: OIDAuthenticator
- OUD: OUDAuthenticator
- AD: ADAuthenticator
DefaultAuthenticator
DefaultIdentityAsserter
Trust Service Identity Asserter

To configure WLS Authentication Providers using automated script:

Open the configureWLSAuthnProviders.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example configureWLSAuthnProviders.config File

OIM_WLSHOST
OIM_WLSPORT
OIM_WLSADMIN
OIM_WLSADMIN_PWD
OIM_SERVER_NAME
## DIRTYPE values can be [OID | OUD | AD]
IDSTORE_DIRECTORYTYPE
IDSTORE_HOST
IDSTORE_PORT
IDSTORE_BINDDN
IDSTORE_BINDDN_PWD
IDSTORE_USERSEARCHBASE
IDSTORE_GROUPSEARCHBASE

The following table describes the parameters that you can set in the configureWLSAuthnProviders.config file.

Table 2-6 Parameters in configureWLSAuthnProviders.config file

Property	Description	Sample Value
`OIM_WLSHOST`	Enter the OIG admin server host name.	`oimadminhost.example.com`
`OIM_WLSPORT`	Enter the OIG admin server port.	`7001`
`OIM_WLSADMIN`	Enter the weblogic administrator user in OIM domain.	`weblogic`
`OIM_WLSADMIN_PWD`	Enter the password for the weblogic admin user in OIM domain.	`password`
`OIM_SERVER_NAME`	Enter the OIG server name.	`oim_server1`
`IDSTORE_DIRECTORYTYPE`	Enter the identity store directory type. Valid options are OID, OUD, and AD.	`OID`
`IDSTORE_HOST`	Enter the identity store host name.	`idstore.example.com`
`IDSTORE_PORT`	Enter the identity store port.	`3060`
`IDSTORE_BINDDN`	An administrative user in Oracle Internet Directory, Oracle Unified Directory or Microsoft Active Directory.	OID: `cn=orcladmin` OUD: `cn=oudadmin` AD: `CN=Administrator,CN=Users,DC=example.com,DC=example,dc=com`
`IDSTORE_BINDDN_PWD`	Enter the Password for administrative user in Oracle Internet Directory, Oracle Unified Directory, or Microsoft Active Directory.	`password`
`IDSTORE_USERSEARCHBASE`	Enter the location in the directory where users are stored.	`cn=users,dc=example,dc=com`
`IDSTORE_GROUPSEARCHBASE`	Enter the location in the directory where groups are stored.	`cn=groups,dc=example,dc=com`

Run the OIGOAMIntegration.sh script from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/bin) to configure WLS Authentication Providers:
```
OIGOAMIntegration.sh -configureWLSAuthnProviders
```
You have successfully executed the automated script for configuring WLS Authentication Providers.
Restart OIG domain servers. See Starting the Servers in Installing and Configuring Oracle Identity and Access Management.

2.3.2.5 Configuring LDAP Connector Using Automated Script

Configure LDAP Connector using automated script for integration, OIGOAMIntegration.sh.

The automated script executes the following operations and configures the LDAP Connector:

Copying the Application On-boarding LDAP templates into the downloaded Connector bundle.
Obtaining application names and other property values such as LDAP host and port from the configuration file.
Creating Application objects, target application and authoritative application, from the unmarshalled LDAP templates.
Executing create API method through the Application Manager to create the Application Instances from the Application objects.
Updating the IT Resource instance with values obtained from the configuration file as follows:
- baseContexts
- principal
- credentials
- host and port
- SSL (true or false)
Setting SSO.DefaultCommonNamePolicyImpl system property.
Setting properties in SSOIntegrationMXBean with values obtained from the configuration file:
- targetAppInstanceName
- targeITResourceNameForGroup
- directorytype
Updating the scheduled jobs with the SSO trusted and target parameters.
Updating container rules by invoking SSOIntegrationMXBean addContainerRules operation with values obtained from the configuration file:
- Directory type
- User search base
- User search base description
- Group search base
- Group search base description

Note:

Executing the script for configuring connector seeds only the default LDAP container rules into MDS. You can use custom container rules and manually upload them to MDS.

To configure the LDAP Connector:

Open the configureLDAPConnector.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example configureLDAPConnector.config File

IDSTORE_DIRECTORYTYPE
OIM_HOST
OIM_PORT
WLS_OIM_SYSADMIN_USER
WLS_OIM_SYSADMIN_USER_PWD
OIM_WLSHOST
OIM_WLSPORT
OIM_WLSADMIN
OIM_WLSADMIN_PWD
OIM_SERVER_NAME
IDSTORE_HOST
IDSTORE_PORT
IDSTORE_BINDDN
IDSTORE_BINDDN_PWD
IDSTORE_OIMADMINUSERDN
IDSTORE_OIMADMINUSER_PWD
IDSTORE_SEARCHBASE
IDSTORE_USERSEARCHBASE
IDSTORE_GROUPSEARCHBASE
IDSTORE_USERSEARCHBASE_DESCRIPTION
IDSTORE_GROUPSEARCHBASE_DESCRIPTION
IDSTORE_EMAIL_DOMAIN
## For ActiveDirectory use the values of "yes" or "no". i.e. IS_LDAP_SECURE
IS_LDAP_SECURE
SSO_TARGET_APPINSTANCE_NAME
## Path to expanded connector bundle: e.g. for OID and OUD
CONNECTOR_MEDIA_PATH
## Path for AD bundle
# CONNECTOR_MEDIA_PATH
## [ActiveDirectory]
# The following attributes need to be initialized only if Active Directory is the target server
# AD_DIRECTORY_ADMIN_NAME
# AD_DIRECTORY_ADMIN_PWD
# AD_DOMAIN_NAME
## Active Directory Connector Server details
# AD_CONNECTORSERVER_HOST
# AD_CONNECTORSERVER_KEY
# AD_CONNECTORSERVER_PORT
# AD_CONNECTORSERVER_TIMEOUT
## Set to yes if SSL is enabled
# AD_CONNECTORSERVER_USESSL

The following table describes the parameters that you can set in the in the configureLDAPConnector.config file.

Table 2-7 Parameters in configureLDAPConnector.config file

Property	Description	Sample Value
`IDSTORE_DIRECTORYTYPE`	Enter the identity store directory type. Valid options are OID, OUD, and AD.	`OID`
`OIM_HOST`	Enter the host name for OIG managed server.	`oimhost.example.com`
`OIM_PORT`	Enter the port for OIG Server.	`14000`
`WLS_OIM_SYSADMIN_USER`	Enter the system admin user to be used to connect to OIG while configuring SSO. This user needs to have system admin role.	`xelsysadm`
`WLS_OIM_SYSADMIN_USER_PWD`	Enter the password for OIG system administrator user.	`password`
`OIM_WLSHOST`	Enter the OIG admin server host name.	`oimadminhost.example.com`
`OIM_WLSPORT`	Enter the OIG admin server port.	`7001`
`OIM_WLSADMIN`	Enter the weblogic administrator user in OIM domain.	`weblogic`
`OIM_WLSADMIN_PWD`	Enter the password for the weblogic admin user in OIM domain.	`password`
`OIM_SERVER_NAME`	Enter the OIG server name. Note: You must manually add the `OIM_SERVER_NAME` property in the `configureLDAPConnector.config` file.	`oim_server1`
`IDSTORE_HOST`	Enter the identity store host name.	`idstore.example.com`
`IDSTORE_PORT`	Enter the identity store port.	`3060`
`IDSTORE_BINDDN`	An administrative user in Oracle Internet Directory, Oracle Unified Directory or Active Directory.	OID: `cn=orcladmin` OUD: `cn=oudadmin` AD: `CN=Administrator, CN=Users, DC=example.com, DC=example, dc=com`
`IDSTORE_BINDDN_PWD`	Enter the Password for administrative user in Oracle Internet Directory, Oracle Unified Directory, or Microsoft Active Directory.	`password`
`IDSTORE_OIMADMINUSERDN`	Enter the location of a container in the directory where system-operations users are stored. There are only a few system-operations users and are kept separate from enterprise users stored in the main user container. For example, the Oracle Identity Governance reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.	`cn=oimLDAP,cn=systemids,dc=example,dc=com`
`IDSTORE_OIMADMINUSER_PWD`	Enter the Password for the user that Oracle Identity Governance uses to connect to the identity store.	`password`
`IDSTORE_SEARCHBASE`	Enter the location in the directory where users and groups are stored.	`dc=example,dc=com`
`IDSTORE_USERSEARCHBASE`	Enter the Container under which Access Manager searches for the users.	`cn=users,dc=example,dc=com`
`IDSTORE_GROUPSEARCHBASE`	Enter the location in the directory where groups are stored.	`cn=groups, dc=example, dc=com`
`IDSTORE_USERSEARCHBASE_DESCRIPTION`	Enter the description for the directory user search base	Default user container
`IDSTORE_GROUPSEARCHBASE_DESCRIPTION`	Enter the description for the directory group search base.	Default group container
`IDSTORE_EMAIL_DOMAIN`	Enter the domain used for e-mail For example, `user@example.com`.	`example.com`
`IS_LDAP_SECURE`	It indicates the usage of SSL for LDAP Communication. Use `yes` or `no` for ActiveDirectory.	`false`
`SSO_TARGET_APPINSTANCE_NAME`	Enter the Target application instance name used for provisioning account to target LDAP.	`SSOTarget`
`CONNECTOR_MEDIA_PATH`	Enter the location of the Connector bundle downloaded and unzipped. Oracle Identity Governance would use this location to pick the Connector bundle to be installed.	OID/OUD: `/u01/oracle/products/identity/idm/server/ConnectorDefaultDirectory/OID-12.2.1.3.0` AD: `/u01/oracle/products/identity/idm/server/ConnectorDefaultDirectory/activedirectory-12.2.1.3.0`
`AD_DIRECTORY_ADMIN_NAME`	Name of AD Admin	`oimLDAP@example`
`AD_DIRECTORY_ADMIN_PWD`	Enter the password for the AD Directory Admin.	`password`
`AD_DOMAIN_NAME`	Enter the domain name configured in Microsoft Active Directory.	`example.com`
`AD_CONNECTORSERVER_HOST`	Enter the host name or IP address of the computer hosting the connector server.	`192.0.2.1`
`AD_CONNECTORSERVER_KEY`	Enter the key for the connector server.	<connectorserverkey>
`AD_CONNECTORSERVER_PORT`	Enter the number of the port at which the connector server is listening.	`8759`
`AD_CONNECTORSERVER_TIMEOUT`	Enter an integer value that specifies the number of milliseconds after which the connection between the connector server and the Oracle Identity Governance times out. A value of `0` means that the connection never times out.	`0`
`AD_CONNECTORSERVER_USESSL`	Enter `true` to specify that you will configure SSL between Oracle Identity Governance or Oracle Unified Directory and the Connector Server. Otherwise, enter `false`. For Active Directory, the value should be `yes` or `no`. The default value is `false` Note: It is recommended that you configure SSL to secure communication with the connector server.	`true` (or `false`)

Run the OIGOAMIntegration.sh script from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/bin) to configure the LDAP Connector:
```
OIGOAMIntegration.sh -configureLDAPConnector
```

You have successfully executed the automated script for configuring LDAP Connector.

Verifying the LDAP Connector Configuration

You can verify the LDAP Connector configuration by performing the following steps:

Verify that the target application instances are created:
1. Open a browser, and access the Oracle the Identity Self Service login page using the following URL format:
  http://OIM_HOST.com:PORT/identity/
2. Click the Manage tab, and then click the Applications box to open the Applications page.
3. Click the Search icon.
  
  The search results table displays the Target application instance name (The values entered in configureLDAPConnector.config file.) used for provisioning account to target LDAP.
  
  For example, SSOTarget and SSOTrusted-for-SSOTarget.
4. Select SSOTarget, and click Setting.
5. From the User section, select Organization.
6. Verify that the application is configured to be published to the Top organization.
Verify that the IT Resource instance is updated with the required parameters you have updated in the configureLDAPConnector.config file:
1. Open a browser, and access the Oracle Identity System Administration Console using the following URL format:
  http://HOSTNAME:PORT/sysadmin
2. Under Provisioning Configuration, click IT Resource.
  
  The Manage IT Resources page is displayed.
3. Search the SSO Server IT Resources and verify that the following attributes are updated with the parameters you specified in the configureLDAPConnector.config file:
  - baseContexts
  - principal
  - credentials
  - host and port
  - SSL (true or false)
Verify that the SSO.DefaultCommonNamePolicyImpl system property is updated with the value oracle.iam.ssointg.impl.handlers.account.commonname.plugins.impl.FirstNameLastNamePolicy using the Oracle Identity System Administration Console.
Verify that the SSOIntegrationMXBean is updated with the required parameters you have updated in the configureLDAPConnector.config file:
1. Open a browser, and access the Oracle Enterprise Manager Fusion Middleware Control for the OIG using the following URL format:
  http://ADMINSTRATION_SERVER:PORT/em
2. Expand Domain and open System MBean Browser.
3. Search the mbean with name SSOIntegrationMXBean.
4. Verify that the following attributes are updated with the parameters you specified in the configureLDAPConnector.config file:
  - DirectoryType
  - TargetAppInstanceName
  - TargetITResourceNameForGroup

2.3.2.6 Configuring SSO Integration Using Automated Script

Configure SSO Integration using automated script for integration, OIGOAMIntegration.sh.

Use OIGOAMIntegration.sh to register OIM as TAP partner for OAM, add the resource policies for OIG-OAM communication, and update SSOIntegrationMXBean values in MDS.

To configure SSO integration:

Open the configureSSOIntegration.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example configureSSOIntegration.config File

NAP_VERSION
COOKIE_EXPIRY_INTERVAL
OAM_HOST
OAM_PORT
OIM_SERVER_NAME
ACCESS_SERVER_HOST
ACCESS_SERVER_PORT
OAM_SERVER_VERSION
WEBGATE_TYPE
ACCESS_GATE_ID
ACCESS_GATE_PWD
COOKIE_DOMAIN
OAM_TRANSFER_MODE
SSO_ENABLED_FLAG
SSO_INTEGRATION_MODE
OIM_LOGINATTRIBUTE
## Parameters required for TAP registration
OAM11G_WLS_ADMIN_HOST
OAM11G_WLS_ADMIN_PORT
OAM11G_WLS_ADMIN_USER
OAM11G_WLS_ADMIN_PASSWD
## Required if OAM_TRANSFER_MODE is not OPEN
#SSO_KEYSTORE_JKS_PASSWORD
#SSO_GLOBAL_PASSPHRASE
OIM_WLSHOST
OIM_WLSPORT
OIM_WLSADMIN
OIM_WLSADMIN_PWD
IDSTORE_OAMADMINUSER
IDSTORE_OAMADMINUSER_PWD
## Required in SSL mode
#OIM_TRUST_LOC
#OIM_TRUST_PWD
#OIM_TRUST_TYPE
OAM11G_IDSTORE_NAME

The following table describes the parameters that you can set in the configureSSOIntegration.config file.

Table 2-8 Parameters in configureSSOIntegration.config File

Property	Description	Sample Value
`NAP_VERSION`	Enter the NAP protocol version. (4 indicates 11g+)	`4`
`OAM11G_IDSTORE_NAME`	Enter the name of the identity Store configured in OAM. This will be set as the default/System ID Store in OAM.	`OAMIDStore`
`COOKIE_EXPIRY_INTERVAL`	Enter the Cookie expiration period.	`120`
`OAM_HOST`	Enter the hostname for OAM server.	`oamhost.example.com`
`OAM_PORT`	Enter the port for OAM Server	`14100`
`ACCESS_SERVER_HOST`	Enter the Access Manager OAP host.	`oamaccesshost.example.com`
`ACCESS_SERVER_PORT`	Enter the Access Manager OAP port.	`5575`
`OAM_SERVER_VERSION`	Only OAM 12c is supported. OAM 10g is not supported in 12c integration.	12c
`WEBGATE_TYPE`	Enter the WebGate agent type you want to create. 10g is no longer supported in 12c.	`ohsWebgate12c` or `ohsWebgate11g`
`ACCESS_GATE_ID`	Name to be assigned to the WebGate. This is the value specified during OAM configuration.	`Webgate_IDM`
`ACCESS_GATE_PWD`	Enter the Password for Access Gate ID.	<password>
`COOKIE_DOMAIN`	Enter the domain in which the WebGate functions.	`.example.com`
`OAM_TRANSFER_MODE`	Enter the security mode in which the access servers function. Supported values are OPEN and SIMPLE	`OPEN`
`SSO_ENABLED_FLAG`	Set it to `true` if OIG-OAM integration is enabled. `False`, otherwise.	`true`
`SSO_INTEGRATION_MODE`	Enter the integration mode with OAM. With Challenge Question Response (CQR) mode, OIG will handle the password policy and password operations. With One Time Password (OTP) mode, any password operations will be handled by OAM itself and there will be no password change or reset in OIG.	`CQR`
`OIM_LOGINATTRIBUTE`	Enter the login attribute of the identity store that contains the user's login name. User uses this attribute for logging in. For example, User Login.	User Login
`OAM11G_WLS_ADMIN_HOST`	Enter the host for Admin server in OAM Domain.	`oamadminhost.example.com`
`OAM11G_WLS_ADMIN_PORT`	Enter the port for Admin server in OAM domain.	`7001`
`OAM11G_WLS_ADMIN_USER`	Enter the weblogic administrator user in OAM domain.	`weblogic`
`OAM11G_WLS_ADMIN_PASSWD`	Enter the password for the weblogic admin user in OAM domain.	password
`SSO_KEYSTORE_JKS_PASSWORD`	Enter the password for keystore, required for SIMPLE mode communication with OAM.	password
`SSO_GLOBAL_PASSPHRASE`	The random global passphrase for SIMPLE security mode communication with Access Manager. By default, Access Manager is configured to use the OPEN security mode. If you want to use the installation default of OPEN mode, you can skip this property.	password
`OIM_WLSHOST`	Enter the OIG admin server host name.	`oimadminhost.example.com`
`OIM_WLSPORT`	Enter the OIG admin server port.	`7001`
`OIM_WLSADMIN`	Enter the weblogic administrator user in OIM domain.	`weblogic`
`OIM_WLSADMIN_PWD`	Enter the password for the weblogic admin user in OIM domain.	<password>
`OIM_SERVER_NAME`	Enter the OIG server name.	`oim_server1`
`IDSTORE_OAMADMINUSER`	Enter the user you use to access your Oracle Access Management Console.	`oamAdmin`
`IDSTORE_OAMADMINUSER_PWD`	Enter the password for the user you use to access your Oracle Access Management Console.	<password>
`OIM_TRUST_LOC`	Enter the location of the OIG trust store.	`ORACLE_HOME/wlserver/server/lib/DemoTrust.jks`
`OIM_TRUST_PWD`	Enter the password to access the trust store	<password>
`OIM_TRUST_TYPE`	Enter the type of the trust store. JKS, by default	JKS

Run the OIGOAMIntegration.sh script from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/bin) to configure SSO Integration:

OIGOAMIntegration.sh -configureSSOIntegration

The OIGOAMIntegration.sh adds the following policy to OAM:

/FacadeWebApp/*
/OIGUI/*
/iam/governance/*
/soa/**
/ucs/**
/reqsvc/**
/workflowservice/**
/HTTPClnt/**
/callbackResponseService/**
/role-sod/**
/sysadmin/**
/oim/**
/admin/**
/spml-xsd/**
/spmlws/**
/sodcheck/**
/SchedulerService-web/**
/jmx-config-lifecycle/**
/integration/**
/identity/**
/provisioning-callback/**
/soa-infra/**
/CertificationCallbackService/**
/identity/faces/firstlogin
/admin/faces/pages/pwdmgmt.jspx
/sysadmin/
/xmlpserver
/sysadmin
/identity/faces/taskdetails
/identity/faces/trackregistrationrequests
/identity/faces/request
/identity/
/identity
/sysadmin/faces/home
/identity/faces/home
/oim/faces/pages/Admin.jspx
/oim/faces/pages/Self.jspx
/admin/faces/pages/Admin.jspx

Add the following policies to OAM:
1. Log in to the Oracle Access Management Console:
  http://oam_adminserver_host:oam_adminserver_port/oamconsole
2. From the Application Security Launch Pad, click Application Domains in the Access Manager section.
  
  The Search Application Domains page is displayed.
3. Click Search on the Search page.
  
  A list of Application domains appears.
4. Click the domain IAM Suite.
5. Click the Resources Tab.
6. Click Create.
7. Select HTTP as the Resource Type and IAMSuiteAgent as the Host Identifier.
8. Enter the following Resource URLs:
  - /iam/governance/configmgmt/**
  - /iam/governance/scim/v1/**
  - /iam/governance/token/api/v1/**
  - /iam/governance/applicationmanagement/**
  - /iam/governance/adminservice/api/v1/**
  - /iam/governance/selfservice/api/v1/**
9. Click Apply.
Seed the OIG Policy Resources by performing the following steps:
1. Run wlst.sh from $ORACLE_HOME <OIG_INSTALL_LOCATION>/oracle_common/common/bin
2. Type connect()
3. Provide OAM domain Admin username. For example, weblogic
4. Provide OAM domain Admin password
5. Provide the OAM Admin server URL. For example, t3://<OAM Host>:<OAM WLS Port>
6. Run the following command:
```
importPolicyDelta(pathTempOAMPolicyFile="ORACLE_HOME <OIG_INSTALL_LOCATION>/idm/oam/def_import_policies/oim-resource-policy.xml",
isAppDomainUpdate="true")
```
Verify the attribute version in SSOIntegrationMXBean.
1. Open a browser, and access the Oracle Enterprise Manager Fusion Middleware Control for the OIG using the following URL format:
  http://ADMINSTRATION_SERVER:PORT/em
2. Expand Domain and open System MBean Browser.
3. Search the mbean with name SSOIntegrationMXBean.
4. Click SSOIntegrationMXBean.
5. Make sure that the attribute Version = 11g.
  
  Note:
  Perform the above steps to enable auto-login in a new 12.2.1.4.0 integrated environment.

You have successfully executed the automated script for configuring SSO Integration.

Verifying the SSO Integration Configuration

Perform the following steps:

Verify the resources
1. Log in to the Oracle Access Management Console:
  http://oam_adminserver_host:oam_adminserver_port/oamconsole
2. From the Application Security Launch Pad, click Application Domains in the Access Manager section.
  
  The Search Application Domains page is displayed.
3. Click Search on the Search page.
  
  A list of Application domains appears.
4. Click the domain IAM Suite.
5. Click the Resources tab and verify that the following resources are created.
  - /soa/**
  - /jmx-config-lifecycle/**
  - /SchedulerService-web/**
  - /sodcheck/**
  - /spmlws/**
  - /spml-xsd/**
  - /XIMDD/**
  - /admin/**
  - /oim/**
  - /sysadmin/**
  - /role-sod/**
  - /callbackResponseService/**
  - /HTTPClnt/**
  - /iam/governance/*
  - /OIGUI/*
  - /FacadeWebApp/*
  - /provisioning-callback/**
  - /CertificationCallbackService/**
  - /iam/governance/configmgmt/**
  - /iam/governance/scim/v1/**
  - /iam/governance/token/api/v1/**
  - /iam/governance/applicationmanagement/**
  - /iam/governance/adminservice/api/v1/**
  - /iam/governance/selfservice/api/v1/**

Verify that the proposed value in the oig-oam-integration log file and the values in the SSOIntegrationMXBean are same.

Open the oig-oam-integration log file (Located at ORACLE_HOME/idm/server/ssointg/logs) and search for the proposed value.

Example oig-oam-integration Log File


OIMIntegrationAutomationTool.connectToDomainRuntime...
Connecting to t3://myhost.us.example.com:7002
OIMIntegrationAutomationTool.getJMXConnector...
mserver: /jndi/weblogic.management.mbeanservers.domainruntime
Connection to domain runtime mbean server established
SSOIntegrationMXBean name: oracle.iam:Location=oim_server1,name=SSOIntegrationMXBean,type=IAMAppRuntimeMBean,Application=oim
sak SSOIntegrationAutomationTool: got SSOIntegrationMXBean...
 sak current value of accessServerHost=myhost.us.example.com
 proposed value of accessServerHost=myhost.us.example.com
  sak new value of accessServerHost=myhost.us.example.com
 sak current value of oamAdminUser=oamAdminUser
 sak proposed value of oamAdminUser=oamAdminUser
 sak new value of oamAdminUser=oamAdminUser
 current value of tapEndpointUrl=http://myhost.us.example.com:14100/oam/server/dap/cred_submit
 sak proposed value of tapEndpointUrl=http://myhost.us.example.com:14100/oam/server/dap/cred_submit
 sak new value of tapEndpointUrl=http://myhost.us.example.com:14100/oam/server/dap/cred_submit
 current value of loginIdAttribute=User Login
 current value of version=12c
 proposed value of version=12c
 new value of version=12c
 current value of accessServerPort=5575
 proposed value of accessServerPort=5575
 new value of accessServerPort=5575
 current value of oamServerPort=14100
 proposed value of oamServerPort=14100
 new value of oamServerPort=5575
 current value of accessGateID=Webgate_IDM
 proposed value of accessGateID=Webgate_IDM
 new value of accessGateID=Webgate_IDM
 current value of napVersion=4
 proposed value of napVersion=4
 new value of napVersion=4
 current value of cookieDomain=.us.example.com
 proposed value of cookieDomain=.us.example.com
 new value of cookieDomain=.us.example.com
 current value of cookieExpiryInterval=120
 proposed value of cookieExpiryInterval=120
 new value of cookieExpiryInterval=120
 current value of transferMode=Open
 proposed value of transferMode=Open
 new value of transferMode=Open
 current value of webgateType=ohsWebgate11g
 proposed value of webgateType=ohsWebgate11g
 new value of webgateType=ohsWebgate11g
 proposed value of SSOEnabled=true
 new value of isSSOEnabled=true
 current value of integrationMode=CQR
 proposed value of integrationMode=CQR
 new value of integrationMode=CQR
 Connection closed sucessfully
 sak configure oam

 Connecting to OAM Domain MBean Server... looking for OAM domain credentials.
 JMX URL : service:jmx:t3://myhost.us.example.com:7001/jndi/weblogic.management.mbeanservers.domainruntime
 sak mbeanObjectNames size: 1
 sak Registering OIM as a TAP partner with OAM...
 sak Registering OIM as a TAP partner with OAM was successful!!
 sak configure oam before strCipherKey=DEC40506366E926CACC9A0D666E94F85
 sak mbeanObjectNames size: 1
 Getting OAM/TAP Endpoint URL...
 Getting OAM/TAP Endpoint URL was successful!!
 MBean server connection closed sucessfully

Open a browser, and access the Oracle Enterprise Manager Fusion Middleware Control for the OIG using the following URL format:
http://ADMINSTRATION_SERVER:PORT/em
Expand Domain and open System MBean Browser.
Search the mbean with name SSOIntegrationMXBean.
Ensure that all the required fields are updated as per the proposed value in the oig-oam-integration log file.

Open the oam-config.xml in the OAM Domain under DOMAIN_HOME/config/fmwconfig and verify that UserStore attribute points to the name of the identity store you specified in the configureSSOIntegration.config file (For example, OAMIDSTORE).

2.3.2.7 Enabling OAM Notifications Using Automated Script

Enable OAM notifications using the OIGOAMIntegration.sh automated script for OIG-OAM integration.

Event handlers are required to terminate user sessions. OAM notification handlers are not loaded by default. Run OIGOAMIntegration.sh -enableOAMsessionDeletion to import OAM notification handlers and register OIG System Administrator to utilize OAM REST APIs.

To enable OAM notification:

Open the enableOAMSessionDeletion.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example enableOAMSessionDeletion.config File

OIM_SERVER_NAME
OIM_WLSHOST
OIM_WLSPORT
OIM_WLSADMIN
OIM_WLSADMIN_PWD
IDSTORE_DIRECTORYTYPE
IDSTORE_HOST
IDSTORE_PORT
## Specify the IDStore admin credentials below
IDSTORE_BINDDN
IDSTORE_BINDDN_PWD
IDSTORE_USERSEARCHBASE
IDSTORE_GROUPSEARCHBASE
IDSTORE_SYSTEMIDBASE
IDSTORE_OAMADMINUSER
IDSTORE_OAMSOFTWAREUSER

The following table describes the parameters that you can set in the enableOAMSessionDeletion.config file.

Table 2-9 Parameters in enableOAMSessionDeletion.config File

Property	Description	Sample Value
`OIM_WLSHOST`	Enter the OIG admin server host name.	`oimadminhost.example.com`
`OIM_WLSPORT`	Enter the OIG admin server port.	`7001`
`OIM_WLSADMIN`	Enter the weblogic administrator user in OIM domain.	`weblogic`
`OIM_WLSADMIN_PWD`	Enter the password for the weblogic admin user in OIM domain.	`password`
`OIM_SERVER_NAME`	Enter the OIG server name. Note: You must manually add the `OIM_SERVER_NAME` property in the `enableOAMSessionDeletion.config` file.	`oim_server1`
`IDSTORE_DIRECTORYTYPE`	Enter the identity store directory type. Valid options are OID, OUD, and AD.	`OID`
`IDSTORE_HOST`	Enter the identity store host name.	`idstore.example.com`
`IDSTORE_PORT`	Enter the identity store port.	`3060`
`IDSTORE_BINDDN`	An administrative user in Oracle Internet Directory, Oracle Unified Directory or Active Directory.	OID: `cn=orcladmin` OUD: `cn=oudadmin` AD: `CN=Administrator,CN=Users,DC=example.com,DC=example,dc=com`
`IDSTORE_BINDDN_PWD`	Enter the Password for administrative user in Oracle Internet Directory, Oracle Unified Directory or Microsoft Active Directory.	`password`
`IDSTORE_USERSEARCHBASE`	Enter the location in the directory where users are stored.	`cn=users,dc=example,dc=com`
`IDSTORE_GROUPSEARCHBASE`	Enter the location in the directory where groups are stored.	`cn=groups,dc=example,dc=com`
`IDSTORE_SYSTEMIDBASE`	Enter the location of a container in the directory where system-operations users are stored. There are only a few system operations users and are kept separate from enterprise users stored in the main user container. For example, the Oracle Identity Governance reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.	`cn=systemids,dc=example,dc=com`
`IDSTORE_OAMADMINUSER`	Enter the user you use to access your Oracle Access Management Console.	`oamAdmin`
`IDSTORE_OAMSOFTWAREUSER`	Enter the user you use to interact with the LDAP server.	`oamLDAP`

Note:

You must manually add the WebLogicCluster parameter to the list of Managed Servers in the cluster:

Run the OIGOAMIntegration.sh script from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/bin) to enable OAM notifications:
```
OIGOAMIntegration.sh -enableOAMSessionDeletion
```
You have successfully executed the automated script to enable OAM notifications.
To verify the configuration, navigate to OIG MDS and ensure that the following event handlers exist under /db/ssointg/:
- EventHandlers.xml
- ldapconnector_sso_eventhandlers.xml

2.3.2.8 Adding Missing Object Classes Using Automated Script

Add the Missing Object Classes using the OIGOAMIntegration.sh automated script for OIG-OAM integration.

Note:

You can only add object classes for existing users in Oracle Internet Directory or Oracle Unified Directory. This feature is not supported in Active Directory.

Open the addMissingObjectClasses.config file from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/config) in a text editor and update the parameters.

Example addMissingObjectClasses.config File

IDSTORE_DIRECTORYTYPE: OID
IDSTORE_HOST: idstore.example.com
IDSTORE_PORT: 3060
IDSTORE_BINDDN: cn=orcladmin
IDSTORE_BINDDN_PWD: <password>
IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com

The following table describes the parameters that you can set in the addMissingObjectClasses.config file.

Table 2-10 Parameters in addMissingObjectClasses.config file

Parameters	Description	Sample Value
`IDSTORE_DIRECTORYTYPE`	Enter the identity store directory type. Valid options are OID or OUD.	`OUD`
`IDSTORE_HOST`	Enter the identity store host name.	`idstore.example.com`
`IDSTORE_PORT`	Enter the identity store port.	`389`
`IDSTORE_BINDDN`	An administrative user in Oracle Internet Directory or Oracle Unified Directory.	OID: `cn=orcladmin` OUD: `cn=oudadmin`
`IDSTORE_BINDDN_PWD`	Enter the password for administrative user in Oracle Internet Directory or Oracle Unified Directory.	password
`IDSTORE_USERSEARCHBASE`	Enter the location in the directory where users are stored.	`cn=users,dc=example,dc=com`

Run the OIGOAMIntegration.sh script from the OIG Oracle home directory (Located at ORACLE_HOME/idm/server/ssointg/bin) to enable OAM notifications:
```
OIGOAMIntegration.sh -addMissingObjectClasses
```

You have successfully executed the automated script to add object classes for existing users in LDAP directory.

Note:

This step depends on the number of users in the LDAP directory. It is estimated to take 10 minutes per 10000 users in the LDAP directory.

If there are no object classes in the LDAP, then the following are added for the existing LDAP users:

OIMPersonPwdPolicy
OblixOrgPerson
OblixPersonPwdPolicy
obpasswordexpirydate

2.3.2.9 Restarting Servers

After executing the automated script to complete the OIG-OAM integration process, restart all the servers.

Restart OHS Server. For information, see Restarting Oracle HTTP Server Instances in Administering Oracle HTTP Server.
Restart the OAM domain. For more information, see Starting the Servers in Installing and Configuring Oracle Identity and Access Management.
Restart OIG domain. For more information, see Starting the Serversin Installing and Configuring Oracle Identity and Access Management.

You have successfully executed the automated script and completed the OIG-OAM Integration process.

Proceed with validation of your integration setup. See Validating OIG-OAM integration.

2.4 Validating the Access Manager and Oracle Identity Governance Integration

Performing the following sanity checks (validating the integrated environment) can help you avoid some common issues that could be encountered during runtime.

In this release, Oracle Identity Governance is integrated with Access Manager using the OIGOAMIntegration.sh script. After Oracle Identity Governance is integrated with Oracle Access Manager, the following configuration settings and files are updated:

The SSOConfig section in the oim-config.xml file, stored in the OIG Metadata store.
The realm security providers in OIM_DOMAIN_HOME/config.xml.
The OIG domain credential store in OIM_DOMAIN_HOME/config/fmwconfig/cwallet.sso.
The orchestration event-handlers required for SSO integration in Eventhandler.xml, stored in the OIG Metadata store..
The SSO logout configuration in OIM_DOMAIN_HOME/config/fmwconfig/jps-config.xml.

See Also:

2.4.1 Validating the Oracle Identity Governance SSO Configuration Settings

This procedure explains how to validate the SSOConfig settings in oim-config.xml:

See Also:

Getting Started Using the Fusion Middleware Control MBean Browsers in Administering Oracle Fusion Middleware.

Log in to Oracle Enterprise Manager Fusion Middleware Control.
Select Weblogic Domain, then right-click the domain name.
Open System Mbean Browser and search for the SSOIntegrationMXBean.
Verify the following attribute settings are correct after running OIGOAMIntegration.sh. Update any values as needed:
- Port of OAM Managed Server, oamServerPort is updated.
- Admin user for OAM, oamAdminUser is updated.
- SsoEnabled attribute is write-only. To ensure it is set to true, manually set it in the Mbean Browser.
  
  To check the attribute value:
  1. Open the Operations tab and select the isSsoEnabled attribute.
  2. Click the Invoke button to see the current value.
- If using TAP communication, the TapEndpointURL attribute is present.
- If using Oracle Access Protocol (OAP) communication, the following attributes are present: AccessGateID, AccessServerHost, AccessServerPort, CookieDomain, CookieExpiryInterval, NapVersion, TransferMode, WebgateType.
- If Version is set to 11g, verify the TapEndpointURL attribute is set to a valid URL.
- IntegrationMode is set to CQR.
- DirectoryType is set to OID or OUD or AD.
- TargetITResourceNameForGroup is set to SSO Server
- TargetApplicationInstanceName is set to the application instance name used during OIGOAMIntegration.sh execution.

2.4.2 Validating the Oracle Identity Governance Security Provider Configuration

This procedure explains how to validate the Oracle Identity Governance Security Provider configuration.

In the WebLogic Server Administration Console, navigate to the OIG domain.
Navigate to Security Realms > myrealm and then click the Providers tab.

Confirm the Authentication Providers are configured as follows.

Authentication Provider	Control Flag
OAMIDAsserter	REQUIRED
OIMSignatureAuthenticator	SUFFICIENT
OIMAuthenticationProvider	SUFFICIENT
LDAP Authenticator	SUFFICIENT
DefaultAuthenticator	SUFFICIENT
DefaultIdentityAsserter	Not Applicable
Trust Service Identity Asserter	Not Applicable

The LDAP Authenticator name may vary depending on which LDAP provider you are using. For example for Oracle Unified Directory, it is OUDAuthenticator. Verify it is configured correctly by selecting Users and Groups tab, and confirming the LDAP users are listed in Users tab.

2.4.3 Validating the Access Manager Security Provider Configuration

This procedure explains how to validate the Access Manager Security Provider configuration.

In the WebLogic Server Administration Console, navigate to the OAM domain.
Navigate to Security Realms > myrealm. Then, click the Providers tab.

Confirm the Authentication Providers are configured as follows.

Authentication Provider	Control Flag
Trust Service Identity Asserter	Not applicable
OAMIDAsserter	Required
DefaultAuthenticator	SUFFICIENT
LDAP Authenticator	SUFFICIENT
DefaultIdentityAsserter	Not applicable

The LDAP authenticator varies depending upon the LDAP provider being used. Verify that it is configured correctly by clicking the Users and Groups tab, and confirming that the LDAP users are listed in Users tab.

2.4.4 Validating the Oracle Identity Governance Domain Credential Store

All passwords and credentials used during communication between Oracle Identity Governance and Access Manager are stored in the domain credential store.

To validate the passwords and credentials used to communicate:

Login to Oracle Enterprise Manager Fusion Middleware Control for the OIG domain and select WebLogic Domain.
From the Weblogic Domain drop-down, navigate to Security and click Credentials.
Expand the oim instance. Verify the following credentials:
- SSOAccessKey: For OPEN mode only
- SSOKeystoreKey: For SIMPLE mode only
- SSOGobalPP: For SIMPLE mode only
- OIM_TAP_PARTNER_KEY
- OAMAdminPassword

2.4.5 Validating the Oracle Identity Governance Event Handlers Configured for SSO

A set of event handlers is uploaded to the Oracle Identity Governance MDS in order to support session termination after a user status change. These event handlers notify Access Manager when a user status is changed, which then terminates the user session. They are uploaded to MDS as part of EventHandlers.xml file, located at /db/ssointg/EventHandlers.xml.

See Also:

Getting Started Using the Fusion Middleware Control MBean Browsers in Administering Oracle Fusion Middleware.
Deploying and Undeploying Customizations in Developing and Customizing Applications for Oracle Identity Governance.

To confirm all event handlers are configured correctly, export the EventHandlers.xml file using Oracle Enterprise Manager Fusion Middleware Control:

Log in to Oracle Enterprise Manager Fusion Middleware Control for the OIG domain.
Click the Target Navigation icon on the left, expand Identity and Access then expand Access and click OIM.
Right-click and navigate to System MBean Browser.
Under Application Defined MBeans, expand each of the following: Oracle.mds.lcm, Server:oim_server1, Application:OIM, MDSAppRuntime, and click MDSAppRuntime.
Click the Operations tab, and then, click exportMetadata.
In toLocation, enter /tmp or the name of another directory. This is the directory where the file will be exported.
In the docs field, click Edit and then Add and enter the complete file location as the Element:
```
/db/oim-config.xml
/db/ssointg/EventHandlers.xml
/db/LDAPContainerRules.xml
```
Select false for excludeAllCust, excludeBaseDocs, and excludeExtendedMetadata.
Click Invoke to export the files specified in the docs field to the directory specified in the toLocation field.

Verify list of handlers in EventHandlers.xml:

<postprocess-handler class="oracle.iam.sso.eventhandlers.UserLockedNotificationHandler" entity-type="User" operation="LOCK" name="UserLockedNotificationHandler" order="FIRST" stage="postprocess" sync="TRUE"/>
<postprocess-handler class="oracle.iam.sso.eventhandlers.UserLockedNotificationHandler" entity-type="User" operation="UNLOCK" name="UserLockedNotificationHandler" order="FIRST" stage="postprocess" sync="TRUE"/>
<postprocess-handler class="oracle.iam.sso.eventhandlers.UserStatusNotificationHandler" entity-type="User" operation="ENABLE" name="UserStatusNotificationHandler" order="FIRST" stage="postprocess" sync="TRUE"/>
<postprocess-handler class="oracle.iam.sso.eventhandlers.UserStatusNotificationHandler" entity-type="User" operation="DISABLE" name="UserStatusNotificationHandler" order="FIRST" stage="postprocess" sync="TRUE"/>
<postprocess-handler class="oracle.iam.sso.eventhandlers.UserUpdatedNotificationHandler" entity-type="User" operation="MODIFY" name="UserUpdatedNotificationHandler" order="FIRST" stage="postprocess" sync="TRUE"/>
<postprocess-handler class="oracle.iam.sso.eventhandlers.UserUpdatedNotificationHandler" entity-type="User" operation="DELETE" name="UserUpdatedNotificationHandler" order="FIRST" stage="postprocess" sync="TRUE"/>
<action-handler class="oracle.iam.sso.eventhandlers.RoleGrantNotificationHandler" entity-type="RoleUser" operation="CREATE" name="RoleGrantNotification" order="FIRST" stage="postprocess" sync="TRUE"/>
<action-handler class="oracle.iam.sso.eventhandlers.RoleGrantNotificationHandler" entity-type="RoleUser" operation="MODIFY" name="RoleGrantNotification" order="FIRST" stage="postprocess" sync="TRUE"/>
<action-handler class="oracle.iam.sso.eventhandlers.RoleGrantNotificationHandler" entity-type="RoleUser" operation="DELETE" name="RoleGrantNotification" order="FIRST" stage="postprocess" sync="TRUE"/>

2.4.6 Validating the Oracle Identity Governance SSO Logout Configuration

Oracle Identity Governance logout is configured to use single logout after the integration is complete. After a user logs out from Oracle Identity Governance, they are logged out from all the Access Manager protected applications as well.

To verify the configuration of single logout, do the following:

From your present working directory, move to the following directory:
```
OIM_DOMAIN_HOME/config/fmwconfig 
```
Open the jps-config.xml file.

Ensure the <propertySet name="props.auth.uri.0"> element in the jps-config.xml file contains entries similar to the following example:

<propertySet name="props.auth.uri.0">
<property name="logout.url" value="/oamsso/logout.html"/>
<property name="autologin.url" value="/obrar.cgi"/>
<property name="login.url.BASIC" value="/${app.context}/adfAuthentication"/>
<property name="login.url.FORM" value="/${app.context}/adfAuthentication"/>
<property name="login.url.ANONYMOUS" value="/${app.context}/adfAuthentication"/>
</propertySet>

2.4.7 Functionally Testing the Access Manager and Oracle Identity Governance Integration

The final task is to verify the Access Manager and Oracle Identity Governance integration.

Perform the steps shown in the following table in sequence.

Table 2-11 Verifying Access Manager and Oracle Identity Governance Integration

Step	Description	Expected Result
1	Log in to the Oracle Access Management Console as the `weblogic_idm` user using the URL: http://admin_server_host:admin_server_port/oamconsole	Provides access to the administration console.
2	Access the Oracle Identity Governance administration page with the URL: For Oracle Identity Self Service: http://hostname:port/identity For Oracle Identity System Administration: http://hostname:port/sysadmin where hostname:port can be for either Oracle Identity Management or OHS, depending on whether a Domain Agent or WebGate is used.	The Oracle Access Management login page from the Access Manager managed server should display. Verify the links for "Forgot Password", "Register New Account" and "Track User Registration" features appear in the login page. Verify that each link works. For more information about these features, see About Password Management Scenarios.
3	Log in as `xelsysadm` (Oracle Identity Governance administrator).	The Oracle Identity Governance Admin Page should be accessible.
4	Create a new user using Oracle Identity Self Service. Close the browser and try accessing the OIG Identity Page. When prompted for login, provide valid credentials for the newly-created user.	You should be redirected to Oracle Identity Governance and be required to reset the password. After resetting the password and setting the challenge question, user should be automatically logged into the application. Auto-login should work.
5	Close the browser and access Oracle Identity Self Service.	The Oracle Access Management login page from the Access Manager managed server should display. Verify the links for "Forgot Password", "Register New Account" and "Track User Registration" features appear in the login page. Verify that each link works. For more information about these features, see About Password Management Scenarios.
6	Verify the lock/disable feature works by opening a browser and logging in as a test user. In another browser session, log in as an administrator, then lock or disable the test user account.	The user must be redirected back to the login page while accessing any of the links.
7	Verify the SSO logout feature works by logging into Oracle Identity Self Service as test user or system administrator.	Upon logout from the page, you are redirected to the SSO logout page.

2.4.8 Validating Integration Configuration

Validate that the oam-config.xml in the OAM Domain under DOMAIN_HOME/config/fmwconfig contains the IDStore provided during OAM configuration, say OAMIDSTORE. XML node SessionRuntime>UserStore should not have UserIdentityStore1, but OAMIDSTORE.

Validate if scheduled jobs exist:
- SSO Group Create And Update Full Reconciliation
- SSO Group Create And Update Incremental Reconciliation
- SSO Group Delete Full Reconciliation
- SSO Group Delete Incremental Reconciliation
- SSO Group Hierarchy Sync Full Reconciliation
- SSO Group Hierarchy Sync Incremental Reconciliation
- SSO Group Membership Full Reconciliation
- SSO Group Membership Incremental Reconciliation
- SSO Post Enable Provision Role Hierarchy to LDAP
- SSO Post Enable Provision Roles to LDAP
- SSO Post Enable Provision Users to LDAP
- SSO User Incremental Reconciliation
- SSO User Full Reconciliation
- SSO Post Enable Provision Role Membership to LDAP
Validate if the IT Resources are updated or created appropriately.
- Navigate to Provisioning Configuration>ITResource.
- Search for IT resource Type OID Connector.
- Verify that IT Resources such as SSOTargetApp and SSOTrusted-for-SSOTargetApp have correct parameter values.

Verify that the log at $ORACLE_HOME/idm/server/ssointg/logs/oig-oam-integration_*.log contains:

[2017-12-22 02:25:13] Seeding OIM Resource Policies into OAM
[2017-12-22 02:25:13] Loading xml... /scratch/userid/devtools/Middleware///idm/server/ssointg/templates/Resources.xml
[2017-12-22 02:25:14] Loading xml... /scratch/userid/devtools/Middleware///idm/server/ssointg/templates/AuthnPolicies.xml
[2017-12-22 02:25:14] Loading xml... /scratch/userid/devtools/Middleware///idm/server/ssointg/templates/AuthzPolicies.xml
[2017-12-22 02:25:14] Getting Application Domains...
[2017-12-22 02:25:14] WebResourceClient::getAppDomainResource(): http://host:port/oam/services/rest/11.1.2.0.0/ssa/policyadmin/appdomain
[2017-12-22 02:25:15] Authenticating using {oamAdmin:******}
[2017-12-22 02:25:15] Getting Resources from domain 'IAM Suite'
[2017-12-22 02:25:15] WebResourceClient::getResource(): http://host:port/oam/services/rest/11.1.2.0.0/ssa/policyadmin/resource
[2017-12-22 02:25:16] Getting Resources from domain 'Fusion Apps Integration'
[2017-12-22 02:25:16] WebResourceClient::getResource(): http://host:port/oam/services/rest/11.1.2.0.0/ssa/policyadmin/resource
[2017-12-22 02:25:16] Getting Authentication Policies from domain 'IAM Suite'
[2017-12-22 02:25:16] WebResourceClient::getAuthenticationPolicyResource(): http://host:port/oam/services/rest/11.1.2.0.0/ssa/policyadmin/authnpolicy
[2017-12-22 02:25:16] Getting Authorization Policies from domain 'IAM Suite'
[2017-12-22 02:25:16] WebResourceClient::getAuthorizationPolicyResource(): http://host:port/oam/services/rest/11.1.2.0.0/ssa/policyadmin/authzpolicy
[2017-12-22 02:25:16] Resources Seeded!!

2.5 Troubleshooting Common Problems in Access Manager and OIG Integration

These sections describe common problems you might encounter in an Oracle Identity Governance and Access Manager integrated environment and explain how to solve them.

In addition to this section, review the Error Messages for information about the error messages you may encounter.

For information about additional troubleshooting resources, see Using My Oracle Support for Additional Troubleshooting Information.

2.5.1 Troubleshooting Single Sign-On Issues in an Access Manager and OIG Integrated Environment

This section describes common problems and solutions relating to single sign-on in the integrated environment. Using single sign-on, a user can access Oracle Identity Governance resources after being successfully authenticated by Access Manager. When accessing any Oracle Identity Governance resource protected by Access Manager, the user is challenged for their credentials by Access Manager using the Oracle Access Management Console login page.

This section discusses the following single sign-on issues:

2.5.1.1 Diagnosing Single Sign-On Issues By Capturing HTTP Headers

Checking the HTTP headers may provide diagnostic information about login issues.You can collect information from the HTTP headers for troubleshooting issues. This can be done by enabling HTTP tracing in the web browser, logging into Access Manager as a new user, and examining the headers for useful information.

2.5.1.2 Access Manager Redirection to OIG Login Page

After accessing an Oracle Identity Governance resource using OHS (for example, http://OHS_HOST:OHS_PORT/identity), the user is redirected to the Oracle Identity Governance login page instead of the Oracle Access Management Console login page.

Cause

The Access Manager WebGate is not deployed or configured properly.

Solution

Confirm the httpd.conf file contains the following entry at the end:

"include "webgate.conf"

where webgate.conf contains the 12c WebGate configuration.

If this entry is not found, review the WebGate configuration steps to verify none were missed. For more information, see Configuring Oracle HTTP Server WebGate for Oracle Access Manager in Installing WebGates for Oracle Access Manager and Configuring Access Manager Settings in the Administering Oracle Access Management.

2.5.1.3 Access Manager Failure to Authenticate User

User login fails with the following error:

An incorrect Username or Password was specified.

Cause

Access Manager is responsible for user authentication but authentication has failed. The identity store configuration may be wrong.

Solution

Check that the identity store is configured correctly in the Oracle Access Management Console.

To resolve this problem:

Login to Oracle Access Management Console.
Navigate to Configuration >User Identity Stores > OAMIDStore.
Verify the Default Store and System Store configuration.
Click Test Connection to verify the connection.

2.5.1.4 Troubleshooting Oracle Access Management Console Login Operation Errors

User is not directed to the Oracle Access Management Console to login and the following error message appears:

Oracle Access Manager Operation Error.

Cause 1

The OAM Server is not running.

Solution 1

Start the OAM Server.

Cause 2

The WebGate is not correctly deployed on OHS and is not configured correctly for the 12c Agent located on the OAM Server.

An error message displays, for example: The AccessGate is unable to contact any Access Servers.

The issue may be with the SSO Agent.

See Understanding Credential Collection and Login in Administering Oracle Access Management.

Solution 2

To resolve this problem:

Run oamtest.jar (ORACLE_HOME/idm/oam/server/tester) and test the connection by specifying AgentID.
The AgentID can be found in ObAccessClient.xml, located in the webgate/config directory in the WEBSERVER_HOME. For example:
```
<SimpleList>
 
        <NameValPair
 
            ParamName="id"
 
            Value="IAMAG_11g"></NameValPair>
 
    </SimpleList>
```
If the Tester fails to connect, this confirms a problem exists with the SSO Agent configuration (password/host/port) on the OAM Server.
Re-create the 12c SSO Agent and then reconfigure the WebGate to use this Agent.

2.5.1.5 Troubleshooting Authenticated User Redirection to OIG Login

User authenticated using the Oracle Access Management Console but is redirected to the Oracle Identity Governance login page to enter credentials.

Cause 1

The security providers for the OIG domain are not configured correctly in Oracle WebLogic Server.

Solution 1

Verify the WebLogic security providers are configured correctly for the OIG domain security realm. Check the LDAP Authenticator setting. For more information, see Validating the Oracle Identity Governance Security Provider Configuration.

Cause 2

OAMIDAsserter is not configured correctly in Oracle WebLogic Server.

Solution 2

To resolve this problem:

Log in to the WebLogic Server Administration Console for the OIG domain.
Navigate to Security Realms, myrealm, and then Providers.
Click OAMIDAsserter.
Navigate to Common tab and verify Active Types contains the correct header for the WebGate type:

OAM_REMOTE_USER for WebGate 12c.

2.5.1.6 User Redirected to OIG During OIG Forgot Password, Register New Account, or Track User Registration Flows

Access Manager relies upon Oracle Identity Governance for password management. If the user logs in for the first time or if the user password is expired, Access Manager redirects the user to the Oracle Identity Governance First Login page.

From the Access Manager login screen, user should be able to navigate to the Oracle Identity Governance Forgot Password, the Self-Registration or Track Registration flows.

Cause

If there is any deviation or error thrown when performing these flows, the configuration in oam-config.xml (OAM_DOMAIN_HOME/config/fmwconfig) is incorrect.

Solution

Verify the contents of oam-config.xml resembles the following example. Specifically, that HOST and PORT corresponds to the OHS (or any supported web server) configured to front-end Oracle Identity Governance resources.

Setting Name="IdentityManagement" Type="htf:map">
<Setting Name="IdentityServiceConfiguration" Type="htf:map">
<Setting Name="IdentityServiceProvider" Type="xsd:string">oracle.security.am.engines.idm.provider.OracleIdentityServiceProvider</Setting>
<Setting Name="AnonymousAuthLevel" Type="xsd:integer">0</Setting>
<Setting Name="IdentityServiceEnabled" Type="xsd:boolean">true</Setting>
<Setting Name="IdentityServiceProviderConfiguration" Type="htf:map">
<Setting Name="AccountLockedURL" Type="xsd:string">/identity/faces/accountlocked</Setting>
<Setting Name="ChallengeSetupNotDoneURL" Type="xsd:string">/identity/faces/firstlogin</Setting>
<Setting Name="DateFormatPattern" Type="xsd:string">yyyy-MM-dd'T'HH:mm:ss'Z'</Setting>
<Setting Name="ForcedPasswordChangeURL" Type="xsd:string">/identity/faces/firstlogin</Setting>
<Setting Name="IdentityManagementServer" Type="xsd:string">OIM-SERVER-1</Setting>
<Setting Name="PasswordExpiredURL" Type="xsd:string">/identity/faces/firstlogin</Setting>
<Setting Name="LockoutAttempts" Type="xsd:integer">5</Setting>
<Setting Name="LockoutDurationSeconds" Type="xsd:long">31536000</Setting>
</Setting>
</Setting>
<Setting Name="RegistrationServiceConfiguration" Type="htf:map">
<Setting Name="RegistrationServiceProvider" Type="xsd:string">oracle.security.am.engines.idm.provider.DefaultRegistrationServiceProvider</Setting>
<Setting Name="RegistrationServiceEnabled" Type="xsd:boolean">true</Setting>
<Setting Name="RegistrationServiceProviderConfiguration" Type="htf:map">
<Setting Name="ForgotPasswordURL" Type="xsd:string">/identity/faces/forgotpassword</Setting>
<Setting Name="NewUserRegistrationURL" Type="xsd:string">/identity/faces/register</Setting>
<Setting Name="RegistrationManagementServer" Type="xsd:string">OIM-SERVER-1</Setting>
<Setting Name="TrackUserRegistrationURL" Type="xsd:string">/identity/faces/trackregistration</Setting>
</Setting>
</Setting>
<Setting Name="ServerConfiguration" Type="htf:map">
<Setting Name="OIM-SERVER-1" Type="htf:map">
<Setting Name="Host" Type="xsd:string">myhost1.example.com</Setting>
<Setting Name="Port" Type="xsd:integer">7777</Setting>
<Setting Name="SecureMode" Type="xsd:boolean">false</Setting>
</Setting>
</Setting>
</Setting>

2.5.1.7 User Redirection in a Loop

A new user attempts to access Oracle Identity Management Self-Service and after successful authentication, the user is redirected in a loop. The service page does not load and the browser continues spinning or refreshing.

Cause

OHS configuration setting for WLCookieName for front-ending identity is incorrect.

Solution

Check the OHS configuration for front-ending identity and verify that WLCookieName directive is set to oimjsessionid. If not, set this directive as oimjsessionid for each Oracle Identity Management resource Location entry. For example:

<Location /identity>
 
  SetHandler weblogic-handler
 
  WLCookieName oimjsessionid
 
  WebLogicHost myhost1.example.com
 
  WebLogicPort 8003
 
  WLLogFile "$
Unknown macro: {ORACLE_INSTANCE}
/diagnostics/logs/mod_wl/oim_component.log"
 
  </Location>

2.5.1.8 Troubleshooting SSO Integration Configuration

Cause

During Configuring SSO Integration execution, the script could fail due to OAM-related issues:

Solution

Verify if OAM server is up.
Ensure that the credentials used for this step are correct.
Check from the console log if it is Error 401--Unauthorized.
Restart OAM admin and managed servers.

Ensure that the sso-config.properties file reflects the following:

generateIndividualConfigFiles=false
prepareIDStore=false
configOAM=false
addMissingObjectClasses=false
populateOHSRules=false
configureWLSAuthnProviders=false
configureLDAPConnector=false
configureSSOIntegration=true
enableOAMSessionDeletion=false
updateContainerRules=false

Run the following REST API and ensure it responds with the OAM policy application domains.
```
http(s)://<oam-admin-server-host>:<oam-admin-server-port>
/oam/services/rest/11.1.2.0.0/ssa/policyadmin/appdomain
```
Note:
The REST API must be run by the user having System Administrator privileges.
To assign system administrator role to a user, perform the following steps:
1. Log in to the OAM console.
2. Click Configuration > Administration > Grant.
3. Search for the user to whom you are required to provide system administrator privileges. For example, weblogic_idm
4. Ensure the Role is set to System Administrator.
5. Click Add Selected.
6. Go to the configureSSOIntegration.config file and specify the user with system administrator privileges against the IDSTORE_OAMADMINUSER property. For example, IDSTORE_OAMADMINUSER =weblogic_idm
If the REST endpoint does not repond, or returns Request Failed error, perform the following steps:
1. Login to the OAM AdminServer WLS Console.
2. Navigate to Application Deployments.
3. Select oam-admin, click Update and then click Active.
4. Stop all OAM domain servers.
5. Delete the tmp and cache directories under admin, oam and policy manager server.
6. Start all the oam domain servers and run the REST command again.
Note:
Do not progress to the next step unless the specified REST API responds with the OAM policy application domains. Otherwise, the following script may return UnmarshalException.
Run OIGOAMIntegration.sh -configureSSOIntegration.

2.5.1.9 WADL Generation Does not Show Description

Issue

WADL generation fails and a java.lang.IllegalStateException: ServiceLocatorImpl is returned.

Exception thrown when provider 
class org.glassfish.jersey.server.internal.monitoring.MonitoringFeature$StatisticsListener 
was processing MonitoringStatistics. Removing provider from further processing.
java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_6,9,221656053) has been shut down 
at org.jvnet.hk2.internal.ServiceLocatorImpl.checkState(ServiceLocatorImpl.java:2393)

Also, when the WADL generation fails, the description field shows Root Resource, instead of a proper description in the following URLs.


http://<Host>:<AdminServerPort>/oam/services/rest/11.1.2.0.0/ssa/policyadmin/application.wadl
http://<Host>:<ManagedServerPort>/iam/access/api/v1/health/application.wadl

Resolution

Restart the Admin server and managed servers to resolve the wadl issue.

2.5.2 Troubleshooting Auto-Login Issues in an Access Manager and OIG Integrated Environment

The auto-login feature enables user login to Oracle Identity Governance after the successful completion of the Forgot Password or Forced Change Password flows, without prompting the user to authenticate using the new password.

Communication between Oracle Identity Governance and Access Manager can be configured to use Oracle Access Protocol (OAP) or TAP channels. Debugging auto-login issues is simplified if you determine which channel is being used. Determine the channel by examining the Oracle Identity Governance SSOIntegrationMXBean (version attribute) using the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control. For more information, see "Using the System MBean Browser" in Administering Oracle Fusion Middleware.

Depending upon the Access Manager version being used, the following applies:

If the version is 11g, the TAP channel is used during auto-login. See Troubleshooting Oracle Access Protocol (OAP) Issues.

After a password is reset in Oracle Identity Governance and in LDAP through LDAP synchronization, Oracle Identity Governance redirects the user to the Access Manager TAP endpoint URL (SSOIntegrationMXBean: TAPEndpointUrl). Access Manager will auto-login the user by redirecting to the requested resource.

Note:

In the 12c Oracle Identity Governance and Access Manager integrated environment, the TAP protocol is configured for auto-login by default.

2.5.2.1 Troubleshooting TAP Protocol Issues

Check the OIG Server and Access Manager Server logs for any of the following error messages:

404 Not Found Error. For possible solution, see 404 Not Found Error
System error. Please re-try your action. For possible solution, see System Error

2.5.2.1.1 404 Not Found Error

After resetting the password, user is redirected to a 404 Not Found error page.

Cause

The Access Manager TAP endpoint URL (SSOIntegrationMXBean: TAPEndpointUrl) is configured incorrectly.

Solution

Verify that TAPEndpointUrl is correctly configured in Oracle Identity Governance SSOIntegrationMXBean and is accessible. For example:

http://OAM_HOST:OAM_PORT/oam/server/dap/cred_submit

http://OHS_HOST:OHS_PORT/oam/server/dap/cred_submit

where Access Manager is front-ended by OHS.

2.5.2.1.2 System Error

After resetting the password, user is redirected to Access Manager TapEndpointUrl (configured in Oracle Identity Governance SSOIntegrationMXBean), and the following error displays in the UI:

System error. Please re-try your action. If you continue to get this error, please contact the Administrator.

Cause 1

A message similar to the following displays in the Access Manager Server logs:

Sep 19, 2012 4:29:45 PM EST> <Warning> <oracle.oam.engine.authn>
 
<BEA-000000> <DAP Token not received>
 
<Sep 19, 2012 4:29:45 PM EST> <Error> <oracle.oam.binding> <OAM-00002>
 
<Error occurred while handling the request.
 
java.lang.NullPointerException
 
at
 
oracle.security.am.engines.enginecontroller.token.DAPTokenEncIssuerImpl.issue(DAPTokenEncIssuerImpl.java:87)

Solution 1

This error could be due to mis-configuration in TAPResponseOnlyScheme in Access Manager. Verify oam-config.xml (located at OAM_DOMAIN_HOME/config/fmwconfig) contains the following entry:

<Setting Name="DAPModules" Type="htf:map">
 
     <Setting Name="7DASE52D" Type="htf:map">
 
         <Setting Name="MAPPERCLASS" Type="xsd:string">oracle.security.am.engine.authn.internal.executor.DAPAttributeMapper</Setting>
 
          <Setting Name="MatchLDAPAttribute" Type="xsd:string">uid</Setting>
 
          <Setting Name="name" Type="xsd:string">DAP</Setting>
 
     </Setting>
 
</Setting>

The value of MatchLDAPAttribute should be uid. If not, change the value.

To resolve the problem:

Login to Oracle Access Management Console.
Navigate to TapResponseOnlyScheme. Add the following as Challenge parameter:
```
MatchLDAPAttribute=uid
```
Save the changes.

Cause 2

The following error displays in the Access Manager Server logs:

 javax.crypto.BadPaddingException: Given final block not properly padded

This may occur if OIM_TAP_PARTNER_KEY is not include in the OIG credential map in the credential store, or if an invalid key is present.

Solution 2

Reregister Oracle Identity Governance as a TAP partner with Access Manager by rerunning the OIGOAMIntegration.sh -configureSSOIntegration option. and restart the complete OIG domain.

Cause 3

After resetting the password, if auto-login is not successful, the OIG server logs contain the following error:

 Error occured while retrieving TAP partner key from Credential store

Solution 3

To resolve the problem:

Using Fusion Middleware Control, verify the OIM_TAP_PARTNER_KEY generic credential is present in the OIG credential map in the credential store.
If OIM_TAP_PARTNER_KEY is present, verify that LDAP connector is configured correctly, and that the password is reset in LDAP provider. Check this by issuing an ldapbind command with the user and the new/reset password.

Cause 4

After resetting the password, if auto-login is not successful, the OAM server logs have the following error:

 Error occured while retrieving DAP token from OAM due to invalid TAP partner key

The OIM_TAP_PARTNER_KEY present in the OIG credential map of credential store is not valid.

Solution 4

Reregister Oracle Identity Management as a TAP partner with Access Manager by rerunning OIGOAMIntegration.sh -configureSSOIntegration option. You must restart the complete OIG domain.

Cause 5

After resetting the password, if auto-login is not successful, the OIG server logs may show the following error:

Error occurred when decrypting the DAP token

Solution 5

To resolve the problem, reset TAP encryption key:

Update the oam-config.xml file:

Set the following environment variables for Oracle Access Manager:
- ORACLE_HOME
- DOMAIN_HOME
- JAVA_HOME
- DB_ORACLE_HOME

Create the prop.properties file.

The following shows an example of the prop.properties file.

oam.entityStore.ConnectString=jdbc:oracle:thin:@dbhost.example.com:1521/servicename.example.com
oam.entityStore.schemaUser=MYPREFIX_OAM
oam.entityStore.schemaPassword=xxxxx
oam.importExportDirPath=/tmp
oam.frontending=params=oamhost.example.com;14100;http

Export oam-config.xml into temporary location (tmp) by running the following command:

java -cp config-utility.jar:ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand <path to which configuration must be exported> export <prop.properties>

Example:

$JAVA_HOME/bin/java -cp $ORACLE_HOME/idm/oam/server/tools/config-utility/config-utility.jar:$DB_ORACLE_HOME/jdbc/lib/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME export /tmp/prop.properties

Open the oam-config.xml file under temp folder in a text editor and update the OIMPartner attribute with OIMPartnerOld attribute.

Import oam-config.xml, into the database by running the following command:

java -cp config-utility.jar:ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand <path to which configuration must be exported> import <prop.properties>

Example:

$JAVA_HOME/bin/java -cp $ORACLE_HOME/idm/oam/server/tools/config-utility/config-utility.jar:$DB_ORACLE_HOME/jdbc/lib/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME import /tmp/prop.properties

Delete OIM_TAP_PARTNER_KEY from the OIG domain using the Oracle Enterprise Manager Fusion Middleware Control.
Reregister Oracle Identity Governance as a TAP partner with Access Manager by rerunning the OIGOAMIntegration.sh -configureSSOIntegration option.
Verify that OIM_TAP_PARTNER_KEY is available in the domain credential store. See Validating the Oracle Identity Governance Domain Credential Store.
Restart OIG and OAM domain.

2.5.2.2 Troubleshooting Oracle Access Protocol (OAP) Issues

Check the OIG Server logs for any of the following types of error messages.

The resource URL is not protected.

Corrective action:

Verify that the correct host:port combination is configured in the Access Manager host identifier configuration.

http://oam_adminserver_host:oam_adminserver_port/oamconsole

In the Oracle Access Management Console, click Application Security at the top of the window.
Click Host Identifiers in the Access Manager section.
The Search Host Identifiers page is displayed.
Click Search to initiate the search.
Click IAMSuiteAgent in the Search Results table.
Check the host identifiers for host:port combination in the identifier.
IAMSuiteAgent Host Identifier should have a combination of OHS (webserver) host:port which is front-ending Oracle Identity Management.

aaaClient is not initialized.

Corrective action:

Verify that the passwords seeded into OIG domain credential store are correct. For OPEN mode, check for the WebGate password. For SIMPLE mode, check that SSO keystore password and SSO global passphrase are seeded in correctly. For more information, see Validating the Oracle Identity Governance Domain Credential Store.

Failed to communicate with any of configured OAM Server.

Corrective action:

Verify that it is up and running.
Verify that the passwords seeded into OIG domain credential store are correct.
For OPEN mode, check for the WebGate password.
For SIMPLE mode, check that SSO keystore password and SSO global passphrase also are seeded in correctly.

See Validating the Oracle Identity Governance Domain Credential Store.

SSOKeystore tampered or password is incorrect.

Corrective action:

Check that the keystore file ssoKeystore.jks is present in OIM_DOMAIN_HOME/config/fmwconfig.
If present, then check if the keystore password is seeded properly into OIG domain credential store.

See Validating the Oracle Identity Governance Domain Credential Store.

Oracle Identity Management logs do not have any information about the failure.

Corrective action:

Enable HTTP headers and capture the headers while running through the First Login, Forgot Password flows. See Diagnosing Single Sign-On Issues By Capturing HTTP Headers.
In the HTTP headers, look for Set-Cookie: ObSSOCookie after the POST method on the First Login, Forgot Password page. Check the domain of the cookie. It should match with the domain for the protected resource URL.
If cookie domain is different, update the CookieDomain in the Oracle Identity Management SSO configuration using Fusion Middleware Control. See Validating the Oracle Identity Governance SSO Configuration Settings.
If cookie domain is correct, then check for any time differences on the machines which host the OIG and OAM Servers.

2.5.3 Troubleshooting Session Termination Issues

The session termination feature enables the termination of all active user sessions after the user status is modified by an Oracle Identity Management administrator. The following Oracle Identity Management operations lead to session termination: user lock, disable or delete.

To troubleshoot session termination issues:

Verify the OAM REST URL, http://<OAM_HOST>:<OAM_PORT>/oam/services/rest/access/api/v1/session?userId=<uid>is accessible.
Here, OAM_HOST refers to SSOIntegrationMXBean: AccessServerHost and OAM_PORT refers to SSOIntegrationMXBean: OAMServerPort
Verify if OAM Admin has authorization to invoke OAM REST API (SSOIntegrationMXBean: OAMAdminUser).
Verify in oam-config.xml in OAM domain that UserStore in SessionRuntime points to IDStore created during integration.
Verify /db/sssointg/EventHandlers.xml is in Oracle Identity Governance MDS. See Validating the Oracle Identity Governance Event Handlers Configured for SSO.

2.5.4 Troubleshooting Account Self-Locking Issues

Use Case 1

Both LDAP store and Access Manager lock out the user due to multiple failed login attempts. The user attempts to reset his or her password using the Oracle Identity Governance (OIG) "Forgot Password" page, but the reset operation fails.

Possible explanation: the user's locked status has not yet propagated to Oracle Identity Governance.

Check if the user is locked in Oracle Identity Governance:
1. Log in to the Identity Self Service application as an Oracle Identity Governance administrator.
2. Navigate to the Users section, then search for the user.
3. Check if the Identity status is locked.
If the status is not locked, run a SSO User Incremental Reconciliation scheduled job, and then confirm that the user status is locked.

Use Case 2

The user account self-locks due to multiple invalid credentials login attempts. Later, when the user attempts to log in with the correct credentials, he or she is not able to log in. The user expects to log in first and then change the password, but login fails consistently.

Possible explanation: both LDAP directory and Access Manager may have locked the user account. In this case the user cannot log in to Oracle Identity Governance or to any protected page. The user has to use the Forgot Password flow to reset the password.

Note that if only Access Manager locks out the user, the user can log in to Oracle Identity Governance and change the password immediately.

Use Case 3

The LDAP directory pwdMaxFailure count of three is less than the oblogintrycount value of five. The LDAP directory locks out the user due to multiple invalid credentials login attempts (in this case, three attempts). Later, when the user tries to log in with the correct credentials, on the fourth attempt the user still cannot log in. The user expects to log in first and then change the password, but login fails consistently.

Possible explanation: LDAP directory locked out the user, but Access Manager did not. The user cannot log in with the correct password even though the oblogintrycount is less than five, but following the Forgot Password flow works and resets the password.

Note that when LDAP directory locks out the user there is nothing to reconcile into OIG, because OIG does not reconcile user accounts that are locked in LDAP store. When LDAP store locks the user, OIG shows the user as active. Following the Forgot Password flow is the only way to reset the password.

Use Case 4

The LDAP directory pwdMaxFailure count value of seven is less than the oblogintrycount value of five. Access Manager locked out the user due to multiple invalid credentials login attempts. Later, when the user tries to login with the correct credentials, the user is able to log in and is redirected to change the password, but the reset password operation fails.

Possible explanation: the user locked status has not yet propagated to OIG.

Check if the user is locked in OIG:
1. Login to Identity Self Service application as an OIG administrator.
2. Navigate to Users section, then search for the user.
3. Check if the Identity status is locked.
If the status is not locked, run a SSO User Incremental Reconciliation scheduled job, and then confirm that the user status is locked.

Note that use case one and this use case look similar. In use case one, both LDAP directory and Access Manager locked the user account, whereas in this use case only Access Manager locks the user. The remedy for both use cases is the same, however.

Use Case 5

The user cannot remember his or her password and tries to reset the password using the Forgot Password flow. The user provides his or her user login, provides a new password, and provides incorrect challenge answers. After three failure attempts, both LDAP directory and Access Manager lock the user. The user expects to get locked out after five attempts instead of three attempts because the oblogintrycount value is 5.

Possible explanation: the password reset attempts in the OIG Reset/Forgot Password flow are governed by the OIG system property XL.MaxPasswordResetAttempts and the default value is 3. Consequently, the user is locked out immediately after three attempts. OIG locks the user natively in LDAP directory and in Access Manager.

Note that password reset attempts are different from login attempts. Login attempts are governed by Access Manager (oblogintrycount=5) and password reset attempts by OIG (XL.MaxPasswordResetAttempts=3).

Use Case 6

LDAP directory locks the user because some constant LDAP binding used incorrect credentials. Access Manager does not lock out the user. When the user tries to log in with the correct credentials, he is not able to log in.

Possible explanation: LDAP directory locks the user out in this use case, not Access Manager. The user cannot log in with the correct password even if the oblogintrycount is still less than 5, but the user can reset his or her password by following the Forgot Password flow.

Note that when a user is only locked out by LDAP directory, the user's lock-out status is not reconciled into OIG. Consequently, the user shows up as still active in OIG even though the user is locked in LDAP directory.

Use Case 7

When the user resets his password, the password reset is not immediate.

The user account self-locks due to multiple invalid credentials login attempts.
The user uses the Forgot Password flow to reset the password.
The user account is still locked, and he is not able to login to Oracle Identity Governance.

Possible explanation: the user's locked status has not yet propagated to OIG.

Check if the user is locked in OIG:
1. Login to Identity Self service application as an OIG administrator.
2. Navigate to the Users section, and then search for the user.
3. Check if the Identity status is locked.
If the status is not locked, run an SSO User Incremental Reconciliation scheduled job, and then confirm that the user status is locked.

2.5.5 Troubleshooting Miscellaneous Issues in an Access Manager and OIG Integrated Environment

This provides solutions for the following miscellaneous issues:

2.5.5.1 Client Based Oracle Identity Governance Login Failure

For successful client-based login to Oracle Identity Governance:

The client-based login user must be present in the LDAP provider.
An LDAP Authenticator must be configured in the OIG domain security realm corresponding to the LDAP provider where the user is present. See Validating the Oracle Identity Governance Security Provider Configuration.

2.5.5.2 Logout 404 Error Occurs After Logging Out of OIG protected Application

If logging out of an Oracle Identity Governance protected application throws a 404 error, verify that the logout configuration is present in jps-config.xml. See Validating the Oracle Identity Governance SSO Logout Configuration.

If needed, the JPS configuration can be fixed by editing the jps-configuration file located in $DOMAIN_HOME/config/fmwconfig and then restarting all the servers.

To resolve a misconfiguration in jps-config.xml:

In a terminal window issue the following commands: cd $$ORACLE_HOME <OIG_INSTALL_LOCATION>/oracle_common/common/bin
./wlst.sh
connect()
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
exit
Restart all servers in the domain.

See Starting and Stopping Admin Server in Administering Oracle Fusion Middleware

2.5.5.3 Old Password Remains Active After Password Reset

In Active Directory environments, old passwords can remain active for up to one hour after a password reset. During this interval, both the old and new password can successfully bind to the Active Directory server. This is the expected behavior.

2.5.5.4 OIG Configuration Failure During Seeding of OIG Policies into Access Manager

As part of running OIGOAMIntegration.sh -configureSSOIntegration, Oracle Identity Governance policies are seeded into Access Manager using the Access Management exposed REST endpoint.

An exception while seeding Oracle Identity Governance policies occurs when the user credentials used for accessing Access Manager exposed endpoint does not have enough privileges to perform the operation.

The solution is as follows:

Make sure IDSTORE_WLSADMINUSER is the same user which was used while running the prepareIdStore mode=wls command.
Try to access the Access Manager REST endpoint using curl command:
```
curl -u weblogic_idm:password "http://OAM_ADMIN_HOST:OAM_ADMIN_PORT/oam/services/rest/11.1.2.0.0/ssa/policyadmin/appdomain"
```
Where:
- weblogic_idm is the user as mentioned for IDSTORE_WLSADMINUSER and password is the password for the user.
If this command fails to return the list of application domains present in Access Manager, then make sure configOAM is run properly and the Access Manager admin server is restarted before running OIGOAMIntegration.sh -configureSSOIntegration.

2.5.5.5 Adding Object Classes Fails

When you run the OIGOAMIntegration.sh -addMissingObjectClasses to add the object class. It fails with the following error:

ldap_bind: Invalid credentials (49)

Cause

This error occurs when you provide additional space for the IDSTORE_BINDDN property in the addMissingObjectClasses.config file.

Example

IDSTORE_BINDDN:cn=Directory Manager

Solution

Ensure that you provide the double quotation marks (") at the beginning and end for the IDSTORE_BINDDN property.
Example
IDSTORE_BINDDN:cn="Directory Manager"

Replace the following lines from the addMissingObjectClasses function in the _OIGOAMIntegration.sh script:

COMMAND="ldapsearch -h $IDSTORE_HOST -p $IDSTORE_PORT -D $IDSTORE_BINDDN -w $IDSTORE_BINDDN_PWD -b $IDSTORE_USERSEARCHBASE -s sub $FILTER dn"
echo "Executing ldapsearch..."
echo $COMMAND
$COMMAND | grep "dn:" > ${ALL_USERS}

With the following lines:

LDAP_COMMAND="ldapsearch -h $IDSTORE_HOST -p $IDSTORE_PORT -D "$IDSTORE_BINDDN" -w $IDSTORE_BINDDN_PWD -b $IDSTORE_USERSEARCHBASE -s sub $FILTER dn"
COMMAND=$(ldapsearch -h $IDSTORE_HOST -p $IDSTORE_PORT -D "$IDSTORE_BINDDN" -w $IDSTORE_BINDDN_PWD -b $IDSTORE_USERSEARCHBASE -s sub $FILTER dn)
echo "Executing ldapsearch..."
echo $LDAP_COMMAND
echo $COMMAND | grep "dn:" > ${ALL_USERS}

2.5.6 Troubleshooting Target Account Creation

The target account creation may fail due to some known reasons. This section helps you troubleshoot and solve some known issues while creating a target account and resetting password in OUD.

Container rules are not configured in SSOIntegrationMXBean

Corrective action:

Execute addContainerRules operation manually against SSOIntegrationMXBean.
Or update the appropriate configuration file and run one of the following scripts:
- $ORACLE_HOME/idm/server/ssointg/bin/OIGOAMIntegration.sh -configureLDAPConnector
- $ORACLE_HOME/idm/server/ssointg/bin/OIGOAMIntegration.sh -updateContainerRules

Application Instance is not created

Corrective action:

Create the Application Instance manually. For more information, see Creating Target Application Instance.

Or update the appropriate configuration file and run the following script:

$ORACLE_HOME/idm/server/ssointg/bin/OIGOAMIntegration.sh -configureLDAPConnector

LDAP server is not running

Corrective action: Start the LDAP server

Directory is not seeded

Corrective action:

Update the appropriate configuration file and run the following script:

$ORACLE_HOME/idm/server/ssointg/bin/OIGOAMIntegration.sh -prepareIDStore

mds-oim connection pool is unable to allocate another connection

Corrective action:

From the WebLogic console, navigate to Services>Data Sources>mds-oim>Connection Pool.
On the Connection Pool page, increase the values of Initial Capacity, Minimum Capacity, and Maximum Capacity.
Click Save.
On the Connection Pool page, select Advanced link available at the bottom of the page.
On the Advanced page, set the value of Inactive Connection Timeout to a non-zero value, for example 10.
Click Save

Resetting password in OUD

When the System Administrator manually locks a user in OIG, the attributes obLockedOn and pwdAccountLockedTime are set for the user in OUD. If the System Administrator resets the user's password, pwdAccoundLockedTime is cleared in the OUD. This is a default behavior in OUD.

When the pwdAccoundLockedTime attribute is cleared, the user status gets updated to unlocked after user reconciliation in OIG. However, obLockedOn is still set in OUD and OAM treats this user as locked.

Corrective action:

It is recommended to lock (or unlock) the user from OIG. This scenario is applicable only to reset password for a manually locked-user. It does not apply to change password for self-locked user where user is locked due to failed password attempts.

2.5.7 Troubleshooting prepareIDStore for AD

Error

Schema in ADUserSchema.ldif fails to load.

This error appears when running the following script step.

oracle.ldap.util.LDIFLoader loadOneLdifFile INFO: Ignoring Error: javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - 00002082: AtrErr: DSID-03151817, #1: 0: 00002082: DSID-03151817, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att90094 (schemaIDGUID):len 26 ]; remaining name 'cn=oblocationdn,cn=schema,cn=configuration,DC=interop55,DC=us,DC=oracle,DC=com'

Solution

Edit ADUserSchema.ldif and replace %IDSTORE_SEARCHBASE% with DC=interop55,DC=my,DC=org,DC=com

Run the LDAP command to load them into AD

ldapmodify -h 192.0.2.1 -p 389 -D Administrator@interop -w <password> -f
ADUserSchema.ldif -c -x

Problem

In AD environment, the object classes such as oblixgroup are not loaded after -prepareIDStore step is run.

Solution

Navigate to $ORACLE_HOME/idm/server/ldif/prepareidstore/AD/schema
Edit ADUserSchema.ldif and replace %IDSTORE_SEARCHBASE% with the location in the directory where users and groups are stored. For example, dc=example,dc=com
.

Run the LDAP command

ldapmodify -h <activedirectoryhostname> -p <activedirectoryportnumber> -D 
<AD_administrator> -f ADUserSchema.ldif -w <password> -c -x

where AD_administrator is the user with schema extension privileges to the directory.

Example:

ldapmodify -h activedirectoryhost.example.com -p 389 -D adminuser -f 
ADUserSchema.ldif -w password -c -x

2.5.8 Troubleshooting the OIG-OAM Integrated Environment Upgrade

After upgrading from an 11.1.2.3.0 environment to 12.2.1.4.0, when you perform the First Login flow, or Forgot Password Flow, or Reset Password Flow then auto-login fails and system error message appears. When you initiate above flows, new password and challenge questions are set correctly irrespective of the system error.

To resolve this issue, you must re-login with the newly set password.

2.6 Scheduled Jobs for OIG-OAM Integration

OIG offers two sets of scheduled jobs for synchronizing with LDAP: Reconciliation Jobs and SSO Post Enable Jobs.

Reconciliation Jobs

The following reconciliation jobs are provided:

SSO User Full Reconciliation
SSO User Incremental Reconciliation
SSO Group Create and Update Full Reconciliation
SSO Group Create and Update Incremental Reconiliation
SSO Group Delete Full Reconciliation
SSO Group Delete Incremental Reconciliation
SSO Group Membership Full Reconciliation
SSO Group Membership Incremental Reconciliation
SSO Group Hierarchy Sync Full Reconciliation
SSO Group Hierarchy Sync Incremental Reconciliation

Note:
SSO Group Hierarchy Sync Incremental Reconciliation is supported only for Oracle Internet Directory and Oracle Unified Directory.

Parameter Values for Reconciliation Jobs

Table 2-12 Parameter values for reconciliation jobs

Reconciliation job	Parameter Name	Parameter Value	Description
SSO User Full Reconciliation	Resource Object Name	SSOTarget	Name of the target resource object against which reconciliation runs must be performed. This corresponds to the target account which has to be reconciled for the user. This value is equal to the target application instance name.
SSO User Full Reconciliation	IT Resource Name	SSOTarget	Name of the target IT resource instance that the connector must use to reconcile data.This corresponds to the target account which has to be reconciled for the user. This value is equal to the target application instance name.
SSO User Full Reconciliation	Object Type	User	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO User Full Reconciliation	Trusted Resource Object Name	SSOTrusted-for-SSOTarget	Name of the trusted resource object against which reconciliation runs must be performed. This corresponds to the target account which has to be reconciled for the user. This value is equal to the trusted application instance name (auto-generated by OIGOAMIntegrationScript.sh).
SSO User Full Reconciliation	Trusted IT Resource Name	SSOTrusted-for-SSOTarget	Name of the trusted IT resource instance that the connector must use to reconcile data.This corresponds to the target account which has to be reconciled for the user. This value is equal to the trusted application instance name (auto-generated by OIGOAMIntegrationScript.sh).
SSO User Full Reconciliation	Scheduled Task Name	SSO User Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO User Full Reconciliation	Incremental Recon Attribute	NA	This attribute should be left empty for SSO User Full Reconciliation job
SSO User Full Reconciliation	Latest Token	NA	This attribute should be left empty for SSO User Full Reconciliation job
SSO User Full Reconciliation	Sync Token	NA	This attribute should be left empty for SSO User Full Reconciliation job
SSO User Full Reconciliation	Filter	NA	Expression for filtering records that must be reconciled by the scheduled job. Sample value: startsWith('cn','Samrole1') Default value: None See Section 7.8 ICF Filter Syntax in Integrating ICF with Oracle Identity Governance documentation for the syntax of this expression.
SSO User Incremental Reconciliation	Resource Object Name	SSOTarget	Name of the target resource object against which reconciliation runs must be performed. This corresponds to the target account which has to be reconciled for the user. This value is equal to the target application instance name.
SSO User Incremental Reconciliation	IT Resource Name	SSOTarget	Name of the target IT resource instance that the connector must use to reconcile data.This corresponds to the target account which has to be reconciled for the user. This value is equal to the target application instance name.
SSO User Incremental Reconciliation	Object Type	User	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO User Incremental Reconciliation	Trusted Resource Object Name	SSOTrusted-for-SSOTarget	Name of the trusted resource object against which reconciliation runs must be performed. This corresponds to the target account which has to be reconciled for the user. This value is equal to the trusted application instance name (auto-generated by OIGOAMIntegrationScript.sh).
SSO User Incremental Reconciliation	Trusted IT Resource Name	SSOTrusted-for-SSOTarget	Name of the trusted IT resource instance that the connector must use to reconcile data.This corresponds to the target account which has to be reconciled for the user. This value is equal to the trusted application instance name (auto-generated by OIGOAMIntegrationScript.sh).
SSO User Incremental Reconciliation	Scheduled Task Name	SSO User Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO User Incremental Reconciliation	Incremental Recon Attribute		Name of the target system attribute that holds the change number at which the last reconciliation run started. The value in this attribute is used during incremental reconciliation to determine the newest or latest record reconciled from the target system. This value is fixed.
SSO User Incremental Reconciliation	Latest Token		This attribute holds the value of the uSNChanged attribute of a domain controller that is used for reconciliation. Note: The reconciliation engine automatically enters a value for this attribute. It is recommended that you do not change the value of this attribute. If you manually specify a value for this attribute, then only group whose uSNChanged value is greater than the Latest Token attribute value are reconciled. Default value: None
SSO User Incremental Reconciliation	Sync Token		This job parameter is only present if the target directory is Oracle Internet Directory or Oracle Unified Directory. You can manually enter the first Sync Token. To retrieve this token, query cn=changelog on rootDSE on the target system. Then, every time sync reconciliation is run, Sync Token is updated. Browse the changelog attribute of the target system to determine a value from the changelog that must be used to resume a reconciliation run. From the next reconciliation run onward, only data about records that are created or modified since the last reconciliation run ended are fetched into Oracle Identity Governance. Or, you can also leave this field blank, which causes the entire changelog to be read. This attribute stores values in one of the following formats: If you are using a target system for which the value of the standardChangelog entry in the Configuration lookup definition is set to true, then this attribute stores values in the following format: <Integer>VALUE</Integer> Sample value: <Integer>476</Integer> If you are using a target system (for example, OUD) for which the value of the standardChangelog entry in the Configuration lookup definition is set to false, then this attribute stores values in the following format: <String>VALUE</String> Sample value: <String>dc=example,dc=com:0000013633e514427b6600000013;</String> Default value: None
SSO User Incremental Reconciliation	Filter		Default value: None Expression for filtering records that must be reconciled by the scheduled job. Sample value: startsWith('cn','Samrole1') Default value: None See Section 7.8 ICF Filter Syntax in Integrating ICF with Oracle Identity Governance documentation for the syntax of this expression.
SSO Group Create and Update Full Reconciliation	Resource Object Name	SSO Group	Name of the resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Create and Update Full Reconciliation	Object Type	Group	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Create and Update Full Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This value is fixed.
SSO Group Create and Update Full Reconciliation	Scheduled Task Name	SSO Group Create And Update Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Create and Update Full Reconciliation	Filter		Expression for filtering records that must be reconciled by the scheduled job. Sample value: startsWith('cn','Samrole1') Default value: None See Section 7.8 ICF Filter Syntax in Integrating ICF with Oracle Identity Governance documentation for the syntax of this expression.
SSO Group Create and Update Full Reconciliation	Organization Name	Top	This job parameter is only present if the target directory is Active Directory. OIG Organization to which the reconciled role should be provisioned. This value is fixed.
SSO Group Create and Update Full Reconciliation	Organization Type	Company	This job parameter is only present if the target directory is Active Directory. Type of therganization to which the reconciled role is being provisioned. This attribute is used only with in connector reconciliation scope and does not have significance in OIG. This value is fixed.
SSO Group Create and Update Incremental Reconciliation	Resource Object Name	SSO Group	Name of the resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Create and Update Incremental Reconciliation	Object Type	Group	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Create and Update Incremental Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This value is fixed.
SSO Group Create and Update Incremental Reconciliation	Scheduled Task Name	SSO Group Create And Update Incremental Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Create and Update Incremental Reconciliation	Filter		Expression for filtering records that must be reconciled by the scheduled job. Sample value: startsWith('cn','Samrole1') Default value: None See Section 7.8 ICF Filter Syntax in Integrating ICF with Oracle Identity Governance documentation for the syntax of this expression.
SSO Group Create and Update Incremental Reconciliation	Sync Token		This job parameter is only present if the target directory is Oracle Internet Directory or Oracle Unified Directory. You can manually enter the first Sync Token. To retrieve this token, query cn=changelog on rootDSE on the target system. Then, every time sync reconciliation is run, Sync Token is updated. Browse the changelog attribute of the target system to determine a value from the changelog that must be used to resume a reconciliation run. From the next reconciliation run onward, only data about records that are created or modified since the last reconciliation run ended are fetched into Oracle Identity Governance. Or, you can also leave this field blank, which causes the entire changelog to be read. This attribute stores values in one of the following formats: If you are using a target system for which the value of the standardChangelog entry in the Configuration lookup definition is set to true, then this attribute stores values in the following format: <Integer>VALUE</Integer> Sample value: <Integer>476</Integer> If you are using a target system (for example, OUD) for which the value of the standardChangelog entry in the Configuration lookup definition is set to false, then this attribute stores values in the following format: <String>VALUE</String> Sample value: <String>dc=example,dc=com:0000013633e514427b6600000013;</String> Default value: None
SSO Group Create and Update Incremental Reconciliation	Incremental Recon Attribute	uSNChanged	This job parameter is only present if the target directory is Active Directory. Name of the target system attribute that holds the change number at which the last reconciliation run started. The value in this attribute is used during incremental reconciliation to determine the newest or latest record reconciled from the target system. This value is fixed.
SSO Group Create and Update Incremental Reconciliation	Latest Token		This attribute holds the value of the uSNChanged attribute of a domain controller that is used for reconciliation. Note: The reconciliation engine automatically enters a value for this attribute. It is recommended that you do not change the value of this attribute. If you manually specify a value for this attribute, then only group whose uSNChanged value is greater than the Latest Token attribute value are reconciled. Default value: None
SSO Group Create and Update Incremental Reconciliation	Organization Name	Top	This job parameter is only present if the target directory is Active Directory. OIG Organization to which the reconciled role should be provisioned. This value is fixed.
SSO Group Create and Update Incremental Reconciliation	Organization Type	Company	This job parameter is only present if the target directory is Active Directory. Type of therganization to which the reconciled role is being provisioned. This attribute is used only with in connector reconciliation scope and does not have significance in OIG. This value is fixed.
SSO Group Delete Full Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This value is fixed.
SSO Group Delete Full Reconciliation	Object Type	Group	This parameter holds the type of object you want to reconcile. This value is fixed.
SSO Group Delete Full Reconciliation	Resource Object Name	SSO Group	Name of the group resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Delete Full Reconciliation	Scheduled Task Name	SSO Group Delete Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Delete Full Reconciliation	Delete Recon	yes	This parameter is present only in SSO Group Delete Reconciliation for Active Directory. This value is fixed.
SSO Group Delete Full Reconciliation	Organization Name		This parameter is present only in SSO Group Delete Reconciliation for Active Directory. This value can be left empty.
SSO Group Delete Incremental Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This value is fixed.
SSO Group Delete Incremental Reconciliation	Object Type	Group	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Delete Incremental Reconciliation	Resource Object Name	SSO Group	Name of the group resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Delete Incremental Reconciliation	Scheduled Task Name	SSO Group Delete Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Delete Incremental Reconciliation	Sync Token		This job parameter is only present if the target directory is Oracle Internet Directory or Oracle Unified Directory. You can manually enter the first Sync Token. To retrieve this token, query cn=changelog on rootDSE on the target system. Then, every time sync reconciliation is run, Sync Token is updated. Browse the changelog attribute of the target system to determine a value from the changelog that must be used to resume a reconciliation run. From the next reconciliation run onward, only data about records that are created or modified since the last reconciliation run ended are fetched into Oracle Identity Governance. Or, you can also leave this field blank, which causes the entire changelog to be read. This attribute stores values in one of the following formats: If you are using a target system for which the value of the standardChangelog entry in the Configuration lookup definition is set to true, then this attribute stores values in the following format: <Integer>VALUE</Integer> Sample value: <Integer>476</Integer> If you are using a target system (for example, OUD) for which the value of the standardChangelog entry in the Configuration lookup definition is set to false, then this attribute stores values in the following format: <String>VALUE</String> Sample value: <String>dc=example,dc=com:0000013633e514427b6600000013;</String> Default value: None
SSO Group Delete Incremental Reconciliation	Delete Recon	yes	This parameter is present only in SSO Group Delete Reconciliation for Active Directory. This value is fixed.
SSO Group Delete Incremental Reconciliation	Organization Name		This parameter is present only in SSO Group Delete Reconciliation for Active Directory. This value can be empty.
SSO Group Membership Full Reconciliation	Application Name	SSOTarget	Name of the target application name from which you reconcile records
SSO Group Membership Full Reconciliation	Object Type	User	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Membership Full Reconciliation	IT Resource Name	SSOTarget	Name of the IT resource user by target application instance from which you reconcile records.
SSO Group Membership Full Reconciliation	Scheduled Task Name	SSO Group Membership Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Membership Full Reconciliation	Filter	<Empty>	Expression for filtering records that must be reconciled by the scheduled job. Sample value: startsWith('cn','Samrole1') Default value: None See Section 7.8 ICF Filter Syntax in Integrating ICF with Oracle Identity Governance documentation for the syntax of this expression.
SSO Group Membership Incremental Reconciliation	Application Name	SSOTarget	Name of the target application name from which you reconcile records
SSO Group Membership Incremental Reconciliation	Resource Object Name	SSO Group	Name of the group resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Membership Incremental Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This value is fixed.
SSO Group Membership Incremental Reconciliation	User IT Resource Name	SSOTarget	Name of the IT resource used by target application instance installation from which you reconcile records. This would be same as target application instance
SSO Group Membership Incremental Reconciliation	User Resource Object Name	SSOTarget	Resource Object name corresponding to target application instance. This would be same as target application instance
SSO Group Membership Incremental Reconciliation	Scheduled Task Name	SSO Group Membership Incremental Reconciliation	Fixed for this job. Not changeable
SSO Group Membership Incremental Reconciliation	Object Type	Group	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Membership Incremental Reconciliation	Sync Token		This job parameter is only present if the target directory is Oracle Internet Directory or Oracle Unified Directory. You can manually enter the first Sync Token. To retrieve this token, query cn=changelog on rootDSE on the target system. Then, every time sync reconciliation is run, Sync Token is updated. Browse the changelog attribute of the target system to determine a value from the changelog that must be used to resume a reconciliation run. From the next reconciliation run onward, only data about records that are created or modified since the last reconciliation run ended are fetched into Oracle Identity Governance. Or, you can also leave this field blank, which causes the entire changelog to be read. This attribute stores values in one of the following formats: If you are using a target system for which the value of the standardChangelog entry in the Configuration lookup definition is set to true, then this attribute stores values in the following format: <Integer>VALUE</Integer> Sample value: <Integer>476</Integer> If you are using a target system (for example, OUD) for which the value of the standardChangelog entry in the Configuration lookup definition is set to false, then this attribute stores values in the following format: <String>VALUE</String> Sample value: <String>dc=example,dc=com:0000013633e514427b6600000013;</String> Default value: None
SSO Group Membership Incremental Reconciliation	Incremental Recon Attribute	uSNChanged	This job parameter is only present if the target directory is Active Directory. Name of the target system attribute that holds the change number at which the last reconciliation run started. The value in this attribute is used during incremental reconciliation to determine the newest or latest record reconciled from the target system. This value is fixed.
SSO Group Membership Incremental Reconciliation	Latest Token		This attribute holds the value of the uSNChanged attribute of a domain controller that is used for reconciliation. Note: The reconciliation engine automatically enters a value for this attribute. It is recommended that you do not change the value of this attribute. If you manually specify a value for this attribute, then only group whose uSNChanged value is greater than the Latest Token attribute value are reconciled. Default value: None
SSO Group Membership Incremental Reconciliation	Filter		Expression for filtering records that must be reconciled by the scheduled job. Sample value: startsWith('cn','Samrole1') Default value: None See Section 7.8 ICF Filter Syntax in Integrating ICF with Oracle Identity Governance documentation for the syntax of this expression.
SSO Group Hierarchy Full Reconciliation	Resource Object Name	SSO Group	Name of the resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Hierarchy Full Reconciliation	Object Type	Group	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Hierarchy Full Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Hierarchy Full Reconciliation	Scheduled Task Name	SSO Group Hierarchy Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Hierarchy Full Reconciliation	Sync Token		This value should always be empty for SSO Group Hierarchy Full Reconciliation
SSO Group Hierarchy Incremental Reconciliation	Resource Object Name	SSO Group	Name of the resource object against which reconciliation runs must be performed This value is fixed.
SSO Group Hierarchy Incremental Reconciliation	Object Type	Group	This attribute holds the type of object you want to reconcile. This value is fixed.
SSO Group Hierarchy Incremental Reconciliation	IT Resource Name	SSO Server	Name of the IT resource instance that the connector must use to reconcile data. This value is fixed.
SSO Group Hierarchy Incremental Reconciliation	Scheduled Task Name	SSO Group Hierarchy Full Reconciliation	This attribute holds the name of the scheduled job. This value is fixed.
SSO Group Hierarchy Incremental Reconciliation	Sync Token		This job parameter is only present if the target directory is Oracle Internet Directory or Oracle Unified Directory. You can manually enter the first Sync Token. To retrieve this token, query cn=changelog on rootDSE on the target system. Then, every time sync reconciliation is run, Sync Token is updated. Browse the changelog attribute of the target system to determine a value from the changelog that must be used to resume a reconciliation run. From the next reconciliation run onward, only data about records that are created or modified since the last reconciliation run ended are fetched into Oracle Identity Governance. Or, you can also leave this field blank, which causes the entire changelog to be read. This attribute stores values in one of the following formats: If you are using a target system for which the value of the standardChangelog entry in the Configuration lookup definition is set to true, then this attribute stores values in the following format: <Integer>VALUE</Integer> Sample value: <Integer>476</Integer> If you are using a target system (for example, OUD) for which the value of the standardChangelog entry in the Configuration lookup definition is set to false, then this attribute stores values in the following format: <String>VALUE</String> Sample value: <String>dc=example,dc=com:0000013633e514427b6600000013;</String> Default value: None

SSO Post Enable Jobs

OIG offers post enable jobs to seed identities and their relation from OIG to LDAP.

The post enable jobs are to be used in case of following deployment scenario: OIG is already been in deployment for certain period of time and OIG is now being integrated with OAM and LDAP. During such scenarios, the existing users and roles and their relations in OIG needs to seeded to synchronize LDAP with data in OIG. After OIG-OAM integration configuration has been performed, these jobs should be run once to seed the users, roles and their relationships to LDAP.

The following post enable jobs are offered:

SSO Post Enable Provision Users to LDAP:
For each user in OIG, this job creates an user in LDAP and provisions SSO target application instance to the user.
SSO Post Enable Provision Roles to LDAP:
For each role in OIG, this job creates a role in LDAP and subsequently creates a lookup, entitlement and catalog entry for the entitlement.
SSO Post Enable Provision Role Membership to LDAP:
For each role granted to the user, this job grants entitlement (corresponding to the role) and in-turn grants the membership for the user in LDAP.
SSO Post Enable Provision Role Hierarchy to LDAP:
For each role-role relation in OIG, this job adds relationship for the groups in LDAP.

Reconciliation Behavior

User Reconciliation

User reconciliation reconciles user (and account) from the LDAP. For each user reconcilied, it provisions SSO target application instance to the reconciled user. User reconciliation job reconcilies users that have following objectclasses:

InetOrgPerson
orclIDXPerson
OblixOrgPerson
OblixPersonPwdPolicy
OIMPersonPwdPolicy

For user reconciliation, set the value for the two mandatory attributes: sn and uid.

User Matching rule:

User reconciliation job uses following reconciliation matching rule for creating or updating users in OIG:

<matchingRule>((UPPER(USR.usr_ldap_guid)=UPPER(RA_SSOTRUSTEDFORSSAEC4C34A.RA_LDAPGUID94FE1B62)) OR (UPPER(USR.usr_login)=UPPER(RA_SSOTRUSTEDFORSSAEC4C34A.RA_USERLOGIN7C7B96D4)))</matchingRule>

Account Matching rule:

User reconciliation job uses following reconciliation matching rule for provisioining SSO target application instance account to an user in OIG:

<matchingRule>((UPPER(USR.usr_login)=UPPER(RA_SSOTARGE.RA_USERLOGIN7C7B96D4)) OR (UPPER(USR.usr_ldap_guid)=UPPER(RA_SSOTARGE.RA_ORCLGUID)))</matchingRule>

Group Reconciliation

Group reconciliation job reconciles groups that have following two objectclass:

groupOfUniqueNames - in case of OID and OUD
group - in case of AD

Group reconciliation job requires that group names are unique in OIG. That is, when the job reconciles a create changelog for a group with name 'Business Administrator' and if OIG already has a role with name 'Business Administrator', then Business Administrator group would not be created again in OIG and the reconciled role will be skipped from further processing.

Alternatively, if a group exists in OIG that has a matching GUID with the group being reconciled from LDAP, then reconciliation engine would perform an update for the existing group in OIG.

Group Matching Rule:

<matchingRule>(UD_SSO_GR.UD_SSO_GR_SERVER=RA_SSOGROUP4DF6ECEE.RA_ITRESOURCENAME70C9F928 and UD_SSO_GR.UD_SSO_GR_ORCLGUID=RA_SSOGROUP4DF6ECEE.RA_ORCLGUID)</matchingRule>

Group Membership Reconciliation

Group membership reconciliation reconciles the current role grants for user in LDAP. On successful reconciliation, for each role granted to the user, an entitlement corresponding to the role is assigned to the user's SSO account.

Entitlement assignment to the user during reconciliation is executed by database trigger for child form table. This child form table stores the membership grants for the user (i.e. account). In some circumstances, the entitlement assignment trigger may not have executed and hence, the user may not have the entitlement assignment yet corresponding to the role grant reconciliation. In such scenarios, execute 'Entitlement Assignment' job to assign entitlments.

Group Hierarchy Reconciliation

Group hierarchy reconciliation job reconcilies current role relations from LDAP.

Reconciliation Job Errors and Remedial Actions

Group membership reconciliation
Group hierarchy reconciliation

Group membership reconciliation

Group membership Full reconciliation

The user entry which is reconciled is looked up in OIG corresponding to it's GUID. If no matching user is found, recon event creation for that user entry is skipped and an error message corresponding to the skipped user entry is added to job error messages.
If the user entry is present but one of the parent roles, with matching role DN, is not existing in OIG, then recon event creation for that user entry is skipped and an error message corresponding to the skipped user entry is added to job error messages.

If there are no missing parent roles for an user entry, then recon event is created for the user entry and added to batch recon service. Once reconciliation job, error message is set for the Job ID.

Group membership Incremental reconciliation

Group membership incremental reconciliation has same behavior as group membership full reconciliation. In addition to reporting the error message, incremental reconciliation also doesn't update the latest incremental token. This is to ensure that when the job is re-run (after performing remedy actions such as running user or group reconciliation jobs), then the user entry(s) which were skipped earlier are assigned a recon event during their next error-free execution.

In situations where customer decide to bypass the error-encountered user entry and want to run incremental reconciliation with latest incremental token, they can do so by checking the schedule job error message from the job UI and the latest token will be printed at the end of the error message. Refer 'Example for reconciliation error due to missing user or role'

Group hierarchy reconciliation

Group Hierarchy Full reconciliation

The role entry which is reconciled is looked up in OIG corresponding to it's GUID. If no matching role is found, recon event creation for that role entry is skipped and an error message corresponding to the skipped user entry is added to job error messages
If the role entry is present but one of the child roles, with matching role DN, is not existing in OIG, then recon event creation for the parent role entry is skipped and an error message corresponding to the skipped user entry is added to job error messages.

If there are no missing parent or child roles, then recon event is created for the parent role entry and added to batch recon service.

Once reconciliation job completes, error message is set for the Job ID.

Group Hierarchy Incremental reconciliation

Group hierarchy incremental reconciliation has same behavior as group hierarchy full reconciliation. In addition to reporting the error message if dataErrorDetected is true, incremental reconciliation also doesn't update the latest incremental token. This is to ensure that when the job is re-run (after performing remedy actions), then the role entry(s) which were skipped earlier are assigned a recon event during their next error-free execution.

In situations where customer decide to bypass the error-encountered role entry and want to run hierarhcy incremental reconciliation with latest incremental token, they can do so by checking the schedule job error message from the job UI and the latest token will be printed at the end of the error message.

Example for Reconciliation Error due to Missing User or Role

Let's assume Group Membership Incremental Reconciliation is executed and the scheduled task identifies that some of the groups, whose membership is to be reconciled, doesn't exists in OIG yet. In such scenario, the scheduled task skips the creation of recon event for the role and adds the GUID of the role to the list of data error messages. Once all the group changelog has been processed, the scheduled task proceeds to submit batch reconciliation for the roles that did not encounter such error (i.e. did not encounter role or user not existing in OIG). For the roles that encountered error, the scheduled task compiles the error message and throws an exception. The outcome is:

The scheduled job status would be failed.

For the job that failed, the 'View error details' would have the list of the roles that were skipped. The last line of the message will have the latest incremental token that was processed by the scheduled task. Sample error message:

oracle.iam.connectors.icfcommon.exceptions.OIMException:
Role with GUID 54A78A7F44E41C39E053211CF50A7639 does not exist in OIM. Skipping group membership incremental reconciliation for the role
Role with GUID 5E750AB0341F16D3E053211CF50A866D does not exist in OIM. Skipping group membership incremental reconciliation for the role
Role with GUID 5E750AB0342016D3E053211CF50A866D does not exist in OIM. Skipping group membership incremental reconciliation for the role
Role with GUID 5E750AB0346116D3E053211CF50A866D does not exist in OIM. Skipping group membership incremental reconciliation for the role
Role with GUID 5E750AB0346216D3E053211CF50A866D does not exist in OIM. Skipping group membership incremental reconciliation for the role
Role with DN cn=SYSTEM ADMINISTRATORS,cn=Groups,dc=us,dc=oracle,dc=com is not found in OIM - Skipping group membership reconciliation for the user with GUID: 5376289A3A766EE7E053211CF50A8B24.
Latest Token value: <Integer>4204</Integer>

Corrective Actions for Reconciliation Error

Customer can execute 'SSO Group Create or Update Reconciliation' job to fix the above errors and re-run group membership incremental reconciliation job. Similarly, execute 'SSO User Reconciliation' job if the error message relates to 'user not existing in OIG'.
Alternatively, if customer prefer to ignore the error for these roles and would like to proceed beyond with incremental reconciliation in future, then customer can set the Sync Token job parameter value to the latest token value listed in the error message. For example, for the above sample message, the Sync Token job parameter value would be: <Integer>4204</Integer>
In case of group membership full reconciliation or group hierarchy full reconciliation, if any of the user(s) and/or group(s) reconciled does not exist in OIG, then the job would report failed status for the missing user and/or group in all subsequent runs.

Ensuring identity Tables Data Synchronization With Child Form Tables

During group membership reconciliation and group hierarchy reconciliation, the reconciliaiton engine updates the child form table corresponding to each recon event data in reconciliation batch. When reconciliation engine triggers post process orchestration for each reconciliation batch, the post process handlers fetches the child form entry corresponding to each recon event in batch and updates OIG's identity relation tables.

Under situations where reconciliaiton post process handler fails to synchronize the child form data with identity table, it is possible to remediate the data inconsistence between the tables by executing following jobs:

Sync Group Membership with SSO Form Table:
For each user in parent form, this job synchronizes membership child form data with USG table. This job accepts an 'Group Membership Child Form Table' name as input parameter and it is assigned a default value. If membership child form table name is different in customer's deployment, then this parameter has to be assigned with appropriate value.
Sync Group Hierarchy with SSO Form Table:
For each role in parent form, this job synchronizes role relationship data with GPG table. Child form table name for role relationship is fixed for a deployment and hence, this job does not accept child form table name as input.

2.7 Configuring User Defined Fields with SSO

You can configure custom attributes or user-defined fields (UDFs) with SSO.

Note:

Role UDFs are not supported.

To do so, complete the following steps:

Create the UDFs for OIG. For more information, see Creating a Custom Attribute.

Note:
Do not specify any value for the LDAP Attribute in the Create Text Field page.
Add the UDF into the Create User Form. For more information, see Adding a Custom Attribute Category into Create User Form in Administering Oracle Identity Governance.
Add UDF to the SSO target application instance. For more information, see Adding Attribute in Performing Self Service Tasks with Oracle Identity Governance.
Add UDF to the SSO trusted application instance. For more information, see Providing Schema Information for Authoritative Application in Performing Self Service Tasks with Oracle Identity Governance.

2.8 Known Limitations and Workarounds in OIG-OAM Integration

Learn more about the known issue and limitations in OIG-OAM Integration.

Some of the known limitation in OIG-OAM Integration:

Do not request the SSO target application.
Do not use SSO target application for access policy.
Do not disable or manually remove the SSO target application.
Do not disable or manually remove the SSO target application entitlements.
SSO target application UI forms are not available out-of-box. You can generate them from the Oracle Identity System Administration Console.
When you clone a SSO target application, the new cloned application can be used for provisioning and reconciliation operations. Do not clone the SSO target application to support SSO integration.
Role User-Defined Fields (UDFs) are not supported.

For more Oracle Identity Governance Integration Issues and Workarounds, see Integration Issues and Workarounds in Release Notes for Oracle Identity Management.