Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Fri, 2016-02-26 at 15:44 -0500, Nathaniel McCallum wrote:
> On Fri, 2016-02-26 at 11:20 -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote:
> > > I was thinking:
> > > 1. Bind as the entity validating the 2nd factor.
> > > 2. Extop which takes the:
> > >* user dn
> > >* type of 2nd factor
> > >* validation data
> > >* dn of 2nd factor (optional)
> > > 
> > > This provides an audit trail of who is validating 2nd factors.
> > Ok, this makes sense.
> > I wish we didn't have to create yet another extop, but if we want to
> > gate the check via another bind it makes sense.
> 
> I wish we had done this the first time. However, this really only makes
> complete sense in a post-SPAKE world.
> 
> I actually think we should have a different extop for each 2F type.
> Each 2F type can define its own interface (and possibly more than one
> round-trip; such as token sync).

Not sure about this.

> > > > > I'm thus not sure if we'll ever add more second factors to the
> > > > > existing
> > > > > simple bind mechanism.
> > > > LDAP binds still need to test both factors if they are required
> > > > ...
> > > We would grandfather OTP. But all new 2FA would require GSSAPI
> > > (using
> > > AIs) to use LDAP.
> > I do not think we can enforce this, we still have a lot of
> > deployments
> > that rely on LDAP binds to check credentials, and we should try to
> > support this as much as possible.
> 
> Consider the case of U2F. I don't think we can ever support LDAP simple
> bind with U2F. And I think U2F will be supported long before anything
> else.

For things like U2F it may make more sense to develop a SASL mechanism,
we use SASL for GSSAPI too.

> > > > > > - 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
> > > > > > kind
> > > > > > of client may want to set this control ? Perhaps one day we
> > > > > > can
> > > > > > have
> > > > > > a
> > > > > > way to do GSSAPI auth and check that the AI on the ldap
> > > > > > ticket
> > > > > > was a
> > > > > > 2FA
> > > > > > and then DS will refuse login if the otp AI was missing on
> > > > > > the
> > > > > > ticket
> > > > > > it
> > > > > > received and the control requires it ? (could be used for the
> > > > > > IPA
> > > > > > UI
> > > > > > connection to LDAP maybe ?)
> > > > > That seems to me like a decision LDAP can make internally. No?
> > > > Not if the user has optional 2FA and you want to enforce the
> > > > second
> > > > factor only for certain operations from the framework (like say
> > > > changing
> > > > passwords or other more privileged operations).
> > > Why can't we just use GSSAPI with AIs?
> > We would! But the AI check would be done (optionally) for the LDAP
> > server, not the HTTP service, remember that we do s4u2proxy and use
> > GSSAPI auth from the framework.
> 
> I'm missing something here.

The idea is that the framework may use the control that the server
should fail the bind if 2FA AI is not present on the ticket and re-bind
to LDAP before performing a high privilege operation. The bind would
fail if the required AI is not present and the higher priv. operation
would fail. for normally privileged operation (like listing users) the
control 2 require OTP AI wouldn't be sent so a bind would succeed even
if original credentials were 1FA.

Hope this makes it more clear.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Nathaniel McCallum]

On Fri, 2016-02-26 at 11:20 -0500, Simo Sorce wrote:
> On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote:
> > I was thinking:
> > 1. Bind as the entity validating the 2nd factor.
> > 2. Extop which takes the:
> >    * user dn
> >    * type of 2nd factor
> >    * validation data
> >    * dn of 2nd factor (optional)
> > 
> > This provides an audit trail of who is validating 2nd factors.
> Ok, this makes sense.
> I wish we didn't have to create yet another extop, but if we want to
> gate the check via another bind it makes sense.

I wish we had done this the first time. However, this really only makes
complete sense in a post-SPAKE world.

I actually think we should have a different extop for each 2F type.
Each 2F type can define its own interface (and possibly more than one
round-trip; such as token sync).

> > > > I'm thus not sure if we'll ever add more second factors to the
> > > > existing
> > > > simple bind mechanism.
> > > LDAP binds still need to test both factors if they are required
> > > ...
> > We would grandfather OTP. But all new 2FA would require GSSAPI
> > (using
> > AIs) to use LDAP.
> I do not think we can enforce this, we still have a lot of
> deployments
> that rely on LDAP binds to check credentials, and we should try to
> support this as much as possible.

Consider the case of U2F. I don't think we can ever support LDAP simple
bind with U2F. And I think U2F will be supported long before anything
else.

> > > > > - 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
> > > > > kind
> > > > > of client may want to set this control ? Perhaps one day we
> > > > > can
> > > > > have
> > > > > a
> > > > > way to do GSSAPI auth and check that the AI on the ldap
> > > > > ticket
> > > > > was a
> > > > > 2FA
> > > > > and then DS will refuse login if the otp AI was missing on
> > > > > the
> > > > > ticket
> > > > > it
> > > > > received and the control requires it ? (could be used for the
> > > > > IPA
> > > > > UI
> > > > > connection to LDAP maybe ?)
> > > > That seems to me like a decision LDAP can make internally. No?
> > > Not if the user has optional 2FA and you want to enforce the
> > > second
> > > factor only for certain operations from the framework (like say
> > > changing
> > > passwords or other more privileged operations).
> > Why can't we just use GSSAPI with AIs?
> We would! But the AI check would be done (optionally) for the LDAP
> server, not the HTTP service, remember that we do s4u2proxy and use
> GSSAPI auth from the framework.

I'm missing something here.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members

[Lukas Slebodnik]

On (26/02/16 12:37), Tomas Babej wrote:
>
>
>On 02/26/2016 07:30 AM, Jan Cholasta wrote:
>> On 22.2.2016 19:56, Tomas Babej wrote:
>>>
>>>
>>> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote:
 On Mon, 22 Feb 2016, Tomas Babej wrote:
>
>
> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote:
>> Hi,
>>
>> attached patch should update compat tree configuration if it exist to
>> follow slapi-nis 0.55 which has support for external members of IPA
>> groups.
>>
>> However, the real work is done in SSSD. These patches are not
>> upstreamed
>> yet. We'll need to bump SSSD dependency in future once they come to
>> distros.
>>
>>
>>
>
> This looks good.
>
> However, the new update file needs to be added to Makefile.am.
> Additionally, patch adds a whitespace error.
 Updated patch is attached.

>>>
>>> ACK.
>>>
>>> This should not be pushed until the dependency for SSSD can be bumped.
>> 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74
>> 
>
>Attaching the required spec change.
>
>Tomas

>From dae8b8fd0b23bf25ccf75b275deaa5c599faa27b Mon Sep 17 00:00:00 2001
>From: Tomas Babej 
>Date: Fri, 26 Feb 2016 12:35:09 +0100
>Subject: [PATCH] spec: Bump required sssd version to 1.13.3-5
>
>Required as part of: https://fedorahosted.org/freeipa/ticket/4403
 ^
There isn't mentioned sssd related ticket in slapi-nis bug
It would be good to add also sssd related ticket to commit message
https://fedorahosted.org/sssd/ticket/2522

LS

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH 00136] use LDAPS during standalone CA/KRA subsystem deployment

[Martin Babinsky]

This patch fixes https://fedorahosted.org/freeipa/ticket/5570 and also 
enables CA installation on CA-less master with hardened dirsrv 
configuration.


When testing I ran into the issue with Dogtag restart during KRA 
installation [1] which I will try to troubleshoot with Dogtag guys. You 
are welcome to troubleshoot it also during the review, maybe I did some 
misconfiguration on my part.


[1] https://www.redhat.com/archives/pki-devel/2016-February/msg00100.html
--
Martin^3 Babinsky
From 911d3d54a4a1fb1914cc2a727e7c01fb065d8b69 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Thu, 25 Feb 2016 09:09:35 +0100
Subject: [PATCH] use LDAPS during standalone CA/KRA subsystem deployment

The deployment descriptor used during CA/KRA install was modified to use LDAPS
to communicate with DS backend. This will enable standalone CA/KRA
installation on top of hardened directory server configuration.

https://fedorahosted.org/freeipa/ticket/5570
---
 ipaserver/install/cainstance.py | 3 +++
 ipaserver/install/dogtaginstance.py | 6 ++
 ipaserver/install/krainstance.py| 2 ++
 3 files changed, 11 insertions(+)

diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index 1a98c438786ae7dad208212fff23e3a760c95b3c..3ca4fa8d373ebc3375a9fc75b59969292f0198f0 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -533,6 +533,9 @@ class CAInstance(DogtagInstance):
 config.set("CA", "pki_ds_base_dn", self.basedn)
 config.set("CA", "pki_ds_database", "ipaca")
 
+if not self.create_ra_agent_db and not self.clone:
+self._use_ldaps_during_spawn(config)
+
 # Certificate subject DN's
 config.set("CA", "pki_subsystem_subject_dn",
 str(DN(('cn', 'CA Subsystem'), self.subject_base)))
diff --git a/ipaserver/install/dogtaginstance.py b/ipaserver/install/dogtaginstance.py
index 940b3ea9b13897d7e9e2878a47a8c66ce5ce9f0a..fa93b5069574b5fad824cee764460afb32dbc13e 100644
--- a/ipaserver/install/dogtaginstance.py
+++ b/ipaserver/install/dogtaginstance.py
@@ -463,3 +463,9 @@ class DogtagInstance(service.Service):
 self.log.critical("  %s" % log)
 
 raise RuntimeError("%s configuration failed." % self.subsystem)
+
+def _use_ldaps_during_spawn(self, config, ds_cacert=paths.IPA_CA_CRT):
+config.set(self.subsystem, "pki_ds_ldaps_port", "636")
+config.set(self.subsystem, "pki_ds_secure_connection", "True")
+config.set(self.subsystem, "pki_ds_secure_connection_ca_pem_file",
+   ds_cacert)
diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py
index 625d84ab3129708cfdaf759cee6c2953b585a822..be2727fb6ed66648c35f9db59ee8729d37e9dc02 100644
--- a/ipaserver/install/krainstance.py
+++ b/ipaserver/install/krainstance.py
@@ -188,6 +188,8 @@ class KRAInstance(DogtagInstance):
 config.set("KRA", "pki_ds_database", "ipaca")
 config.set("KRA", "pki_ds_create_new_db", "False")
 
+self._use_ldaps_during_spawn(config)
+
 # Certificate subject DNs
 config.set("KRA", "pki_subsystem_subject_dn",
str(DN(('cn', 'CA Subsystem'), self.subject_base)))
-- 
2.5.0

From f4bc04be5cf3c577acb0a3091d70455580550f51 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Thu, 25 Feb 2016 09:09:35 +0100
Subject: [PATCH] use LDAPS during standalone CA/KRA subsystem deployment

The deployment descriptor used during CA/KRA install was modified to use LDAPS
to communicate with DS backend. This will enable standalone CA/KRA
installation on top of hardened directory server configuration.

https://fedorahosted.org/freeipa/ticket/5570
---
 ipaserver/install/cainstance.py | 3 +++
 ipaserver/install/dogtaginstance.py | 6 ++
 ipaserver/install/krainstance.py| 2 ++
 3 files changed, 11 insertions(+)

diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index b72255f1ad2f95c5265a40eddfb1fe413826dba4..d9452016670241f200fa646c8cab1e777291d089 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -480,6 +480,9 @@ class CAInstance(DogtagInstance):
 config.set("CA", "pki_ds_base_dn", self.basedn)
 config.set("CA", "pki_ds_database", "ipaca")
 
+if not self.create_ra_agent_db and not self.clone:
+self._use_ldaps_during_spawn(config)
+
 # Certificate subject DN's
 config.set("CA", "pki_subsystem_subject_dn",
 str(DN(('cn', 'CA Subsystem'), self.subject_base)))
diff --git a/ipaserver/install/dogtaginstance.py b/ipaserver/install/dogtaginstance.py
index 5c2b28202329240e264e0b0a6149308ee208e8fa..f5e5649f9a7b80ab25c9789b62ea7efcd5662bb6 100644
--- a/ipaserver/install/dogtaginstance.py
+++ b/ipaserver/install/dogtaginstance.py
@@ -500,3 +500,9 @@ class DogtagInstance(service.Service):
 for group in self.admin_groups:
 

Re: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI

[Martin Babinsky]

On 02/26/2016 04:24 PM, thierry bordaz wrote:

On 02/25/2016 07:17 PM, thierry bordaz wrote:

On 02/25/2016 12:03 PM, Martin Babinsky wrote:

On 02/24/2016 04:30 PM, thierry bordaz wrote:

On 01/21/2016 05:04 PM, Martin Babinsky wrote:

On 01/21/2016 01:37 PM, thierry bordaz wrote:





Hi Thierry,

I have couple of comments to your patch:

1.)
there is a number of PEP8 errors in the patch
(http://paste.fedoraproject.org/313246/33893701), please fix them.

See http://www.freeipa.org/page/Python_Coding_Style for our
conventions used in Python code.

2.)
+DNA_BIND_METHOD   = "dnaRemoteBindMethod"
+DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol"
+DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config'
+dna_config_base   = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN

Uppercase names are usually reserved for module-level constants. OTOH,
local variables should be lowercase. Also you can instantiate
dna_config_base directly as DN, using 2-member tuples, i. e:

"""
dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric
Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config'))
"""

When passing DN object to the formatting functions/operators, it is
automatically converted to string so no need to hold string and DN
object separately. This is done in other places (see function/methods
in replication.py).

3.)

+for i in range(len(entries)) :
+
+mod = []
+if entries[i].single_value.get(DNA_BIND_METHOD) !=
method:
+mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD,
method))
+
+if entries[i].single_value.get(DNA_CONN_PROTOCOL) !=
protocol:
+mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL,
protocol))


please use idiomatic Python when handling list of entries, e.g.:

"""
for entry in entries:
   mod = []
   if entry.single_value.get(DNA_BIND_METHOD) != method:
   ...
"""

4.) I think that this method should in DSInstance class since it deals
with directory server configuration. Service is a parent object of all
other service installers/configurators and should contain only methods
common to more children.

5.) Since the method is called from every installer, it could be
beneficial to call it in DSInstance.__common_post_setup() as a part of
Directory server installation. Is there any reason why this is not the
case?

6.)

+while attempt != MAX_WAIT:
+try:
+entries = conn.get_entries(sharedcfgdn,
scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn)
+break
+except errors.NotFound:
+root_logger.debug("So far enable not find DNA shared
config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn,
sharedcfgdn))
+attempt = attempt + 1
+time.sleep(2)
+continue
+
+# safety checking
+# there is no return, if there are several entries, as a
workaround of #5510
+if len(entries) != 1:

I am quite afraid what would happen if the server does not return any
entries until 30 s timeout. The code will then continue to the
condition which can potentially test an uninitialized variable and
blow up with 'NameError'. This should be handled more robustly, e. g.
raise an exception when a timeout is reached and no entries were
returned.

7.)

+if len(mod) > 0:

A Pythonic way to test for non-empty container is

"""
if mods:
   # do stuff
"""

since an empty list/dict/set evaluates to False and non-empty
containers are True.


8.)

+entry = conn.get_entry(entries[i].dn)
+if entry.single_value.get(DNA_BIND_METHOD) != method:
+root_logger.error("Fail to set SASL/GSSAPI bind
method to %s" % (entries[i].dn))
+if entry.single_value.get(DNA_CONN_PROTOCOL) !=
protocol:
+root_logger.error("Fail to set LDAP protocol to
%s" % (entries[i].dn))

rather than re-fetching the modified entry and testing what happened,
you can just catch an exception raised by unsuccessfull mod and log an
error like this:

"""
try:
   conn.modify_s(entry.dn, mod)
except Exception as e:
   root_logger.error("Failed to modify entry {}: {}".format(entry, e))
"""

as a matter of fact, if the modify_s operation would fail for some
reason, an ldap exception would be raised and you checks would not
even be executed.

9.)
The debug message on line 219 should read "Unable to find DNA shared
config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors
at the end of the method should have "Failed" instead of "Fail".


Hi Martin,

Finally tested... here is the updated patch. Thanks for you patience


thanks
thierry


Hi Thierry,

the patch works as expected. I have some more nitpicks though:

1.) Please fix the following pep8 errors:

http://paste.fedoraproject.org/329086/56397841/

you can check whether you recent commit conforms to PEP8 by running

"git show -U0 | pep8 --diff"

2.)

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Simo Sorce]

On Fri, 2016-02-26 at 17:17 +0100, Jakub Hrozek wrote:
> On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 13:17 +0100, Lukáš Hellebrandt wrote:
> > > Hi, FreeIPA and SSSD communities!
> > > 
> > > I am working on adding URI to HBAC as my thesis [1]. The goal is to
> > > control access not only based on (user, host, service), but on (user,
> > > host, service, resource's URI).
> > > 
> > > I created a patch for FreeIPA [2] so it is capable of storing URI as
> > > part of HBAC rule. I created a patch for SSSD [3] so it is able to get
> > > this URI from FreeIPA and use it in HBAC evaluation.
> > > 
> > > I still need to develop a part of SSSD receiving URI-aware requests. It
> > > will either be an enhancement of Infopipe or I will use PAM responder
> > > (any suggestions?).
> > > 
> > > I wanted to kindly ask you for review and your opinions on the patches
> > > and generally on my approach. This would be my first contribution to
> > > FreeIPA and SSSD so there might be bugs. What do you think?
> > > 
> > > Btw, is there some better place to share patches than a pasting tool?
> > > Maybe some form of pull request?
> > > 
> > > Thanks for your opinions!
> > > 
> > > [1]
> > > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa
> > > [2]
> > > http://pastebin.com/rsHzXeAR
> > > [3]
> > > http://pastebin.com/atcZMuP1
> > > 
> > 
> > Hi Lukas, could please post your patches here using git-format-patch or
> > even better provide a public git tree with them applied ?
> > (Any place github, fedorapeople, your own server, etc. is fine)
> > 
> > 
> > First a question, what service can actually use this scheme and how ?
> > there is no URL field in PAM.
> 
> When Lukas started the work, we IIRC concluded that PAM is not an
> appropriate interface and we should probably expose some DBUS methods
> for access control. We haven't really discussed any details since then.

This only shifts the question, what service would use this interface ?
note I am not opposed to it, but would like to understand how we are
going to test that it actually works and is useful.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote:
> On Fri, 2016-02-26 at 10:12 -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote:
> > > 
> > > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote:
> > > > Questions:
> > > > - Should the control specify what kind of auth specifically
> > > > should be
> > > > required ?
> > > I had also wondered that. I'm certainly not against it. But I'd
> > > probably prefer a simple utf8 string value to avoid parsing
> > > complexity.
> > > 
> > > > 
> > > > - 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 ?
> > > I'm personally hoping that we can deprecate ipa-otpd after SPAKE
> > > lands.
> > > Post-SPAKE validations will require a method for validating OTP-
> > > only
> > > (excluding password). This will probably be an extop. The same will
> > > be
> > > true for all new second factors.
> > Why an extop ? I was thinking you'd do a bind with this same control
> > with a string that specifies you want to check only the second
> > factor.
> > (The result of the bind will be positive but you won't be logged in
> > as
> > the user the connection will still be marked anonymous.)
> 
> How can you do this anonymously?

The bind is not done anonymously, but the outcome of the bind operation
is that the user DS sees is the anonymous user (because you didn't use
the first factor at all).

>  You need to know which tokens to
> validate. This requires a user dn.

Sure this is a different concern, I was concerned about the outcome of
the bind operation not its setup.

>  Besides, I would think we also want
> to be bound *before* performing this operation. Otherwise, we could
> allow brute force tries on the 2nd factor.

Yes, this is a concern, but only with HOTP, with TOTP, you cannot really
brute force easily as you have to wait 30 sec. between each try
(assuming we mark the current OTP has been used and immediately return
an error on any further attempt ?)

We can also still lock the user account if too many attempts are
performed.

However it is a concern indeed.

> I was thinking:
> 1. Bind as the entity validating the 2nd factor.
> 2. Extop which takes the:
>* user dn
>* type of 2nd factor
>* validation data
>* dn of 2nd factor (optional)
> 
> This provides an audit trail of who is validating 2nd factors.

Ok, this makes sense.
I wish we didn't have to create yet another extop, but if we want to
gate the check via another bind it makes sense.

> > > I'm thus not sure if we'll ever add more second factors to the
> > > existing
> > > simple bind mechanism.
> > LDAP binds still need to test both factors if they are required ...
> 
> We would grandfather OTP. But all new 2FA would require GSSAPI (using
> AIs) to use LDAP.

I do not think we can enforce this, we still have a lot of deployments
that rely on LDAP binds to check credentials, and we should try to
support this as much as possible.

> > > > - 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
> > > > kind
> > > > of client may want to set this control ? Perhaps one day we can
> > > > have
> > > > a
> > > > way to do GSSAPI auth and check that the AI on the ldap ticket
> > > > was a
> > > > 2FA
> > > > and then DS will refuse login if the otp AI was missing on the
> > > > ticket
> > > > it
> > > > received and the control requires it ? (could be used for the IPA
> > > > UI
> > > > connection to LDAP maybe ?)
> > > That seems to me like a decision LDAP can make internally. No?
> > Not if the user has optional 2FA and you want to enforce the second
> > factor only for certain operations from the framework (like say
> > changing
> > passwords or other more privileged operations).
> 
> Why can't we just use GSSAPI with AIs?

We would! But the AI check would be done (optionally) for the LDAP
server, not the HTTP service, remember that we do s4u2proxy and use
GSSAPI auth from the framework.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Jakub Hrozek]

On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote:
> On Fri, 2016-02-26 at 13:17 +0100, Lukáš Hellebrandt wrote:
> > Hi, FreeIPA and SSSD communities!
> > 
> > I am working on adding URI to HBAC as my thesis [1]. The goal is to
> > control access not only based on (user, host, service), but on (user,
> > host, service, resource's URI).
> > 
> > I created a patch for FreeIPA [2] so it is capable of storing URI as
> > part of HBAC rule. I created a patch for SSSD [3] so it is able to get
> > this URI from FreeIPA and use it in HBAC evaluation.
> > 
> > I still need to develop a part of SSSD receiving URI-aware requests. It
> > will either be an enhancement of Infopipe or I will use PAM responder
> > (any suggestions?).
> > 
> > I wanted to kindly ask you for review and your opinions on the patches
> > and generally on my approach. This would be my first contribution to
> > FreeIPA and SSSD so there might be bugs. What do you think?
> > 
> > Btw, is there some better place to share patches than a pasting tool?
> > Maybe some form of pull request?
> > 
> > Thanks for your opinions!
> > 
> > [1]
> > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa
> > [2]
> > http://pastebin.com/rsHzXeAR
> > [3]
> > http://pastebin.com/atcZMuP1
> > 
> 
> Hi Lukas, could please post your patches here using git-format-patch or
> even better provide a public git tree with them applied ?
> (Any place github, fedorapeople, your own server, etc. is fine)
> 
> 
> First a question, what service can actually use this scheme and how ?
> there is no URL field in PAM.

When Lukas started the work, we IIRC concluded that PAM is not an
appropriate interface and we should probably expose some DBUS methods
for access control. We haven't really discussed any details since then.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES] 0772-0774 Python3 fixes in for client installation

[Petr Viktorin]

On 02/22/2016 12:37 PM, Petr Viktorin wrote:
> Hello,
> These fixes are needed for the "happy path" of ipa-client-install
> --server on Python 3.

Hello,
Could someone please look at these patches?



-- 
Petr Viktorin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Simo Sorce]

On Fri, 2016-02-26 at 13:17 +0100, Lukáš Hellebrandt wrote:
> Hi, FreeIPA and SSSD communities!
> 
> I am working on adding URI to HBAC as my thesis [1]. The goal is to
> control access not only based on (user, host, service), but on (user,
> host, service, resource's URI).
> 
> I created a patch for FreeIPA [2] so it is capable of storing URI as
> part of HBAC rule. I created a patch for SSSD [3] so it is able to get
> this URI from FreeIPA and use it in HBAC evaluation.
> 
> I still need to develop a part of SSSD receiving URI-aware requests. It
> will either be an enhancement of Infopipe or I will use PAM responder
> (any suggestions?).
> 
> I wanted to kindly ask you for review and your opinions on the patches
> and generally on my approach. This would be my first contribution to
> FreeIPA and SSSD so there might be bugs. What do you think?
> 
> Btw, is there some better place to share patches than a pasting tool?
> Maybe some form of pull request?
> 
> Thanks for your opinions!
> 
> [1]
> https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa
> [2]
> http://pastebin.com/rsHzXeAR
> [3]
> http://pastebin.com/atcZMuP1
> 

Hi Lukas, could please post your patches here using git-format-patch or
even better provide a public git tree with them applied ?
(Any place github, fedorapeople, your own server, etc. is fine)


First a question, what service can actually use this scheme and how ?
there is no URL field in PAM.


On the patches:

[2] you define a new attribute Url which is fine, but the actual
attribute is not ok in several way.

- You assigned an OID from a hole in the IPAv2 Attibutes space, it
should be an assigned ID from the IPAv3 attribute space instead

- You do not namespace the attribute, it should at least be ipaUrl 

- you are using case Exact matching, is this intentional? Are the URIs
in there case sensitive strings ?

- there is an available attribute called labeledURI (with alias
labeledurl) in the standard schema (however I notice it also has
caseExactMatch) that has basically the same definition of your Url
attribute, why not use that one ?

[3] If I read the patch correctly failing to find a Url is a fatal
condition, this is not ok as it would fail to operate with older servers
that do not have a url on the rules.


It is not clear to me what happen on an older client if URL is used but
not the service? Or is service always enforced ? (It is not clear to me
that it is).


HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH] 0001 Adding URL to HBAC rule

[Lukáš Hellebrandt]

On 02/26/2016 01:30 PM, Martin Kosek wrote:
> Greetings, welcome!
> 
> On 02/26/2016 01:17 PM, Lukáš Hellebrandt wrote:
> ...
>> Btw, is there some better place to share patches than a pasting tool?
>> Maybe some form of pull request?
> 
> There is :-) Please see advise here:
> 
> http://www.freeipa.org/page/Contribute/Code#Submit_a_patch
> 
> It has more information on top of submitting patches. For example, I think it
> would actually make sense to start with a design page where you would describe
> the use cases, design, APIs, etc:
> 
> http://www.freeipa.org/page/Contribute/Code#Prepare
> 
> Martin
> 

Should I send it as an attachment? Ok, sending, but do not apply it yet
(even if you don't find bugs), I just need some feedback - not
everything is done yet.


-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com
From 001d6c90c6fd007a49a22a9d96fe31fcc5b8ba6c Mon Sep 17 00:00:00 2001
From: Lukas Hellebrandt 
Date: Thu, 18 Feb 2016 18:43:59 +0100
Subject: [PATCH] Adding URL to HBAC rule

---
 ACI.txt|  2 +-
 API.txt|  9 ++---
 VERSION|  4 ++--
 install/share/60basev2.ldif|  3 ++-
 install/ui/src/freeipa/hbac.js | 14 --
 install/ui/test/data/ipa_init.json |  3 ++-
 ipalib/plugins/hbacrule.py |  7 +--
 ipalib/plugins/internal.py |  1 +
 8 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/ACI.txt b/ACI.txt
index 24cb332ce6e10c82a5bfab76d084fb6c0277800d..ecacc1ca50b6203d90879dcca35fdad16f7fc15b 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -93,7 +93,7 @@ aci: (targetattr = "externalhost || memberhost || memberservice || memberuser")(
 dn: cn=hbac,dc=ipa,dc=example
 aci: (targetattr = "accessruletype || accesstime || cn || description || hostcategory || ipaenabledflag || servicecategory || sourcehost || sourcehostcategory || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Modify HBAC Rule";allow (write) groupdn = "ldap:///cn=System: Modify HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetattr = "accessruletype || accesstime || cn || createtimestamp || description || entryusn || externalhost || hostcategory || ipaenabledflag || ipauniqueid || member || memberhost || memberservice || memberuser || modifytimestamp || objectclass || servicecategory || sourcehost || sourcehostcategory || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Read HBAC Rules";allow (compare,read,search) userdn = "ldap:///all;;)
+aci: (targetattr = "accessruletype || accesstime || cn || createtimestamp || description || entryusn || externalhost || hostcategory || ipaenabledflag || ipauniqueid || member || memberhost || memberservice || memberuser || modifytimestamp || objectclass || servicecategory || sourcehost || sourcehostcategory || url || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Read HBAC Rules";allow (compare,read,search) userdn = "ldap:///all;;)
 dn: cn=hbacservices,cn=hbac,dc=ipa,dc=example
 aci: (targetfilter = "(objectclass=ipahbacservice)")(version 3.0;acl "permission:System: Add HBAC Services";allow (add) groupdn = "ldap:///cn=System: Add HBAC Services,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbacservices,cn=hbac,dc=ipa,dc=example
diff --git a/API.txt b/API.txt
index e2976e0e2897355bdb7ead438d4b67524f2fb1e8..5886e6a94bd8f25caa54c373e9ac9314e0755aff 100644
--- a/API.txt
+++ b/API.txt
@@ -1656,7 +1656,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
 command: hbacrule_add
-args: 1,16,3
+args: 1,17,3
 arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, required=True)
 option: StrEnum('accessruletype', attribute=True, autofill=True, cli_name='type', default=u'allow', exclude='webui', multivalue=False, required=True, values=(u'allow', u'deny'))
 option: Str('addattr*', cli_name='addattr', exclude='webui')
@@ -1672,6 +1672,7 @@ option: Str('setattr*', cli_name='setattr', exclude='webui')
 option: DeprecatedParam('sourcehost_host', attribute=True, cli_name='sourcehost_host', multivalue=False, required=False)
 option: DeprecatedParam('sourcehost_hostgroup', attribute=True, cli_name='sourcehost_hostgroup', multivalue=False, required=False)
 option: DeprecatedParam('sourcehostcategory', attribute=True, cli_name='sourcehostcategory', multivalue=False, required=False)
+option: Str('url', attribute=True, cli_name='url', multivalue=False, required=False)
 option: StrEnum('usercategory', attribute=True, cli_name='usercat', multivalue=False, required=False, values=(u'all',))
 option: Str('version?', exclude='webui')
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
@@ -1748,7 

Re: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI

[thierry bordaz]

On 02/25/2016 07:17 PM, thierry bordaz wrote:

On 02/25/2016 12:03 PM, Martin Babinsky wrote:

On 02/24/2016 04:30 PM, thierry bordaz wrote:

On 01/21/2016 05:04 PM, Martin Babinsky wrote:

On 01/21/2016 01:37 PM, thierry bordaz wrote:





Hi Thierry,

I have couple of comments to your patch:

1.)
there is a number of PEP8 errors in the patch
(http://paste.fedoraproject.org/313246/33893701), please fix them.

See http://www.freeipa.org/page/Python_Coding_Style for our
conventions used in Python code.

2.)
+DNA_BIND_METHOD   = "dnaRemoteBindMethod"
+DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol"
+DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config'
+dna_config_base   = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN

Uppercase names are usually reserved for module-level constants. OTOH,
local variables should be lowercase. Also you can instantiate
dna_config_base directly as DN, using 2-member tuples, i. e:

"""
dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric
Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config'))
"""

When passing DN object to the formatting functions/operators, it is
automatically converted to string so no need to hold string and DN
object separately. This is done in other places (see function/methods
in replication.py).

3.)

+for i in range(len(entries)) :
+
+mod = []
+if entries[i].single_value.get(DNA_BIND_METHOD) != 
method:
+mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, 
method))

+
+if entries[i].single_value.get(DNA_CONN_PROTOCOL) !=
protocol:
+mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL,
protocol))


please use idiomatic Python when handling list of entries, e.g.:

"""
for entry in entries:
   mod = []
   if entry.single_value.get(DNA_BIND_METHOD) != method:
   ...
"""

4.) I think that this method should in DSInstance class since it deals
with directory server configuration. Service is a parent object of all
other service installers/configurators and should contain only methods
common to more children.

5.) Since the method is called from every installer, it could be
beneficial to call it in DSInstance.__common_post_setup() as a part of
Directory server installation. Is there any reason why this is not the
case?

6.)

+while attempt != MAX_WAIT:
+try:
+entries = conn.get_entries(sharedcfgdn,
scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn)
+break
+except errors.NotFound:
+root_logger.debug("So far enable not find DNA shared
config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn,
sharedcfgdn))
+attempt = attempt + 1
+time.sleep(2)
+continue
+
+# safety checking
+# there is no return, if there are several entries, as a
workaround of #5510
+if len(entries) != 1:

I am quite afraid what would happen if the server does not return any
entries until 30 s timeout. The code will then continue to the
condition which can potentially test an uninitialized variable and
blow up with 'NameError'. This should be handled more robustly, e. g.
raise an exception when a timeout is reached and no entries were
returned.

7.)

+if len(mod) > 0:

A Pythonic way to test for non-empty container is

"""
if mods:
   # do stuff
"""

since an empty list/dict/set evaluates to False and non-empty
containers are True.


8.)

+entry = conn.get_entry(entries[i].dn)
+if entry.single_value.get(DNA_BIND_METHOD) != method:
+root_logger.error("Fail to set SASL/GSSAPI bind
method to %s" % (entries[i].dn))
+if entry.single_value.get(DNA_CONN_PROTOCOL) !=
protocol:
+root_logger.error("Fail to set LDAP protocol to
%s" % (entries[i].dn))

rather than re-fetching the modified entry and testing what happened,
you can just catch an exception raised by unsuccessfull mod and log an
error like this:

"""
try:
   conn.modify_s(entry.dn, mod)
except Exception as e:
   root_logger.error("Failed to modify entry {}: {}".format(entry, e))
"""

as a matter of fact, if the modify_s operation would fail for some
reason, an ldap exception would be raised and you checks would not
even be executed.

9.)
The debug message on line 219 should read "Unable to find DNA shared
config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors
at the end of the method should have "Failed" instead of "Fail".


Hi Martin,

Finally tested... here is the updated patch. Thanks for you patience


thanks
thierry


Hi Thierry,

the patch works as expected. I have some more nitpicks though:

1.) Please fix the following pep8 errors:

http://paste.fedoraproject.org/329086/56397841/

you can check whether you recent commit conforms to PEP8 by running

"git show -U0 | pep8 --diff"

2.)
+self.step("update DNA shared config 

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Nathaniel McCallum]

On Fri, 2016-02-26 at 10:12 -0500, Simo Sorce wrote:
> On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote:
> > 
> > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote:
> > > Questions:
> > > - Should the control specify what kind of auth specifically
> > > should be
> > > required ?
> > I had also wondered that. I'm certainly not against it. But I'd
> > probably prefer a simple utf8 string value to avoid parsing
> > complexity.
> > 
> > > 
> > > - 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 ?
> > I'm personally hoping that we can deprecate ipa-otpd after SPAKE
> > lands.
> > Post-SPAKE validations will require a method for validating OTP-
> > only
> > (excluding password). This will probably be an extop. The same will
> > be
> > true for all new second factors.
> Why an extop ? I was thinking you'd do a bind with this same control
> with a string that specifies you want to check only the second
> factor.
> (The result of the bind will be positive but you won't be logged in
> as
> the user the connection will still be marked anonymous.)

How can you do this anonymously? You need to know which tokens to
validate. This requires a user dn. Besides, I would think we also want
to be bound *before* performing this operation. Otherwise, we could
allow brute force tries on the 2nd factor.

I was thinking:
1. Bind as the entity validating the 2nd factor.
2. Extop which takes the:
   * user dn
   * type of 2nd factor
   * validation data
   * dn of 2nd factor (optional)

This provides an audit trail of who is validating 2nd factors.

> > I'm thus not sure if we'll ever add more second factors to the
> > existing
> > simple bind mechanism.
> LDAP binds still need to test both factors if they are required ...

We would grandfather OTP. But all new 2FA would require GSSAPI (using
AIs) to use LDAP.

> > > - 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
> > > kind
> > > of client may want to set this control ? Perhaps one day we can
> > > have
> > > a
> > > way to do GSSAPI auth and check that the AI on the ldap ticket
> > > was a
> > > 2FA
> > > and then DS will refuse login if the otp AI was missing on the
> > > ticket
> > > it
> > > received and the control requires it ? (could be used for the IPA
> > > UI
> > > connection to LDAP maybe ?)
> > That seems to me like a decision LDAP can make internally. No?
> Not if the user has optional 2FA and you want to enforce the second
> factor only for certain operations from the framework (like say
> changing
> passwords or other more privileged operations).

Why can't we just use GSSAPI with AIs?

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote:
> On Thu, 2016-02-25 at 16:51 -0500, 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 wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 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
> > > > > > > > a
> > > > > > > > request/response pair.
> > > > > > > > A client that wishes to know what kind of authentication
> > > > > > > > happened
> > > > > > > > should
> > > > > > > > send a request control, and only in that case , the
> > > > > > > > server
> > > > > > > > will
> > > > > > > > send
> > > > > > > > the
> > > > > > > > associated reply control with the requested information.
> > > > > > > I just pushed a new version of the control (now merged into
> > > > > > > a
> > > > > > > single
> > > > > > > patch): https://github.com/npmccallum/freeipa/commit/a78191
> > > > > > > ee5d
> > > > > > > 31
> > > > > > > e1de
> > > > > > > 39
> > > > > > > 

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Petr Spacek]

On 25.2.2016 16:46, Simo Sorce wrote:
> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote:
>> On 25.2.2016 15:28, Simo Sorce wrote:
>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote:
 Variant C
 -
 An alternative is to be lazy and dumb. Maybe it would be enough for
 the first
 round ...

 We would retain
 [first step - no change from variant A]
 * create locations
 * assign 'main' (aka 'primary' aka 'home') servers to locations
 ++ specify weights for the 'main' servers in given location, i.e.
 manually
 input (server, weight) tuples

 Then, backups would be auto-generated set of all remaining servers
 from all
 other locations.

 Additional storage complexity: 0

 This covers the scenario "always prefer local servers and use remote
 only as
 fallback" easily. It does not cover any other scenario.

 This might be sufficient for the first run and would allow us to
 gather some
 feedback from the field.

 Now I'm inclined to this variant :-)
>>>
>>> To be honest, this is all I always had in mind, for the first step.
>>>
>>> To recap:
>>> - define a location with the list of servers (perhaps location is a
>>> property of server objects so you can have only one location per server,
>>> and if you remove the server it is automatically removed from the
>>> location w/o additional work or referential integrity necessary), if
>>> weight is not defined (default) then they all have the same weight.
>>
>> Agreed.
>>
>>
>>> - Allow to specify backup locations in the location object, priorities
>>> are calculated automatically and all backup locations have same weight.
>>
>> Hmm, weights have to be inherited form the original location in all cases. 
>> Did
>> you mean that all backup locations have the same *priority*?
> 
> Yes, sorry.
> 
>> Anyway, explicit configuration of backup locations is introducing API and
>> schema for variant A and that is what I'm questioning above. It is hard to
>> make it extensible so we do not have headache in future when somebody decides
>> that more flexibility is needed OR that link-based approach is better.
> 
> I think no matter we do we'll need to allow admins to override backup
> locations, in future if we can calculate them automatically admins will
> simply not set any backup location explicitly (or set some special value
> like "autogenerate" and the system will do it for them.
> 
> Forcing admins to mentally calculate weights to force the system to
> autogenerate the configuration they want would be a bad experience, I
> personally would find it very annoying.
> 
>> In other words, for doing what you propose above we would have to design
>> complete schema and API for variant A anyway to make sure we do not lock
>> ourselves, so we are not getting any saving by doing so.
> 
> A seemed much more complicated to me, as you wanted to define a ful
> matrix for weights of servers when they are served as backups and all
> that.
> 
>>> - Define a *default* location, which is the backup for any other
>>> location but always with lower priority to any other explicitly defined
>>> backup locations.
>>
>> I would rather *always* use the default location as backup for all other
>> locations. It does not require any API or schema (as it equals to "all
>> servers" except "servers in this location" which can be easily calculated on 
>> fly).
> 
> We can start with this, but it works well only in a stellar topology
> where you have a central location all other location connect to.
> As soon as you have a super-stellar topology where you have hub location
> to which regional locations connect to, then this is wasteful.
> 
>> This can be later on extended in whatever direction we want without any
>> upgrade/migration problem.
>>
>> More importantly, all the schema and API will be common for all other 
>> variants
>> anyway so we can start doing so and see how much time is left when it is 
>> done.
> 
> I am ok with this for the first step.
> After all location is mostly about the "normal" case where clients want
> to reach the local servers, the backup part is only an additional
> feature we can keep simple for now. It's a degraded mode of operation
> anyway so it is probably ok to have just one default backup location as
> a starting point.

Okay, now we are in agreement. I will think about minimal schema and API over
the weekend.

Petr^2 Spacek


>>> - Weights for backup location servers are the same as the weight defined
>>> within the backup location itself, so no additional weights are defined
>>> for backups.
>>
>> Yes, that was somehow implied in the variant A. Sorry for not mentioning it.
>> Weight is always relative number for servers inside one location.
> 
> Ok it looked a lot more complex from your description.
> 
> Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute 

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Nathaniel McCallum]

On Thu, 2016-02-25 at 16:51 -0500, 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 wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 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
> > > > > > > a
> > > > > > > request/response pair.
> > > > > > > A client that wishes to know what kind of authentication
> > > > > > > happened
> > > > > > > should
> > > > > > > send a request control, and only in that case , the
> > > > > > > server
> > > > > > > will
> > > > > > > send
> > > > > > > the
> > > > > > > associated reply control with the requested information.
> > > > > > I just pushed a new version of the control (now merged into
> > > > > > a
> > > > > > single
> > > > > > patch): https://github.com/npmccallum/freeipa/commit/a78191
> > > > > > ee5d
> > > > > > 31
> > > > > > e1de
> > > > > > 39
> > > > > > f28eb637f66199da7e9225
> > > > > > 
> > > > > > 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
> > > > > > 

[Freeipa-devel] [PATCH 0403] adtrustinstance: Make sure smb.conf exists

[Tomas Babej]

Hi,

The 'net' command fails unless smb.conf exists. Touch
the file prior to any 'net' call to make sure we do not crash
for this very reason.

I couldn't find the aforementioned Samba bug either in the RH/Samba
bugzilla, despite spending non-trivial amount of time searching for it.

Can somebody point me to it? I referenced the IPA ticket for now.

https://fedorahosted.org/freeipa/ticket/5687
From 4fd714beec5c95e079028836168e0188ed27ff0c Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Fri, 26 Feb 2016 14:28:26 +0100
Subject: [PATCH] adtrustinstance: Make sure smb.conf exists

The 'net' command fails unless smb.conf exists. Touch
the file prior to any 'net' call to make sure we do not crash
for this very reason.

https://fedorahosted.org/freeipa/ticket/5687
---
 ipaserver/install/adtrustinstance.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py
index 54a23bc15d818864f0987b02294244414ed9883f..cd346e0698e7c7d2e0f9f76893104cdf7262fb98 100644
--- a/ipaserver/install/adtrustinstance.py
+++ b/ipaserver/install/adtrustinstance.py
@@ -517,6 +517,11 @@ class ADTRUSTInstance(service.Service):
 os.write(tmp_fd, conf)
 os.close(tmp_fd)
 
+# Workaround for: https://fedorahosted.org/freeipa/ticket/5687
+# We make sure that paths.SMB_CONF file exists, hence touch it
+with open(paths.SMB_CONF, 'a'):
+os.utime(paths.SMB_CONF, None)
+
 args = [paths.NET, "conf", "import", tmp_name]
 
 try:
-- 
2.5.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Martin Kosek]

Greetings, welcome!

On 02/26/2016 01:17 PM, Lukáš Hellebrandt wrote:
...
> Btw, is there some better place to share patches than a pasting tool?
> Maybe some form of pull request?

There is :-) Please see advise here:

http://www.freeipa.org/page/Contribute/Code#Submit_a_patch

It has more information on top of submitting patches. For example, I think it
would actually make sense to start with a design page where you would describe
the use cases, design, APIs, etc:

http://www.freeipa.org/page/Contribute/Code#Prepare

Martin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Lukáš Hellebrandt]

Hi, FreeIPA and SSSD communities!

I am working on adding URI to HBAC as my thesis [1]. The goal is to
control access not only based on (user, host, service), but on (user,
host, service, resource's URI).

I created a patch for FreeIPA [2] so it is capable of storing URI as
part of HBAC rule. I created a patch for SSSD [3] so it is able to get
this URI from FreeIPA and use it in HBAC evaluation.

I still need to develop a part of SSSD receiving URI-aware requests. It
will either be an enhancement of Infopipe or I will use PAM responder
(any suggestions?).

I wanted to kindly ask you for review and your opinions on the patches
and generally on my approach. This would be my first contribution to
FreeIPA and SSSD so there might be bugs. What do you think?

Btw, is there some better place to share patches than a pasting tool?
Maybe some form of pull request?

Thanks for your opinions!

[1]
https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa
[2]
http://pastebin.com/rsHzXeAR
[3]
http://pastebin.com/atcZMuP1

-- 
Lukas Hellebrandt

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members

[Tomas Babej]

On 02/26/2016 07:30 AM, Jan Cholasta wrote:
> On 22.2.2016 19:56, Tomas Babej wrote:
>>
>>
>> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote:
>>> On Mon, 22 Feb 2016, Tomas Babej wrote:


 On 02/22/2016 11:48 AM, Alexander Bokovoy wrote:
> Hi,
>
> attached patch should update compat tree configuration if it exist to
> follow slapi-nis 0.55 which has support for external members of IPA
> groups.
>
> However, the real work is done in SSSD. These patches are not
> upstreamed
> yet. We'll need to bump SSSD dependency in future once they come to
> distros.
>
>
>

 This looks good.

 However, the new update file needs to be added to Makefile.am.
 Additionally, patch adds a whitespace error.
>>> Updated patch is attached.
>>>
>>
>> ACK.
>>
>> This should not be pushed until the dependency for SSSD can be bumped.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74
> 

Attaching the required spec change.

Tomas
From dae8b8fd0b23bf25ccf75b275deaa5c599faa27b Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Fri, 26 Feb 2016 12:35:09 +0100
Subject: [PATCH] spec: Bump required sssd version to 1.13.3-5

Required as part of: https://fedorahosted.org/freeipa/ticket/4403
---
 freeipa.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 7dff2605d2d681a07841f401967971cbfffe2243..3ae12fff7745e24edffa0c49d314aefb4feda404 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -323,7 +323,7 @@ Requires: pam_krb5
 Requires: curl
 Requires: libcurl >= 7.21.7-2
 Requires: xmlrpc-c >= 1.27.4
-Requires: sssd >= 1.13.1
+Requires: sssd >= 1.13.3-5
 Requires: python-sssdconfig
 Requires: certmonger >= 0.78
 Requires: nss-tools
-- 
2.5.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 953 advise: configure TLS in redhat_nss_pam_ldapd and redhat_nss_ldap plugins

[Lukas Slebodnik]

On (25/02/16 18:01), Petr Vobornik wrote:
>I did not add --enableldapstarttls to config_redhat_nss_ldap because I'm not
>sure if it is present on el5 (IMO it is not).
>
I can confirm it doesn't have such option
[root@host /]# authconfig --help | grep -A1 "tls\|ssl"
  --enableldaptls, --enableldapssl
enable use of TLS with LDAP
  --disableldaptls, --disableldapssl
disable use of TLS with LDAP
[root@host /]# cat /etc/issue
CentOS release 5.11 (Final)
Kernel \r on an \m

LS

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Request to add support to specify username/password for each host

[Niranjan]

Greetings,

Request to review the patch for 
https://fedorahosted.org/python-pytest-multihost/ticket/5

Regards
Niranjan

From 28cd560f58b96817306a6eae6976e26166a9351a Mon Sep 17 00:00:00 2001
From: Niranjan MR 
Date: Fri, 26 Feb 2016 15:30:25 +0530
Subject: [PATCH] Add support to specify usernames/password per host

https://fedorahosted.org/python-pytest-multihost/ticket/5

Signed-off-by: Niranjan MR 
---
 pytest_multihost/host.py  | 12 +---
 pytest_multihost/transport.py | 12 ++--
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py
index f3346f6..7885722 100644
--- a/pytest_multihost/host.py
+++ b/pytest_multihost/host.py
@@ -26,10 +26,13 @@ class BaseHost(object):
 """
 transport_class = None
 
-def __init__(self, domain, hostname, role, ip=None,
- external_hostname=None):
+def __init__(self, domain, hostname, role, 
+ username=None, password=None,
+ ip=None, external_hostname=None):
 self.domain = domain
 self.role = str(role)
+self.username = username
+self.password = password
 
 shortname, dot, ext_domain = hostname.partition('.')
 self.shortname = shortname
@@ -109,9 +112,12 @@ class BaseHost(object):
 ip = dct.pop('ip', None)
 external_hostname = dct.pop('external_hostname', None)
 
+username = dct.pop('username', None)
+password = dct.pop('password', None)
+
 check_config_dict_empty(dct, 'host %s' % hostname)
 
-return cls(domain, hostname, role, ip, external_hostname)
+return cls(domain, hostname, role, username, password, ip, 
external_hostname)
 
 def to_dict(self):
 """Export info about this Host to a dict"""
diff --git a/pytest_multihost/transport.py b/pytest_multihost/transport.py
index eda71cd..e893e48 100644
--- a/pytest_multihost/transport.py
+++ b/pytest_multihost/transport.py
@@ -177,11 +177,19 @@ class ParamikoTransport(Transport):
  host.ssh_port))
 self._transport = transport = paramiko.Transport(sock)
 transport.connect(hostkey=host.host_key)
+if host.password:
+ self.log.debug('Authenticating with password set in host section')
+ transport.auth_password(username=host.username,
+ password=host.password)
 if host.ssh_key_filename:
-self.log.debug('Authenticating with private RSA key')
 filename = os.path.expanduser(host.ssh_key_filename)
 key = paramiko.RSAKey.from_private_key_file(filename)
-transport.auth_publickey(username=host.ssh_username, key=key)
+if host.username:
+self.log.debug('Authenticating with private RSA key using user 
%s' % ( host.username))
+transport.auth_publickey(username=host.username, key=key)
+else:
+self.log.debug('Authenticating with private RSA key')
+transport.auth_publickey(username=host.ssh_username, key=key)
 elif host.ssh_password:
 self.log.debug('Authenticating with password')
 transport.auth_password(username='root',
-- 
1.9.3



pgpgvYpuw5e0L.pgp
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation

[Oleg Fayans]

On 02/25/2016 12:06 PM, Petr Spacek wrote:
> On 24.2.2016 15:13, Martin Basti wrote:
>> https://fedorahosted.org/freeipa/ticket/5686
>>
>> Patch attached.
> 
> LGTM, ACK if it passes QE testing.
> 
That did it. Works with both replica-prepare under domain level 0 and
with replica-install on domlevel1.

ACK


-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Martin Kosek]

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 wrote:
>>
>>
>> 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
>>> a
>>> request/response pair.
>>> A client that wishes to know what kind of authentication
>>> happened
>>> should
>>> send a request control, and only in that case , the server
>>> will
>>> send
>>> the
>>> associated reply control with the requested information.
>> I just pushed a new version of the control (now merged into a
>> single
>> patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d
>> 31
>> e1de
>> 39
>> f28eb637f66199da7e9225
>>
>> 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
>> will fail.
>>
>> This approach is simpler and doesn't require a request/response
>> control
>> pair.
> I need some design advice. My goal here is that we need a way to
> expose
> the authentication indicators to services in the FreeIPA UI/CLI.
>
> Here is the good news: users can already set these values in
> FreeIPA
> using kadmin. They do this by simply setting the require_auth
> string on
> the target service principal. Our kdb plugin then encodes these
> with
> the rest of the tl_data into the krbExtraData attribute.
>
> I see two approaches here. First, we can try to manipulate the
> krbExtraData attribute directly. Second, we can create a separate
> attribute for the authentication indicator strings and then
> synthesize
> the tl_data internally in kdb. We would have to do this for both
> reads
> and writes so as not to break existing kdb functionality.
>
> The trade-off that I see is that the first method complicates the
> python