On 02/29/2016 11:35 PM, Nathaniel McCallum wrote:
On Fri, 2016-02-26 at 09:00 +0100, Martin Kosek wrote:
On 02/25/2016 10:51 PM, Simo Sorce wrote:
On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote:
On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote:
On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote:
On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote:
On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum
On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:
On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum
The above (pseudo) pull request contains four patches
to enable the insertion of Authentication Indicators
tickets. The basic flow looks like this.
First, we patch ipa-pwd-extop to return a control
authentication method succeeded resulting in a
Second, we patch ipa-otpd to check the returned
the bind resulted from an otp validation.
Third, we patch ipa-kdb to enable the KDC to return
encrypted timestamp or encrypted challenge preauth
user is configured for optional 2FA logins. Clients
whether to do 1FA or 2FA login (for kinit, sane
Forth, we patch ipa-kdb again to insert hard-coded
indicators for either OTP or RADIUS.
Some explanation is required for the first two
is possible to do a 1FA through the otp
the user is configured for doing optional 2FA.
to insert an authentication indicator in this code
guarantee that a request going through the otp
actually validates an OTP. This is the purpose of the
Items still on the TODO list:
* Authentication Indicator enforcement
- Upstream libkrb5 needs to grow funcs for
- Schema change to add indicators multi-value
- 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
code basically amounts to my brainstorming. It is not
just basic review.
It looks mostly ok, however the LDAP control part needs
A client that wishes to know what kind of
send a request control, and only in that case , the
associated reply control with the requested
I just pushed a new version of the control (now merged
In this version the client sends a critical control with
indicating that the server must validate an OTP. If the
doesn't support the control (for whatever reason), bind
the LDAP server doesn't validate an OTP (for whatever
This approach is simpler and doesn't require a
I need some design advice. My goal here is that we need a
the authentication indicators to services in the FreeIPA
Here is the good news: users can already set these values
using kadmin. They do this by simply setting the
the target service principal. Our kdb plugin then encodes
the rest of the tl_data into the krbExtraData attribute.
I see two approaches here. First, we can try to manipulate
krbExtraData attribute directly. Second, we can create a
attribute for the authentication indicator strings and then
the tl_data internally in kdb. We would have to do this for
and writes so as not to break existing kdb functionality.
The trade-off that I see is that the first method
python framework side where the second method complicates
A third option, which I doubt is even possible, is to use
manipulate this option rather than modifying LDAP directly.
We should translate it, we need that to allow to delegate
the specific attribute via our standard means.
We already do this for other tl_data entries.
The krbExtraData access cannot always be delegated because it
open ended. also it is really obnoxious to have to manipulate
stuff in the framework.
kadmin could be used at some point, but we'd still want to
attribute extracted in order to be able to grant access
individually, as our ACL system and delegation system is more
grained than what kadmin can offer.
After discussing this with MIT, Simo and Matt, it seems that
option is to update the (MIT) upstream krbPrincipal objectClass
a new attribute. The reason for this is twofold. First, it has
value. Second, we don't have good objectClass to attach the new
attribute to inside FreeIPA.
So the current plan is that Matt will create a patch for
indicators (specifically, the "required_auth" strings) in a new
value string attribute on krbPrincipal objects. The
hook will read "required_auth" from krbExtraData or (if
preferred) the new attribute. In turn, the put_principal() KDB
will store "required_auth" in the new attribute. This will
transparent migration of any data currently stored in
As part of this process, Matt will also refactor
smaller functions (it is currently 800+ LOC).
Once we have an attribute in upstream krbPrincipal, we will use
attribute exclusively in our KDB plugin.
I have started a project page:
Thanks Nathaniel! For starters, I moved the page to
to make sure the URL is consistent with other pages ;-)
I also updated the Use Cases and added the User Story I am tracking
We are still waiting on some details. But the general shape of
is there. Please review. :)
LGTM so far.
- Should the control specify what kind of auth specifically should
- Will it make sense in future to have different strength otp-like
second factors and have ipa-otpd be able to specify which one it is
expecting to be validated ?
- Even if ipa-otpd will not grow such a feature, I see this control
could be useful for pure LDAP auth clients, so perhaps a different
of client may want to set this control ? Perhaps one day we can
way to do GSSAPI auth and check that the AI on the ldap ticket was
and then DS will refuse login if the otp AI was missing on the
received and the control requires it ? (could be used for the IPA
connection to LDAP maybe ?)
It would be also nice to add some graph how the workflows look like.
It may be
something based on Simo's picture he created some time back
How's this (attached)?
Good! Your version is IMO most useful for developers. The previous Simo's
diagram could be also useful for admins that are Kerberos protocol savvy and
would help them get the big picture of how the AI is inserted in the tokens.
Design page can include both, it should not be a problem.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code