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

Thursday Oct 17, 2013

Using EUSM to manage EUS mappings in OUD

EUSM is a command line tool that can be used to manage the EUS settings starting with the 11.1 release of Oracle. In the 11.1 release the tool is not yet documented in the Oracle EUS documentation, but this is planned for a coming release.

The same commands used by EUSM can be performed from the Database Console GUI or from Grid Control*.

For more details, search for the document ID 1085065.1 on https://support.oracle.com/epmos/faces/DocumentDisplay?id=1085065.1.

The examples below don't include all the EUSM options, only the options that are used by EUS.

EUSM is user friendly and intuitive. Typing eusm help <option> lists the parameters to be used for any of the available options. Here are the options related to connectivity with OUD :

ldap_host="gnb.fr.oracle.com" - name of the OUD server.
ldap_port=1389 - nonSSL (SASL) port used for OUD connections. 
ldap_user_dn="cn=directory manager" - OUD administrator name
ldap_user_password="welcome1" - OUD administrator password

Find below common commands:

To List Enterprise roles in OUD
eusm listEnterpriseRoles domain_name=<Domain> realm_dn=<realm> ldap_host=<hostname> ldap_port=<port> ldap_user_dn=<oud administrator> ldap_user_password=<oud admin password>

To List Mappings
eusm listMappings domain_name=<Domain> realm_dn=<realm> ldap_host=<hostname> ldap_port=<port> ldap_user_dn=<oud admin> ldap_user_password=<oud admin password>

To List Enterprise Role Info
eusm listEnterpriseRoleInfo enterprise_role=<rdn of enterprise role> domain_name=<Domain> realm_dn=<realm> ldap_host=<hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password=<oud admin password>

To Create Enterprise Role
eusm createRole enterprise_role=<rdn of the enterprise role> domain_name=<Domain> realm_dn=<realm> ldap_host=<hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password=<oud admin password>

To Create User-Schema Mapping
eusm createMapping database_name=<SID of target database> realm_dn="<realm>" map_type=<ENTRY/SUBTREE> map_dn="<dn of enterprise user>" schema="<name of the shared schema>" ldap_host=<oud hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password="<oud admin password>"

To Create Proxy Permission
eusm createProxyPerm proxy_permission=<Name of the proxypermission> domain_name=<Domain> realm_dn="<realm>" ldap_host=<hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password=<oud admin password>

To Grant Proxy permission to Proxy group
eusm grantProxyPerm proxy_permission=<Name of the proxy permission> domain_name=<Domain> realm_dn="<realm>" ldap_host=<hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password=<password> group_dn="<dn of the enterprise group>"

To Map proxy permission to proxy user in DB
eusm addTargetUser proxy_permission=<Name of the proxy permission> domain_name=<Domain> realm_dn="<realm>" ldap_host=<hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password=<oud admin password> database_name=<SID of the target database> target_user=<target database user> dbuser=<Database user with DBA privileges> dbuser_password=<database user password> dbconnect_string=<database_host>:<port>:<DBSID>

Enterprise role to Global role mapping

eusm addGlobalRole enterprise_role=<rdn of the enterprise role> domain_name=<Domain> realm_dn="<realm>" database_name=<SID of the target database> global_role=<name of the global role defined in the target database> dbuser=<database user> dbuser_password=<database user password> dbconnect_string=<database_host>:<port>:<DBSID> ldap_host=<oid_hostname> ldap_port=<port> ldap_user_dn="<oud admin>" ldap_user_password=<oud admin password>


Thursday Oct 03, 2013

Reusing passwords encoded with custom hash in OUD

Existing user passwords can be easily migrated to OUD as long as they are hashed with an algorithm supported OOTB by Oracle Unified Directory. The list of password storage schemes supported by OUD is available at http://docs.oracle.com/cd/E22289_01/html/821-1278/password-storage-scheme.html

In some situations, legacy passwords to be migrated are hashed with custom algorithms or old hash algorithms not supported by OUD.  The OUD Extensible Framework can be used to reuse these passwords and migrate them transparently to a new & configurable password storage scheme, without forcing users to change their password.

The proposed plugin intercepts bind requests and add pre&post processing to handle custom algorithm and migrate the password to a new scheme. Here is the high level algorithm:

§1. Plugin intercepts LDAP bind request as a pre-operation plugin

§2. Determine if the password stored in the user entry has a custom hash tag e.g {Custom}

§3a. If the entry has the custom hash, then hash the clear text password provided by the LDAP client using the custom password hash.

§3b. If the entry does not have the custom hash, the skip to step 6

§4. Compare the hashed value computed from the clear text password with the custom hash contained in the entry.

§5. If the hash compare matches, then replace the existing custom hashed password with the hash algorithm defined by the default password hash storage scheme.

§6. Then pass the bind through to OUD to bind.

§7. OUD will hash the clear text value using the default password hash storage scheme and compare with the value in the directory.

Step 6 always forwards the bind request to the OUD core server to make sure the password policy states are properly updates.

User passwords are migrated progressively over time to the new password storage scheme as users authenticate to the OUD directory. The plugin can them be desactivated when all the passwords have been migrated.


Thursday Aug 19, 2010

Using ODSEE Directory Proxy Server with Oracle Internet Directory (OID)

The DPS 6.x and 7.x default configuration must be slightly changed to be able to work smoothly with OID. Indeed, the DPS health-check engine might compute OID operational state incorrectly and consider OID down when it is up and running.

There are 2 ways to fix that: either disable the proactive health-check monitoring or (recommended) change the LDAP query done to determine the backend operational state. To do so, make sure DPS is running and launch the command below on each ldap data source associated with an OID instance:

dpconf set-ldap-data-source-prop <data source> monitoring-search-filter:(objectclass=\*)

Note: this configuration is not specific to OID and works well with other directory server instances, including DSEE.

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
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
9
10
11
12
13
14
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today