Troubleshooting Common Problems in Access Manager and OIG Integration

4 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.

4.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:

4.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.

4.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.

4.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.

4.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.

4.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.

4.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. See Exporting and Importing the OAM Configuration File for the steps to export and import the oam-config.xml file.

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>

4.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>

4.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 respond, 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.

4.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.

4.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.

4.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

4.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.

4.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:

Note:

See Exporting and Importing the OAM Configuration File for the steps to export and import the oam-config.xml file.

<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 the TAP encryption key:

Update the OIMPartner attribute with OIMPartnerOld attribute by using OAM REST API. See Modifying OAM Configuration Parameters Using OAM REST API.
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.

4.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.

4.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.

4.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.

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

This provides solutions for the following miscellaneous issues:

4.5.1 Scheduler and System Properties do not come up in the Integrated Environment

When accessing the scheduler page, the following error occurs and configuration properties are not visible.

Failed <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head>
<title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The
requested URL /iam/governance/selfservice/api/v1/scheduler/history was not
found on this server.</p> </body></html>

Solution

Add the following entries in the oim.conf file at the following locations:

Locations:

OAM_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/oim.conf

OAM_DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs1/moduleconf/oim.conf

Entries

<Location /iam/governance/adminservice/api/v1>
 SetHandler weblogic-handler
 WLCookieName oimjsessionid
 WebLogicHost %OIM_HOST%
 WebLogicPort %OIM_PORT%
 WLLogFile “${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log”
</Location>

<Location /iam/governance/selfservice/api/v1>
 SetHandler weblogic-handler
 WLCookieName oimjsessionid
 WebLogicHost %OIM_HOST%
 WebLogicPort %OIM_PORT%
 WLLogFile “${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log”
</Location>

Restart the servers

4.5.2 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.

4.5.3 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

4.5.4 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.

4.5.5 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.

4.5.6 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}

4.5.7 SSO Reconciliation Filter Does Not Work With DN Attributes for Trusted Source Reconciliation

When you use Contains, startsWith, and endsWith filters with the entryDN field, SSO full and incremental reconciliation fails with the following error:

org.identityconnectors.framework.common.exceptions.ConnectorException:
Unsupported filter type for attribute entryDN

The LDAP filters on the entryDN and DN attributes are not supported as per the LDAP connector specification/implementation. Only the __parentDN__ attribute with the equalTo filter is supported as per the current LDAP filter support. Therefore, for fetching users under the OU as part of trusted reconciliation, the equalTo filter must be applied on the __parentDN__ attribute.

4.5.8 Login Fails for Users Created Through Bulk Load

In an OAM-OIG integrated environment with AD used as LDAP in connector-based setup, if login does not work for users created through bulk load, then follow the solution described in this topic.

Cause

This happens because in the AD target user attribute sAMAccountName has some junk value, such as$JI7000-BD7NAT1841M6, instead of the actual user ID.

Solution

When AD is used as LDAP, update the transformation script for the application SSOTarget to add the condition for BULKLOAD. To do so:

Login to Oracle Identity Self Service.
Click the Manage tab, and edit the SSOTarget application from the Applications page.
Go to the Settings page, and click the Reconciliation tab.
In the Validation & Transformation section, click Transformation Script to open the editor.

Add the condition for BULKLOAD, as shown:

(context.provisionMechanism.equalsIgnoreCase("REQUEST") 
||
context.provisionMechanism.equalsIgnoreCase("ADMIN") 
||
context.provisionMechanism.equalsIgnoreCase("BULKLOAD")
) 
{
if (User_Id == null || User_Id == "") {
User_Id = getBeneficiaryAttrFromContext("User Login");
}

Save the changes.

After adding this condition for BULKLOAD, reload all the bulkload users, and then attempt for login.

4.5.9 Events are Generated Without Any Changes in the Target

When you run the SSO User Incremental Reconciliation scheduled job, events are generated although there are no changes done in the target.

Cause

Events are generated because the obPasswordExpiryDate field value coming from the target is not formatted correctly in OIG.

Solution

In Oracle Identity Self Service, click the Manage tab, and edit the SSOTarget application from the Applicaitons page.
Go to the Schema page and change the advanced settings of the obPasswordExpiryDate schema attribute to enable the Date option.
Save the changes.
Run the SSO User Incremental Reconciliation scheduled job.

4.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.

4.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

4.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.