[Freeipa-devel] [freeipa PR#10] Client-side CSR autogeneration (comment)

[LiptonB]

LiptonB commented on a pull request

"""
As discussed elsewhere, this script generation is a fairly low-level operation; 
you have to specify the helper and know how to run the script. Most users will 
probably want a command that just takes in a private key location and a profile 
and requests the cert for them. In case you'd like to look at it now, I have an 
implementation of that in a separate branch, which I'll create a pull request 
for after this one is complete: 
https://github.com/freeipa/freeipa/compare/master...LiptonB:local-cert-build
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/10#issuecomment-243811501
-- 
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] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
Probably instead of that magic, there could be:
```
self.testdir = os.path.abspath(os.path.dirname(__file__))
```
It should always find the proper local directory

And please in read_file, instead of plus sign, use os.path.join(self.testdir, 
filename)
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/42#issuecomment-243806638
-- 
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] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
I don't like this. Will we have if/elif for each possible location of where 
tests are executed. What changed? I'm sure those tests work in past. Why dir 
where test is executed was changed?
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/42#issuecomment-243804469
-- 
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] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (opened)

[mirielka]

mirielka's pull request #42: "Tests: Avoid skipping tests due to missing files" 
was opened

PR body:
"""
When running test_install/test_updates and test_pkcs10/test_pkcs10 as
outoftree, these are skipped with reason 'Unable to find test update files'.
For outoftree tests wrong paths are checked for these files.
Adding proper paths to test setup.

https://fedorahosted.org/freeipa/ticket/6284
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/42
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/42/head:pr42
git checkout pr42
From 965e54f016f52bdfcddb05a08d49ba4a01af25b8 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Wed, 31 Aug 2016 15:51:51 +0200
Subject: [PATCH] Tests: Avoid skipping tests due to missing files

When running test_install/test_updates and test_pkcs10/test_pkcs10 as
outoftree, these are skipped with reason 'Unable to find test update files'.
For outoftree tests wrong paths are checked for these files.
Adding proper paths to test setup.

https://fedorahosted.org/freeipa/ticket/6284
---
 ipatests/test_install/test_updates.py | 2 ++
 ipatests/test_pkcs10/test_pkcs10.py   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/ipatests/test_install/test_updates.py b/ipatests/test_install/test_updates.py
index b41a7c5..51301cc 100644
--- a/ipatests/test_install/test_updates.py
+++ b/ipatests/test_install/test_updates.py
@@ -69,6 +69,8 @@ def setUp(self):
 self.testdir="./"
 elif ipautil.file_exists("ipatests/test_install/0_reset.update"):
 self.testdir= "./ipatests/test_install/"
+elif ipautil.file_exists("test_install/0_reset.update"):
+self.testdir= "./test_install/"
 else:
 raise nose.SkipTest("Unable to find test update files")
 
diff --git a/ipatests/test_pkcs10/test_pkcs10.py b/ipatests/test_pkcs10/test_pkcs10.py
index 86de3c6..6a61709 100644
--- a/ipatests/test_pkcs10/test_pkcs10.py
+++ b/ipatests/test_pkcs10/test_pkcs10.py
@@ -45,6 +45,8 @@ def setup(self):
 self.testdir="./"
 elif ipautil.file_exists("ipatests/test_pkcs10/test0.csr"):
 self.testdir= "./ipatests/test_pkcs10/"
+elif ipautil.file_exists("test_pkcs10/test0.csr"):
+self.testdir= "./test_pkcs10/"
 else:
 raise nose.SkipTest("Unable to find test update files")
 
-- 
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] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (closed)

[mbasti-rh]

tomaskrizek's pull request #41: "Postpone enabling LDAPS in replica promotion" 
was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/41
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/41/head:pr41
git checkout pr41
-- 
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] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (comment)

[jcholast]

jcholast commented on a pull request

"""
`ipa-replica-install` fails with:
```
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
448, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
438, in run_step
method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 
786, in __enable_ssl
self.nickname, self.fqdn, cadb)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 336, 
in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 405, 
in issue_server_cert
self.secdir, password, "ipaCert", **params)
  File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 156, in 
https_request
method=method, headers=headers)
  File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 207, in 
_httplib_request
raise NetworkError(uri=uri, error=str(e))
NetworkError: cannot connect to 
'https://vm-058-011.abc.idm.lab.eng.brq.redhat.com:8443/ca/ee/ca/profileSubmitSSLClient':
 (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.
```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/41#issuecomment-243770659
-- 
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] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (comment)

[jcholast]

jcholast commented on a pull request

"""
However, I don't think this should block the release of 4.4.1, so I would just 
revert 89de60c5d8ba64d619101a7498b8c4469b6e50ae and keep the ticket open.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/41#issuecomment-243771692
-- 
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] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/f32e0e4e522e09390f4295dd79f52d7a48877d3a
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/40#issuecomment-243758104
-- 
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] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (+pushed)

[mbasti-rh]

martbab's pull request #40: "do not use trusted forest name to construct domain 
admin principal" label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/40
-- 
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] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (+pushed)

[mbasti-rh]

mirielka's pull request #39: "Tests: Add missing attributes to 
test_xmlrpc/test_trust tests" label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/39
-- 
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] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/60e88038c43c2ea2afc7e48f3e8dbd9bcfe955e8
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/39#issuecomment-243757482
-- 
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] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (closed)

[mbasti-rh]

mirielka's pull request #39: "Tests: Add missing attributes to 
test_xmlrpc/test_trust tests" was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/39
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/39/head:pr39
git checkout pr39
-- 
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] [freeipa PR#39] Tests: Add missing attributes to test_xmlrpc/test_trust tests (+ack)

[gkaihorodova]

mirielka's pull request #39: "Tests: Add missing attributes to 
test_xmlrpc/test_trust tests" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/39
-- 
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] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (+ack)

[abbra]

martbab's pull request #40: "do not use trusted forest name to construct domain 
admin principal" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/40
-- 
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] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (comment)

[abbra]

abbra commented on a pull request

"""
Apologies. This is indeed a minor issue which is correctly fixed, so ACK for 
this one.
Note, though, this will not help with the actual query because regardless of 
what credentials were used, AD DC of a child domain behaves wrongly in Windows 
Server 2012R2 by not following MS-NRPC 3.5.4.7.5.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/40#issuecomment-243756126
-- 
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] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (comment)

[abbra]

abbra commented on a pull request

"""
NACK. This is wrong.
In the case of external trust to a child domain we cannot run 
netr_DsRGetForestTrustInformation() against the child domain, regardless what 
credentials we have. Instead, we should run this request against the forest 
root domain using the credentials specified by the user.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/40#issuecomment-243752391
-- 
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] [freeipa PR#41] Postpone enabling LDAPS in replica promotion (opened)

[tomaskrizek]

tomaskrizek's pull request #41: "Postpone enabling LDAPS in replica promotion" 
was opened

PR body:
"""
Fixes a bug that prevented ipa-replica-install with CA, because
LDAPS was configured before the SSL cerificate was assigned.

https://fedorahosted.org/freeipa/ticket/6226
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/41
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/41/head:pr41
git checkout pr41
From cffb2ca4051a64ea57f1a2019d9c413636f35124 Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Wed, 31 Aug 2016 14:41:38 +0200
Subject: [PATCH] Postpone enabling LDAPS in replica promotion

Fixes a bug that prevented ipa-replica-install with CA, because
LDAPS was configured before the SSL cerificate was assigned.

https://fedorahosted.org/freeipa/ticket/6226
---
 ipaserver/install/dsinstance.py| 1 -
 ipaserver/install/server/replicainstall.py | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 8e26485..26cd246 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -395,7 +395,6 @@ def create_replica(self, realm_name, master_fqdn, fqdn,
 self.step("creating DS keytab", self.__get_ds_keytab)
 if self.ca_is_configured:
 self.step("retrieving DS Certificate", self.__get_ds_cert)
-self.step("configuring ssl for ds instance", self.__enable_ssl)
 self.step("restarting directory server", self.__restart_instance)
 
 self.step("setting up initial replication", self.__setup_replica)
diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py
index c73600c..77d75b3 100644
--- a/ipaserver/install/server/replicainstall.py
+++ b/ipaserver/install/server/replicainstall.py
@@ -1476,6 +1476,9 @@ def promote(installer):
 cainstance.export_kra_agent_pem()
 CA.fix_ra_perms()
 
+# we now need to enable ssl on the ds
+ds.enable_ssl()
+
 krb = install_krb(config,
   setup_pkinit=not options.no_pkinit,
   promote=True)
-- 
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] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (closed)

[dkupka]

jcholast's pull request #35: "rpcserver: assume version 1 for unversioned 
command calls" was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/35
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/35/head:pr35
git checkout pr35
-- 
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] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (comment)

[dkupka]

dkupka commented on a pull request

"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/8891465247a0bab5d07f560f2c963f3ee56905f0
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/35#issuecomment-243750424
-- 
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] restrict setkeytab operation

[Martin Basti]

On 26.07.2016 13:38, Simo Sorce wrote:

On Mon, 2016-07-25 at 11:26 -0400, Simo Sorce wrote:

On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote:

Simo Sorce wrote:

On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:

Simo Sorce wrote:

As described in #232 start restricting the use of the setkeytab
operation to just the computers objects.

I haven't tested this with older RHEL/CentOS machines that actully use
the setkeytab operation as I do not have such an old VM handy right now.

Meanwhile I'd like to know if ppl agree with this approach.

What about services?

Do we automatically acquire keytab for services in the old clients ?

Are you thinking about scripted ipa-getkytab callouts ?

You are limiting access to host keytabs, what about service keytabs?
Should they be or are they now similarly restricted?

Installers for something like Foreman may try to generate a service
keytab in its installer, probably using admin credentials. I am planning
to do the same in Openstack.

Ok I'll amend the patch to allow service keytabs to still use the
setkeytab control still, and restrict only users.
However note that the idea of using this method is that admin can change
this default on their own, so they can restrict more or less if they
want, to that end I need to remember how to set a default that we do not
override in the update file.

Simo.


Amended patch to allow services too.
Only users are excluded.

Simo.





bump for review
-- 
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] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (+pushed)

[dkupka]

jcholast's pull request #35: "rpcserver: assume version 1 for unversioned 
command calls" label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/35
-- 
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] [freeipa PR#35] rpcserver: assume version 1 for unversioned command calls (+ack)

[dkupka]

jcholast's pull request #35: "rpcserver: assume version 1 for unversioned 
command calls" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/35
-- 
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] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (closed)

[mbasti-rh]

mirielka's pull request #17: "Tests: Random issuer certificate can be added to 
a service" was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/17
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/17/head:pr17
git checkout pr17
-- 
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] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (+pushed)

[mbasti-rh]

mirielka's pull request #17: "Tests: Random issuer certificate can be added to 
a service" label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/17
-- 
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] [freeipa PR#17] Tests: Random issuer certificate can be added to a service (+ack)

[gkaihorodova]

mirielka's pull request #17: "Tests: Random issuer certificate can be added to 
a service" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/17
-- 
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] [freeipa PR#40] do not use trusted forest name to construct domain admin principal (opened)

[martbab]

martbab's pull request #40: "do not use trusted forest name to construct domain 
admin principal" was opened

PR body:
"""
When `trust-add` is supplied AD domain admin name without realm component, the
code appends the uppercased AD forest root domain name to construct the full
principal. This can cause authentication error, however, when external trust
with non-root domain is requested.

We should instead use the supplied DNS domain name (if valid) as a realm
component.

https://fedorahosted.org/freeipa/ticket/6277
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/40
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/40/head:pr40
git checkout pr40
From ebce3c0cdf8a4b1df35614187c782551c2c590eb Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Wed, 31 Aug 2016 13:59:14 +0200
Subject: [PATCH] do not use trusted forest name to construct domain admin
 principal

When `trust-add` is supplied AD domain admin name without realm component, the
code appends the uppercased AD forest root domain name to construct the full
principal. This can cause authentication error, however, when external trust
with non-root domain is requested.

We should instead use the supplied DNS domain name (if valid) as a realm
component.

https://fedorahosted.org/freeipa/ticket/6277
---
 ipaserver/plugins/trust.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index 26f85c2..65dc1f4 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -319,7 +319,7 @@ def generate_creds(trustinstance, style, **options):
 else:
sp = admin_name.split(sep)
 if len(sp) == 1:
-sp.append(trustinstance.remote_domain.info['dns_forest'].upper())
+sp.append(trustinstance.remote_domain.info['dns_domain'].upper())
 creds = u"{name}%{password}".format(name=sep.join(sp),
 password=password)
 return creds
-- 
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] Release 4.4.1 planning

[Martin Basti]

On 30.08.2016 15:00, Alexander Bokovoy wrote:

Hi,

we have a plan to release FreeIPA 4.4.1 on Wednesday, Aug 31st.

I started preparing a release page:
http://www.freeipa.org/page/Releases/4.4.1

It has staggering 140+ closed tickets already.

Please help me with filling in enhancements and bug fixes sections.



We must postpone release today, fix for 
https://fedorahosted.org/freeipa/ticket/6226 pushed yesterday causes 
replica installation issues


Sorry :-(

--
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] [DESIGN][UPDATE] Time-Based HBAC Policies

[Petr Spacek]

On 31.8.2016 12:42, Standa Laznicka wrote:
> On 08/30/2016 03:34 PM, Simo Sorce wrote:
>> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:
>>> On 08/26/2016 05:37 PM, Simo Sorce wrote:
 On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:
> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:
>> On Fri, 26 Aug 2016, Simo Sorce wrote:
>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
> I miss "why" part of "To be able to handle backward compatibility
 with
> ease, a new object called ipaHBACRulev2 is introduced. " in the
 design
> page. If the reason is the above - old client's should ignore time
 rules
> then it has to be mentioned there. Otherwise I don't see a reason to
> introduce a new object type instead of extending the current.
 How do you want to enforce HBAC rule that have set time from 10 to 14
 everyday? With the same objectclass old clients will allow this HBAC
 for
 all day. Isn't this CVE?
>>> This is a discussion worth having.
>>>
>>> In general it is a CVE only if an authorization mechanism fails to work
>>> as advertised.
>>>
>>> If you make it clear that old clients *DO NOT* respect time rules then
>>> there is no CVE material, it is working as "described".
>>>
>>> The admins already have a way to not set those rules for older clients
>>> by simply grouping newer clients in a different host group and applying
>>> time rules only there.
>>>
>>> So the question really is: should we allow admins to apply an HBAC Rule
>>> potentially to older clients that do not understand it and will
>>> therefore allow access at any time of the day, or should we prevent it ?
>>>
>>> This is a hard question to answer and can go both ways.
>>>
>>> A time rule may be something that admins want to enforce at all cost or
>>> deny access. In this case a client that fails to handle it would be a
>>> problem.
>>>
>>> But it may be something that is just used for defense in depth and not a
>>> strictly hard requirement. In this case allowing older clients would
>>> make it an easy transition as you just set up the rule and the client
>>> will start enforcing the time when it is upgraded but work otherwise
>>> with the same rules.
>>>
>>> I am a bit conflicted on trying to decide what scenario we should
>>> target, but the second one appeals to me because host groups do already
>>> give admins a good way to apply rules to a specific set of hosts and
>>> exclude old clients w/o us making it a hard rule.
>>> OTOH if an admin does not understand this difference, they may be
>>> surprised to find out there are clients that do not honor it.
>>>
>>> Perhaps we could find a way to set a flag on the rule such that when set
>>> (and only when set) older clients get excluded by way of changing the
>>> objectlass or something else to similar effect.
>>>
>>> Open to discussion.
>> At this point using new object class becomes an attractive approach. We
>> don't have means to exclude HBAC rules other than applying them
>> per-host/hostgroup. We also have no deny rules.
>>
>> I have another idea: what about enforcing time rules always to apply
>> per-host or per-hostgroup by default? Add --force option to override the
>> behavior but default to not allow --hostcat=all. This would raise
>> awareness and make sure admins are actually applying these rules with
>> intention.
> This sounds like a good idea, but it is not a silver bullet I am afraid.
>
> Simo.
 I was thinking that for future proofing we could add a version field,
 then reasoned more and realized that changing the object class is
 basically the same thing.

 There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
 (I know 389ds allows us to do an LDAPv3 illegal operation and change it,
 but I do not like to depend on that behavoir).

 Now looking into this I had an idea to solve the problem of legacy
 clients without having to swap classes.
 We can redefine the accessRuleType attribute to be a "capability" type.

 Ie rules that have a timeAccess component will be of type
 "allow_with_time" instead of just "allow".
 Old clients are supposed to search with accessRuleType=allow (and I can
 see that SSSD does that), so an older client will fail to get those
 rules as they won't match.

 New clients instead can recognize both types.

 Also if we need a future extension we will simpy add a new access rule
 type and we can have the same effect.
 The nice thing is that accessRyleType is defined as multivalue (no
 SINGLE in schema) so we may actually create compatible rules if we want
 to.
 Ie we could set both "allow" and 

[Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (synchronize)

[jcholast]

jcholast's pull request #34: " dns: prompt for missing record parts in CLI" was 
synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/34
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/34/head:pr34
git checkout pr34
From 5f3ccad67bb5eb9d3ed9b60bcaedcc8ebb3a31b9 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 29 Aug 2016 12:34:25 +0200
Subject: [PATCH 1/2] dns: prompt for missing record parts in CLI

Fix the code which determines if a record part is required and thus should
be prompted not to wrongfully consider all record parts to be optional.

https://fedorahosted.org/freeipa/ticket/6203
---
 ipaclient/plugins/dns.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ipaclient/plugins/dns.py b/ipaclient/plugins/dns.py
index e17c282..18903cd 100644
--- a/ipaclient/plugins/dns.py
+++ b/ipaclient/plugins/dns.py
@@ -45,11 +45,21 @@
 _rev_top_record_types = ('PTR', )
 _zone_top_record_types = ('NS', 'MX', 'LOC', )
 
+_optional_part_params = {
+'loc_part_lat_min',
+'loc_part_lat_sec',
+'loc_part_lon_min',
+'loc_part_lon_sec',
+'loc_part_size',
+'loc_part_h_precision',
+'loc_part_v_precision',
+}
+
 
 def __get_part_param(cmd, part, output_kw, default=None):
 name = part.name
 label = unicode(part.label)
-optional = not part.required
+optional = name in _optional_part_params
 
 output_kw[name] = cmd.prompt_param(part,
optional=optional,
@@ -91,7 +101,7 @@ def prompt_missing_parts(rrtype, cmd, kw, prompt_optional=False):
 if name in kw:
 continue
 
-optional = not part.required
+optional = name in _optional_part_params
 if optional and not prompt_optional:
 continue
 

From 4f2ae8a0b2c522130413fffbb594df2741ffcc75 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Tue, 23 Aug 2016 12:53:39 +0200
Subject: [PATCH 2/2] dns: fix crash in interactive mode against old servers

Add a client-side fallback of the dnsrecord_split_parts command for old
servers to avoid CommandError in dnsrecord_add and dnsrecord_mod CLI
interactive mode.

https://fedorahosted.org/freeipa/ticket/6203
---
 ipaclient/plugins/dns.py | 62 +++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/ipaclient/plugins/dns.py b/ipaclient/plugins/dns.py
index 18903cd..ade442f 100644
--- a/ipaclient/plugins/dns.py
+++ b/ipaclient/plugins/dns.py
@@ -22,6 +22,7 @@
 
 import six
 import copy
+import re
 
 from ipaclient.frontend import MethodOverride
 from ipalib import errors
@@ -30,7 +31,8 @@
 has_cli_options,
 iterate_rrparams_by_parts,
 record_name_format)
-from ipalib.parameters import Bool
+from ipalib.frontend import Command
+from ipalib.parameters import Bool, Str
 from ipalib.plugable import Registry
 from ipalib import _, ngettext
 from ipapython.dnsutil import DNSName
@@ -129,6 +131,64 @@ class dnszone_mod(DNSZoneMethodOverride):
 pass
 
 
+# Support old servers without dnsrecord_split_parts
+# Do not add anything new here!
+@register(no_fail=True)
+class dnsrecord_split_parts(Command):
+NO_CLI = True
+
+takes_args = (
+Str('name'),
+Str('value'),
+)
+
+def execute(self, name, value, *args, **options):
+def split_exactly(count):
+values = value.split()
+if len(values) != count:
+return None
+return tuple(values)
+
+result = ()
+
+rrtype = get_record_rrtype(name)
+if rrtype in ('A', '', 'CNAME', 'DNAME', 'NS', 'PTR'):
+result = split_exactly(1)
+elif rrtype in ('AFSDB', 'KX', 'MX'):
+result = split_exactly(2)
+elif rrtype in ('CERT', 'DLV', 'DS', 'SRV', 'TLSA'):
+result = split_exactly(4)
+elif rrtype in ('NAPTR'):
+result = split_exactly(6)
+elif rrtype in ('A6', 'TXT'):
+result = (value,)
+elif rrtype == 'LOC':
+regex = re.compile(
+r'(?P\d{1,2}\s+)'
+r'(?:(?P\d{1,2}\s+)'
+r'(?P\d{1,2}(?:\.\d{1,3})?\s+)?)?'
+r'(?P[NS])\s+'
+r'(?P\d{1,3}\s+)'
+r'(?:(?P\d{1,2}\s+)'
+r'(?P\d{1,2}(?:\.\d{1,3})?\s+)?)?'
+r'(?P[WE])\s+'
+r'(?P-?\d{1,8}(?:\.\d{1,2})?)m?'
+r'(?:\s+(?P\d{1,8}(?:\.\d{1,2})?)m?'
+r'(?:\s+(?P\d{1,8}(?:\.\d{1,2})?)m?'
+r'(?:\s+(?P\d{1,8}(?:\.\d{1,2})?)m?\s*)?)?)?$')
+
+m = regex.match(value)
+if m is not None:
+result = tuple(
+x.strip() if x is not None else x for x in m.groups())
+elif rrtype == 'SSHFP':
+  

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was originally
actually used to distinguish newer version of HBAC rules from the older
so we may just do this again and profit from its original purpose. To
top it off, this change should be really easy to implement to what I
currently have on SSSD side.

I was just wondering 

[Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (comment)

[jcholast]

jcholast commented on a pull request

"""
I have decided to instead copy & paste the code, as it exists solely for the 
purpose of supporting old servers, so it should not get any additional 
improvements in the future.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/34#issuecomment-243725653
-- 
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] [freeipa PR#34] dns: prompt for missing record parts in CLI (synchronize)

[jcholast]

jcholast's pull request #34: " dns: prompt for missing record parts in CLI" was 
synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/34
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/34/head:pr34
git checkout pr34
From 5f3ccad67bb5eb9d3ed9b60bcaedcc8ebb3a31b9 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 29 Aug 2016 12:34:25 +0200
Subject: [PATCH 1/2] dns: prompt for missing record parts in CLI

Fix the code which determines if a record part is required and thus should
be prompted not to wrongfully consider all record parts to be optional.

https://fedorahosted.org/freeipa/ticket/6203
---
 ipaclient/plugins/dns.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ipaclient/plugins/dns.py b/ipaclient/plugins/dns.py
index e17c282..18903cd 100644
--- a/ipaclient/plugins/dns.py
+++ b/ipaclient/plugins/dns.py
@@ -45,11 +45,21 @@
 _rev_top_record_types = ('PTR', )
 _zone_top_record_types = ('NS', 'MX', 'LOC', )
 
+_optional_part_params = {
+'loc_part_lat_min',
+'loc_part_lat_sec',
+'loc_part_lon_min',
+'loc_part_lon_sec',
+'loc_part_size',
+'loc_part_h_precision',
+'loc_part_v_precision',
+}
+
 
 def __get_part_param(cmd, part, output_kw, default=None):
 name = part.name
 label = unicode(part.label)
-optional = not part.required
+optional = name in _optional_part_params
 
 output_kw[name] = cmd.prompt_param(part,
optional=optional,
@@ -91,7 +101,7 @@ def prompt_missing_parts(rrtype, cmd, kw, prompt_optional=False):
 if name in kw:
 continue
 
-optional = not part.required
+optional = name in _optional_part_params
 if optional and not prompt_optional:
 continue
 

From 8484092d72a75e9f8fe043b9bcb6558478c87e41 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Tue, 23 Aug 2016 12:53:39 +0200
Subject: [PATCH 2/2] dns: fix crash in interactive mode against old servers

Add a client-side fallback of the dnsrecord_split_parts command for old
servers to avoid CommandError in dnsrecord_add and dnsrecord_mod CLI
interactive mode.

https://fedorahosted.org/freeipa/ticket/6203
---
 ipaclient/plugins/dns.py | 61 +++-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/ipaclient/plugins/dns.py b/ipaclient/plugins/dns.py
index 18903cd..31e4f6b 100644
--- a/ipaclient/plugins/dns.py
+++ b/ipaclient/plugins/dns.py
@@ -22,6 +22,7 @@
 
 import six
 import copy
+import re
 
 from ipaclient.frontend import MethodOverride
 from ipalib import errors
@@ -30,7 +31,8 @@
 has_cli_options,
 iterate_rrparams_by_parts,
 record_name_format)
-from ipalib.parameters import Bool
+from ipalib.frontend import Command
+from ipalib.parameters import Bool, Str
 from ipalib.plugable import Registry
 from ipalib import _, ngettext
 from ipapython.dnsutil import DNSName
@@ -129,6 +131,63 @@ class dnszone_mod(DNSZoneMethodOverride):
 pass
 
 
+# Support old servers without dnsrecord_split_parts
+@register(no_fail=True)
+class dnsrecord_split_parts(Command):
+NO_CLI = True
+
+takes_args = (
+Str('name'),
+Str('value'),
+)
+
+def execute(self, name, value, *args, **options):
+def split_exactly(count):
+values = value.split()
+if len(values) != count:
+return None
+return tuple(values)
+
+result = ()
+
+rrtype = get_record_rrtype(name)
+if rrtype in ('A', '', 'CNAME', 'DNAME', 'NS', 'PTR'):
+result = split_exactly(1)
+elif rrtype in ('AFSDB', 'KX', 'MX'):
+result = split_exactly(2)
+elif rrtype in ('CERT', 'DLV', 'DS', 'SRV', 'TLSA'):
+result = split_exactly(4)
+elif rrtype in ('NAPTR'):
+result = split_exactly(6)
+elif rrtype in ('A6', 'TXT'):
+result = (value,)
+elif rrtype == 'LOC':
+regex = re.compile(
+r'(?P\d{1,2}\s+)'
+r'(?:(?P\d{1,2}\s+)'
+r'(?P\d{1,2}(?:\.\d{1,3})?\s+)?)?'
+r'(?P[NS])\s+'
+r'(?P\d{1,3}\s+)'
+r'(?:(?P\d{1,2}\s+)'
+r'(?P\d{1,2}(?:\.\d{1,3})?\s+)?)?'
+r'(?P[WE])\s+'
+r'(?P-?\d{1,8}(?:\.\d{1,2})?)m?'
+r'(?:\s+(?P\d{1,8}(?:\.\d{1,2})?)m?'
+r'(?:\s+(?P\d{1,8}(?:\.\d{1,2})?)m?'
+r'(?:\s+(?P\d{1,8}(?:\.\d{1,2})?)m?\s*)?)?)?$')
+
+m = regex.match(value)
+if m is not None:
+result = tuple(
+x.strip() if x is not None else x for x in m.groups())
+elif rrtype == 'SSHFP':
+values = 

Re: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin

[Martin Basti]

On 30.08.2016 13:27, Martin Basti wrote:



On 11.08.2016 16:39, Alexander Bokovoy wrote:

On Thu, 11 Aug 2016, thierry bordaz wrote:
+/* rc should always be 0 (else slapi_sdn_new_dn_byref 
should have sigsev)
+ * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to 
stop here

+ * because ret is not significant */

A short note here. You talk about slapi_sdn_new_dn_byref() but your
patch replaces that with slapi_sdn_new_dn_byval(). Does the comment
still apply?


+if (rc != 0) {
+LOG_OOM();
+goto free_and_return;
+}
+
   if (ret == 0) {
   Slapi_Value *cpw[2] = { NULL, NULL };
   Slapi_Value *pw;
--
2.7.4





Good catch Alexander. Yes the comment contained a wrong cut/paste

ACK.



Is there a ticket for this?


Pushed to master: b942b00ac7bca7e2864c7dc513d25983556916ff

--
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