Help with sms token enrollment and smsotp challenge response

217 vistas
Ir al primer mensaje no leído

haik...@gmail.com

no leída,
6 ene 2015, 9:44:02 p.m.6/1/15
para priva...@googlegroups.com
Hi guys,

  I need help with doing mass enrollment for sms token to users. I manage to add users singly, but I need to add a couple hundreds of users and create sms tokens for each of them. I'm using  ubuntu 14.04 and installed privacyidea using sudo apt-get install privacyidea. 

Also can anyone point me in the right direction for doing a proper smsotp challenge response authentication using. More specifically the check for result status & value to be true.


Thanks!
Haiks

Cornelius Kölbel

no leída,
7 ene 2015, 3:14:42 a.m.7/1/15
para priva...@googlegroups.com
Hello Haiks,

there is no way to automate the SMS TOken enrollment at the moment.
If the mobile number is contained in the directory privacyidea will use it during enrollment.

NEvertheless you can use the client api to ease the enrollment and write a little python script like this:

from privacyideautils.clientutils import privacyideaclient

protocol = "https"
host = "localhost"
admin = "admin"
adminpw = "test"
adminrealm = "admin"

client = privacyideaclient(protocol, host, admin=admin, adminpw=adminpw,
                           adminrealm=adminrealm)

users = [("+49 12345", "cornelius", "pin1"),
        ("+1 12345", "corny", "pin2")]

for user in users:
    r = client.inittoken({"phone": user[0], "user": user[1], "pin": user[2],
                          "genkey": 1, "type": "sms"})

You can define a big array "users" with all your users, their mobile numbers and the OTPpins. Client.inittoken will create all these SMS tokens for the users.
PLease note, that the users have to exist in a directory or your passwd.

To be able to use challenge response you need to set the policy

scope:authentication
action:challenge_response

You can generate a challenge by trying to authenticate with the otp pin:
   /validate/check?user=cornelius&pass=pin1
and then authenticate in the second step with the state/transactionid and the OTP value sent to you with the SMS.

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...@googlegroups.com.
To post to this group, send email to priva...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/privacyidea/8bc31d89-d2b8-4998-a4e0-010fa7c26fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Cornelius Kölbel
corneliu...@netknights.it
+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

haik...@gmail.com

no leída,
8 ene 2015, 9:48:54 p.m.8/1/15
para priva...@googlegroups.com
Thanks Cornelius,

  Would the enrollment process be different using sqlresolver? I'm getting my users and phone numbers from a mysql database. 


I'm writing the php page for the authentication and using form method post and file_get_contents() i can do step 1 and trigger the sms sending but i'm having difficulty with the second step of authenticating as you mentioned. Sorry if i'm unclear, still very new to this.

Thanks again,

Haiks





Cornelius Kölbel

no leída,
9 ene 2015, 3:28:54 a.m.9/1/15
para priva...@googlegroups.com
Hallo Haiks,

it does not matter if the users are located in a file, ldap, sql or scim.

So if you are retrieving the OTP value via SMS that is good.

You can authenticate in at least two different ways:

You either use the transaction_id, that was sent in the http response in combination with the otp value:

   /validate/check?user=haiks&pass=123456&transactionid=09234028934kajsdhflkashf

where pass is the OTP value.

Or you use the OTP PIN again with the OTP value, but without the transactionid:

  /validate/check?user=haiks&pass=pin123456

The transactionid is used to proove that the user already presented the correct OTP PIN.

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...@googlegroups.com.
To post to this group, send email to priva...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
signature.asc

haik...@gmail.com

no leída,
13 ene 2015, 4:25:17 a.m.13/1/15
para priva...@googlegroups.com
Thanks Cornelius, 

  You have been most helpful! Another question, I see this error in the privacyidea.log file in /var/log

2015/01/13 - 17:13:51 ERROR {140110506989312} [privacyidea.lib.policy][check_auth_serial #2455] {}
2015/01/13 - 17:13:51 ERROR {140110506989312} [privacyidea.lib.policy][check_auth_serial #2459] No policy scope=authorize, action=serial for user u'USER', realm u'REALM', client 'IPADDRESS'

Is there some policy that i haven't set properly?


Thanks

Haiks

Cornelius Kölbel

no leída,
13 ene 2015, 4:36:26 a.m.13/1/15
para priva...@googlegroups.com
Hi Haiks,

no, this is no problem.
It is a wrong labeled log entry. It tells, that there was no authorize policy defined.
You can define an authorize policy to define, which token is allowed to authenticate at which client.
If you have not authorize policies at all, this test is skipped.
This log message is just the note, that it was skipped.

I changed this to DEBUG.

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...@googlegroups.com.
To post to this group, send email to priva...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
signature.asc

MKS

no leída,
19 ene 2016, 7:21:33 a.m.19/1/16
para privacyidea
Hello,


On Friday, January 9, 2015 at 10:28:54 AM UTC+2, Cornelius Kölbel wrote:
it does not matter if the users are located in a file, ldap, sql or scim.

Currently we have all users phone numbers in LDAP, this records managed by HR dep, so data is always in actual state.
Is it possible to use phone number from LDAP record for user instead of hardcoding it for SMS tockens?

Cornelius Kölbel

no leída,
19 ene 2016, 7:23:50 a.m.19/1/16
para priva...@googlegroups.com
Hi,

did you check the enrollment of the SMS token?
The phone number gets read from the LDAP during enrollment!

Do you mean you want the mobile phone number dynamically to be looked up
whenever an SMS is to sent?

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...@googlegroups.com.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/privacyidea/5b8a968e-70e9-46a5-abd1-9f3278421d52%40googlegroups.com.
signature.asc

MKS

no leída,
19 ene 2016, 7:26:20 a.m.19/1/16
para privacyidea
On Tuesday, January 19, 2016 at 2:23:50 PM UTC+2, Cornelius Kölbel wrote:

Do you mean you want the mobile phone number dynamically to be looked up
whenever an SMS is to sent?

Yes, exactly.

Cornelius Kölbel

no leída,
19 ene 2016, 8:30:41 a.m.19/1/16
para priva...@googlegroups.com
Why?

Do the mobile numbers of the users change so often?
Do you have so many users, so that you want the HR to handle this?

In this case a HR employee could simply change the mobile number and
reroute authentication to any other mobile phone.

I just want to understand your needs and intention.

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...@googlegroups.com.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/privacyidea/be6c3663-fbe4-4d36-8816-98e23f859551%40googlegroups.com.
signature.asc

MKS

no leída,
19 ene 2016, 9:38:10 a.m.19/1/16
para privacyidea
All users personal info is stored in LDAP, it may or may not be changed, but it's good when this information stored in one central place.
Also it's better to keep HR persons away from IT systems, and if we force them "to do their work twice" whey will be very unhappy. )
More over, I think it would be good to have one universal SMS token for all users within realm (in additional to present SMS token scheme), so all new users would be able to use SMS tokens immediately after creation, without any actions from privacyIDEA admins side.

Cornelius Kölbel

no leída,
19 ene 2016, 2:04:33 p.m.19/1/16
para priva...@googlegroups.com
I think these are two different kind of ideas or requirements.

Yes, you may leave the HR department out of the loop as far as IT is
concerned. But image this: The HR deparment "accidentially" changing the
mobile number of a user. Thus they will break the IT functionality.
After all, they are responsible for the authentication to work properly,
since they are responsible for assigning the right SMS token (a.k.a.
mobile number) to the users ;-)

The 2nd thought sill has the HR department responsible for
authentication but it is a technical nice idea having all users simply
have an SMS token.

But you can do this today by running a script using the REST API like
this:

1. find all users without a token
2. assign an SMS token to those users

Helping with such integrations and automations is one part of the
services the NetKNights provides.
https://netknights.it/en/leistungen/one-time-services/


Kind regards
Cornelius
> https://groups.google.com/d/msgid/privacyidea/b78e7d4c-9466-4f0b-b104-29f31085c1cf%40googlegroups.com.
signature.asc
Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos