[Freeipa-devel] [PATCHES 21-22] ipautil log messages and API version to env
Hello,
Patch 21:
This is a patch for https://fedorahosted.org/freeipa/ticket/3724
Patch 22:
This is part of https://fedorahosted.org/freeipa/ticket/4316 and adds the
API to 'ipa env'
One question that I had for adding 'ipa --version' is if using the default
optparse version argument would be sufficient/intended i.e.
version=('Version: %s, API_Version: %s' % (version, api_version) or if a
custom optparse argument is needed.
Thanks,
Gabe
From 6d69da44fa6d95c6e67b8071d587f57fdd61ecbb Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Tue, 3 Jun 2014 16:33:08 -0600
Subject: [PATCH] ipautil.run args log message is confusing
- Use python lists for args in ipautil
https://fedorahosted.org/freeipa/ticket/3724
---
ipapython/ipautil.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index ce4c978385ba681d2925dfd4816cb1f334d3a1c2..4d86b8cd0620242f41b2ffbed9ab4e32a77ec925 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -301,7 +301,7 @@ def run(args, stdin=None, raiseonerr=True,
p_out = subprocess.PIPE
p_err = subprocess.PIPE
-arg_string = nolog_replace(' '.join(args), nolog)
+arg_string = nolog_replace(args, nolog)
root_logger.debug('Starting external process')
root_logger.debug('args=%s' % arg_string)
--
1.9.3
From efc311adb0a8e9ca12b0abe22f134967ecd1f9fe Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Tue, 3 Jun 2014 16:41:55 -0600
Subject: [PATCH] Add API version to env
Part of:
https://fedorahosted.org/freeipa/ticket/4316
---
ipalib/constants.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ipalib/constants.py b/ipalib/constants.py
index e98eee6f8bcf2c227daa88327326b4dd850fbfe0..2269189f443844f77f3d8499cda3b88ae6d1d760 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -23,7 +23,8 @@ All constants centralised in one file.
import socket
from ipapython.dn import DN
-from ipapython.version import VERSION
+from ipapython.version import VERSION, API_VERSION
+
try:
FQDN = socket.getfqdn()
except:
@@ -65,6 +66,7 @@ CONFIG_SECTION = 'global'
# This is a tuple instead of a dict so that it is immutable.
# To create a dict with this config, just d = dict(DEFAULT_CONFIG).
DEFAULT_CONFIG = (
+('api_version', API_VERSION),
('version', VERSION),
# Domain, realm, basedn:
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Wikipedia articles mentioning FreeIPA
Hello list, I accidentally came across RHEV wikipedia articles mentioning FreeIPA: https://en.wikipedia.org/wiki/FreeIPA https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization Those articles could use attention of wordsmith :-) I'm not saying it should be full of marketing buzzwords, it should be factually correct. https://en.wikipedia.org/wiki/FreeIPA says: FreeIPA aims to provide support not just for Linux and Unix based computers but ultimately Microsoft Windows and Apple Macintosh computers also. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization says: It can acquire user and group information from an Active Directory service or FreeIPA Active Directory emulator, Have a nice day! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Wikipedia articles mentioning FreeIPA
On 06/06/2014 09:43 AM, Petr Spacek wrote: Hello list, I accidentally came across RHEV wikipedia articles mentioning FreeIPA: https://en.wikipedia.org/wiki/FreeIPA https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization Those articles could use attention of wordsmith :-) I'm not saying it should be full of marketing buzzwords, it should be factually correct. https://en.wikipedia.org/wiki/FreeIPA says: FreeIPA aims to provide support not just for Linux and Unix based computers but ultimately Microsoft Windows and Apple Macintosh computers also. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization says: It can acquire user and group information from an Active Directory service or FreeIPA Active Directory emulator, Have a nice day! Note that if you're a FreeIPA developer, especially a paid one, you should read Wikipedia's Conflict of Interest page carefully before (not) editing those pages. http://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Patch for #1539
On 05/31/2014 03:27 AM, Simo Sorce wrote: I have rebased theold patch attached to the ticket, unfortunately I haven't had time to test it yet, but didn't want to lose it in some branch. Simo. I tested the patch and it worked fine, code also reads OK. Thus, I am willing to ACK it. I am just wondering if there is any scenario we could have missed, but I did not find any. In there is no push back against the patch I may just push it. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed
On 06/04/2014 06:43 PM, Petr Viktorin wrote: Hello, I try to think about any kind of data the user might have in LDAP, but in the spirit of YAGNI, I'll deal with the various corner cases in IPA's historic default permissions as I go along. Patch 0568 adds support for the case where the default permissions changed in something else than attribute lists. Needed for the 'Change User password' permission. Patch 0569 converts user permissions to managed. Patch 0570 fixes https://fedorahosted.org/freeipa/ticket/3697 1) Add aci has targetfilter part - is that intentional? # ipa permission-show 'System: Add Users' --all --raw ... aci: (targetfilter = (objectclass=posixaccount))(version 3.0;acl permission:System: Add Users;allow (add) groupdn = ldap:///cn=System: Add Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test;) This part IS effective though, so it may not be a bad thing at all, to keep it in the ACI: # ldapadd -Y GSSAPI SASL/GSSAPI authentication started SASL username: f...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. dn: cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test objectclass: top objectclass: nscontainer cn: foo adding new entry cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test ldap_add: Insufficient access (50) additional info: Insufficient 'add' privilege to add the entry 'cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test'. # ipa user-add --first=Foo --last Bar fbar2 -- Added user fbar2 -- User login: fbar2 First name: Foo ... 2) System: Add User to default group I was wondering whether we should keep the ACI in cn=groups container or directly with the group, but I think the group itself is a good idea. (Unless someone deletes and recreates it). 3) System: Change User password I hit some nasty DS error which prevented authorized user to update password. ACI log attached. Ludwig, does that ring any bell? The ACI itself looks OK though as after I restarted DS, it started to work. Maybe DS did not cache the ACIs properly after upgrade? 4) When running user unit tests, I found couple issues: a) Some attributes we may still miss in the permissions: - krbPrincipalExpiration - userclass - ipaUserAuthType - preferredLanguage I am thinking we could base Modify Users permission on the read one and add regular attributes there b) Read membership ACIs for users and groups miss member attribute and thus indirect/direct processing goes wrong. This is all I could find, patches are looking good, otherwise. Martin [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=742 (main): Allow search on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=742 (main): Allow search on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=742 (main): Allow search on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.t...@mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root
Re: [Freeipa-devel] Move replication topology to the shared tree
we need to be careful on the process, I have an idea how it could work, but need to think a bit more about it I am all ears. Simo. We already have several situations (CRL, DNSSEC, cert rotation) where a single server has to do the job first and all the rest should rely on that. We can simply our life by making the initialization a special admin initialized operation for the situations when we upgrade from earlier versions. So general topology plugin does not initialize anything automatically. If we build a new deployment the ipa replica management tools will drive the modifications as servers are added. If it is an upgrade admin might go to IPA configuration and ray build/rebuild topology. This will drop all segment information if there is any and using master list from cn=masters connect to each replica, query its replication agreements and create data for the replicated tree. If some replica is not on line the operation will report that replica can be connected and that topology is not complete. I think this is acceptable for topology plugin to focus only on keeping data in sync when replica management tools are invoked and mot worry about initialization after migration. I finally agree, especially after having done some experiments with a rapid prototype. If the topology plugin is started before the replication plugin and does changes to the shared tree, these are not replicated. If the topology plugin is started after the replication plugin I get a failure in replication that no csn is assigned, and the startup of the topology plugin fails. These might be bugs to be resolved, but I think I will follow Dmitri's scenario for now - improvements can come later ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Multi-master replication with puppet
Hi FreeIPA, *intro* As some of you might know, I'm currently working on deploying multi-master replicas with puppet. Since it looks like there will be security implications, I wanted to start off by trying to build some confidence. I want to demonstrate that I am as paranoid about getting the security bits right as you all are. *cough* I'm looking at you Simo ;) I've just announced the first sane implementation for secret handling in puppet. Since everyone does this wrong, I thought I'd do it right, by pioneering a new technique. You can read about it here: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ In short, the dm_password and admin_password never get touched by puppet, and are generated locally on the freeipa server. What this means is that puppet doesn't know what they are, and as a result, can't use them to accomplish admin tasks. *replicas* ipa-replica-prepare and ipa-replica-install work _too_ well. they're the one part of freeipa that are so easy to use by a human, but nearly impossible to use with puppet (without storing the password in puppet). puppet can't use them as is because they need you to enter a password (which i don't want it to have). Here is what I propose to do for accomplishing this. Please correct me if I've made a mistake, or recommend something different. ipa-replica-prepare seems to need the dm_password. This seems to be needed for symmetrically encrypting the bunch of files to transfer to the replica. Instead, I'll patch this process to allow use of a public key for asymetric encryption that is unique to the receiving replica. I'll make sure that each ipa server generates it's own keypair, and that the public halves are distributed to the sending hosts. I don't think there is any other need for the dm_password in ipa-replica-prepare. Did I miss something? ipa-replica-install needs the dm_password to decrypt the gpg file. Since I'm handling that with my asymmetric key pair, we don't need the password for that. mkosek was very kind in helping me dig through this part a bit, and it seems that the dm_password is needed to allow the replica to bind to the first server. I would need some help to find an alternative for this process. As was suggested, perhaps a one-time password could be generated and sent across the wire (with puppet) to the replica. Any mechanism that doesn't need the dm_password would be great. I don't think there is any other need for the dm_password in ipa-replica-install. Did I miss something? Of course if I store the dm_password in puppet, then it's easy to do this peering because it will be easy to use the password on each host. I could be done my puppet module already :) But I'm going out of my way to do it right, so that you'll all be proud of the work too! *symmetry* It would be especially elegant and beneficial to FreeIPA and the puppet module if the process of peering was symmetrical, that is to say, similar for any host. If I could use ipa-server-install to setup N hosts, and then run a secondary command to cause certain ones to join this would make the process much more natural for puppet. In addition, this would ensure that the configuration management itself is HA. Without this type of functionality, then if the first ipa server isn't available, then config management will be blocked. I would appreciate any recommendations on how to convert a previously installed ipa server into a replica. Of course it's fine that it will have it's data overwritten. Thanks again! Cheers, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile
On 23.1.2014 14:34, Jan Cholasta wrote:
On 22.1.2014 16:43, Simo Sorce wrote:
On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote:
On 22.1.2014 15:34, Simo Sorce wrote:
On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote:
On 21.1.2014 17:12, Simo Sorce wrote:
Later in the patch you seem to be changing from needing
managedby_host
to needing write access to an entry, I am not sure I understand
why that
was changed. not saying it is necessarily wrong, but why the
original
check is not right anymore ?
The original check is wrong, see
https://fedorahosted.org/freeipa/ticket/3977#comment:23.
The check in my patch allows SAN only if the requesting host has write
access to all of the SAN services. I'm not entirely sure if this is
right, but even if it is not, I think we should still check for write
access to the SAN services, so that access control can be (partially)
handled by ACIs.
Right, I remembered that comment, but it just says to check the right
object's managed-by, here instead you changed it to check if you can
write the usercertificate.
I guess it is the same *if* there is an ACI that gives write permission
when the host is in the managed-by attribute, is that the reasoning ?
Exactly. The ACIs that allow this by default are named Hosts can manage
service Certificates and kerberos keys and Hosts can manage other host
Certificates and kerberos keys.
I think the check can be extended to users as well, so that requesting
certificate with SAN is allowed only to users which have write access to
the SAN services.
I have done the modification, see attached patches.
Sounds good to me then, thanks for explaining.
The patches also look good, but I would like someone to give them a try
for a formal ack.
OK, thanks.
Bump.
I have added stricter validation of subject alt names as well as
certificate extensions in general to the second patch.
Updated patches attached.
Note that you will need python-nss 0.15 in order to test, you can get a
RPM for Fedora here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=514739.
Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does
not work, because https://fedorahosted.org/freeipa/ticket/4370.
--
Jan Cholasta
From d5393642e6492af32d095ed2562be12f93b6be22 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 5 Dec 2013 14:34:14 +0100
Subject: [PATCH 1/2] Allow SAN in IPA certificate profile.
https://fedorahosted.org/freeipa/ticket/3977
---
install/tools/ipa-upgradeconfig | 7 +-
ipaserver/install/cainstance.py | 51 +
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 265d71c..431cca0 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -328,9 +328,14 @@ def upgrade_ipa_profile(ca, domain, fqdn):
root_logger.debug('Subject Key Identifier updated.')
else:
root_logger.debug('Subject Key Identifier already set.')
+san = ca.enable_subject_alternative_name()
+if san:
+root_logger.debug('Subject Alternative Name updated.')
+else:
+root_logger.debug('Subject Alternative Name already set.')
audit = ca.set_audit_renewal()
uri = ca.set_crl_ocsp_extensions(domain, fqdn)
-if audit or ski or uri:
+if audit or ski or san or uri:
return True
else:
root_logger.info('CA is not configured')
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index f528704..755d63b 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -462,6 +462,7 @@ class CAInstance(service.Service):
self.step(setting up signing cert profile, self.__setup_sign_profile)
self.step(set certificate subject base, self.__set_subject_in_config)
self.step(enabling Subject Key Identifier, self.enable_subject_key_identifier)
+self.step(enabling Subject Alternative Name, self.enable_subject_alternative_name)
self.step(enabling CRL and OCSP extensions for certificates, self.__set_crl_ocsp_extensions)
self.step(setting audit signing renewal to 2 years, self.set_audit_renewal)
self.step(configuring certificate server to start on boot, self.__enable)
@@ -1196,6 +1197,8 @@ class CAInstance(service.Service):
new_set_list = '1,2,3,4,5,6,7,8,9'
elif setlist == '1,2,3,4,5,6,7,8,10':
new_set_list = '1,2,3,4,5,6,7,8,9,10'
+elif setlist == '1,2,3,4,5,6,7,8,10,11':
+new_set_list = '1,2,3,4,5,6,7,8,9,10,11'
if new_set_list:
installutils.set_directive(self.dogtag_constants.IPA_SERVICE_PROFILE,
@@ -1511,6 +1514,54 @@ class CAInstance(service.Service):
# No update was done
return False
+def
Re: [Freeipa-devel] Patch for #1539
On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: On 05/31/2014 03:27 AM, Simo Sorce wrote: I have rebased theold patch attached to the ticket, unfortunately I haven't had time to test it yet, but didn't want to lose it in some branch. Simo. I tested the patch and it worked fine, code also reads OK. Thus, I am willing to ACK it. I am just wondering if there is any scenario we could have missed, but I did not find any. In there is no push back against the patch I may just push it. The only thing I would draw attention to is the fact that now I am sending back the error directly once we have a negative return from the function in which expiration is checked (ipapwd_authenticate). I could not see why we did, in fact, not do that before and I meant asking Nathaniel if he had an explicit reason why we do not, as he is the last one that did some significant refactoring in the bind preop plugin. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multi-master replication with puppet
On Fri, Jun 06, 2014 at 06:38:10AM -0400, James wrote: I've just announced the first sane implementation for secret handling in puppet. Since everyone does this wrong, I thought I'd do it right, by pioneering a new technique. You can read about it here: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ In short, the dm_password and admin_password never get touched by puppet, and are generated locally on the freeipa server. What this means is that puppet doesn't know what they are, and as a result, can't use them to accomplish admin tasks. Could we make this functionality part of the ipa-server-install script itself? It could be useful outside of puppet as well? Do you have any proposal how to go about ipa-client-install in puppet, without having the password stored/exposed there? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Wikipedia articles mentioning FreeIPA
On Fri, 2014-06-06 at 09:58 +0200, Petr Viktorin wrote: On 06/06/2014 09:43 AM, Petr Spacek wrote: Hello list, I accidentally came across RHEV wikipedia articles mentioning FreeIPA: https://en.wikipedia.org/wiki/FreeIPA https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization Those articles could use attention of wordsmith :-) I'm not saying it should be full of marketing buzzwords, it should be factually correct. https://en.wikipedia.org/wiki/FreeIPA says: FreeIPA aims to provide support not just for Linux and Unix based computers but ultimately Microsoft Windows and Apple Macintosh computers also. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization says: It can acquire user and group information from an Active Directory service or FreeIPA Active Directory emulator, Have a nice day! Note that if you're a FreeIPA developer, especially a paid one, you should read Wikipedia's Conflict of Interest page carefully before (not) editing those pages. http://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest I do not see any COI in amending factual errors. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multi-master replication with puppet
On Fri, 2014-06-06 at 06:38 -0400, James wrote: Hi FreeIPA, *intro* As some of you might know, I'm currently working on deploying multi-master replicas with puppet. Since it looks like there will be security implications, I wanted to start off by trying to build some confidence. I want to demonstrate that I am as paranoid about getting the security bits right as you all are. *cough* I'm looking at you Simo ;) I am cracking my knuckles already :-) Comments inline. I've just announced the first sane implementation for secret handling in puppet. Since everyone does this wrong, I thought I'd do it right, by pioneering a new technique. You can read about it here: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ In short, the dm_password and admin_password never get touched by puppet, and are generated locally on the freeipa server. What this means is that puppet doesn't know what they are, and as a result, can't use them to accomplish admin tasks. Ok let me try first to clarify what is the intent here. Clearly puppet has root level access to the system so you do not (should not ?) care much about preventing access to these systems, the aim is to not inadvertently divulge secrets through manifests and nothing else. Correct ? *replicas* ipa-replica-prepare and ipa-replica-install work _too_ well. they're the one part of freeipa that are so easy to use by a human, but nearly impossible to use with puppet (without storing the password in puppet). puppet can't use them as is because they need you to enter a password (which i don't want it to have). Here is what I propose to do for accomplishing this. Please correct me if I've made a mistake, or recommend something different. ipa-replica-prepare seems to need the dm_password. This seems to be needed for symmetrically encrypting the bunch of files to transfer to the replica. Instead, I'll patch this process to allow use of a public key for asymetric encryption that is unique to the receiving replica. I'll make sure that each ipa server generates it's own keypair, and that the public halves are distributed to the sending hosts. I don't think there is any other need for the dm_password in ipa-replica-prepare. Did I miss something? Yes, the dm_password was chosen because it is needed to actually initialize and install the replica, so instead of asking it twice we just ask for it once and use it *also* to encrypt the prepared file. But the password is still currently absolutely necessary. But let me ask a more important question, how do you distribute the public keys securely ? Is it puppet fetching them from each replica-to-be server and sending them to the first master server ? ipa-replica-install needs the dm_password to decrypt the gpg file. Since I'm handling that with my asymmetric key pair, we don't need the password for that. Beeep, sorry wrong answer for now :-) mkosek was very kind in helping me dig through this part a bit, and it seems that the dm_password is needed to allow the replica to bind to the first server. It is also needed to actually store the DM password on the replica server itself in it's own cn=Directory Manager super user entry. Although I think we could send the hash for that. I would need some help to find an alternative for this process. As was suggested, perhaps a one-time password could be generated and sent across the wire (with puppet) to the replica. Any mechanism that doesn't need the dm_password would be great. Forget custom schemes. The simplest way to handle this (which I wanted to do for a while) is to pre-create the replica's LDAP principal and keys at replica-prepare time so we can start right away with GSSAPI authentication for the first replication and create agreements directly using GSSAPI auth. This would in turn simplify replication agreements creation as we won't need anymore to do the dance where we create the agreement with a plain text bind and then we need to convert the agreement to use GSSAPI. I don't think there is any other need for the dm_password in ipa-replica-install. Did I miss something? See above, it needs the password to actually create the DM account at DS setup time. *also* the DM password is used to setup some parts of the dogtag CA so if any of your replica is also a CA clone you go straight back to needing the DM password. Of course if I store the dm_password in puppet, then it's easy to do this peering because it will be easy to use the password on each host. I could be done my puppet module already :) But I'm going out of my way to do it right, so that you'll all be proud of the work too! Ok, here is a quickest method to do what you want to do IMO: First of all, you need a DM password for the initial server and you need to store it somewhere because the admin must know what it is, there is no way around this. So I guess you are planning to store it in a file under /root in
Re: [Freeipa-devel] Move replication topology to the shared tree
On Fri, 2014-06-06 at 06:58 -0400, James wrote: On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz lkris...@redhat.com wrote: Ticket 4302 is a request for an enhancement: Move replication topology to the shared tree One comment to add: It would be particularly useful if the interface used to set the topology is something sane that a single host can use to set its peers. Eg: host1$ ipa-topology-set-peers host2 host2$ ipa-topology-set-peers host3 host3$ ipa-topology-set-peers host4 host4$ ipa-topology-set-peers host1 # redundant, but okay... This way config management could define topologies in terms of algorithms. Eg: Ring topology: Order hostnames alphabetically. Peer with host name index of self + 1 (Example shown above) Star topology: Peer with every other host in list Pick two topology: Peer with each subsequent hosts in ordered list... And so on... If running the command changes the topology again, then that's great because changing the algorithm would re-arrange the graph :) Hope this made sense. Oh it does! But I am dreaming even bigger, my aim is to end up (in the long run) with something like: ipa topology change --stellar host1 host2 host3 host4 host5 causes topology for those 5 servers only (ignores any other connection) to become: host2 | host3 - host1 - host5 | host4 So any agreement between host1 and 2,3,4,5 get wiped and replaced with the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not affected in any way and stay). And later on you'd be able to say ipa topology change --circular host1 host2 host3 host4 and you get: host1 - host2 | | host4 - host3 Note that if you previously did the stellar thing and you only have these 5 servers the actual complete topology ends up being like this: host5 | host1 - host2 | | host4 - host3 As the agreement between host1 and host5 is not touched by the second command. But this is in the far future IMO, we'll probably start by only implementing: ipa topology set-peering host1 host2 and ipa topology break-peering host3 host4 Ie creating and breaking segments in the topology tree only between pairs and storing/deleting the segment object in the shared tree. The reason is that the topology plugin will allow or disallow changes based on whether you are breaking the graph, and it is much simpler to do that if you change one object at a time. To do the nifty stuff above we'd need some staging area where we describe all the changes and then have a commit type change that would cause the topology plugin to do all the calculations and move stuff around inside at once (or refuse the commit if the change as a whole breaks the graph). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multi-master replication with puppet
On Fri, Jun 06, 2014 at 08:51:39AM -0400, Simo Sorce wrote: Clearly puppet has root level access to the system so you do not (should not ?) care much about preventing access to these systems, the aim is to not inadvertently divulge secrets through manifests and nothing else. And puppet logs. And forgetting the secrets around. With puppet you do not have interactive (password) prompt available so everything including secrets needs to be pre-created and pre-populated before the puppet apply starts. Or, where possible, generated and immediatelly encrypted -- I find that approach very clever. But unfortunately it can only be used for the initial FreeIPA server installation, it seems -- in all the subsequent operations, we need to pass the existing matching credential. I wonder if we could be able to pass the passwords to puppet via file descriptors from some invoking wrapper ... -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly
On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote:
ACK for patches #592-#628. I'll continue reviewing the rest.
ACK for patches #633-639, #642, #644, #652, and #653. Patches #640
#641 have an issue (see #19 below) that should be fixed before pushing.
Other issues are minor/unrelated/suggestions that can be addressed
separately.
13. The separators in the top right drop down menu shouldn't be
focusable. To test this, click the menu, then hit tab several times.
14. In the certificates page, if I enter a search filter then hit
Refresh (instead of Enter) it doesn't change the content based on the
new search filter. I suppose a more intuitive behavior would be to rerun
the search with the new filter, or reset the filter to the previous value.
15. In the certificates page, if I enter an invalid filter it will show
an error dialog, then after I close it it will show the error message in
the page. This is fine, but if I go to another page, then back, it will
do the same thing as if the search is executed again. If the page is
cached, it probably shouldn't display the error dialog, just the error
message in the page. Alternatively, if the search failed it shouldn't be
cached.
16. In the association adder dialog it's not clear if the filter applies
to just the Available list or the Prospective list too. Maybe the
placeholder text could say Filter available ${other_entity}.
17. It looks like some facet-actions elements contain unnecessary blank
ul.dropdown-menu elements which probably correspond to the number of
menu items (see User's Actions button).
18. In the New Certificate dialog for Host, the instruction to create a
CSR exceeds the dialog boundary.
19. The View certificate is missing from the Host's and Service's
Action, probably because of the incorrect labels below:
IPA.cert.view_action = function(spec) {
// should be objects.cert.view_certificate_btn
spec.label = spec.label || '@i18n:objects.cert.view';
that.execute_action = function(facet) {
// should be objects.cert.view_certificate
var title = text.get('@i18n:objects.cert.view_certificate_btn');
20. The capitalization of Certificate is inconsistent in Host's and
Service's Actions.
21. Should there be a link from the Host page to the Certificate page?
Can the certificate serial number be displayed in the Host page? If we
do this, it's probably not necessary to have Revoke/Restore Certificate
actions in the Host page. Same thing with the Service page.
22. The add dialog for RADIUS Server uses a field label Secret.
Everywhere else in the RADIUS Server page it's called Password (e.g.
Verify Password, Reset Password).
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 21-22] ipautil log messages and API version to env
Patch 21:
Update per recommendation
Patch 22:
Added version option as well as updated the manpage.
Thanks,
Gabe
On Fri, Jun 6, 2014 at 5:47 AM, Petr Viktorin pvikt...@redhat.com wrote:
On 06/06/2014 08:36 AM, Gabe Alford wrote:
Hello,
Patch 21:
This is a patch for https://fedorahosted.org/freeipa/ticket/3724
Nope, doesn't work for me: nolog_replace expects a string.
File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 639, in run_script
return_value = main_function()
File /usr/sbin/ipa-upgradeconfig, line 1140, in main
certificate_renewal_update(ca),
File /usr/sbin/ipa-upgradeconfig, line 691, in
certificate_renewal_update
ca.configure_renewal()
File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1444, in configure_renewal
post_command='renew_ca_cert %s' % nickname)
File /usr/lib/python2.7/site-packages/ipapython/certmonger.py, line
431, in dogtag_start_tracking
(stdout, stderr, returncode) = ipautil.run(args, nolog=[pin])
File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 305,
in run
arg_string = nolog_replace(args, nolog)
File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 360,
in nolog_replace
string = string.replace(nolog_value, '')
I'd recommend something like ' '.join(shell_quote(a) for a in args).
Patch 22:
This is part of https://fedorahosted.org/freeipa/ticket/4316 and adds
the API to 'ipa env'
One question that I had for adding 'ipa --version' is if using the
default optparse version argument would be sufficient/intended i.e.
version=('Version: %s, API_Version: %s' % (version, api_version) or if a
custom optparse argument is needed.
I think the default will be just fine. Can you update the patch to add the
option?
--
Petrł
From e1fccecb68b946b1868255b1db7ed3227c24ccdc Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Fri, 6 Jun 2014 06:39:59 -0600
Subject: [PATCH] Add version and API version
- Add API version to constants.py
- Add version option to plugable.py
- Add version to ipa manpage and fix a couple of typos
https://fedorahosted.org/freeipa/ticket/4316
---
ipa.1 |6 --
ipalib/constants.py |4 +++-
ipalib/plugable.py |3 +++
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/ipa.1 b/ipa.1
index 3d998cc1bb1053b079fa3813a037f7a09926a1bd..fc39fceaae5aa4c614ccaaa7e608f2326d926755 100644
--- a/ipa.1
+++ b/ipa.1
@@ -37,7 +37,7 @@ Load configuration from \fIFILE\fR.
\fB\-d\fR, \fB\-\-debug\fR
Produce full debugging output.
.TP
-\fB\-\-\-delegate\fR
+\fB\-\-delegate\fR
Delegate the user's TGT to the IPA server
.TP
\fB\-e\fR \fIKEY=VAL\fR
@@ -56,7 +56,9 @@ Prompt for all parameters of \fICOMMAND\fR, even if they are optional.
Don't fall back to other IPA servers if the default doesn't work.
.TP
\fB\-v\fR, \fB\-\-verbose\fR
-Produce verbose output. A second \-v displays the XML\-RPC request
+Produce verbose output. A second \-v displays the XML\-RPC request.
+\fB\-\-version\fR
+Display the IPA version and API version.
.SH COMMANDS
The principal function of the CLI is to execute administrative commands specified by the \fICOMMAND\fR argument. The majority of commands are executed remotely over XML\-RPC on a IPA server listed in the configuration file (see FILES section of this manual page).
diff --git a/ipalib/constants.py b/ipalib/constants.py
index e98eee6f8bcf2c227daa88327326b4dd850fbfe0..2269189f443844f77f3d8499cda3b88ae6d1d760 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -23,7 +23,8 @@ All constants centralised in one file.
import socket
from ipapython.dn import DN
-from ipapython.version import VERSION
+from ipapython.version import VERSION, API_VERSION
+
try:
FQDN = socket.getfqdn()
except:
@@ -65,6 +66,7 @@ CONFIG_SECTION = 'global'
# This is a tuple instead of a dict so that it is immutable.
# To create a dict with this config, just d = dict(DEFAULT_CONFIG).
DEFAULT_CONFIG = (
+('api_version', API_VERSION),
('version', VERSION),
# Domain, realm, basedn:
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 216f9c08a8b5d22bdb1e7853013967e8fe3f88b0..a6504d16222ff9c714a17e71db3d8bd12d885a9b 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -43,6 +43,7 @@ from text import _
from base import ReadOnly, NameSpace, lock, islocked, check_name
from constants import DEFAULT_CONFIG
from ipapython.ipa_log_manager import *
+from ipapython.version import VERSION, API_VERSION
# FIXME: Updated constants.TYPE_ERROR to use this clearer format from wehjit:
TYPE_ERROR = '%s: need a %r; got a %r: %r'
@@ -559,6 +560,8 @@ class API(DictProxy):
formatter=IPAHelpFormatter(),
usage='%prog [global-options] COMMAND [command-options]',
description='Manage an IPA domain',
+version=('VERSION: %s, API_VERSION: %s'
+
Re: [Freeipa-devel] Patch for #1539
On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: On 05/31/2014 03:27 AM, Simo Sorce wrote: I have rebased theold patch attached to the ticket, unfortunately I haven't had time to test it yet, but didn't want to lose it in some branch. Simo. I tested the patch and it worked fine, code also reads OK. Thus, I am willing to ACK it. I am just wondering if there is any scenario we could have missed, but I did not find any. In there is no push back against the patch I may just push it. The only thing I would draw attention to is the fact that now I am sending back the error directly once we have a negative return from the function in which expiration is checked (ipapwd_authenticate). I could not see why we did, in fact, not do that before and I meant asking Nathaniel if he had an explicit reason why we do not, as he is the last one that did some significant refactoring in the bind preop plugin. In the current design, if ipapwd_authenticate() fails, we defer to 389ds for the actual response to the client. The purpose for this is so that verification of the first factor always behaves the same, regardless of what is in pre-bind. So ipapwd_authenticate() is not actually the final authentication. It is a preliminary authentication to determine if the user should be able to write kerberos keys and perform OTP sync. So checking expiration in pre-bind only protects these two operations. I presume that 389ds also checks password expiration. If this assumption is true, ipapwd_authenticate() SHOULD NOT return any response to the client. It should simply fail key-write/otp-sync silently and let dirsrv return the error to the client. The important point here is that so long as 389ds is verifying password expiration, using a correct-but-expired password will should not result in a bind in the current code. It will result in kerberos key writing and OTP sync. Do we actually care about protecting kerberos key writing and OTP sync from correct-but-expired passwords? If 389ds does not check password expiration, then we probably need to patch upstream 389ds or, at the very least, return an error to the client. Otherwise, if we don't care about protecting kerberos key writing and OTP sync from correct-but-expired passwords, this patch is entirely unnecessary. Otherwise, the patch is necessary, but should skip kerberos key writing and OTP sync and fall through silently to 389ds. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Patch for #1539
On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: On 05/31/2014 03:27 AM, Simo Sorce wrote: I have rebased theold patch attached to the ticket, unfortunately I haven't had time to test it yet, but didn't want to lose it in some branch. Simo. I tested the patch and it worked fine, code also reads OK. Thus, I am willing to ACK it. I am just wondering if there is any scenario we could have missed, but I did not find any. In there is no push back against the patch I may just push it. The only thing I would draw attention to is the fact that now I am sending back the error directly once we have a negative return from the function in which expiration is checked (ipapwd_authenticate). I could not see why we did, in fact, not do that before and I meant asking Nathaniel if he had an explicit reason why we do not, as he is the last one that did some significant refactoring in the bind preop plugin. In the current design, if ipapwd_authenticate() fails, we defer to 389ds for the actual response to the client. The purpose for this is so that verification of the first factor always behaves the same, regardless of what is in pre-bind. So ipapwd_authenticate() is not actually the final authentication. It is a preliminary authentication to determine if the user should be able to write kerberos keys and perform OTP sync. So checking expiration in pre-bind only protects these two operations. I presume that 389ds also checks password expiration. If this assumption is true, ipapwd_authenticate() SHOULD NOT return any response to the client. It should simply fail key-write/otp-sync silently and let dirsrv return the error to the client. 389ds would check it if we were using 389ds native password policies but we are not. So we need to check on our own, which is what this patch implements. The important point here is that so long as 389ds is verifying password expiration, using a correct-but-expired password will should not result in a bind in the current code. It will result in kerberos key writing and OTP sync. Do we actually care about protecting kerberos key writing and OTP sync from correct-but-expired passwords? No, but that's not the point. If 389ds does not check password expiration, then we probably need to patch upstream 389ds or, at the very least, return an error to the client. It is not a 389ds bug, it is just an integration issue due to the fact IPA uses a different schema for password policies (for compatibility with the Kerberos schema). Otherwise, if we don't care about protecting kerberos key writing and OTP sync from correct-but-expired passwords, this patch is entirely unnecessary. Otherwise, the patch is necessary, but should skip kerberos key writing and OTP sync and fall through silently to 389ds. If we fall through to 389ds then authentication will succeed. So from this discussion it seem to me we achieve the goal of the patch and returning an error directly is ok. Unless Nathaniel has something *against* returning an error in this place I think we are good to go. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly
On 6.6.2014 15:45, Endi Sukma Dewata wrote:
On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote:
ACK for patches #592-#628. I'll continue reviewing the rest.
ACK for patches #633-639, #642, #644, #652, and #653. Patches #640
#641 have an issue (see #19 below) that should be fixed before pushing.
Other issues are minor/unrelated/suggestions that can be addressed
separately.
Thank you for the review.
I've fixed issues:
- #19, #20 in patch #640.
And some low hanging fruit:
- #16, in patch #637
- #17, in patch #612
- #13, in patch #612
The branch has been rebased to current master.
Some comments bellow. For the rest (including issues #1-#12) I'll create
tickets and/or fix them later. Some are existing issues.
I am not able to reproduce issues #4 and #11.
13. The separators in the top right drop down menu shouldn't be
focusable. To test this, click the menu, then hit tab several times.
Fixed. Also disabled items are no longer focusable.
14. In the certificates page, if I enter a search filter then hit
Refresh (instead of Enter) it doesn't change the content based on the
new search filter. I suppose a more intuitive behavior would be to rerun
the search with the new filter, or reset the filter to the previous value.
15. In the certificates page, if I enter an invalid filter it will show
an error dialog, then after I close it it will show the error message in
the page. This is fine, but if I go to another page, then back, it will
do the same thing as if the search is executed again. If the page is
cached, it probably shouldn't display the error dialog, just the error
message in the page. Alternatively, if the search failed it shouldn't be
cached.
I don't think this page is cached - the wrong command is executed every
time which will show the dialog.
16. In the association adder dialog it's not clear if the filter applies
to just the Available list or the Prospective list too. Maybe the
placeholder text could say Filter available ${other_entity}.
Fixed
17. It looks like some facet-actions elements contain unnecessary blank
ul.dropdown-menu elements which probably correspond to the number of
menu items (see User's Actions button).
Fixed DropdownWidget's _render_items method.
18. In the New Certificate dialog for Host, the instruction to create a
CSR exceeds the dialog boundary.
caused by BS' CSS:
code {
white-space: nowrap;
}
I wonder if the best solution is to reset it to initial value in all
dialogs.
19. The View certificate is missing from the Host's and Service's
Action, probably because of the incorrect labels below:
IPA.cert.view_action = function(spec) {
// should be objects.cert.view_certificate_btn
spec.label = spec.label || '@i18n:objects.cert.view';
that.execute_action = function(facet) {
// should be objects.cert.view_certificate
var title = text.get('@i18n:objects.cert.view_certificate_btn');
Fixed
20. The capitalization of Certificate is inconsistent in Host's and
Service's Actions.
Fixed
21. Should there be a link from the Host page to the Certificate page?
Can the certificate serial number be displayed in the Host page? If we
do this, it's probably not necessary to have Revoke/Restore Certificate
actions in the Host page. Same thing with the Service page.
22. The add dialog for RADIUS Server uses a field label Secret.
Everywhere else in the RADIUS Server page it's called Password (e.g.
Verify Password, Reset Password).
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Patch for #1539
On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: On 05/31/2014 03:27 AM, Simo Sorce wrote: I have rebased theold patch attached to the ticket, unfortunately I haven't had time to test it yet, but didn't want to lose it in some branch. Simo. I tested the patch and it worked fine, code also reads OK. Thus, I am willing to ACK it. I am just wondering if there is any scenario we could have missed, but I did not find any. In there is no push back against the patch I may just push it. The only thing I would draw attention to is the fact that now I am sending back the error directly once we have a negative return from the function in which expiration is checked (ipapwd_authenticate). I could not see why we did, in fact, not do that before and I meant asking Nathaniel if he had an explicit reason why we do not, as he is the last one that did some significant refactoring in the bind preop plugin. In the current design, if ipapwd_authenticate() fails, we defer to 389ds for the actual response to the client. The purpose for this is so that verification of the first factor always behaves the same, regardless of what is in pre-bind. So ipapwd_authenticate() is not actually the final authentication. It is a preliminary authentication to determine if the user should be able to write kerberos keys and perform OTP sync. So checking expiration in pre-bind only protects these two operations. I presume that 389ds also checks password expiration. If this assumption is true, ipapwd_authenticate() SHOULD NOT return any response to the client. It should simply fail key-write/otp-sync silently and let dirsrv return the error to the client. 389ds would check it if we were using 389ds native password policies but we are not. So we need to check on our own, which is what this patch implements. The important point here is that so long as 389ds is verifying password expiration, using a correct-but-expired password will should not result in a bind in the current code. It will result in kerberos key writing and OTP sync. Do we actually care about protecting kerberos key writing and OTP sync from correct-but-expired passwords? No, but that's not the point. If 389ds does not check password expiration, then we probably need to patch upstream 389ds or, at the very least, return an error to the client. It is not a 389ds bug, it is just an integration issue due to the fact IPA uses a different schema for password policies (for compatibility with the Kerberos schema). Otherwise, if we don't care about protecting kerberos key writing and OTP sync from correct-but-expired passwords, this patch is entirely unnecessary. Otherwise, the patch is necessary, but should skip kerberos key writing and OTP sync and fall through silently to 389ds. If we fall through to 389ds then authentication will succeed. So from this discussion it seem to me we achieve the goal of the patch and returning an error directly is ok. Unless Nathaniel has something *against* returning an error in this place I think we are good to go. Looks good to me. ACK. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move replication topology to the shared tree
On 06/06/2014 09:03 AM, Simo Sorce wrote: On Fri, 2014-06-06 at 06:58 -0400, James wrote: On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz lkris...@redhat.com wrote: Ticket 4302 is a request for an enhancement: Move replication topology to the shared tree One comment to add: It would be particularly useful if the interface used to set the topology is something sane that a single host can use to set its peers. Eg: host1$ ipa-topology-set-peers host2 host2$ ipa-topology-set-peers host3 host3$ ipa-topology-set-peers host4 host4$ ipa-topology-set-peers host1 # redundant, but okay... This way config management could define topologies in terms of algorithms. Eg: Ring topology: Order hostnames alphabetically. Peer with host name index of self + 1 (Example shown above) Star topology: Peer with every other host in list Pick two topology: Peer with each subsequent hosts in ordered list... And so on... If running the command changes the topology again, then that's great because changing the algorithm would re-arrange the graph :) Hope this made sense. Oh it does! But I am dreaming even bigger, my aim is to end up (in the long run) with something like: ipa topology change --stellar host1 host2 host3 host4 host5 causes topology for those 5 servers only (ignores any other connection) to become: host2 | host3 - host1 - host5 | host4 So any agreement between host1 and 2,3,4,5 get wiped and replaced with the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not affected in any way and stay). And later on you'd be able to say ipa topology change --circular host1 host2 host3 host4 and you get: host1 - host2 | | host4 - host3 Note that if you previously did the stellar thing and you only have these 5 servers the actual complete topology ends up being like this: host5 | host1 - host2 | | host4 - host3 As the agreement between host1 and host5 is not touched by the second command. But this is in the far future IMO, we'll probably start by only implementing: ipa topology set-peering host1 host2 and ipa topology break-peering host3 host4 Ie creating and breaking segments in the topology tree only between pairs and storing/deleting the segment object in the shared tree. The reason is that the topology plugin will allow or disallow changes based on whether you are breaking the graph, and it is much simpler to do that if you change one object at a time. To do the nifty stuff above we'd need some staging area where we describe all the changes and then have a commit type change that would cause the topology plugin to do all the calculations and move stuff around inside at once (or refuse the commit if the change as a whole breaks the graph). HTH, Simo. I was thinking about the commit and staging too. I think this approach will be beneficial for the rebuild from existing non replicated agreements use case too. The logic for the use case that I described in other branch of this discussion will be: - Collect all info by contacting all the servers. - Save in staging - Analyze that topology makes sense and graph is not broken (error out if it is) - Start transaction - Put the data into the replicated tree - Stop transaction - Start replicating -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move replication topology to the shared tree
On 06/06/2014 06:12 PM, Dmitri Pal wrote: On 06/06/2014 09:03 AM, Simo Sorce wrote: On Fri, 2014-06-06 at 06:58 -0400, James wrote: On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz lkris...@redhat.com wrote: Ticket 4302 is a request for an enhancement: Move replication topology to the shared tree One comment to add: It would be particularly useful if the interface used to set the topology is something sane that a single host can use to set its peers. Eg: host1$ ipa-topology-set-peers host2 host2$ ipa-topology-set-peers host3 host3$ ipa-topology-set-peers host4 host4$ ipa-topology-set-peers host1 # redundant, but okay... This way config management could define topologies in terms of algorithms. Eg: Ring topology: Order hostnames alphabetically. Peer with host name index of self + 1 (Example shown above) Star topology: Peer with every other host in list Pick two topology: Peer with each subsequent hosts in ordered list... And so on... If running the command changes the topology again, then that's great because changing the algorithm would re-arrange the graph :) Hope this made sense. Oh it does! But I am dreaming even bigger, my aim is to end up (in the long run) with something like: ipa topology change --stellar host1 host2 host3 host4 host5 causes topology for those 5 servers only (ignores any other connection) to become: host2 | host3 - host1 - host5 | host4 So any agreement between host1 and 2,3,4,5 get wiped and replaced with the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not affected in any way and stay). And later on you'd be able to say ipa topology change --circular host1 host2 host3 host4 and you get: host1 - host2 | | host4 - host3 Note that if you previously did the stellar thing and you only have these 5 servers the actual complete topology ends up being like this: host5 | host1 - host2 | | host4 - host3 As the agreement between host1 and host5 is not touched by the second command. But this is in the far future IMO, we'll probably start by only implementing: ipa topology set-peering host1 host2 and ipa topology break-peering host3 host4 Ie creating and breaking segments in the topology tree only between pairs and storing/deleting the segment object in the shared tree. The reason is that the topology plugin will allow or disallow changes based on whether you are breaking the graph, and it is much simpler to do that if you change one object at a time. To do the nifty stuff above we'd need some staging area where we describe all the changes and then have a commit type change that would cause the topology plugin to do all the calculations and move stuff around inside at once (or refuse the commit if the change as a whole breaks the graph). HTH, Simo. I was thinking about the commit and staging too. I think this approach will be beneficial for the rebuild from existing non replicated agreements use case too. The logic for the use case that I described in other branch of this discussion will be: - Collect all info by contacting all the servers. - Save in staging - Analyze that topology makes sense and graph is not broken (error out if it is) - Start transaction - Put the data into the replicated tree - Stop transaction - Start replicating ok, so this will be handled outside of the topology plugin, a future step could be to define topology types and connectivity rules and have the topology plugin to verify this ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0049] Add support for protected tokens
On Thu, 2014-06-05 at 08:45 +0200, Jan Cholasta wrote: On 28.5.2014 22:44, Nathaniel McCallum wrote: On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote: On 13.5.2014 19:12, Nathaniel McCallum wrote: On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote: On 12.5.2014 21:02, Nathaniel McCallum wrote: On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: Hi, On 6.5.2014 17:08, Nathaniel McCallum wrote: On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: This also constitutes a rethinking of the token ACIs after the introduction of SELFDN support. Admins, as before, have full access to all token permissions. Normal users have read/search/compare access to all of the non-secret data for tokens assigned to them, whether protected or non-protected. Users can add or delete non-protected tokens and modify most of their metadata. However they cannot create, delete or modify protected tokens. Regardless of whether the token is protected or not, users cannot change a token's ownership or unique identity. In contrast, admins can create protected tokens. This protects the token from deletion or modification when assigned to users. Additionally, when a user account is deleted, the assigned non-protected tokens are deleted but the protected tokens are merely orphaned. This permits the token to be reassigned without having to recreate it. This last point is particularly useful in the case of hardware tokens. https://fedorahosted.org/freeipa/ticket/4228 NOTE: This patch depends on my patch 0048. This new version makes ipatokenDisabled visible for token owners. It is also writable if the token is non-protected. This additionally fixes: https://fedorahosted.org/freeipa/ticket/4259 This new version changes the way the default value of protected is setup in accordance with the changes made for the review of my patch 0048.2. Nathaniel Is using the ipatokenprotected attribute the final design? No. Alternate designs are welcome. The code is easy enough to modify. I did not dig too deep into this, but I think it might be better to instead use the managedby attribute on a token to limit who can delete (or administer in other way) the token. On otptoken-add, managedby would be set to the whoami user DN, unless run with --protected, in which case managedby would be left empty. Then, when deleting a user, the token would be deleted only if the user manages the token. It seems to me that the mechanics of this are roughly the same as protected, just with a different syntax. The cost of this is more complex ACIs. In particular, we'd have to use two userdn clauses (is this possible?) instead of a simple filter. If there is a clear benefit, we can justify the more obtuse syntax. We usually try not to create new attributes until it is fully justified. I would like Simo to chime in on this. I would also prefer to reuse existing attributes and mechanism if possible and if it will not preclude future work. In this case, it sounds like managed-by has the appropriate meaning: who manages the token ? - myself, admin, other, none ? Nathaniel can you send 2 lines showing the difference in ACIs between using managed-by vs a new attribute ? These are the ACIs using the protected mechanism: aci: (targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || description || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0; acl Users can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN;) aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs = ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details; allow (read, search, compare) userattr = ipatokenOwner#USERDN;) aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs = ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can see HOTP details; allow (read, search, compare) userattr = ipatokenOwner#USERDN;) aci: (targetfilter = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs = description || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can write basic token info; allow (write) userattr = ipatokenOwner#USERDN;) aci: (target =
[Freeipa-devel] [RFC] Extdom plugin enhancement: grouplist
Hi,
I've created a design page about enhancing the extdom plugin to send the
list of groups of a user together with the POSIX data to IPA clients
with SSSD at
http://www.freeipa.org/page/V4/Extdom_plugin_enhancement_grouplist
For your convenience the text can be found below as well.
Comments and suggestions are welcome.
bye,
Sumit
= Overview =
Currently on FreeIPA clients the full list of group-memberships for
users from trusted domains is only available for authenticated users.
Authentication is needed because the group-memberships are extracted
from the PAC which is a part of the Kerberos ticket of the user. For
un-authenticated users only the primary POSIX group is available.
With the introduction of SSSD's ipa-server-mode IPA servers can resolve
the group memberships for user from trusted domains even for
un-authenticated users by reading them from the AD DCs of the trusted
domains directly. This data should be made available to the IPA clients
as well.
= Use Cases =
* Calling the 'id' command on a IPA client or calling getgrouplist() in
* a process should return the full list of secondary groups for any user
* from a trusted domain without requiring that the user has to log in
* first
** [https://fedorahosted.org/freeipa/ticket/4031 RFE Support initgroups
for unauthenticated AD users] FreeIPA ticket
** [https://fedorahosted.org/sssd/ticket/2159 RFE Support initgroups for
unauthenticated AD users] SSSD ticket
= Design =
The IPA extdom plugin is already called by SSSD running on the IPA
clients to translate SID to names or POSIX IDs. It can be enhanced to
return the secondary groups as well.
To make this change backward compatible in the sense that newer client
can still work with older servers
* a new OID can be added to the extdom plugin, currently it uses
* 2.16.840.1.113730.3.8.10.4 , if we agree on this approach it might be
* possible to just add a .1 to the OID. With this the client can
* determine from reading the rootDSE if the server supports this
* operation or not.
* the client just sends the new request and assumes in the case of a
* specific error the request is not supported. A suitable error code
* might be LDAP_UNWILLING_TO_PERFORM which is currently only returned by
* the extdom plugin if either there is no request data or if there are
* issues reading and understanding the first enumeration in the request
* data (see Implementation section for more details).
If the request was parsed successful the extdom plugin will return the
secondary groups for the given user as a list of fully qualified group
names. Additionally the POSIX user data (UID, GID, gecos, home-directory
and shell) can be send. This would reduce the number of requests to the
extdom plugin, because refreshing user and group-membership data often
happen together. Please note that UID and GID may change due to
user-views. But as long as this feature is implemented after user-views
everything what is needed will be available.
= Implementation =
== Request ==
The current request looks like this:
/* We expect the following request:
* ExtdomRequestValue ::= SEQUENCE {
*inputType ENUMERATED {
*sid (1),
*name (2),
*posix uid (3),
*posix gid (3)
*},
*requestType ENUMERATED {
*simple (1),
*full (2)
*},
*data InputData
* }
*
* InputData ::= CHOICE {
*sid OCTET STRING,
*name NameDomainData
*uid PosixUid,
*gid PosixGid
* }
*
* NameDomainData ::= SEQUENCE {
*domain_name OCTET STRING,
*object_name OCTET STRING
* }
*
* PosixUid ::= SEQUENCE {
*domain_name OCTET STRING,
*uid INTEGER
* }
*
* PosixGid ::= SEQUENCE {
*domain_name OCTET STRING,
*gid INTEGER
* }
*/
Basically only a new request type must be added, e.g.
*requestType ENUMERATED {
*simple (1),
*full (2)
*full_with_groups (3)
*},
But as mentioned before the LDAP_UNWILLING_TO_PERFORM error code is only
send if there are issues with the inputType. The requestType is
evaluated later in the existing code and the quite generic
LDAP_OPERATIONS_ERROR error code is returned if an unexpected value is
found. This would make the detection based on error code much more
fragile. I would suggest if we do not want to use a new OID to indicate
the feature, that the inputType is extended as well, e.g. by adding 128
or 256 to the values. Nevertheless I think it is less error prone to use
a new OID.
== Processing the request ==
The extdom plugin will call getgrouplist() and the resolve the fully
qualified names by calling getgrgid(). By default groups from the local
IPA domain are returned unqualified and the local domain name should be
added in this case so that the response only contains fully qualified
group names.
There are two things to note here. First getgrgid() returns the full
list of group members which might cause some unneeded overhead e.g. with
[Freeipa-devel] [PATCH 0263-0265] Support root master zone in LDAP Follow BIND semantics for forwarders
Hello,
This patch set contains necessary changes for supporting root master zone in
LDAP. I had to remove one hack so now we follow BIND semantics for forwarders.
Please see commit messages.
https://fedorahosted.org/bind-dyndb-ldap/ticket/122
--
Petr^2 Spacek
From 21f7ecd4eb4f977392975034fc9de3b61958e2aa Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 6 Jun 2014 19:28:13 +0200
Subject: [PATCH] Refactor DN-DNS name conversion.
Original code was fragile and unable to parse name of root zone
(idnsName=.).
https://fedorahosted.org/bind-dyndb-ldap/ticket/122
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_convert.c | 275 +
1 file changed, 106 insertions(+), 169 deletions(-)
diff --git a/src/ldap_convert.c b/src/ldap_convert.c
index 89c371d27447b34e28bd24ddcaefb58fcaf1dd07..be5c2e1d4dc903b4d9e72cc07ed1d9fc32fef0d1 100644
--- a/src/ldap_convert.c
+++ b/src/ldap_convert.c
@@ -40,164 +40,149 @@
#include util.h
#include zone_register.h
-static isc_result_t explode_dn(const char *dn, char ***explodedp, int notypes) ATTR_NONNULLS ATTR_CHECKRESULT;
-static isc_result_t explode_rdn(const char *rdn, char ***explodedp,
-int notypes) ATTR_NONNULLS ATTR_CHECKRESULT;
-
-
-isc_result_t
-dn_to_dnsname(isc_mem_t *mctx, const char *dn, dns_name_t *target,
- dns_name_t *otarget)
-{
- isc_result_t result;
- DECLARE_BUFFERED_NAME(name);
- DECLARE_BUFFERED_NAME(origin);
- ld_string_t *str = NULL;
- ld_string_t *ostr = NULL;
- isc_buffer_t buffer;
-
- REQUIRE(dn != NULL);
-
- INIT_BUFFERED_NAME(name);
- CHECK(str_new(mctx, str));
-
- if (otarget != NULL) {
- INIT_BUFFERED_NAME(origin);
- CHECK(str_new(mctx, ostr));
- }
-
- CHECK(dn_to_text(dn, str, ostr));
- str_to_isc_buffer(str, buffer);
- CHECK(dns_name_fromtext(name, buffer, NULL, 0, NULL));
-
- if (otarget != NULL) {
- str_to_isc_buffer(ostr, buffer);
- CHECK(dns_name_fromtext(origin, buffer, NULL, 0, NULL));
- }
-
-cleanup:
- if (result == ISC_R_SUCCESS)
- result = dns_name_dupwithoffsets(name, mctx, target);
- else
- log_error_r(failed to convert dn %s to DNS name, dn);
-
- if (otarget != NULL result == ISC_R_SUCCESS)
- result = dns_name_dupwithoffsets(origin, mctx, otarget);
-
- if (result != ISC_R_SUCCESS) {
- if (dns_name_dynamic(target))
- dns_name_free(target, mctx);
- if (otarget) {
- if (dns_name_dynamic(otarget))
-dns_name_free(otarget, mctx);
- }
- }
-
- str_destroy(str);
- if (otarget != NULL)
- str_destroy(ostr);
-
- return result;
-}
-
/**
- * Convert LDAP DN to absolute DNS name.
+ * Convert LDAP DN to absolute DNS names.
*
* @param[in] dn LDAP DN with one or two idnsName components at the
*beginning.
- * @param[out] target Absolute DNS name derived from the all idnsNames.
+ * @param[out] target Absolute DNS name derived from the first two idnsNames.
* @param[out] origin Absolute DNS name derived from the last idnsName
*component of DN, i.e. zone. Can be NULL.
*
* @code
* Examples:
- * dn = idnsName=foo, idnsName=bar, idnsName=example.org,
- * cn=dns, dc=example, dc=org
+ * dn = idnsName=foo.bar, idnsName=example.org., cn=dns, dc=example, dc=org
* target = foo.bar.example.org.
* origin = example.org.
*
- * dn = idnsname=89, idnsname=4.34.10.in-addr.arpa.,
- * cn=dns, dc=example, dc=org
+ * dn = idnsname=89, idnsname=4.34.10.in-addr.arpa, cn=dns, dc=example, dc=org
* target = 89.4.34.10.in-addr.arpa.
* origin = 4.34.10.in-addr.arpa.
- * (The dot at the end is not doubled when it's already present.)
+ *
+ * dn = idnsname=third.test., idnsname=test., cn=dns, dc=example, dc=org
+ * target = third.test.
+ * origin = test.
* @endcode
*/
isc_result_t
-dn_to_text(const char *dn, ld_string_t *target, ld_string_t *origin)
+dn_to_dnsname(isc_mem_t *mctx, const char *dn_str, dns_name_t *target,
+ dns_name_t *otarget)
{
+ LDAPDN dn = NULL;
+ LDAPRDN rdn = NULL;
+ LDAPAVA *attr = NULL;
+ int idx;
+ int ret;
+
+ DECLARE_BUFFERED_NAME(name);
+ DECLARE_BUFFERED_NAME(origin);
+ isc_buffer_t name_buf;
+ isc_buffer_t origin_buf;
isc_result_t result;
- char **exploded_dn = NULL;
- char **exploded_rdn = NULL;
- unsigned int i;
- REQUIRE(dn != NULL);
+ REQUIRE(dn_str != NULL);
REQUIRE(target != NULL);
- CHECK(explode_dn(dn, exploded_dn, 0));
- str_clear(target);
- for (i = 0; exploded_dn[i] != NULL; i++) {
- if (strncasecmp(exploded_dn[i], idnsName, 8) != 0)
+ INIT_BUFFERED_NAME(name);
+ INIT_BUFFERED_NAME(origin);
+ isc_buffer_initnull(name_buf);
+ isc_buffer_initnull(origin_buf);
+
+ /* Example DN: cn=a+sn=b, ou=people */
+
+ ret = ldap_str2dn(dn_str, dn, LDAP_DN_FORMAT_LDAPV3);
+ if (ret != LDAP_SUCCESS || dn == NULL) {
+ log_bug(ldap_str2dn failed: %u, ret);
+ CLEANUP_WITH(ISC_R_UNEXPECTED);
+ }
+
+ /* iterate over DN components: e.g. cn=a+sn=b */
+ for (idx = 0; dn[idx] != NULL; idx++) {
+ rdn = dn[idx];
+
+ /* iterate over RDN components:
Re: [Freeipa-devel] Multi-master replication with puppet
On Fri, 2014-06-06 at 15:10 +0200, Jan Pazdziora wrote: On Fri, Jun 06, 2014 at 08:51:39AM -0400, Simo Sorce wrote: Clearly puppet has root level access to the system so you do not (should not ?) care much about preventing access to these systems, the aim is to not inadvertently divulge secrets through manifests and nothing else. And puppet logs. And forgetting the secrets around. Right... A good reason to not store anything in puppet. With puppet you do not have interactive (password) prompt available so everything including secrets needs to be pre-created and pre-populated before the puppet apply starts. Or, where possible, generated and immediatelly encrypted -- I find that approach very clever. Thanks :) But unfortunately it can only be used for the initial FreeIPA server installation, it seems -- in all the subsequent operations, we need to pass the existing matching credential. Right... This is what I'm trying to work around. I only need this for additional replicas. The single master case is basically *solved*. But it's no fun to stop there... I wonder if we could be able to pass the passwords to puppet via file descriptors from some invoking wrapper ... See my comment on: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ about an interactive password helper. This could be useful for something when puppet-freeipa is being used with other tools that insist on telling it the password... Functionally the issues with the replicas don't dissapear. We have to pretend that the password is still forgotten after initial install of first master. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly
On 6/6/2014 10:43 AM, Petr Vobornik wrote:
On 6.6.2014 15:45, Endi Sukma Dewata wrote:
On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote:
ACK for patches #592-#628. I'll continue reviewing the rest.
ACK for patches #633-639, #642, #644, #652, and #653. Patches #640
#641 have an issue (see #19 below) that should be fixed before pushing.
Other issues are minor/unrelated/suggestions that can be addressed
separately.
Thank you for the review.
I've fixed issues:
- #19, #20 in patch #640.
And some low hanging fruit:
- #16, in patch #637
- #17, in patch #612
- #13, in patch #612
The branch has been rebased to current master.
ACK.
I am not able to reproduce issues #4 and #11.
4. In the list page (e.g. Users) in mobile mode the Refresh button may overlap
the search box.
Here's what I saw as I was adjusting the page width:
http://edewata.fedorapeople.org/ipa/images/snapshot1.png
http://edewata.fedorapeople.org/ipa/images/snapshot2.png
http://edewata.fedorapeople.org/ipa/images/snapshot3.png
Notice that in snapshot #2 the search box is partially covered by the
Refresh button.
11. In desktop mode the QR code for new OTP token is displayed outside the
dialog box.
Here's what I saw:
http://edewata.fedorapeople.org/ipa/images/snapshot4.png
18. In the New Certificate dialog for Host, the instruction to create a
CSR exceeds the dialog boundary.
caused by BS' CSS:
code {
white-space: nowrap;
}
I wonder if the best solution is to reset it to initial value in all
dialogs.
Alternatively, the sample command could be broken into two lines.
20. The capitalization of Certificate is inconsistent in Host's and
Service's Actions.
Fixed
The View certificate is still inconsistent though.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multi-master replication with puppet
On Fri, 2014-06-06 at 14:06 -0400, James wrote: On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote: Yes, the dm_password was chosen because it is needed to actually initialize and install the replica, so instead of asking it twice we just ask for it once and use it *also* to encrypt the prepared file. But the password is still currently absolutely necessary. Okay... But it's only needed for encryption on replica-prepare side, right? We use it to encrypt the package and also to check that it is indeed the correct password by performing a successful bind to LDAP. I think we may be using it also to generate the certificates for the replica, but I haven't looked at that code for a while and may be remembering incorrectly. But let me ask a more important question, how do you distribute the public keys securely ? Is it puppet fetching them from each replica-to-be server and sending them to the first master server ? Yes. That is one approach. What did you have in mind ? It is also needed to actually store the DM password on the replica server itself in it's own cn=Directory Manager super user entry. Although I think we could send the hash for that. This is what I was thinking... I'll need to know how to extract this, send it (encrypted), and use it instead of --password It might be greppable out of the dse.ldif file I think. I would need some help to find an alternative for this process. As was suggested, perhaps a one-time password could be generated and sent across the wire (with puppet) to the replica. Any mechanism that doesn't need the dm_password would be great. Forget custom schemes. The simplest way to handle this (which I wanted to do for a while) is to pre-create the replica's LDAP principal and keys at replica-prepare time so we can start right away with GSSAPI authentication for the first replication and create agreements directly using GSSAPI auth. This would in turn simplify replication agreements creation as we won't need anymore to do the dance where we create the agreement with a plain text bind and then we need to convert the agreement to use GSSAPI. This of course sounds fine to me. As long as it meets my criteria of not needing the password, it should work. Is this an easy patch? IOW something that I could test a build of within the next month at the latest? Well, you may not need a password (you do because you need to be DM on the replica to create replication agreements, but we can do some magic there and use ldapi as root I guess) but you'll need a keytab, which is a secret, just like a password and must not be exposed to anyone and anything just like the DM password. But that wouldn't be a problem, the keytab would be in the encrypted prepared file. I don't think there is any other need for the dm_password in ipa-replica-install. Did I miss something? See above, it needs the password to actually create the DM account at DS setup time. *also* the DM password is used to setup some parts of the dogtag CA so if any of your replica is also a CA clone you go straight back to needing the DM password. Which I understand we could get around by passing around the (salted?) hashed password, correct? Not for the CA, unfortunately the CA requires the DM password in the clear. Of course if I store the dm_password in puppet, then it's easy to do this peering because it will be easy to use the password on each host. I could be done my puppet module already :) But I'm going out of my way to do it right, so that you'll all be proud of the work too! Ok, here is a quickest method to do what you want to do IMO: First of all, you need a DM password for the initial server and you need to store it somewhere because the admin must know what it is, there is no way around this. So I guess you are planning to store it in a file under /root in the master server or something like that. This means puppet has access to the DM password w/o storing it in the manifest. Wrong. The whole idea is I want to keep puppet's grubby hands off the password. I generate the password on the host, encrypt it with the admin's public key, and never store it unencrypted. More details here: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ Sure, I do not mean that puppet needs to transport it in the clear, but it gets to know it in the abstract, either because it generates it (on the ipa server) or because it transports it (encrypted) and unpacks it in the replicas. But the fact is a certain points it must have access to it to do the initial install. Use the DM password to do everything as usual AND create the asymmetric keys in the replicas and *securely* transmit them to the master. Keep in mind I'm only transmitting public keys, so it doesn't have to be secure as long as I know verify the identity. Bt. How do I know that these are the public key
