Steps for an easy migration from LinOTP

Howtos
1

Hey,

as long time users of LinOTP we would like to migrate to privacyIDEA. I already stumbled upon a migration script which is supposed to migrate the tokens and the assignments.

I was wondering what the the recommended workflow for a migration is. My idea was

  1. Setting up a clean privacyIDEA instance
  2. Set up the realms and User resolvers the same way they are currently in LinOTP
  3. Run the migrate script
  4. ???
  5. Profit

Will this just work or are there further things to consider, e.g. copying over the encKey? Or is this only required if I would also like to migrate over the resolver configuration including encrypted passwords from the LinOTP servers?

Cheers,

Basti

2

Welcome to privacyIDEA, Basti!

Disclaimer: During the migration by default we keep the encrypted data. We only migrate the contents of the LinOTP token table.
If you need to change the encryption or if you need to update the counters of the tokens, because you might have tens of thousands of users, this is also possible, but not covered by my comment. In this case you definitively should get professional help.

Assumption: Having said this I assume you are migrating only a several hundrets of tokens.

So you should go like this:

  1. Set up a fresh privacyIDEA installation.

  2. Copy the encryption key from LinOTP to privacyIDEA, since in the default migration we keep the encryption. Take /etc/linotp2/encKey and place it in /etc/privacyidea/enkey on your new privacyIDEA machine. (File access rights!)

  3. Configure all policies, system settings you want to have in privacyIDEA. We do not migrate those.

  4. Set up your resolvers and your realms in privacyIDEA. They do not need to have the same names, but they need to create the same UID! E.g. if you have an LDAP-Resolver “linotpusers” in “realm1” which are identified by the DN, then you can set up an LDAP-Resolver “privacyideausers” in “domain1” for users identified by DN. You can not change the uidtype.

  5. As you probably have privacyIDEA not running on the same machine like the old LinOTP system and since you probably have not opened the mysql port on the LinOTP server, I recommend to make a dump of the LinOTP token table::

     mysqldump -u root -p linotp2 Token > linotp-token.sql

  6. Now you can create a database (or only a table) on the mysql instance of your privacyIDEA system and add the linotp-tokentable there. Makes life a lot easier.

  7. Get the migration script. Note: The migration script contains a sample configuration. Till now it does not take a config file, i.e. you need to adapt some settings directly in the script! You can copy the script to your local folder and make adaptions there:

  8. Now you can run the migration script.
    Note: The migration script operates directly on the database level.
    I recommend running the migration script on a privacyIDEA database with no tokens. If you run the migration script twice or you already have tokens in the database, the migration script will try to insert all new tokens. I there is already a token with the same serial number, then inserting will fail…

  9. Check your new privacyIDEA system. Get an old token and try to authenticate against privacyIDEA.

  10. Save the environment and turn of the LinOTP system and enjoy :slight_smile:

Kind regards
Cornelius

3

Hey Cornelius,

thanks for the quick and detailed reply. I tried to follow the instructions you gave and could succesfully import all the tokens, however I am experiencing problems with user resolving.

The mappings look fine:
Realm-Map: {u’gbl’: 4L, u’adm_admins’: 6L, u’ces’: 5L, u’defrealm’: 1L, u’campus_admins’: 7L, u’adm_users’: 3L, u’campus’: 2L}
Resolver-Map: {u’ADM_LDAP’: 5L, u’CES_LDAP’: 6L, u’CAMPUS_LDAP’: 2L, u’deflocal’: 1L, u’CAMPUS_LDAP_ADM’: 4L, u’GBL_LDAP’: 3L}

But the tokens only seem to get assigned halfway to the correct realms:
For these assigned tokens the “realm” column in the token view is empty. In the detailed view for a token the “Realms” value in the Token Details table is correct with e.g. “campus”, but the user table looks like this:

Username: resolver error
Realm:
Resolver: CAMPUS_LDAP
User Id: CN=Correct AD LDAP Information,OU=IT,DC=CAMPUS,…

So the AD LDAP information seems to be imported correctly, but the user itself seems to not be part of a realm which in turn seems to cause the resolver error. Did I miss a crucial step here?

Cheers,

Basti

4

Hi again,

I was able to figure out the problem:

After unassigning one of the tokens and then succesfully reassigning it to the correct user I saw that the LDAP attribute type to determine the user was objectGUID.
This is the default settings when creating a new LDAP user resolver and “Preset Active Directory”; the same is actually true for LinOTP.
However my LinOTP user resolver had DN to determine UID type. Now I need to figure out why DN was used instead of objectGUID. Maybe Legacy defaults or whatever.

Now I need to have someone try some authenticating.
Is there a possibility to also import the user resolvers and realms from LinOTP easily? Resetting these up was quite cumbersome.

Cheers,

Basti

5

Hi Basti,

no, currently we do not migrate the resolvers and realms. Why? Because this would be prone to errors.
In LinOTP all configuration is stored in one config table. As we operate only on the database level, this would be a quite tricky logic to extract the resolvers and realms.

I think in most cases you do not have more than a handfull of resolvers and realms, so in 90% it is ok to go through this. In addition - this might be a good chance to reconsider some configurations! :wink:

Kind regards
Cornelius