This section describes how to prepare an existing LDAP directory manually, to use for Oracle Identity and Access Management.
Note:
Do not prepare the Identity Store using both manual procedure and the IDM LCM tool. If you do so, you might encounter an error or failure during the deployment.This chapter includes the following sections:
You may have an existing LDAP directory that you wish to use for Oracle Identity and Access Management. If you are creating a new directory, you can ignore this section, as the LCM tool does this for you. If, however, you have an existing directory you wish to use, you must first prepare it using the steps described in this chapter.
The LDAP Directory types supported are:
Oracle Unified Directory
Oracle Internet Directory
Microsoft Active Directory
Create a property file iam.props, to use when preparing the Identity Store and as a basis for later integration and configuration processes. The file will have the structure described in this section. When creating the file do not include any blank lines.
The property files in this section are complete examples. Some of the parameters specified in the file will not be used until later configuration steps in the guide. It is only necessary to include the properties for the products you are going to use.
This section includes the following topics:
The following is and example configuration file for Oracle Internet Directory:
# LDAP Properties IDSTORE_HOST: idstore.example.com IDSTORE_PORT: 3060 IDSTORE_DIRECTORYTYPE: OID IDSTORE_BINDDN: cn=orcladmin IDSTORE_SEARCHBASE: dc=example,dc=com IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com IDSTORE_USERNAMEATTRIBUTE: cn IDSTORE_LOGINATTRIBUTE: uid OAM11G_SERVER_LOGIN_ATTRIBUTE: uid IDSTORE_NEW_SETUP: true # OAM Properties IDSTORE_OAMADMINUSER: oamAdmin IDSTORE_OAMSOFTWAREUSER: oamLDAP OAM11G_IDSTORE_ROLE_SECURITY_ADMIN: OAMAdministrators # OIM Properties IDSTORE_OIMADMINGROUP: OIMAdministrators IDSTORE_OIMADMINUSER: oimLDAP # WebLogic Properties IDSTORE_WLSADMINUSER: weblogic_idm IDSTORE_WLSADMINGROUP: IDM Administrators #Misc SPLIT_DOMAIN: true
The following is and example configuration file for Oracle Unified Directory:
# Common IDSTORE_HOST: idstore.example.com IDSTORE_PORT: 1389 IDSTORE_ADMIN_PORT: 4444 IDSTORE_KEYSTORE_FILE: INSTANCE_HOME/OUD/config/admin-keystore IDSTORE_KEYSTORE_PASSWORD: Password key IDSTORE_BINDDN: cn=oudadmin IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com IDSTORE_SEARCHBASE: dc=example,dc=com IDSTORE_USERNAMEATTRIBUTE: cn IDSTORE_LOGINATTRIBUTE: uid OAM11G_SERVER_LOGIN_ATTRIBUTE: uid IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com IDSTORE_NEW_SETUP: true POLICYSTORE_SHARES_IDSTORE: TRUE IDSTORE_DIRECTORYTYPE: OUD # OAM IDSTORE_OAMADMINUSER:oamAdmin IDSTORE_OAMSOFTWAREUSER:oamLDAP OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators # OAM and OIM IDSTORE_SYSTEMIDBASE: cn=SystemIDs,dc=example,dc=com # OIM IDSTORE_OIMADMINGROUP: OIMAdministrators IDSTORE_OIMADMINUSER: oimLDAP # WebLogic IDSTORE_WLSADMINUSER : weblogic_idm IDSTORE_WLSADMINGROUP : IDM Administrators #Misc SPLIT_DOMAIN: true
This section explains the configuration file property values.
IDSTORE_HOST and IDSTORE_PORT are, respectively, the host and port of your Identity Store directory. When preparing the Identity Store these should point to one of the LDAP instances. When configuring components such as OAM or OIM they should point to the load balancer entry point.
For Exalogic setup, you must specify the OTD fail-over group name for this host.
IDSTORE_DIRECTORYTYPE is the type of directory you are using. Valid values are OID, OUD
IDSTORE_BINDDN is an administrative user in the Identity Store Directory
IDSTORE_SEARCHBASE is the location in the directory where Users and Groups are stored.
IDSTORE_LOGINATTRIBUTE is the LDAP attribute, which contains the users Login name.
IDSTORE_USERSEARCHBASE is the location in the directory where Users are Stored.
IDSTORE_GROUPSEARCHBASE is the location in the directory where Groups are Stored.
IDSTORE_SYSTEMIDBASE is the location of a container in the directory where system users can be placed when you do not want them in the main user container.
IDSTORE_USERNAMEATTRIBUTE this is the name of the LDAP attribute which stores a users name.
IDSTORE_LOGIN_ATTRIBUTE this is the name of the LDAP attribute where userids are stored.
IDSTORE_ADMIN_PORT is the administration port of your Oracle Unified Directory instance. If you are not using Oracle Unified Directory, you can leave out this parameter.
IDSTORE_KEYSTORE_FILE is 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_INSTANCE_HOME/OUD/config. If you are not using Oracle Unified Directory, you can leave out this parameter.
IDSTORE_KEYSTORE_PASSWORD is the encrypted password of the Oracle Unified Directory keystore. This value can be found in the file OUD_INSTANCE_HOME/OUD/config/admin-keystore.pin.
IDSTORE_NEW_SETUP this parameter is used when preparing a directory for the first time.
IDSTORE_HOST and IDSTORE_PORT are, respectively, the host and port of your Identity Store directory. When preparing the Identity Store these should point to one of the LDAP instances. When configuring components such as OAM or OIM they should point to the load balancer entry point.
For Exalogic setup, you must provide the OTD fail-over group name for this host.
IDSTORE_OAMADMINUSER is the name of the user you want to create as your Access Manager Administrator.
IDSTORE_OAMSOFTWAREUSER is a user that gets created in LDAP that is used when Access Manager is running to connect to the LDAP server.
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN is the name of the group, which is used to allow access to the OAM console. Only users assigned to this group will be able to access the OAM Console.
OAM11G_SERVER_LOGIN_ATTRIBUTE this is the name of the LDAP attribute where userids are stored, this should be the same as the IDSTORE_LOGIN_ATTRIBUTE.
IDSTORE_OIMADMINGROUP Is the name of the group you want to create to hold your Oracle Identity Manager administrative users.
IDSTORE_OIMADMINUSER is the user that Oracle Identity Manager uses to connect to the Identity store.
IDSTORE_WLSADMINUSER: The username to be created for logging in to the web logic domain once it is enabled by SSO.
IDSTORE_WLSADMINGROUP: is the name of the group to which users who are allowed to log in to the WebLogic system components, such as the WLS Console and EM, belong.
The idmConfigTool script requires passwords to connect to the LDAP directory and to connect to the WebLogic Administration Server. It also requires you to create new passwords for the system and administrative accounts that it creates in the LDAP directory.
You can provide these passwords in one of two ways:
Interactively provide the passwords when prompted by idmConfigTool script.
Create a password file that is provided an input file to the idmConfigTool script.
If you decide to create a password file, you can run the idmConfigTool script without human interaction.
To create a password file:
Use a text editor to create a text file. You can use any file name or location, as long as it is accessible to the idmConfigTool script.
Enter the following password values in the file for example mypasswd.props:
IDSTORE_PASSWD: your_value IDSTORE_PWD_READONLYUSER: your_value IDSTORE_PWD_READWRITEUSER: your_value IDSTORE_PWD_SUPERUSER: your_value IDSTORE_PWD_OAMSOFTWAREUSER: your_value IDSTORE_PWD_OAMADMINUSER: your_value IDSTORE_PWD_OAMOBLIXUSER: your_value IDSTORE_PWD_OIMADMINUSER: your_value IDSTORE_ADMIN_PASSWD: your_value WLSPASSWD: your_value IDSTORE_PWD_XELSYSADMINUSER: your_value IDSTORE_PWD_WEBLOGICADMINUSER: your_value
If you are creating an automated deployment using the deployment wizard, you will not have access to the idmtool command described in this chapter. In such cases, if you are using Oracle Unified Directory (OUD) or Oracle Internet Directory (OID), you can choose to do one of the following:
Let the automation tool prepare the directory for you. In this case, you do not have to follow the steps in this chapter.
Use the standalone version of the idmConfigTool to create the objects.
The Software Repository includes a stand alone version of the idmtool for use in these circumstances. This tool is called idmConfigTool_STA.sh and is located in the directory LCM_HOME/existing_directory/idmtools/bin/.
Before using the tool, you must add the following parameter to the configuration file you created in Section 13.2, "Creating a Configuration File":
LDIF_FILES_DIR: LCM_HOME/existing_directory/idmtools/templates/oid
Note:
You must use this path regardless of the directory type you are using, that is, Oracle Unified Directory (OUD) or Oracle Internet Directory (OID).After you add the parameter to the configuration file, set the environment variable ORACLE_HOME to point to LCM_HOME/existing_directory. A sample configuration file can be found at LCM_HOME/existing_directory/idmtools/input_parameters.properties.
Follow the instructions in the following sections by substituting idmConfigTool_STA.sh for idmConfigTool.sh.
Before the LDAP directory can be used as an identity store for Oracle Access Management, it needs to be extended to include the object classes required by the product. Once it has been extended users are seeded into the directory for later use.
To prepare the Identity store perform the following steps:
Section 13.5.1, "Configuring Oracle Internet Directory and Oracle Unified Directory"
Section 13.5.4, "Updating Oracle Unified Directory ACIs for LDAP Synchronization"
Section 13.5.6, "Creating Access Control Lists in Non-Oracle Directories"
Pre-configuring the Identity Store extends the schema in Oracle Internet Directory (OID) and Oracle Unified Directory (OUD).
To do this, perform the following tasks on LDAPHOST1 if you are extending Oracle Internet Directory, or on LDAPHOST1 if you are extending Oracle Unified Directory:
Note:
If your Directory is on a different host to theIAD_ORACLE_HOME, then the idmconfigTool.sh tool will need to be run from that host. If you have a firewall between the IAD_ORACLE_HOME and your directory server, you will be required to open up the LDAP ports in that firewall for the duration of this step.
If you are installing OIM only and wish to configure your directory, use IGD_ORACLE_HOME instead of IAD_ORACLE_HOME. The idmtool is the same in both the locations.
Set the environment variables - MW_HOME, JAVA_HOME, and ORACLE_HOME. Make sure you set ORACLE_HOME to IAD_ORACLE_HOME or IGD_ORACLE_HOME, and MW_HOME to IGD_MW_HOME or IAD_MW_HOME.
Configure the Identity Store using the command idmConfigTool from the location IAD_ORACLE_HOME/idmtools/bin.
Note:
When you run theidmConfigTool, it creates or appends to the file idmDomainConfig.param. This file is generated in the same directory that the idmConfigTool is run from. To ensure that each time the tool is run, the same file is appended to, always run the idmConfigTool from the directory IAD_ORACLE_HOME/idmtools/bin.The syntax of the command on Linux is:
idmConfigTool.sh -preConfigIDStore input_file=configfile
For example:
idmConfigTool.sh -preConfigIDStore input_file=iam.props
When the command runs, you are prompted to enter the password of the account you are connecting to the Identity Store with. This command might take some time to complete.
Check the log file for any errors or warnings, and correct them. The file with the name automation.log is created in the directory from where you run the tool.
You must seed the Identity Store with users and groups that are required by the Identity Management components.
To seed the Identity Store, perform the following tasks on OAMHOST1 or OIMHOST1:
Set the Environment Variables: MW_HOME, JAVA_HOME and ORACLE_HOME.
Set ORACLE_HOME to IAM_ORACLE_HOME
Note:
Replace IAM_ORACLE_HOME with either IGD_ORACLE_HOME or IAD_ORACLE_HOME depending on whether theidmConfigTool is being run on OIMHOST1 or OAMHOST1.Configure the Identity Store using the command idmConfigTool, at the following location:
IAM_ORACLE_HOME/idmtools/bin
Note:
When you run theidmConfigTool, it creates or appends to the file idmDomainConfig.param. This file is generated in the directory from which idmConfigTool is run. To ensure that each time you run the tool, it appends the same file, always run the idmConfigTool from the following directory:
IAM_ORACLE_HOME/idmtools/bin
The syntax of the command on Linux is:
idmConfigTool.sh -prepareIDStore mode=MODE input_file=configfile pwd_file=passwordfile
The value selected for MODE determines the type of users to be created. Possible values for MODE are: OAM, OIM, and WLS.
In all topologies, when you enable single sign-on for your administrative consoles, you must ensure that there is a user in your Identity Store that has the permissions to log in to your WebLogic Administration Console and Oracle Enterprise Manager Fusion Middleware Control. Type:
idmConfigTool.sh -prepareIDStore mode=WLS input_file=iam.props
If your topology includes Access Manager, you must seed the Identity Store with users that are required by Access Manager. Type:
idmConfigTool.sh -prepareIDStore mode=OAM input_file=iam.props
If your topology includes Oracle Identity Manager, you must seed the Identity Store with the xelsysadm user and assign it to an Oracle Identity Manager administrative group. You must also create a user outside of the standard cn=Users location to be able to perform reconciliation. This user is also the user that should be used as the bind DN when connecting to directories with Oracle Virtual Directory. Type
idmConfigTool.sh -prepareIDStore mode=OIM input_file=iam.props
Note:
This command also creates a container in your Identity Store for reservations.Note:
When entering a password forxelsysadm ensure that it is the same at the OIM policy that is it must be at least 8 characters long, contain an Uppercase character, and a number.When the command runs, you are prompted to enter the password of the account you are connecting to the Identity Store with.
After running each command, check the log file for any errors or warnings and correct them. The file with the name automation.log is created in the directory from where you run the tool.
If you are using Oracle Unified Directory, you must grant access to the changelog, by performing the following steps on LDAPHOST1 and LDAPHOST2:
Create a file called passwordfile which contains the password you use to connect to OUD.
Remove the existing change log by issuing the command:
OUD_ORACLE_INSTANCE/OUD/bin/dsconfig set-access-control-handler-prop \
--remove \
global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; deny (all) userdn=\"ldap:///anyone\";)" \
--hostname OUD Host \
--port OUD Admin Port \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt
For example:
OUD_ORACLE_INSTANCE/OUD/bin/dsconfig set-access-control-handler-prop \
--remove
global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; deny (all) userdn=\"ldap:///anyone\";)" \
--hostname LDAPHOST1.example.com \
--port 4444 \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt
Add the new aci:
OUD_ORACLE_INSTANCE/OUD/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; allow (read,search,compare,add,write,delete,export) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=example,dc=com\";)" \
--hostname OUD Host \
--port OUD Admin Port \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt
For example:
OUD_ORACLE_INSTANCE/OUD/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; allow (read,search,compare,add,write,delete,export) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=example,dc=com\";)" \
--hostname LDAPHOST1.example.com \
--port 4444 \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt
The following is a workaround for an Oracle Unified Directory operations failure when LDAP synchronization is enabled.
Update OUD_ORACLE_INSTANCE/OUD/config/config.ldif on all OUD instances with below changes:
Look for the following line:
ds-cfg-global-aci: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2 || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 || 1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9") (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///all";)
Remove the Object Identifier (OID) 1.2.840.113556.1.4.319 from the above aci and add it to following aci as shown:
ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31 || 1.2.840.113556.1.4.319") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)
Add Object Identifiers 1.3.6.1.4.1.26027.1.5.4 and 1.3.6.1.4.1.26027.2.3.4 to the following aci as shown:
ds-cfg-global-aci: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2 || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 || 1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9 || 1.3.6.1.4.1.26027.1.5.4 || 1.3.6.1.4.1.26027.2.3.4") (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///all";)
Restart the Oracle Unified Directory server on both LDAPHOSTs.
When you ran the idmConfigTool to prepare an OUD identity store, it creates indexes for the data on the instance against which it is run. These indexes must be manually created on each of the OUD instances in LDAPHOST2.
To do this, run the following commands on LDAPHOST2:
OUD_ORACLE_INSTANCE/OUD/bin/ldapmodify -h LDAPHOST2.example.com -Z -X -p 4444 -a -D "cn=oudadmin" -j password -c \-f IAM_ORACLE_HOME/oam/server/oim-intg/ldif/ojd/schema/ojd_user_index_generic.ldif OUD_ORACLE_INSTANCE/OUD/bin/ldapmodify -h LDAPHOST2.example.com -Z -X -p 4444 -a -D "cn=oudadmin" -j password -c \-f IAM_ORACLE_HOME/idmtools/templates/oud/oud_indexes_extn.ldif
If you are performing this ready for an IDMLCM installation, use the following commands:
OUD_ORACLE_INSTANCE/OUD/bin/ldapmodify -h LDAPHOST2.example.com -Z -X -p 4444 -a -D "cn=oudadmin" -j password -c \-f IDMLCM_HOME/existing_directory/idmtools/templates/oid/ojd_user_index_generic.ldif OUD_ORACLE_INSTANCE/OUD/bin/ldapmodify -h LDAPHOST2.example.com -Z -X -p 4444 -a -D "cn=oudadmin" -j password -c \-f IDMLCM_HOME/existing_directory/idmtools/templates/oud/oud_indexes_extn.ldif
Once the indexes have been created on all of the LDAP Hosts, the indexes should be rebuilt using the commands:
Shutdown OUD by issuing the command:
OUD_ORACLE_INSTANCE/OUD/bin/stop-ds
Execute the command:
OUD_ORACLE_INSTANCE/OUD/bin/rebuild-index --rebuildAll -b "dc=example,dc=com"
Restart OUD by issuing the command:
OUD_ORACLE_INSTANCE/OUD/bin/start-ds
Repeat for every LDAPHOST including the host, which the idmTool was run against, to maintain availability only stop the directory for which you are rebuilding the indexes.
In the preceding sections, you seeded the Identity Store with users and artifacts for the Oracle components. If your Identity Store is not Oracle Internet Directory or Oracle Unified Directory, such as Microsoft Active Directory or Oracle Directory Server Enterprise Edition, you must set up the access control lists (ACLs) to provide appropriate privileges to the entities you created, this is true even if using Oracle Virtual Directory in front of them. This section lists the artifacts created and the privileges required for the artifacts.
Systemids. The System ID container is created for storing all the system identifiers. If there is another container in which the users are to be created, that is specified as part of the admin.
Access Manager Admin User. This user is added to the OAM Administrator group, which provides permission for the administration of the Oracle Access Management Console. No LDAP schema level privileges are required, since this is just an application user.
Access Manager Software User. This user is added to the groups where the user gets read privileges to the container. This is also provided with schema admin privileges.
Oracle Identity Manager user oimLDAP under System ID container. Password policies are set accordingly in the container. The passwords for the users in the System ID container must be set up so that they do not expire.
Oracle Identity Manager administration group. The Oracle Identity Manager user is added as its member. The Oracle Identity Manager admin group is given complete read/write privileges to all the user and group entities in the directory.
WebLogic Administrator. This is the administrator of the IDM domain for Oracle Virtual Directory
WebLogic Administrator Group. The WebLogic administrator is added as a member. This is the administrator group of the IDM domain for Oracle Virtual Directory.
Reserve container. Permissions are provided to the Oracle Identity Manager admin group to perform read/write operations.
To set up the directory instance of Active Directory, perform the following tasks:
Section 13.6.1, "Adding the Required Schemas to the Active Directory Instance"
Section 13.6.2, "Creating the Required Containers in the Active Directory Instance"
Section 13.6.3, "Adding Access Control Lists (ACLs) to the Containers in Active Directory"
Section 13.6.4, "Creating Users in the Active Directory Instance"
Section 13.6.5, "Adding User Memberships to Groups in an Active Directory Instance"
Section 13.6.6, "Assigning Administrator Privileges to the OIMAdministrators Group"
Section 13.6.7, "Resetting User Passwords in an Active Directory Instance"
Section 13.6.8, "Enabling User Accounts for in an Active Directory Instance"
Section 13.6.9, "Setting the LockoutThreshold in Active Directory"
The first step in preparing an existing Active Directory instance for an automatic deployment with the LCM Tools is to load the required schemas into the directory.
Oracle provides the schemas as a set of LDIF files that you can edit and then import into the Active Directory instance.
To load the schemas into the existing Active Directory instance:
Change directory to the following directory: in the LCM Tools home directory (IDMLCM_HOME):
IAM_ORACLE_HOME/idmtools/templates/ad/
Note:
If you are deploying Oracle Identity and Access Management manually, without the LCM Tools, then the schema LDIF files can be found in the following directory in the Oracle Identity and Access Management Oracle home after you install the software:
IAM_ORACLE_HOME/oam/server/oim-intg/ldif/ad/schema/
Open the LDIF files required for your topology with a text editor and replace all occurrences of <domain-dn> with the distinguished name (DN) for your organization:
If you are planning to deploy an OAM and OMSS topology, then edit the following LDIF files:
AD_OracleSchema.ldif AD_OblixSchema.ldif
Note:
If you are planning to use OMSS and Active Directory without the OAM password management functionality, then it is not mandatory to use theAD_OracleSchema and AD_OblixSchema LDIF files to extend the Active Directory schema.If you are planning to deploy an integrated OIM, OAM, and OMSS topology, then edit the following LDIF files:
AD_OracleSchema.ldif AD_UserSchema.ldif AD_oam_pwd_schema_add.ldif
Use your standard procedures to import the applicable LDIF files into the Active Directory instance.
For more information about loading an LDIF file, refer to the Active Directory documentation.
After you install the required schemas in an existing Active Directory instance, you can then create the required containers within the directory instance.
To create the required containers:
Create a new LDIF file that can be used to create the containers required for your topology.
If you are planning to deploy an OAM and OMSS topology, create a .ldif file as shown in Example 13-1.
If you are planning to deploy an integrated OIM, OAM, and OMSS topology, create a .ldif file as shown in Example 13-2.
Note that both sample .ldif files use the following as a placeholder for the actual domain container for your organization. Be sure to replace the following with the information applicable to your environment:
dc=example,dc=com
Use your standard procedures to import the LDIF file into the Active Directory instance.
Example 13-1 Sample LDIF File Used to Create Containers for an OAM and OMSS Deployment
dn: cn=Groups,dc=example,dc=com changetype: add cn: Groups objectclass: container dn: cn=SystemIDs,dc=example,dc=com changetype: add cn: SystemIDs objectclass: container dn: cn=orclFAUserReadPrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAUserReadPrivilegeGroup objectclass: group dn: cn=orclFAUserWritePrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAUserWritePrivilegeGroup objectclass: group dn: cn=orclFAUserWritePrefsPrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAUserWritePrefsPrivilegeGroup objectclass: group dn: cn=orclFAGroupReadPrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAGroupReadPrivilegeGroup objectclass: group dn: cn=orclFAGroupWritePrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAGroupWritePrivilegeGroup objectclass: group dn: cn=orclFAOAMUserWritePrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAOAMUserWritePrivilegeGroup objectclass: group dn: cn=IDM Administrators,cn=Groups,dc=example,dc=com changetype: add cn: IDM Administrators objectclass: group dn: cn=OAMAdministrators,cn=Groups,dc=example,dc=com changetype: add cn: OAMAdministrators objectclass: group
Example 13-2 Sample LDIF File to Create Containers for an Integrated OIM, OAM, and OMSS Topology
dn: cn=Groups,dc=example,dc=com changetype: add cn: Groups objectclass: container dn: cn=SystemIDs,dc=example,dc=com changetype: add cn: SystemIDs objectclass: container dn: cn=reserve,cn=Groups,dc=example,dc=com changetype: add cn: reserve objectclass: container dn: cn=orclFAUserReadPrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAUserReadPrivilegeGroup objectclass: group dn: cn=orclFAUserWritePrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAUserWritePrivilegeGroup objectclass: group dn: cn=orclFAGroupReadPrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAGroupReadPrivilegeGroup objectclass: group dn: cn=orclFAGroupWritePrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAGroupWritePrivilegeGroup objectclass: group dn: cn=orclFAOAMUserWritePrivilegeGroup,cn=Groups,dc=example,dc=com changetype: add cn: orclFAOAMUserWritePrivilegeGroup objectclass: group dn: cn=IDM Administrators,cn=Groups,dc=example,dc=com changetype: add cn: IDM Administrators sAMAccountName: IDM Administrators objectclass: group dn: cn=OAMAdministrators,cn=Groups,dc=example,dc=com changetype: add cn: OAMAdministrators sAMAccountName: OAMAdministrators objectclass: group dn: cn=OIMAdministrators,cn=Groups,dc=example,dc=com changetype: add cn: OIMAdministrators sAMAccountName: OIMAdministrators objectclass: group dn: cn=BIReportAdministrator,cn=Groups,dc=example,dc=com changetype: add cn: BIReportAdministrator sAMAccountName: BIReportAdministrator objectclass: group
After you create the required containers in the Active Directory instance, you can then set the privileges for each container, using Access Control Lists (ACLs).
Follow the instructions in the following article on the Microsoft TechNet Web site to add the ACLs listed in Example 13-3:
http://technet.microsoft.com/en-us/library/cc757520%28v=ws.10%29.aspx
Example 13-3 List of ACLs for the Required Active Directory Containers
orclFAUserReadPrivilegeGroup : Read privileges to users container orclFAUserWritePrivilegeGroup : Write privileges to users container orclFAGroupReadPrivilegeGroup : Read privileges to groups container orclFAGroupWritePrivilegeGroup : Write privileges to groups container orclFAOAMUserWritePrivilegeGroup : Write privileges to users and groups container
After you have created the containers within the Active Directory instance, then you can create the required users:
Create a new LDIF file that can be used to create the users required for your topology:
If you are planning to deploy an OAM and OMSS topology, create a .ldif file as shown in Example 13-4.
If you are planning to deploy an integrated OIM, OAM, and OMSS topology, then create a .ldif file as shown in Example 13-5.
Note that both sample .ldif files use the following as a placeholder for the actual domain container for your organization. Be sure to replace the following with the information applicable to your environment:
dc=example,dc=com @example.com
Use your standard procedures to import the LDIF file into the Active Directory instance.
Example 13-4 Sample LDIF File for Adding Users to the Active Directory Instance for an OAM and OMSS Topology
dn: cn=weblogic_idm,cn=Users,cd=example,dc=com changetype: add cn: weblogic_idm objectClass: user samAccountName: weblogic_idm givenName: weblogic_idm sn: weblogic_idm userPrincipalName: weblogic_idm@example.com dn: cn=oamadmin,cn=Users,cd=example,dc=com changetype: add cn: oamadmin objectClass: user samAccountName: oamadmin givenName: oamadmin sn: oamadmin userPrincipalName: oamadmin@example.com dn: cn=OblixAnonymous,cd=example,dc=com changetype: add cn: OblixAnonymous objectClass: user samAccountName: OblixAnonymous givenName: OblixAnonymous sn: OblixAnonymous userPrincipalName: oblixanonymous@example.com dn: cn=oamLDAP,cn=systemids,cd=example,dc=com changetype: add cn: oamLDAP objectClass: user samAccountName: oamLDAP givenName: oamLDAP sn: oamLDAP userPrincipalName: oamldap@example.com
Example 13-5 Sample LDIF File to Create Users in an Active Directory Instance for an Integrated OIM, OAM, and OMSS Topology
dn: cn=weblogic_idm,cn=Users,dc=example,dc=com changetype: add objectClass: user samAccountName: weblogic_idm givenName: weblogic_idm sn: weblogic_idm cn: weblogic_idm userPrincipalName: weblogic_idm@example.com dn: cn=xelsysadm,cn=Users,dc=example,dc=com changetype: add objectClass: user samAccountName: xelsysadm givenName: xelsysadm sn: xelsysadm cn: xelsysadm userPrincipalName: xelsysadm dn: cn=oamadmin,cn=Users,dc=example,dc=com changetype: add objectClass: user samAccountName: oamadmin givenName: oamadmin sn: oamadmin cn: oamadmin userPrincipalName: oamadmin@example.com dn: cn=OblixAnonymous,dc=example,dc=com changetype: add objectClass: user samAccountName: OblixAnonymous givenName: OblixAnonymous sn: OblixAnonymous cn: OblixAnonymous userPrincipalName: oblixanonymous@example.com dn: cn=oamLDAP,cn=systemids,dc=example,dc=com changetype: add objectClass: user samAccountName: oamLDAP givenName: oamLDAP sn: oamLDAP cn: oamLDAP userPrincipalName: oamLDAP@example.com dn: cn=oimLDAP,cn=systemids,dc=example,dc=com changetype: add objectClass: user samAccountName: oimLDAP givenName: oimLDAP sn: oimLDAP cn: oimLDAP userPrincipalName: oimLDAP@example.com
After you have created the users in the Active Directory instance, add each user to the appropriate group:
For an OAM and OMSS topology, the groups and their associated users are shown in Section 13.6.5.1.
For an integrated OIM, OAM, and OMSS deployment, the groups and their associated users are shown in Section 13.6.5.2.
For instructions on adding users to groups, see the following article on the Microsoft TechNet Web site:
https://technet.microsoft.com/en-us/library/cc737130%28v=ws.10%29.aspx
For an OAM and OMSS deployment, use the following list to assign the required users to each group:
cn=IDM Administrators,cn=Groups,dc=example,dc=com
cn=oamadministrators,cn=groups,dc=example,dc=com
cn=weblogic_idm,cn=users,dc=example,dc=com
cn=OAMAdministrators,cn=Groups,dc=example,dc=com
cn=oamadmin,cn=users,dc=example,dc=com
cn=orclFAGroupReadPrivilegeGroup,cn=Groups,dc=example,dc=com
cn=oamldap,cn=systemids,dc=example,dc=com
cn=orclFAOAMUserWritePrivilegeGroup,cn=Groups,dc=example,dc=com
cn=oamldap,cn=systemids,dc=example,dc=com
cn=orclFAUserReadPrivilegeGroup,cn=Groups,dc=example,dc=com
cn=oamldap,cn=systemids,dc=example,dc=com
For an integrated OIM, OAM, and OMSS topology, use the following list to assign the required users to each group:
cn=IDM Administrators,cn=Groups,dc=example,dc=com
cn=oamadministrators,cn=groups,dc=example,dc=com
cn=weblogic_idm,cn=users,dc=example,dc=com
cn=OAMAdministrators,cn=Groups,dc=example,dc=com
cn=oamadmin,cn=users,dc=example,dc=com
cn=OIMAdministrators,cn=Groups,dc=example,dc=com
cn=oimldap,cn=systemids,dc=example,dc=com
cn=orclFAGroupReadPrivilegeGroup,cn=Groups,dc=example,dc=com
cn=oamldap,cn=systemids,dc=example,dc=com
cn=orclFAOAMUserWritePrivilegeGroup,cn=Groups,dc=example,dc=com
cn=oamldap,cn=systemids,dc=example,dc=com
cn=orclFAUserReadPrivilegeGroup,cn=Groups,dc=example,dc=com
cn=oamldap,cn=systemids,dc=example,dc=com
cn=BIReportAdministrator,cn=Groups,dc=example,dc=com
cn=xelsysadm,cn=Users,dc=example,dc=com
For integrated OIM, OAM, and OMSS deployments, add the OIMAdministors group to the Administrators group, as follows:
In Active Directory Users and Computers, right-click the OIMAdministrators group.
Select Properties from the context menu.
Select the Member Of tab.
Click Add and use the Select Groups dialog box to add Administrators.
Click OK to close the Select Groups dialog box.
Click Apply to apply your changes.
After you have created the required users and assigned them to the appropriate groups, you should reset the user passwords.
To reset the user passwords, see the following article on the Microsoft TechNet Web site:
http://technet.microsoft.com/en-in/library/cc782255%28v=ws.10%29.aspx
Note that when you reset the password for each of the required Oracle Identity and Access Management users in the directory, clear the User must change password at next logon check box.
After you have created the containers, set the ACLs, added the users, assigned t hem to the proper groups, and reset the user passwords, you can then enable the user accounts:
From the Start menu, select Administrative Tools, and then Active Directory Users and Computers.
Click each container that contains the users you have created.
From the Details pane, right-click each user and select Enable Account.
To ensure the proper behavior when a user enters the wrong password multiple times, it important that you configure the LockoutThreshold value for Active Directory to match the security settings for Oracle Identity and Access Management software.
In most cases, it is best to set the Active Directory LockoutThreshold to 10. However, after you deploy Oracle Identity and Access Management, you should check to see if the pwdMaxFailure setting in the following Oracle Identity and Access Management configuration file is also set to 10:
DOMAIN_HOME/config/fmwconfig/ovd/oim/adapters.os_xml
In general, you should set the Active Directory LockoutThreshold to match the pwdMaxFailure setting.
For more information about the LockoutThreshold setting, see the following article on the Microsoft Technet Web site:
https://technet.microsoft.com/en-us/library/cc775412%28v=ws.10%29.aspx