Re: [Freeipa-devel] [Testplan Review]

[Oleg Fayans]

Hi Petr,

The test plan is updated.

On 05/19/2016 12:54 PM, Petr Vobornik wrote:
> On 05/19/2016 12:38 PM, Oleg Fayans wrote:
>> Hi all,
>>
>> I've created the first versio of the testplan for Topology Management
>> feature in 4.4 release:
>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan
>>
>> Could someone please review it?
>>
> 
> I'll mention what are the important parts.
> 
> 1. In the 3 scenarios, the most important one is testing the
> `ipa-server-install --uninstall`. There it is more important to check
> whether it did the same as `ipa-csreplica-manage del`,
> `ipa-replica-manage del` and `ipa-server-install --uninstall` procedure.
> Which means removal of master entry, DNS records, Kerberos keys,
> revocation of certificates... Checking RUVs is not the critical part.
> 
> 2. I miss test for move of `ipa-replica-manage set-renewal-master` to API

Isn't it more related to the server roles feature? Will it be one of the
ipa server* commands?

> 
> 3. test of new `ipa server-del` method
> 
> when these three are done then I'd focus on RUVs
> 

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

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

Re: [Freeipa-devel] V4/Sub-CAs review

[Jan Cholasta]

On 17.5.2016 14:50, Fraser Tweedale wrote:

On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:

On 10.5.2016 12:36, Fraser Tweedale wrote:

Honza, thanks for the review.  Comments inline.

Copy Nalin, re certmonger discussion at the very bottom.

On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:

Hi,



8<--


2) 

It should be mentioned here that the primary CA is also handled by this
plugin.

I would like to propose two additional fields:

  * subject (required) - subject name of the CA, to be able to look up
sub-CA that issued a certificate from its issuer name.

  * issuer_ca (optional) - name of the sub-CA which issued certificate for
this CA, to have information about the sub-CA hierarchy. If there is no
sub-CA entry for the issuer, it would be unset.


These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?


As for subject, we are adding the ability to look up information about
arbitrary certificates to cert-{show,find} as part of
. Part of this information
should be whether the certificate was issued by our CA and what CA it was,
so that the web UI can present an appropriate "revoke certificate" button
for the certificate.

As for issuer CA, I believe we need it to fix automatic CA certificate
renewal. The current renewal code uses virtual "profiles" to handle CA
certificate renewal, but that turned out to be an issue, especially with
externally signed CA certificates:
. Instead it could use
the issuer CA information from LDAP to figure out what needs to be done.
(Note that during the renewal, Dogtag is offline.)

Also, both the attributes should be included for compatibility with external
CAs. At this point, I think it's only a matter of time when support for them
will be added (there were already several requests for such a feature), and
I would very much prefer to have to maintain only a single code path for the
generic stuff (which includes both of the attributes), instead of one for
Dogtag and one for external CAs.


OK, I'll add issuer DN and subject DN attributes to the ipaCa
objectClass.


Just to be clear, what I meant is for the issuer attribute to contain 
the DN of the CA entry in LDAP, not the issuer DN itself.










8<--


4) 

"""
For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
implements the KeyRetriever interface. It invokes a Python script that
performs the retrieval, reusing existing FreeIPA Custodia client code.
"""

Will this be distributed with Dogtag or with IPA?


It's shipped in Dogtag.


The Python script bit sounds like an implementation detail rather than an
actual design. Ideally the whole thing would be done in Java, right?


I removed the script from the design page (it had changed, though
not dramatically).  It is written in Python so that we can reuse the
CustodiaClient.


I figured as much. My point is that whether you are executing an external
binary or using native code is an implementation detail, so it should not be
in the "Design" section, but rather the "Implementation" section.


Fair point; I'll move what remains the Implementation section.




"""
The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
and shall be executed as pkiuser.
"""

Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
going to be distributed with IPA).


What is the rationale - is it a packaging guideline or just common
sense?


I'm not sure if it's an actual guideline, but IMHO it's definitely common
sense - I don't think littering the global namespace (i.e. /usr/libexec) is
ever preferable to keeping your stuff in your own namespace.


I'll drop the script in a subdir.  While I'm at it, I think I will
move it to the IPA codebase, to improve locality of the Python code.
e.g. if CustodiaClient API or any other IPA Python API changes, the
code in pki repo will be too easily missed.


OK, makes sense.






"""
pkiuser does not have read access to either of these locations, so a new
service principal shall be created for each Dogtag CA instance for the
purpose of authenticating to Custodia and retrieving lightweight CA private
keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its
keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and
mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and
/etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.
"""

Don't forget to update this paragraph with the new principal name.


Thanks, I updated it.



5) 

"""
A CA obj

[Freeipa-devel] FreeIPA.org mediawiki upgraded to 1.26.3

[Martin Kosek]

Hi all,

As there was a security release of Mediawiki software and FreeIPA.org run an
obsoleted version of Mediawiki (1.24), I had to upgrade it to the latest and
greatest version - 1.26.3.

The upgrade is now live:
http://www.freeipa.org/page/Special:Version

If you have any issue with the wiki, please let me know.

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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 0099] ipa-nis-manage: add status option

[Petr Spacek]

On 20.5.2016 15:03, Martin Babinsky wrote:
> On 04/28/2016 05:15 PM, Petr Spacek wrote:
>> On 28.4.2016 14:52, Abhijeet Kasurde wrote:
>>> Hi Petr,
>>>
>>> On 04/25/2016 08:28 PM, Petr Spacek wrote:
 Hello,

 ipa-nis-manage: add status option

 https://bugzilla.redhat.com/show_bug.cgi?id=1329275



>>> Can you reword the error message here as well ?
>>>
>>>  if len(args) != 1:
>>>  sys.exit("You must specify one action, either enable or disable")
>>>
>>> Thanks,
>>> Abhijeet Kasurde
>>
>> Good catch!
>>
>>
>>
> 
> Hi Petr,
> 
> please use upstream ticket provided by Petr Vobornik[1] in the commit message.
> 
> Also I would rewrite
> 
> """+elif args[0] != "enable" and args[0] != "disable" and args[0] !=
> "status":
> 
> """
> 
> in a more pythonic way:
> 
> "elif args[0] not in {"enable", "disable", "status"}:"
> 
> Otherwise the patch works as expected.
> 
> [1] https://fedorahosted.org/freeipa/ticket/5856

Here you go.

-- 
Petr^2 Spacek
From e966d141724127720e3b036027f91e8438e88f45 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 25 Apr 2016 16:56:08 +0200
Subject: [PATCH] ipa-nis-manage: add status option

https://fedorahosted.org/freeipa/ticket/5856
---
 install/tools/ipa-nis-manage   | 22 ++
 install/tools/man/ipa-nis-manage.1 |  8 ++--
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/install/tools/ipa-nis-manage b/install/tools/ipa-nis-manage
index 948aa0046b6eeb0f68dd90390eaca6d5b6c8dba3..f70961309c34e48ea1b4c1b144c9c0df5860f667 100755
--- a/install/tools/ipa-nis-manage
+++ b/install/tools/ipa-nis-manage
@@ -47,7 +47,7 @@ nis_config_dn = DN(('cn', 'NIS Server'), ('cn', 'plugins'), ('cn', 'config'))
 compat_dn = DN(('cn', 'Schema Compatibility'), ('cn', 'plugins'), ('cn', 'config'))
 
 def parse_options():
-usage = "%prog [options] \n"
+usage = "%prog [options] \n"
 usage += "%prog [options]\n"
 parser = OptionParser(usage=usage, formatter=config.IPAFormatter())
 
@@ -96,8 +96,8 @@ def main():
 options, args = parse_options()
 
 if len(args) != 1:
-sys.exit("You must specify one action, either enable or disable")
-elif args[0] != "enable" and args[0] != "disable":
+sys.exit("You must specify one action: enable | disable | status")
+elif args[0] not in {"enable", "disable", "status"}:
 sys.exit("Unrecognized action [" + args[0] + "]")
 
 standard_logging_setup(None, debug=options.debug)
@@ -186,11 +186,25 @@ def main():
 print(lde)
 retval = 1
 
+elif args[0] == "status":
+nis_entry = get_entry(nis_config_dn, conn)
+enabled = (nis_entry and
+   nis_entry.get(
+   'nsslapd-pluginenabled', '')[0].lower() == "on")
+if enabled:
+print("Plugin is enabled")
+retval = 0
+else:
+print("Plugin is not enabled")
+retval = 4
+
 else:
 retval = 1
 
 if retval == 0:
-print("This setting will not take effect until you restart Directory Server.")
+if args[0] in {"enable", "disable"}:
+print("This setting will not take effect until you restart "
+  "Directory Server.")
 
 if args[0] == "enable":
 print("The %s service may need to be started." % servicemsg)
diff --git a/install/tools/man/ipa-nis-manage.1 b/install/tools/man/ipa-nis-manage.1
index d60fda788fb7b97d6fa97544f63f346eb13e956a..93278487c1adb50f4ae49804d0214841e2bef30c 100644
--- a/install/tools/man/ipa-nis-manage.1
+++ b/install/tools/man/ipa-nis-manage.1
@@ -20,13 +20,15 @@
 .SH "NAME"
 ipa\-nis\-manage \- Enables or disables the NIS listener plugin
 .SH "SYNOPSIS"
-ipa\-nis\-manage [options] 
+ipa\-nis\-manage [options] 
 .SH "DESCRIPTION"
 Run the command with the \fBenable\fR option to enable the NIS plugin.
 
 Run the command with the \fBdisable\fR option to disable the NIS plugin.
 
-In both cases the user will be prompted to provide the Directory Manager's password unless option \fB\-y\fR is used.
+Run the command with the \fBstatus\fR option to read status of the NIS plugin. Return code 0 indicates enabled plugin, return code 4 indicates disabled plugin.
+
+In all cases the user will be prompted to provide the Directory Manager's password unless option \fB\-y\fR is used.
 
 Directory Server will need to be restarted after the NIS listener plugin has been enabled.
 
@@ -45,3 +47,5 @@ File containing the Directory Manager password
 2 if the plugin is already in the required status (enabled or disabled)
 
 3 if RPC services cannot be enabled.
+
+4 if status command detected plugin in disabled state.
-- 
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/

Re: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Petr Spacek]

On 20.5.2016 12:43, Alexander Bokovoy wrote:
> On Fri, 20 May 2016, Petr Spacek wrote:
>> Theory I have seen looks good to me but Security considerations section is
>> missing. The design must spell out what are security implications of
>>  ignore_acceptor_hostname = true
>>  GSSAPIStrictAcceptorCheck no
> I'll add security considerations, thanks for noticing that.
> 
>> All of the implementation details are missing so this review cannot be
>> considered complete.
> There is nothing to implement here on our side. We discussed it with
> Martin K. and he suggested that we might add a link to documentation
> when it would be written but that's as much as we can do.
> 
> Thing is, a proper implementation means changes to be done way above
> ipa-client-install level, even way above FreeIPA deployment itself,
> especially for SSO case where a CNAME would need to be created in a
> separate DNS zone that is not under control of FreeIPA. So all we can do
> is to suggest something rather than implement. We do that already and
> Mark is going to turn the design into a section in the Windows
> Integration Guide.

Let me clarify that. I did not mean that ipa-client-install should *create*
CNAME records. I was thinking more about tailored installation process which
can be automatically enabled when CNAME is detected during installation.


>> I'm very interested in implementation details & usability of it. Can we make
>> this setup easier to achieve by changing ipa-client-install?
>>
>> Some ideas:
>> - populate krb.conf only with
>> [domain_realm]
>> canonical hostname = IPA.EXAMPLE.COM
>>
>> and enable DNS auto-detection for everything else.
> We already have auto-detection working. For non-SSO case
> 'ipa-client-install --domain=ipa.example.com' on ipa-client.example.com
> will automatically configure everything. The only change is indeed by
> setting 'ipa-client.example.com = IPA.EXAMPLE.COM'. For SSO case we
> simply discover that AD DC is not IPA LDAP server so we refuse to
> operate unless you provide manual options.

Sorry for not being clear. I did not mean auto-detection of domain, this
surely needs to be handled by --domain option.

I was thinking about detection of CNAME which could trigger addition of
ipa-client.example.com = IPA.EXAMPLE.COM
to krb5.conf.

Or, alternatively, why can't we add ipa-client.example.com = IPA.EXAMPLE.COM
to krb5.conf unconditionally? I do not see any harm in doing so.


> However, it is impossible to
> do anything here automatically because the actual behavior would depend
> on external conditions which we cannot control.
> 
> This is really something that has to be written in the planning guide.
> For example, if you have SSO case and want to put A/ record and
> CNAME record, it is not a given fact that both of them have to be named
> in the same way. In fact, they most likely will be different as CNAME
> record is part of user-facing application namespace and A/ records
> in IPA DNS zone are part of a backend naming. There is no
> standardization here.

Sure. I was thinking about special handling for case where ipa-client-install
is ran with parameters "--domain=ipa --hostname=cname". It could modify
krb5.conf and possibly print hint about ignore_acceptor_hostname or just a
link to docs "it seems that you should read ".


>> I think that:
>> a) For normal setups with disjoint domains this should just work as usual.
>>
>> b) For setup without CNAME for IPA client it should work because example.com
>> will be detected as AD domain and scenario described in the section 'No 
>> single
>> sign-on required' will work.
>>
>> c) For setup with CNAME the user will need to add ignore_acceptor_hostname 
>> but
>> krb5.conf will be configured properly.
>>
>>
>>
>> BTW why is it needed to use ignore_acceptor_hostname if there is a CNAME? MIT
>> Kerberos should see the correct name as it detects CNAMEs. Does AD ignore the
>> CNAME when requesting a ticket? What else?
> No, it does not ignore, it resolves CNAME to A/ name. However, there
> are cases when people want to have both principals from IPA and AD
> realms in /etc/krb5.keytab and want to support both ways to access it.
> 
>> If it is needed, can we detect the CNAME and turn on ignore_acceptor_hostname
>> automatically? (This depends on security considerations section, of course.)
> Exactly because it is part of the behavior defined by application
> frontend considerations, we can only document it and not do automated
> handling.

Okay, understood.


>> Speaking of certs, should we introduce a aliases for host entries to avoid 
>> the
>> need of fake hosts?
> These 'fake hosts' are as good as aliases, even better, because they
> allow us to have full control over who can manage them.

I do not see how this is different from any other object which has managedBy
attribute. It is not a special property of host.

-- 
Petr^2 Spacek

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

[Freeipa-devel] Questions on git

[Florence Blanc-Renaud]

Hi all,

as I am ramping up with git, I have a few questions. Let's imagine the 
following development workflow:


- I start working on a specific issue and decide to create a branch on 
my git repository (on my laptop)

git clone git://git.fedorahosted.org/git/freeipa.git
git branch -b issue
- When my code looks ok, I decide to commit on the branch (still on my 
ldaptop)

git add 
git commit

- Now I would like to push this on my development VM (I already cloned 
the repos on the VM). What would be the right command to push only the 
branch "issue" to my VM repo? Does the following command push only the 
current branch?

git push --repo=ssh://frenaud@:/path/to/src/freeipa

- When the tests are ok and I want to submit a patch, can I stay on the 
branch "issue" to create the patch or should I merge first with the main 
branch? If a merge is required, is it recommended to pull then merge or 
merge then pull?


Thanks for your tips,
Flo.

--
Florence Blanc-Renaud
Identity Management Team, Red Hat

-- 
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] Questions on git

[Martin Basti]

On 23.05.2016 16:24, Florence Blanc-Renaud wrote:

Hi all,

as I am ramping up with git, I have a few questions. Let's imagine the 
following development workflow:


- I start working on a specific issue and decide to create a branch on 
my git repository (on my laptop)

git clone git://git.fedorahosted.org/git/freeipa.git
git branch -b issue
- When my code looks ok, I decide to commit on the branch (still on my 
ldaptop)

git add 
git commit


I found handy also 'git add -p' which allows you to choose what commit



- Now I would like to push this on my development VM (I already cloned 
the repos on the VM). What would be the right command to push only the 
branch "issue" to my VM repo? Does the following command push only the 
current branch?

git push --repo=ssh://frenaud@:/path/to/src/freeipa


Could work, I usually just rsync the whole folder to VM


- When the tests are ok and I want to submit a patch, can I stay on 
the branch "issue" to create the patch or should I merge first with 
the main branch? If a merge is required, is it recommended to pull 
then merge or merge then pull?


You can stay on your issue branch, but patch should be rebased to 
current master (patch should apply on top of master)


something like:

git checkout master
git pull
git check issue
git rebase master issue

or interactive rebase if you want change order of patches or something
git rebase -i master issue


Thanks for your tips,
Flo.
--
Florence Blanc-Renaud
Identity Management Team, Red Hat




Martin^2
-- 
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] Questions on git

[Jakub Hrozek]

On Mon, May 23, 2016 at 04:33:29PM +0200, Martin Basti wrote:
> 
> 
> On 23.05.2016 16:24, Florence Blanc-Renaud wrote:
> > Hi all,
> > 
> > as I am ramping up with git, I have a few questions. Let's imagine the
> > following development workflow:
> > 
> > - I start working on a specific issue and decide to create a branch on
> > my git repository (on my laptop)
> > git clone git://git.fedorahosted.org/git/freeipa.git
> > git branch -b issue
> > - When my code looks ok, I decide to commit on the branch (still on my
> > ldaptop)
> > git add 
> > git commit
> 
> I found handy also 'git add -p' which allows you to choose what commit

...or git add -e

> 
> > 
> > - Now I would like to push this on my development VM (I already cloned
> > the repos on the VM). What would be the right command to push only the
> > branch "issue" to my VM repo? Does the following command push only the
> > current branch?
> > git push --repo=ssh://frenaud@:/path/to/src/freeipa
> 
> Could work, I usually just rsync the whole folder to VM

For local VMs, I use an NFS share so that I don't rsync anything, but
the sources magically appear in the VMs (vagrant's shared folders make
this easy once you're past the initial setup pain).

> > 
> > - When the tests are ok and I want to submit a patch, can I stay on the
> > branch "issue" to create the patch or should I merge first with the main
> > branch? If a merge is required, is it recommended to pull then merge or
> > merge then pull?
> 
> You can stay on your issue branch, but patch should be rebased to current
> master (patch should apply on top of master)
> 
> something like:
> 
> git checkout master
> git pull
> git check issue
> git rebase master issue
> 
> or interactive rebase if you want change order of patches or something
> git rebase -i master issue

IMO creating the branch with "--track origin/master" helps..

btw I find this man page helpful:
https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html
as well as this free book:
https://git-scm.com/book/en/v2

-- 
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 0099] ipa-nis-manage: add status option

[Martin Babinsky]

On 05/23/2016 01:55 PM, Petr Spacek wrote:

On 20.5.2016 15:03, Martin Babinsky wrote:

On 04/28/2016 05:15 PM, Petr Spacek wrote:

On 28.4.2016 14:52, Abhijeet Kasurde wrote:

Hi Petr,

On 04/25/2016 08:28 PM, Petr Spacek wrote:

Hello,

ipa-nis-manage: add status option

https://bugzilla.redhat.com/show_bug.cgi?id=1329275




Can you reword the error message here as well ?

 if len(args) != 1:
 sys.exit("You must specify one action, either enable or disable")

Thanks,
Abhijeet Kasurde


Good catch!





Hi Petr,

please use upstream ticket provided by Petr Vobornik[1] in the commit message.

Also I would rewrite

"""+elif args[0] != "enable" and args[0] != "disable" and args[0] !=
"status":

"""

in a more pythonic way:

"elif args[0] not in {"enable", "disable", "status"}:"

Otherwise the patch works as expected.

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


Here you go.



Thanks, ACK.

--
Martin^3 Babinsky

--
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 557] replica install: do not set CA renewal master flag

[Jan Cholasta]

Hi,

the attached patch fixes .

Honza

--
Jan Cholasta
From 6daef1e8e7fa55fd2be3a3ab1fff32ff10b88298 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 23 May 2016 16:18:02 +0200
Subject: [PATCH] replica install: do not set CA renewal master flag

The CA renewal master flag was uncoditionally set on every replica during
replica install. This causes the Dogtag certificates initially shared
among all replicas to differ after renewal.

Do not set the CA renewal master flag in replica install anymore. On
upgrade, remove the flag from all but one IPA masters.

https://fedorahosted.org/freeipa/ticket/5902
---
 ipaserver/install/ca.py|  6 +-
 ipaserver/install/cainstance.py|  2 +-
 ipaserver/install/plugins/ca_renewal_master.py | 24 ++--
 3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py
index acc5433..3a827ae 100644
--- a/ipaserver/install/ca.py
+++ b/ipaserver/install/ca.py
@@ -188,7 +188,11 @@ def install_step_1(standalone, replica_config, options):
 ca.stop('pki-tomcat')
 
 # We need to ldap_enable the CA now that DS is up and running
-ca.ldap_enable('CA', host_name, dm_password, basedn, ['caRenewalMaster'])
+if replica_config is None:
+config = ['caRenewalMaster']
+else:
+config = []
+ca.ldap_enable('CA', host_name, dm_password, basedn, config)
 
 # This is done within stopped_service context, which restarts CA
 ca.enable_client_auth_to_db(paths.CA_CS_CFG_PATH)
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index 337a077..475e74d 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -1288,7 +1288,7 @@ class CAInstance(DogtagInstance):
 
 def __enable_instance(self):
 basedn = ipautil.realm_to_suffix(self.realm)
-self.ldap_enable('CA', self.fqdn, None, basedn, ['caRenewalMaster'])
+self.ldap_enable('CA', self.fqdn, None, basedn)
 
 def configure_replica(self, master_host, subject_base=None,
   ca_cert_bundle=None, ca_signing_algorithm=None,
diff --git a/ipaserver/install/plugins/ca_renewal_master.py b/ipaserver/install/plugins/ca_renewal_master.py
index e83cf3b..a92caf9 100644
--- a/ipaserver/install/plugins/ca_renewal_master.py
+++ b/ipaserver/install/plugins/ca_renewal_master.py
@@ -42,6 +42,7 @@ class update_ca_renewal_master(Updater):
 ldap = self.api.Backend.ldap2
 base_dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'),
  self.api.env.basedn)
+dn = DN(('cn', 'CA'), ('cn', self.api.env.host), base_dn)
 filter = '(&(cn=CA)(ipaConfigString=caRenewalMaster))'
 try:
 entries = ldap.get_entries(base_dn=base_dn, filter=filter,
@@ -50,7 +51,27 @@ class update_ca_renewal_master(Updater):
 pass
 else:
 self.debug("found CA renewal master %s", entries[0].dn[1].value)
-return False, []
+
+master = False
+updates = []
+
+for entry in entries:
+if entry.dn == dn:
+master = True
+continue
+
+updates.append({
+'dn': entry.dn,
+'updates': [
+dict(action='remove', attr='ipaConfigString',
+ value='caRenewalMaster')
+],
+})
+
+if master:
+return False, updates
+else:
+return False, []
 
 criteria = {
 'cert-database': paths.HTTPD_ALIAS_DIR,
@@ -95,7 +116,6 @@ class update_ca_renewal_master(Updater):
 "assuming local CA is renewal slave", config)
 return (False, False, [])
 
-dn = DN(('cn', 'CA'), ('cn', self.api.env.host), base_dn)
 update = {
 'dn': dn,
 'updates': [
-- 
2.5.5

From 242e85bb040dcf1d4c0f979421ea7b37716aa81a Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 23 May 2016 16:18:02 +0200
Subject: [PATCH] replica install: do not set CA renewal master flag

The CA renewal master flag was uncoditionally set on every replica during
replica install. This causes the Dogtag certificates initially shared
among all replicas to differ after renewal.

Do not set the CA renewal master flag in replica install anymore. On
upgrade, remove the flag from all but one IPA masters.

https://fedorahosted.org/freeipa/ticket/5902
---
 ipaserver/install/ca.py|  6 +-
 ipaserver/install/plugins/ca_renewal_master.py | 24 ++--
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py
index d2fb5fe..1fc0b7a 100644
--- a/ipaserver/install/ca.py
+++ b/ipaserver/install/ca.py
@@ -

Re: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Alexander Bokovoy]

On Mon, 23 May 2016, Petr Spacek wrote:

On 20.5.2016 12:43, Alexander Bokovoy wrote:

On Fri, 20 May 2016, Petr Spacek wrote:

Theory I have seen looks good to me but Security considerations section is
missing. The design must spell out what are security implications of
 ignore_acceptor_hostname = true
 GSSAPIStrictAcceptorCheck no

I'll add security considerations, thanks for noticing that.


All of the implementation details are missing so this review cannot be
considered complete.

There is nothing to implement here on our side. We discussed it with
Martin K. and he suggested that we might add a link to documentation
when it would be written but that's as much as we can do.

Thing is, a proper implementation means changes to be done way above
ipa-client-install level, even way above FreeIPA deployment itself,
especially for SSO case where a CNAME would need to be created in a
separate DNS zone that is not under control of FreeIPA. So all we can do
is to suggest something rather than implement. We do that already and
Mark is going to turn the design into a section in the Windows
Integration Guide.


Let me clarify that. I did not mean that ipa-client-install should *create*
CNAME records. I was thinking more about tailored installation process which
can be automatically enabled when CNAME is detected during installation.

If CNAME is detected, we can do some magic, right. But would it help?
Two things matter here:
- if `hostname` is a CNAME, we need to register real hostname
- also create host object for CNAME record and make sure realm hostname
  is used to manage it

Question is what to do if hostname was forced via command line option
and it is different from the CNAME which is `hostname`. In current code
we ignore `hostname` and force the hostname via /etc/hosts to whatever
was specified on the command line.



I was thinking about detection of CNAME which could trigger addition of
ipa-client.example.com = IPA.EXAMPLE.COM
to krb5.conf.

Or, alternatively, why can't we add ipa-client.example.com = IPA.EXAMPLE.COM
to krb5.conf unconditionally? I do not see any harm in doing so.

That sounds better. May be you can file a ticket for this one? It
doesn't need to be tied to the discussed proposal although you can
certainly mention it.



However, it is impossible to
do anything here automatically because the actual behavior would depend
on external conditions which we cannot control.

This is really something that has to be written in the planning guide.
For example, if you have SSO case and want to put A/ record and
CNAME record, it is not a given fact that both of them have to be named
in the same way. In fact, they most likely will be different as CNAME
record is part of user-facing application namespace and A/ records
in IPA DNS zone are part of a backend naming. There is no
standardization here.


Sure. I was thinking about special handling for case where ipa-client-install
is ran with parameters "--domain=ipa --hostname=cname". It could modify
krb5.conf and possibly print hint about ignore_acceptor_hostname or just a
link to docs "it seems that you should read ".

Well, we don't have the documentation for it yet, only upstream wiki.
May be we should add instead a section to ipa-client-install manual page
and reference it?






Speaking of certs, should we introduce a aliases for host entries to avoid the
need of fake hosts?

These 'fake hosts' are as good as aliases, even better, because they
allow us to have full control over who can manage them.


I do not see how this is different from any other object which has managedBy
attribute. It is not a special property of host.

We have managedBy handling in hosts and services specifically to allow
certificate issuing on behalf of another entity.

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