FusionAuth has a bunch of import scripts, but one that you are probably most interested in is the CSV importer, which takes a CSV file and then calls the user import API.

Here's the link: https://github.com/FusionAuth/fusionauth-import-scripts/tree/main/csv

Of course, LDIF is not CSV.

Instead of using a CSV gem to get the list of users and their attributes, use a gem that can read LDIF. Here's a candidate. https://www.rubydoc.info/gems/ruby-ldap/0.9.19/LDAP%2FLDIF.parse_file but I'm not sure what the state of the art for ruby LDIF parsing is nowadays.

If you pursue this, please submit a PR to that repo because there may be other folks who want to import users from LDIF

An alternative would be to have them manipulate the LDIF file into CSV and import that using the csv importer. See https://www.google.com/search?client=firefox-b-1-d&q=ldif+to+csv for some examples on how to do the LDIF->CSV transformation.

@mark-robustelli Oh ok, I'll set the password to a UUID then and set the user to change password on login. I'll try on Monday. Thanks for the forum link.

@fusionauth-qhj5e I have brought this up internally, for now we are considering adding a PR to make it more clear for users.

https://github.com/FusionAuth/fusionauth-site/pull/2918

No. But the user.bulk.create would. See https://fusionauth.io/docs/v1/tech/events-webhooks/events/#user-bulk-create for more details.

Hi @casper!

Welcome to the community. This is working as designed. The import API is currently designed to only write new records to the database and not check if the record is already duplicated. This is partly for performance reasons. It maybe be possible to write a script to check existing records, and then only import "new" users based on that feedback, but we do not have any current documented cases of this.

There is an option to get additional information about what is failing on your import.
https://fusionauth.io/docs/v1/tech/apis/users/#import-users

validateDbConstraints [Boolean] OPTIONAL Defaults to false Set this value to true in order to perform additional validation of the request. The import request is intended to be used to populate the initial set of users, this means FusionAuth does not expect to find duplicate users in the database. If a duplicate is encountered a 500 will be returned without this additional validation. If you intend to use this API with existing users in FusionAuth set this value to true to request additional validation be performed on the input request and a 400 response will be returned with JSON body indicating the duplicate values encountered. Setting this value to true will dramatically decrease the performance of this request. If importing large numbers of users in a single request you may need to increase request timeouts to ensure this request does not timeout before it has completed.

I hope this helps,
Josh

Yes you can. You have a few options.

If your algorithm matches one of the FusionAuth supported algorithms or one of the community provided ones, you can configure FusionAuth to use it. If not, you may need to write your own hashing plugin.

Once you have imported the hashes, the next the to consider is whether you want FusionAuth to rehash the passwords as the users log in. This is a good option if the previous hashing algorithm was not a strong one. This is configured at the tenant level, under the Passwords tab.

Yup, you can check out our test script repo here: https://github.com/FusionAuth/fusionauth-import-scripts

You need to have ruby installed, but there's a script under testing in that directory that can import a large number of users (1M is the default).

Loading 1M users to a basic FusionAuth cloud instance in Europe over a home network connection took about 40 minutes.

This data is exposed in version 1.20.1.

Options:

You can drop the database. This will work if you want to start with a clean slate every time. You may want to look into kickstart or terraform to set default applications, accounts, and other items up every time. You can load all the users into a tenant (not the default one). Then, when you are done with loading up the users and want to clean up, you can delete the tenant, which will remove all users associated with that tenant. This option maintains all the other non tenant settings (IdPs, emails templates, themes, etc). You can use the bulk delete API. You can start deleting blocks of 5-10k users and increase the number deleted with each API call. This will be slower, but has the benefit of leaving the rest of the system untouched.

No, the users must have a password. In this scenario, where you know the users do not have a password, you can just set a secure random password. A UUID, or other securely generated high entropy value.

You can provide the password value, but this will cause FusionAuth to hash it inline, so it will be costly in terms of time and CPU if you are importing a large number of users.

If you don’t want to take this hit at import time, you can provide these users just random hashed values, as long as you provide the factor, encryptionScheme, salt and password FusionAuth will assume this is a hash, and it will not re-hash it.

@dwong

FusionAuth is API first, so this type of flow could be created using our API and custom integration code.

Roughly:

On tenant B, a user from tenant A logs in. Do a search for a user If found, do a registration and/or user create using API. The newly created user can now be logged in. As referenced above, you may have some interstitial pages that would be needed for password generation as the user passes from one tenant to another.

Another way to do this would be to reconsider how you are using tenants and applications. Depending on your business requirements, registering a user to a new application rather than a completely separate tenant removes a few steps from a workflow as described.

Reference documentation -> https://fusionauth.io/docs/v1/tech/apis/

Thanks,
Josh