On 15.5.2014 00:23, Dmitri Pal wrote:
On 05/14/2014 05:49 PM, Nathaniel McCallum wrote:
On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote:
On 05/14/2014 05:23 PM, Nathaniel McCallum wrote:
On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote:
On 05/14/2014 02:08 PM, Nathaniel McCallum wrote:
Occasionally OTP tokens get out of sync with the server. When this
happens, the user or an admin need to synchronize the token. To this
end, we landed server-side synchronization support, which is a simple
bind with a custom control. This all works with my sample test
Client support is proving a bit more difficult. In the ideal
client would contact LDAP directly and perform the operation. This
make a man in the middle attack difficult and we can ensure
over the entire operation.
However, browsers, without server-side assistance, cannot perform
factor and two second factors must be transmitted to the FreeIPA
and then proxied to 389. Is this an acceptable compromise?
May be we should do some encryption before sending the values over
On the other hand we are OK with the form based login so I am not sure
if there is any value.
Yes, but I agree there is not a lot of value.
We might have some logic related to permissions i.e. members of the
admin group can only sync on server but I am not sure that is
we should consider out of box.
In any way IMO it should be a separate page, other than login page
can be accessed by anyone. It should be visible outside firewall like
other OTP vendors do. This would allow to use a mobile device to
a token (and potentially change the password).
This would be nice.
This command also needs to be accessible *without* an existing user
login since, if a user's token is out of sync, the user can't
it possible to expose such an API? If so, how? Both "ipa env" and
ping" seem to require kinit, so I don't see any obvious examples.
IMO SSSD should probably have a way to sync the token.
From usability point of view it should be a part of the standard
client software, not a part of the IPA client or ipa tools.
It should probably have a good UI integration too if token is used to
login into a laptop.
SSSD has direct access to LDAP right? If so, it can just do a bind with
the added control. That is actually the easiest way. Trying to access
via a third API is probably actually more difficult.
So for that to happen we should probably expose this interface over
This is what we talked about with the desktop folks some time ago.
The attached is the doc and there are diagrams at the end that show
we decided needs to be done.
Similar to that one can provide a simple otp-sync application that
sync using command line (but on the other hand may be it should just
How exactly we expose this in GDM is indeed a much more complicated
question and needs to be part of the next phase of integration. I've
CC'd jhrozek for this part.
Some thoughts came up while writing this mail:
a) We can go the complex path and provide password and sync
in every client. This is a lot of work based on my past experience and
can't be done quickly. See the complexity of the diagrams and flows in
the attached doc. And may be it should not be.
The synchronization needs to be added to whatever layer has access to
the LDAP server. How it is exposed from there is specific to each
b) May be IPA should provide a portal/proxy to do self service token
sync and/or password change. This can be a URL. It should be
access it externally outside the firewall. It should be bullet proof.
But then we need just one interface and one call and we can use it
mobile device or some other system on the internet to self service the
token and then pass authentication. IMO that would save us a lot of
and effort. I know other OTP vendors went this path and were quite
+1. This solves the VPN bootstrapping problem.
1. It should be available by default in the FreeIPA installation with a
link from the login page. This is just a matter of product polish.
2. In the case of a user logging into GDM, we have a bootstrapping
problem that they can't login without a token, and they can't sync
token without logging into a browser. GDM/SSSD probably needs to
True but not from day one.
This is why I mentioned a mobile device.
Keeping in mind that FreeOTP is on the mobile device and there is a good
chance that the person who will have a Linux laptop will have a mobile
They can also call a helpdesk and ask the helpdesk engineer to sync the
token for them.
That means that there should be an admin interface that would not
require the first factor just two codes.
Yup. Agreed. Just thinking big picture.
So it looks like that we agree that:
a) IPA should provide a special page to do resync and or password change.
These pages should not point to our UI but they might provide a
mechanism for redirecting to other page on success if supplied.
We already provide separate page for password reset which can be exposed.
b) This page can be linked off the login page
in addition to the separate pages, the otp-sync interface might be also
integrated in Web UI app in a same way as password reset:
c) Desktop would need to be integrated (in future but not now)
d) There should be an internal page/CLI that would allow admin or token
owner to resync the token without providing the first factor (future).
It also occurred to me that the workflow can be:
User can't log in
He calls helpdesk
Admin disables his token for a period of time (day, hour - policy
defined) allowing user to log in and resync it
User logs with the password part
User goes to his portal because he knows that token will be auto
reenabled after some time.
User resyncs the token
Token auto enables itself
IMO this would be a nice optimization in future.
We can also recommend always having a backup software token on the
mobile device just in case.
Bottom line: in modern world portal + backup alternative token on mobile
device would address most of the scenarios, also people will tell us
what problems they face and what we should address next.
We probably should have a "Token owner guide" that would talk about
these scenarios and help people to resolve them.
Freeipa-devel mailing list