[Freeipa-devel] [PATCH] spec: require Dogtag >= 10.3.3-3

[Fraser Tweedale]

On Thu, Jul 07, 2016 at 01:16:04PM +0200, Petr Spacek wrote:
> Hello,
> 
> IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for
> Fedora any time soon?
> 
> Or should I update my scripts to automatically enable
> COPR @freeipa/freeipa-master
> in my testing VMs?
> 
> Thanks.
> Petr^2 Spacek
>
Hi Petr,

The required features were released for Fedora as 10.3.3-3.
Attached patch retracts the min required version accordingly.

Thanks,
Fraser
From f6fd4c9c7838e841e1a3728d7e9afbe5f081927d Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Fri, 8 Jul 2016 14:47:06 +1000
Subject: [PATCH] spec: require Dogtag >= 10.3.3-3

Required features that were expected to be released in Dogtag 10.3.4
have instead been released for Fedora in 10.3.3-3.  Retract the
minimum required version.

https://fedorahosted.org/freeipa/ticket/5956
---
 freeipa.spec.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 
ff27a32eebcc640cdbc8895f47732f06a90c4a1b..135e9c980011c6c2730c6c29a3c22098e48270d5
 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -94,7 +94,7 @@ BuildRequires:  libunistring-devel
 BuildRequires:  python-lesscpy
 BuildRequires:  python-yubico >= 1.2.3
 BuildRequires:  openssl-devel
-BuildRequires:  pki-base >= 10.3.4
+BuildRequires:  pki-base >= 10.3.3-3
 BuildRequires:  python-pytest-multihost >= 0.5
 BuildRequires:  python-pytest-sourceorder
 BuildRequires:  python-kdcproxy >= 0.3
@@ -155,8 +155,8 @@ Requires(post): systemd-units
 Requires: selinux-policy >= %{selinux_policy_version}
 Requires(post): selinux-policy-base >= %{selinux_policy_version}
 Requires: slapi-nis >= 0.56.0
-Requires: pki-ca >= 10.3.4
-Requires: pki-kra >= 10.3.4
+Requires: pki-ca >= 10.3.3-3
+Requires: pki-kra >= 10.3.3-3
 Requires(preun): python systemd-units
 Requires(postun): python systemd-units
 Requires: zip
-- 
2.5.5

-- 
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 0038-0040] Sub CA test patches

[Fraser Tweedale]

On Thu, Jul 07, 2016 at 03:46:52PM +0200, Milan Kubík wrote:
> On 07/04/2016 08:57 AM, Fraser Tweedale wrote:
> > Hi Milan,
> > 
> > Yes, we can :)  Two issues, outlined below.
> > 
> > 
> > 1)
> > Running the tests, I get error in
> > test_create_subca_with_subject_conflict cleanup::
> > 
> >   ERROR at teardown of 
> > TestCAbasicCRUD.test_create_subca_with_subject_conflict _
> > 
> >  def cleanup():
> >  created = self.exists
> >  try:
> >  del_command()
> > 
> >  
> >  E   NotFound: crud-subca-2: Certificate Authority not found
> > 
> > 
> > I do not know testing framework very well but it looks like
> > track_create() sets 'self.exists = True' before the create command
> > throws the (expected) DuplicateEntry error.  (These are called from
> > create() in the tracker 'base' class).  Later, cleanup() catches a
> > NotFound but re-throws it because it believes the entry should have
> > existed.
> > 
> > 
> > 2)
> > the usercert.conf.tmpl does not like a subject base with spaces in
> > it, i.e. if 'openssl req' config template gets formatted like:
> > 
> >  [ dn ]
> >  commonName = "alice"
> >  o=IPA.LOCAL 201606201330
> > 
> > then 'openssl req' fails with nasty error like:
> > 
> >  140644791924600:error:0D06407A:asn1 encoding 
> > routines:a2d_ASN1_OBJECT:first num too large:a_object.c:108:
> >  140644791924600:error:0B083077:x509 certificate 
> > routines:X509_NAME_ENTRY_create_by_txt:invalid field 
> > name:x509name.c:295:name=o
> > 
> > and CalledProcessError gets raised and the test fails.
> > 
> > Simplest solution is to simply remove the '{ipacertbase}' from the
> > template, because AFAIK it is not needed and parsing and formatting
> > the certbase (which could have multiple AVAs) is more complex than
> > the test calls for, IMO.
> > 
> > 
> > Thanks,
> > Fraser
> Hi, thanks.
> 
> I must have missed the first issue after I removed the expected fail marker.
> I have fixed it now.
> 
> As for the usercert template, this code is older than the issues at hand. I
> do not remember why exactly I used that
> option in the openssl config. I have removed that in a new patch.
> 
Thanks Milan,

All working for me now.  ACK on all four patches.

Cheers,
Fraser

-- 
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] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

[Fraser Tweedale]

On Thu, Jul 07, 2016 at 04:10:51PM +0200, Sebastian Hetze wrote:
> 
> 
> On 07/07/2016 03:16 PM, Rob Crittenden wrote:
> > Sebastian Hetze wrote:
> >> Hi *
> >>
> >> attached you find a patch that adds new options --subject_cn and
> >> --subject_mail to ipa-server-install that make the CA cert subject CN
> >> customizable.
> >>
> >> This patch has been tested by a customer in a PoC.
> >> However, i assume additional testing in different environments is
> >> required.
> >>
> >> It would be greatly appreciated if this patch would find its way into
> >> the product very soon.
> >
> > I don't see the advantage of passing around the subject_rdn along with
> > the base. Why not pre-combine them into a DN?
> Think of the subject_rdn as given name for the CA cert and the
> subject_base as family name for all subsequent service certs that IPA
> automatically generates and signs. While the given names for the
> generated service certs may stay hard coded, only the given name for the
> CA cert needs to be customizable as requested in the RFE.
> Look into the source and you will see that subject_base is used all over
> the place and subject_rdn (as replacement for the hard coded
> "CN=Certificate Authority") only related to the CA cert. They need to be
> kept separate.
> 
In your patch, subject_rdn is used in few places where it is passed
around.  I agree with Rob; in the handful of places where the full
DN is formed (currently by prepending "CN=Certificate Authority"),
we should pass in the full DN.

> >
> >
> > Similarly, I think I'd drop storing the subject base and RDN and just
> > store just the DN. I don't think there would be any backwards compat
> > issues as this would only apply to new installs.
> >
> > I think this would explode the number of options as users request
> > additional attributes for the subject (OU, C, etc). Might be better to
> > make the user pass in a full DN if they want to manage the CA subject.
> > I don't know if any validation would be required for dogtag (e.g. is
> > there a minimum set of components needed?)
> CN is mandatory and only emailAddress is a commonly used option for the
> "given name" subject_rdn. OU, C and alike belong to the subject_base.
>
Let us not add new arguments.  We should enhance --subject instead.

Existing behaviour:

- ``--subject`` gives subject base.  If not given, defaults to
  "O=$REALM".

- "CN=Certificate Authority" prepended to subject base to form
  full subject DN.

- Dogtag requires that the CA Subject DN starts with CN.

My proposal for augmented behaviour:

- If ``--subject`` not given, existing behaviour retained.

- If ``--subject`` supplied:

  1. Extract O, OU, C, L, ST and DC components from argument
  (order preserved) to form the subject base.  If argument
  contains none of these attributes, subject base is defaulted
  to "O=$REALM" (per current behaviour) and appended to the CA
  Subject DN.

  2. If argument contains CN but it is not the "most specific"
  RDN, move it to the front (to satisfy requirement of Dogtag
  profile).

  3. If argument does not contain CN, prepend "CN=Certificate
  Authortiy" per existing behaviour.

  4. Apart from (1), (2) and (3), CA Subject DN stays otherwise
  unchanged, therefore Email Address (E) is supported.

Sebastian, would this scheme meet your customer's requirements?

I also note, in your patch, that you define method
DsInstance.find_subject_rdn() but it is not used.  What is the
purpose of this method?

Thank you for providing this patch and pushing forward on this RFE.
If you are happy with my above proposal I'm happy to take ownership
and get this over this line.

Cheers,
Fraser

> >
> > rob
> 
> Beste Grüße / Best regards
>   Sebastian Hetze
> -- 
> Senior Solution Architect
> Red Hat GmbH. Niederlassung Berlin
> Am Treptower Park 75 12435 Berlin
> Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205
> Fax: +49 30 678 1798-111 . E-Mail: s...@redhat.com
> 
> -- 
> 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

-- 
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] 0001: Silence sshd messages during install

[Ben Lipton]

Thanks for the review! Comments below.


On 07/01/2016 07:42 AM, Martin Basti wrote:




On 29.06.2016 20:46, Ben Lipton wrote:
The attached patch silences some annoying messages I've been getting 
when upgrading the freeipa-client package on F24:

"""
WARNING: 'UseLogin yes' is not supported in Fedora and may cause 
several problems.
This will be fixed by openssh-7.2p2-9.fc24 
(https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably 
shouldn't worry about it.

Could not load host key: /etc/ssh/ssh_host_dsa_key
This is because by default sshd looks for all of 
/etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, 
/etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but Fedora 
doesn't generate a DSA key by default.

"""

Since the script causing the message only looks at the return code 
from sshd to determine the right options to use, I thought it might 
be ok to discard the output. What do you think?


Ben




Hello, I don't like to hiding errors/warnings. Can you determine and 
solve the root cause?


I definitely agree with this in principle, but in this case the purpose 
of this code is to try different, potentially wrong, parameters to sshd 
until it finds a combination that it accepts. It seems like in some 
environments this would produce error messages that aren't actionable 
and don't indicate any problem for package function, which is why I 
didn't think these messages were necessarily worth preserving.


On the other hand, if the code makes the wrong decision about sshd 
version we might be interested in error logs that show why. Can we log 
this to a file instead of the console, maybe?


If you'd prefer just addressing the root cause, a patch that prevents 
the missing host key error is attached, but it won't stop the error 
messages showing up when openssh is an older version.


Thanks,
Ben
From afb460c2fe3b8329ae5b8ed9603db8723e79c34a Mon Sep 17 00:00:00 2001
From: Ben Lipton 
Date: Thu, 7 Jul 2016 10:28:04 -0400
Subject: [PATCH] Use existing HostKey config to test sshd

Prevents sshd from producing warning messages on package upgrade because
not all of the default host key files (/etc/ssh/ssh_host_dsa_key,
/etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and
/etc/ssh/ssh_host_rsa_key) are present.
---
 freeipa.spec.in | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index ff27a32eebcc640cdbc8895f47732f06a90c4a1b..4a339869257df4b599b774ec7ac728d43ab33ff5 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -1007,17 +1007,21 @@ if [ -f '/etc/ssh/sshd_config' -a $restore -ge 2 ]; then
 /^(AuthorizedKeysCommand(User|RunAs)|PubKeyAgentRunAs)[ \t]/ d
 ' /etc/ssh/sshd_config >/etc/ssh/sshd_config.ipanew
 
-if /usr/sbin/sshd -t -f /dev/null -o 'AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys' -o 'AuthorizedKeysCommandUser=nobody'; then
+# Prevent complaints about missing host keys by using the configured ones
+tmp_config=$(mktemp sshd_config.XX)
+sed -n '/^HostKey[ \t]/ p' /etc/ssh/sshd_config > $tmp_config
+
+if /usr/sbin/sshd -t -f $tmp_config -o 'AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys' -o 'AuthorizedKeysCommandUser=nobody'; then
 sed -ri '
 s/^PubKeyAgent (.+) %u$/AuthorizedKeysCommand \1/
 s/^AuthorizedKeysCommand .*$/\0\nAuthorizedKeysCommandUser nobody/
 ' /etc/ssh/sshd_config.ipanew
-elif /usr/sbin/sshd -t -f /dev/null -o 'AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys' -o 'AuthorizedKeysCommandRunAs=nobody'; then
+elif /usr/sbin/sshd -t -f $tmp_config -o 'AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys' -o 'AuthorizedKeysCommandRunAs=nobody'; then
 sed -ri '
 s/^PubKeyAgent (.+) %u$/AuthorizedKeysCommand \1/
 s/^AuthorizedKeysCommand .*$/\0\nAuthorizedKeysCommandRunAs nobody/
 ' /etc/ssh/sshd_config.ipanew
-elif /usr/sbin/sshd -t -f /dev/null -o 'PubKeyAgent=/usr/bin/sss_ssh_authorizedkeys %u' -o 'PubKeyAgentRunAs=nobody'; then
+elif /usr/sbin/sshd -t -f $tmp_config -o 'PubKeyAgent=/usr/bin/sss_ssh_authorizedkeys %u' -o 'PubKeyAgentRunAs=nobody'; then
 sed -ri '
 s/^AuthorizedKeysCommand (.+)$/PubKeyAgent \1 %u/
 s/^PubKeyAgent .*$/\0\nPubKeyAgentRunAs nobody/
-- 
2.5.5

-- 
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] 0010 Show full error message for selinuxusermap-add-hostgroup

[Florence Blanc-Renaud]

On 07/07/2016 01:23 PM, Petr Vobornik wrote:

On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote:

Hi,

the output of ipa selinuxusermap-add-hostgroup and
selinuxusermap-add-user does not display any more the host/host group or
user/group that could not be added. This patch fixes this regression by
adding the labels host/hostgroup/user/group to the list of
_failed_member_output_params of the class ClientMethod.


https://fedorahosted.org/freeipa/ticket/6026



I've a feeling that this issue is more general and multiple commands
regressed. Would be good to check other member options, e.g. also in
user plugin.


Hi Petr,

you are right, a lot of other commands regressed. So far I checked only 
user and sudocmd but it is likely to be a long task. Are there 
regression tests that could help me make sure that the fix is exhaustive?


Flo

--
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] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

[Sebastian Hetze]

On 07/07/2016 03:16 PM, Rob Crittenden wrote:
> Sebastian Hetze wrote:
>> Hi *
>>
>> attached you find a patch that adds new options --subject_cn and
>> --subject_mail to ipa-server-install that make the CA cert subject CN
>> customizable.
>>
>> This patch has been tested by a customer in a PoC.
>> However, i assume additional testing in different environments is
>> required.
>>
>> It would be greatly appreciated if this patch would find its way into
>> the product very soon.
>
> I don't see the advantage of passing around the subject_rdn along with
> the base. Why not pre-combine them into a DN?
Think of the subject_rdn as given name for the CA cert and the
subject_base as family name for all subsequent service certs that IPA
automatically generates and signs. While the given names for the
generated service certs may stay hard coded, only the given name for the
CA cert needs to be customizable as requested in the RFE.
Look into the source and you will see that subject_base is used all over
the place and subject_rdn (as replacement for the hard coded
"CN=Certificate Authority") only related to the CA cert. They need to be
kept separate.

>
>
> Similarly, I think I'd drop storing the subject base and RDN and just
> store just the DN. I don't think there would be any backwards compat
> issues as this would only apply to new installs.
>
> I think this would explode the number of options as users request
> additional attributes for the subject (OU, C, etc). Might be better to
> make the user pass in a full DN if they want to manage the CA subject.
> I don't know if any validation would be required for dogtag (e.g. is
> there a minimum set of components needed?)
CN is mandatory and only emailAddress is a commonly used option for the
"given name" subject_rdn. OU, C and alike belong to the subject_base.
>
> rob

Beste Grüße / Best regards
  Sebastian Hetze
-- 
Senior Solution Architect
Red Hat GmbH. Niederlassung Berlin
Am Treptower Park 75 12435 Berlin
Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205
Fax: +49 30 678 1798-111 . E-Mail: s...@redhat.com

-- 
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] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

[Petr Vobornik]

On 07/07/2016 03:16 PM, Rob Crittenden wrote:

Sebastian Hetze wrote:

Hi *

attached you find a patch that adds new options --subject_cn and
--subject_mail to ipa-server-install that make the CA cert subject CN
customizable.

This patch has been tested by a customer in a PoC.
However, i assume additional testing in different environments is
required.

It would be greatly appreciated if this patch would find its way into
the product very soon.


I don't see the advantage of passing around the subject_rdn along with
the base. Why not pre-combine them into a DN?

Similarly, I think I'd drop storing the subject base and RDN and just
store just the DN. I don't think there would be any backwards compat
issues as this would only apply to new installs.

I think this would explode the number of options as users request
additional attributes for the subject (OU, C, etc). Might be better to
make the user pass in a full DN if they want to manage the CA subject. I
don't know if any validation would be required for dogtag (e.g. is there
a minimum set of components needed?)


+1, IMO using e.g., --subject="e=mail,cn=Something,O=REALM.NAME" is 
better. But IPA should validate it properly to disallow anything not 
usable by dogtag.


Adding Fraser for the dogtag part.



rob



--
Petr Vobornik

--
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 0038-0040] Sub CA test patches

[Milan Kubík]

On 07/04/2016 08:57 AM, Fraser Tweedale wrote:

Hi Milan,

Yes, we can :)  Two issues, outlined below.


1)
Running the tests, I get error in
test_create_subca_with_subject_conflict cleanup::

  ERROR at teardown of 
TestCAbasicCRUD.test_create_subca_with_subject_conflict _

 def cleanup():
 created = self.exists
 try:
 del_command()

 
 E   NotFound: crud-subca-2: Certificate Authority not found


I do not know testing framework very well but it looks like
track_create() sets 'self.exists = True' before the create command
throws the (expected) DuplicateEntry error.  (These are called from
create() in the tracker 'base' class).  Later, cleanup() catches a
NotFound but re-throws it because it believes the entry should have
existed.


2)
the usercert.conf.tmpl does not like a subject base with spaces in
it, i.e. if 'openssl req' config template gets formatted like:

 [ dn ]
 commonName = "alice"
 o=IPA.LOCAL 201606201330

then 'openssl req' fails with nasty error like:

 140644791924600:error:0D06407A:asn1 encoding 
routines:a2d_ASN1_OBJECT:first num too large:a_object.c:108:
 140644791924600:error:0B083077:x509 certificate 
routines:X509_NAME_ENTRY_create_by_txt:invalid field name:x509name.c:295:name=o

and CalledProcessError gets raised and the test fails.

Simplest solution is to simply remove the '{ipacertbase}' from the
template, because AFAIK it is not needed and parsing and formatting
the certbase (which could have multiple AVAs) is more complex than
the test calls for, IMO.


Thanks,
Fraser

Hi, thanks.

I must have missed the first issue after I removed the expected fail 
marker. I have fixed it now.


As for the usercert template, this code is older than the issues at 
hand. I do not remember why exactly I used that

option in the openssl config. I have removed that in a new patch.


--
Milan Kubik

From ac2fa02ef8f4d7290d8b7dbdd12ebf84d85d71f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= 
Date: Fri, 17 Jun 2016 12:20:55 +0200
Subject: [PATCH 1/3] ipatests: Tracker implementation for Sub CA feature

The patch implements Tracker subclass for CA plugin
and the basic CRUD tests for the plugin entries.

https://fedorahosted.org/freeipa/ticket/4559
---
 ipatests/test_xmlrpc/objectclasses.py |   5 +
 ipatests/test_xmlrpc/test_ca_plugin.py| 175 ++
 ipatests/test_xmlrpc/tracker/ca_plugin.py | 126 +
 ipatests/test_xmlrpc/xmlrpc_test.py   |   3 +
 4 files changed, 309 insertions(+)
 create mode 100644 ipatests/test_xmlrpc/test_ca_plugin.py
 create mode 100644 ipatests/test_xmlrpc/tracker/ca_plugin.py

diff --git a/ipatests/test_xmlrpc/objectclasses.py b/ipatests/test_xmlrpc/objectclasses.py
index 134a08803f3abca1124c4d26274d9e3fc981b941..1ea020b18f975f717eb9d9d5399d8e9fb40264cb 100644
--- a/ipatests/test_xmlrpc/objectclasses.py
+++ b/ipatests/test_xmlrpc/objectclasses.py
@@ -222,3 +222,8 @@ caacl = [
 u'ipaassociation',
 u'ipacaacl'
 ]
+
+ca = [
+u'top',
+u'ipaca',
+]
diff --git a/ipatests/test_xmlrpc/test_ca_plugin.py b/ipatests/test_xmlrpc/test_ca_plugin.py
new file mode 100644
index ..1e0e52ff748a5dc4faeab6526783ae95237ba73b
--- /dev/null
+++ b/ipatests/test_xmlrpc/test_ca_plugin.py
@@ -0,0 +1,175 @@
+#
+# Copyright (C) 2016  FreeIPA Contributors see COPYING for license
+#
+
+"""
+Test the `ipalib.plugins.ca` module.
+"""
+
+import pytest
+
+from ipalib import errors
+from ipatests.test_xmlrpc.xmlrpc_test import XMLRPC_test, fuzzy_issuer
+
+from ipatests.test_xmlrpc.tracker.certprofile_plugin import CertprofileTracker
+from ipatests.test_xmlrpc.tracker.caacl_plugin import CAACLTracker
+from ipatests.test_xmlrpc.tracker.ca_plugin import CATracker
+
+
+@pytest.fixture(scope='module')
+def default_profile(request):
+name = 'caIPAserviceCert'
+desc = u'Standard profile for network services'
+tracker = CertprofileTracker(name, store=True, desc=desc)
+tracker.track_create()
+return tracker
+
+
+@pytest.fixture(scope='module')
+def default_acl(request):
+name = u'hosts_services_caIPAserviceCert'
+tracker = CAACLTracker(name, service_category=u'all', host_category=u'all')
+tracker.track_create()
+tracker.attrs.update(
+{u'ipamembercertprofile_certprofile': [u'caIPAserviceCert']})
+return tracker
+
+
+@pytest.fixture(scope='module')
+def default_ca(request):
+name = u'ipa'
+desc = u'IPA CA'
+tracker = CATracker(name, fuzzy_issuer, desc=desc)
+tracker.track_create()
+return tracker
+
+
+@pytest.fixture(scope='class')
+def crud_subca(request):
+name = u'crud-subca'
+subject = u'CN=crud subca test,O=crud testing inc'
+tracker = CATracker(name, subject)
+
+return tracker.make_fixture(request)
+
+
+@pytest.fixture(scope='class')
+def subject_conflict_subca(request):
+

Re: [Freeipa-devel] IPA clients in AD DNS domain & Kerberos referrals

[Alexander Bokovoy]

On Thu, 07 Jul 2016, Petr Spacek wrote:

Hello,

this is probably a silly idea ...

I wonder if there is some way to use Kerberos referrals on AD side in a way
which would return cross-realm referral to IPA realm.

Maybe it could be used in Frankenstein setup where IPA client belongs to a DNS
domain managed by AD ... I do not know, just throwing out the idea.

Yes, throw it out completely. :)

For each trust Active Directory has a name suffix routing table. This
table contains list of fully qualified domain names (TLNs) that belong to the
trusted domain/forest's namespace or excluded from it.

For those TLNs which belong to the trusted domain/forest namespace,
Kerberos cross-realm TGT is issued to the client together with the
referral.

For those TLNs which are excluded from the namespace belonging to the
trusted domain/forest namespace, no Kerberos cross-realm TGT is issued
and no referral is given.

If any of the TLNs from the trusted domain/forest conflicts with the
Active Directory's own table or from any other trusted domain/forest,
the trust is frozen and the conflict is marked as such. The whole forest
trust is non-operational then.

So there is only one possible solution: add exclusion TLNs for every
host that belongs to IPA but is in AD DNS namespace to the AD own table.
I talked to Microsoft people while at IOLab event and we verified that
this is not a solution. The routing table is a single list and is
consulted every single TGT request. This makes a solution of TLN
exclusion entries a highly inefficient and affecting performance of all
AD DCs for any requests.

--
/ Alexander Bokovoy

--
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] IPA clients in AD DNS domain & Kerberos referrals

[Petr Spacek]

Hello,

this is probably a silly idea ...

I wonder if there is some way to use Kerberos referrals on AD side in a way
which would return cross-realm referral to IPA realm.

Maybe it could be used in Frankenstein setup where IPA client belongs to a DNS
domain managed by AD ... I do not know, just throwing out the idea.

-- 
Petr^2 Spacek

-- 
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] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

[Rob Crittenden]

Sebastian Hetze wrote:

Hi *

attached you find a patch that adds new options --subject_cn and
--subject_mail to ipa-server-install that make the CA cert subject CN
customizable.

This patch has been tested by a customer in a PoC.
However, i assume additional testing in different environments is required.

It would be greatly appreciated if this patch would find its way into
the product very soon.


I don't see the advantage of passing around the subject_rdn along with 
the base. Why not pre-combine them into a DN?


Similarly, I think I'd drop storing the subject base and RDN and just 
store just the DN. I don't think there would be any backwards compat 
issues as this would only apply to new installs.


I think this would explode the number of options as users request 
additional attributes for the subject (OU, C, etc). Might be better to 
make the user pass in a full DN if they want to manage the CA subject. I 
don't know if any validation would be required for dogtag (e.g. is there 
a minimum set of components needed?)


rob

--
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] Added fix for correct IPA backup file name

[Rob Crittenden]

Abhijeet Kasurde wrote:

Hi Florence,


On 07/07/2016 03:30 PM, Florence Blanc-Renaud wrote:

On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote:

Hi All,

Please review the patch.

Fixes : https://fedorahosted.org/freeipa/ticket/6031

--
Thanks,
Abhijeet Kasurde

IRC: akasurde
http://akasurde.github.io




Hi Abhijeet,

thanks for your patch. I have a comment though: if the filename is
modified in ipa-backup, then it should also be changed in ipa-restore,
to make sure that the backup can be restored. It may be a good idea to
define the file name as a constant and use this constant everywhere.


I will change ipa-restore as well.

As far as I can see, the tool ipa-restore checks that the backup
version and ipa-restore version are consistent, meaning that both
tools should use the same filename and that it will not break backward
compatibility, but other team members can confirm.


I will wait for other team members to comment on this.


ipa-restore will probably need to look for both the ipa-full.tar and 
ipa-full.tar.gz because the version check is optional.


rob

--
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 031] RedHatCAService should wait for local Dogtag instance

[Martin Basti]

On 01.07.2016 13:25, Petr Spacek wrote:

On 1.7.2016 11:43, Petr Spacek wrote:

On 1.7.2016 11:17, Petr Spacek wrote:

On 1.7.2016 11:04, Christian Heimes wrote:

On 2016-07-01 10:59, Petr Spacek wrote:

On 1.7.2016 10:55, Christian Heimes wrote:

On 2016-07-01 10:48, Petr Spacek wrote:

On 1.7.2016 10:42, Christian Heimes wrote:

RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a
HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus
returns OK. The ca_status() function defaults to api.env.ca_host as
host.

On a replica without CA ca_host is a remote host (e.g. master's
FQDN). ipa-ca-install waits for master:8080 instead of replica:8080,
which might be blocked by a firewall.

https://fedorahosted.org/freeipa/ticket/6016

Interesting. How it happens that replica without CA is calling RedHatCAService?

Also, why replica should be waiting for CA if it is not installed?

I'm confused.

There is a hint in the last sentence: ipa-ca-install

The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install
doesn't wait for the local Dogtag to come up but connects to a remote
Dogtag to check if it's up. It uses 8443 or 8080, which might be
blocked. In my test setup I have both ports blocked so ipa-ca-install
never succeeds.

Oh, I missed that, thanks!

Isn't the root cause that ipa.env.ca_host does not get updated during
ipa-ca-install?

Been there, tried it, didn't work:
https://fedorahosted.org/freeipa/ticket/6016#comment:1

I understand that it does not work right now but it does not mean that it is
an actual problem in api.env :-)

Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as
Petr^1 is about to push the RELEASE button any minute now.

Petr^2 Spacek


It just doesn't make sense that RedHatCAService should ever check a
remote instance. The rest of the class is about the local systemd
service. As soon as we have sd_notify
https://fedorahosted.org/pki/ticket/1233 implemented, we can use systemd
to wait for Dogtag.

It seems to work but ipa-client-install blows up on certificate request.

# getcert list
Number of certificates and requests being tracked: 1.
Request ID '20160701093734':
 status: CA_UNREACHABLE
 ca-error: Server at
https://vm-058-082.abc.idm.lab.eng.brq.redhat.com/ipa/xml failed request, will
retry: 903 (RPC failed at server.  an internal error has occurred).
 stuck: no
 key pair storage: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local
IPA host',token='NSS Certificate DB',pinfile='/etc/ipa/nssdb/pwdfile.txt'
 certificate: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA
host'
 CA: IPA
 issuer:
 subject:
 expires: unknown
 pre-save command:
 post-save command:
 track: yes
 auto-renew: yes

error log on the server:

[Fri Jul 01 11:37:34.294677 2016] [wsgi:error] [pid 38273] ipa: INFO:
[jsonserver_kerb]
host/vm-046.abc.idm.lab.eng.brq.redhat@dom-058-082.abc.idm.lab.eng.brq.redhat.com:
host_mod(u'vm-046.abc.idm.lab.eng.brq.redhat.com', ipasshpubkey=(u'ssh-rsa
B3NzaC1yc2EDAQABAAABAQCtrWFHeOF6UxI/DNdlLsUUazTpol2sRqQgbZplpkB9t/HUSjUHq0OY1mwaUfxvJp/E9yDmuHZgUgzKMSAdUf2apwFm5bw3T7qSdJ0Y7hC9vG0v6kLT0EaPuQmfJ8Rt4xOyva9htKbzkxs9Kr0ujB6V4u41ZZW2oevqtGunC2+aCxkQzd42we0c47ypxnvl8gGAa76CDXenGaChPKSfeEMddnhFvjGfkSyqjD+dCxBF+IyTRDPtt6f5iF80lfv/559rsKYlHdbbgv30i5C/F2DzaB011BmcQwK1eWSGWsEWVFtQKNMdahTl2IMgvZwHcaw8TMqgqqgZ7ZZ6lMR+UA8l',
u'ecdsa-sha2-nistp256
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBHkoeGOzfQzqYOGQs2bdgL0jOBul+/eTBZ0HBM8HW3Wb5O15Fv3rt8jRp+xdSQcdG3DV5yPfjd66Fyz5hCTKS6s=',
u'ssh-ed25519
C3NzaC1lZDI1NTE5IH5/uXvdJ1l+uTAk0rgbjKeTBx9HRWk7w+xJLHMt/yRx'),
updatedns=False, version=u'2.26'): SUCCESS
[Fri Jul 01 11:37:37.961175 2016] [wsgi:error] [pid 38272] ipa: ERROR:
non-public: ValueError: User name is defined only for user and enterprise
principals
[Fri Jul 01 11:37:37.961220 2016] [wsgi:error] [pid 38272] Traceback (most
recent call last):
[Fri Jul 01 11:37:37.961224 2016] [wsgi:error] [pid 38272]   File
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in
wsgi_execute
[Fri Jul 01 11:37:37.961226 2016] [wsgi:error] [pid 38272] result =
self.Command[name](*args, **options)
[Fri Jul 01 11:37:37.961229 2016] [wsgi:error] [pid 38272]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__
[Fri Jul 01 11:37:37.961259 2016] [wsgi:error] [pid 38272] return
self.__do_call(*args, **options)
[Fri Jul 01 11:37:37.961262 2016] [wsgi:error] [pid 38272]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in __do_call
[Fri Jul 01 11:37:37.961265 2016] [wsgi:error] [pid 38272] ret =
self.run(*args, **options)
[Fri Jul 01 11:37:37.961267 2016] [wsgi:error] [pid 38272]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run
[Fri Jul 01 11:37:37.961269 2016] [wsgi:error] [pid 38272] return

Re: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals

[Petr Spacek]

On 7.7.2016 13:52, Sumit Bose wrote:
> On Thu, Jul 07, 2016 at 01:31:03PM +0200, Petr Vobornik wrote:
>> On 07/06/2016 07:01 PM, Sumit Bose wrote:
>>> Hi,
>>>
>>> although enterprise principals for trusted domains now are working as
>>> expected they do not work for the local domain:
>>>
>>> # kinit -E admin@IPA.DEVEL
>>> kinit: Client 'admin\@IPA.DEVEL@IPA.DEVEL' not found in Kerberos 
>>> database while getting initial credentials
>>>
>>> Attached patch handles this case. It is not that nice because of the
>>> duplication of ipadb_fetch_principals() and ipadb_find_principal(). But
>>> I think there was a reason I do not remember why we didn't check for
>>> enterprise principals before checking the local database. If there is no
>>> such reason it might make sense to check for enterprise principals
>>> before doing the lookup. Please let me know if I should change the patch
>>> accordingly or if the current version is ok,

I can't see the reason why we should not allow enterprise principals ...

Personally I like rule of thumb 'design is not documented -> change it as you
see fit & document it this time'.

Petr^2 Spacek

>>>
>>> bye,
>>> Sumit
>>>
>>
>> Hi Sumit,
>>
>> thanks for the patch. This patch should have a ticket. It will help
>> downstream planning.
> 
> sure, I created https://fedorahosted.org/freeipa/ticket/6036. Please
> clone it to suitable downstream tickets.
> 
> Please note that we didn't released a patch for SSSD to enable enterprise
> principals automatically if the IPA server (should) support them because
> of this issues. Since 4.4.0 is already released I think we have to wait
> on the SSSD side until a new FreeIPA version with a fix is released.

-- 
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] kdb: check for local realm in enterprise principals

[Sumit Bose]

On Thu, Jul 07, 2016 at 01:31:03PM +0200, Petr Vobornik wrote:
> On 07/06/2016 07:01 PM, Sumit Bose wrote:
> > Hi,
> > 
> > although enterprise principals for trusted domains now are working as
> > expected they do not work for the local domain:
> > 
> > # kinit -E admin@IPA.DEVEL
> > kinit: Client 'admin\@IPA.DEVEL@IPA.DEVEL' not found in Kerberos 
> > database while getting initial credentials
> > 
> > Attached patch handles this case. It is not that nice because of the
> > duplication of ipadb_fetch_principals() and ipadb_find_principal(). But
> > I think there was a reason I do not remember why we didn't check for
> > enterprise principals before checking the local database. If there is no
> > such reason it might make sense to check for enterprise principals
> > before doing the lookup. Please let me know if I should change the patch
> > accordingly or if the current version is ok,
> > 
> > bye,
> > Sumit
> > 
> 
> Hi Sumit,
> 
> thanks for the patch. This patch should have a ticket. It will help
> downstream planning.

sure, I created https://fedorahosted.org/freeipa/ticket/6036. Please
clone it to suitable downstream tickets.

Please note that we didn't released a patch for SSSD to enable enterprise
principals automatically if the IPA server (should) support them because
of this issues. Since 4.4.0 is already released I think we have to wait
on the SSSD side until a new FreeIPA version with a fix is released.

bye,
Sumit

> 
> -- 
> Petr Vobornik

-- 
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] kdb: check for local realm in enterprise principals

[Petr Vobornik]

On 07/06/2016 07:01 PM, Sumit Bose wrote:

Hi,

although enterprise principals for trusted domains now are working as
expected they do not work for the local domain:

# kinit -E admin@IPA.DEVEL
kinit: Client 'admin\@IPA.DEVEL@IPA.DEVEL' not found in Kerberos database 
while getting initial credentials

Attached patch handles this case. It is not that nice because of the
duplication of ipadb_fetch_principals() and ipadb_find_principal(). But
I think there was a reason I do not remember why we didn't check for
enterprise principals before checking the local database. If there is no
such reason it might make sense to check for enterprise principals
before doing the lookup. Please let me know if I should change the patch
accordingly or if the current version is ok,

bye,
Sumit



Hi Sumit,

thanks for the patch. This patch should have a ticket. It will help 
downstream planning.


--
Petr Vobornik

--
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] 0010 Show full error message for selinuxusermap-add-hostgroup

[Petr Vobornik]

On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote:

Hi,

the output of ipa selinuxusermap-add-hostgroup and
selinuxusermap-add-user does not display any more the host/host group or
user/group that could not be added. This patch fixes this regression by
adding the labels host/hostgroup/user/group to the list of
_failed_member_output_params of the class ClientMethod.


https://fedorahosted.org/freeipa/ticket/6026



I've a feeling that this issue is more general and multiple commands 
regressed. Would be good to check other member options, e.g. also in 
user plugin.


--
Petr Vobornik

--
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] Dogtag 10.3.4 in Fedora 24?

[Petr Spacek]

Hello,

IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for
Fedora any time soon?

Or should I update my scripts to automatically enable
COPR @freeipa/freeipa-master
in my testing VMs?

Thanks.
Petr^2 Spacek


> commit 45daffa22fcc6c481a8302f1947a5e0ded0b3eb8
> CommitDate: Tue Jun 28 19:15:35 2016 +0200
> 
> Set default OCSP URI on install and upgrade
> 
> Dogtag has been updated to support a default OCSP URI when the
> profile includes AuthInfoAccess with URI method but does not specify
> the URI (instead of constructing one based on Dogtag's hostname and
> port).
> 
> Add the pkispawn config to ensure that the OCSP URI is set before
> issuing CA and system certificates, and add the config to existing
> CA instances on upgrade.
> 
> Fixes: https://fedorahosted.org/freeipa/ticket/5956
> Reviewed-By: Martin Basti 
> ---
>  freeipa.spec.in | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/freeipa.spec.in b/freeipa.spec.in
> index c86fc31..a4d3c06 100644
> --- a/freeipa.spec.in
> +++ b/freeipa.spec.in
> @@ -94,7 +94,7 @@ BuildRequires:  libunistring-devel
>  BuildRequires:  python-lesscpy
>  BuildRequires:  python-yubico >= 1.2.3
>  BuildRequires:  openssl-devel
> -BuildRequires:  pki-base >= 10.3.3
> +BuildRequires:  pki-base >= 10.3.4

-- 
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] Added fix for correct IPA backup file name

[Abhijeet Kasurde]

Hi Florence,


On 07/07/2016 03:30 PM, Florence Blanc-Renaud wrote:

On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote:

Hi All,

Please review the patch.

Fixes : https://fedorahosted.org/freeipa/ticket/6031

--
Thanks,
Abhijeet Kasurde

IRC: akasurde
http://akasurde.github.io




Hi Abhijeet,

thanks for your patch. I have a comment though: if the filename is 
modified in ipa-backup, then it should also be changed in ipa-restore, 
to make sure that the backup can be restored. It may be a good idea to 
define the file name as a constant and use this constant everywhere.



I will change ipa-restore as well.
As far as I can see, the tool ipa-restore checks that the backup 
version and ipa-restore version are consistent, meaning that both 
tools should use the same filename and that it will not break backward 
compatibility, but other team members can confirm.



I will wait for other team members to comment on this.

Flo.


Thanks for your comments.

--
Thanks,
Abhijeet Kasurde

IRC: akasurde
http://akasurde.github.io

-- 
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] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

[Sebastian Hetze]

Hi *

attached you find a patch that adds new options --subject_cn and
--subject_mail to ipa-server-install that make the CA cert subject CN
customizable.

This patch has been tested by a customer in a PoC.
However, i assume additional testing in different environments is required.

It would be greatly appreciated if this patch would find its way into
the product very soon.

Beste Grüße / Best regards
  Sebastian Hetze
-- 
Senior Solution Architect
Red Hat GmbH. Niederlassung Berlin
Am Treptower Park 75 12435 Berlin
Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205
Fax: +49 30 678 1798-111 . E-Mail: s...@redhat.com

diff -Nur freeipa-4.2.0-15.el7.17/install/share/60ipaconfig.ldif freeipa-4.2.0/install/share/60ipaconfig.ldif
--- freeipa-4.2.0-15.el7.17/install/share/60ipaconfig.ldif	2015-06-18 14:54:49.0 +0200
+++ freeipa-4.2.0/install/share/60ipaconfig.ldif	2016-07-05 17:06:49.433028447 +0200
@@ -43,11 +43,12 @@
 attributeTypes: (2.16.840.1.113730.3.8.3.16 NAME 'ipaConfigString' DESC 'Generic configuration stirng' EQUALITY caseIgnoreMatch ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )
 attributeTypes: ( 2.16.840.1.113730.3.8.3.26 NAME 'ipaSELinuxUserMapDefault' DESC 'Default SELinux user' EQUALITY caseIgnoreMatch ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3')
 attributeTypes: ( 2.16.840.1.113730.3.8.3.27 NAME 'ipaSELinuxUserMapOrder' DESC 'Available SELinux user context ordering' EQUALITY caseIgnoreMatch ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3')
+attributeTypes: ( 2.16.840.1.113730.3.8.3.28 NAME 'ipaCertificateSubjectRdn' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
 ###
 ##
 ## ObjectClasses
 ##
 ## ipaGuiConfig - GUI config parameters objectclass
-objectClasses: ( 2.16.840.1.113730.3.8.2.1 NAME 'ipaGuiConfig' AUXILIARY MAY ( ipaUserSearchFields $ ipaGroupSearchFields $ ipaSearchTimeLimit $ ipaSearchRecordsLimit $ ipaCustomFields $ ipaHomesRootDir $ ipaDefaultLoginShell $ ipaDefaultPrimaryGroup $ ipaMaxUsernameLength $ ipaPwdExpAdvNotify $ ipaUserObjectClasses $ ipaGroupObjectClasses $ ipaDefaultEmailDomain $ ipaMigrationEnabled $ ipaCertificateSubjectBase $ ipaSELinuxUserMapDefault $ ipaSELinuxUserMapOrder $ ipaKrbAuthzData ) )
+objectClasses: ( 2.16.840.1.113730.3.8.2.1 NAME 'ipaGuiConfig' AUXILIARY MAY ( ipaUserSearchFields $ ipaGroupSearchFields $ ipaSearchTimeLimit $ ipaSearchRecordsLimit $ ipaCustomFields $ ipaHomesRootDir $ ipaDefaultLoginShell $ ipaDefaultPrimaryGroup $ ipaMaxUsernameLength $ ipaPwdExpAdvNotify $ ipaUserObjectClasses $ ipaGroupObjectClasses $ ipaDefaultEmailDomain $ ipaMigrationEnabled $ ipaCertificateSubjectBase $ ipaSELinuxUserMapDefault $ ipaSELinuxUserMapOrder $ ipaKrbAuthzData $ ipaCertificateSubjectRdn ) )
 ## ipaConfigObject - Generic config strings object holder
 objectClasses: (2.16.840.1.113730.3.8.4.13 NAME 'ipaConfigObject' DESC 'generic config object for IPA' AUXILIARY MAY ( ipaConfigString ) X-ORIGIN 'IPA v2' )
diff -Nur freeipa-4.2.0-15.el7.17/install/share/certmap.conf.template freeipa-4.2.0/install/share/certmap.conf.template
--- freeipa-4.2.0-15.el7.17/install/share/certmap.conf.template	2015-06-18 14:54:49.0 +0200
+++ freeipa-4.2.0/install/share/certmap.conf.template	2016-07-05 17:06:49.433028447 +0200
@@ -41,6 +41,6 @@
 #default:InitFn 
 default:DNComps
 default:FilterComps uid
-certmap ipaca   CN=Certificate Authority,$SUBJECT_BASE
+certmap ipaca   $SUBJECT_RDN,$SUBJECT_BASE
 ipaca:CmapLdapAttr  seeAlso
 ipaca:verifycerton
diff -Nur freeipa-4.2.0-15.el7.17/ipaserver/install/cainstance.py freeipa-4.2.0/ipaserver/install/cainstance.py
--- freeipa-4.2.0-15.el7.17/ipaserver/install/cainstance.py	2016-05-24 19:37:31.0 +0200
+++ freeipa-4.2.0/ipaserver/install/cainstance.py	2016-07-05 17:06:49.433028447 +0200
@@ -391,7 +391,8 @@
cert_file=None, cert_chain_file=None,
master_replication_port=None,
subject_base=None, ca_signing_algorithm=None,
-   ca_type=None, ra_p12=None):
+   ca_type=None, ra_p12=None,
+   subject_rdn=None):
 """Create a CA instance.
 
For Dogtag 9, this may involve creating the pki-ca instance.
@@ -416,7 +417,11 @@
 if subject_base is None:
 self.subject_base = DN(('O', self.realm))
 else:
-self.subject_base = subject_base
+self.subject_base = DN(subject_base)
+if subject_rdn is None:
+self.subject_rdn = DN(('CN', 'Certificate Authority'))
+else:
+self.subject_rdn = subject_rdn
 if ca_signing_algorithm is None:
 self.ca_signing_algorithm 

Re: [Freeipa-devel] [PATCH 0017] Added fix for correct IPA backup file name

[Florence Blanc-Renaud]

On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote:

Hi All,

Please review the patch.

Fixes : https://fedorahosted.org/freeipa/ticket/6031

--
Thanks,
Abhijeet Kasurde

IRC: akasurde
http://akasurde.github.io




Hi Abhijeet,

thanks for your patch. I have a comment though: if the filename is 
modified in ipa-backup, then it should also be changed in ipa-restore, 
to make sure that the backup can be restored. It may be a good idea to 
define the file name as a constant and use this constant everywhere.


As far as I can see, the tool ipa-restore checks that the backup version 
and ipa-restore version are consistent, meaning that both tools should 
use the same filename and that it will not break backward compatibility, 
but other team members can confirm.


Flo.

--
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] [Testplan] Support of UPN for trusted domains

[Sumit Bose]

On Fri, May 27, 2016 at 11:24:24AM +0300, Alexander Bokovoy wrote:
> On Fri, 27 May 2016, Sumit Bose wrote:
> > On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote:
> > > Hi all,
> > > 
> > > 
> > > here [1] is a draft of test plan for V4 RFE Support of UPN for trusted
> > > domains.
> > > 
> > > Please review this and let me know if there's something missing or wrong.
> > 
> > Hi Lenka,
> > 
> > thank you for the test plan.
> > 
> > About the TBD, Alexander and I agreed to store the alternative domain
> > suffixes read from AD in a new attribute in the LDAP object of the
> > forest root of the trusted domain.
> > 
> > About the kinit tests. Please note that it is expected that the -E
> > option of kinit must be used when alternative suffixes are used.
> > 
> > I'm not sure if SSSD tests are in the scope here as well. If they are I
> > would suggest to add authentication tests with SSSD where e.g. the name
> > with an alternative domain suffix is used as login name. This in general
> > already works with SSSD but is disabled by default for IPA because of
> > the missing server-side support so far. Since SSSD must be able to work
> > with old and new IPA server https://fedorahosted.org/sssd/ticket/3018
> > was created so that SSSD can detect at runtime if the server supports
> > this or not.
> Right, I think we should make sure SSSD is tested against IPA UPN
> support because otherwise we might get regressions.

Hi Lenka,

I would like to ask you to add test where 'kinit -E' is used with an IPA
user as well to avoid regression, because currently 'kinit -E
ipauser@IPA.DOMAIN' does not work. 

Please note that the full principal must be used with kinit in this case
because when just using

kinit -E ipauser

kinit is smart enough to see that it makes no sense to add the
default_realm twice and internally just does 'kinit ipauser@IPA.DOMAIN'.

If you think this test is better suited in a different test plan please
let me know, then I'll ask there.

bye,
Sumit

> 
> 
> -- 
> / Alexander Bokovoy

-- 
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 0017] Added fix for correct IPA backup file name

[Abhijeet Kasurde]

Hi All,

Please review the patch.

Fixes : https://fedorahosted.org/freeipa/ticket/6031

--
Thanks,
Abhijeet Kasurde

IRC: akasurde
http://akasurde.github.io

From 5cbf144f0157146ef73185b029259f7cdeffb5b9 Mon Sep 17 00:00:00 2001
From: Abhijeet Kasurde 
Date: Thu, 7 Jul 2016 14:22:50 +0530
Subject: [PATCH] Added fix for correct IPA backup file name

Fixes: https://fedorahosted.org/freeipa/ticket/6031

Signed-off-by: Abhijeet Kasurde 
---
 ipaserver/install/ipa_backup.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py
index 18a60ecd13c7e7f5381b61ec70ea308a1931b7ec..75c5462ac9a2aa3459382b85e9a97e12de8a4257 100644
--- a/ipaserver/install/ipa_backup.py
+++ b/ipaserver/install/ipa_backup.py
@@ -289,7 +289,7 @@ class Backup(admintool.AdminTool):
 self.log.info('Stopping Directory Server')
 dirsrv.stop(capture_output=False)
 else:
-self.log.info('Stopping IPA services')
+self.log.info('Stopping IPA service')
 run(['ipactl', 'stop'])
 
 instance = installutils.realm_to_serverid(api.env.realm)
@@ -578,10 +578,10 @@ class Backup(admintool.AdminTool):
 
 if data_only:
 backup_dir = os.path.join(paths.IPA_BACKUP_DIR, time.strftime('ipa-data-%Y-%m-%d-%H-%M-%S'))
-filename = os.path.join(backup_dir, "ipa-data.tar")
+filename = os.path.join(backup_dir, "ipa-data.tar.gz")
 else:
 backup_dir = os.path.join(paths.IPA_BACKUP_DIR, time.strftime('ipa-full-%Y-%m-%d-%H-%M-%S'))
-filename = os.path.join(backup_dir, "ipa-full.tar")
+filename = os.path.join(backup_dir, "ipa-full.tar.gz")
 
 os.mkdir(backup_dir)
 os.chmod(backup_dir, 0o700)
-- 
2.4.11

-- 
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-0053] Forced-client-reenrollment test fixed.

[Oleg Fayans]

Updated version of the patch is attached with the failing tests marked 
as xfailed (let's make the jenkins green).


On 07/04/2016 10:50 PM, Oleg Fayans wrote:

2 out of 7 tests currently fail due to a known issue [1], others pass.

[1] https://fedorahosted.org/freeipa/ticket/6029






--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From 7234a38fb99220ad9629c8fc84c40c23d8d5a263 Mon Sep 17 00:00:00 2001
From: Oleg Fayans 
Date: Thu, 7 Jul 2016 08:07:38 +0200
Subject: [PATCH] Updated forced_client_reenrollment test

With current implementation the client host record stays in master's
ldap after client uninstallation in a common way so there is no need to dance
around with turning iptables on and off.
Also, in some environments neither A nor SSHFP records don't get created for
the client, it is more robust to check for host sshfp using host-find command
---
 .../test_forced_client_reenrollment.py | 100 +++--
 1 file changed, 32 insertions(+), 68 deletions(-)

diff --git a/ipatests/test_integration/test_forced_client_reenrollment.py b/ipatests/test_integration/test_forced_client_reenrollment.py
index d430a98e74450f44eac286ac0ad35a5aee7cc602..b4b2e987b56b821533d4273ce804f7dfd184ea38 100644
--- a/ipatests/test_integration/test_forced_client_reenrollment.py
+++ b/ipatests/test_integration/test_forced_client_reenrollment.py
@@ -17,6 +17,7 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 import os
+import re
 import subprocess
 from ipaplatform.paths import paths
 import pytest
@@ -50,46 +51,52 @@ class TestForcedClientReenrollment(IntegrationTest):
 Client re-enrollment using admin credentials (--force-join)
 """
 sshfp_record_pre = self.get_sshfp_record()
-self.restore_client()
-self.check_client_host_entry()
+self.uninstall_client()
+self.check_client_host_entry(enabled=False)
 self.reenroll_client(force_join=True)
 sshfp_record_post = self.get_sshfp_record()
 assert sshfp_record_pre == sshfp_record_post
 
+@pytest.mark.xfail(strict=True,
+   reason='https://fedorahosted.org/freeipa/ticket/6029')
 def test_reenroll_with_keytab(self, client):
 """
 Client re-enrollment using keytab
 """
 self.backup_keytab()
 sshfp_record_pre = self.get_sshfp_record()
-self.restore_client()
-self.check_client_host_entry()
+self.uninstall_client()
+self.check_client_host_entry(enabled=False)
 self.restore_keytab()
 self.reenroll_client(keytab=self.BACKUP_KEYTAB)
 sshfp_record_post = self.get_sshfp_record()
 assert sshfp_record_pre == sshfp_record_post
 
+@pytest.mark.xfail(strict=True,
+   reason='https://fedorahosted.org/freeipa/ticket/6029')
 def test_reenroll_with_both_force_join_and_keytab(self, client):
 """
 Client re-enrollment using both --force-join and --keytab options
 """
 self.backup_keytab()
 sshfp_record_pre = self.get_sshfp_record()
-self.restore_client()
-self.check_client_host_entry()
+self.uninstall_client()
+self.check_client_host_entry(enabled=False)
 self.restore_keytab()
 self.reenroll_client(force_join=True, keytab=self.BACKUP_KEYTAB)
 sshfp_record_post = self.get_sshfp_record()
 assert sshfp_record_pre == sshfp_record_post
 
+@pytest.mark.xfail(strict=True,
+   reason='https://fedorahosted.org/freeipa/ticket/6029')
 def test_reenroll_to_replica(self, client):
 """
 Client re-enrollment using keytab, to a replica
 """
 self.backup_keytab()
 sshfp_record_pre = self.get_sshfp_record()
-self.restore_client()
-self.check_client_host_entry()
+self.uninstall_client()
+self.check_client_host_entry(enabled=False)
 self.restore_keytab()
 self.reenroll_client(keytab=self.BACKUP_KEYTAB, to_replica=True)
 sshfp_record_post = self.get_sshfp_record()
@@ -101,7 +108,7 @@ class TestForcedClientReenrollment(IntegrationTest):
 """
 self.backup_keytab()
 self.disable_client_host_entry()
-self.restore_client()
+self.uninstall_client()
 self.check_client_host_entry(enabled=False)
 self.restore_keytab()
 self.reenroll_client(keytab=self.BACKUP_KEYTAB, expect_fail=True)
@@ -112,7 +119,6 @@ class TestForcedClientReenrollment(IntegrationTest):
 """
 self.backup_keytab()
 self.uninstall_client()
-self.restore_client()
 self.check_client_host_entry(enabled=False)
 self.restore_keytab()
 self.reenroll_client(keytab=self.BACKUP_KEYTAB, expect_fail=True)
@@ -123,7 +129,7 @@ class