In this scenario, you want to use Sun Java System Directory Server as the OpenSSO Enterprise user data store, but the required OpenSSO schema files have not been loaded into Directory Server.
If you configuring OpenSSO Enterprise using the Configurator, you can simply specify Directory Server as the user data store, as described in Chapter 4, Configuring OpenSSO Enterprise Using the GUI Configurator or Chapter 5, Configuring OpenSSO Enterprise Using the Command-Line Configurator.
Otherwise, you must load the OpenSSO schema and index LDIF files using the Directory Server Console, Directory Service Command Center (DSCC), or a command-line utility such as ldapmodify, depending on the version of Directory Server you are using and your personal preference.
The LDIF files you must load into Directory Server are:
zip-root/opensso/ldif/sunone_schema2.ldif
zip-root/opensso/ldif/ds_remote_schema.ldif
zip-root/opensso/ldif/fam_sds_schema.ldif
zip-root/opensso/ldif/fam_sds_index.ldif
zip-root/opensso/ldif/index.ldif
zip-root/opensso/ldif/plugin.ldif
where zip-root is the directory where you unzipped opensso_enterprise_80.zip.
In fam_sds_index.ldif and index.ldif, replace @DB_NAME@ with the name of your backend DB.
The index creation LDIF files require the backend DB name. Both index.ldif and fam_sds_index.ldif contain the @DB_NAME@ variable to represent the backend DB name of the specific instance where you originally deployed OpenSSO Enteprise.
For example, a system with the dc=openssohost,dc=example,dc=com suffix, an index entry might look like:
dn: cn=nsroledn,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=memberof,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=iplanet-am-static-group-dn,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=iplanet-am-modifiable-by,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=sunxmlkeyvalue,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=o,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=ou,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=sunPreferredDomain,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=associatedDomain,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config dn: cn=sunOrganizationAlias,cn=index,cn=openssohost,cn=ldbm database,cn=plugins,cn=config
To determine the name of the backend database, use either of these methods:
Use the ldapsearch utility. For example:
ldapsearch -h host-name -p port-number -s base -b "cn=config" -D \ "cn=directory manager" -w password "objectclass=*" | grep backend nsslapd-backendconfig=cn=config,cn=red,cn=ldbm database,cn=plugins,cn=config
In this example, the suffix is dc=red,dc=iplanet,dc=com, and the backend database name is red.
Check the nsslapd-backend property in the Directory Server instance's dse.ldif file.
Load the LDIF files into Directory Server, in this order:
sunone_schema2.ldif
ds_remote_schema.ldif
fam_sds_schema.ldif
fam_sds_index.ldif
index.ldif
plugin.ldif
For example, using ldapmodify:
ldapmodify -h dshost -p dsport -D "cn=directory manager" -w dmpasswd -c -f sunone_schema2.ldif ldapmodify -h dshost -p dsport -D "cn=directory manager" -w dmpasswd -c -f ds_remote_schema.ldif ldapmodify -h dshost -p dsport -D "cn=directory manager" -w dmpasswd -c -f fam_sds_schema.ldif ldapmodify -h dshost -p dsport -D "cn=directory manager" -w dmpasswd -c -a -f fam_sds_index.ldif ldapmodify -h dshost -p dsport -D "cn=directory manager" -w dmpasswd -c -a -f index.ldif ldapmodify -h dshost -p dsport -D "cn=directory manager" -w dmpasswd -c -a -f plugin.ldif
where dshost and dsport are the Directory Server host name and port, and dmpasswd is the Directory Manager password.
Note: If you encounter a SASL BIND error use the -x option with ldapmodify.
Create a new file named ldapentries:
Add the entries shown in Example 18–1.
In the ldapentries file, replace:
dc=example,dc=com with your root suffix
dsameuser-password and amldapuser-password with your actual passwords
Load the entries in ldapentries. For example:
ldapmodify -h dshost -p dsport -D "cn=directory manager" \ -w dmpasswd -c -a -f ldapentries
In the OpenSSO Enterprise Admin Console, create a new data store with the Directory Server that you just configured with the OpenSSO schema:
Log in to the Console as amadmin.
Click Access Control, realm-name, Data Stores, and then New.
Specify the new data store Name.
Specify the Type as Sun DS with OpenSSO schema and then click Next.
Specify the LDAP Bind DN as cn=dsameuser,ou=dsame users,root-suffix, where root-suffix is the root suffix for the Directory Server user data store.
Specify other values as required for your deployment, and then click Finish.
dn: ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit dn: ou=agents,dc=example,dc=com objectClass: top objectClass: organizationalUnit dn: ou=groups,dc=example,dc=com objectClass: top objectClass: organizationalUnit dn: ou=dsame users,dc=example,dc=com objectClass: top objectClass: organizationalUnit dn: cn=dsameuser,ou=DSAME Users,dc=example,dc=com objectclass: inetuser objectclass: organizationalperson objectclass: person objectclass: top cn: dsameuser sn: dsameuser userPassword: dsameuser-password dn: cn=amldapuser,ou=DSAME Users,dc=example,dc=com objectclass: inetuser objectclass: organizationalperson objectclass: person objectclass: top cn: amldapuser sn: amldapuser userPassword: amldapuser-password dn:dc=example,dc=com changetype:modify add:aci aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "S1IS special dsame user rights for all under the root suffix"; allow (all) userdn = "ldap:///cn=dsameuser,ou=DSAME Users,dc=example,dc=com"; ) dn:dc=example,dc=com changetype:modify add:aci aci: (target="ldap:///dc=example,dc=com")(targetattr="*")(version 3.0; acl "S1IS special ldap auth user rights"; allow (read,search) userdn = "ldap:///cn=amldapuser,ou=DSAME Users,dc=example,dc=com"; )
You can now use Directory Server as the OpenSSO Enterprise 8.0 user data store.