OPAM – Installation and Configuration
What is OPAM?
Oracle Privileged Account Manager (OPAM) is a secure password management solution designed to generate, provision, and manage access to passwords for privileged accounts like UNIX “root” or Oracle database admin accounts. It enables auditing and establishes accountability for users who normally share privileged account credentials, and has user Session Management and Recording. It leverages the Oracle Platform Security Services (OPSS) framework as a security foundation and Oracle Database as back-end data storage.
While Oracle Privileged Account Manager most commonly manages shared and elevated privileged accounts, OPAM administrators can also use it to manage passwords for any type of account. For example, if the administrator of a certain group is on a leave and you have a business reason for allowing another employee to access the administrator’s system using his/her account, Oracle Privileged Account Manager can manage that privileged account.
What can OPAM do?
- Associates privileged accounts with targets (Target is a software system that contains, uses, and relies on user, system, or application accounts) and policies with privileged accounts.
- Grants users and groups, access to privileged accounts and removes that access after a specified time limit.
- It also provides role-based access to accounts maintained in OPAM accounts.
- Provides password check out and check in, as well as session checkout to control access to accounts
- Resets passwords to a random value on check in and check out by default for security purposes.
- OPAM can be configured to automatically check in privileged accounts after a specified time to protect against multiple open accesses.
- Manages password resets on configured targets.
- Performs Create, Read, Update, Delete, and Search (CRUDS) operations on targets, privileged accounts, and policies.
- Provides an extensible plug-in framework that uses various plug-ins to perform operations such as custom notifications, usage policies, and synchronize passwords.
- OPAM connects to targets by using Identity Connector Framework (ICF) connectors.
- Oracle Privileged Account Manager supports database, LDAP, lockbox, and UNIX target types.
Roles in OPAM:
The following are the four Administrator roles in OPAM:
- Application Configurator (OPAM_APPLICATION_CONFIGURATOR):
Configure Oracle Privileged Account Manager Console and servers, Manage plug-in configurations and Session Manager Configuration properties.
- Security Administrator (OPAM_SECURITY_ADMIN):
Manage Accounts, targets (add, edit, and remove) and password usage and policies.
- Security Auditor (OPAM_SECURITY_AUDITOR):
Open and review Oracle Privileged Account Manager reports.View Oracle Privileged Account Manager Audit reports in the Oracle Identity Navigator Reports portlet.
- User Manager (OPAM_USER_MANAGER):
Assign end users with grants to privileged accounts, Manage Usage Policies. This group can assign Usage Policies to grants and terminate all Oracle Privileged Session Manager sessions for a selected account.
Installation and Configuration – High Level Steps:
Installation Tasks:
1. Schema Creation: Create Schema for OPAM using RCU 11.1.2.x.
2. Install JDK 1.6.29 or higher.
3. Install WebLogic 10.3.6.
4. IAM Suite Installation: Install Identity & Access Management 11gR2 (11.1.2) software under middleware home by running the command:
./runInstaller -jreLoc $JAVA_HOME
5. Weblogic Domain configuration: Run the Oracle Fusion Middleware Configuration Wizard to configure OPAM in a new WebLogic domain.
cd <IAM_Home>/common/bin
./config.sh
Note: During Domain creation select Oracle Privileged Account Manager template. OPAM will be deployed under managed server opam_server1 running on port 18101 and 18102 (non SSL port).
6. Configure Database Security Store for OPAM Domain: We can share the same Database Security Store and use the same domain encryption key from the oim_domain for opam_domain:
- Export the encryption key from the oim_domain
cd <Middleware_Home>/oracle_common/common/bin ./wlst.sh exportEncryptionKey(jpsConfigFile=”<Middleware_Home>/user_projects/domains/oim_domain/config/fmwconfig/jps-config.xml",keyFilePath=”<Middleware_Home>",keyFilePassword="<password>") exit()
- Check for the encryption file present in <Middleware_Home> and join the DB Security store to opam_domain by executing the command:
<Middleware_Home> /oracle_common/common/bin/wlst.sh <IAM_Home>/common/tools/configureSecurityStore.py –d <Middleware_Home>/user_projects/domains/opam_domain -c IAM -p <oim store password> -m join -k <Middleware_Home> -w <keyFilePassword>
- This will migrate policy & credential store from XML file (and files) to database under OPSS schema.
Note: In 11gR1 you could keep policy store to XML, OID, or in Database. From 11gR2 onwards policy store must be migrated to Database under OPSS Schema.
Configuration Tasks:
1. Start WebLogic Admin Server for OPAM domain.
2. Set the ANT_HOME, ORACLE_HOME and Permgen Size
export ORACLE_HOME=<Middleware_Home>/Oracle_IDM1 export ANT_HOME=<Middleware_Home>/org.apache.ant_1.7.1 export ANT_OPTS="-Xmx512M -XX:MaxPermSize=512m"
3. Configuring OPAM: Enter relevant details when prompted and restart the Admin server
cd <IAM_Home>/opam/bin ./opam-config.sh
4. OPAM Server:
- Start the OPAM server:
cd <Middleware_Home> /user_projects/domains/opam_domain ./startManagedWeblogic.sh opam_server1
- Check the status by opening a web browser and going to https://<host>:18102/opam and login via Weblogic Admin credentials.
- Check the OPAM Admin console by browsing to https://<host>:18101/oinav/opam
5. Configure OPAM Identity Store:
- We can configure any Directory Service as an Identity store. We use the embedded Weblogic LDAP Directory as the Identity store for OPAM.
- We do not need to create a separate Authentication Provider, instead we can use the DefaultAuthenticator. External Identity store can be used while integrating OPAM with OIM.
- Create an Admin user in the Weblogic LDAP Directory by browsing to https://<host>:<Admin_port>/console and login using Weblogic Admin credentials.
- Navigate to Security Realms-> myrealm->Users and Groups->New and create “opam_admin”.
6. Assign OPAM Admin role to user:
- Log into Oracle Identity Navigator ( https://<host>:18101/oinav ) with Weblogic Admin credentials and go to the Administrator tab.
- Search for “opam_admin” user and assign the Application Configurator
- Log into OPAM console ( https://<host>:18101/oinav/opam ) with “opam_admin” credentials and confirm.
7. Manage Targets:
- Log into OIN with Weblogic Admin credentials and assign the Security Admin role to opadmin user.
- Log into OPAM console and check for Administrator Tab. Now we can add Targets and Accounts to be managed.
OPAM – OIM Integration
Configuring an External Identity Store for OPAM
To configure the Oracle Unified Directory authenticator in Oracle WebLogic Server:
1. Log in to the WebLogic Administration Console, and access Security Realms –> myrealm –> Providers Tab –> Authentication sub-tab and create a New Authentication Provider (OUDDirectory).
- Name: Enter a name for the Authentication provider. For example, OUDDirectory.
- Type: Select IPlanetAuthenticator from the list.
2. Set the Control Flags of the newly added authenticator and the default authenticator to ‘SUFFICIENT’.
The possible values for the Control Flag attribute are:
- REQUIRED – This Login Module must succeed. Even if it fails, authentication proceeds down the list of Login Modules for the configured Authentication providers.
- REQUISITE – This Login Module must succeed. If other Authentication providers are configured and this Login Module succeeds, authentication proceeds down the list of Login Modules. Otherwise, control is returned to the application.
- SUFFICIENT – This Login Module need not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are configured, authentication proceeds down the Login Module list.
- OPTIONAL – This Login Module can succeed or fail. However, if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.
Note: Control Flag attribute determines the ordered execution of the Authentication providers.
3. Select the “Provider Specific” tab and enter the required values for your environment (Host, Port, Principal, User and Group DN’s, etc.) and save it.
4. Reorder the authenticators to move the new authenticator into the first position in the list.
5. Activate changes and restart Oracle WebLogic Server.
Preparing the Identity Store
Pre-configuring the identity store extends the schema in Oracle Unified Directory.
1. Set the environment variables:MW_HOME, JAVA_HOME, and ORACLE_HOME
2. Create a properties file, called extend.props and enter the required details.
For example:
IDSTORE_HOST: idstore.mycompany.com
IDSTORE_PORT: 1389
IDSTORE_BINDDN: cn=Directory Manager
IDSTORE_USERNAMEATTRIBUTE: uid
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users, dc=mycompany, dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups, dc=mycompany, dc=com
IDSTORE_SEARCHBASE: dc=mycompany, dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids, dc=mycompany, dc=com
3. Configure the identity store by using the idmConfigTool command, which is located at:
cd <IAM_HOME>/idmtools/bin ./idmConfigTool.sh -preConfigIDStore input_file=extend.props, dc=mycompany, dc=com
Create Users and Groups for OPAM
You must fill the identity store with the users and groups that are required by Oracle Privileged Account Manager. To create the necessary users and groups, perform the following tasks:
1. Set the environment variables:MW_HOME, JAVA_HOME, and ORACLE_HOME (set it to IAM_HOME).
2. Create a properties file, called apm.props with the system details.
IDSTORE_HOST: oim.mycompany.com
IDSTORE_PORT: 1389
IDSTORE_BINDDN: cn=Directory Manager
IDSTORE_USERNAMEATTRIBUTE: uid
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users, dc=mycompany, dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups, dc=mycompany, dc=com
IDSTORE_SEARCHBASE: dc=mycompany, dc=com
POLICYSTORE_SHARES_IDSTORE: true
IDSTORE_APMUSER: opam_admin
3. Configure the identity store by using the idmConfigTool command, which is located at:
cd <IAM_HOME>/idmtools/bin ./idmConfigTool.sh -prepareIDStore input_file=apm.props, dc=mycompany, dc=com
Manually Preparing the Directory
Create the below 4 roles in the OUD Directory to manage the Accounts in OPAM
- OPAM_APPLICATION_CONFIGURATOR
- OPAM_SECURITY_ADMIN
- OPAM_SECURITY_AUDITOR
- OPAM_USER_MANAGER
End Users: Oracle Privileged Account Manager End Users are not assigned any roles, so they have limited access to Oracle Privileged Account Manager user interface components. These users are only entitled to perform certain tasks; which includes viewing, checking out, and checking in privileged accounts for which they have been granted access.
Adding the CA Certificate for OPAM
You must configure Oracle Privileged Account Manager’s Catalog Synchronization task to include the Oracle Privileged Account Manager server’s web service Certificate authority (CA) certificate or HTTPS calls to the OPAM server cannot succeed.
This process is done in two steps:
- Retrieve the CA Certificate
- Import the CA Certificate
1. Retrieve the CA Certificate
To retrieve the Oracle Privileged Account Manager server’s CA certificate:
- From your browser, connect to the OPAM server web service:
https:/hostname:sslport/opam
- Locate and save the CA certificate (.pem) file to the trust store.
- For example, from a Firefox browsers, Click the lock icon in the browser’s address bar.
When the information dialog displays, Go to More Information –> View certificate –> Certificate Viewer dialog –> Details tab to view the Certificate Hierarchy.
- Select the first certificate in the Certificate Hierarchy list, and then click Export.
- When the Save Certificate to File dialog displays, navigate to the directory where you want to save the file.
- Select X.509 Certificate (PEM) from the Save as type menu, enter opam.pem as the file name, and click Save.
2. Import the CA Certificate
Run the following command to import the CA certificate file, opam.pem, into the WebLogic trust store on the server where you are running Oracle Identity Manager:
Keytool -import -file FILE_LOCATION -keystore TRUSTSTORE_LOCATION -storepass TRUSTSTORE_PASSWORD -trustcacerts -alias ALIASwhere,
FILE_LOCATION: Full path and name of the certificate file.
ALIAS: Alias for the certificate.
TRUSTSTORE_PASSWORD: Password for the trust store.
TRUSTSTORE_LOCATION: Trust store path.
Setting Up OIM for the Integration
- Installing and Configuring the OUD connector
- Creating an OUD Application Instance.
- Create Group (opamgroup) in OUD (Identity store).
- Run Organization and Group Look up recon Schedulers from OIM ‘sysadmin’ console and verify in the corresponding Lookups in the design console.
- Run the catalog Sync Scheduler Job and check the Entitlements are added in the OUD Application Instance.
Once connector is installed and configured successfully, then do the following steps to integrate OPAM with OIM.
- Run the opamSetup Script.
- Create the OPAM_TAGS UDF.
- Tagging Catalog Entries with Oracle Privileged Account Manager Metadata
1. Running the opamSetup Script
For the Oracle Privileged Account Manager-Oracle Identity Manager integration, you must run the OPAM-OIM integration setup script, which is available in the following directory:<OIM Oracle Home>/server/bin
1. Set APP_SERVER, OIM_ORACLE_HOME, JAVA_HOME, MW_HOME, DOMAIN_HOME parameters.
2. Run opamsetup.sh command.
Enter OIM URL: t3://<oimhost>: <oimport> Enter OIM username: xelsysadm Enter OIM user password: ******** Enter OPAM IT resource name: OPAMITR Enter OPAM server name: <OPAM server host name> Enter OPAM server port: 18102 Enter OPAM user: opam_admin Enter OPAM user password: ******** Enter ID Store IT resource name: OUD Server Enter Context: weblogic.jndi.WLInitialContextFactory
This script performs the following tasks:
- Creates OPAM IT resource
- Creates a UDF column named OPAM_TAGS in the Oracle Identity Manager catalog.
- Creates an Oracle Privileged Account Manager synchronization scheduled job
- Creates the OIM.OPAM.Integration system property (if it does not yet exist) and sets it to true.
If any of these tasks fail, the script automatically executes the next task.
2. Creating the ‘OPAM_TAGS’ UDF
After setting up the Oracle Privileged Account Manager-Oracle Identity Manager integration environment, you must manually create an OPAM_TAGS user-defined field (UDF) in the Oracle Identity Manager catalog. This enables Oracle Privileged Account Manager to search the Oracle Identity Manager catalog.
To manually create the ‘OPAM_TAGS’ UDF, perform the following steps:
- Log in to ‘sysadmin’ console and create and activate a sandbox.
- Click Catalog to open the manage Catalog page.
- Create a custom field icon and specify the necessary settings and then verify that the UDFs appear in the custom fields table.
- Publish Sandbox.
3. Tagging Catalog Entries with OPAM Metadata
The Oracle Privileged Account Manager Catalog Synchronization Job created by the opamSetup script, tags the catalog entries with the Oracle Privileged Account Manager metadata. Go to Schedulers page in ‘sysadmin’ console, and run the OPAM Catalog Synchronization job.
The purpose of this scheduler is to get all groups and entitlements added by target privileged account user and update the catalog entitlement OPAM_TAGS field with the target information.
Testing OIM – OPAM Integration
1. Create a test user in OIM and provisioned user to OUD.
2. Login into OPAM as opam_admin and check the list of privileged target accounts assigned to group (opamgroup).
3. Before assigning this group, login OPAM console with the created test user and check the Accounts. (The created user shouldn’t have any privileged accounts).
4. Now we are going assign “DEV_OIM” privileged account to the test user (CSALADNA) through OIM by searching the catalog with privileged account name/ target type/ target domain/ target name which will display the all entitlements containing the ‘opamgroup’.
5. Login OPAM console with CSALADNA and check the Accounts. (It will display privileged target Accounts related to ‘opamgroup’).
6. In Group grantees, login with admin user in OPAM console and check for the user “CSALADNA” in the list of users.
This successfully completes the Integration of OPAM and OIM.
Configuring Kerberos Authentication for Databases with Oracle Unified Directory (OUD)
Use Case:
Centralized user authentication and authorization for the Oracle Databases with the following requirements:
- Use the existing Microsoft Active Directory for centralized authorization i.e., role management
- Should NOT require changes to Active Directory schema
- Should NOT require placing any DLLs on Active Directory domain controllers
- Should NOT synchronize user data to another directory
Solution
For above use case, the solution is to configure databases for Kerberos authentication and deploy the Oracle Unified Directory (OUD) proxy for AD with Enterprise User Security for authorization.
Step by step process:
Topology
Active Directory & Kerberos Server (Microsoft KDC):
- Host name: addemo1.ziontech.demo
- Microsoft Windows Server 2008 R2 Enterprise Edition with Service Pack 1
- Active Directory (incorporating Kerberos Key Distribution Centre (KDC))
- Realm name: ziontech.demoRealm name: ziontech.demo
Oracle Unified Directory:
- Host name: oud.ziontech.demo
- 11.1.2.2.0 version running on Oracle Enterprise Linux 6
Oracle Database:
- Host name: db1.ziontech.demo
- Oracle Enterprise Linux 6Oracle Enterprise Linux 6
- Oracle11g R2 Server Enterprise Edition 11.2.0.4with Oracle Advanced Security Option (ASO)
Oracle Client:
- Host name: win7a.ziontech.demo
- Microsoft Windows 7 64 bitMicrosoft Windows 7 64 bit
- Oracle11g R211.2.0.4 64 bit Client installation with Oracle Advanced Security Option (ASO)
Section 1: On AD machine
1.1 Create two users (principals in Kerberos terminology)
testuser1, which will be used to connect to DB from client

Second for Oracle DB server,
→ Check password never expires option for sever principal Check password never expires option for sever principal
- The ‘First Name’ is the fully qualified domain name of the machine the Oracle server is running on. The ‘Full Name’ will automatically be filled in.The ‘Full Name’ will automatically be filled in.
1.2 Create Key Table in Windows 2008 R2
The final step on the Windows 2008 R2 server is to extract a key table for the database server principal. This is done using the ktpass tool.
ktpass.exe -princ oracle/db1.ziontech.demo@ZIONTECH.DEMO -mapuser ZIONTECHDEMO\db1.ziontech.demo -crypto all -pass Welcome9 -out c:\keytab
The resulting keytab file should then be transferred to the machine running Oracle
There is a process on how to validate keytab (read this post). Using this approach, we can avoid lot of troubleshooting upfront by ensuring that the KVNO value is compatible.
As mentioned in above referenced post, perform following ldapsearch query to obtain msDS-KeyVersionNumber from Active Directory.
ldapsearch -h ad.ziontech.demo -p 389 -D "testuser1@ziontech.demo" -w "Welcome1" -b "DC=ziontech,DC=demo" -s sub servicePrincipalName=oracle/db1.ziontech.demo msDS-KeyVersionNumber
The output will look like:
CN=db1,CN=Users,DC=ziontech,DC=demo msDS-KeyVersionNumber=6
Then, increment value of msDS-KeyVersionNumber by 1 and pass it as a value to the parameter -kvno in ktpass command.
We can even specify specific supported algorithm(s) for crypto parameter and use this version of ktpass instead of above.
ktpass.exe -princ oracle/db1.ziontech.demo@ZIONTECH.DEMO -mapuser ZIONTECHDEMO\db1.ziontech.demo -crypto AES256-CTS-HMAC-SHA1-96 -pass Welcome9 -ptype KRB5_NT_PRINCIPAL -kvno 7 -out c:\keytab
1.3 Create a group
→ Create a group called g1 and add testuser1 to it.
Section 2: On OUD machine
2.1 Configure OUD proxy instance
2.1.1 Install JDK and OUD software. Optionally ODSM
Pretty much standard installation. Accept all defaults.
2.1.2 Invoke OUD proxy set up script:
$MW_HOME/Oracle_OUD1/oud-proxy-setup
→ Ensure, to enable SSL In server settingsEnsure, to enable SSL In server settings
→ Select Configure EUS under deployment optionsSelect Configure EUS under deployment options
→ Select Microsoft Active Directory as the backend-server typeSelect Microsoft Active Directory as the backend-server type
→ Add AD server instanceAdd AD server instance
→ Select or specify Naming ContextSelect or specify Naming Context
→ FinishFinish
2.1.3 Post Install steps
Configure the proxy workflow elements using dsconfig tool located in $MW_HOME/Oracle_OUD1/bin
dsconfig set-workflow-element-prop \ --element-name proxy-we1 \ --set remote-root-dn:CN=Administrator,CN=Users,DC=ziontech,DC=demo \ --set remote-root-password:Welcome1 \ --hostname localhost \ --port 6444 \ --trustAll \ --bindDN cn=Directory\ Manager \ --bindPasswordFile pwd.txt \ --no-prompt dsconfig set-workflow-element-prop \ --element-name proxy-we1 \ --add exclude-list:cn=directory\ manager \ --add exclude-list:cn=oraclecontext,dc=ziontech,dc=demo \ --set remote-ldap-server-bind-dn:CN=Administrator,CN=Users,DC=ziontech,DC=demo \ --set remote-ldap-server-bind-password:Welcome1 \ --hostname localhost \ --port 6444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
2.1.4 Update the realm information in the OUD configuration:
Locate the LDIF template file at $MW_HOME/Oracle_OUD1/config/EUS/modifyRealm.ldif
Edit the modifyRealm.ldif file as follows:
→ Replace dc=example,dc=com with dc=ziontech,dc=demoReplace dc=example,dc=com with dc=ziontech,dc=demo
→ Replace ou=people and ou=groups with the correct locations of the user and group entries in ADReplace ou=people and ou=groups with the correct locations of the user and group entries in AD
Use the ldapmodify command to update the configuration with the edited LDIF template file, for example:
$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file -f modifyRealm.ldif
2.2 Perform following changes in OUD proxy
Modify the attribute orclcommonkrbprincipalattribute in the EUS config (cn=OracleContext,<realm>) to the attribute name which stored the Kerberos principal on AD.
Additionally, I modified few other attributes.
$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file -f modifyConfig.ldif # cat modifyConfig.ldif dn: cn=Common,cn=Products,cn=OracleContext,dc=ziontech,dc=demo changetype: modify replace: orclCommonKrbPrincipalAttribute orclCommonKrbPrincipalAttribute: userPrincipalName - dn: cn=Common,cn=Products,cn=OracleContext,dc=ziontech,dc=demo changetype: modify replace: orclCommonWindowsPrincipalAttribute orclCommonWindowsPrincipalAttribute: samaccountname - dn: cn=Common,cn=Products,cn=OracleContext,dc=ziontech,dc=demo changetype: modify replace: orclCommonNicknameAttribute orclCommonNicknameAttribute: samaccountname -
Section 3: On DB machine
3.1 Verify that the system settings remote_os_authent=false and os_authent_prefix=”” are configured correctly:
SQL> select value from v$parameter where name = 'os_authent_prefix'; SQL> select value from v$parameter where name = 'remote_os_authent';
If you see something like ops$ for os_authent_prefix, it has to be changed to null using following process:
SQL> create pfile='/tmp/pfile.txt' from spfile; SQL> shutdown immediate;
Add this to the “/tmp/pfile.txt” file:
os_authent_prefix=''
Recreate the pfile:
SQL> sqlplus / as sysdba SQL> create spfile from pfile='/tmp/pfile.txt'; SQL> startup
3.2 Configure SQLNET for Kerberos
Modify sqlnet.ora with following configuration:
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) ADR_BASE = /app/db1 SQLNET.KERBEROS5_KEYTAB=/app/kerberos/keytab SQLNET.KERBEROS5_CONF=/app/kerberos/krb5.conf SQLNET.KERBEROS5_CONF_MIT=TRUE SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)
Create /app/kerberos/krb5.conf with following content:
[libdefaults]
default_realm = ZIONTECH.DEMO
[realms]
ZIONTECH.DEMO = {
kdc = addemo1.ziontech.demo:88
}
[domain_realm]
.ziontech.demo = ZIONTECH.DEMO
ziontech.demo = ZIONTECH.DEMO
3.3 Configure and Register Database for directory usage
Configure the database to use the directory:
Run netca and then,
1) Select ‘Directory Usage Configuration’
2) Set the Directory Type to ‘Oracle Internet Directory’
3) Set the Hostname, Port, and SSL Port for the OUD Server
4) Select the Oracle Context to use. In this document, the context used is “cn=OracleContext,dc=ziontech,dc=demo”
5) Click Finish.
This will create an ldap.ora file in the $ORACLE_HOME/network/admin directory with following content:
# ldap.ora Network Configuration File: /app/db1/product/11.2.0/dbhome_1/network/admin/ldap.ora # Generated by Oracle configuration tools. DIRECTORY_SERVERS= (oud.ziontech.demo:4389:4636) DEFAULT_ADMIN_CONTEXT = "dc=ziontech,dc=demo" DIRECTORY_SERVER_TYPE = OID
Registering Database with the Directory:
Run the Database Configuration Assistant (dbca) from the database Oracle Homes to register the database with OID.
Run dbca and then,
1) Click ‘Next’
2) Select ‘Configure Database Options’
3) Select the database from the list – there may then be a short delay.
4) On the Directory Service screen select ‘Yes, register the database’ and enter the username and password of an OUD user who is authorized to register databases. For example a username of ‘cn=Directory Manager’.
Then enter a password to be used for the new database wallet. This wallet is used to store a randomly generated internal password for the database.
5) Click ‘Next’, and the ‘Next’ again on the Database Components screen.
6) Finally click ‘Finished’ on the Connection Mode screen, and ‘OK’ on the pop-up Confirmation window.
3.4 Create test user and role on Database
Create user:
create user testuser1 identified globally as 'CN=testuser1,CN=Users,DC=ziontech,DC=demo'; grant create session to testuser1;
Create global role in the Database:
create role g1 identified globally;
3.5 Create mappings
These can be performed either by using Oracle Enterprise Manager or using a command line alternative tool ‘eusm’ located under $ORACLE_HOME/bin
# Create a role in Directory
eusm createRole enterprise_role=g1 domain_name="OracleDefaultDomain" realm_dn="dc=ziontech,dc=demo" ldap_host="oud.ziontech.demo" ldap_port=1389 ldap_user_dn='cn=Directory\20Manager' ldap_user_password='Welcome1'
# Map the ENT role with DB role
eusm addGlobalRole enterprise_role="g1" domain_name="OracleDefaultDomain" realm_dn="dc=ziontech,dc=demo" database_name="db1" global_role="g1" dbuser="system" dbuser_password="Welcome1" dbconnect_string="db1.ziontech.demo:1521:db1" ldap_host="oud.ziontech.demo" ldap_port=1389 ldap_user_dn='cn=Directory\20Manager' ldap_user_password='Welcome1'
# Grant Role
eusm grantRole enterprise_role="g1" domain_name="OracleDefaultDomain" realm_dn="dc=ziontech,dc=demo" group_dn="CN=g1,CN=Users,DC=ziontech,DC=demo" ldap_host="oud.ziontech.demo" ldap_port=1389 ldap_user_dn='cn=Directory\20Manager' ldap_user_password='Welcome1'
Section 4: On Client Machine
- Login to Windows 7 client as testuser1 to ZIONTECH.DEMO domain
- Since client Windows PC is a member of Active Directory Domain, and the user has logged into the Windows machine as a domain user, user should be able to connect to Oracle Database without need for Oracle client.
- Client is already installed under default location: C:\app\testuser1\product\11.2.0\client_1\
Modify sqlnet.ora to contain following information:
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) SQLNET.KERBEROS5_CC_NAME=OSMSFT:// SQLNET.AUTHENTICATION_SERVICES= (beq,kerberos5) SQLNET.KERBEROS5_CONF =c:\kerberos\krb5.conf SQLNET.KERBEROS5_CONF_MIT = true
Create krb5.conf in the location defined above:
SQLNET.KERBEROS5_CC_NAME=c:\kerberos\cc SQLNET.AUTHENTICATION_SERVICES= (beq,kerberos5) SQLNET.KERBEROS5_CONF =c:\kerberos\krb5.conf SQLNET.KERBEROS5_CONF_MIT = true
Create tnsnames.ora
DB1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = db1.ziontech.demo)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db1.ziontech.demo) ) )
Connect to Database using SQLplus.
User is automatically logged on to database as Oracle Client uses the internal Windows credentials cache.
Global role is assigned as expected
Keytab Validation
Setting up Kerberos authentication for the Oracle Databases or WNA with Access Manager is so simple if things go as per plan. To ensure smooth build process, it will be very helpful to perform some form of sanity checks wherever possible. One such check in process of Desktop SSO configuration is validating Keytab.
For a Keytab to successfully function the Key Version Number (KVNO) used by the Key Distribution Center (KDC) and the service principal keys stored in keytab file for services hosted on the system must match.
If not, tickets validation and thus end user authentication will fail. When tracing or debugging is enabled on the products using Keytab, messages similar to following will appear suggesting KNVO mismatch:
- Specified version of key is not available
- Invalid KNVO for Kerberos authentication
Oracle SQLplus clients configured for Kerberos authentication fail with following message.
ORA-12631: Username retrieval failed
Note that ORA-12631 is a very broad error.
The KVNO can get out of synchronization when a new set of keys is created on the KDC without updating the keytab file with the new keys.
Verification process:
We can verify KNVO using the following process:
From Keytab
On he server, where Keytab is located:
$ klist -k -t /app/kerberos/keytab
The out put will look like:
Service Key Table: /app/kerberos/keytab Ver Timestamp Principal 6 31-Dec-1969 16:00:00 oracle/db1.ziontech.demo@ZIONTECH.DEMO
If klist command is not available, we can use oklist available under Oracle database $ORACLE_HOME/bin
From KDC
Most of the enterprises use Microsoft Key Distribution Center (KDC), which is part of the Active Directory domain services. It uses the Active Directory as its account database and the Global Catalog for directing referrals to KDCs in other domains.
The KNVO for an user object in Active Directory is stored under an operation attribute called msDS-KeyVersionNumber. This can be obtained by following LDAP query:
ldapsearch -h ad.ziontech.demo -p 389 -D "testuser1@ziontech.demo" -w "Welcome1" -b "DC=ziontech,DC=demo" -s sub servicePrincipalName=oracle/db1.ziontech.demo msDS-KeyVersionNumber
The output will look like:
CN=db1,CN=Users,DC=ziontech,DC=demo msDS-KeyVersionNumber=6
Compare value of msDS-KeyVersionNumber with value under Ver in Keytab. They should match. If not, regenerate keytab using ktpass and replace the current keytab file.
In the above ldapsearch command, options represent the following:
-h hostname of the Active Directory server
-p Active Directory LDAP port
-D BindDN. You can use the default admin account or any other service account with proper read privileges
-w Specify password for Bind DN.
-b root of LDAP tree
Change servicePrincipalName value (oracle/db1.ziontech.demo in above example) according to your environment. Usually, it is same as principal (without @REALM part) found in Keytab.
Configuring Kerberos Authentication for Databases with a Microsoft Windows 2008 R2 Active Directory KDC
This post describes how to configure an Oracle database for Kerberos authentication with Microsoft Windows 2008 R2 Active Directory, and how to configure the Oracle clients.
Topology
Kerberos Server (Microsoft KDC):
- Host name: addemo1.ziontech.demo
- Microsoft Windows Server 2008 R2 Enterprise Edition with Service Pack 1
- Active Directory (incorporating Kerberos Key Distribution Centre (KDC)
- Realm name: ziontech.demoRealm name: ziontech.demo
Oracle Database:
- Host name: db1.ziontech.demo Host name: db1.ziontech.demo
- Oracle Enterprise Linux 6Oracle Enterprise Linux 6
- Oracle11g R2 Server Enterprise Edition with Oracle Advanced Security Option (ASO) with 11.2.0.4
Oracle Client:
- Host name: win7a.ziontech.demoHost name: win7a.ziontech.demo
- Microsoft Windows 7 64 bitMicrosoft Windows 7 64 bit
- Oracle11g R2 64 bit Client installation with Oracle Advanced Security Option (ASO) with 11.2.0.4
ASO approach in this post works only with Oracle Database and Clients 11.2.0.2 patchset or higher
Section 1: On AD machine
1.1 Create two users (principals in Kerberos terminology)
testuser1, which will be used to connect to DB from client

Second for Oracle DB server,

→ Check password never expires option for sever principals
1.2 Create Key Table in Windows 2008 R2
The final step on the Windows 2008 R2 server is to extract a key table for the database server principal. This is done using the KTPASS.EXE tool.
ktpass.exe -princ oracle/db1.ziontech.demo@ZIONTECH.DEMO -mapuser ZIONTECHDEMO\db1.ziontech.demo -crypto all -pass Welcome9 -out c:\keytab
The resulting keytab file should then be transferred to the machine running the Oracle Database
There is a process on how to validate keytab (read this post). Using this approach, we can avoid lot of troubleshooting upfront by ensuring that the KVNO value is compatible.
As mentioned in above referenced post, perform following ldapsearch query to obtain msDS-KeyVersionNumber from Active Directory.
ldapsearch -h ad.ziontech.demo -p 389 -D "testuser1@ziontech.demo" -w "Welcome1" -b "DC=ziontech,DC=demo" -s sub servicePrincipalName=oracle/db1.ziontech.demo msDS-KeyVersionNumber
The output will look like:
CN=db1,CN=Users,DC=ziontech,DC=demo msDS-KeyVersionNumber=6
Then, increment value of msDS-KeyVersionNumber by 1 and pass it as a value to the parameter -kvno in ktpass command.
We can even specify specific supported algorithm(s) for crypto parameter and use this version of ktpass instead of above.
ktpass.exe -princ oracle/db1.ziontech.demo@ZIONTECH.DEMO -mapuser ZIONTECHDEMO\db1.ziontech.demo -crypto AES256-CTS-HMAC-SHA1-96 -pass Welcome9 -ptype KRB5_NT_PRINCIPAL -kvno 7 -out c:\keytab
Section 2: On DB machine
2.1 Verify that the system settings remote_os_authent=false and os_authent_prefix=”” are configured correctly:
SQL> select value from v$parameter where name = 'os_authent_prefix'; SQL> select value from v$parameter where name = 'remote_os_authent';
If you see something like ops$ for os_authent_prefix, it has to be changed to null using following process:
SQL> create pfile='/tmp/pfile.txt' from spfile; SQL> shutdown immediate;
Add this to the “/tmp/pfile.txt” file:
os_authent_prefix=''
Recreate the pfile:
SQL> sqlplus / as sysdba SQL> create spfile from pfile='/tmp/pfile.txt'; SQL> startup
2.2 Configure SQLNET for Kerberos
Modify sqlnet.ora with following configuration:
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) ADR_BASE = /app/db1 SQLNET.KERBEROS5_KEYTAB=/app/kerberos/keytab SQLNET.KERBEROS5_CONF=/app/kerberos/krb5.conf SQLNET.KERBEROS5_CONF_MIT=TRUE SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)
Create /app/kerberos/krb5.conf with following content:
[libdefaults]
default_realm = ZIONTECH.DEMO
[realms]
ZIONTECH.DEMO = {
kdc = addemo1.ziontech.demo:88
}
[domain_realm]
.ziontech.demo = ZIONTECH.DEMO
ziontech.demo = ZIONTECH.DEMO
2.3 Create test user on Database
create user "TESTUSER1@ZIONTECH.DEMO" identified externally; grant create session to "TESTUSER1@ZIONTECH.DEMO";
This username must be created in uppercase and must have the realm (Active Directory domain) specified.This username must be created in uppercase and must have the realm (Active Directory domain) specified.
Section 3: On Client Machine
- Login to Windows 7 client as testuser1 to ZIONTECH.DEMO domain
- Since client Windows PC is a member of Active Directory Domain, and the user has logged into the Windows machine as a domain user, user should be able to connect to Oracle Database without need for Oracle client.
- Client is already installed under default location: C:\app\testuser1\product\11.2.0\client_1\
Modify sqlnet.ora to contain following information:
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) SQLNET.KERBEROS5_CC_NAME=OSMSFT:// SQLNET.AUTHENTICATION_SERVICES= (beq,kerberos5) SQLNET.KERBEROS5_CONF =c:\kerberos\krb5.conf SQLNET.KERBEROS5_CONF_MIT = true
Create krb5.conf in the location defined above:
SQLNET.KERBEROS5_CC_NAME=c:\kerberos\cc SQLNET.AUTHENTICATION_SERVICES= (beq,kerberos5) SQLNET.KERBEROS5_CONF =c:\kerberos\krb5.conf SQLNET.KERBEROS5_CONF_MIT = true
Create tnsnames.ora
DB1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = db1.ziontech.demo)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db1.ziontech.demo) ) )
Connect to Database using SQLplus.
User is automatically logged on to database as Oracle Client uses the internal Windows credentials cache.
Integrating OUD and EUS: Troubleshooting
Here are some of the commonly seen issues during integrating a database with Directory Services:
Issue 1: The Directory Service tab is not displayed in DBCA
- Is ldap.ora correctly configured? Compare with the example earlier in this section.
Create an ldap.ora in $ORACLE_HOME/network/admin that points to your directory services instance. The file may be created using the Network Configuration Assistant (netca) or any text editor. Below is an example of the content of the file.
DIRECTORY_SERVERS= (oud.ziontech.net:1389:1636)
DEFAULT_ADMIN_CONTEXT = "dc=ziontech,dc=net"
DIRECTORY_SERVER_TYPE = OID
- Is the correct ldap.ora located in DBCA? Check that the correct ldap.ora is located first in the search path.
Issue 2: DBCA fails to complete registration, Database Configuration Assistant: Error. Unable to create database entry in the directory service. – No Listeners configured
- Check that a copy of the listener.ora exists in the default network admin directory and that it was created via the Oracle network tools (i.e., Net Manager or Net Configuration Assistant).
- Check if the environment variables, such as TNS_ADMIN, are configured to point to the correct directory.
Issue 3: DBCA fails to complete registration, Database Configuration Assistant: Error.Unable to create database entry in the directory service
- Check if the database is already configured for LDAP Naming resolution. If the entry exists, the DBCA failed to register to OID.
- Remove the current LDAP entry before trying to register the database again. A LDAP naming entry have to be deleted using Net Manager.
I will keep updating this post with any new issues that I encounter.
Integrating OUD and EUS: OUD as Proxy
EUS can be enabled for an OUD proxy server during installation or can be configured later if a proxy instance is already existing. In this post, I will cover steps on how to create a new OUD proxy instance for EUS using a GUI and Active Directory as the backend.
Assumptions:
- OUD base product binaries are already installed and a Web Logic domain (optionally) has been configured for ODSM.
- The Active Directory has user identities to which the OUD will act as proxy.
- An OUD proxy instance will be now created.
Configuring EUS for an OUD proxy server
Change to OUD_install_dir directory. For example:
cd /opt/app/mw/Oracle_OUD/
Ensure JAVA_HOME environment variable is set to a supported JVM.
export JAVA_HOME=/opt/app/jdk
Set INSTANCE_NAME environment variable.
export INSTANCE_NAME=oud-proxy
Run the oud-proxy-setup command to configure the proxy server installation.
./oud-proxy-setup
The utility launches the graphical installer.
- On the Welcome panel, click Next.
- On the Server Settings panel, enter the proxy server’s host name or IP address, LDAP Port, Password for Root DN.
- Configure the SSL Port by clicking Configure. Click Next to continue.
- In the Deployment Options panel, select Configure EUS from the Configuration Option drop-down menu.Click Next to continue.
- Select the backend LDAP server type. In my case, it is Active Directory. Click Next.
- Click Add Server and provide Active Directory details.
- Enter the naming context.
- On the Runtime options panel, click Change to configure any specific JVM settings, or click Next to run the server with the default JVM settings.
- Review the installation configuration.
- Click Finish to complete the installation.
Screenshots for reference:
Configure the EUS content:
- Once proxy instance is created, we must configure the EUS context for each EUS suffix defined.
- Take a backup of the eusData.ldif file located at $OUD_install_dir/config/EUS/.
- Create a file /tmp/password.txt which contains the password of the Root User DN of the OUD.
- Now edit the eusData.ldif file to replace every occurrence of dc=example and dc=com by the DN of the EUS suffix, and occurrence of cn=orcladmin by the Root User DN.
Then, import the content of the files by running the following command
$OUD_INSTANCE_ROOT/OUD/bin/import-ldif -n oraclecontext -l eusData.ldif -F --hostname localhost --port 4444 --bindDN "cn=directory manager" --bindPasswordFile /tmp/password.txt
- Now, login to ODSM and navigate to Data Browser.
- We must see user identities from an Active Directory through the OUD.
This completes preparing the OUD proxy for EUS. The next steps are to prepare the database and create user mappings.
Integrating OUD and EUS: Users and Groups Mapping
After preparing the OUD and the database for EUS, users from the directory can be authenticated to the database. However, they have to be associated with a schema in the database.
Directory identities are mapped to database schemas. The database schema can be dedicated or a shared schema. Directory groups are mapped to database roles.
Create a shared schema in the database
- Creating a shared schema in the database enables one to map multiple enterprise users to the same schema.
- Run the following similar SQL statements on the database to create a user and grant basic connect access.
- We will then map a subtree from the OUD to this shared schema.
CREATE USER global_ident_schema_user IDENTIFIED GLOBALLY; GRANT CONNECT TO global_ident_schema_user;
- Now login to the database Enterprise Manager and select Enterprise User Security under the Server tab.
- Provide directory manager credentials and login.
- Click Manage Enterprise Domains, click Configure, and go to the User Schema Mappings tab.
- Click on Create.
- Select Subtree and click on torch icon to select all users to map to this shared schema. Click Continue.
- Now try to login to the database with OUD user credentials.
Creating a dedicated schema in the database
To map a directory user directly to a database schema, the first step is to get the complete DN of this particular user from the OUD.
A complete DN looks like this:
uid=nasir,ou=people,dc=ziontech,dc=net
Now, on the database run the following statements to create a user called ldap_nasir locally in the database. This will be authenticated using OID credentials.
create user ldap_nasir identified globally as 'uid=nasir,ou=people,dc=ziontech,dc=net';
We can also alter an existing user in the database so that the user will now use OUD credentials to login.
alter user existing_user identified globally as 'uid=nasir,ou=people,dc=ziontech,dc=net';
Mapping roles
- Similarly, we can map database groups and roles under the enterprise roles table and proxy permission.
- We will now create a global role in the database that allows access to the hr.employees table. The following SQL statements create a global role, hr_access, and grant the necessary privilege to it.
CREATE ROLE hr_access IDENTIFIED GLOBALLY; GRANT SELECT ON hr.employees TO hr_access;
- Next, we create an enterprise role called hr_access and assign the global role to it. We then assign this enterprise role to the enterprise user, nasir. The enterprise role can be created using Enterprise Manager.
To create the enterprise role, hr_access:
- Log in to Enterprise Manager.
- Click the Server tab. Under the Security section, click Enterprise User Security.
- Enter the distinguished name (DN) of a directory user who can administer enterprise users in the User field. Enter the user password in the Password field. Click Login.
- The Enterprise User Security page appears.
- Click Manage Enterprise Domains.
- The Manage Enterprise Domains page appears. This page lists the enterprise domains in the identity management realm.
- Select the enterprise domain that contains the database. Click Configure.
- The Configure Domain page appears.
- Click the Enterprise Roles tab.
- Click Create.
- The Create Enterprise Role page appears.
- Enter hr_access in the Name field.
- Click Add to add the database global role to the enterprise role.
- The Search and Select Database Global Roles window is displayed.
- Select the hr_access global role in your database. Click Select.
Note: You will be required to log in to the database before you can select the global role.
- Click the Grantees tab. Click Add.
- Then Select Users or Groups window appears.
- Select user Nasir. Click Select.
- Click Continue in the Create Enterprise Role page.
- Click OK in the Configure Domain page.
The enterprise user, Nasir, can now access the hr.employees table in the database.
Integrating OUD and EUS: Preparing Database
After preparing Oracle Unified Directory (OUD), the database itself must be prepared for Enterprise User Security (EUS). Preparing a database involves configuring the database, registering the database, mapping the user(s) or group(s) to a schema.
Preparing the database
Similar to OUD, there is more than one way to achieve this. We will use GUI.
Configuring the Database with OUD info:
Set the required environment variables for database. For example:
export ORACLE_BASE=/opt/app/db/ export ORACLE_SID=dbdev export ORACLE_HOME=/opt/app/db/11.2.0
Run Net Configuration Assistant (netca) tool to configure OUD for the database.
On database machine, run:
$ORACLE_HOME/bin/netca
- Welcome screen is displayed.
- Select Directory Service Usage Configuration and click Next.
- Directory Usage Configuration, Directory Type screen is displayed. Select Oracle Internet Directory as the directory type and click Next.
- On next screen, Enter the name of the host on which the OUD server is running, its port, SSL port and click Next.
- Select the default Oracle Context to use. Select the one that includes your base dn or you will receive TNS error while running dbca.
- Click Finish.
Screenshots for reference:
NetCA creates an ldap.ora file in the $ORACLE_HOME/network/admin directory which stores the connection information details about the directory.
Registering the database with the directory service:
The Database Configuration Assistant (DBCA) tool enables to register the database with OUD.
To register the database with the directory: Start DBCA using the dbca command.
$ORACLE_HOME/bin/dbca
- Welcome screen is displayed.
- Select Configure Database options.
- Select the database to which EUS will be configured.
- Click Next.
- Select Yes; register the database. Provide credentials for OUD and a password for wallet.
- Select Dedicated server mode and Click Finish.
Screenshots for reference:
Once the database is prepared, we need to associate enterprise users to database. Please refer to this post to learn about various user/group mappings available.
Integrating the OUD and EUS: User Identities in the OUD
To integrate the Oracle Unified Directory (OUD) with Enterprise User Security (EUS), the following has to be performed:
- Configuring EUS for an OUD server
- Modifying the OUD Configuration for EUS
- Configuring the Oracle Database for the OUD
Configuring EUS for an OUD server
EUS can be configured for an OUD server using one of the following options:
- Enabling EUS during instance creation
- Enabling EUS for an existing instance
This post outlines steps for enabling EUS during instance creation.
Assumptions:
- OUD base product binaries are already installed.
- A WebLogic domain is created for ODSM.
- An instance has yet to be created or a new instance will be created for EUS.
To setup an OUD instance using GUI:
- Change to the ORACLE_HOME sub directory for OUD (i.e., where you have installed the software)
cd OUD-base-location Ensure that your JAVA_HOME environment variable is set.
- Run OUD-setup; this will create an OUD instance.
- Click Next on first screen.
- Provide details for the server settings.
- Since enabling EUS requires an SSL, configure an SSL.
- Select your topology, if required.
- Provide the base DN details.
- Select Enable EUS on Oracle Components Integration screen; click Next.
- Review your configuration details; click Finish.
Screenshots for reference:
Login to ODSM
- Navigate to http://oud-hostname:port/odsm.
- Create a connection for the newly created OUD instance and login.
- Trust the certificate.
- Go to the data browser and validate the following:
- When EUS is selected, in addition to creating this suffix, two suffixes are created automatically: “cn=oracleschemaversion” and “cn=oraclecontext.”
- An EUS workflow element is also added in front of the local backend workflow element.
- A DN renaming workflow element for “cn=schema” is added, so that it can be accessed using the “cn=subschemasubentry” DN.
After the OUD has been enabled for EUS, the realm information must be updated in the OUD configuration by performing the following steps:
Locate the LDIF template file at install_dir/config/EUS/modifyRealm.ldif
- Edit the modifyRealm.ldif file as follows:
- Replace dc=example,dc=com with the correct naming context for your server instance.
- Replace ou=people and ou=groups with the correct location of the user and group entries in your DIT.
- Use the ldapmodify command to update the configuration with the edited LDIF template file. For example:
ldapmodify -h oud.ziontech.net -p 1636 -D "cn=Directory Manager" -Z -v -f /opt/app/middleware/Oracle_OUD1/config/EUS/modifyRealm.ldif
With this, we have an OUD instance ready for EUS. The next steps are to prepare the database and create user mappings.