Token enrollment or assignment audit log

Hello Cornelius,
I was trying to figure out what does audit log contain when a user is being
assigned with a token because I need to track(and notify) a user when
someone enroll and bind a token with him.
And here is what I discovered:
If I go to all users, filter user needed and then on the page
https:///#/user/details/
I click “Enroll new token”, enroll it, in audit log for this user I see
pretty much everything I expect - admin, token serial and user itself:
https://lh3.googleusercontent.com/-GUk3te6LjRA/VwIq0QnlyjI/AAAAAAAAL50/EIMbkvCHrnAm_vK40--2BOcEe3YPdIuFw/s1600/Screenshot_2.png

But if I first enroll a token, then, after the enrollment, I bind it to a
user, I cannot see in audit logs what user I bound a token to:

https://lh3.googleusercontent.com/-eS4KH07HJaA/VwIrMzM5jZI/AAAAAAAAL54/NFx2nv-c2OswTQw5GEMrqNssjNLDEa7ew/s1600/Screenshot_1.png

Is it expected behavior? For me it seems useless to have an audit log entry
for “assign” action if you can’t see what user the token had been assigned
to.

Ok, I will. Thank you Cornelius!
By the way, it’d be great if you consider adding such an option to PI as
notification of a user by e-mail about token enrollment event to its name.
Email is already gathered by PI(in case of LDAP resolver). Because it’s not
too good in terms of security if a user doesn’t aware that someone from
helpdesk for instance enroll a token and assign it to his name. Then this
person could easily use the victim’s username and freshly generated token’s
pin and otp to be authenticated on services where OTP is the only
authentication factor.

Hi Sergey,

you are right. there should be the username in the audit log.
Can you open an issue at github?

Thanks a lot
CorneliusAm Montag, den 04.04.2016, 01:53 -0700 schrieb Sergey Kolosovski:

Hello Cornelius,
I was trying to figure out what does audit log contain when a user is
being assigned with a token because I need to track(and notify) a user
when someone enroll and bind a token with him.
And here is what I discovered:
If I go to all users, filter user needed and then on the page
https:///#/user/details/

I click “Enroll new token”, enroll it, in audit log for this user I
see pretty much everything I expect - admin, token serial and user
itself:

But if I first enroll a token, then, after the enrollment, I bind it
to a user, I cannot see in audit logs what user I bound a token to:

Is it expected behavior? For me it seems useless to have an audit log
entry for “assign” action if you can’t see what user the token had
been assigned to.


Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

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/be945b35-d9a0-4311-8310-40838b59389c%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)

Hi Sergey,

interesting idea.
But again it is all a matter of access rights.

If the help desk has the right to deactivate email notification, there
is no use.
You may use otppin=userstore, in this case the help desk can not reset
the user password.
Or you do not allow the helpdesk to set a pin…

But please post a feature request.
This could be a more common thing like

“email notification to user about certain kind of activities
in regards to his account and his tokens”

Kind regards
CorneliusAm Montag, den 04.04.2016, 02:12 -0700 schrieb Sergey Kolosovski:

Ok, I will. Thank you Cornelius!
By the way, it’d be great if you consider adding such an option to PI
as notification of a user by e-mail about token enrollment event to
its name. Email is already gathered by PI(in case of LDAP resolver).
Because it’s not too good in terms of security if a user doesn’t aware
that someone from helpdesk for instance enroll a token and assign it
to his name. Then this person could easily use the victim’s username
and freshly generated token’s pin and otp to be authenticated on
services where OTP is the only authentication factor.

Please read the blog post about getting help
https://www.privacyidea.org/getting-help/.

For professional services and consultancy regarding two factor
authentication please visit
https://netknights.it/en/leistungen/one-time-services/

In an enterprise environment you should get a SERVICE LEVEL AGREEMENT
which suites your needs for SECURITY, AVAILABILITY and LIABILITY:
https://netknights.it/en/leistungen/service-level-agreements/

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/08a5847c-31ed-4ac5-a238-70d90f93beba%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)