Tuesday Mar 31, 2009

Get Off My Case if You Can't Export OpenSSO Configuration Data

I wanted to export the configuration data on my install of OpenSSO so I went back to the directory that was created after I expanded opensso.zip to setup the ssoadm command line utility. Here are the steps I followed.
  1. Set JAVA_HOME and PATH variables to point to the correct version of Java; in this case, version 1.5.
    # JAVA_HOME=/usr/java/jdk1.5.0_14
    # export JAVA_HOME
    # PATH=$JAVA_HOME/bin:$PATH;
    # export PATH
  2. Create a directory into which you will expand the ssoAdminTools.zip.
    # mkdir /ssoadmtool
  3. Unzip ssoAdminTools.zip into the top-level directory created.
    # cd /opensso/tools
    # unzip ssoAdminTools.zip -d /ssoadmtool
    # cd /ssoadmtool
    # ls -la
    total 320
    drwxr-xr-x   6 root     root          10 Mar 31 10:42 .
    drwxr-xr-x  42 root     root          47 Mar 31 08:16 ..
    -rw-r--r--   1 root     root        4796 Mar 18 01:31 README.setup
    drwxr-xr-x   2 root     root          25 Mar 18 03:55 lib
    -rw-r--r--   1 root     root       17003 Mar 18 01:31 license.txt
    drwxr-xr-x   3 root     root           3 Mar 31 10:42 opensso
    drwxr-xr-x   2 root     root        1161 Mar 18 03:55 resources
    -rwxr-xr-x   1 root     root        2638 Mar 18 01:31 setup
    -rw-r--r--   1 root     root        3182 Mar 18 01:31 setup.bat
    drwxr-xr-x   4 root     root           4 Mar 18 01:31 template
  4. Run setup from the top-level ssoadmtool directory.
    # ./setup
    Path to config files of OpenSSO server (example: /opensso):/opensso
    Debug Directory:/opensso/debug
    Log Directory:/opensso/log
    The scripts are properly setup under directory: /ssoAdmin/opensso
    Debug directory is /opensso/debug.
    Log directory is /opensso/log.
    The version of this tools.zip is: (2009-March-18 01:14)
    The version of your server instance is: (2009-March-18 01:14)
  5. Run ssoadm using the export-svc-cfg option.

    ./ssoadm export-svc-cfg -e secretenckey -o /var/tmp/config.xml -u amadmin -f /tmp/password

    • e defines the key that will be used to encrypt any sensitive information in the configuration data store.
    • o defines the name and location of the XML file to which the configuration data will be written.
    • u defines the OpenSSO administrator; by default, amadmin.
    • f defines the name and location of the file that contains the OpenSSO administrator's password.

    config.xml is created in /var/tmp and contains the configuration data stored in the OpenSSO embedded configuration data store.
Now I'm exporting (-o you) the loveliness that is the Comateens singing Get Off My Case in the old train station in Hoboken, New Jersey. They are a great band singing in a great city in an OK state. And I would know - I lived in Hoboken for three years.

Monday Dec 01, 2008

Stopping and Starting an External Configuration Data Store is Björn Again

Thanks to OpenSSO members Christopher and Michel for this information.
OpenSSO uses an LDAP server for persistence of its configuration data so the LDAP server that contains this configuration data must be available when OpenSSO is running. After a default installation OpenDS, which is embedded with OpenSSO, will stop and start as OpenSSO does. If OpenSSO is installed pointing to an instance of Directory Server for its configuration data, Directory Server needs to be stopped and started on its own. The best way to do this is to stop the underlying OpenSSO web container first and Directory Server second - reversing the order for the imminent restart. This insures that the configuration data is always available for the OpenSSO web application.

That said, I've noticed a few people (externally and internally) asking about an Invalid Domain - No such Organization found error that is displayed when attempting to log in to the console using the default URL (http://web-server-host:port/opensso/UI/Login) after restarting an instance of Directory Server 5.2 configured as the OpenSSO configuration data store. If you see this error message, do the following:
  1. Login to the OpenSSO console at http://web-server-host:port/opensso/UI/Login?org=LDAP-DN-root.
  2. Under the Access Control tab, click the / (Top-level Realm).
  3. Add another host name to the Realm/DNS Alias property of the / (Top-level Realm) and click Save.
    The information will be removed so MacGuffin text is fine.
  4. Restart the deployment as previously detailed.
  5. Login to the OpenSSO console using the default URL and remove the host name you just added.
This workaround forces OpenSSO to export the Realm/DNS Alias values to the external Directory Server. The following search returns zero results before the workaround and should return one result after it.

SRCH base="ou=services,DN" scope=2 filter="(|(&(objectClass=sunRealmService)(&(|(sunxmlkeyvalue=sunidentityrepositoryservice-sunOrganizationAliases=hostname.site.com)(sunxmlkeyvalue=sunOrganizationAliases=hostname.site.com))))(&(objectClass=sunServiceComponent)(&(|(sunxmlkeyvalue=sunidentityrepositoryservice-sunOrganizationAliases=hostname.site.com)(sunxmlkeyvalue=sunOrganizationAliases=hostname.site.com)))))" attrs="o"

While you're waiting for the restart, enjoy Stop, the ABBA-esque version of the Erasure song by Björn Again.




« February 2016