Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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 f
Re: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation
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
[Freeipa-devel] Request to add support to specify username/password for each host
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] 953 advise: configure TLS in redhat_nss_pam_ldapd and redhat_nss_ldap plugins
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
Re: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members
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
[Freeipa-devel] URI in HBAC rules - patch - request for feedback
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] URI in HBAC rules - patch - request for feedback
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
Re: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095
Hey guys, could anyone review this please? On 02/19/2016 02:11 PM, Oleg Fayans wrote: > Hi Milan, > > On 02/12/2016 04:03 PM, Milan Kubík wrote: >> On 02/04/2016 08:49 AM, Oleg Fayans wrote: >>> Hi Petr, >>> >>> On 02/03/2016 02:19 PM, Petr Spacek wrote: On 3.2.2016 10:22, Oleg Fayans wrote: > Guys, can anyone take a look at this? The commit message does not explain why you are setting search path. >>> Fixed. >>> I have to say that I do not like touching resolv.conf, as stated many times earlier. Why the test has to reconfigure the host and cannot use values provided by the provisioning system? >>> This patch exactly removes this messing around with nameservers in >>> resolv.conf >>> It introduces the possibility to put ipa domain in the search directive >>> of resolv.conf so that we could test service autodiscovery during client >>> installation. >>> >>> >>> >> I just verified that the tampering with resolv.conf is not needed >> (libvirt and ovirt/rhev). I think this is an artifact from the whole >> issue of "let's use improvised domain names, what can go wrong" approach >> that was uncovered by the enforced DNS checks. I think we can defer the >> networking configuration to provisioning system. > > Agreed. The latest patch gets rid of all resolv.conf related > manipulations. The tests work (where not affected by > https://fedorahosted.org/bind-dyndb-ldap/ticket/160) > > >> >> -- >> Milan Kubik >> > > > -- 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
[Freeipa-devel] [PATCH 0403] adtrustinstance: Make sure smb.conf exists
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] [PATCH] 953 advise: configure TLS in redhat_nss_pam_ldapd and redhat_nss_ldap plugins
On 25.2.2016 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). > > authconfig in: > * config_redhat_nss_ldap got > * --enableldaptls > > * config_redhat_nss_pam_ldapd got > * --enableldaptls > * --enableldapstarttls > options Shouldn't it get only one of them? It seems weird to enable both at the same time. Petr^2 Spacek > https://fedorahosted.org/freeipa/ticket/5654 -- 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
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 > > > > > > t
Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface
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 t
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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 > > > > > > > f28eb637f66199
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI
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
[Freeipa-devel] [PATCH] 0001 Adding URL to HBAC rule
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 +1749,7 @@ output: Ou
Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback
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
Re: [Freeipa-devel] [PATCHES] 0772-0774 Python3 fixes in for client installation
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
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] [REVIEW] Intial stab towards Authentication Indicators
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
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] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI
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.) +
[Freeipa-devel] [PATCH 00136] use LDAPS during standalone CA/KRA subsystem deployment
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: self.__remove_admin_from_group(group) self.admin_conn.de
Re: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members
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
Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators
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] [REVIEW] Intial stab towards Authentication Indicators
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