Initial OTP token configuration

Question
1

Hi,

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 account.

Here’s what I’m thinking.
(please, tell me a better/easier way if you have a "best practices"
workflow.)

  • User creates an account request, which includes an acceptable password.
  • We put that account request into a “stage” OU.
  • 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 joyfully
    do.
  • We SMS a one-time/time-limited URL to the user’s cell phone.
    (Might we leverage the autoassignment enrollment policies for this?
    Something else?)
  • User goes to the URL, which is the OTP sign-up/config page.
  • 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.

Thanks!

-kb

2

Hi Tom,

thanks for the description.

I just want to add, that you can have the same functionalities with the
privacyIDEA webui:

  • user logs in with LDAP password (by defining a webui-policy)
  • user can only enroll a limited number of tokens (by defining an
    enrollment-policy)
  • user can only delete/resync… (by defining a user-policy)

But if you prefer your own look and feel or UI, of course you can use
the REST API to add this all into a portal or webinterface a user feels
more familiar with.

This is the idea behind privacyIDEA, to give you maximum flexibility.

Kind regards
CorneliusAm Dienstag, den 21.07.2015, 11:36 -0700 schrieb Tom Cole:

We also looked at those questions and came to the easiest solution
(for IT and users).

We have a web GUI that the users log into. The GUI uses LDAP
authentication. This verifies the user. They can then enroll a token
(but only 1). The other options they have are delete, re-sync and
test. Unless you absolutely have to I would stay away from using an
OTP Pin (seemed to confuse our users - not sure why as they are all
supposedly college grads). The user than uses the token for 2FA with
Palo Alto Global Protect. They have to login to the portal with LDAP
and then use the token for the gateway. If the 2 users don’t match it
wont work.

On Monday, July 20, 2015 at 6:51:00 PM UTC-4, Kurt Bendl wrote:
Hi,

    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 account.
    
    
    Here's what I'm thinking. 
    
    (please, tell me a better/easier way if you have a "best
    practices" workflow.)
    
    
    * User creates an account request, which includes an
    acceptable password.
    * We put that account request into a "stage" OU.
    * 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 joyfully do.
    * We SMS a one-time/time-limited URL to the user's cell
    phone. 
      (Might we leverage the autoassignment enrollment policies
    for this? Something else?)
    * User goes to the URL, which is the OTP sign-up/config page.
    * 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.
    
    
    
    
    Thanks!
    
    
      -kb

–
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 privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/37a9fbb3-4cf9-47c0-a1d7-246a2db791d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
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)

3

We also looked at those questions and came to the easiest solution (for IT
and users).

We have a web GUI that the users log into. The GUI uses LDAP
authentication. This verifies the user. They can then enroll a token (but
only 1). The other options they have are delete, re-sync and test. Unless
you absolutely have to I would stay away from using an OTP Pin (seemed to
confuse our users - not sure why as they are all supposedly college grads).
The user than uses the token for 2FA with Palo Alto Global Protect. They
have to login to the portal with LDAP and then use the token for the
gateway. If the 2 users don’t match it wont work.On Monday, July 20, 2015 at 6:51:00 PM UTC-4, Kurt Bendl wrote:

Hi,

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 account.

Here’s what I’m thinking.
(please, tell me a better/easier way if you have a “best practices”
workflow.)

  • User creates an account request, which includes an acceptable password.
  • We put that account request into a “stage” OU.
  • 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 joyfully
    do.
  • We SMS a one-time/time-limited URL to the user’s cell phone.
    (Might we leverage the autoassignment enrollment policies for this?
    Something else?)
  • User goes to the URL, which is the OTP sign-up/config page.
  • 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.

Thanks!

-kb

4

Hello Kurt,

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
involved.

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
identification process.

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.

http://privacyidea.readthedocs.org/en/latest/configuration/tokens/registration.html
http://privacyidea.readthedocs.org/en/latest/modules/lib/tokentypes/registration.html?highlight=registration%20token

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
than email).

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
directory.

…more below…

Hi,

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
account.

Here’s what I’m thinking.

(please, tell me a better/easier way if you have a “best practices”
workflow.)

  • User creates an account request, which includes an acceptable
    password.
  • 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
    joyfully do.
  • We SMS a one-time/time-limited URL to the user’s cell phone.
    (Might we leverage the autoassignment enrollment policies for this?
    Something else?)

The autoassignment policy is used for already existing tokens a.k.a.
hardware tokens.
http://privacyidea.readthedocs.org/en/latest/policies/enrollment.html?highlight=autoassign#autoassignment
I.e. there already must exist a token, that will be assigned just by
using it.

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
registration code.

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
lot.

As mentioned in the beginning, this things are usually discussed the
best in a personal conversation but let’s try it this way here.

Kind regards
CorneliusAm Montag, den 20.07.2015, 15:51 -0700 schrieb Kurt Bendl:

Thanks!

-kb

–
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 privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/c8851f01-b43a-495d-8409-6a1dd4aa2266%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
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)

5

Sorry - I realize now that I gave the impression we use our own GUI. We
dont - why recreate the wheel. We use the privacyIDEA GUI - works great.> Cornelius Kölbel mailto:cornelius.koelbel@netknights.it

July 21, 2015 at 16:09
Hi Tom,

thanks for the description.

I just want to add, that you can have the same functionalities with the
privacyIDEA webui:

  • user logs in with LDAP password (by defining a webui-policy)
  • user can only enroll a limited number of tokens (by defining an
    enrollment-policy)
  • user can only delete/resync… (by defining a user-policy)

But if you prefer your own look and feel or UI, of course you can use
the REST API to add this all into a portal or webinterface a user feels
more familiar with.

This is the idea behind privacyIDEA, to give you maximum flexibility.

Kind regards
Cornelius

6

No need to be sorry.

I added a video https://www.youtube.com/watch?v=pukEqI6dScQ on how to
setup tokenenrollment with the registration token, where the user will
get a registration code, that can be used once to login and enroll.

The interesting thing here is, that the user also needs two “factors”

  • his userstore password (a.k.a. LDAP password)
  • the registration code
    when initially logging in to the portal. The registration code could be
    send via a letter, thus only granting initial access to the user, if he
    knows his password and if he has access to his real life mail box.
    Thus the hurdle to enroll the OTP token and the necessary “identity
    check” is higher than only relying on the LDAP pw.

…it was a bit late… :wink:

Kind regards
CorneliusAm Dienstag, den 21.07.2015, 20:22 -0400 schrieb Tom Cole:

Sorry - I realize now that I gave the impression we use our own GUI.
We dont - why recreate the wheel. We use the privacyIDEA GUI - works
great.

Cornelius Kölbel
July 21, 2015 at 16:09
Hi Tom,

thanks for the description.

I just want to add, that you can have the same functionalities with
the
privacyIDEA webui:

  • user logs in with LDAP password (by defining a webui-policy)
  • user can only enroll a limited number of tokens (by defining an
    enrollment-policy)
  • user can only delete/resync… (by defining a user-policy)

But if you prefer your own look and feel or UI, of course you can
use
the REST API to add this all into a portal or webinterface a user
feels
more familiar with.

This is the idea behind privacyIDEA, to give you maximum
flexibility.

Kind regards
Cornelius

–
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 privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/55AEE238.3000708%
40gmail.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
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)

7

That gives me an idea. What about this:
If we get a user’s phone#, verify that user’s phone,
could send that code to the user’s phone (SMS)?

-kbOn Wednesday, July 22, 2015 at 1:52:53 AM UTC-6, Cornelinux K wrote:

The registration code could be
send via a letter, thus only granting initial access to the user, if he
knows his password and if he has access to his real life mail box.

8

Hi Kurt,

you could run a script like this:

  1. get the tokens for the user:

http://privacyidea.readthedocs.org/en/latest/modules/api/token.html#get--token-

and check if the user already has a token.

  1. If the user has not token, create registration token:

http://privacyidea.readthedocs.org/en/latest/modules/api/token.html#post--token-init

The JSON returns the registration code like this:
http://privacyidea.readthedocs.org/en/latest/modules/lib/tokentypes/registration.html#code-registration-token

  1. Now you need to fetch the mobile number of the user

http://privacyidea.readthedocs.org/en/latest/modules/api/user.html#get--user-

and send the Registration Code to the user.

The user now has the registration code an can use it once to login and
enroll the OTP token.

Kind regards
CorneliusAm Donnerstag, den 23.07.2015, 08:25 -0700 schrieb Kurt Bendl:

That gives me an idea. What about this:
If we get a user’s phone#, verify that user’s phone,
could send that code to the user’s phone (SMS)?

-kb

On Wednesday, July 22, 2015 at 1:52:53 AM UTC-6, Cornelinux K wrote:
The registration code could be
send via a letter, thus only granting initial access to the
user, if he
knows his password and if he has access to his real life mail
box.

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 privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/e6860ea8-a7ea-46ad-b1e0-bf30df5663b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
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)