Migrating from Oracle DSEE to DS/OpenDJ

The purpose of this book is to provide information on migrating from DSEE to DS/OpenDJ.


Migrating from Oracle DSEE to DS/OpenDJ

The purpose of this article is to provide information on what you must consider when planning a migration from Oracle® Directory Server Enterprise Edition (DSEE) or Sun® DSEE to DS/OpenDJ.

Introduction

Parts of the DSEE code base dates back to the original Netscape® Directory Server (DS). Over the years the directory server became a widely used, robust product. And yet one of the original assumptions built into DSEE is that directory services are mainly for reads, not for writes. Furthermore the code base for DSEE started out at a time when the LDAP standards were still very much in progress, and so does not always apply the standards strictly.

The code base that today backs DS/OpenDJ started in the DSEE team after it had already become clear that directories must handle as many writes as reads, today's directory data being more volatile than ever. In addition the LDAP standards were mature and consolidating, so for interoperability it made sense to follow them more strictly. Luckily, a primary goal of the project has always been relatively easy migration from DSEE.

Today with Oracle holding its infrastructure products like DSEE in maintenance mode, it makes sense to leave yesterday's architecture behind and build directory services with DS/OpenDJ.

This article is not a step-by-step guide to making that change. Instead it highlights what you must consider when planning a migration from DSEE to DS/OpenDJ. We assume that you are already familiar with both products, and that you already have successfully managed similar projects in the past. If not, you can turn to one of ForgeRock’s partners, or you can complete the project yourself with the expectation that you will learn a lot along the way.

How DSEE differs from DS/OpenDJ

DS/OpenDJ aims for compatibility with DSEE, providing additional performance and features. There are nevertheless a number of important differences you must be aware of when moving from DSEE to DS/OpenDJ, including the following which are discussed in detail in subsequent sections:

  • LDAPv3: DSEE leniency versus DS/OpenDJ compliance.
  • Replication: DSEE peer-to-peer versus DS/OpenDJ hub-and-spoke.
  • Operational attributes and password policy: different attributes, additional DS/OpenDJ functionality.
  • Data Storage: DS/OpenDJ​​​​​​​ for portability and performance.
  • DSEE roles and CoS versus DS/OpenDJ​​​​​​​ groups, virtual and collective attributes.
  • DSEE ACIs versus DS/OpenDJ​​​​​​​ ACIs: no MACRO ACIs exist in DS/OpenDJ​​​​​​​.
  • PKI: DSEE NSS versus DS/OpenDJ​​​​​​​ Java®-based implementations.
  • Code Base: DSEE closed source C/C++ versus DS/OpenDJ​​​​​​​ open source Java.

LDAPv3: DSEE leniency versus DS/OpenDJ compliance

In some respects, DSEE is more lenient in what it accepts versus DS/OpenDJ.

Attribute Value Syntax Checking

LDAP attribute values are supposed to respect the syntax defined for the attribute. This means that applications can expect the attribute values they read from the centralized directory service to conform to the syntax, and therefore can handle the values in uniform ways.

The tradeoff is that applications that update directory entries have to perform more checking and processing of their input before sending it to the directory. When a user updates a telephone number manually, the application might have to transform that number to fit telephone number syntax before sending a modify request to the directory.

In DSEE, the decision was made to lighten the load on application developers by allowing non-conformant attribute values. This is the case for phone numbers and access control instructions (ACIs), for example.

In DS/OpenDJ, the default settings limit garbage coming in so as to reduce garbage going out.

If you can, clean up the data, and warn application maintainers that non-conformant values are going to be rejected.

If you cannot avoid accepting non-conformant values, then use the dsconfig command to change the advanced Global property: invalid-attribute-syntax-behavior.

Object Class Inheritance

DSEE does not apply this restriction from RFC 4512 section 2.4.2:

An object or alias entry is characterized by precisely one structural object class superclass chain which has a single structural object class as the most subordinate object class. This structural object class is referred to as the structural object class of the entry.

DS/OpenDJ follows the RFC by default. This can lead to errors when you try to use object class definitions that worked with DSEE, but do not follow the restriction.

One good way to work around the problem is to fix the schema definitions. You can often redefine some object classes as AUXILIARY rather than STRUCTURAL. Auxiliary object classes augment the characteristics of entries, letting you add attributes to entries without changing what the entries represent. For instance, the example-class-of-service-object-class near the outset of Example.ldif defines an Auxiliary object class. It lets you add classOfService, mailQuota, and diskQuota attributes to user entries. Common sense tells you it is better to employ an Auxiliary object class in the case of Class of Service. Clearly a user has a Class of Service; no user is a class of service.

Another workaround is to change DS/OpenDJ’s configuration to make it more lenient. Use the dsconfig command to change the advanced Global property: single-structural-objectclass-behavior. This workaround is recommended only as an expedient temporary measure allowing you quickly to test with DSEE schema definitions until you get a chance to fix the schema definitions in alignment with RFC 4512.

Attribute Names with Underscores

RFC 4512 allows attribute names to use letters, digits, and hyphens with the first character being a letter, basically: [A-Za-z][A-Za-z0-9-]*. If the schema definitions from DSEE have attribute names with underscores and applications depend on those names, it can be tough to fix them.

In such cases you can use the dsconfig command to change the advanced Global property: allow-attribute-name-exceptions.

Replication: DSEE peer-to-peer versus DS/OpenDJ hub-and-spoke

Both DSEE and DS/OpenDJ support multi-master replication with automated conflict resolution. Multi-master means that more than one replica (often all replicas) can handle both read and write operations. Automated conflict resolution means that if the directory service can resolve two conflicting write operations—such as different attribute values being written to the same entry at the same time on two different replicas—then it performs the resolution without any manual administrator action.

This is the killer feature of LDAP directories, making it easy to set up a service that continues working fine when a server or data center goes down. (The tradeoff of eventual consistency—eventually, but not instantly, replication makes data consistent across all replicas—is perhaps the Achilles heel of LDAP directories. Eventual consistency can be counterintuitive to developers used to relational databases and synchronous operations.)

In DSEE, replication traffic goes over LDAP. Replication is configured in peer-to-peer fashion, with each server having a replication agreement for each replica. Each DSEE replica must keep track of its state with respect to peer replicas. In a large deployment this leads to many replication agreements and complex configuration. It can also lead to a lot of traffic, including traffic over WAN links.

In DS/OpenDJ, replication traffic uses its own ports and its own protocol. A basic default configuration resembles the peer-to-peer arrangement used by DSEE. And yet there is a crucial design difference in DS/OpenDJ: the directory service and the replication service are separate, and can be set up in fact, on separate servers. In DS/OpenDJ​​​​​​​ the directory service responds to client requests. It also publishes its changes to the replication service, and subscribes to the replication service for changes from other directory servers. A directory server needs to connect only to one replication server at a time (potentially per suffix).

In DS/OpenDJ​​​​​​​, the replication service manages replication data only, handling replication traffic with directory servers and with other replication servers, receiving, sending, and storing only changes to directory data rather than full entry data itself. When you configure the two separately, you can significantly reduce the number of replication servers needed as described in the Administration Guide section on Administration Guide › Standalone Replication Servers. This can limit the traffic over WAN links for example.

When you move from DSEE to DS/OpenDJ​​​​​​​, you should therefore reconsider how replication is set up. In particular if you have many servers, or if you have a lot of update traffic, DS/OpenDJ​​​​​​​ is better designed to handle your needs tha DSEE, and you should take advantage of that.

Operational attributes and password policy: different attributes, additional DS/OpenDJ functionality

Operational attributes are those attributes used by the directory server for its own operation. They must be specified to be returned in an LDAP search for example.

Password policy attributes can be operational, or can be part of the user data.

Operational Attribute Differences

The following table maps DSEE operational attributes to those of DS/OpenDJ.

Note

This table is based on the documented DSEE operational attributes, and on DS/OpenDJ schema. This table does not include the DS/OpenDJ attributes that are not in DSEE.

DSEE DS/OpenDJ
accountUnlockTime N/A, calculated based on pwdAccountLockedTime
aci aci (compatible except for MACRO acis)
changeHasReplFixupOp N/A, DSEE RetroChangelog attribute
changeIsReplFixupOp N/A, DSEE RetroChangelog attribute
copiedFrom N/A, DSEE RetroChangelog attribute
copyingFrom N/A, DSEE RetroChangelog attribute
deletedEntryAttrs N/A, replication model is different
ds-pluginDigest N/A
ds-pluginSignature N/A
isMemberOf isMemberOf virtual attribute (configurable)
ldapSyntaxes ldapSyntaxes
namingContexts namingContexts, ds-private-naming-contexts
nsIdleTimeout idle-time-limit, ds-rlim-idle-time-limit
nsLookThroughLimit lookthrough-limit, ds-rlim-lookthrough-limit
nsRole N/A, can be simulated by creating an nsRole virtual attribute
nsds5ReplConflict N/A, replication model is different
nsRoleDN N/A, can be simulated by creating an nsRole virtual attribute
nsSizeLimit size-limit, ds-rlim-size-limit
nsTimeLimit time-limit, ds-rlim-time-limit
numSubordinates numSubordinates
passwordAllowChangeTime N/A, calculated based on pwdChangedTime
passwordExpWarned N/A
passwordExpirationTime N/A, calculated based on pwdChangedTime
passwordHistory pwdHistory
passwordPolicySubentry pwdPolicySubentry
passwordRetryCount N/A, calculated based on pwdFailureTime
pwdAccountLockedTime pwdAccountLockedTime
pwdChangedTime pwdChangedTime
pwdFailureTime pwdFailureTime
pwdGraceUseTime pwdGraceUseTime
pwdHistory pwdHistory
pwdLastAuthTime Depends on the last-login-time-attribute setting
pwdPolicySubentry pwdPolicySubentry
pwdReset pwdReset
replicaIdentifier replicaIdentifier
replicationCSN replicationCSN
retryCountResetTime N/A, calculated based on pwdAccountLockedTime
subschemaSubentry subschemaSubentry
supportedControl supportedControl
supportedExtension supportedExtension
supportedLDAPVersion supportedLDAPVersion
supportedSASLMechanisms supportedSASLMechanisms
targetUniqueId targetEntryUUID (alias targetUniqueID)
vendorName vendorName
vendorVersion vendorVersion

Password Policy Differences

DS/OpenDJ supports Internet-Draft Password Policy for LDAP Directories (version 09), but also server configuration-based password policies, with additional password policy features not available in DSEE. See Administration Guide › Configuring Password Policies for details.

The following tables map DSEE password policy attributes to DS/OpenDJ subentry policy attributes.

Note

This table is based on documented DSEE password policy attributes for the object class pwdPolicy.

DSEE DS/OpenDJ
pwdAllowUserChange pwdAllowUserChange
pwdCheckQuality N/A, use DS/OpenDJ​​​​​​​ password validators instead
pwdExpireWarning pwdExpireWarning
pwdFailureCountInterval pwdFailureCountInterval
pwdGraceAuthNLimit pwdGraceAuthNLimit
pwdInHistory pwdInHistory
pwdLockout N/A, calculated from other attributes
pwdLockoutDuration pwdLockoutDuration
pwdMaxAge pwdMaxAge
pwdMaxFailure pwdMaxFailure
pwdMinAge pwdMinAge
pwdMinLength N/A, use the length based password validator instead
pwdMustChange pwdMustChange
pwdSafeModify pwdSafeModify
Note

This table is based on documented DSEE password policy attributes for the object class passwordPolicy.

DSEE DS/OpenDJ
passwordChange See pwdAllowUserChange
passwordCheckSyntax N/A, use DS/OpenDJ​​​​​​​ password validators instead
passwordExp See require-change-by-time
passwordExpireWithoutWarning expire-passwords-without-warning
passwordInHistory See pwdInHistory
passwordLockout N/A, calculated from other attributes
passwordLockoutDuration See pwdLockoutDuration
passwordMaxAge See pwdMaxAge
passwordMaxFailure See pwdMaxFailure
passwordMinAge See pwdMinAge
passwordMinLength N/A, use the length based password validator instead
passwordMustChange See pwdMustChange
passwordNonRootMayResetUserpwd N/A, see the password-reset privilege
passwordResetDuration See pwdLockoutDuration
passwordResetFailureCount See pwdMaxFailure
passwordRootdnMayBypassModsChecks See skip-validation-for-administrators
passwordStorageScheme See default-password-storage-schemes
passwordUnlock N/A, off could be simulated with pwdLockoutDuration
passwordWarning See pwdExpireWarning

Data Storage: DS/OpenDJ for portability and performance

Like DSEE, DS/OpenDJ uses Berkeley DB technology to store user data. The implementations are different, however. Even if your data is perfectly compatible between DSEE and DS/OpenDJ, you must still export it to LDIF from DSEE and then import it into DS/OpenDJ.

Moreover indexes between DSEE and DS/OpenDJ​​​​​​​ are not configured in the same way. For each of your DSEE indexes that applies to user data, you must configure a corresponding index in DS/OpenDJ​​​​​​​. See Administration Guide › Indexing Attribute Values for instructions on setting up indexes in DS/OpenDJ​​​​​​​.

DSEE uses the C language Berkeley DB. The internal data representation is page based. DSEE data is portable from one server to another as long as the underlying host system is identical. You therefore need one DSEE backup server per host configuration.

DS/OpenDJ​​​​​​​ uses the Java language Berkeley DB by default to store user data. The internal data representation is log based. The log based representation affords DS/OpenDJ​​​​​​​ improved write performance. Throughput for write operations is often an order of magnitude better with DS/OpenDJ​​​​​​​ than with DSEE. Furthermore, DS/OpenDJ​​​​​​​ backups are fully portable between servers. You therefore need only one DS/OpenDJ​​​​​​​ backup server at a time.

DSEE roles and CoS versus DS/OpenDJ groups, virtual and collective attributes

Roles and Class of Service (CoS) in DSEE were implemented when Sun and Netscape server product teams worked together in iPlanet:

  • Roles are a proprietary feature of DSEE used to associate entries with different roles; somewhat similar to groups but reversed: groups have DNs pointing at members, role members have DNs (nsRole attribute) pointing at each role entry. See Migrating Oracle DSEE roles to DS/OpenDJ for further information.
  • CoS is a proprietary feature of DSEE used to manage attribute values that are common to many entries, in a single place. For example, the postal address might be an attribute that’s common to everyone in an organization. See Migrating Oracle DSEE CoS to DS/OpenDJ for further information.

DSEE ACIs versus DS/OpenDJ ACIs: no MACRO ACIs exist in DS/OpenDJ

DS/OpenDJ access control instructions aim to be strictly compatible with DSEE access control instructions, except that DS/OpenDJ does not support DSEE Macro ACIs. Nevertheless, test that your various ACIs produce the expected results after you migrate from DSEE to DS/OpenDJ. See Administration Guide › Configuring Privileges and Access Control for further information.

DS/OpenDJ employs global-aci settings in the server configuration, for server-wide access control.

DS/OpenDJ also has a privileges subsystem that provides access control for server administration operations independently from access control instructions.

PKI: DSEE NSS versus DS/OpenDJ Java-based implementations

DSEE relies on Netscape Security Services (NSS) for its keystore and truststore implementations. Sun Microsystems inherited the Netscape Certificate Management System for managing keys, but later discontinued the product. Although it was originally designed only for testing, the command-line certutil tool can be used to manage the keys.

DS/OpenDJ builds on Java-based PKI infrastructure for its keystore and truststore implementations. By default it uses Java Key Store (JKS), but you can also use other formats such as PKCS12 for the trust store or PKCS11 for the key store. The Administration Guide describes how to secure the ports listening for client connections and also how to change server certificates/key pairs.

Code Base: DSEE closed source C/C++ versus DS/OpenDJ open source Java

Oracle DSEE source code is not publicly available whereas DS/OpenDJ source code is available to all customers.

Plugin API

As a server implemented in the C language, DSEE provides a C-based plugin API, described in the DSEE Developer’s Guide. DSEE provides a number of plugin points.

As a pure Java server, DS/OpenDJ provides a large Java API, including a plugin API with even more plugin points than DSEE.

Note

Server APIs are considered evolving. It is likely that a future version of DS/OpenDJ will provide a more stable, but also more restricted plugin API, and that customization could be achieved through scripting languages like Groovy or JavaScript instead of compiled Java.

If you cannot avoid writing a plugin for DS/OpenDJ to match an existing DSEE plugin, know that you must re-implement the plugin in the Java language. Begin with the example plugin delivered with DS/OpenDJ, /path/to/ds/example-plugin.zip.

General DSEE to DS/OpenDJ migration phases

Moving from DSEE to DS/OpenDJ is not an upgrade. You must install DS/OpenDJDJ alongside DSEE, configure DS/OpenDJ appropriately and move your data from DSEE to DS/OpenDJ.

Installing DS/OpenDJ

This is a chance to take another look at the directory service architecture over all.

DS/OpenDJ's hub-and-spoke replication model can work in practice like DSEE's peer-to-peer model, so you might want the same replication topology as before. Or you can take the migration as an opportunity to split the replication service from the directory service, and reduce load over the WAN.

You can choose to retire older hardware, or even to move to a platform as a service. DS/OpenDJ has proven to work well in virtualized production environments.

Keep in mind that DS/OpenDJ performance tuning settings, for a variety of reasons, differ from DSEE tuning settings, so do not assume that what you have done to prepare for DSEE has exactly the same effect for DS/OpenDJ. If you have had to tune DSEE performance, subject DS/OpenDJ to the same performance tests you used for DSEE. When out-of-the-box performance with DS/OpenDJ is not good enough, read the Administration Guide for tuning tips.

Updating DS/OpenDJ schema definitions

Generally DS/OpenDJ​​​​​​​ schema definitions are compatible with those of DSEE, and customizations that you applied in DSEE also work in DS/OpenDJ.

But some of your DSEE data might not quite comply with DS/OpenDJ's more strict interpretation of object class inheritance and of attribute syntax checking. In practice, you apply schema customizations to DS/OpenDJ​​​​​​​, and then try to import your DSEE data with default (strict) settings for schema checking.

If errors arise during the import, figure out how to correct each error, and prepare automated error corrections so that you can apply them during migration.

Indexing directory data

DS/OpenDJ​​​​​​​ index configuration is done differently from DSEE index configuration.

For each attribute you must index, find the appropriate configuration in DS/OpenDJ​​​​​​​ so that when you import data it is indexed properly.

Adapting ACIs

Generally DS/OpenDJ​​​​​​​'s ACIs are compatible with those of DSEE, except that DS/OpenDJ​​​​​​​ does not have MACRO ACIs.

That said, test the impact of your ACIs in DS/OpenDJ​​​​​​​, and make sure there are no surprises.

If any bugs are found during testing, figure out how to correct the offending ACIs, and prepare automated error corrections so that you can apply them during migration.

Adapting password policy and account status attributes

As described above, DS/OpenDJ​​​​​​​ password policies and operational attributes differ from those of DSEE.

Adapt password policies and account status attributes after you export data from DSEE in order to achieve the desired effects in DS/OpenDJ​​​​​​​.

Prepare and test automated adaptations to apply during migration.

Moving from Roles and CoS to Virtual and Collective attributes

DS/OpenDJ​​​​​​​ does not use the Roles and Class of Service features provided by DSEE, but it supports all of the same use cases.

Adapt your Roles and CoS definitions for use with DS/OpenDJ​​​​​​​ as described in the DSEE Roles and CoS versus DS/OpenDJ​​​​​​​ Groups, Virtual and Collective attributes section above.

Prepare and test automated adaptations to apply during migration.

Rewriting server plugins

If you have custom DSEE server plugins that do something DS/OpenDJ​​​​​​​ does not do, then consider whether you still need the functionality.

Custom server plugins that you find you still need must be rewritten in Java and installed into DS/OpenDJ​​​​​​​. See /path/to/ds/example-plugin.zip where you installed DS/OpenDJ​​​​​​​ to get started.

Adapting PKI

When you install DS/OpenDJ​​​​​​​ separately from DSEE, you might also be getting new private-public key pairs to secure traffic on the DS/OpenDJ​​​​​​​ servers as part of installation, and so you can skip this phase.

In cases where you opt to reuse key pairs, you must export them from DSEE's NSS store and import them into DS/OpenDJ's Java-based store. Do consider the impact of potential differences in supported protocols and cipher suites.

Adapting backup and recovery strategies

As described above DS/OpenDJ​​​​​​​ backup is more portable than that of DSEE. Furthermore import is generally faster.

Adapt your backup and recovery plans accordingly. See How do I design and implement my backup and restore strategies for DS/OpenDJ (All versions)? for further information.

Adapting monitoring

DS/OpenDJ​​​​​​​ has logs, SNMP support, JMX monitoring as well as cn=monitor suffix similar to DSEE. And yet the content is not identical.

Adapt your monitoring capabilities to those of DS/OpenDJ​​​​​​​, so that you can achieve the same aims as with DSEE.

Adapting and importing data into DS/OpenDJ​​​​​​​

Once you have finished the steps above, you can test automated import.

Assuming the results of automated import are what you expect, then what you do depends on whether you can do the whole migration with the directory service offline, or whether you must keep the directory service online during migration.

Offline or live migration?

If you have a large enough maintenance window, you can perform offline migration:

  1. Perform the export process including all the adaptations described above.
  2. Import the adapted data into DS/OpenDJ.
  3. Verify that everything works as expected with DS/OpenDJ​​​​​​​.
  4. Point applications to DS/OpenDJ​​​​​​​.

If you must keep your directory service online during migration, then you must deal with changes that happen after the initial import to DS/OpenDJ​​​​​​​:

  1. Perform the export process including all the adaptations described above.
  2. Import the adapted data into DS/OpenDJ.
  3. Replay new changes in DSEE to DS/OpenDJ​​​​​​​ by using the DSEE retro changelog or audit log.
  4. Verify that everything works as expected with DS/OpenDJ​​​​​​​.
  5. Point applications to DS/OpenDJ​​​​​​​.
  6. Replay new changes in DS/OpenDJ​​​​​​​ to DSEE by using the DS/OpenDJ​​​​​​​ external changelog until the DSEE-based service is retired.
Note

When replaying the changes, take care to apply any necessary transformations where you must adapt DSEE data for use in DS/OpenDJ or DS/OpenDJ​​​​​​​ data for use in DSEE. The necessary adaptations are those described above.

See Also

Migrating Oracle DSEE roles to DS/OpenDJ

Migrating Oracle DSEE CoS to DS/OpenDJ

FAQ: Moving from Oracle DSEE to DS/OpenDJ

FAQ: Installing and configuring DS/OpenDJ

Migrating from Oracle DSEE to ForgeRock Directory Services

DS product page

DS product documentation

Related Training

ForgeRock Directory Services Core Concepts (DS-400)


Migrating Oracle DSEE CoS to DS/OpenDJ

The purpose of this article is to provide information on migrating Oracle® Directory Server Enterprise Edition (DSEE) or Sun® DSEE Class of Service (CoS) to DS/OpenDJ.

Class of Service

This is a proprietary feature of DSEE which allows the administrator to manage attribute values that are common to many entries, in a single place. For example, the postal address might be an attribute that’s common to everyone in an organization.

CoS is defined in an LDAP subentry. There are three kinds of CoS:

  • Pointer CoS - The subentry references another template entry (via cosTemplateDN) and defines which attributes (via cosAttributes) from the template appear in the target entries.
  • Indirect CoS - The subentry specifies which DN-valued attribute (cosIndirectSpecifier) in the target identifies the template entry, and then defines which attributes (via cosAttributes) to copy from the template to the target. The example in the DSEE docs uses the target’s manager attribute to select the template, and then copies one of the manager’s attributes across to the target.
  • Classic CoS - The subentry identifies the top of a subtree of template entries. An attribute (via cosSpecifier) in each target is used to select the child in the subtree, which becomes the template.

Collective attributes

These are a standard feature of LDAPv3, although implemented by DS/OpenDJ in a proprietary way. They are broadly similar to CoS, but different in that the subentry itself contains the attribute values to copy to the targets. The subentry also selects which entries in scope are given the attributes.

Pointer CoS maps very simply to a single subentry. Assuming users are held below ou=People,dc=example,dc=com, this subentry will give each one a common description:

dn: cn=Collective description subentry,dc=example,dc=com
cn: Collective description subentry
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
subtreeSpecification: { base "ou=People" }
description;collective: This is the shared value.

Indirect CoS can be implemented in DS/OpenDJ using one subentry for each template in the subtree. Each subentry uses a specificationFilter to identify different target entries:

dn: cn=Staff subentry,dc=example,dc=com
cn: Staff subentry
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
subtreeSpecification: { base "ou=People", specificationFilter "(employeeType=staff)" }
description;collective: This is the shared value for staff.
dn: cn=Contractor subentry,dc=example,dc=com
cn: Contractor subentry
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
subtreeSpecification: { base "ou=People", specificationFilter "(employeeType=contractor)" }
description;collective: This is the shared value for contractors.
Note

Classic CoS cannot easily be translated into collective attributes, as the attribute can only be defined in the subentry and is a combination of Pointer CoS and Indirect CoS.

See Also

Migrating from Oracle DSEE to DS/OpenDJ

Migrating Oracle DSEE roles to DS/OpenDJ

FAQ: Moving from Oracle DSEE to DS/OpenDJ

Developer's Guide › Collective Attributes

Installation Guide

Deployment Guide

Oracle DSEE - Directory Server Class of Service

Related Training

ForgeRock Directory Services Core Concepts (DS-400)


Migrating Oracle DSEE roles to DS/OpenDJ

The purpose of this article is to provide information on migrating Oracle® Directory Server Enterprise Edition (DSEE) or Sun® DSEE roles to DS/OpenDJ, including examples. References to DSEE in this article include ODSEE.

Roles

This is a proprietary feature of DSEE which allows the administrator to associate entries with different roles; somewhat similar to groups but reversed: groups have DNs pointing at members, role members have DNs (nsRole attribute) pointing at each role entry.

In general, DSEE roles are better implemented in DS/OpenDJ using groups and virtual attributes such as isMemberOf or virtual attributes with the is-member-of type. See Best practice for managing groups in DS/OpenDJ (All versions) for further information.

Roles are defined in an LDAP subentry. There are three kinds of roles:

  • Managed Role - Each entry has an nsRoleDN attribute pointing at each managed role the entry has.
  • Filtered Role - The role subentry contains a filter; each entry within the role’s scope and matching the filter is given the role.
  • Nested Role - The role subentry identifies a number of other roles (nsRoleDN) that belong to the role.
Note

To determine “role” membership, retrieve the isMemberOf attribute on the user entry in DS/OpenDJ. Do not read the group entries.

Managed role

DSEE Example

Managed roles in DSEE are defined using a role (nsManagedRoleDefinition) entry. Entries are assigned the role using a nsRoleDN with a value of the dn: equating to the role entry itself. 

In the following example, uid (user.0) gets assigned to the cn=Managed Role by adding the nsRoleDN: cn=Managed Role,ou=People,dc=example,dc=com to its entry.

dn: cn=Managed Role,ou=People,dc=example,dc=com
cn: Managed Role
description: DSEE/ODSEE Managed Role
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsSimpleRoleDefinition
objectclass: nsManagedRoleDefinition

dn: uid=user.0,ou=People,dc=example,dc=com
nsRoleDN: cn=Managed Role,ou=People,dc=example,dc=com

dn: uid=user.1,ou=People,dc=example,dc=com
nsRoleDN: cn=Managed Role,ou=People,dc=example,dc=com

dn: uid=user.2,ou=People,dc=example,dc=com
nsRoleDN: cn=Managed Role,ou=People,dc=example,dc=com

DS/OpenDJ Example

This is the most straightforward mapping; the resultant group entry has a member/uniqueMember attribute for each member of the group/entry with the role.

dn: cn=Managed Role,ou=Groups,dc=example,dc=com
cn: Managed Role
description: Like nsManagedRoleDefinition
objectClass: groupOfUniqueNames
objectClass: top
uniqueMember: uid=user.0,ou=People,dc=example,dc=com
uniqueMember: uid=user.1,ou=People,dc=example,dc=com
uniqueMember: uid=user.2,ou=People,dc=example,dc=com

Filtered role

DSEE Example

A filtered role (nsFilteredRoleDefinition) uses a basic LDAP search filter to return its members. Unlike a managed role, the nsRoleDN is not added to the users' physical entry.

Note

nsRole must be requested for the role to be returned.

dn: cn=Filtered Role,ou=People,dc=example,dc=com
cn: Filtered Role
description: DSEE/ODSEE Filtered Role
description: All Norwegian Employees
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
nsRoleFilter: (c=NO)

bash-4.2# ./ldapsearch -h localhost -p 10389 -D "cn=Directory Manager" -w ****** -s sub -b "dc=example,dc=com" "(uid=user.0)" nsRole
version: 1
dn: uid=user.0, ou=People, dc=example,dc=com
nsRole: cn=filtered role,dc=example,dc=com

DS/OpenDJ Example

This is also straightforward. Take the filter from the role subentry and use it in a groupOfURLs dynamic group entry. Testing group membership must be done by inspecting isMemberOf.

dn: cn=Filtered Role,ou=Groups,dc=example,dc=com
cn: Filtered Role
description: Like nsFilteredRoleDefinition
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(c=NO)
objectClass: top
objectClass: groupOfURLs

Nested role

DSEE Example 

Combinations of managed and filtered roles can be used to create nested roles.

dn: cn=Nested Role,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsNestedRoleDefinition
cn: Nested Role
nsRoleDN: cn=Managed Role,ou=People,dc=example,dc=com
nsRoleDN: cn=Filtered Role,ou=People,dc=example,dc=com
nsRoleScopeDN: ou=People,dc=example,dc=com

DS/OpenDJ Example

Only a limited range of nested roles can be converted, as DS/OpenDJ’s group nesting is limited to members of a static group. In other words, you cannot nest a dynamic group inside a static group.

If you need dynamic groups containing other dynamic groups, you could create a new dynamic group which copies the memberURL attributes from the other “nested” dynamic groups.

dn: cn=Filtered Managed Role,ou=Groups,dc=example,dc=com
cn: Filtered Managed Role
description: A dynamic group mirroring nested groups
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(isMemberOf=cn=Managed Role,ou=Groups,dc=example,dc=com)
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(isMemberOf=cn=Filtered Role,ou=Groups,dc=example,dc=com)
objectClass: top
objectClass: groupOfURLs

See Also

Migrating from Oracle DSEE to DS/OpenDJ

Migrating Oracle DSEE CoS to DS/OpenDJ

FAQ: Moving from Oracle DSEE to DS/OpenDJ

Installation Guide

Deployment Guide

Oracle DSEE - Directory Server Roles

Related Training

ForgeRock Directory Services Core Concepts (DS-400)


FAQ: Moving from Oracle DSEE to DS/OpenDJ

The purpose of this FAQ is to provide answers to commonly asked questions regarding moving from Oracle® Directory Server Enterprise Edition (DSEE) or Sun® DSEE to DS/OpenDJ.

Frequently asked questions

Q. What are the main changes I should be aware of when planning my migration from DSEE to DS/OpenDJ?

A. There are a number of key areas to take into consideration when planning your migration. Unfortunately, there is not a 'one size fits all' approach as it depends on your deployment.

The main changes that you should be aware of and investigate in terms of your deployment are:

  • LDAPv3 - DSEE is tolerant of certain schema and syntax errors; DS/OpenDJ enforces strict compliance. This can impact data migration as well as data runtime modifications.
  • Password policy - DSEE uses a legacy form of password policy; DS/OpenDJ uses an internet draft specification of password policy with additional capabilities.
  • Replication - DSEE is peer-peer and the DS does everything; DS/OpenDJ​​​​​​​ is hub (RS) and spoke (DS), and all RSs are fully meshed.
  • Database - DSEE uses Berkeley DB (C edition); DS/OpenDJ​​​​​​​ uses Berkeley DB (Java edition). On disk formats are very different.
  • Roles - DSEE implements iPlanet roles; DS/OpenDJ​​​​​​​ uses standard groups in addition to virtual attributes such as isMemberOf.
  • ACI - DSEE has macro ACIs; DS/OpenDJ​​​​​​​ does not. The syntax of ACIs is the same but is strictly checked in DS/OpenDJ​​​​​​​.
  • Class of service - this is specific to DSEE; DS/OpenDJenDJ uses collective attributes instead.
  • Certificates - DSEE uses NSS-based utilities; DS/OpenDJ​​​​​​​ uses Java-based utilities, and may have different ciphers.
  • API - DSEE has a C-based API for plugins; DS/OpenDJ​​​​​​​ uses Java and has a different API.

See Migrating from Oracle DSEE to ForgeRock Directory Services and Migrating from Oracle DSEE to DS/OpenDJ​​​​​​​ for further information on planning your migration.

Q. Can I export schema and data from DSEE and then import it into DS/OpenDJ?

A. Yes you can, but you must ensure the exported data does not include any replication metadata as this will cause conflicts; DSEE replication is not compatible with DS/OpenDJ replication.

Additionally, you will need to make changes to the schema prior to importing it such as removing DSEE specific values and entries:

Values not used

DS/OpenDJ​​​​​​​ uses entryUUID in place of nsUniqueId; likewise, it will create its own createTimestamp etc.

creatorsName: cn=Directory Manager
modifiersName: cn=Directory Manager
createTimestamp: 20040315171642Z
modifyTimestamp: 20040315171642Z
nsUniqueId: d88c698d-1dd111b2-80c8c04d-ec0219a2

Entries not used

The following type of entry is used only for DSEE Replication and cannot be used with DS/OpenDJ​​​​​​​; these must be removed as well.

# entry-id: 1
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, dc=sundsee,dc=com
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5433f974000000000000
nsds50ruv: {replica 1 ldap://localhost.localdomain:10389} 5433f9ff000000010000
  5433f9ff000000010000
nsds50ruv: {replica 2 ldap://opendj.sundsee.com:10390}
ds6ruv: {PRIO 1 ldap://localhost.localdomain:10389}
ds6ruv: {PRIO 2 ldap://opendj.forgerock.com:10390}
nsUniqueId: ffffffff-ffffffff-ffffffff-ffffffff

You can use the attached Perl script (dseeStripper.pl) to remove all these values and entries from a DSEE export.​ The script is executed using the following command:

$ cat [export ldif file] | ./dseeStripper.pl > [new ldif filename]

You may need to make other changes depending on your deployment to allow the schema to be successfully imported as DS/OpenDJ​​​​​​​ has strict LDAPv3 compliance and checking, and will reject errors that were tolerated in DSEE. This is likely to be an iterative process where you attempt an import, correct the errors, attempt another import and so on until your import is successful. You can relax the checking if required, although it is preferable to fix the errors to ensure you have standard LDAP data, which is more portable going forward.

Note

You can use any good text processing script language (such as Perl or Python) to make these additional changes.

See Administration Guide › Managing Schema for further information.

Q. Does DS/OpenDJ support DSEE roles?

A. No, DS/OpenDJ does not use roles; you should use dynamic and static groups in DS/OpenDJ to perform the same function as roles.

See Developer's Guide › Working With Groups of Entries and Migrating Oracle DSEE roles to DS/OpenDJ for further information.

Q. Is there an equivalent attribute in DS/OpenDJ for the DSEE attribute nsaccountlock?

A. Yes. DS/OpenDJ has a ds-pwp-account-disabled attribute, which is the equivalent of the DSEE nsaccountlock attribute. You can set this attribute using the manage account command and the set-account-is-disabled sub-command.

See Administration Guide › Managing Accounts Manually for further information.

Caution

If you disable an account in DS/OpenDJ by setting the ds-pwp-account-disabled attribute via Sun® IDM, the user's password is scrambled.

Q. Can I use the same index entry limit in DS/OpenDJ that I used in DSEE?

A. The default index entry limit for DS/OpenDJ is 4000 and this is considered sufficient for most indexes. It is not recommended that you increase this as it will have an impact on performance. DSEE recommended that the index entry limit (all-ids-threshold property) was set to 5% of the total number of users, which could result in a much higher limit than 4000.

See Administration Guide › Understanding Index Entry Limits for further information.

Q. Can our users keep their passwords when we migrate?

A. Yes. The password hashing support in DS/OpenDJ is backwards compatible with DSEE, so you should be able to migrate and keep the same passwords.

See Administration Guide › Configuring Password Policy for further information.

Q. Is the tuning I implemented for DSEE sufficient for DS/OpenDJ?

A. No. Tuning in DS/OpenDJ is completely different to DSEE and you should look to do some tuning once you have migrated to ensure the best performance.

See Administration Guide › Tuning Servers For Performance and FAQ: DS/OpenDJ performance and tuning for further information.

See Also

Migrating from Oracle DSEE to DS/OpenDJ

Migrating Oracle DSEE roles to DS/OpenDJ

Migrating Oracle DSEE CoS to DS/OpenDJ

Administration Guide

Migrating from Oracle DSEE to ForgeRock Directory Services


Copyright and TrademarksCopyright © 2019 ForgeRock, all rights reserved.

This content has been optimized for printing.

Loading...