Hi Jeff, Of course there is way. 1. In a browser login to oxTrust, go to `Configuration` > `JSON configuration` 1. Grab the value of field `orgInum` 1. Login to your Gluu server, eg `service gluu-server-3.1.2 login` 1. Issue this command replacing `orgInum` appropriately and suppyling the admin password ``` /opt/opendj/bin/ldapsearch -h localhost -p 1636 -D "cn=directory manager,o=gluu" -w PASSWORD -ZXT -b 'ou=people,o=ORGINUM,o=gluu' "(objectclass=oxDeviceRegistration)" > creds.ldif ``` If your LDAP is openDJ, the *bindDN* option should be "cn=directory manager" only The above creates a file named `creds.ldif`. Now, grab the `orgInum` of the 3.1.3 server and replace all occurrences of `o=OLD_ORG_INUM` with `o=NEW_ORG_INUM`. You can edit this in a plain text editor. Next step is reimporting into your fresher LDAP. 1. Copy `creds.ldif` to a location like `/opt/gluu-server-3.1.3/root`: 1. Login to your Gluu server, eg `service gluu-server-3.1.3 login` 1. Issue the following command: ``` /opt/opendj/bin/ldapmodify -h localhost -p 1636 -D "cn=directory manager,o=gluu" -w PASSWORD --trustAll --useSSL -a -f /root/creds.ldif ``` That should do. **Note**: If the new server you are setting up has a different base URL, you may also need to adjust accordingly the attribute `oxApplication` for each entry in the file beforehand. Then test it (one security key and one supergluu), I am not quite sure at the moment if changing the U2F app ID has an important impact in this case.

OK, I figured the first part out: `root@gluu:~/# /opt/opendj/bin/ldapsearch -p 1636 -Z -X -D 'cn=directory manager,o=gluu' -w password -b "o=gluu" "objectclass=oxDeviceRegistration" > oxDeviceRegistration.ldif` This generates a file containing what appears to be the credentials, but with the inum of the user for the old server. It looks like OTP is handled differently, but first things first.

Jeff, If you want to do a direct 1:1 transition of users from one Gluu Server installation to another, you need to provide a setup.properties file from a previous version that is properly formatted. This is because a lot of unique identifiers, specifically the GUID's in the inums, differ between each installation. A minimum viable `setup.properties` file used while runinng `setup.py` would look something like this: ``` city=Austin installOxAuth=True installOxTrust=True inumAppliance=$YOUR_APPLIANCE_INUM countryCode=US installOxAuthRP=False orgName=Gluu, Inc ip=45.55.232.15 hostname=c7.gluu.org ldapPass=secret installSaml=True application_max_ram=4000 inumOrg=$YOUR_ORGANIZATIONAL_INUM installHTTPD=True state=TX installPassport=True ldap_type=opendj installJce=True jksPass= admin_email=dc@gluu.org installLDAP=True ``` Note an appliance inum will be formatted like this `@!5D14.DF29.461E.DC13!0002!63EF.FAD9` while an organizational inum will be formatted like this `@!5D14.DF29.461E.DC13!0001!A93C.3BFC`. You'll note some similarities between the 2, only being differentiated by the appliance marker `!0002!` and the organizational marker `!0001!` and some unique GUID's afterwards. Both of these values can be found in oxTrust by navigating to `Configuration` -> `JSON Configuration` -> `oxTrust Configuration`. `orgInum` and `applianceInum`. The rest of the values will tell you the options you want to install: `installOxAuth`, `installOxTrust`, `installOxAuthRP` (This is a testing tool), `installSaml` (Shibboleth IDP), `installHTTPD` (Apache2), `installPassport`. Some of the other options are for self-signed certificates during installation: `city`, `state`, `countryCode`, `admin_email`, `hostname` (Used elsewhere too). If I were you, I would gather the values from your old install, re-install a new instance of Gluu Server, save this file inside the Gluu chroot at `/install/community-edition-setup/setup.properties` and run `setup.py`. This will ingest the values of `setup.properties` and give you minimum prompts to continue the installation. After that you'll have an easy to migrate installation of Gluu Server ready to import. Note there may be some issues with links to other resources in the user data, like groups, etc.