This chapter describes the initial steps needed to start your servers and log in to the Oracle Access Management Console. All tasks presume that Oracle Access Management 11.1.2 is deployed as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
This information is organized in the following sections.
The Oracle Access Management Console is deployed on the WebLogic Administration Server (AdminServer) thus, Oracle Access Management Administrators can access it only when the AdminServer is running. If the Oracle Access Management Console is protected by a WebGate, the OAM Server must also be running. And the Node Manager must be started before the other servers. The following sections have more details.
Node Manager is a Java utility that allows you to perform common operations tasks for a Managed Server, regardless of its location with respect to its Administration Server. Node Manager must be running before you can start and stop the WebLogic AdminServer, or WebLogic managed servers hosting OAM Servers.
After installing and configuring Oracle Identity Manager, configure the Node Manager for use with the WebLogic Administration Console (AdminServer) or Oracle Enterprise Manager Fusion Middleware Control. This configuration is done only once, as described in "Configuring the Node Manager" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.
Following this configuration, ensure that the Node Manager is up by running the startNodeManager.sh
script. Oracle WebLogic Administration Server does not do this automatically.
$WLS_HOME/server/bin/startNodeManager.sh
See Also:
Oracle WebLogic Server Administrator Guide for details.Change to your $WLS_HOME/server/bin directory.
Enable Start Scripts: Run setNMProps
to start the stack and instruct Node Manager to enable the use of start scripts (StartScriptEnabled=true
):
./setNMProps.sh
Start Node Manager:
./startNodeManager.sh
Starting the WebLogic AdminServer the first time can take 12-15 minutes or more. This process must not be interrupted or terminated as policy data might be corrupted. The following procedure describes starting and stopping the WebLogic AdminServer using the scripts located in your $DOMAIN_HOME/bin
directory.
Unix: startWebLogic.sh
or stopWebLogic.sh
Windows: startWebLogic.cmd
or stopWebLogic.cmd
WARNING:
If startWebLogic.cmd (Windows) or startWebLogic.sh (Linux) is stopped for any reason (whether accidently or because of a system crash or reboot), policy data might be corrupted. This would require removal and recreation of the domain and running the RCU again to recreate the OAM schema.
Navigate to your $DOMAIN_HOME/bin
.
Start AdminServer:
Unix: ./startWebLogic.sh
Windows: run startWebLogic.cmd
Stop AdminServer:
Unix: ./stopWebLogic.sh
Windows: run stopWebLogic.
cmd
You can perform all start and stop operations for managed WebLogic Servers hosting Oracle Access Management Servers (OAM Servers) from either a command prompt, the Oracle WebLogic Server Administration Console or the Oracle Enterprise Manager Fusion Middleware Control. The following procedure describes starting and stopping the OAM Server using the scripts located in the $DOMAIN_HOME/bin
directory (.sh scripts for Unix systems; .cmd scripts for Windows Systems).
Unix: startManagedWebLogic.sh
or stopManagedWebLogic.sh
Windows: startManagedWebLogic.cmd
or stopManagedWebLogic.cmd
Both the Managed Server name and the AdminServer URL are required for these operations. For example, if the managed server is named oam_server1 and the AdminServer URL is http://examplewlsadminhost.example.com:7001, the start and stop commands run on a Unix system would look like these:
startManagedWebLogic.sh oam_server1 http://examplewlsadminhost.example.com:7001 stopManagedWebLogic.sh oam_server1 http://examplewlsadminhost.example.com:7001
Navigate to $DOMAIN_HOME/bin
.
Start OAM Server.
Unix: ./startManagedWebLogic.sh
MANAGED_SERVER_NAME
ADMIN_SERVER_URL
Windows: run startManagedWebLogic.cmd
MANAGED_SERVER_NAME
ADMIN_SERVER_URL
Stop OAM Server.
Unix: ./stopManagedWebLogic.sh
MANAGED_SERVER_NAME
ADMIN_SERVER_URL
Windows: run stopManagedWebLogic.cmd MANAGED_SERVER_NAME
ADMIN_SERVER_URL
A single default LDAP group, the WebLogic Server Administrators
group, is set in the Default User Identity Store (Embedded LDAP) designated as the System Store. The LDAP group, when assigned to a specified user, grants full system and policy configuration privileges. Specifying a different LDAP group prohibits WebLogic Administrators from logging in to Oracle Access Management Console or from using administrative command-line tools.
Note:
Unless explicitly stated, the term Administrator in this guide refers to the Oracle Access Management Administrator.During initial deployment with the Oracle Fusion Middleware Configuration Wizard, the Administrator userID and password are set. These credentials grant access to the:
Oracle Access Management Console to register and manage system configurations, security elements, and policies.
WebLogic Server Administration Console to view the Summary of Server Configuration (Cluster, Machine, State, Health, and Listening Port) of deployed OAM Servers within the WebLogic Server domain, and also to Start, Resume, Suspend, Shutdown, or Restart SSL on these servers. See the WebLogic Server Administration Console, see Oracle Fusion Middleware Administrator's Guide for more information.
Custom Administrative command-line tools (including the WebLogic Scripting Tool and Remote Registration Tool) provide an alternative to the Oracle Access Management Console for a specific set of functions. See Section 2.4, "Configuring with the Command-Line Tools" for more information.
Initially, administrative users must log in to the Oracle Access Management Console using the WebLogic Administrator credentials set during initial configuration. However, your enterprise might require independent sets of Administrators: one set of users responsible for Oracle Access Management administration and a different set for WebLogic administration. For information on this, see "Managing the Administrators Role".
Note:
Concurrent configuration updates are not supported. Only one Administrator is allowed to modify the system configuration at any given time. Administrators performing updates concurrently will result in an inconsistent state within the Oracle Access Management Console's system configuration.The newly-designed Oracle Access Management Console provides administrative access to Oracle Access Management services and configuration. The following sections describe features of the Oracle Access Management Console.
Note:
If you have Oracle Identity Navigator installed to access multiple consoles from one URL, see the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator.When accessing the Oracle Access Management Console, the WebLogic Server (AdminServer) host and port must be specified in the URL. Let's assume the following sample URL, https://examplewlsadminhost.example.com:7001/oamconsole. In this URL, the following is true.
HTTPS represents the Hypertext Transfer Protocol (HTTP) with the Secure Socket Layer (SSL) enabled to encrypt and decrypt user page requests and the pages returned by the Web server
examplewlsadminhost.example.com refers to fully-qualified domain name of the computer hosting the Oracle Access Management Console (AdminServer)
7001 refers to the designated bind port for the Oracle Access Management Console, which is the same as the bind port used for AdminServer (the WebLogic Server Administration Console)
/oamconsole/ refers to the Oracle Access Management Console Log In page
Note:
If you specify an OAM Server host and port (as you would to access the ODSM console), the AdminServer redirects to the managed server which produces a 404 Not Found error.When navigating to the oamconsole URL, the default Oracle Access Management Console Log In page is displayed - as in Figure 2-1.
Figure 2-1 Default Oracle Access Management Console Log In Page
Note:
Ensure that you use the correct administrative credential to log in. Initially, the LDAP group for the Oracle Access Management Console Administrator is the same as the LDAP group defined for the WebLogic Server Administration Console (Administrators
) and the common Default System User Identity Store store is the WebLogic Embedded LDAP.To log in to Oracle Access Management Console
In a browser window, enter the URL to the Oracle Access Management Console using the appropriate protocol (HTTP or HTTPS). For example:
https://hostname:port/oamconsole/
On the Log In page, enter the Oracle Access Management Console Administrator credentials. For example:
Username: Admin_login_id
Password: Admin_password
Language: English (see "Choosing a User Login Language")
Click the Login button.
Successful: The Oracle Access Management Console Welcome page is displayed.
Not Successful: See "Administrator Lockout".
The Sign Out link appears in the upper-right corner of the Oracle Access Management Console, as shown in Figure 2-2. You click the Sign Out link to conclude your session. Oracle recommends that you also close the browser window after signing out.
Figure 2-2 Signing Out of the Oracle Access Management Console
To sign out of Oracle Access Management Console
Click the Sign Out link in the upper-right corner of the console.
Close your browser window.
The Oracle Access Management Console is a Web-based program that provides function controls for system and policy configuration as well as page-level tabs and controls.
Note:
Concurrent configuration updates are not supported. Only one Administrator should be allowed to modify the system configuration at any given time. Administrators performing updates concurrently will result in an inconsistent state within the system configuration.This section provides a quick introduction to orient you to the Oracle Access Management Console.
The new Oracle Access Management Console Launch Pad provides quick access to the configuration and service pages. When a Launch Pad link is clicked, a new tab opens (in line with the default Launch Pad tab) that includes the fields applicable to the link's function. Figure 2-3 provides a look at the Oracle Access Management Console Launch Pad as it appears immediately after successfully logging in.
Figure 2-3 Oracle Access Management Console Launch Pad
The Launch Pad is divided into panels that include one or more links that you can click to initiate certain tasks. Table 2-1 contains links to the sections of this guide that contain information on these shortcuts.
Table 2-1 Welcome Page Sections and Shortcuts
Section | Shortcuts |
---|---|
Quick Start Wizards |
|
Access Manager |
|
Identity Federation |
|
Security Token Service |
See Managing Oracle Access Management Security Token Service. |
Mobile and Social |
|
Access Portal |
|
Configuration |
See Managing Access Manager Settings and Agents and Managing Access Manager SSO, Policies, and Testing. |
Like the Launch Pad, any clicked shortcut appears as a named tab under the Oracle Access Management banner. The tab of the active page is white. Only the active page is visible and generally provides a work space where you can add, view, or modify related settings. Up to ten pages (tabs) can be open simultaneously. Figure 2-4 illustrates multiple pages open at the same time. You can see named tabs for each page and controls to access pages that are concealed (or to close the active page or close multiple pages). The controls that you can use to close the open pages are described in Table 2-2.
Note:
Each page is displayed only once. No warning is issued if you attempt to open the same page multiple times.Table 2-2 Controls for Closing Pages
Page Control | Definition | Description |
---|---|---|
![]() |
Close Active Page |
Click this button to close the active page. Note: Closing a page before clicking Apply might discard any changes or additions without warning. |
![]() |
Close Multiple Pages |
Note: Closing a page before clicking Apply might discard any changes or additions without warning. |
Pages in the console contain one or more graphical user interface elements as described in Table 2-3.
Table 2-3 Page Elements and Descriptions
Page Element | Description |
---|---|
Named tab |
Identifies each open page in the console. See Figure 2-1. |
Page controls |
Enables you to close one or more pages. See Table 2-2. |
Apply button |
Submits changes or additions made to the page. |
Named text box |
Enables you to enter relevant details in the named field using the keyboard. |
Checkbox |
Enables you to choose one of several options. For example, you can tick a checkbox to define a state (Enabled vs. Disabled) or a security mode (Open vs. Simple vs. Cert). |
Tables |
Displays current specifications or space for new specifications. Tables have independent command buttons independent from page-level and option buttons. |
Command buttons for tables ![]() ![]() |
Enables you to: Add a fresh row or definition to the table. Remove the selected row or definition from the table. |
Drop down lists (list) |
Found on certain pages to provide a menu of choices from which to choose when supplying information. |
Table 2-4 describes how to select the desired node or instance and other commands and page controls in the Oracle Access Management Console. The usual selection guidelines apply.
Table 2-4 Selection Tasks and Controls
Task | Control | Description |
---|---|---|
Activate |
Click mouse button |
Click to activate the desired:
|
Open |
Click Item, Select Open command button |
Click the item, click the Open command button:
|
Highlight |
Drag cursor |
Drag the cursor across text in a box to highlight its content. |
Select |
Click mouse button |
Click the desired item on which to operate. For example, click the desired:
|
At any time while using the Oracle Access Management Console, you can click the Help link at the top of the page to get more information. Online Help topics link to information in an online version of this book.
Generally speaking, topics that are displayed by selecting Help in the Oracle Access Management Console appear in only English and Japanese languages. Online Help is not translated into the ADMIN languages.
You can click the Welcome tab to display a list of topics that describe actions you can take. For specific help topics, use the following procedure.
To locate a specific help topic
From the Oracle Access Management Console, click a tab.
Click Help in the upper-right corner of the console.
Review the page that appears in a new window and select one of the following links to:
More—Click this link to view more information.
How?—Click this link to see steps to perform a task related to your help search.
Contents—In the left Help pane, expand Contents to see all help topics as well as all topics in the online manual.
Search—Displays a search window where you can enter your help search criteria.
Click the following buttons, as needed:
View—Displays a set of viewing options.
Arrows—Return to the previous page or go forward to the next page.
Printer Icon—Prints the page.
Envelope Icon—Emails the page.
The Oracle Access Management Console provides search controls for specific elements such as Agents, Application Domains, and Resources. Figure 2-5 is a screen shot of a Search page used for SSO Agent searches.
Search pages differ depending on the entity you are trying to find. In all searches, you can leave a field blank to display everything or use a wildcard (*) character if you do not know the exact name you seek. Some search controls include the ability to save your search criteria. From the search results table, you can choose an item to open for viewing or editing.
Note:
The search tool is case insensitive.Several command-line tools are available to perform various tasks using the keyboard rather than the Oracle Access Management Console. After using these commands, the configurations will be available in the console.
Remote registration tool, oamreg
, enables remote registration of Agents, and creation of default Application Domains.
Upgrade Assistant (UA) enables you to transfer OSSO 10g configuration to Oracle Access Management
Oracle WebLogic Scripting Tool (WLST) provides a number of custom OAM command-line alternatives for tasks you can perform in the Oracle Access Management Console.
Logging is the mechanism by which components write messages to a file. These messages can be logged at different levels of granularity. Oracle Access Management components use the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 11g. Administrators can monitor performance and log messages for Access Manager and Security Token Service using Oracle Fusion Middleware Control.
In Oracle Fusion Middleware, auditing provides a measure of accountability and answers to the "who has done what and when" types of questions. Oracle Access Management uses the Oracle Fusion Middleware Common Audit Framework to support auditing for a large number of user authentication and authorization run-time events, and administrative events (changes to the system). The Oracle Fusion Middleware Common Audit Framework provides uniform logging and exception handling and diagnostics for all audit events. For more information, see Part I, "Logging, Auditing, Reporting and Monitoring Performance".
The following sections contain information on configuring user login options.
Oracle Access Management supports language selection through a drop down list of languages on the login form combined with use of the OAM_LANG_PREF language preference cookie. Table 2-5 lists the supported languages and applicable language codes.
Table 2-5 Language Codes For Login Pages
Language Code | Language | Administrators |
---|---|---|
ar |
Arabic |
|
cs |
Czech |
|
da |
Danish |
|
de |
German |
German |
el |
Greek |
|
en |
English |
English |
es |
Spanish |
Spanish |
fi |
Finnish |
|
fr |
French |
French |
fr-CA |
Canadian French |
|
he |
Hebrew |
|
hr |
Croatian |
|
hu |
Hungarian |
|
it |
Italian |
Italian |
ja |
Japanese |
Japanese |
ko |
Korean |
Korean |
nl |
Dutch |
|
no |
Norwegian |
|
pl |
Polish |
|
pt-BR |
Brazilian Portuguese |
Brazilian Portuguese |
pt |
Portuguese |
|
ro |
Romanian |
|
ru |
Russian |
|
sk |
Slovak |
|
sv |
Swedish |
|
th |
Thai |
|
tr |
Turkish |
|
zh-CN |
Simplified Chinese |
Simplified Chinese |
zh-TW |
Traditional Chinese |
Traditional Chinese |
To accomplish a very specific login experience, implement a custom login page using the customization facilities in Oracle Access Management as described in Oracle Fusion Middleware Developer's Guide for Oracle Access Management.
Note:
Prior to the release of 11.1.2.1, Oracle Access Manager relied on the Browser Language preference (Accept-Language HTTP Header) to determine the language in which the login page was rendered. The default, if the language could not determined, was English (en-us). This behavior is supported going forward until existing applications have migrated to the 11.1.2.1 model.This section provides the following topics:
Oracle Access Management provides the language selection methods described in Table 2-6. The order of these items in the table illustrate the preference order. The preference order can be configured using WLST. See Configuring Your Language Preference for details.
Table 2-6 Oracle Access Management Language Selection Methods
Method | Description |
---|---|
Server Override |
Allows the OAM Server to determine the language. It is intended to support scenarios where the User Agent cannot reliably indicate its language preference(s) or where the administrator needs to override other selection mechanisms for operational reasons. |
Preference Cookie |
A domain cookie (similar to ORA_FUSION_PREFS) that contains the user's language preferences. It is intended to allow lang preferences maintained by an application(s) personalization facilities to be used. Note: Multiple DNS domain support for the Preference Cookie is a limitation today. The solution will include Resource Webgates using the OAM Front-Channel protocol in combination with local resource cookie enhancements to manage preference cookie semantics across DNS domains. |
Browser Language |
Allows User Agents (Browsers, REST Clients, HTTP Clients) to specify the user's language preference via an HTTP Accept-Language header. |
Default Language |
Used if Oracle Access Management cannot determine the user's language preference based on the specified selection mechanisms. |
Language preferences are disabled until explicitly enabled. By default, the login form does not include the list of language values until the application locales are specified.
Note:
Language Selection is only available in the ECC login page; it is not currently available in the DCC login page.The language preference cookie, OAM_LANG_PREF is a domain scoped cookie as described in Table 2-7.
Table 2-7 OAM_LANG_PREF Cookie
Parameters | Description |
---|---|
Name |
OAM_LANG_PREF |
Domain |
Domain-scoped cookie |
Path |
/ |
Value |
[Cookie version] [separator] [UTF-8 BASE64(name-value pairs)] For example: v1.0~kqhkiG9w0BAQQFADCB0TELM |
ExpirationTime |
Persistent | Session (default) – Specified in OAM configuration |
Secure Flag |
No |
preferredLanguage |
BCP47/RFC4647. Specifically, the value space should conform to what is formally called the "language priority list". |
defaultLanguageMarker |
true (reconcile cookie with application maintained preferences) |false (read from cookie). |
Cookie Lifecycle |
Oracle Access Management and other applications can perform create, read, update, and delete operations. |
Oracle Access Management will propagate the language selected by the user to applications as described in Table 2-8.
Table 2-8 Application Integration for Language Preference
Method | Description |
---|---|
HTTP Accept-Language Header |
This enables application to integration without code change. This is a major advantage over the other options. We can expect this to be good for most applications that respond to the browser locale setting. This is the standard practice in internationalizing a Web application. We expect this to be able to become the standard option for all ADF based products, as well as any application that responds to browser locale. Note: OAM Agents ensure that the Accept-Language reflects the language selected. Also, ServletFilters could be used to make this happen. |
Access Manager Policy Response |
Access Manager stores the language selection in the attribute langPref in the session namespace. For instance: This attribute can be passed to downstream applications using an HTTP Header and/or Cookie through the Access Manager Policy Response. The name of the Header and/or Cookie is a deployment time assignment. |
Preference Cookie |
When the language selected during login differs from the value stored in the Preference Cookie, Oracle Access Management will update the " |
IdentityContext |
The language preference can be propagated as a custom claim in the IdentityContext. Select "oracle:idm:claims:session:attributes" as the claim name and then specify the session attribute using the following notation: " The claim will be created with the name of " |
Use the configOAMLoginPagePref
WebLogic Scripting Tool command to configure the login page language preferences. Information regarding this WLST command can be found in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
With Access Manager, a user needs to re-authenticate after a period of session inactivity defined by the Idle Timeout parameter (default is 15 minutes) and once the session expires, due to the value of the Session Lifetime parameter (default is 8 hours). New with this release, the Persistent Login functionality offers administrators the option to skip user re-authentication for a considerably longer period of time should the user opt in - allowing a user two weeks or a month significantly improves convenience. Persistent Login (sometimes referred to as Remember Me or Keep Me Signed In) can be enabled or disabled with the period of time being configurable. It is disabled by default.
Persistent Login is enabled in the oam-config.xml
global configuration file. The appropriate Application Domain must also explicitly allow Persistent Login. When enabled globally, the user login page will have a Keep Me Signed In checkbox and, when checked, the user receives an RMToken. Once the user's session expires or times out, a user with an RMToken will not be challenged if the resource is in the Application Domain that allows Persistent Login and if its authentication level is adequate. If the user tries to access a resource in an Application Domain that has not opted in, the user will be challenged for credentials even if the authentication level is adequate. (If the user does not opt in when logging in, reauthentication will be prompted after a session expiration or inactive timeout.)
Note:
If the Application Domain 'Session Idle Timeout' is specified, Persistent Login cannot be enabled.The following behaviors are pertinent to the Persistent Login functionality.
If enabled for the user logged in to Access Manager from a device browser, closing and reopening the browser does not require reauthentication within the defined Persistent Login time period
Session activities will be reflected in the Audit data.
When the time period expires, the end user is asked to authenticate again.
When attempting to access applications from a different device (or even a different process/browser in the same device), the end user will be asked to authenticate again.
When the user clicks log out, the OAM_RM token is deleted and they user must log in again. Session termination by an administrator will have the same effect.
As the OAM_RM token is based on credentials entered at the time of token creation, any event that changes the password status will invalidate the token and force the user to re-authenticate. This includes:
Password expiration
Password reset by administrator
Password changed by the user on a different device
User deleted or locked by the administrator
To address a stolen device scenario, the administrator can terminate all sessions for all devices/browsers of a user. The user will need to re-authenticate but has the option to enable Persistent Login on the login page
Application triggered re-authentication forces the user to re-authenticate even if Persistent Login is enabled as the application is intentionally challenging the user before doing a sensitive operation.
When a user navigates from an application which allows Persistent Login to one that does not, although the user is logged in automatically, the application which does not allow Persistent Login will challenge the user to enter credentials.
Persistent Login is not available in application triggered login pages.
The following sections have additional details.
Follow this procedure to enable Persistent Login. The feature is not enabled by default.
Enable Persistent Login globally by running one the following WLST command.
For WebLogic Server, run Oracle_IDM1/common/bin/wlst.sh using configurePersistentLogin(enable="true", validityInDays="30", maxAuthnLevel="2", userAttribute="obPSFTID")
For WebSphere Application Server, go to $IDM_HOME/common/bin/wsadmin -connType SOAP -port SOAP_PORT -user WAS_ADMIN -password WAS_ADMIN_PASSWORD and run Oam.configurePersistentLogin(enable="true", validityInDays="30", maxAuthnLevel="2", userAttribute="obPSFID")
Create a new Authentication Scheme for Persistent Login using the values in the following table.
Details can be found in Section 19.9, "Managing Authentication Schemes." The 'Keep me signed in' check box will be displayed only when accessing a resource protected by this scheme.
Attribute | Value |
---|---|
Name | PersistentLoginScheme (or any name) |
Description | any description |
Authentication Level | 2 |
Challenge Method | FORM |
Challenge Redirect URL | /oam/server/ |
Authentication Module | LDAPPlugin |
Challenge URL | /pages/login.jsp |
Context Type | default |
Context Value | /oam |
Challenge Parameters | enablePersistentLogin=true |
Click the Application Domains link in the Launch Pad.
Click the Application Domain for which you will use this PersistentLoginScheme and change its Authentication Scheme as documented in this sub procedure.
Details are in Section 20.7, "Defining Authentication Policies for Specific Resources."
Click the Authentication Policies tab in the appropriate Application Domain.
Change the Authentication Scheme for the Protected Resource Policy to PersistentLoginScheme. This allows persistent login for this policy.
Note:
The Public Resource Policy should not be modified.Click the Application Domain under which you will create a Response for all configured Authorization Policies as documented in this sub procedure.
There may be multiple authorization policies and this needs to be done for all. Details are in Section 20.9.4, "About Constructing a Policy Response for SSO."
Click the Authorization Policies tab in the appropriate Application Domain.
One at a time, click an Authorization Policy in this Application Domain to open its configuration tab.
Click Responses.
Click Add to create an Authorization Response in the Application Domain.
Enter the following values in the displayed Add Response pop-up and click Add.
Attribute | Value |
---|---|
Type | Session |
Name | allowPersistentLogin |
Value | true |
Perform this procedure for all Authorization Policies before moving on to the next step.
Access a resource protected by this scheme.
The 'Keep me signed in' checkbox is displayed on the login page.
Provide valid credentials and select 'Keep me signed in'.
Close and re-open the browser.
Access the same resource.
You will be logged in automatically without asking for credentials.
Note:
Persistent Login can also be enabled and disabled using WLST. See the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for details on theconfigurePersistentLogin
command.When enabling Persistent Login using WLST, an LDAP attribute named obpsftid
is defined to store the Persistent Login properties. When the user is locked, this attribute needs to be updated but the oamSoftwareUser
does not have sufficient LDAP rights over it. Use the following procedure to give oamSoftwareUser permission.
Copy the LDIF data below and paste it into a file that you will save as oam_user_write_acl_users_obpsftid_template.ldif
.
############################################################################## # Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. # # NAME: idm_idstore_groups_acl_template.ldif # # # DESCRIPTION: # # This file provides appropriate ACLs to user and group containers. # # # SUBSTITUTION VARIABLES: # # %s_UsersContainerDN% : The container in which users reside # %s_GroupsContainerDN% : The container in which groups reside # ############################################################################## dn: %s_UsersContainerDN% changetype: modify delete: orclaci orclaci: access to attr=(obUserAccountControl, obLoginTryCount, obLockoutTime, oblastsuccessfullogin, oblastfailedlogin, obpasswordexpirydate, obver, obLastLoginAttemptDate, oblockedon) by group="cn=orclFAOAMUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write) by group="cn=orclFAUserReadPrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare) by group="cn=orclFAUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write) - add: orclaci orclaci: access to attr=(obUserAccountControl, obLoginTryCount, obLockoutTime, oblastsuccessfullogin, oblastfailedlogin, obpasswordexpirydate, obver, obLastLoginAttemptDate, oblockedon, obpsftid) by group="cn=orclFAOAMUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write) by group="cn=orclFAUserReadPrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare) by group="cn=orclFAUserWritePrivilegeGroup,%s_GroupsContainerDN%" (search,read,compare,write)
Do the following in the created oam_user_write_acl_users_obpsftid_template.ldif
.
Replace %s_UsersContainerDN% with User Search Base.
Replace %s_GroupsContainerDN% with Group Search Base.
Change to the OID directory and run ldapmodify.
$ setenv ORACLE_HOME <OID_INSTALL_LOCATION> $ cd $ORACLE_HOME/bin $ ./ldapmodify -h <LDAP server> -p <LDAP port> -D <bind DN> -w <bindpassword> -v -f oam_user_write_acl_users_obpsftid_template.ldif