[Freeipa-devel] FreeIPA OTP End-to-End

[Jakub Hrozek]

On Sat, Jan 11, 2014 at 01:20:59AM +0200, Alexander Bokovoy wrote:
> On Thu, 09 Jan 2014, Nathaniel McCallum wrote:
> >New RPMs are up: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/
> Just as a note -- we can use copr service to provide a better experience
> for testing. I made a copr repo with previous patchset last year:
> http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/
> Any Fedora contributor can make own copr repositories.
> 
> >WHAT'S NEW IN THE RPMS?
> >* 389ds OTP Last Token Plugin
> >* 389ds OTP Sync Plugin
> >* HOTP token support
> >* OTP UI is now working
> >
> >All of the non-UI code is currently on the list. Petr is working on UI
> >cleanup. You can see all the patches here:
> >https://github.com/npmccallum/freeipa/tree/otp
> >https://github.com/npmccallum/freeipa/tree/otpui
> >
> >KNOWN ISSUES
> >Setting User Auth Type globally doesn't work:
> >https://fedorahosted.org/freeipa/ticket/4105
> >
> >SELinux is broken on F20 (should be fixed in rawhide):
> >https://bugzilla.redhat.com/show_bug.cgi?id=970163
> There seem to be two parts, one is covered by this bug and another one
> is related to SSSD/logind communication:
> 
> allow sssd_t systemd_logind_var_run_t:dir search;
> allow sssd_t systemd_logind_var_run_t:file { read getattr open };

Interesting, which version are you running? The logind support is
currently only present in master (aka 1.12 dev)

> 
> >User's can't add their own tokens. A patch to fix this is in the RPMs,
> >but currently has a bug. A workaround exists. Details are here:
> >https://www.redhat.com/archives/freeipa-devel/2014-January/msg00068.html
> >
> >Alexander Bokovoy (I think) found some issues when interacting with
> >pkinit. I don't know the state of this.
> It is unclear what exactly happens but from Jakub Hrozek's testing we
> saw that on client side (preauth2.c) in tryagain() code 'pkinit' module
> gets control despite 'otp' module returns success and modified pa_data.
> 'pkinit' cannot process pa_data afterwards and therefore returns error
> which is interpreted by the libkrb5 as a failure of preauth processing.

Right, I can see this problem on my local VM test machines. Ping me if
you'd like to run some tests and I can create a tunnel. Petr Vobornik
was also seeing some failures that seemed similar, but with my limited
Kerberos knowledge I can't tell for certain if it's the same problem.