the concept how to enroll or distribute authentication devices to the
users is often a central part of an overall concept of two factor
authentication project. Depending on the size and side effects of such
an enrollment/infrastructure this can take several days doing workshops,
discussions and writing concept to the satisfaction of all people
privacyIDEA does not have THE way to distribute tokens to the users.
But it has several possibilities, so that you can look at your workflow
and processes and design the enrollment process nearly seamless into
your existing workflows.
So how do your users usually interact with IT?
Are all the users on site or are they scattered in the world?
Which identity attributes of the users are already known?
When assigning a token to the user, you need to identify the user
somehow. The quality of the two factor afterwards will be as good as the
If you are using 2FA for remote access it might be enough, that the user
authenticates with his domain password to the web ui internally and
enroll his own token.
In other cases it might be necessary to identify the user personally,
i.e. the user needs to come to a registration desk in person.
As an example privcayIDEA comes with a registration token type.
You could restrict that the user may only possess one token.
Enroll a registration token to the user (automatically) and send the
registration code to the user in a trusted way (more likely snail mail
I do not get your idea with the stage OU. I assume the users already
exist, but they have no token assigned.
So I think there is no need to move the users around in the user
I’m planning how we will set up an account’s initial OTP exchange.
I’m hoping there’s a “best practices” method to provision a new
Here’s what I’m thinking.
(please, tell me a better/easier way if you have a “best practices”
- User creates an account request, which includes an acceptable
- We put that account request into a “stage” OU.
I am puzzled, are there no user accounts, yet?
- A human approves/denies the account request.
- If approved, the user can then change the account password.
- Beyond setting the initial password, the user must set up OTP before
gaining any more access.
- We ask the user to go get an OTP app (like FreeOTP), which they
- We SMS a one-time/time-limited URL to the user’s cell phone.
(Might we leverage the autoassignment enrollment policies for this?
The autoassignment policy is used for already existing tokens a.k.a.
I.e. there already must exist a token, that will be assigned just by
But you could send the registration code via SMS to the user.
- User goes to the URL, which is the OTP sign-up/config page.
The user would go the the WebUI and login with his password and the
As soon as he logged in, the registration token is deleted. Within the
WebUI, he needs to enroll a new FreeOTP token.
- Once the OTP is configured, we move the user to a realm that
requires OTP from that moment on.
Maybe I’m missing some functionality or feature in PrivacyIDEA for
doing this (I’m still reading the docs.) If so, please let me know.
Any ideas or direction will be greatly appreciated.
Depending on how many users you want to enroll, you can also automate
the process using the REST API. This would speed up and smooth things a
As mentioned in the beginning, this things are usually discussed the
best in a personal conversation but let’s try it this way here.
CorneliusAm Montag, den 20.07.2015, 15:51 -0700 schrieb Kurt Bendl:
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to email@example.com.
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.
+49 151 2960 1417
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798
Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel
signature.asc (819 Bytes)