Preparing Policy and Application Stores
This section explains how to prepare a DS server for use as an external policy or application data store.
In a new AM deployment, you can install new instances of DS for policy and/or application data. See "Installing and Configuring Directory Services for Policy and/or Application Data".
In deployments where there is existing policy and/or application data, you may prefer to migrate this data from the existing location alongside the configuration data, into new separate DS instances. See "Migrating Policy and/or Application Data to a DS Instance"
Installing and Configuring Directory Services for Policy and/or Application Data
The following instructions show how to install and set up the DS server.
Directory Services 6.5 added support for setup profiles to greatly simplify initial configuration.
Using a setup profile will create the backend, schema, bind user, and indexes required for use with policy and/or application data. Note that policy and application data has the same schema requirements as configuration data.
To install DS using a setup profile, follow the steps in DS for AM Configuration Data in the Directory Services 7 Installation Guide.
Important
Ensure that you specify the same base DN value as your configuration store when using a setup profile to create a policy or application store. For example:
--set am-config/baseDn:"dc=example,dc=com"
Creating a separate DS backend for policies and/or applications in the configuration store is not supported.
Share the store certificate with the AM container to prepare for TLS/LDAPS. Application and policy stores should communicate over secure connections for security reasons.
DS 7 or later is configured to require secure connections by default; therefore, share its certificate with the AM container before continuing.
Export the DS server certificate:
$
/path/to/opendj/bin/dskeymgr export-ca-cert \ --deploymentKey $DEPLOYMENT_KEY \ --deploymentKeyPassword password \ --alias ds-ca-cert \ --outputFile ds-ca-cert.pem
Note that
$DEPLOYMENT_KEY
is a Unix variable that contains the DS deployment key, so that it is not logged in the user's command history.The default DS server certificate only has the hostname you supplied at setup time, and
localhost
, as the value of theSubjectAlternativeName
attribute; however, certificate hostname validation is strict.Ensure that the certificate matches the hostname (or the FQDN) of the DS server before continuing.
Import the DS certificate into the AM truststore:
$
keytool \ -importcert \ -alias ds-ca-cert \ -file ds-ca-cert.pem \ -keystore /path/to/openam/security/keystores/truststore
For more information on configuring AM's truststore, see "Preparing a Truststore".
You have successfully installed and prepared the DS directory server for use as an external policy or application store.
You can use the instance created in these procedures for both policy and application data simultaneously. To have separate instances for policies and applications, repeat the previous step to create an additional external policy or application store.
Proceed to configuring AM to use the prepared DS directory servers as external policy or application stores, see Policy and Application Stores.
The bind DN of the default AM service account used to authenticate to the external store has the form:
uid=am-config,ou=admins,Base DN
Migrating Policy and/or Application Data to a DS Instance
If you are upgrading existing AM instances to use external DS instances for policy and/or application data, you may want to migrate that existing data into the new instances. Migrating policy and/or application data to a separate store allows tuning and scaling of the more dynamic data, separately from the more static nature of configuration data.
This section covers the following high-level methods for migrating policy and/or application data to new DS instances:
Exporting and Importing Data in DS by using LDIF
This section gives an overview of migrating data to new DS instances by using the import-ldif
and export-ldif
commands.
The top-level steps are as follows:
Install a DS instance to store the policy and/or application data, by following the steps in "Installing and Configuring Directory Services for Policy and/or Application Data".
Use the export-ldif command to create an LDIF file of the structure of the new DS instance.
For example:
$
/path/to/opendj/bin/export-ldif \ --hostname 'config.example.com' \ --port 4444 \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePasswordFile /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ --backendId cfgStore \ --ldifFile /tmp/Apps_and_or_Policies.ldif
Use the export-ldif command to append to the previous LDIF file your existing policy and/or application data.
Tip
The export-ldif command has a
--includeBranch
option to limit the data exported to just policy and/or application data.See the following commands to export application data, policy data, or both:
$
/path/to/opendj/bin/export-ldif \ --hostname 'config.example.com'\ --port 4444 \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePasswordFile /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ --includeBranch o=sunamhiddenrealmdelegationservicepermissions,ou=services,dc=example,dc=com \ --includeBranch ou=AgentService,ou=services,dc=example,dc=com \ --includeBranch ou=sunEntitlementService,ou=services,dc=example,dc=com \ --includeBranch ou=sunEntitlementIndexes,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMCOTConfigService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMIDFFMetadataService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMSAML2MetadataService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMWSFederationMetadataService,ou=services,dc=example,dc=com \ --backendId appData \ --appendToLdif \ --ldifFile /tmp/Apps_and_or_Policies.ldif
$
/path/to/opendj/bin/export-ldif \ --hostname 'config.example.com'\ --port 4444 \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePasswordFile /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ --includeBranch ou=sunEntitlementService,ou=services,dc=example,dc=com \ --includeBranch ou=sunEntitlementIndexes,ou=services,dc=example,dc=com \ --includeBranch o=sunamhiddenrealmdelegationservicepermissions,ou=services,dc=example,dc=com \ --backendId appData \ --appendToLdif \ --ldifFile /tmp/Apps_and_or_Policies.ldif
$
/path/to/opendj/bin/export-ldif \ --hostname 'config.example.com'\ --port 4444 \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePasswordFile /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ --includeBranch ou=AgentService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMCOTConfigService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMIDFFMetadataService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMSAML2MetadataService,ou=services,dc=example,dc=com \ --includeBranch ou=sunFMWSFederationMetadataService,ou=services,dc=example,dc=com \ --backendId appData \ --appendToLdif \ --ldifFile /tmp/Apps_and_or_Policies.ldif
Replace dc=example,dc=com in the commands above with your base DN value.
To also export policy and/or application data from subrealms, repeat the previous step, but altered to include the path to the subrealm in the included branches.
For example, to export data from a realm named
mySubRealm
, addou=services,o=mySubRealm,
into each of the included branches, as shown below:$
/path/to/opendj/bin/export-ldif \ --hostname 'config.example.com'\ --port 4444 \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePasswordFile /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ --includeBranch o=sunamhiddenrealmdelegationservicepermissions,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=AgentService,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=sunEntitlementService,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=sunEntitlementIndexes,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=sunFMCOTConfigService,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=sunFMIDFFMetadataService,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=sunFMSAML2MetadataService,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --includeBranch ou=sunFMWSFederationMetadataService,<replaceable>ou=services,o=mySubRealm,</replaceable>ou=services,dc=example,dc=com \ --backendId appData \ --appendToLdif \ --ldifFile /tmp/Apps_and_or_Policies.ldif
Repeat this step for each subrealm that contains application and/or policy data you want to transfer to an external store.
Edit the LDIF file to include the required top-level
ou=services
entry. For example, after the entry fordn: dc=example,dc=com
add the following:dn: ou=services,dc=example,dc=com objectclass: top objectclass: organizationalunit objectclass: sunServiceComponent ou: services
Note that the example above requires a blank line both before and after, and you must replace dc=example,dc=com with your base DN value.
The start of the resulting LDIF will resemble the following:
dn: dc=example,dc=com objectClass: top objectClass: untypedObject dc: openam aci: (targetattr="*")(version 3.0;acl "Allow CRUDQ operations";allow (search, read, write, add, delete)(userdn = "ldap:///uid=am-config,ou=admins,dc=example,dc=com");) aci: (targetcontrol="2.16.840.1.113730.3.4.3")(version 3.0;acl "Allow persistent search"; allow (search, read)(userdn = "ldap:///uid=am-config,ou=admins,dc=example,dc=com");) aci: (targetcontrol="1.2.840.113556.1.4.473")(version 3.0;acl "Allow server-side sorting"; allow (read)(userdn = "ldap:///uid=am-config,ou=admins,dc=example,dc=com");) entryUUID: 5beee9ea-1c31-3129-a8f9-c79da3102f26 dn: ou=services,dc=example,dc=com objectclass: top objectclass: organizationalunit objectclass: sunServiceComponent ou: services dn: ou=admins,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: admins ... ...
Repeat the previous step to create the parent entries for any subrealms that you exported.
For example, before the
ou=admins,dc=example,dc=com
line, add the following for a subrealm namedmySubRealm
:dn: o=mySubRealm,ou=services,dc=example,dc=com objectClass: sunRealmService objectClass: top o: mySubRealm dn: ou=services,o=mySubRealm,ou=services,dc=example,dc=com objectClass: organizationalUnit objectClass: sunServiceComponent objectClass: top ou: services
Note that the example above requires a blank line both before and after, and you must replace dc=example,dc=com with your base DN value.
The start of the resulting LDIF will resemble the following:
dn: dc=example,dc=com objectClass: top objectClass: untypedObject dc: openam aci: (targetattr="*")(version 3.0;acl "Allow CRUDQ operations";allow (search, read, write, add, delete)(userdn = "ldap:///uid=am-config,ou=admins,dc=example,dc=com");) aci: (targetcontrol="2.16.840.1.113730.3.4.3")(version 3.0;acl "Allow persistent search"; allow (search, read)(userdn = "ldap:///uid=am-config,ou=admins,dc=example,dc=com");) aci: (targetcontrol="1.2.840.113556.1.4.473")(version 3.0;acl "Allow server-side sorting"; allow (read)(userdn = "ldap:///uid=am-config,ou=admins,dc=example,dc=com");) entryUUID: 5beee9ea-1c31-3129-a8f9-c79da3102f26 dn: ou=services,dc=example,dc=com objectclass: top objectclass: organizationalunit objectclass: sunServiceComponent ou: services dn: o=mySubRealm,ou=services,dc=example,dc=com objectClass: sunRealmService objectClass: top o: mySubRealm dn: ou=services,o=mySubRealm,ou=services,dc=example,dc=com objectClass: organizationalUnit objectClass: sunServiceComponent objectClass: top ou: services dn: ou=admins,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: admins ... ...
Use the import-ldif command to add the updated LDIF data to the new instance. For example:
$
/path/to/opendj/bin/import-ldif \ --hostname external.example.com \ --port 4444 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePasswordFile /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword str0ngAdm1nPa55word \ --backendId cfgStore \ --ldifFile /tmp/Apps_and_or_Policies.ldif
Configure AM to use the new store for policy and/or application data, by following the steps in "Setting Up Policy and Application Stores.".
For more information and the specific steps for importing and exporting LDIF data, see Data Storage in the DS Configuration Guide.
Backing Up and Restoring a DS Instance
This section gives an overview of migrating data to new DS instances by using the DS backup and restore commands.
The top-level steps are as follows:
Use the backup command to make a backup copy of the existing configuration store.
Install a DS instance to store the policy and/or application data, by following the steps in "Installing and Configuring Directory Services for Policy and/or Application Data".
Note that the DS instance MUST have the same base DN, and backend name, as the instance from which the backup was created.
Use the restore command to restore your policy and/or application data to the new store.
Configure AM to use the new store for policy and/or application data, by following the steps in "Setting Up Policy and Application Stores.".
For more information and the specific steps for performing backup and restore operations in DS, see Backup and Restore in the DS Maintenance Guide, and To Initialize a Replica From Backup Files in the DS Configuration Guide.