Wednesday Nov 06, 2013

New Oracle White Paper about Directory Services Integration with Database Enterprise User Security

I've written a new Oracle White Paper about Directory Services Integration with
Database Enterprise User Security based on 2 recent posts, https://blogs.oracle.com/sduloutr/entry/oud_eus_take_2_db and  https://blogs.oracle.com/sduloutr/entry/oud_eus_take_1_db

The official document is available at http://www.oracle.com/technetwork/database/security/dirsrv-eus-integration-133371.pdf

Thursday Oct 17, 2013

Using EUSM to manage EUS mappings in OUD

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

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

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

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

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

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

Find below common commands:

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

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

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

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

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

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

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

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

Enterprise role to Global role mapping

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


Thursday Oct 03, 2013

Reusing passwords encoded with custom hash in OUD

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

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

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

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

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

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

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

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

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

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

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

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

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


Friday Aug 30, 2013

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 DSEE
or
- 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: JKS
Keystore provider: SUN
Your keystore contains 2 entries

defaultcert, Aug 29, 2013, PrivateKeyEntry,
Certificate fingerprint (MD5): 10:63:DC:B5:6B:C8:F3:A0:6B:A7:23:9E:0B:EA:9C:30

server-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 \

         ...

Tuesday Aug 27, 2013

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 Oracle Directory Services and gives you the ability to centrally manage database users and role memberships in an LDAP directory. EUS reduces administration costs and increases security.

DB Accounts Proxy-ed by OUD into existing Directories

Most enterprises already have existing corporate directories in place, and prefer the EUS implementation. An EUS implementation leverages the existing directory infrastructure and user information base without putting in place synchronization between directories. In this way, OUD acts as a real-time interpreter for Oracle database information requests to user data.

Using OUD enables the database to interact with third-party directories. OUD leverages existing user and group information in the existing third-party directory infrastructure by forwarding LDAP requests and responses back and forth to the third-party directory holding user data. User data, database meta-data such as DB registration information, user/role Mappings, and other EUS specific meta-data are stored locally in OUD, without requiring any schema changes to store EUS configuration in the existing third-party directory.

As of release 11gR2PS1, OUD is certified with EUS to support Active Directory, Oracle Directory Server Enterprise Edition, and Novell eDirectory. Working with these products, OUD eliminates user data duplication and synchronization and consequently lowers total cost of ownership (TCO).

1. Centralizing Accounts into Microsoft Active Directory

You can integrate Active Directory for password-based authentication or integrate Active Directory with Kerberos authentication.

Active Directory Integration for Password-based authentication

Such a scenario requires deployment of an additional component: the OUD Password Change Notification plug-in (oidpwdcn.dll). Microsoft uses a proprietary implementation to hash passwords in Active Directory that is incompatible with the Oracle DB requirements. The OUD Password Change Notification plug-in is notified when a password change occurs, and stores hashes in Active Directory. The oidpwdcn dll must be installed on every Active Directory domain controller.

Active Directory Schema extension is required to store the hashed passwords.

The database establishes a connection to OUD. OUD retrieves user data (users and groups) from Active Directory. User passwords are retrieved from the hashed password stored by the OUD Password Change Notification plug-in. EUS metadata are stored and retrieved from OUD.

The database version must be 10.1 or later as earlier versions use a different and incompatible password format.

Figure 2: EUS Account management with Active Directory

Active Directory Integration with Kerberos Authentication

In this scenario, Kerberos is used for DB authentication. EUS with DB Kerberos authentication does not require any changes to the database beyond standard EUS configuration. The database establishes a connection to OUD. OUD looks up the requested DB information in Active Directory. All database clients must be Kerberos-enabled to use this option. This capability is only supported with 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 retrieved from OUD. Access to the hashed user password is not required, so no schema extensions and no Password Change Notification dll have to be deployed on Active Directory.

 

Figure 3: EUS Account management with Kerberos and Active Directory

2. Centralizing Accounts 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 what is usually required for EUS, nor for database clients that use username/password authentication.

 

Figure 4: EUS Account management with DSEE

3. Centralizing Accounts into 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 what is usually required for EUS, nor for database clients that use username/password authentication.

Using Novell eDirectory doesn’t require an Oracle password filter. You have to enable Universal Password in eDirectory, and allow the administrator to retrieve the user password. Refer to Novell's eDirectory documentation on Password Management for more information.

This configuration can only be used with DB versions 10.1 or higher due to incompatible password formats in earlier DB versions.

 

Figure 5: EUS Account management with DSEE

 



Tuesday Jul 09, 2013

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 Oracle Directory Services and gives you the ability to centrally manage database users and role memberships in an LDAP directory. EUS reduces administration costs and increases security

Storing DB Accounts in OUD

OUD is specifically tailored to work seamlessly with EUS. Database user information, passwords and privileges information for a database or for a database domain can be stored in OUD.

EUS can leverage existing user and group information stored in OUD to provide single password authentication and consistent password policy across enterprise applications. User data, database meta-data, such as DB registration information, 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 that can be shared across applications.

In addition to providing centralized database user management, Enterprise EUS provides three different methods of user authentication: X.509 certificate authentication (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 methods were introduced in OUD 11gR2PS1.

In the password authentication scenario, the database does not perform user authentication via LDAP bind to OUD. Instead the database collects user credentials, hashes the password, and compares the password hash value retrieved from OUD. More detailed information about EUS can be found in the Enterprise User Administrator's Guide in the Database documentation section on OTN.


Wednesday Jul 03, 2013

New Patch available for Oracle Unified Directory 11gR2PS1 (11.1.2.1)

A new patch is available on top of OUD 11gR2PS1 (11.1.2.1).
To download it, go to http://support.oracle.com,  select the Patches&Update tab, enter 16847568 in the Patch Name/Number field then click on the Search button.


Thursday Apr 18, 2013

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.


Thursday Apr 11, 2013

Oracle Unified Directory 11g R2 PS1 released

Oracle Identity and Access Management 11g R2 (11.1.2.1.0) is now generally available. Media is available for download on the Oracle Software Delivery Cloud (OSDC). This includes the following products:
  • Oracle Identity and Access Management
  • Oracle Entitlements Server Security Module
  • Oracle Access Manager OHS 11g WebGates
  • Oracle Access Manager IHS 7.0 WebGates
  • Oracle Access Manager Access SDK
  • Oracle Access Manager JBoss 5 Agent
  • Oracle Unified Directory
  • Oracle Enterprise Single Sign-On
  • Oracle Access Management Mobile and Social SDK

To download OUD,go to https://edelivery.oracle.com/ , select "Oracle Fusion MiddleWare" and the target platform, select  "Oracle Fusion Middleware Identity Management 11gR2 Media Pack"  then "Oracle Unified DIrectory 11g (11.1.2.1.0)"

Documentation is avilable at http://docs.oracle.com/cd/E37116_01/index.htm

Certification Matric is available at http://www.oracle.com/technetwork/middleware/id-mgmt/identity-accessmgmt-11gr2certmatrix-1714221.xls

Wednesday Mar 13, 2013

ODSEE 11gR1 PS2 Released

Check our documentation set for more, including Release Notes and Certification Matrix.

Download ODSEE 11gR1 PS2 (aka 11.1.1.7.0) from here.

Tuesday Jan 15, 2013

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.






Monday Nov 12, 2012

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 info
dsconfig 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 EUS
dsconfig 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 routing
dsconfig 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 group
dsconfig set-network-group-prop --group-name network-group --add workflow:exampleContext_workflow -n

// Create the local database for o=example
dsconfig 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 EUS
dsconfig 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 routing
dsconfig 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 group
dsconfig set-network-group-prop --group-name network-group --add workflow:example_workflow -n 

// Add the appropriate acis for EUS
dsconfig 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.


Tuesday Sep 25, 2012

OUD as a OAM Identity Store

Since 11gR2, OUD can be used natively as a OAM Identity Store. Select  "OUD: Oracle Unified Directory" as Store Type as described here.

As an alternate solution, you can also configure OVD as Identity Store with OAM and then configure LDAP adapter for OVD with OUD details.Configuring Identity store for OAM is documented here. Choose "OVD: Oracle Virtual Directory" as store type and provide store details as per the document. Configuring LDAP adapter for OVD is documented here. Provide your OUD details required as per the document.

Friday Sep 21, 2012

Creating a new naming context in OUD

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


Wednesday Sep 12, 2012

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 ?
About


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

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

Search

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