X

Recent Posts

Oracle Unified Directory Services (OUD)

Oracle E-Business Suite certified with Unified Directory

Oracle Unified Directory 11gR2 Patchset 3 (11.1.2.3.0) is now certified for use with Oracle E-Business Suite Release 12.2.Oracle Unified Directory 11gR2 Patchset 3 (11.1.2.3.0) (along with Directory Integration Platform 11gR1 Patchset 7 (11.1.1.9.0)) can be integrated with Oracle Access Manager 11gR2 Patchset 3 (11.1.2.3) as a single sign-on solution.For availability and other information on Oracle Unified Directory, refer to the articles listed in the documentation section below.My Oracle Support Knowledge Document 2003483.1 - Integrating Oracle E-Business Suite Release 12.2 with Oracle Unified Directory 11gR2  My Oracle Support Knowledge Document 1576425.1 - Integrating Oracle E-Business Suite Release 12.2 with Oracle Access Manager 11gR2 (11.1.2) using Oracle E-Business Suite AccessGate My oracle Support Knowledge Document 1388152.1 - Overview of Single Sign-On Integration Options for Oracle E-Business Suite Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management 11g Release 2 (11.1.2) (E27301-04) Oracle Fusion Middleware Installation Guide for Oracle Unified Directory 11g Release 2 (11.1.2) (E23737-02) Oracle Fusion Middleware Installing Oracle Unified Directory 11g Release 2 (11.1.2) (E56132-02) Oracle Fusion Middleware Installation Guide for Oracle Identity Management 11g Release 1 (11.1.1.9.0) (E12002-13) Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2)(E22648-02) Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform (E56469-01) Oracle Fusion Middleware Patching Guide 11g Release 1 (11.1.1.9.0) (E16793-28)

Oracle Unified Directory 11gR2 Patchset 3 (11.1.2.3.0) is now certified for use with Oracle E-Business Suite Release 12.2.Oracle Unified Directory 11gR2 Patchset 3 (11.1.2.3.0) (along with Directory...

Oracle Unified Directory Services (OUD)

Migration from OID to OUD: Adapting EUS metadata

Enterprise User Security is an important component of Oracle Database Enterprise Edition. It enables you to address administrative and security challenges for a large number of enterprise database users by centralizing users and roles in a LDAP directory.It is possible to use either Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) as LDAP repository for EUS.To migrate from OID to OUD, - enable EUS support in OUD- copy your user and groups in <your_context)- copy across EUS metadata (in cn=oracleContext,<your suffix) EUS metadata as stored in OID must be slighly adapted before being impoorted to OUD otherwise the DB won't be able to authenticate against OUD and will raise the following error: ORA-28043: invalid bind credentials for DB-OID connection Migrating the DB entry from OID to OUD requires some specific steps for SASL/DIGEST-MD5 authentication. In OID, the password hash used for SASL/DIGEST-MD5 authentication is stored in authpassword;oid, with the {SASL/MD5} prefix. In OUD, this must be stored in orclcommonrpwdattribute with the {SASL-MD5} prefix. For instance: In OID: ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one "(cn=orcl11g)" authpassword dn: cn=orcl11g,cn=oraclecontext,dc=example,dc=com authpassword;oid: {SASL/MD5}ola+G+GFsSeiu6QcRiAh9g== authpassword;oid: {SASL/MD5-DN}3UeqmU5Axd+XVAM9Lxf28g== authpassword;oid: {SASL/MD5-U}BD6uyBcSiFbGtlPzq6TtUA== In OUD: ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one "(objectclass=orcldbserver)" orclcommonrpwdattribute dn: cn=orcl11g,cn=OracleContext,dc=example,dc=com orclcommonrpwdattribute: {SASL-MD5}ola+G+GFsSeiu6QcRiAh9g==

Enterprise User Security is an important component of Oracle Database Enterprise Edition. It enables you to address administrative and security challenges for a large number of enterprise database...

Oracle Unified Directory Services (OUD)

Integrating OUD in Monitoring Frameworks: Service Users

Oracle Unified Directory is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities.It can be monitored and integrated in various Monitoring Solutions including Oracle Enterprise Manager, via a dedicated plugin that provides performance monitoring of hundreds of directory metrics, raise alerts based on thresholds and provides rich out-of-the-box reports. By default, monitoring data are retrieved from OUD over LDAPS from the OUD administration port. In order to use this method, it is recommended to define a dedicated directory user with read privilege on monitoring statistics and configuration. Such user can either be a so-called Root User or a Global Admin User. Root Users are local to a OUD instance and have some special privileges. Global Admin Users are quite similar to Root Users except that they are replicated across OUD servers, so this is more convenient if you want to monitor several OUD instances.The following rights and privileges are required to access monitoring data and config:  Read access on cn=config and cn=monitor naming contexts and config-read privilege. Root Users automatically inherit a bunch of default privileges, much more than what is strictly needed to monitor OUD, so unnecessary privileges must be removed and read access must be granted. To create a Root User called "cn=monitor" with sufficient privileges , do the following ./ldapmodify  -h <hostname> -p <adminport> \-D "cn=Directory Manager" -w <password> -X --useSSL  <<EOFdn : cn=monitor,cn=Root DNs,cn=configchangetype: addobjectclass: inetOrgPersonobjectclass: personobjectclass: ds-cfg-root-dn-userobjectclass: topuserPassword: <password>ds-cfg-alternate-bind-dn: cn=monitorcn: monitorsn: monitorEOF Let's remove unnecessary privileges (basically all but config-read) ./ldapmodify  -h <hostname> -p <adminport> \-D "cn=Directory Manager" -w <password> -X --useSSL <<EOFdn : cn=monitor,cn=Root DNs,cn=configchangetype: modifyadd: ds-privilege-nameds-privilege-name: -config-writeds-privilege-name: -modify-aclds-privilege-name: -ldif-importds-privilege-name: -ldif-exportds-privilege-name: -backend-backupds-privilege-name: -backend-restoreds-privilege-name: -server-shutdownds-privilege-name: -server-restartds-privilege-name: -disconnect-clientds-privilege-name: -cancel-requestds-privilege-name: -unindexed-searchds-privilege-name: -password-resetds-privilege-name: -update-schemads-privilege-name: -privilege-changeds-privilege-name: -bypass-aclEOF If you prefer to use Global Admin Users, do the following: ./ldapmodify  -h <hostname> -p <adminport> \ -D "cn=Directory Manager" -w <password> -X --useSSL <<EOFdn : cn=monitor,cn=Administrators,cn=admin datachangetype: addobjectclass: personobjectclass: topuserPassword: <password>cn: monitorsn: monitorEOF Let's add config-read privilege: ./ldapmodify  -h <hostname> -p <adminport> -D "cn=Directory Manager" -w <password> -X -Z <<EOFdn : cn=monitor,cn=Administrators,cn=admin datachangetype: modifyadd: ds-privilege-nameds-privilege-name: config-readEOF No matter what User type you choose to use, you need to grant read access to the config and the monitoring information using OUD global acis:For Root Users, add the following acis using dsconfig: Start dsconfig, select Authentication and Authorization, then Access Control Handler and add the 2 following global acis: (target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \ userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";)(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \ userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";)  For Global Admin Users, here are the corresponding acis: (target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \ userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";) (target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \ userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";)  At that stage, config and monitoring stats are available from the OUD admin port to the cn=monitor user (if you choose to use Root Users) or to cn=monitor,cn=administrators,cn=admin data (for Global Admins).:

Oracle Unified Directory is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities.It can be monitored and integrated in various Monitoring Solutions ...

Oracle Unified Directory Services (OUD)

OUD Directory Server vs Replication Server: Who Cares ?

Oracle Unified Directory replication model relies on 2 logical components, Directory Servers and Replication Servers.Directory Servers contain user data, pushes changes to replication changed and get updates from replication servers.Replication Server stores replication changes, they receive changes to directory servers and forward them to the rest of the topology.By default, you don't need to care about Replication Servers. Replication Servers and internal components managed automatically: a Replication Server is autimatically configured in each OUD DIrectory Server process when replication is configured.OUD Replication Server and Directory Servers are NOT equivalent to DSEE Suppliers and Consumers. By default, every replicated OUD is a Read-Write Supplier/Master.When do you need to know about replication servers? - Primarily, when full network connectivity cannot be guarantied across every instance as every Replication Server must be able to communicate to each other. - Optionally, Replication Servers and DIrectory Servers can be separated to optimize resource usage in large OUD topologies (10's of instances)- To enable external changelog service on a standalone OUD instance (for instance in a test environment) as a Replication Server is required is such case.Example:

Oracle Unified Directory replication model relies on 2 logical components, Directory Servers and Replication Servers.Directory Servers contain user data, pushes changes to replication changed and get...

Oracle Unified Directory Services (OUD)

Global Administrators with a subset of Admin Privileges

Oracle Unified Directory provides one default root DN or root user, "cn=Directory Manager". The default root DN is a user entry assigned with specialized privileges with full read and write access to all data in the server. Comparable to a Unix root user or superuser, the root DN can bypass access controls to carry out tasks on the server. The root user is defined below the "cn=Root DNs,cn=config" branch of the server atcn=Directory Manager,cn=Root DNs,cn=config. and is local to each OUD instance.  The server supports multiple root users who have their own entries and their own set of credentials on the server. OUD also provides the notion of global administrators. Global Administrators are responsible for managing and maintaining administrative server domains in replicated environments. One Global Administrator is created when you set up replication servers using the graphical installer or the dsreplication command (you are prompted to set a user name and password for the Global Administrator) .  The Global Administrator created for the replication exists in the cn=Administrators,cn=admin data subtree, so it is replicated and can be used with every OUD instance of a replicated topology. To view the Global Administrator entry, run the following ldapsearch command: $ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ --useSSL -b "cn=Administrators,cn=admin data" -s sub "(objectclass=*)"dn: cn=Administrators,cn=admin dataobjectClass: topobjectClass: groupofurlsdescription: Group of identities which have full access.cn: AdministratorsmemberURL: ldap:///cn=Administrators,cn=admin data??one?(objectclass=*)dn: cn=admin,cn=Administrators,cn=admin dataobjectClass: personobjectClass: topuserPassword: {SSHA}+ed1wbhcWjxtv2zJ6OHEA2TuE9n1qIJGnuR94w==description: The Administrator that can manage all the OUD instances.cn: admin  The Global Administrator created for the replication exists has the full set of admin privileges. In some situations, it might be useful to create additional administrators having only a subset of admin right. For instance, a Monitor Administrator would have the privilege to read the OUD configuration but he/she would not be able to modify it. To do so, you can create your own admin container node in the cn=admin data suffix ./ldapmodify -a -p 4444 -Z -X -D "cn=directory manager"  -w ****dn: cn= my admins,cn=admin dataobjectclass: topobjectClass: ds-cfg-branchdn: cn=monitor,cn=my admins,cn=admin dataobjectClass: personcn: monitorsn: monitor userpassword: **** At that stage, it is possible to use these credentials (cn=monitor,cn=my admins,cn=admin data) with dsconfig. dsconfig can authenticate that user, however the "admin" won't be able to read the config as he/she does not have the privilege to do so. dsconfig reports the following error during navigation in the config: The Administration Connector could not be modified because you do not have the correct authorization Appropriate privileges must be assigned to the admin so that he/she has the right to perform the desired actions. In that example, the admin requires the config-read privilege. The bypass-acl is also required so that he/she can perform privileged actions on the configuration. ./ldapmodify -p 4444 -Z -X -D "cn=directory manager"  -w ****dn: cn=monitor,cn=my admins,cn=admin datachangetype: modifyadd: ds-privilege-nameds-privilege-name: bypass-aclds-privilege-name: config-read Now the admin can read the config via dsconfig. However, any attempt to modify it would raise the following error: The Configuration could not be modified because you do not have the correct authorization 

Oracle Unified Directory provides one default root DN or root user, "cn=Directory Manager". The default root DN is a user entry assigned with specialized privileges with full read and write access to...

Oracle Unified Directory Services (OUD)

Configuring OUD to Support Multiple Enterprise User Security Domains

ConfiguringOUD to Support Multiple Enterprise User Security DomainsIf your users and groups are stored inmultiple domains, you must configure OUD to support multiple EUSdomains. Forexample, a single OUD instance contains two EUS domains. One EUS domainstores users entries in Active Directory below cn=users,dc=ad1,dc=com. A second EUS domainstores user entries in a different Active Directory instancebelow cn=users,dc=ad2,dc=com. You must configureOUD to support each EUS domain.To configure OUD to support multipleEUS domains:ConfigureOUD as if the primary domain is the single domain containingall your users and groups.In thisexample, the primary domain is dc=ad1,dc=com.Completethe tasks in 28.4 Oracle UnifiedDirectory Used as a Proxy Server for an External LDAPDirectory with Enterprise User SecurityConfigurethe secondary domain.In thisexample, the secondary domain is dc=ad2,dc=com.For thissecondary domain, complete the steps in 28.4.1.1 User Identitiesin Microsoft Active DirectoryCreate anew naming context for the EUS domain, which is dc=ad2,dc=com in thisexample.Complete thesteps in 28.4.2.1.2toconfigure Enterprise User Security for an existing OracleUnified Directory Proxy Server instance.Updatethe Oracle context with the new naming context.Createan LDIF file.Inthe following myconfig.ldif example,make the following substitutions:Replace dc=ad1,dc=com withthe DN of your first domain.Replace orclcommonusersearchbase withthe users location in the secondary domain.orclcommongroupsearchbase withthe groups location in the secondary domain.dn: cn=Common,cn=Products,cn=OracleContext,dc=ad1,dc=comchangetype: modifyadd: orclcommonusersearchbaseorclcommonusersearchbase: cn=users,dc=ad2,dc=comorclcommongroupsearchbase: cn=groups,dc=ad2,dc=comUpdateOUD configuration using the LDIF file you created instep 4a.ldapmodify -h oudhost -p 1389 -D "cn=directory manager" -w password -f myconfig.ldif

id="1680" class="segment">Configuring OUD to Support Multiple Enterprise User Security Domains id="1681" class="segment">If your users and groups are stored inmultiple domains, you must configure OUD...

Oracle Unified Directory Services (OUD)

OUD and Referral Management with AD

Oracle Unified Directory(OUD) can be configured as a proxy to Active Directory (AD).For instance, it is possible to define a Remote LDAP Extension in OUD pointging to Root Catalog of AD 2008. Searches to AD would return referrals, so the appropriate OUD Network group can to be modified to  follow referrals automatically with the command below: /dsconfig -h localhost -p 4444 -D "cn=directory manager" -j ~/.pwd  -X -n set-network-group-qos-policy-prop --group-name network-group --policy-type referral --set referral-policy:follow In some cases, a ldapsearch with a basedn which is not local to the root catalog still returns referrals to another AD Server. OUD reports the following error: SEARCH operation failedResult Code:  1 (Operations Error)Additional Information:  Unable to process the operation because a referral leading to an unknown or disabled ldap-server example.com:389 was received This error is specific to AD because AD builds referrals as follow: ldap://example.com/CN=Configuration,DC=example,DC=com.  Example.com does not systematically correspond to a LDAP host declared in the OUD proxy configuration. For security reasons, OUD follows referrals to hosts explicitely declared as LDAP server extensions in the OUD proxy configuration.To make sure OUD is able to chase referrals, define a new ldap-server-extension with remote-ldap-server-address property set to example.com and remote-ldap-server-port set to 389. In this case, creation of a proxy workflow element is not required for this ldap-server-extension. More on ldap-server extensions at http://docs.oracle.com/cd/E29407_01/admin.111200/e22648/proxy_config.htm#solCREATING-AN-LDAP-SERVER-EXTENSION

Oracle Unified Directory(OUD) can be configured as a proxy to Active Directory (AD). For instance, it is possible to define a Remote LDAP Extension in OUD pointging to Root Catalog of AD 2008. Searches...

Oracle Unified Directory Services (OUD)

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 mappingsIf 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;

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...

Oracle Unified Directory Services (OUD)

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 \ --setsource-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.

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...

Oracle Unified Directory Services (OUD)

Using OUD Transformations to expose Operational attributes as Regular ones

Some (badly written) LDAP client applications expect to get operational attributes along with regular attributes when they search the directory w/o specifying attributes explicitely. The LDAP standards specify that operation attributes have to be explicitely requested in the search request. Alternatively, the special character + can be used to retrieve all the operational attributes w/o specifying explictely one by one. OUD adheres to the LDAP standard, so operational attributes must be explicitely specified in a search request. A specific option to facilitate migration from other directories can be used to expose schema related attributes (objectclasses, attributeTypes) as regular attributes. This option is described in one of my posts at https://blogs.oracle.com/sduloutr/entry/oracle_unified_directory_root_dse However, others operational attributes are not exposed. Don't worry, OUD transformations framework can help you to solve this specific integration problem:Say you have an client application that expects the (operational)  pwdChangedTime attribute to be returned systematically as a user attribute.First, setup a OUD proxy. The client application in question will point to that proxy, but others applications will not be subject to the (non-standard) directory server behaviour.Then create a Add Outbound Transformation as below: dsconfig create-transformation \          --set client-attribute:pwdChangedTime=%pwdChangedTime% \          --type add-outbound-attribute \          --transformation-name Mymap \ Then put that transformation to a transformation workflow element: dsconfig create-workflow-element \          --set enabled:true \          --set next-workflow-element:userRoot\          --set transformation:myMap \          --type transformations \          --element-name myTransfo \ Insert your transformation workflow element to the appropriate workflow: dsconfig set-workflow-prop \          --workflow-name workflow1 \   --set workflow-element:myTransfo \  Update the OUD Proxy schema, so that the pwdChangedTime is no longer declared as Operational. All you need to do is remove the  Usage DirectoryOperation and the NO-USER-MODICATION flag. Either modify the schema via LDAP or use the procedure below:stop the OUD proxycopy default schema cp <OUD_HOME>/config/schema/01-pwpolicy.ldif <OUD_PROXY_INSTANCE>/OUD/config/schema edit <OUD_PROXY_INSTANCE>/OUD/config/schema and change the pwdChangedTime definition as below:  attributeTypes: ( 1.3.6.1.4.1.42.2.27.8.1.16 NAME 'pwdChangedTime'  DESC 'The time the password was last changed' EQUALITY generalizedTimeMatch  ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24  SINGLE-VALUE  X-ORIGIN 'draft-behera-ldap-password-policy' ) restart the OUD proxy At that stage, pwdChangedTime will be returned by a LDAP search with attribute list set to * or empty. 

Some (badly written) LDAP client applications expect to get operational attributes along with regular attributes when they search the directory w/o specifying attributes explicitely. The LDAP...

Oracle Unified Directory Services (OUD)

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/pythonimport os, sysreadTemplate(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/pythonimport os, sysreadDomain('/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 

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...

Oracle Unified Directory Services (OUD)

Provisioning to OUD using the OIM connector for OUD

OIM provides an extensive list of connectors, including a connector to Oracle Unified Directory (OUD). OIM Connector for OUD is described at http://docs.oracle.com/cd/E22999_01/doc.111/e28603/toc.htm The Lookup.LDAP.UM.ProvAttrMap lookup definition maps process form fields with OUD target system attributes. This lookup definition is used for performing user provisioning operations. For the default user fields that you can specify or modify values during provisioning operations , see Section 1.9.2.2, "User Fields for Provisioning an OUD Target System." For example, the Process Form Field "Common Name" is mapped on cn on the OUD side. Some specific Process Form Fields are mapped differently. For instance the "Login Disabled" Process Form Field is mapped to the __ENABLED__ keyword in the default mapping file. __ENABLED__ does not directly correspond to any OUD attribute. It is a keyword that is associated with an effective OUD attribute in the OUD Connector configuration, as described in http://docs.oracle.com/cd/E22999_01/doc.111/e28603/deploy_oud.htm#CEGDHHHH. The OUD attribute used to store account state is specified  by the enabledAttribute. By default, it is set to ds-pwp-account-disabled. The same indirection mechanism apply to the NsuniqueID and Password Process Form Fields mapped to __UID__ and __PASSWORD__ that are provisionned to the OUD attributes defined by uidAttribute and passwordAttribute (entryUUID and userPassword by default).

OIM provides an extensive list of connectors, including a connector to Oracle Unified Directory (OUD). OIM Connector for OUD is described at http://docs.oracle.com/cd/E22999_01/doc.111/e28603/toc.htm Th...

Oracle Unified Directory Services (OUD)

OUD External change log and rootDSE search

Some LDAP client applications perform subtree searches with search base set to the rootDSE (empty DN). Oracle Unified Directory (OUD) nicely routes the search to every top level suffix automatically. When the replication is enabled, OUD automatically publicizes all changes that have occurred in adirectory server database in the cn=changelog suffix. This is particularly useful for synchronizing the LDAP directory withother subsystems.  The cn=changelog suffix may contains millions of changes depending on the modification rate on the replication topology and the change retention policy (purge delay). Subtree searches with search base set to the rootDSE are routed to the cn=changelog suffix as well as long as the replication is enabled. In general, this is not a problem in testing/stagging area, because the changelog is almost empty. However, in production, this may have big impact on performances as this suffix may contain many entries. Furthermore, custom  indexes corresponding to client access pattern do not exist on that suffix, so they can't be used to speed up entry processing. In order to address that problem, you can disable the so-called external changelog, without disabling the underlying replication changelog used by the replication. To do so, run the following command on the OUD servers for each user suffixes: dsconfig -h <hostname> -p <admin port>  -D "cn=directory manager" -w <admin password> -n \   set-external-changelog-domain-prop \   --provider-name "Multimaster Synchronization" --domain-name <your suffix>  \   --set enabled:false Note: some provisoning apps may require the external changelog to synchronize with external systems. If so, keep the external changelog enabled on a couple of OUD servers and reserve them for these apps.

Some LDAP client applications perform subtree searches with search base set to the rootDSE (empty DN). Oracle Unified Directory (OUD) nicely routes the search to every top level suffix automatically. Wh...

Oracle Unified Directory Services (OUD)

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

I was recently involved in a LDAP directory servicestransition project, from DSEE 6.3.1.1 to OUD 11gR2PS1, for a largemanufacturing 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 CorporateDirectory to Identity Store for Identity Management and user management forintranet and extranet portals. Here is an overview of the steps we followed and the issues we addressed duringthis project to successfully transition the infrastructure to OUD. 1. Transition Assessment Putting in place a sound methodology and design isa key success factor for a directory migration, regardless the final migrationoptions selected.This assessment was conducted over a period of 3 weeks and included thefollowing: - Identification and formalization ofthe main drivers and requirements for transition - Inventory of the current directoryinfrastructure, including identification of the application portfolio accessingthe directory - Identification of transition optionscompatible with requirements - Estimation of transition effort - Identification of trainingrequirement for the staff and skills required during the transition, especiallypeople 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 accountsused by Enterprise User Security) as deployment of EUS was a Corporate decision    - smooth integration and official support of OUD with theOracle Identity stack, especially OIM and OAM    - superior scalability, able to deliver SLA required by newservices 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 wereidentified as critical for the transition, mostly provisioning applications. Figure 1: Existing DSEE topology with 4 masters, 6read-only replicas in each DC + 2 read-only replicas in remote branches OUD provides several options to transition from DSEE. For this project, theDSEE and OUD topologies have to cohabit for 6 months in production astransition was planned incrementally on a geo basis. Furthermore, clientapplications heavily relies on password policy, so strong data consistency isrequired across the 2 topologies during transition. Based on that,tightly-coupled cohabitation via the replication gateway was selected. Inaddition to that, this strategy provides smooth and incremental transitionwithout interruption of service. Transition analysis and design was conducted over a period of 1 week. The goalof this critical phase was to adapt schema, configuration and data to OUD,define and automate procedures to deploy an OUD directory server able todeliver a service equivalent to existing DSEE servers in staging area. Businessknowledge of directory data was really important during this phase. Transitionof the replication topology was also addressed during this phase. 4 OUD servers have been deployed as a directory backbone. Actual roll-out ofother OUD servers (20+ servers all over the world) will be performed incrementallyover the next months. 2. Transition Analysis and Design Transition analysis and design heavily relied on thetransitioning tools provided with OUD. Transitioning to OUD implies adaptingODSEE configuration (and sometimes the data) to the OUD format.The OUD delivery provides tools to automatically adapt ODSEE configuration anddata. The few configuration elements that can't be adapted automatically areidentified by the OUD diagnostic tools and require manual adaptation. The work was broken down into the following steps: - Diagnose the DSEE deployment - Migrate the schema, configurationand data to a reference OUD instance - Validate configuration and settings - Deploy additional OUD instances in areplicated topology - Upgrade 2 DSEE masters in place toODSEE 11gR1 PS2 - Deploy Replication Gateway to makethe link between the 2 topologies - Use T2P procedure (Test toProduction) to roll out server configuration  in production - 2.1 Diagnosing the DSEE deployment OUD ships with the ds2oud tool ableto diagnose DSEE configuration, schema and existing user data. You can use thistool to identify areas that are likely to require special attention during thetransition. 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 architecturaldecisions. In order to run this tool, you must have administrative access to one runningDSEE instance. For sake of security, one additional DSEE master server wasdeployed specifically for that purpose so that production systems are notimpacted at all by this diagnostic phase. 2.2 Migrating the schema, configuration and data to a reference OUDinstance LDAP SchemaLDAP schemas were compared first. Custom schema extensions were properlyimported to the OUD side. However, we faced a couple of issues with someexperimental schemas, e.g. RFC 2307: OUD ships with the latest versions of theRFCs, but in this case, DSEE was using an older and incompatible version of theschema. A huge amount of existing LDAP entries were relying on the olderschema, so we decided to use this old schema on OUD too. Server ConfigurationWe also used ds2oud to migrate the server configuration. The -F option isused to produce a batch file containing a list of configuration changes to beapplied to the OUD directory server. This batch file was reused to setupsubsequent OUD servers during server roll-out. Global parameters, database suffixes, indexes, global password policy weremigrated automatically. Note: Support of global password policy and account lockout duringcohabitation of DSEE and OUD via the replication gateway requires that DSEE usethe 'DS6' password policy mode. For this deployment, the DSEE topology wasalready using this mode, so no additional action was required on that side. User DataFor 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 overtime by a huge variety of applications. The number of provisioning applicationsis now quite limited. However, it appeared that about 5% of the LDAP entriesdid 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 valuesyntax. Based on that, it was decided to use that transition project to conduct adetailed data assessment and sanitization. This assessment was completed overthe 1 week period as originally planned. However, it required involvement ofadditional stakeholders to figure out whether entries that did not match theLDAP schema were correct or incorrect from a business and applicationperspective. 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 applicationscreating these entries could not be modified.- Some entries contained attribute type extensions (e.gcriteria:criteria;x-custom-extension) that violate LDAP standards because theycontain 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 MetadataThe transition strategy chosen is based on the replication protocol. Itprovides strong data consistency and all data including directory metadata arereplicated back and forth between DSEE and OUD. For that project, directory metadata, mainly access controls, could bereplication w/o any problem, However, we had to adapt directory metadatarelated 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 modifiedso that each DSEE attribute name related to resource limits is declared as analias name for each corresponding OUD attribute. 2.3 Validating OUD Configuration and Settings A few OUD servers were deployed in staging area andconfigured as defined above. Then traffic from key customer applications identifiedduring the transition assessment was redirected to the OUD infrastructure. This phase is very important to validate the changes above and identifybehavioral differences between OUD and DSEE that are not always detectedautomatically. We detected a few problems that required additionalconfiguration changes on the OUD side. These changes were added to the list ofconfiguration 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 rejectsuch searches.     For technical reasons, it was not acceptable to createthe appropriate indexes to suppress unindexed searches: For this project, werecommend to disable privileges leading to aci behavioral differences betweenOUD and ODSEE.- Attributes present in the rootDSE and in the schema are flagged asoperational, so they are not returned to client applications unless they areexplicitly specified in the search attribute list. On ODSEE, these attributesare systematically returned.             Client applications relied on the DSEE behavior; we had tomodify the OUD configuration so that rootDSE entries are returned like userattributes- By default, in OUD, unauthenticated users are not granted access to cn=schemanor the rootDSE.     Appropriate access controls was added to OUD 2.4 Deploy additional instances in a replicated topologyIn such medium/large replication topology, it is advisable to separate thedirectory server and replication server instances into separate JVMs, and tolimit the number of replication servers: - 4 instances having both Directory server and Replication Server roles aredeployed, 2 in each data center. - The number of directory server instances serving search operations could bereduced to 4 due to superior OUD performances.  - 2 replication groups are defined so that DSs in one data center preferablyconnect to a RS within the same data center.- 2 directory servers deployed in remote branches are configured as read-onlyreplicas to conform to corporate rules. These 2 servers can connect toreplication server from either data center to receive updates. Note: Unlike DSEE topology, every directory server running in the maindata centers are read-write master. The corresponding servers in DSEE handled alimited write traffic that was redirected to DSEE masters via referrals. Thenew OUD topology eliminates the need for referrals. Figure 2: New OUD topology with 4 RS+DS, 4 DS in eachDC + 2 read-only DS in remote branches 3 Deploying the OUD topology The main outcome of the transition analysis anddesign phase is a collection of commands to be applied to set up an OUDdirectory server instance. Additional OUD directory server instances were setup then configured. The Testto Production feature provided by OUD is used to clone configurations topre-production environment. Data are exported from DSEE (with the --opends flag) to preservereplication metadata, so that replication can be established between the 2environments. Data are imported in a single OUD directory server, thenreplication was enabled between servers and database files are copied to theother servers. In the customer environment, this initialization strategy was preferredover an over-the-network full initialization. The minimum version required for tightly coupled coexistence is ODSEE 11gRelease 1 (11.1.1) for the ODSEE master that communicates directly with thereplication gateway. However, the rest of the ODSEE topology does not need tobe uniformly based on this version and remain in 6.x, so we upgraded 2 DSEEmasters to the latest ODSEE 11gR1 PS2 (11.1.1.7.0). Instances wereautomatically upgraded in place without having to copy,export or import anything. An alternate solution would have been to deploy 2new ODSEE 11g instances as replication gateway companion. At that stage, 2 replication gateways are deployed as described in the OUDadministration guide. This is the recommended setting to avoid single point offailure. Backup strategy was adapted to reflect the new hybrid topology: In a replicatedenvironment involving ODSEE and OUD, you must perform regular backups on theODSEE side and on the OUD side. A backup must always be restored in thetopology it is associated with. Figure3: Cohabitation DSEE/OUD The current plan is to keep the DSEE-OUD cohabitation for 6 months asapplications are progressively redirected to OUD. 4 Conclusion Tightlycoupled coexistence of OUD with ODSEE is achieved by deploying OUD and ODSEE ina replicated topology using the “Replication Gateway”. The replication gatewayprovides out-of-the-box live transition without service interruption. This enables you to run OUD and DSEE in parallel in a mixed environment so thatyou can transition to OUD over time, validate your upgrade strategy applicationby 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 duringthis process, so some time should be allocated to address that during thetransition analysis and design.

I was recently involved in a LDAP directory services transition project, from DSEE 6.3.1.1 to OUD 11gR2PS1, for a largemanufacturing enterprise. Directory service is medium-sized with a few of million...

Oracle Unified Directory Services (OUD)

Binding a server to privileged port on Linux w/o running as root

This is applicable to any service using privileged ports (< 1024), for instance to run a HTTP server on port 80 or a LDAP directory server on port 389. Running the server as root is not a recommended option for security reasons. Using iptables to map privileged port (e.g. 389) to non-privileged port is a well-know method. Updating the Linux config to put 389 on the non-privileged port list is another option. There is another option that I use frequently, based on setcap to run OUD on port 389 in my labs:This solution requires install and modification of a java 7 JVM specifically for OUD use. Such configuration has security implications, as anyone running that JVM has the right to bind on privileged ports (settings are JVM wide, not restricted to a specific jar file/application), so the jvm access should be restricted to the appropriate user only (the one allowed to start OUD) Here is the procedure: download patchelf sources from here and compile them on target Linux. install setcap package on Linux if needed install a java 7 SDK on target system e.g. /space/java/jdk1.7.0_45 restrict access to that jvm (java and jre) to the appropriate user only (the one used to start OUD). Put in place additional security if needed. as root, run the following commands to allow java to bind as priviledged portssetcap cap_net_bind_service=+epi <JAVA_HOME>/bin/java setcap cap_net_bind_service=+epi <JAVA_HOME>/jre/bin/java - change java dynamic library loading strategy as default strategy is not compatible with setcappatchelf --set-rpath <JAVA_HOME>/jre/lib/amd64/jli <JAVA_HOME>/jre/bin/javapatchelf --set-rpath <JAVA_HOME>/lib/amd64/jli <JAVA_HOME>/bin/java - Modify jvm used by oudedit java.properties and modify property e.g default.java-homerun dsjavaproperties - start OUD with standard start-ds command.

This is applicable to any service using privileged ports (< 1024), for instance to run a HTTP server on port 80 or a LDAP directory server on port 389. Running the server as root is not a recommended...

Oracle Unified Directory Services (OUD)

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 In the Weblogic Console, go to Security Realms/ RealName/ Providers/ Authentication Page Click New to add a new Authentication Provider Enter a name for the provider and choose IplanetAuthenticator as the type Click OK In the Security Realms / RealName / Providers/ Authentication page, click the name of the provider you created, and select the Configuration / Provider Specific page Configure connection attributes for OUD and search bases as appropriate Update the field labeled GUID Attribute at the bottom of the page to value entryuuid 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=domobjectclass: 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, extend OUD schema with wlsUser objectclass and wlsmemberOf attributeNote that I've not found the official oid for wlsmemberOf and wlsUSer so I 've used fake oid in the schema belowattributeTypes: ( 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') Create suffix holding oud=<myreal>,dc=<domain> Allow pre-encoded password import in OUDdsconfig set-password-policy-prop --policy-name Default\ Password\ Policy --set allow-pre-encoded-passwords:true Allow multiple structural objectclasses per entry in OUDdsconfig set-global-configuration-prop --set single-structural-objectclass-behavior:accept 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.

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...

Oracle Unified Directory Services (OUD)

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 musthave exactly one STRUCTURAL object-class to conform to Directory Standards. If aODSEE entry has 0 or more than one structural object-class, the entry would berejected during an import. ODSEE does not differentiate between the two object-classtypes, so this kind of schema inconsistency is commonly found in realdeployments. It is recommended that you fix such user entries on the ODSEE sidebefore 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 configurationDon'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

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...

Oracle Unified Directory Services (OUD)

How to Subscribe My Oracle Support(MOS)'s "Hot Topics" via E-Mail for OUD and DSEE topics. (Doc ID 1391461.1)

Users can add a subscription which will email a digest of newly published KM articles, service request updates and bugs to particular categories or products. Subscriptions are unique to users' selected Knowledge User Template, which is set in users' profile. To subscribe to the Hot Topics, follow the instructions below:Go to My Oracle Support(MOS)Select "Settings" under tab "More..." located on top middle side.Select "Hot Topics E-Mail" from 'Settings' menu available on left side.You will be presented with new screen(see below image).  Make appropriate selections regarding frequency, format, and other item as per your preference. Be sure to tick the "On" button for "Turn Hot Topics E-mail".Click "Add" button under "Include Specific Products" section.A new pop-up comes up.  Enter "Oracle Directory" in "Product" pull-down menu and select "Oracle Directory Server Enterprise Edition".Tick the boxes for the types of notifications you'd like to receive. (Knowledge Articles, Alerts, Bugs, select Bug levels- for example, All Bugs, etc.)Click button "OK" if you are done or "Apply" button if you want to add another product.Enter "Oracle Unified" in "Product" pull-down menu and select "Oracle Unified Directory", tick interested 'Include' list and click button "OK".Click button "Save" once done.  Note that these settings can be updated at any time by following above steps.

Users can add a subscription which will email a digest of newly published KM articles, service request updates and bugs to particular categories or products. Subscriptions are unique to users' selected...

Oracle Unified Directory Services (OUD)

Using OUD with Oracle Directory Integration Platform (DIP)

This post will guide you through configuring OUD as a DIP backend instead of OID.Such deployment is supported since DIP 11.1.1.7.0  (PS6). 1- Install OUD and configure 1 suffix to be synchronized, e.g. dc=example,dc=com HOST=beaglePORT=1389SPORT=1636APORT=4444ADMIN="cn=Directory Manager"PASSWD=welcome1PW_FILE=/tmp/pwdecho $PASSWD > "$PW_FILE" oud-setup --cli --hostName "$HOST" --ldapPort $PORT --ldapsPort $SPORT --adminConnectorPort 4444 --rootUserDN "$ADMIN" --rootUserPasswordFile "$PW_FILE" --generateSelfSignedCertificate --enableStartTLS --baseDN dc=example,dc=com --addBaseEntry --ldifFile /home/sylvain/lib/ldif/Example.ldif --no-prompt --noPropertiesFile 2- Configure a suffix holding DIP configuration DIP stores its configuration in cn=Products,cn=oracleContext.You must create and initialize a local backend holding the cn=oracleContext suffix with the commands below: dsconfig create-workflow-element --set base-dn:cn=oraclecontext --set enabled:true --type db-local-backend --element-name myNewDb --hostname $HOST --port $APORT --bindDN "$ADMIN" --bindPasswordFile "$PW_FILE" --trustAll --no-prompt dsconfig create-workflow --set base-dn:cn=oraclecontext --set enabled:true --set workflow-element:myNewDb --type generic --workflow-name workFlowForMyNewDb --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --bindPasswordFile "$PW_FILE" --trustAll --no-promptdsconfig set-network-group-prop --group-name network-group --add workflow:workFlowForMyNewDb --hostname $HOST --port $APORT --bindDN "$ADMIN" --bindPasswordFile "$PW_FILE" --trustAll --no-promptthen create top entry and Products entry: ldapmodify -a -p $PORT -h $HOST -D "$ADMIN" -w "$PASSWD" <<EOFdn: cn=oraclecontextobjectClass: topobjectClass: containerdn: cn=Products,cn=oraclecontextobjectClass: topobjectClass: containerEOF3- Enable changelogsDIP stores its configuration in cn=Products,cn=oracleContext.OUD uses OUD changelogs for both data anc configuration to detect changes efficiently.dsreplication enable-changelog --no-prompt --baseDN "dc=example,dc=com" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAlldsreplication enable-changelog --no-prompt --baseDN "cn=Products,cn=oraclecontext" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAll4- Grant access to synchronized dataldapmodify -h localhost -p 1389 -D "$ADMIN" -w "$PASSWD" <<EOFdn: dc=example,dc=comchangetype: modifyadd: aciaci: (target="ldap:///dc=example,dc=com")(version 3.0; acl "Entry-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext"; )-add: aciaci: (targetattr="*")(version 3.0; acl "Attribute-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext";)EOFNote: Make sure to enable LDAPS port (LDAP over SSL) if you plan to synchronize userPassword with DIP as this is required for obvious security reasons.5 - Install DIP The procedure is described in http://docs.oracle.com/cd/E23943_01/install.1111/e12002/oud.htm#CHDEDHBGMake sure to Install DIP only (do not run the Configure procedure as it is OID specific)

This post will guide you through configuring OUD as a DIP backend instead of OID. Such deployment is supported since DIP 11.1.1.7.0  (PS6). 1- Install OUD and configure 1 suffix to be...

Oracle Unified Directory Services (OUD)

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 nameldap_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>

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 toolis not yet documented in the Oracle EUS documentation, but...

Oracle Unified Directory Services (OUD)

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 bindrequest as a pre-operation plugin §2. Determine if thepassword stored in the user entry has a custom hash tag e.g {Custom} §3a. If the entry hasthe custom hash, then hash the clear text password provided by the LDAP clientusing the custom password hash. §3b. If the entry doesnot have the custom hash, the skip to step 6 §4. Compare the hashedvalue computed from the clear text password with the custom hash containedin the entry. §5. If the hashcompare matches, then replace the existing custom hashed password with the hashalgorithm defined by the default password hash storage scheme. §6. Then pass the bindthrough to OUD to bind. §7. OUD will hash theclear text value using the default password hash storage scheme and comparewith 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.

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...

Oracle Unified Directory Services (OUD)

Migrating SSL Certificates to OUD

By default, self-signed certificates are automatically asssigned to OUD instances. In some cases, you might want to reuse a DSEE server certificate for the new OUD instance, so that the migration is transparent for SSL clients. Note that this might require installation of the OUD instance on the same box as the DSEE depending on SSL certificate options used. If you want to have your OUD instance reuse the SSL servert certificate,  perform the following steps 1. export the DSEE server certificate to a PKCS12 file (e.g dsee.p12) as described in the ODSEE admin guide    The exact procedure may depend on the DSEE release. On DSEE 6.x, DSEE 7.x and ODSEE, run the command below:     dsadm export-cert -o dsee.p12  <instance_path> defaultCert Note: By default, the alias of the DSEE server cert is defaultCert. Use the appropriate alias in case you choosed to use another value. 2. copy the PKCS12 file to <OUD_INSTANCE>/config 3. create a pin file containing the pkcs12 file password e.g. dsee.p12.pin in the <OUD_INSTANCE>/config directory At that stage, the DSEE server certificate can be imported in the OUD instance in 2 different ways:- either configure a PKCS12 OUD keystore pointing to the file exported from DSEEor- import the DSEE certificate to the default JKS OUD keystore To configure a OUD PKCS12 keystore, perform the following steps: 4.1 Configure the PKCS12 keystore dsconfig set-key-manager-provider-prop \         --provider-name PKCS12 \         --set key-store-file:config/dsee.p12 \         --set key-store-pin-file:config/dsee.p12.pin \         --set enabled:true \         ... 4.2 Configure the LDAPS connection handler to use the pkcs#12 keystore dsconfig set-connection-handler-prop \         --handler-name LDAPS\ Connection\ Handler \         --set key-manager-provider:PKCS12 \         ... To import the DSEE certificate key pair to the existing OUD JKS keystore, perform the following steps: 5.1 Locate the JAVA_HOME of the jvm used by OUD    The version of the JVM used is displayed at startup in the OUD error log 5.2 Run the following command to import the DSEE certificate JAVA_HOME/bin/keytool -v -importkeystore -srckeystore <Path to PKCS12 cert file exported from DSEE>  -srcstoretype PKCS12 -destkeystore <OUD_INSTANCE_DIR>/OUD/config/keystore  -deststoretype JKS     When prompted, specify the JKS pin (available in <OUD_INSTANCE_DIR>/OUD/config/keystore.pin  and the PKCS12 pin you used to export the DSEE server cert 5.3 Check import    To list the content of the OUD JKS keystore, use the following:     JAVA_HOME/bin/keytool -list -keystore <OUD_INSTANCE_DIR>/OUD/config/keystore Enter keystore password:Keystore type: JKSKeystore provider: SUNYour keystore contains 2 entriesdefaultcert, Aug 29, 2013, PrivateKeyEntry,Certificate fingerprint (MD5): 10:63:DC:B5:6B:C8:F3:A0:6B:A7:23:9E:0B:EA:9C:30server-cert, Aug 29, 2013, PrivateKeyEntry,Certificate fingerprint (MD5): BE:C9:F3:8A:49:98:96:15:EF:AC:B4:08:6F:76:FB:05 By default, the DSEE server cert alias is defaultcert.By default, the OUD server cert alias is server-cert.By default, OUD let java  automatically choose the best server-cert amongst those present in the keystore. If you want to force the use of  one certificate, do the following: dsconfig set-connection-handler-prop \         --handler-name LDAPS\ Connection\ Handler \         --set ssl-cert-nickname:defaultcert \         ...

By default, self-signed certificates are automatically asssigned to OUD instances. In some cases, you might want to reuse a DSEE server certificate forthe new OUD instance, so that the migration is...

Oracle Unified Directory Services (OUD)

OUD&EUS Take 2: DB Accounts Proxy-ed by OUD into existing Directories

This post is the second one of a serie focusing on Enterprise User Security (EUS) and Oracle Unified DIrectory (OUD). Enterprise User Security(EUS), an Oracle Database Enterprise Edition feature, leverages the OracleDirectory Services and gives you the ability to centrally manage database usersand role memberships in an LDAP directory. EUS reduces administration costs andincreases security. DB Accounts Proxy-ed by OUDinto existing Directories Most enterprises already have existing corporate directories in place, andprefer the EUS implementation. An EUS implementation leverages the existingdirectory infrastructure and user information base without putting in placesynchronization between directories. In this way, OUD acts as a real-timeinterpreter for Oracle database information requests to user data. Using OUD enables the database to interact with third-partydirectories. OUD leverages existing userand group information in the existing third-party directory infrastructure byforwarding LDAP requests and responses back and forth to the third-partydirectory holding user data. User data, database meta-data such as DBregistration information, user/role Mappings, and other EUS specific meta-data arestored locally in OUD, without requiring any schema changes to store EUSconfiguration in the existing third-party directory. As of release 11gR2PS1, OUD iscertified with EUS to support Active Directory, Oracle Directory ServerEnterprise Edition, and Novell eDirectory. Working with these products, OUD eliminatesuser data duplication and synchronization and consequently lowers total cost ofownership (TCO). 1. Centralizing Accountsinto Microsoft Active Directory You can integrate Active Directory for password-based authentication orintegrate Active Directory with Kerberos authentication. ActiveDirectory Integration for Password-based authentication Such a scenario requires deployment of an additional component: the OUD PasswordChange Notification plug-in (oidpwdcn.dll). Microsoft uses a proprietary implementation to hash passwords in ActiveDirectory that is incompatible with the Oracle DB requirements. The OUDPassword Change Notification plug-in is notified when a password change occurs, and stores hashes in ActiveDirectory. The oidpwdcn dll must be installed on every Active Directory domain controller. Active Directory Schema extension is required to store the hashedpasswords. The database establishes a connection to OUD. OUD retrieves user data(users and groups) from Active Directory. User passwords are retrieved from thehashed password stored by the OUD Password Change Notification plug-in. EUSmetadata are stored and retrieved from OUD. The database version must be 10.1 or later as earlier versions use adifferent and incompatible password format. Figure 2: EUS Account management with ActiveDirectory ActiveDirectory Integration with Kerberos Authentication In this scenario, Kerberos is used for DB authentication. EUS with DBKerberos authentication does not require any changes to the database beyondstandard EUS configuration. The database establishes a connection to OUD. OUDlooks up the requested DB information in Active Directory. All database clientsmust be Kerberos-enabled to use this option. This capability is only supportedwith DB version 10.1 or higher. The database establishes a connection to OUD. OUD retrieves user data(users and groups) from Active Directory. EUS metadata are stored and retrievedfrom OUD. Access to the hashed user password is not required, so no schemaextensions and no Password Change Notification dll have to be deployed onActive Directory. Figure 3: EUS Account managementwith Kerberos and Active Directory 2. CentralizingAccounts into ODSEE The database establishes a connection to OUD. OUD retrieves user data(users and groups) from Oracle Directory Server Enterprise Edition (ODSEE) .EUS metadata are stored and retrieved from OUD. This integration does not require any changes in the database (beyond whatis usually required for EUS, nor fordatabase clients that use username/password authentication. Figure 4: EUS Account managementwith DSEE 3. Centralizing Accountsinto Novell eDirectory The database establishes a connection to OUD. OUD retrieves user data(users and groups) from Novell eDirectory. EUS metadata are retrieved from OUD. This integration does not require any changes in the database beyond whatis usually required for EUS, nor for database clients that useusername/password authentication. Using Novell eDirectory doesn’t require an Oracle password filter. You haveto enable Universal Password in eDirectory, and allow the administrator toretrieve the user password. Refer toNovell's eDirectory documentation on Password Management for more information. This configuration can only be used with DB versions 10.1 or higher due to incompatiblepassword formats in earlier DB versions. Figure 5: EUS Account management with DSEE

This post is the second one of a serie focusing on Enterprise User Security (EUS) and Oracle Unified DIrectory (OUD).Enterprise User Security(EUS), an Oracle Database Enterprise Edition feature,...

Oracle Unified Directory Services (OUD)

OUD&EUS Take 1: DB Accounts Stored in OUD

This post is the first one of a serie focusing on Enterprise User Security (EUS) and Oracle Unified DIrectory (OUD). Enterprise User Security(EUS), an Oracle Database Enterprise Edition feature, leverages the OracleDirectory Services and gives you the ability to centrally manage database usersand role memberships in an LDAP directory. EUS reduces administration costs andincreases security Storing DB Accounts in OUD OUD is specifically tailored to work seamlessly with EUS. Database userinformation, passwords and privileges information for a database or for adatabase domain can be stored in OUD. EUS can leverage existing user and group information stored in OUD toprovide single password authentication and consistent password policy acrossenterprise applications. User data, database meta-data, such as DB registrationinformation, user/role Mappings, and other EUS specific meta-data are stored in OUD using a specific, supported, read-to-use LDAP schema.These meta-data are stored in a separate OUD suffix, called Oracle Context,making a clean logical separation between EUS data and user information thatcan be shared across applications. In addition to providing centralized database user management, Enterprise EUSprovides three different methods of user authentication: X.509 certificateauthentication (introduced in DB 8i);Password-based authentication (since DB 9i);and authentication via Kerberos (since DB 10g).OUD support for Password-based authentication for EUS was introduced in OUD 11gR2. The other authentication methodswere introduced in OUD 11gR2PS1. In the password authentication scenario, the database does not perform userauthentication via LDAP bind to OUD. Instead the database collects usercredentials, hashes the password, and compares the password hash valueretrieved from OUD. More detailed information about EUS can be found in theEnterprise User Administrator's Guide in the Database documentation section on OTN.

This post is the first one of a serie focusing on Enterprise User Security (EUS) and Oracle Unified DIrectory (OUD). Enterprise User Security(EUS), an Oracle Database Enterprise Edition feature,...

Oracle Unified Directory Services (OUD)

Oracle Virtual Desktop Infrastructure and Unified Directory

Oracle Virtual Desktop Infrastructure offers a complete solution for managing and providing access to virtualized desktop environments hosted in the datacenter.  Oracle Virtual Desktop Instrastructure enables organizations to simplify administration, reduce operating costs, increase the utilization of existing IT assets, and boost security by moving from a tradtional desktop environment to a virtual desktop architecture. Typically, you configure Oracle VDI to use the information held in a corporate user directory, like Oracle Unified Directory Server. You can use the OUD setup or the ODSM to create a suffix holding users, eg,  ou=People,dc=oscr,dc=uk,dc=oracle,dc=com using existing schema.Then create a few user entries with the fields User Name, First Name, Last Name, User ID and User Password.  So for my account it is User Name : Sylvain Duloutre First Name : Sylvain Last Name : Duloutre User ID : sduloutr User Password : **** To install Virtual Desktop Infrastructure, follow the install guide, then connect to the VDI Web UI using your preferred browser. Here is a screenshot showing the setup of the VDI server : Next are 2 screenshots showing the LDAP settings and how they map to VDI: As you can see there isn't actually a lot of configuration to do.  You  can now login to VDI from a Sunray or from the Oracle Virtual Desktop Client using the login name and password stored in OUD. Thanks to Rob for VDI snapshots and testing.

Oracle Virtual Desktop Infrastructure offers a complete solution for managing and providing access to virtualized desktop environments hosted in the datacenter.  OracleVirtual Desktop Instrastructure...

Oracle Unified Directory Services (OUD)

Migration Stategy to Oracle Unified Directory

Developing a good strategy is a key element of a migration from third-party directories to OUD. For sake of simplification, migration can be broken down in 5 steps as described below: User Data Migration Most companies defined some custom LDAP attributes and object classes. They use them  in conjunction with standard LDAP schema. LDAP provides a standard way to define schema extensions, so migration of user data is in general quite straight-forward:  Custom schema extensions need to be added to the OUD configuration, user data are exported from the existing directory to the standard LDIF format then re-imported into OUD.  By default, OUD schema checking is strict, some user entries may be rejected when they do not strictly adhere with the LDAP schema. In such case, either fix the data, fix the schema or relax the corresponding schema option in OUD configuration. Migration of passwords may cause problems if they are encrypted with non-standard algorithms. I plan to cover that in a separate post soon. Directory Metadata Migration Most directories, including OUD, store meta data along with the User Data. This may  include access control information (aci), collective attributes, ldap sub entries etc. Each directory vendor uses its own model, so this aspect of the migration requires attention  and must be carefully planned. Directory Configuration Migration Each directory has its own configuration model, so the configuration must be ported to OUD. It includes the LDAP ports the directory listen on, the LDAP naming contexts exposed, database indexes, replication settings, security settings, performance setting, etc. This can be done using OUD graphical interface (ODSM) or using command line dsconfig. This is in general quite simple to migrate the directory configuration to OUD. Special care is needed to manage migration of SSL server certificates if certificate renewal is not an option. Dealing with hard-wired dependencies in client applications Some LDAP client application have hard-wired dependencies on a directory vendor and/or version. For instance, an application would query the directory service version string and would take some decision based on that. Some applications may also create/update directory-specific metadata. It is quite difficult to identify such issues upfront, but it is usually good policy to classify client applications based on their LDAP traffic patterns: traffic of provisioning applications should be review first, as the probabilities to have dependencies on vendor-specific interface is higher than for application doing simple authentication. Oracle Virtual Directory (OVD), part of the  Oracle Directory Services Plus can be used to emulate directory-specific features. Switching from existing directory to OUD From an operational perspective, it is key to define how the actual switch to OUD will occur: Some customers would favor export and import w/o maintaining the 2 environments in sync. This seems very simple, but this methodology cannot ensure an highly-available deployment with up-to-date entries on both sides. When this is not acceptable, synchronization tools like DIP (Directory Integration Platform) which is a part of Oracle Directory Services Plus can be used to synchronize user data. Additional options exist to migrate from Oracle Directory Enterprise Edition (DSEE) to OUD as described here.

Developing a good strategy is a key element of a migration from third-party directories to OUD. For sake of simplification, migration can be broken down in 5 steps as described below: User Data...

Oracle Unified Directory Services (OUD)

Enabling EUS support in OUD 11gR2 using command line interface

Enterprise User Security (EUS) allows Oracle Database to use users & roles stored in LDAP for authentication and authorization.Since the 11gR2 release, OUD natively supports EUS. EUS can be easily configured during OUD setup. ODSM (the graphical admin console) can also be used to enable EUS for a new suffix. However, enabling EUS for a new suffix using command line interface is currently not documented, so here is the procedure: Let's assume that EUS support was enabled during initial setup.Let's o=example be the new suffix I want to use to store Enterprise users. The following sequence of command must be applied for each new suffix: // Create a local database holding EUS context infodsconfig create-workflow-element --set base-dn:cn=OracleContext,o=example --set enabled:true --type db-local-backend --element-name exampleContext -n// Add a workflow element in the call path to generate on the fly attributes required by EUSdsconfig create-workflow-element --set enabled:true --type eus-context --element-name eusContext --set next-workflow-element:exampleContext -n// Add the context to a workflow for routingdsconfig create-workflow --set base-dn:cn=OracleContext,o=example --set enabled:true --set workflow-element:eusContext --workflow-name exampleContext_workflow -n//Add the new workflow to the appropriate network groupdsconfig set-network-group-prop --group-name network-group --add workflow:exampleContext_workflow -n // Create the local database for o=exampledsconfig create-workflow-element --set base-dn:o=example --set enabled:true --type db-local-backend --element-name example -n// Create a workflow element in the call path to the user data to generate on the fly attributes expected by EUSdsconfig create-workflow-element --set enabled:true --set eus-realm:o=example --set next-workflow-element:example --type eus --element-name eusWfe// Add the db to a workflow for routingdsconfig create-workflow --set base-dn:o=example --set enabled:true --set workflow-element:eusWfe --workflow-name example_workflow -n//Add the new workflow to the appropriate network groupdsconfig set-network-group-prop --group-name network-group --add workflow:example_workflow -n  // Add the appropriate acis for EUSdsconfig set-access-control-handler-prop \          --add global-aci:'(target="ldap:///o=example")(targetattr="authpassword")(version 3.0; acl "EUS reads authpassword"; allow (read,search,compare) userdn="ldap:///??sub?(&(objectclass=orclservice)(objectclass=orcldbserver))";)'dsconfig set-access-control-handler-prop \      --add global-aci:'(target="ldap:///o=example")(targetattr="orclaccountstatusevent")(version 3.0; acl "EUS writes orclaccountstatusenabled"; allow (write) userdn="ldap:///??sub?(&(objectclass=orclservice)(objectclass=orcldbserver))";)' Last but not least you must adapt the content of the ${OUD}/config/EUS/eusData.ldif file with your suffix value then inport it into OUD.

Enterprise User Security (EUS) allows Oracle Database to use users & roles stored in LDAP for authentication and authorization.Since the 11gR2 release, OUD natively supports EUS. EUS can be easily...

Oracle Unified Directory Services (OUD)

Creating a new naming context in OUD

A naming context (also known as a directory suffix) is a DN that identifies the topentry in a locally held directory hierarchy. A new naming context can be created using ODSM, the OUD gui admin console, as described in http://docs.oracle.com/cd/E29407_01/admin.111200/e22648/server_config.htm#CBDGCJGF It can also be created using the dsconfig command line as described below: Creation of a new naming context consists in 3 steps: First create a Local Backend Workflow element (myNewDb in this exemple) ,  responsible for the naming context base dn, e.g o=example. dsconfig create-workflow-element \          --set base-dn:o=example \          --set enabled:true \          --type db-local-backend \          --element-name myNewDb \          --hostname <your host> \          --port <admin port> \          --bindDN cn=Directory\ Manager \          --bindPasswordFile ****** \          --no-prompt Second, create a Workflow element (workFlowForMyNewDb in this exemple) associated with the Local Backend Workflow element. WorkFlow elements are used to route LDAP requests to the appropriate database, based on the target base dn. dsconfig create-workflow \          --set base-dn:o=example \          --set enabled:true \          --set workflow-element:myNewDb \          --type generic \          --workflow-name workFlowForMyNewDb \          --hostname <your host name> \          --port <admin port>\          --bindDN cn=Directory\ Manager \          --bindPasswordFile ****** \          --no-prompt Then, the workflow element must be made visible outside of the directory, i.e added to the internal "routing table". This is done by adding the Workflow to the appropriate Network Group. A Network group  is used to classify incoming client connections and route requests to workflows. dsconfig set-network-group-prop \          --group-name network-group \          --add workflow:workFlowForMyNewDb \          --hostname <your hostname> \          --port <admin port>\          --bindDN cn=Directory\ Manager \          --bindPasswordFile ****** \          --no-prompt At that stage, it is possible to import entries to the new naming context o=example.

A naming context (also known as a directory suffix) is a DN that identifies the top entry in a locally held directory hierarchy. A new naming context can be created using ODSM, the OUD gui admin...

Personal

Fuzzing for Security

Yesterday, I attended an internal workshop about ethical hacking. Hacking skills like fuzzing can be used to quantitatively assess and measure security threats in software.  Fuzzing is a software testing technique used to discover coding errors and security loopholes in software, operating systems or networks by injecting massive amounts of random data, called fuzz, to the system in an attempt to make it crash. If the program contains a vulnerability that can leads to an exception, crash or server error (in the case of web apps), it can be determined that a vulnerability has been discovered.A fuzzer is a program that generates and injects random (and in general faulty) input to an application. Its main purpose is to make things easier and automated.There are typically two methods for producing fuzz data that is sent to a target, Generation or Mutation. Generational fuzzers are capable of building the data being sent based on a data model provided by the fuzzer creator. Sometimes this is simple and dumb as sending random bytes, swapping bytes or much smarter by knowing good values and combining them in interesting ways.Mutation on the other hand starts out with a known good "template" which is then modified. However, nothing that is not present in the "template" or "seed" will be produced.Generally fuzzers are good at finding buffer overflow, DoS, SQL Injection, Format String bugs etc. They do a poor job at finding vulnerabilites related to information disclosure, encryption flaws and any other vulnerability that does not cause the program to crash.  Fuzzing is simple and offers a high benefit-to-cost ratio but does not replace other proven testing techniques.What is your computer doing over the week-end ?

Yesterday, I attended an internal workshop about ethical hacking. Hacking skills like fuzzing can be used to quantitatively assess and measure security threats in software.  Fuzzing is a software...

Oracle Unified Directory Services (OUD)

Using execution context ID (ECID)

Execution context ID (ECID) is a unique identifier to correlate events or requests associated with the same transation across several components.The ECID value for a particular request is generated at the first layer and is passed down to the subsequent layers. The ECID value is logged (and auditable) in each product involved in the transaction. ECID allows an administrator to track the end-to-end flow of a particular request across the product stack.ECID are supported by OUD and can be used to track LDAP requests from the client down to the ultimate LDAP server processing the request (inclusing LDAP access layer/proxy if any).When performing a LDAP operation, a client can pass a ECID using the LDAP control extension 2.16.840.1.113894.1.8.31 . This ECID is logged by OUD. The OUD server generates a ECID in case none is present in the incoming request.ECID are logged in the "Oracle Access Logger". By default, this logger is disabled. To enable it, run the command below:dsconfig set-log-publisher-prop \         --publisher-name Oracle\ Access\ Logger \         --set enabled:true\         --hostname prehnite \         --port <admin port>\         --bindDN cn=Directory\ Manager \         --bindPassword ****** \         --no-promptHere is a sniplet of the Oracle access log:[2012-08-16T16:10:26.770+02:00] [OUD] [TRACE] [OUD-24641559] [PROTOCOL] [host: prehnite] [nwaddr: 10.166.70.62] [tid: 25] [userId: sduloutr] [ecid: 10.166.70.62:37126:1345126226770:39,0] [category: REQ] [conn: -1] [op: 80] [msgID: 81] [dn: o=example] [type: synchronization] MODIFYThe administrator can then search the logs using a particular ECID value. Audit logs can be queried for a given ECID through Oracle BI Publisher’s audit reports. For example, if you send an LDAP request to Oracle Virtual Directory front-ending Oracle Unified Directory, an ECID associated with the LDAP request is present in the OVD diagnostic logs and audit logs; similarly, when the query reaches OUD, OUD includes the same ECID in its diagnostic logs and audit reports.

Execution context ID (ECID) is a unique identifier to correlate events or requests associated with the same transation across several components. The ECID value for a particular request is generated at...

Oracle Unified Directory Services (OUD)

Monitoring OUD with VisualVM

VisualVM is a visual tool integrating several commandline JDK tools and lightweight profiling capabilities. Designed for both production and development time use, it further enhances the capability of monitoring and performance analysis for the Java SE platform. Here are the steps to use VisualVM to monitor Oracle Unified Directory:  #1 Download the latest release of VisualVM from http://visualvm.java.net/ #2 Enable the MBeans plugin as described in  http://visualvm.java.net/mbeans_tab.html to take advantage of the statistics exposed by OUD #3 Enable JMX on OUD Start the server. Enable the JMX Connection Handler and set the port number to be used with JMX. Choose a port that is not in use and to which the user that is running the server has access rights. $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-connection-handler-prop --handler-name "JMX Connection Handler" \ --set enabled:true --set listen-port:1689 Add the JMX read, write, and notify privileges to the root DN. $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-root-dn-prop \ --add default-root-privilege-name:jmx-read \ --add default-root-privilege-name:jmx-write \ --add default-root-privilege-name:jmx-notify Restart the server. #4 Connect to OUD from VisualVM To connect VisualVMto a server instance, click on File/Add JMX Connection. The following fields are required: JMX URL: service:jmx:rmi:///jndi/rmi://''host'':''port''/org.opends.server.protocols.jmx.client-unknown host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets. port is the decimal port number of the JMX connector. The default JMX URL is: service:jmx:rmi:///jndi/rmi://198.51.100.0:1689/org.opends.server.protocols.jmx.client-unknown User Name. A valid LDAP user name. The default Directory Manager user name is cn=Directory Manager. Password. The user's LDAP password. #5 Browse MBeans attributes Go to the right panel then select the MBean tab and navigate in the MBean tree. You can get access to the OUD config, monitoring information & statistics and all the convenient java metrics. Note: You can plot those JMX numeric values in VisualVM that appear in bold. To do so, double-clicking on numeric attribute values will display a chart that plots changes in that numeric value.

VisualVM is a visual tool integrating several commandline JDK tools and lightweight profiling capabilities. Designed for both production anddevelopment time use, it further enhances the capability...

Oracle Unified Directory Services (OUD)

OUD Database Indexes & Performance Tuning

Oracle Unified Directory (OUD) database indexes enable (search) directory requests  to be processed efficiently.  Indexes are filesthat contain lists of values, where each value is associated with a listof entry identifiers to suffixes in the directory server database. When the directoryserver processes a search request, it searches the database using the list ofentry identifiers in the indexes, thus speeding up the search. If indexes didnot exist, the directory server would have to look up each entry inthe database, which dramatically degrades performance. First of all, unindexed searches are rejected by default unless the (authenticated)  user has the privilege to perform them because unindexed searches  may negatively impact overall directory performances. In some circumstances, unindexed searches are a valid approach, so it is possible to explicitely  assign the unindexed-search privilege to a user or a group of user. A user attempting to perform an unindexed search gets the message "you do not have sufficient privileges to perform an unindexed search". Note that unindexed searches always complete sucessfully when the amount of entries in the database does not exceed the value if index-entry-limit (4000 by default), which is unlikely to be seen in real deployments. The verify-index command can be used to check the consistency between the indexand entry data within the directory server database. This command also provides informationabout the number of index keys that have reached the index entry limit (See below). The rebuild-index command can be used to rebuild an index. It is useful in the following cases: When the index-entry-limit property of an index changes When a new index is created The index-entry-limit tuning parameter (known as AllIDs threshold in Oracle Directory Server Entreprise Edition) controls the maximum numbers of entries kept in an index record as scaning the whole database may become a more efficient option when the number of entries associated with a given index value becomes huge. Tuning indexes upfront may not be an obvious task, that's the reason why OUD provides you with  both  static and  dynamic index analyser tools: The static analyser is delivered as part of the dbtest tool.  The dbtest list-index-status -n <dbName> -b <dbSuffix> command let you figure out how many entries are associated with each index value, and tune index-entry-limit when needed.. The dynamic analyser can be used to monitor live search filters received by OUD and corresponding  index usage: Live index analysis must be first enabled at the database level. At that point, subsequent searches hitting OUD are analysed and the corresponding statistics are kept in memory.  Statistics can be retrieved from the in-memory suffix cn=monitor as part of the database environmenent entry. To enable live index data collection, run  the following command: $ dsconfig set-workflow-element-prop --element-name userRoot  --set index-filter-analyzer-enabled:true  --set max-entries:100 -h localhost -p 4444 -D cn=directory\ manager -w <password> The set-max-entries parameter controls how many statistical records are kept in memory. To retrieve the results, run the following search: $ ldapsearch -p 1389 -D cn=directory\ manager -w <password>  -b "cn=<dbName> Database Environment,cn=monitor"  "(objectclass=*)"  filter-usefilter-use: (description=*) hits:2 maxmatches:-1 message:presence index type is disabled for the description attribute Important note:  It is not recommanded to enable statistic collection in a production system for a long time as it consumes ressources. It is also possible to use the operational attribute debugsearchindex to figure out which entries are targetted by each component of a LDAP search filter. This is a lightweight yet convenient way to debug index-related issues. $ ./ldapsearch -p 11389 -b "o=example" -D "cn=directory manager" -w *** "(&(uid=user.9*)(objectclass=*))" debugsearchindexdn: cn=debugsearchdebugsearchindex: filter=(&(objectClass=*)[NOT-INDEXED](uid=user.9*)[COUNT:111]) [COUNT:111] scope=wholeSubtree[LIMIT-EXCEEDED:4101] final=[COUNT:111] 

Oracle Unified Directory (OUD) database indexes enable (search) directory requests  to be processed efficiently.  Indexes are filesthat contain lists of values, where each value is associated with...

Oracle Unified Directory Services (OUD)

Cohabitation/Migration ODSEE->OUD: privileges

OUDprovides a privilege subsystem, which can be used to define capabilities thatwill be granted to users. The privilege subsystem works in conjunction with theaccess control implementation in theprocess of determining whether a user will be allowed to perform a certainoperation. Ingeneral, default OUD access control settings are stricter than ODSEE.Appropriate privileges must be added to achieve behavior that is equivalent tothat of ODSEE. For instance, by default, OUD ACIs don’t allow users to resetanother users’s password. Alternatively, it is possible to disable theprivilege subsystem. By default, normal users are not granted any of the privileges listed above.Therefore, if a user should be allowed to perform any of theassociated operations, they must be granted the appropriate privileges. This can be done byadding the ds-privilege-name operational attribute to the user's entry. ds-privilege-name is a multivalued attribute, and if a user is to be givenmultiple privileges, then a separate value should be used for each one. Whenthe virtual attribute subsystem is in place, it should also be possible togrant privileges to groups of users automatically by making ds-privilege-name a virtual attribute inthose user entries. As an example, the following modification can be used to add theproxied-auth privilege to the user cn=Proxy User,dc=example,dc=com: dn: cn=Proxy User,dc=example,dc=comchangetype: modifyadd: ds-privilege-nameds-privilege-name: proxied-auth Granting privileges explictely to users may not be the optimal solution when OUD and ODSEE cohabit in a replication topology as the OUD-specific ds-privilege-name would be replicated by to ODSEE, so privileges can also be assign implicitely to a set of user based on group membership for example, using the notion of virtual attribute. I'll cover Virtual attribute in a subsequent post. Alternatively, It is possible to disable those privileges leading to aci behavioraldifferences between OUD and ODSEE. For instance, the  unindexed-search privilege can be disabled  so that users canperform un-indexed searches. A privilege (unindex search checking in the example below) can be disabled using the followingcommand: dsconfigset-global-configuration-prop  --add \ disabled-privilege: unindexed-search -n The list of OUD privileges is available here.

OUD provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in thepro...

Oracle Unified Directory Services (OUD)

Cohabitation/Migration ODSEE->OUD: schema checking

By default, OUD schema scheck is stricter than ODSEE.  Schema checking is key for data sanity, however this might cause some trouble when "incorrect" data have to be imported into OUD or when incorrect data are replicated from ODSEE. Generally speaking, it is not recommanded to disable schema checking and the data should be fixed whenever possible before import and on the ODSEE side when ODSEE and OU cohabit in the same replication topology. In some cases, this is not possible, so some specific checks can be disabled to accomodate with common inconsistency: Structural object class unicity Per LDAP standard, every LDAP entry must contain exactly one structural object class.  In many deployments, some LDAP entries contain 0 or more than 1 objectclass and several LDAP server implementations do not enforce this. By default OUD does. Such check can be relaxed w/o know adverse effect by using the command below: dsconfig set-global-configuration-prop --set \single-structural-objectclass-behavior:accept -n Attribute type names containing invalid characters A few customers defined their own attribute types, using forbidden characters, e.g undercores, or leading digit in attribute names and/or in attribute type extensions (e.g 4you;x_bad_extension). Such check can be relaxed using the command below: dsconfig set-global-configuration-prop --set \allow-attribute-name-exceptions:true -n  Zero-length attribute value Zero-length attribute values (that is, an empty string) is technically not allowed by the revised LDAPv3 specification, but some environments may require it for backward compatibility with servers that do allow it. Empty string can be explicitely allowed on a per LDAP syntax basis, using the example below for DirectoryString syntax: dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \--set allow-zero-length-values:true -n

By default, OUD schema scheck is stricter than ODSEE.  Schema checking is key for data sanity, however this might cause some trouble when "incorrect" data have to be imported into OUD or when...

Oracle Unified Directory Services (OUD)

Cohabitation/Migration ODSEE->OUD: dn-based search resource limits

Oracle Unified Directory 11g Release 1 (11.1.1) provides a mechanism to replicatedata between Oracle Directory Server Enterprise Edition and Oracle Unified Directory. Depending on the ODSEE features used, the OUD configuration may need to be adapted to provide the same service transparently to client application. Both ODSEE and OUD provide ways to control ressources used by a directory user. The following limits are provided by OUD at the global configuration level: ds-cfg-size-limit specifies the maximum number of entries that can be returned to the client during a single search operation. ds-cfg-time-limit specifies the maximum length of time that should be spent processing a single search operation ds-cfg-lookthrough-limit specifies the maximum number of entries that the Directory Server should "look through" in the course of processing a search request. This includes any entry that the server must examine in the course of processing the request, regardless of whether it actually matches the search criteria. ds-cfg-idle-time-limit specifies the maximum length of time that a client connection may remain established since its last completed operation The corresponding configuration attributes in ODSEE are search-size-limit, search-time-limit, look-through-limit, idle-timeout.  Such configuration mapping is automatically provided by tools like ds2oud. Server limits for search operations can also be controlled using special operational attribute values assoaicted with the user binding to the directory. These attributes are stored as part of the directory data, so they are replicated between ODSEE and OUD.  Attribute names (and sometimes values) vary so the OUD configuration need to be extended to deal with that: DSEE entries may contain the following resourcelimit attributes: nsSizeLimit, nsTimeLimit, nsLookThroughLimit, nsIdleTimeout. Corresponding attributes on OUD areds-rlim-size-limit, ds-rlim-time-limit, ds-rlim-lookthrough-limit,ds-rlim-idle-time-limit.In order to replicate the functionality correctly, theOUD schema (02-config.ldif) must be modified so that each DSEE attribute namerelated to resource limits is declared as an alias name for each correspondingOUD attribute. An alias can be declared in an attributeType declaration as below: attributeTypes: ( 1.3.6.1.4.1.26027.1.1.244 NAME ( 'ds-pwp-password-policy-dn''alias-for-ds-pwp-password-policy-dn') On DSEE, -1 is used to disable a resource limit. OnOUD, 0 is used. One way to address this difference is to create a virtualattribute on OUD to override the content of the OUD attribute when the value ofthe DSEE attribute is equals to -1. A virtual attribute must be created for the4 attributes mentioned, as described below: dsconfig create-virtual-attribute--name "mapping nsSizeLimit " --type user-defined --setattribute-type:ds-rlim-size-limit \ --set filter:”(nsSizeLimit=-1)”\ --set conflict-behavior:virtual-overrides-real\ --set value:"0" --set enabled:true dsconfig create-virtual-attribute --name "mapping nsTimeLimit " --type user-defined --set attribute-type:ds-rlim-time-limit \--set filter:”(nsTimeLimit=-1)”\--set conflict-behavior:virtual-overrides-real \--set value:"0"--set enabled:true dsconfig create-virtual-attribute--name "mapping nsLookthroughLimit" --type user-defined --set attribute-type:ds-rlim-lookthrough-limit --set filter:”(nsLookthroughLimit=-1)”--set conflict-behavior:virtual-overrides-real--set value:"0"--set enabled:true dsconfig create-virtual-attribute --name "mapping nsIdleTimeout " \--type user-defined --set attribute-type:ds-rlim-idle-time-limit \--set filter:”(nsIdleTimeout=-1)”\--set conflict-behavior:virtual-overrides-real \--set value:"0"--set enabled:true More information about account-based resource limits is available here.

Oracle Unified Directory 11g Release 1 (11.1.1) provides a mechanism to replicatedata between Oracle Directory Server Enterprise Edition and Oracle Unified Directory. Depending on the ODSEE features...

Oracle Unified Directory Services (OUD)

Installing Oracle Unified Directory in silent mode

By default, the OUD installer runs in GUI mode. Alternatively, it is possible to install and setup OUD in silent mode.First, download the OUD bits, then run the installer in silent mode. Last but not least setup/configure OUD in silent mode as well. To run the installer in silent mode, either run it in GUI mode on your laptop or any system with a GUI and record your answers so that you can replya them on another system in silent mode. Alternatively, you can build a response file manually for OUD. To record your answers, run the installer with the option -record, e.g ./runInstaller -record -destinationFile /tmp/OUD.rsp To the installer with an existing response file (silent mode) ./runInstaller -silent -responseFile /tmp/OUD.rsp A response file template is available at the end of this post. You need to change values for ORACLE_HOME and MIDDLEWARE_HOME.After this install, you can setup oud in cli mode (oud-setup), either interactive or in batch. oud-setup --cli --no-prompt -D "cn=directory manager" -j $PASS_FILE -p $PORT1 --adminConnectorPort $APORT1 --noPropertiesFile More info available athttp://docs.oracle.com/cd/E22289_01/html/821-1274/ds-cli-setup.html#scrolltoc  --- template file for the OUD installer[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 directorySPECIFY_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 trueSOFTWARE_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=/u01/app/oracle/middleware/OUD#Provide existing Middleware Home location.MIDDLEWARE_HOME=/u01/app/oracle/middleware/#CONFIG_WIZARD_RESPONSE_FILE_LOCATION=0[SYSTEM][APPLICATIONS][RELATIONSHIPS]

By default, the OUD installer runs in GUI mode. Alternatively, it is possible to install and setup OUD in silent mode. First, download the OUD bits, then run the installer in silent mode. Last but not...

Virtual Directory & Sun Directory Proxy Server

Unable to retrieve backend SEARCH connection

That error message is pretty common with Directory Proxy Server. Here are the reasons why: Upon reception of a request, DPS tries to route the request to the target data views, based on the request (base) dn. When this step fails (misconfiguration), a "No such Object" error is returned with additional text "The entry foo=bar is not handled by the server.Then DPS selects the "best" directory server associated with the target data view according to the load-balancing algorithm. If no valid directory server is found, the error "Unable to retrieve backend SEARCH connection" is returned. There are 4 possible causes: - the data source pool associated with the target data view is empty (configuration problem)- the data sources in that data source pool are disabled or have search-weight/bind-weight set to 0 so they are not considered valid servers to process search/bind operations (configuration problem)- every data source (directory server) in that data source pool are down- the max number of connection to every data source is reached. If you get these errors after a brain new deployment with the OOTB dps configuration, #1 is probably the cause: DPS default config comes with a default data view able to handle every suffix/request. This data view is associated with a data souce pool that is empty by default. You have to create at least one data source object, add it to that data source pool then set load-balancing weights. More info are available at   http://docs.sun.com/app/docs/doc/820-4809/fhktx?l=en&q=dsee&a=view

That error message is pretty common with Directory Proxy Server. Here are the reasons why: Upon reception of a request, DPS tries to route the request to thetarget data views, based on the request...

Virtual Directory & Sun Directory Proxy Server

Dynamic provisioning of directory instances with DPS - Part 1

The goal here is to dynamically  add/remove a directory server instance from the mesh with no or limited impact on the client applications and w/o altering the HW load-balancers that are commonly deployed in front of the directories. In the rest of this post, we assume that client applications access the directory services via an access layer provided by the Sun/Oracle Directory Proxy Server (DPS). The first method consists in changing the directory server operational state so that it is automatically considered as "unavailable" by DPS. Each DPS periodically checks directory servers availability by retrieving  its operational state with a configurable LDAP search. Would the operational entry "disappears" (i.e. no longer matches a search filter), the directory server would stop receiving traffic from the DPS(s). Configuration First, decide  which entry and attribute will hold the server operational state, e.g. attribute description in entry  cn=server state,cn=config dn: cn=server state,cn=configobjectclass: topobjectclass: extensibleObjectdescription: SERVER_AVAILABLE Then change the DPS configuration of each LDAP data sources so that this "state" entry is checked on a regular basis. By convention, the server is down if the poll returns no entry. In this example, the property monitoring-entry-dn must be set to cn=server state,cn=config, the property monitoring-search-filter can be set to (description=SERVER_AVAILABLE). Depending on the state entry used, it may be necessary to use specific credentials to access it. In such case, the properties monitoring-bind-dn and monitoring-bind-pwd should be changed as well. [@euler]# dpconf get-ldap-data-source-propeuler:10389           ...ldap-address                                          : euler.france.sun.com  ldap-port                                               :  10389  ldaps-port                                             :  ldaps  monitoring-bind-dn                        :  cn=directory manager  monitoring-bind-pwd                      : {3DES}qowEGwcvUhKdUKegsRrO73X46Gb2JKPT  monitoring-bind-timeout              :  5s  monitoring-entry-dn                       :  cn=serverstate,cn=config monitoring-interval                       :  30s  monitoring-search-filter              : (description=SERVER_AVAILABLE) Removing a directory server from the topology The description of the state entry must first be modified e.g. the state can be set to SERVER_UNAVAILABLE.  DPS will take up to about 2 times the monitoring-interval to stop forwarding traffic to that server. It is then safe to shut down the directory server instance w/o impacting client applications. (Re)adding a directory server to the topology Set (back) the description value to "SERVER_AVAILABLE" in the directory state entry (and dynamically add a new data source object to the DPS configuration for a brand-new server).

The goal here is to dynamically  add/remove a directory server instance from the mesh with no or limited impact on the client applications and w/o altering the HW load-balancers that are commonly...

Sun Campus Ambassadors

Occasional Lecturer at INSA LYON

Last week, I gave a 3-hour lecture at INSA Lyon about Java Web Services. My presentation was split in 3 parts; First, Web Services in general (standard WS and RESTful), then an introduction to JavaEE. Last but not least, I've combined both to present how to develop Java Web Services with JAX-WS. This was quite intense, with lots of content and acronyms over a short period of time, but this was the goal Dr. Sylvie Servigne and Anne Tchounikine set to me for this session. Good interactions with the audience; Many interesting questions were raised. I really like interacting with different types of audience. This is a great way to improve my communication skills, meet great people and have fun. This was the first time I was on the Campus since the discontinuation of the Sun Campus Ambassador program I took care of during the last 2 years. Now, thanks to the success of that program, Sun technologies are well-known and some are used during hands-on and practical sessions. Many students asked questions about the future of Sun Opensource projects with Sun's acquisition by Oracle. Oracle awareness was limited to SQL databases with only a few students aware of Oracle ERP products, but the rest of the product offering was totally unknown. There might be some opportunities to fill in this gap in the future...

Last week, I gave a 3-hour lecture at INSA Lyon about Java Web Services. My presentation was split in 3 parts; First, Web Services in general (standard WS and RESTful), then an introduction toJavaEE....

Oracle

Integrated Cloud Applications & Platform Services