Token enrollment wizard problem

Question
1

Hello Cornelius!
Could you please bring some light regarding token enrollment wizard?
I tried to find any info about usage of it here and on readthedocs, but it
seems like it isn’t documented well…
I have a user policy configured, which describes which token types are
available for enrollment and which parameters(max/min pin, otplen, etc…).
And when a user clicks on the Token enrollment wizard button it receives a
page with only “Enroll a new token” text and “Enroll token button”. But
after click on it an alert appears “The minimum OTP PIN length is 4”. Also
in audit logs
POST /token/init
The minimum OTP PIN length is 4
Could you please give a hint of how to use it? What does it require?

2

Hello Sergey,

did you know the youtube video?
You may get a better understanding here.
https://www.youtube.com/watch?v=diAGbsiG8_A

At which point do we need to improve the documentation?

The token enrollment wizard does entroll a token without an OTP PIN
(it supposes, you use otppin=userstore)

This is why you get the error message.

Kind regards
CorneliusAm Donnerstag, den 21.04.2016, 12:12 -0700 schrieb Sergey Kolosovski:

Hello Cornelius!
Could you please bring some light regarding token enrollment wizard?
I tried to find any info about usage of it here and on readthedocs,
but it seems like it isn’t documented well…
I have a user policy configured, which describes which token types are
available for enrollment and which parameters(max/min pin, otplen,
etc…). And when a user clicks on the Token enrollment wizard button
it receives a page with only “Enroll a new token” text and “Enroll
token button”. But after click on it an alert appears “The minimum OTP
PIN length is 4”. Also in audit logs
POST /token/init

The minimum OTP PIN length is 4

Could you please give a hint of how to use it? What does it require?

Please read the blog post about getting help
Getting help – privacyID3A.

For professional services and consultancy regarding two factor
authentication please visit
One Time Services - NetKnights - IT-Sicherheit - Zwei-Faktor-Authentisierung - Verschlüsselung

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
privacyIDEA Support Level

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.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/f61f1092-329e-4203-aea4-7f8f70ec6d71%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 (836 Bytes)

3

Hi and thank you for the youtube demo!
Wizard is a good feature.
Now as you explained,

The token enrollment wizard does entroll a token without an OTP PIN
(it supposes, you use otppin=userstore)

it became much clearer to understand the behavior.
But I have an idea!
Parameters for otp pin are described in the user policy. So PI aware about
what token could exist in the particular realm. Why it don’t just fetch
those parameters of the current user realm, for instance PI knows that user
limited by a policy to have pin code of:
minimum 4 chars
maximum 10 chars
contents: “nc”
and generate a pin-code for user?
In this case it could be, for instance, “123asd321”
And then propose it to a user together with the QR?

As for documentation,
the only place I found a “wizard” keyword is
http://privacyidea.readthedocs.org/en/latest/policies/webui.html?highlight=wizard

So maybe here you could add more detailed explanation about what does PI
require for token enrollment using wizard

4

But how does the user login to the UI in the first place???

You mean, for the first time, when it doesn’t have any token?
For example in my scenario any user from LDAP resolver can log in to WEB UI
into default realm(which contains this LDAP user store) using their AD
login and password. This is due to *login_mode *by default is “userstore”
in webui policy.
Then, I suppose, PI can check policies related to token enrollment for this
current realm and propose a generated QR and PIN for the user in the token
enrollment wizard process… If it’s not seems to be too complicated or
maybe contradicts with the idea…

The enrollment wizard unleashes all its power in case the user has no

token, yet. Then the user can login with his ldap password. Enroll his
first token and then use the two factors ldap password + otp.

Sorry, couldn’t find how and where it is set up to use LDAP password
instead of a PIN code…
I only see that User scope policy contains options to set pin
characteristics - length and content. In addition every token assignment
user interface has fields for pin set up(to be entered by user or admin).
This would be useless fields if a pin would be equal to ldap password.
But it seems that I read about it somewhere formerly but can’t find and
remember :frowning:

In any case, treat it as a IDEA(not exactly Privacy though… :wink: ) about how
to make token enrollment wizard more flexible. For my opinion and in my
case even standard token enrollment mechanism is maximally minimized so the
only thing a user needs to enter is pin, but users just get confused
sometimes when they intuitively go to the token enrollment wizard, push the
button and get a red alert like “the minimum pin length is 4” :slight_smile:

5

Hi and thank you for the youtube demo!
Wizard is a good feature.
Now as you explained,
The token enrollment wizard does entroll a token without an
OTP PIN
(it supposes, you use otppin=userstore)
it became much clearer to understand the behavior.
But I have an idea!
Parameters for otp pin are described in the user policy. So PI aware
about what token could exist in the particular realm. Why it don’t
just fetch those parameters of the current user realm, for instance PI
knows that user limited by a policy to have pin code of:
minimum 4 chars
maximum 10 chars
contents: “nc”
and generate a pin-code for user?
In this case it could be, for instance, “123asd321”
And then propose it to a user together with the QR?

This is a nice idea for generating the OTP PIN.
But how does the user login to the UI in the first place???

The enrollment wizard unleashes all its power in case the user has no
token, yet. Then the user can login with his ldap password. Enroll his
first token and then use the two factors ldap password + otp.
(This was the original scenario - but it is always cool to enhance)

As for documentation,
the only place I found a “wizard” keyword is
7.6. WebUI Policies — privacyIDEA 3.8 documentation

Ok, this needs to be improved!

Thanks a lot
CorneliusAm Freitag, den 22.04.2016, 05:26 -0700 schrieb Sergey Kolosovski:

So maybe here you could add more detailed explanation about what does
PI require for token enrollment using wizard

Please read the blog post about getting help
Getting help – privacyID3A.

For professional services and consultancy regarding two factor
authentication please visit
One Time Services - NetKnights - IT-Sicherheit - Zwei-Faktor-Authentisierung - Verschlüsselung

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
privacyIDEA Support Level

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.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/4cbbb329-234e-43c4-b028-0c4b2a6df81b%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 (836 Bytes)

6

Hi Sergey,

honestly the token enrollment wizard was developed together with a
customer…
…to get the most simple way for the user. This simple way excluded the
token pin.

Of course you are right. We could add more configuration policies to the
enrollment wizard to also allow

  1. setting a PIN
  2. or creating the random PIN

In case of “setting a PIN” I am not completely convinced. Because it
gets more complicated and the user will have to “understand” the UI. He
will have additional UI elements (PIN entry). So - he could soon use the
normal token enrollment, since it is only a bit more complex.

Hm, in case of “creating a random PIN” the user will not use this random
PIN. Because it sucks. So he will have to reset the PIN. So either we
return to 1 “setting a PIN” or we set a random PIN and than the user has
to reset this PIN. Argh. No.

I think there is a way to also use PIN + OTP with the enrollment wizard.

Just thinking this through, back and forth to get the best way of doing
it.

Kind regards
CorneliusAm Freitag, den 22.04.2016, 12:43 -0700 schrieb Sergey Kolosovski:

    But how does the user login to the UI in the first place???

You mean, for the first time, when it doesn’t have any token?
For example in my scenario any user from LDAP resolver can log in to
WEB UI into default realm(which contains this LDAP user store) using
their AD login and password. This is due to login_mode by default is
“userstore” in webui policy.
Then, I suppose, PI can check policies related to token enrollment for
this current realm and propose a generated QR and PIN for the user in
the token enrollment wizard process… If it’s not seems to be too
complicated or maybe contradicts with the idea…

    The enrollment wizard unleashes all its power in case the user
    has no 
    token, yet. Then the user can login with his ldap password.
    Enroll his 
    first token and then use the two factors ldap password + otp.

Sorry, couldn’t find how and where it is set up to use LDAP password
instead of a PIN code…
I only see that User scope policy contains options to set pin
characteristics - length and content. In addition every token
assignment user interface has fields for pin set up(to be entered by
user or admin). This would be useless fields if a pin would be equal
to ldap password.
But it seems that I read about it somewhere formerly but can’t find
and remember :frowning:

In any case, treat it as a IDEA(not exactly Privacy though… :wink: )
about how to make token enrollment wizard more flexible. For my
opinion and in my case even standard token enrollment mechanism is
maximally minimized so the only thing a user needs to enter is pin,
but users just get confused sometimes when they intuitively go to the
token enrollment wizard, push the button and get a red alert like “the
minimum pin length is 4” :slight_smile:

–
Please read the blog post about getting help
Getting help – privacyID3A.

For professional services and consultancy regarding two factor
authentication please visit
One Time Services - NetKnights - IT-Sicherheit - Zwei-Faktor-Authentisierung - Verschlüsselung

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
privacyIDEA Support Level

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.
Visit this group at https://groups.google.com/group/privacyidea.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/9cc918ba-0c82-4b7c-bef3-de25220da692%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 (836 Bytes)

7

Hello Cornelius!
In continuation of the wizard discussion, may I drop a feature request if
you don’t mind?

Considering the fact that token enrollment wizard works with userstore
passwords as pin codes, but some organizations may have strict policies of
pin codes - what they should consist of, and may or may not they ever be a
userstore password - we can say that in some cases, as I described, for
instance, TEW provides only errors and personally I don’t think something
is terrible here. But some users when got to the OTP system get confused
maybe and choose wizard instead of enroll token(although there only needs
to be a pin code entered twice and a button to be hit). And this is
regardless we have well-documented instructions where to go and where to
push…
So, is it good and possible improvement on your opinion to add a checkbox
somewhere in user policy to enable or disable the token enrollment
wizard(actually to hide the button)? For example, as the token assign
button which is being controlled by “assign” policy in user policy set.