Wednesday Apr 08, 2015

New OUD Source Code plugin examples

I've just published a couple of OUD plugin examples to help customers develop their own extensions.

The ZIP package includes 2 plugin examples to demonstrate the richness of OUD plugin API. The FilterDistributor can be used to route bind request to 2 different workflow elements based on a condition present on the user entry about to be used for authentication. The PasswordSchemeUpgrade  can be used to migrate passwords from one storage/encryption scheme to another.

Plugins examples are available at http://www.oracle.com/technetwork/middleware/id-mgmt/learnmore/oid-demos-182820.html

OUD Plugin API reference is available at http://docs.oracle.com/cd/E49437_01/apirefs.111220/e38583/index.html

OUD Plugin Developer Guide is available at http://docs.oracle.com/cd/E49437_01/doc.111220/e38455/toc.htm

Tuesday Mar 10, 2015

Support Dates for ODSEE have been updated

FYI, the End of support dates for ODSEE have been updated. See link below (page 37 and 42):

http://www.oracle.com/us/support/library/lifetime-support-middleware-069163.pdf

Wednesday Jan 14, 2015

Configuring OUD to Support Multiple Enterprise User Security Domains

Configuring OUD to Support Multiple Enterprise User Security Domains

If your users and groups are stored in multiple domains, you must configure OUD to support multiple EUS domains. For example, a single OUD instance contains two EUS domains. One EUS domain stores users entries in Active Directory below cn=users,dc=ad1,dc=com. A second EUS domain stores user entries in a different Active Directory instance below cn=users,dc=ad2,dc=com. You must configure OUD to support each EUS domain.

To configure OUD to support multiple EUS domains:

  1. Configure OUD as if the primary domain is the single domain containing all your users and groups.

    In this example, the primary domain is dc=ad1,dc=com.

    Complete the tasks in 28.4 Oracle Unified Directory Used as a Proxy Server for an External LDAP Directory with Enterprise User Security

  2. Configure the secondary domain.

    In this example, the secondary domain is dc=ad2,dc=com.

    For this secondary domain, complete the steps in 28.4.1.1 User Identities in Microsoft Active Directory

  3. Create a new naming context for the EUS domain, which is dc=ad2,dc=com in this example.

    Complete the steps in 28.4.2.1.2 to configure Enterprise User Security for an existing Oracle Unified Directory Proxy Server instance.

  4. Update the Oracle context with the new naming context.

    1. Create an LDIF file.

      In the following myconfig.ldif example, make the following substitutions:

      • Replace dc=ad1,dc=com with the DN of your first domain.

      • Replace orclcommonusersearchbase with the users location in the secondary domain.

      • orclcommongroupsearchbase with the groups location in the secondary domain.

      dn: cn=Common,cn=Products,cn=OracleContext,dc=ad1,dc=com
      changetype: modify
      add: orclcommonusersearchbase
      orclcommonusersearchbase: cn=users,dc=ad2,dc=com
      orclcommongroupsearchbase: cn=groups,dc=ad2,dc=com
      
    2. Update OUD configuration using the LDIF file you created in step 4a.

      ldapmodify -h oudhost -p 1389 -D "cn=directory manager" 
      
      -w password -f myconfig.ldif

Friday Oct 17, 2014

Troubleshooting OUD/EUS integration: Invalid username/password; logon denied

Oracle's Enterprise User Security (EUS) enables you to store user identities in LDAP-compliant directory service for Oracle Database authentication.

Enterprise User Security enables you to centrally manage database users across the enterprise. Enterprise users are created in LDAP-compliant directory service, and can be assigned roles and privileges across various enterprise databases registered with the directory.

Users connect to Oracle Database by providing credentials that are stored in Oracle Unified Directory. The database executes LDAP search operations to query user specific authentication and authorization information.

Here are steps to troubleshoot EUS when the "Invalid username/password; login denied" is reported to DB users by EUS:

First, this error is reported in 2 cases:

  • the DB is not able to find a LDAP user that corresponds to the provided name on the DB side, 
  • the user password is invalid.
Assuming the password is correct, follow the procedure below to identify the root cause:

#1 Check EUS configuration

The database reads its configuration from the entry cn=common,cn=products,cn=oraclecontext,$BASEDN:

  • The location of users and groups is configured in the attributes orclcommonusersearchbase and orclusercommongroupsearchbase. They are referred to as users and groups containers.
  • The username supplied to sqlplus must correspond to the value of orclcommonnicknameattribute in the user entry. For instance, if I connect to sqlplus using sqlplus joe/password, and orclcommonnicknameattribute=uid, then the database will look for an entry containing the attribute uid=joe.
  • The user entry DN must start with orclcommonnamingattribute. For instance, if orclcommonnamingattribute=cn, the user entry must be cn=joeuser,<orclcommonusersearchbase>.

You can read the configuration using the following command:

$ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -b cn=common,cn=products,cn=oraclecontext,$BASEDN  "(objectclass=*)" orclcommonusersearchbase orclcommongroupsearchbase orclcommonnicknameattribute orclcommonnamingattribute
dn: cn=Common,cn=Products,cn=OracleContext,dc=eusovd,dc=com
orclcommonusersearchbase: ou=people,dc=eusovd,dc=com
orclcommongroupsearchbase: ou=groups,dc=eusovd,dc=com
orclcommonnicknameattribute: uid
orclcommonnamingattribute: cn

#2 Check the User Entry

You  must ensure that there is an LDAP entry in the user container that matches the username supplied by SQL+. Target LDAP entry must be an instance of inetorgperson and contain the attribute defined in orclcommonnicknameattribute:

$ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -D $DN -w $PWD -b ou=people,$BASEDN  "(uid=joe)"                         
dn: cn=joe,ou=people,dc=eusovd,dc=com
userPassword: {SSHA}DdW5je5GCUnT2jVTeMdfPR9NWwkBt40FwWImpA==
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: top
uid: joe
cn: joe
sn: joe

#3 Check the User-schema mappings

If the user entry exists and can be read by the database entry, the problem can be that there is no user-schema mapping. EUS maps the LDAP user entry to a database schema following a mapping rule that is defined in Enterprise Manager console. The mapping associates either a user DN to a schema or all users of a subtree to a schema. It can be defined at the domain level or at the database level.

#4 Check the global schema associated with the user

If there is a user-schema mapping, ensure that the schema has the CONNECT privilege.

The global schema was defined using the following commands:

SQL> CREATE USER global_ident_schema_user IDENTIFIED GLOBALLY;
User created.
SQL> GRANT CONNECT TO global_ident_schema_user;

Monday Oct 06, 2014

Data Adaptation again

Yet another common usage of OUD Transformations to transparently adapt some values during provisioning:

In this real use case, ODIP (Oracle Directory Integration Platform) is used to synchronize some SQL tables with OUD.
The country every user is living in is stored in an Oracle DB and is synchronized by DIP into the LDAP country attribute.
Unfortunatelly, the country name format expected by the applications on the Directory side differ from the one used on the DB side.

In this case, country name is stored in full in the DB (e.g. USA, FRANCE, ITALY) when apps that contact OUD expect standard country short form e.g. US, FR, IT.  For administrative and political reasons within the enterprise, it is not possible to create a additional mapping table in the RDBMS that could be used by a SQL JOIN to return the correct values.

OUD Tranformation Framework can be used to address that integration problem: a so-called add inbound tranformation is invoked when a new entry is created and value mapping is applied on the incoming add request before it is processed by the OUD database engine. For sake of peformance, this transformation can be configured to trigger on udates originated from DIP only, using the network group mechanism.

To create a transformation that maps USA to US and France to FR, do the following:

First create the transformation with the appropriate mappings:

dsconfig create-transformation \
--set source-attribute:country=%country%(US,USA)(FR,France)(IT,Italy) \
--type add-inbound-attribute \
--transformation-name mapCountry \
--set conflict-behavior:virtual-overrides-real 

Then stash this transformation to a Transformation Workflow element to be inserted ahead of local DB (userRoot):

dsconfig create-workflow-element \
          --set enabled:true \
          --set next-workflow-element:userRoot \
          --set transformation:mapCountry \
          --type transformations \
          --element-name mapCountry

Then put the Transformation Workflow Element to the appropriate workflow so  that it can be invoked:

dsconfig set-workflow-prop \
          --workflow-name userRoot1 \
          --set workflow-element:mapCountry

 At that stage, appropriate values are automatically stored in OUD.

Wednesday Jul 23, 2014

OUD R2PS2 Bundle Patch available

The first bundle patch for OUD 11gR2PS2 (11.1.2.2.1) is available for download from My Oracle Support.

Search for the support note 1905631.1 (Doc ID 1905631.1 : Information And Bug Listing of Oracle Unified Directory Bundle Patches: 11.1.2.2.x (11gR2PS2))  that describes its content and download instructions (patch 18662903)

Thursday Jul 10, 2014

ODSM Silent Install

If you plan to manage Oracle Unified Directory (OUD) with Oracle Directory Services Manager (ODSM), you must install and configure it as described in the Installation Guide. The installation process described rely on a Graphical User Interface. 

Here is the equivalent procedure in silent mode so that you can incorporate it in a script or automated procedure:
To make it short, you need to install OUD as described in this post, configure an application server (WebLogic), then install the ADF framework, install ODSM and add it to a weblogic domain then start WebLogic.

#1 Weblogic installation 

- download weblogic 10.3.6 from http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html
- locate wls1036_generic.jar in the delivery
- create a input file (WEBLOGIC_silent.xml) for Weblogic install (properties in bold to be customized, assuming that you install the middleware components in /local/myinstall)

<?xml version="1.0" encoding="UTF-8"?>
<bea-installer> 
<input-fields>
<data-value name="BEAHOME" value="/local/myinstall" />
<data-value name="USER_INSTALL_DIR"  value="/local/myinstall" />
<data-value name="INSTALL_NODE_MANAGER_SERVICE"   value="no" />
<data-value name="COMPONENT_PATHS" value="WebLogic Server/Core Application Server|WebLogic Server/Administration Console|WebLogic 
Server/Configuration Wizard and Upgrade Framework|WebLogic Server/Web 2.0 HTTP Pub-Sub Server|WebLogic Server/WebLogic JDBC Drivers|WebLogic 
Server/Third Party JDBC Drivers|WebLogic Server/WebLogic Server Clients|WebLogic Server/WebLogic Web Server Plugins|WebLogic Server/UDDI 
and Xquery Support|WebLogic Server/Server Examples" />
<data-value name="LOCAL_JVMS" value="/usr/lang/JAVA/jdk7_u45/linux-x64"/>
</input-fields>
</bea-installer>
- run
    wls1036_generic.jar -mode=silent -silent_xml=./WEBLOGIC_silent.xml

#2 Install ADF

- download the Oracle Application Development Framework from Oracle Technology Network (OTN) at the following location: http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html
- locate and unzip appdev.zip to target directory e.g. /local/myinstall/appdev_unzip
- create an input file (oui_install.rsp ) to install appdev (properties in bold to be customized)

[ENGINE]
 
  
#DO NOT CHANGE THIS.
Response File Version=1.0.0.0.0
 
  
[GENERIC]
 
  
#Set this to true if you wish to specify a directory where latest 
updates are downloaded. This option would use the software updates from 
the specified directory
SPECIFY_DOWNLOAD_LOCATION=false
 
  
#
SKIP_SOFTWARE_UPDATES=true
 
  
#If the Software updates are already downloaded and available on your 
local system, then specify the path to the directory where these patches 
are available and set SPECIFY_DOWNLOAD_LOCATION to true
SOFTWARE_UPDATES_DOWNLOAD_LOCATION=
 
  
#Provide the Oracle Home location. The location has to be the immediate 
child under the specified Middleware Home location. The Oracle Home 
directory name may only contain alphanumeric , hyphen (-) , dot (.) and 
underscore (_) characters, and it must begin with an alphanumeric 
character. The total length has to be less than or equal to 128 
characters. The location has to be an empty directory or a valid SOA 
Oracle Home.
ORACLE_HOME=/local/myinstall/Oracle_appdev
 
  
#Provide existing Middleware Home location.
MIDDLEWARE_HOME=/local/myinstall
 
  
#
CONFIG_WIZARD_RESPONSE_FILE_LOCATION=0
 
  
[SYSTEM]
 
  
[APPLICATIONS]
 
  
[RELATIONSHIPS]

- install appdev (path in bold to be customized)
/local/myinstall/appdev_unzip/appdev/Disk1/runInstaller -silent -response ./oui_install.rsp -invPtrLoc /local/myinstall/appdev_unzip/oraInst.loc  -jreLoc /usr/lang/JAVA/jdk7_u45/linux-x64 -waitforcompletion

#3 Create Weblogic domain for ODSM

- Create template file (e.g create_domain.py) and customize the properties in bold.

#!/usr/bin/python
import os, sys
readTemplate(r'/local/myinstall/wlserver_10.3/common/templates/domains/wls.jar')
cd(r'/Security/base_domain/User/weblogic')
cmo.setPassword('welcome1')
cd(r'/Server/AdminServer')
cmo.setName('AdminServer')
cmo.setListenPort(7001)
cmo.setListenAddress('mylocalhost')
create('AdminServer','SSL')
cd('SSL/AdminServer')
cmo.setEnabled(true)
cmo.setListenPort(7002)
cmo.setHostnameVerificationIgnored(true)
cmo.setHostnameVerifier(None)
cmo.setTwoWaySSLEnabled(false)
writeDomain(r'/local/myinstall/WEBLOGIC_domains/ODSM')
closeTemplate()
exit()

- Run the following command to create the ODSM domain:

/local/myinstall/oracle_common/common/bin/wlst.sh /local/myinstall/create_domain.py

#4 Configure ODSM

- create template file (e.g config_odsm.py) and customize properties in bold

#!/usr/bin/python

import os, sys

readDomain('/local/myinstall/WEBLOGIC_domains/ODSM')
addTemplate(r'/local/myinstall/Oracle_OUD/common/templates/applications/oracle.odsm_11.1.1.5.0_template.jar')
updateDomain()
closeDomain()
exit()

- Run the following command:

/local/myinstall/oracle_common/common/bin/wlst.sh /local/myinstall/config_odsm.py

#5 Start Weblogic domain

/local/myinstall/WEBLOGIC_domains/ODSM/bin/startWebLogic.sh  


Thursday Mar 06, 2014

Transition Guide from DSEE to OUD just published

Transition Guide from (O)DSEE to Oracle Unified Directory (OUD) was just added to the OUD doc set.
It is available at http://docs.oracle.com/cd/E49437_01/doc.111220/e51265.pdf

Other OUD documents are available at http://docs.oracle.com/cd/E49437_01/index.htm

Friday Feb 28, 2014

Oracle Unified Directory (OUD) Forum on OTN

Friendly reminder, feel free to post OUD-related questions on the OUD Forum available at
https://community.oracle.com/community/developer/english/fusion_middleware/identity_management/oracle_directory_server_enterprise_edition_sun_dsee

Tuesday Feb 18, 2014

Lessons from the Field: A directory transition from DSEE 6.3.1.1 to OUD 11gR2PS1

I was recently involved in a LDAP directory services transition project, from DSEE 6.3.1.1 to OUD 11gR2PS1, for a large manufacturing enterprise. Directory service is medium-sized with a few of million LDAP entries, and is accessed by a wide range of services and applications, ranging from Corporate Directory to Identity Store for Identity Management and user management for intranet and extranet portals.

Here is an overview of the steps we followed and the issues we addressed during this project to successfully transition the infrastructure to OUD.

1. Transition Assessment

Putting in place a sound methodology and design is a key success factor for a directory migration, regardless the final migration options selected.
This assessment was conducted over a period of 3 weeks and included the following:


- Identification and formalization of the main drivers and requirements for transition
- Inventory of the current directory infrastructure, including identification of the application portfolio accessing the directory
- Identification of transition options compatible with requirements
- Estimation of transition effort
- Identification of training requirement for the staff and skills required during the transition, especially people with business knowledge of the data stored in the directory.

For this project, the 4 main drivers to migrate to OUD were:

    - native support of EUS (ability to store Oracle DB accounts used by Enterprise User Security) as deployment of EUS was a Corporate decision
    - smooth integration and official support of OUD with the Oracle Identity stack, especially OIM and OAM
    - superior scalability, able to deliver SLA required by new services to be rolled out in the coming years
    - support for global account lockout

About 10,000 applications word-wide access the directory. Among them, 10 were identified as critical for the transition, mostly provisioning applications.


Figure 1: Existing DSEE topology with 4 masters, 6 read-only replicas in each DC + 2 read-only replicas in remote branches

OUD provides several options to transition from DSEE. For this project, the DSEE and OUD topologies have to cohabit for 6 months in production as transition was planned incrementally on a geo basis. Furthermore, client applications heavily relies on password policy, so strong data consistency is required across the 2 topologies during transition. Based on that, tightly-coupled cohabitation via the replication gateway was selected. In addition to that, this strategy provides smooth and incremental transition without interruption of service.

Transition analysis and design was conducted over a period of 1 week. The goal of this critical phase was to adapt schema, configuration and data to OUD, define and automate procedures to deploy an OUD directory server able to deliver a service equivalent to existing DSEE servers in staging area. Business knowledge of directory data was really important during this phase. Transition of the replication topology was also addressed during this phase.


4 OUD servers have been deployed as a directory backbone. Actual roll-out of other OUD servers (20+ servers all over the world) will be performed incrementally over the next months.

2. Transition Analysis and Design

Transition analysis and design heavily relied on the transitioning tools provided with OUD. Transitioning to OUD implies adapting ODSEE configuration (and sometimes the data) to the OUD format.
The OUD delivery provides tools to automatically adapt ODSEE configuration and data. The few configuration elements that can't be adapted automatically are identified by the OUD diagnostic tools and require manual adaptation.

The work was broken down into the following steps:

  1. - Diagnose the DSEE deployment
  2. - Migrate the schema, configuration and data to a reference OUD instance
  3. - Validate configuration and settings
  4. - Deploy additional OUD instances in a replicated topology
  5. - Upgrade 2 DSEE masters in place to ODSEE 11gR1 PS2
  6. - Deploy Replication Gateway to make the link between the 2 topologies
  7. - Use T2P procedure (Test to Production) to roll out server configuration  in production

-

2.1 Diagnosing the DSEE deployment

OUD ships with the ds2oud tool able to diagnose DSEE configuration, schema and existing user data. You can use this tool to identify areas that are likely to require special attention during the transition.
Many of the differences spotted by this tool can be automatically migrated, especially those related to schema and server configuration. Others issues, related to advanced server configuration and user data requires manual intervention as they often require business knowledge or architectural decisions.

In order to run this tool, you must have administrative access to one running DSEE instance. For sake of security, one additional DSEE master server was deployed specifically for that purpose so that production systems are not impacted at all by this diagnostic phase.

2.2 Migrating the schema, configuration and data to a reference OUD instance


LDAP Schema
LDAP schemas were compared first. Custom schema extensions were properly imported to the OUD side. However, we faced a couple of issues with some experimental schemas, e.g. RFC 2307: OUD ships with the latest versions of the RFCs, but in this case, DSEE was using an older and incompatible version of the schema. A huge amount of existing LDAP entries were relying on the older schema, so we decided to use this old schema on OUD too.

Server Configuration
We also used ds2oud to migrate the server configuration. The -F option is used to produce a batch file containing a list of configuration changes to be applied to the OUD directory server. This batch file was reused to setup subsequent OUD servers during server roll-out.


Global parameters, database suffixes, indexes, global password policy were migrated automatically.

Note: Support of global password policy and account lockout during cohabitation of DSEE and OUD via the replication gateway requires that DSEE use the 'DS6' password policy mode. For this deployment, the DSEE topology was already using this mode, so no additional action was required on that side.

User Data
For this project, most of the transition effort was related to user data migration: LDAP was deployed more than 15 years ago. LDAP entries were provisioned over time by a huge variety of applications. The number of provisioning applications is now quite limited. However, it appeared that about 5% of the LDAP entries did not strictly conform to the LDAP schema and/or to the LDAP standard.  By default, OUD strictly enforce the LDAP standard and the LDAP schema, including attribute value syntax check. DSEE does not check attribute value syntax.

Based on that, it was decided to use that transition project to conduct a detailed data assessment and sanitization. This assessment was completed over the 1 week period as originally planned. However, it required involvement of additional stakeholders to figure out whether entries that did not match the LDAP schema were correct or incorrect from a business and application perspective.

Here are a few road blocks hit and addressed:

- Most LDAP entries contained more than one structural LDAP object class
    This non-standard setting is accepted by ODSEE but by default, it is rejected by OUD. That check was relaxed on OUD because applications creating these entries could not be modified.
- Some entries contained attribute type extensions (e.g criteria:criteria;x-custom-extension) that violate LDAP standards because they contain underscores.
    That check was relaxed on OUD as well
- Some DNs and telephoneNumber attributes contain incorrect values
    These values were cleaned up on DSEE.

Directory Metadata
The transition strategy chosen is based on the replication protocol. It provides strong data consistency and all data including directory metadata are replicated back and forth between DSEE and OUD.
For that project, directory metadata, mainly access controls, could be replication w/o any problem, However, we had to adapt directory metadata related to account-based resource limits settings:

Some DSEE entries contain the following resource limit attributes, namely nsSizeLimit, nsTimeLimit, nsLookThroughLimit, nsIdleTimeout. Corresponding attributes on OUD are ds-rlim-size-limit, ds-rlim-time-limit, ds-rlim-lookthrough-limit,ds-rlim-idle-time-limit. In order to replicate the functionality correctly, the OUD schema was modified so that each DSEE attribute name related to resource limits is declared as an alias name for each corresponding OUD attribute.

2.3 Validating OUD Configuration and Settings

A few OUD servers were deployed in staging area and configured as defined above. Then traffic from key customer applications identified during the transition assessment was redirected to the OUD infrastructure.

This phase is very important to validate the changes above and identify behavioral differences between OUD and DSEE that are not always detected automatically. We detected a few problems that required additional configuration changes on the OUD side. These changes were added to the list of configuration to be applied to OUD servers.

Here are a few road blocks hit and how we addressed them:

- Few applications were performing unindexed operations. By default, OUD reject such searches.
     For technical reasons, it was not acceptable to create the appropriate indexes to suppress unindexed searches: For this project, we recommend to disable privileges leading to aci behavioral differences between OUD and ODSEE.
- Attributes present in the rootDSE and in the schema are flagged as operational, so they are not returned to client applications unless they are explicitly specified in the search attribute list. On ODSEE, these attributes are systematically returned.        
    Client applications relied on the DSEE behavior; we had to modify the OUD configuration so that rootDSE entries are returned like user attributes
- By default, in OUD, unauthenticated users are not granted access to cn=schema nor the rootDSE.
    Appropriate access controls was added to OUD


2.4 Deploy additional instances in a replicated topology

In such medium/large replication topology, it is advisable to separate the directory server and replication server instances into separate JVMs, and to limit the number of replication servers:

- 4 instances having both Directory server and Replication Server roles are deployed, 2 in each data center.
- The number of directory server instances serving search operations could be reduced to 4 due to superior OUD performances. 
- 2 replication groups are defined so that DSs in one data center preferably connect to a RS within the same data center.
- 2 directory servers deployed in remote branches are configured as read-only replicas to conform to corporate rules. These 2 servers can connect to replication server from either data center to receive updates.

Note: Unlike DSEE topology, every directory server running in the main data centers are read-write master. The corresponding servers in DSEE handled a limited write traffic that was redirected to DSEE masters via referrals. The new OUD topology eliminates the need for referrals.

Figure 2: New OUD topology with 4 RS+DS, 4 DS in each DC + 2 read-only DS in remote branches

3 Deploying the OUD topology

The main outcome of the transition analysis and design phase is a collection of commands to be applied to set up an OUD directory server instance.
Additional OUD directory server instances were setup then configured. The Test to Production feature provided by OUD is used to clone configurations to pre-production environment.

Data are exported from DSEE (with the --opends flag) to preserve replication metadata, so that replication can be established between the 2 environments. Data are imported in a single OUD directory server, then replication was enabled between servers and database files are copied to the other servers. In the customer environment, this initialization strategy was preferred over an over-the-network full initialization.

The minimum version required for tightly coupled coexistence is ODSEE 11g Release 1 (11.1.1) for the ODSEE master that communicates directly with the replication gateway. However, the rest of the ODSEE topology does not need to be uniformly based on this version and remain in 6.x, so we upgraded 2 DSEE masters to the latest ODSEE 11gR1 PS2 (11.1.1.7.0). Instances were automatically upgraded in place without having to copy, export or import anything. An alternate solution would have been to deploy 2 new ODSEE 11g instances as replication gateway companion.

At that stage, 2 replication gateways are deployed as described in the OUD administration guide. This is the recommended setting to avoid single point of failure.

Backup strategy was adapted to reflect the new hybrid topology: In a replicated environment involving ODSEE and OUD, you must perform regular backups on the ODSEE side and on the OUD side. A backup must always be restored in the topology it is associated with.


Figure 3: Cohabitation DSEE/OUD

The current plan is to keep the DSEE-OUD cohabitation for 6 months as applications are progressively redirected to OUD.

4 Conclusion

Tightly coupled coexistence of OUD with ODSEE is achieved by deploying OUD and ODSEE in a replicated topology using the “Replication Gateway”. The replication gateway provides out-of-the-box live transition without service interruption.
This enables you to run OUD and DSEE in parallel in a mixed environment so that you can transition to OUD over time, validate your upgrade strategy application by application, and most importantly, without downtime.

Migration tools shipped with OUD addresses most of the transitioning issues. However, data cleaning and/or manual adaptation is sometimes required during this process, so some time should be allocated to address that during the transition analysis and design.


Monday Jan 27, 2014

OUD 11gR2PS2 (11.1.2.2) available

Oracle Unified Directory 11gR2PS2 (11.1.2.2) is available for download at http://download.oracle.com/otn/nt/middleware/11g/111220/ofm_oud_generic_11.1.2.2.0_disk1_1of1.zip. Other IdM R2PS2 components are available at http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/index.html

Documentation for Oracle Unified Directory (OUD) 11gR2PS2 (11.1.2.2) is available at http://docs.oracle.com/cd/E49437_01/index.htm

Certification matrix is available at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/identity-access-111220certmatrix-2105036.xlsx

Wednesday Jan 22, 2014

Migrating DSEE database indexes to OUD

Many DSEE customers declare database indexes by writting directly to the DSEE server configuration. For instance, the following LDIF sniplet creates a presence & equality index for attribute employeeNumber in the userRoot database

dn: cn=employeenumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: nsIndex
cn: employeenumber
nsSystemIndex: false
nsIndexType: pres
nsIndexType: eq

It is not recommended to update the OUD configuration directly as this is not a public interface and internal configuration representation may be subject to change. It is recommended to use the dsconfig command line tool. Here is the command equivalent to the index creation above:

dsconfig -h localhost -p <admin port> -D "cn=directory manager" -j <password_file> -X -n \
  create-local-db-index \
  --backend-name userRoot \
  --index-name employeenumber\
  --set index-type:presence\
  --set index-type:equality

More about OUD index creation and management is available at http://docs.oracle.com/cd/E37116_01/admin.111210/e22648/indexing.htm#solINDEX-DATABASES  and http://docs.oracle.com/cd/E37116_01/admin.111210/e22648/managing_data.htm#solTO-CREATE-A-NEW-LOCAL-DB-INDEX

Monday Jan 20, 2014

Using OUD as a WebLogic Authentication Provider

Each WebLogic security realm must have at least one authentication provider configured. The default authentication provider (defaultAuthenticator) uses an embedded LDAP directory server to store user credentials & group membership.

Using an external authentication provider

The file-based embedded LDAP store does not scale when the number of users and group to manae grow. However, many customners favoir a centralized administration for users and groups, so you can declare an external authentication provider. The default authenticator is kept for "emergency" only to store Weblogic administrator in case the external authenticator cannot be reached as it is possible to control authenticator priority and criticality.

OUD as a Weblogic authentication provider

Such use case is certified since WebLogic 10.3.5; OUD can be used to store users and groups. Furthermore, it is possible to export existing users & groups from embedded LDAP to OUD for seamless transition.

When OUD is used an an external authentication provider, it is recommended to disable user lockout provided by WebLogic and rather rely on the password policy provided at the OUD level.

Configuring OUD as an authentication Provider

  1. In the Weblogic Console, go to Security Realms/ RealName/ Providers/ Authentication Page
  2. Click New to add a new Authentication Provider
  3. Enter a name for the provider and choose IplanetAuthenticator as the type
  4. Click OK
  5. In the Security Realms / RealName / Providers/ Authentication page, click the name of the provider you created, and select the Configuration / Provider Specific page
  6. Configure connection attributes for OUD and search bases as appropriate
  7. Update the field labeled GUID Attribute at the bottom of the page to value entryuuid
  8. Click Save

Reusing existing users & groups from embedded LDAP

To export users and groups from embedded LDAP:

First, modify credentials of the embedded LDAP server: Click <Domain> under Domain Structure on the left panel. On the right panel, click Security tab then Embedded LDAP tab, change credentials, Save and restart WebLogic

Then, perform a LDAP search on the Weblogic port as cn=admin using above credentials e.g.

ldapsearch -p 7001 -D "cn=admin" -w <password> -b "ou=myrealm,dc=<domain>" "(|(objectclass=wlsUser)(objectclass=groupOfURLs)(objectclass=groupOfUniqueNames))

Here is an exemple of entries:

dn: cn=Administrators,ou=groups,ou=myrealm,dc=dom memberURL:ldap:///ou=groups,ou=myrealm,dc=dom??sub?(&(objectclass=per son)(wlsMemberOf=cn=Administrators,ou=groups,ou=myrealm,dc=dom))
objectclass
: groupOfURLs cn: Administrators


dn: uid=weblogic,ou=people,ou=myrealm,dc=dom
objectclass
: inetOrgPerson
objectclass
: organizationalPerson
objectclass
: person
objectclass
: wlsUser
cn
: weblogic
sn:
weblogic
userpassword
: {ssha}5ZFkp4qHIzfrGe8AV3naJOndwzTXC2W/
wlsMemberOf: cn=Administrators,ou=groups,ou=myrealm,dc=dom

By default, user entries are stored in oud=people while groups are stored in ou=groups in the embedded LDAP server. As you can see, the search base in the LDAP URL defining dynamic groups (e.g. Administrators) is incorrect as it searches user entries in the group container. This must be changed prior to importing entries in OUD to the following value:


memberURL:ldap:///ou=people,ou=myrealm,dc=dom??sub?(&(objectclass=per son)(wlsMemberOf=cn=Administrators,ou=groups,ou=myrealm,dc=dom))

To import entries in OUD,

  1. extend OUD schema with wlsUser objectclass and wlsmemberOf attribute
    Note that I've not found the official oid for wlsmemberOf and wlsUSer so I 've used fake oid in the schema below

    attributeTypes: ( 1.3.6.1.4.1.1000 NAME ('wlsMemberOf') SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'WLS')
    objectclasses: (1.3.6.1.4.1.1001 NAME 'wlsUser' SUP top MAY (wlsMemberOf) X-ORIGIN 'WLS')
  2. Create suffix holding oud=<myreal>,dc=<domain>
  3. Allow pre-encoded password import in OUD
    dsconfig set-password-policy-prop --policy-name Default\ Password\ Policy --set allow-pre-encoded-passwords:true
  4. Allow multiple structural objectclasses per entry in OUD
    dsconfig set-global-configuration-prop --set single-structural-objectclass-behavior:accept
  5. Import entries in OUD using dsimport

Optimizing Group membership evaluation

Weblogic can determine group membership based on a configurable attribute present in user entries. If not set in the provider specific configuration (User Dynamic Group DN property), it determines membership by evaluating the URLs present in the dynamic group.

This property can be set to isMemberOf as this attribute is provided OOTB by OUD. It can also be set to wlsMemberOf when every dynamic group used is based on this attribute.


Tuesday Jan 14, 2014

Transition from DSEE to OUD: Top 5 tips

The ds2oud tool can be used to migrate DSEE configuration to OUD. However, a few additional OUD configuration changes might be required on a case by case basis to provide seamless transition for applications.

Here are the top 5 differences spotted during real transition projects and how to address them:

#1 Syntax checking

DSEE does not check attribute value syntax. OUD does, so attribute values must conform to the attribute syntax defined in the schema. For instance, an attribute with Boolean syntax can hold TRUE or FALSE values only. Ideally, data should be fixed by the customer. However, this is not always possible and takes time. Furthermore, somne client application may rely on the incorrect data.

To disable attribute value syntac checking on OUD, the invalid-attribute-syntax-behavior property in the global configuration  can be changed to 'warn' or accept

#2 Structural objectclasses

Every user entry must have exactly one STRUCTURAL object-class to conform to Directory Standards. If a ODSEE entry has 0 or more than one structural object-class, the entry would be rejected during an import. ODSEE does not differentiate between the two object-class types, so this kind of schema inconsistency is commonly found in real deployments. It is recommended that you fix such user entries on the ODSEE side before transitioning to OUD.

Alternatively, you can disable this schema checking  as described in https://blogs.oracle.com/sduloutr/entry/cohabitation_odsee_oud_schema_checking

# Schema and root DSE access

The root DSE entry (empty DN) and the schema entry (cn=schema) contains several operational attributes. DSEE systematically returns these attributes even when the client application does not list them explilcitely in the search attribute list. This does not conform to the LDAP standard. By default OUD does not return them. However, it is possible to configure OUD to behave like DSEE using the procedure described in https://blogs.oracle.com/sduloutr/entry/oracle_unified_directory_root_dse

#4 Unindexed searches

By default, OUD does not allow unindexed searches as they may impact overall directory services performances. DSEE does.
It is recommended to limit the number of unindexed searches by creating additional indexes. However, unindex searches are valid patterns in some specific situations.
It is possible to grant unindexed search privilege on a per user account basis as described in https://blogs.oracle.com/sduloutr/entry/cohabitation_migration_odsee_oud_privileges

#5 Anonymous access

By default, DSEE accepts requests with DN and no passsword. Such requests are processed as anonymous.
By default, OUD rejects such requests. This behaviour can be changed by setting the property bind-with-dn-requires-password to false in the global OUD configuration

Don't forget to have a look at the additional OUD KM notes available on OTN . They can be accessed as described in https://blogs.oracle.com/sduloutr/entry/how_to_subscribe_my_oracle
About


I am Sylvain Duloutre, I work as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
31
 
       
Today