Token enrollment or assignment audit log

20 views
Skip to first unread message

Sergey Kolosovski

unread,
Apr 4, 2016, 4:53:54 AM4/4/16
to privacyidea
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://<pi-server>/#/user/details/<realm><user>
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.


Cornelius Kölbel

unread,
Apr 4, 2016, 4:59:29 AM4/4/16
to priva...@googlegroups.com
Hi Sergey,

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

Thanks a lot
Cornelius

Am 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://<pi-server>/#/user/details/<realm><user>
>
> 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...@googlegroups.com.
> To post to this group, send email to priva...@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
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

Sergey Kolosovski

unread,
Apr 4, 2016, 5:12:45 AM4/4/16
to privacyidea
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. 

Cornelius Kölbel

unread,
Apr 4, 2016, 5:24:42 AM4/4/16
to priva...@googlegroups.com
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
Cornelius
> --
> 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...@googlegroups.com.
> To post to this group, send email to priva...@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.
signature.asc
Reply all
Reply to author
Forward
0 new messages