On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:
> On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote:
> > https://github.com/npmccallum/freeipa/pull/1
> > The above (pseudo) pull request contains four patches against
> > FreeIPA
> > to enable the insertion of Authentication Indicators into Kerberos
> > tickets. The basic flow looks like this.
> > First, we patch ipa-pwd-extop to return a control indicating what
> > authentication method succeeded resulting in a successful bind.
> > Second, we patch ipa-otpd to check the returned control to ensure
> > that
> > the bind resulted from an otp validation.
> > Third, we patch ipa-kdb to enable the KDC to return either the
> > encrypted timestamp or encrypted challenge preauth mechanism when
> > the
> > user is configured for optional 2FA logins. Clients can then decide
> > whether to do 1FA or 2FA login (for kinit, sane behavior already
> > exists).
> > Forth, we patch ipa-kdb again to insert hard-coded authentication
> > indicators for either OTP or RADIUS.
> > Some explanation is required for the first two patches. Currently,
> > it
> > is possible to do a 1FA through the otp preauthentication mechanism
> > if
> > the user is configured for doing optional 2FA. However, because we
> > want
> > to insert an authentication indicator in this code path, we need to
> > guarantee that a request going through the otp preauth mechanism
> > actually validates an OTP. This is the purpose of the control.
> > Items still on the TODO list:
> > * Authentication Indicator enforcement
> > - Upstream libkrb5 needs to grow funcs for reading indicators
> > - Schema change to add indicators multi-value attr to services
> > - ipa-kdb needs to implement check_policy_tgs()
> > * SSSD needs to learn to handle optional 2FA
> > I will write up a project page for all of this tomorrow. But this
> > small
> > code basically amounts to my brainstorming. It is not ready for
> > merge,
> > just basic review.
> It looks mostly ok, however the LDAP control part needs to be done as
> request/response pair.
> A client that wishes to know what kind of authentication happened
> send a request control, and only in that case , the server will send
> associated reply control with the requested information.
I just pushed a new version of the control (now merged into a single
In this version the client sends a critical control with no content
indicating that the server must validate an OTP. If the LDAP server
doesn't support the control (for whatever reason), bind will fail. If
the LDAP server doesn't validate an OTP (for whatever reason), bind
This approach is simpler and doesn't require a request/response control
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code