[Freeipa-devel] Is CA certificate storage correct?
Hi there, I checked the update CA Certificate renewal feature design page and one part seemed awkward to me: http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store IIUC, when there are multiple iterations of a certificate stored, there will be one LDAP object with multiple cACertificate attributes, multiple ipaKeyUsage attributes, ipaKeyTrust, ... Given that LDAP does not guarantee order, how do I identify which cACertificate belongs to which attribute? If I do ldapsearch for some specific ipaKeyUsage and I get this LDAP record returned, how do I find out which certificate it is? Do I need to go through all binary blobs, parse them and look which blob matches? Wouldn't it be better to have just one LDAP entry with one blob, one ipaKeyUsage, ...? I think it would be then much easier manipulated, LDAP-wise. Maybe we could store certificates with a timestamp like following? cn=auditCert-20130520,cn=certificates,cn=ipa,cn=etc,suffix ... cn=auditCert-20140520,cn=certificates,cn=ipa,cn=etc,suffix ... Would it be easier to manipulate? -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
On 05/19/2014 03:19 PM, Petr Viktorin wrote: > Hello list, > Here's a conversation that started internally. I'm making it public. > > On 05/19/2014 01:00 PM, Martin Kosek wrote: >> On 05/19/2014 12:46 PM, Petr Viktorin wrote: >>> On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: > On 05/16/2014 04:48 PM, thierry bordaz wrote: >> Hello Martin, >> >> I am getting familiar with the freeipa CLI code and started >> implemented '--to-stage' and '--from-stage'. This really an >> impressive set of code :-) > > Great! :-) > >> I completed 'to-stage' and testing '--from-stage'. >> >> I have a question regarding the '--from-stage' syntax. 'uid' is a >> mandatory argument to 'user-add' subcommand. In the design the >> '--from-stage' option is described with: >> >> ipa user-add --from-stage=tuser > > Note, the design is here: > http://www.freeipa.org/page/V4/User_Life-Cycle_Management > >> But as 'uid' is mandatory the command should rather be >> >> ipa user-add tuser --from-stage=tuser >> >> In that case the option value for '--from-stage' is not required and >> the command should be >> >> ipa user-add tuser --from-stage >> >> Is that ok if I implement the command like above or did I miss >> something ? >> >> regards >> thierry > > Hmm, no, I think you are right. We can change --from-stage to just Bool > parameter. When it is true, it'd mean that get_dn or pre-callback should > retrieve the record from stage and use all it's attributes (and add > standard > default attributes values on top of that). > > Also CC-ing Petr Viktorin for reference. >>> >>> This operation can't change the user's attributes, can it? I.e., we don't >>> support something like: >>> ipa user-add tuser --from-stage --phone=123456789 >>> --email=newem...@example.com >>> If this is the case, what's the reason for using user-add for this? >>> Wouldn't it >>> be better to make this a separate command, say: >>> ipa user-activate tuser >>> ipa user-activate tuser --from-deleted >>> ipa user-activate tuser --from-deleted --to-staged >> >> user-add command does a lot of additional processing besides just taking the >> values and writing them to LDAP. It fills the UID and GID, sets the >> non-filled >> default attributes like Kerberos attributes, adds user as a member of >> ipausers >> groups - all that stuff. The same procedures should be also done with the >> user >> from stage. This is why I proposed to augment user-add. >> >> If there is a better way, I am open to it. > > That's not a very good reason to bring in all the CLI/API options, most > importantly from the user's perspective. Also you'd have to write extra code > to > e.g. check the user didn't use the other options, and that tends to get messy > quite fast. > > The common processing should be split out into functions* that both commands > would call. > (Or methods of the `user` object, which may turn out to be more practical.) Ok, that makes sense - let us make separate commands. Thierry, can you please update the design page on the wiki to match the new proposal? You should be able to log in with your Fedora account. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
On 05/19/2014 04:44 PM, Jan Cholasta wrote: On 19.5.2014 16:34, thierry bordaz wrote: On 05/19/2014 04:22 PM, Jan Cholasta wrote: On 19.5.2014 16:03, thierry bordaz wrote: On 05/19/2014 03:54 PM, Jan Cholasta wrote: On 19.5.2014 15:19, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged +1, I would even go as far as having separate commands for staged and deleted users, e.g.: ipa user-unstage tuser ipa user-undelete tuser ipa user-undelete tuser --to-staged A deleted entry has already been active so it contains already set attributes while the pure staged entries are "almost" empty boxes. But from an administrator point of view, both staged/deleted entries are inactive. What would be the advantages of two separated commands ? You just said it yourself: activating/unstaging a user is quite different from undeleting a user. Cramming multiple different operations in a single command is bad design IMHO. Ok I understand. I believe that deleted entries and staged entries will be in the same container (provisioning). The design page mentions "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX" and "cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX", which are two different containers. Oppsss.. Sorry for the confusion :-[ So we may have at least those two possibilities: * ipa user-activate tuser [--from-staging|--from-delete] * ipa user-unstage tuser ipa user-undelete tuser user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
On 19.5.2014 16:34, thierry bordaz wrote: On 05/19/2014 04:22 PM, Jan Cholasta wrote: On 19.5.2014 16:03, thierry bordaz wrote: On 05/19/2014 03:54 PM, Jan Cholasta wrote: On 19.5.2014 15:19, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged +1, I would even go as far as having separate commands for staged and deleted users, e.g.: ipa user-unstage tuser ipa user-undelete tuser ipa user-undelete tuser --to-staged A deleted entry has already been active so it contains already set attributes while the pure staged entries are "almost" empty boxes. But from an administrator point of view, both staged/deleted entries are inactive. What would be the advantages of two separated commands ? You just said it yourself: activating/unstaging a user is quite different from undeleting a user. Cramming multiple different operations in a single command is bad design IMHO. Ok I understand. I believe that deleted entries and staged entries will be in the same container (provisioning). The design page mentions "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX" and "cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX", which are two different containers. So we may have at least those two possibilities: * ipa user-activate tuser [--from-staging|--from-delete] * ipa user-unstage tuser ipa user-undelete tuser user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
On 05/19/2014 04:22 PM, Jan Cholasta wrote: On 19.5.2014 16:03, thierry bordaz wrote: On 05/19/2014 03:54 PM, Jan Cholasta wrote: On 19.5.2014 15:19, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged +1, I would even go as far as having separate commands for staged and deleted users, e.g.: ipa user-unstage tuser ipa user-undelete tuser ipa user-undelete tuser --to-staged A deleted entry has already been active so it contains already set attributes while the pure staged entries are "almost" empty boxes. But from an administrator point of view, both staged/deleted entries are inactive. What would be the advantages of two separated commands ? You just said it yourself: activating/unstaging a user is quite different from undeleting a user. Cramming multiple different operations in a single command is bad design IMHO. Ok I understand. I believe that deleted entries and staged entries will be in the same container (provisioning). So we may have at least those two possibilities: * ipa user-activate tuser [--from-staging|--from-delete] * ipa user-unstage tuser ipa user-undelete tuser user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
On 19.5.2014 16:03, thierry bordaz wrote: On 05/19/2014 03:54 PM, Jan Cholasta wrote: On 19.5.2014 15:19, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged +1, I would even go as far as having separate commands for staged and deleted users, e.g.: ipa user-unstage tuser ipa user-undelete tuser ipa user-undelete tuser --to-staged A deleted entry has already been active so it contains already set attributes while the pure staged entries are "almost" empty boxes. But from an administrator point of view, both staged/deleted entries are inactive. What would be the advantages of two separated commands ? You just said it yourself: activating/unstaging a user is quite different from undeleting a user. Cramming multiple different operations in a single command is bad design IMHO. user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
On 05/19/2014 03:54 PM, Jan Cholasta wrote: On 19.5.2014 15:19, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged +1, I would even go as far as having separate commands for staged and deleted users, e.g.: ipa user-unstage tuser ipa user-undelete tuser ipa user-undelete tuser --to-staged A deleted entry has already been active so it contains already set attributes while the pure staged entries are "almost" empty boxes. But from an administrator point of view, both staged/deleted entries are inactive. What would be the advantages of two separated commands ? user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0455 Replace "replica admins read access" ACI with a permission
On 05/16/2014 02:30 PM, Martin Kosek wrote:
On 04/30/2014 05:16 PM, Petr Viktorin wrote:
This should fix https://fedorahosted.org/freeipa/ticket/3829
You mistakenly assigned the permission to all authenticated users. When I
changed bind type from "all" to "permission", it gave the expected and correct
results.
Admin user was no longer able to see other but allowed config settings.
Thanks for the catch. Updated patch attached.
--
Petr³
From 6de87553554ce4ac7e24588a3085a640cb1e64e9 Mon Sep 17 00:00:00 2001
From: Petr Viktorin
Date: Mon, 28 Apr 2014 14:23:19 +0200
Subject: [PATCH] Replace "replica admins read access" ACI with a permission
Add a 'Read Replication Agreements' permission to replace
the read ACI for cn=config.
https://fedorahosted.org/freeipa/ticket/3829
---
install/share/replica-acis.ldif| 5 --
install/updates/20-aci.update | 5 ++
.../install/plugins/update_managed_permissions.py | 61 ++
3 files changed, 66 insertions(+), 5 deletions(-)
diff --git a/install/share/replica-acis.ldif b/install/share/replica-acis.ldif
index f4e96139f356826b1c6e07f7dfdfad2de42aafbd..8c0bc8ec3826a57ee531726cfeec2789484a3032 100644
--- a/install/share/replica-acis.ldif
+++ b/install/share/replica-acis.ldif
@@ -1,10 +1,5 @@
# Replica administration
-dn: cn=config
-changetype: modify
-add: aci
-aci: (targetattr != aci)(version 3.0; aci "replica admins read access"; allow (read, search, compare) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permissions,cn=pbac,$SUFFIX";)
-
dn: cn="$SUFFIX",cn=mapping tree,cn=config
changetype: modify
add: aci
diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index d9dcad2e572ab72ff793c41a4300562caead6c77..f31c2017796d17ab988f0426fa2e6617bbc50062 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -46,3 +46,8 @@ dn: $SUFFIX
add:aci:'(targetfilter = "(objectClass=krbPwdPolicy)")(targetattr = "krbMaxPwdLife || krbMinPwdLife || krbPwdMinDiffChars || krbPwdMinLength || krbPwdHistoryLength")(version 3.0;acl "Admins can write password policies"; allow (read, search, compare, write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;)'
# Read-only
add:aci:'(targetattr="ipaUniqueId || memberOf || enrolledBy || krbExtraData || krbPrincipalName || krbCanonicalName || krbPasswordExpiration || krbLastPwdChange || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount")(version 3.0; acl "Admin read-only attributes"; allow (read, search, compare) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;)'
+
+# Removal of obsolete ACIs
+dn: cn=config
+# Replaced by 'System: Read Replication Agreements'
+remove:aci: '(targetattr != aci)(version 3.0; aci "replica admins read access"; allow (read, search, compare) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permissions,cn=pbac,$SUFFIX";)'
diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index bffd9bbf434e76c9c6d74d0167a718acc96a54b1..92e5d963b6be35784825bf565da4e7e3ccda1d6e 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/install/plugins/update_managed_permissions.py
@@ -155,6 +155,67 @@
'ipantdomainguid', 'ipantfallbackprimarygroup',
},
},
+'System: Read Replication Agreements': {
+'ipapermlocation': DN('cn=config'),
+'ipapermtargetfilter': {
+'(|'
+'(objectclass=nsds5Replica)'
+'(objectclass=nsds5replicationagreement)'
+'(objectclass=nsDSWindowsReplicationAgreement)'
+'(objectClass=nsMappingTree)'
+')'
+},
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass',
+# nsds5Replica
+'nsds5replicaroot', 'nsds5replicaid', 'nsds5replicacleanruv',
+'nsds5replicaabortcleanruv', 'nsds5replicatype',
+'nsds5replicabinddn', 'nsstate', 'nsds5replicaname',
+'nsds5flags', 'nsds5task', 'nsds5replicareferral',
+'nsds5replicaautoreferral', 'nsds5replicapurgedelay',
+'nsds5replicatombstonepurgeinterval', 'nsds5replicachangecount',
+'nsds5replicalegacyconsumer', 'nsds5replicaprotocoltimeout',
+'nsds5replicabackoffmin', 'nsds5replicabackoffmax',
+# nsds5replicationagreement
+'nsds5replicacleanruvnotified', 'nsds5replicahost',
+'nsds5replicaport', 'nsds5replicatransportinfo',
+'nsds5replicabinddn', 'nsds5replicacredentials',
+'nsds5replicabindmethod', 'nsds5replicaroot',
+'nsds5replicatedattributelist',
+'nsds5replicatedattributelisttotal', 'nsds5replicaupdateschedule',
+'nsds5beginreplicarefresh', 'description', 'nsds50ruv',
+
Re: [Freeipa-devel] Status/Question about User life cycle
On 19.5.2014 15:19, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged +1, I would even go as far as having separate commands for staged and deleted users, e.g.: ipa user-unstage tuser ipa user-undelete tuser ipa user-undelete tuser --to-staged user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI
On 05/16/2014 02:00 PM, Martin Kosek wrote: On 04/29/2014 11:02 PM, Petr Viktorin wrote: I didn't test this as much as I'd like to, but it might come in handy when testing my earlier patches. The ACI is removed in the managed permissions plugin because I want to make sure it's done after all the managed permission updates, which query it. It worked in my case (I tested upgrade from 3.3.5). What do we do about other permissions we will want to remove? I am talking about following ACIs: - no anonymous access to roles - no anonymous access to sudo - no anonymous access to hbac - no anonymous access to member information I would like to remove them in 544 as well as otherwise they would bias the testing. Right. Here is the updated patch. -- Petr³ From 316605f6aa5f487b2845bc3abc3d9e029b60bd0a Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Tue, 29 Apr 2014 21:46:26 +0200 Subject: [PATCH] Remove the global anonymous read ACI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Also remove - the deny ACIs that implemented exceptions to it: - no anonymous access to roles - no anonymous access to member information - no anonymous access to hbac - no anonymous access to sudo (2Ã) - its updater plugin Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 --- install/share/default-aci.ldif | 13 --- install/share/delegation.ldif | 5 -- install/updates/20-aci.update | 13 +++ install/updates/60-trusts.update | 1 - ipaserver/install/plugins/update_anonymous_aci.py | 96 -- .../install/plugins/update_managed_permissions.py | 19 + 6 files changed, 32 insertions(+), 115 deletions(-) delete mode 100644 ipaserver/install/plugins/update_anonymous_aci.py diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index 480facf3294c593c6a2bcf326e20c32157d6d3c6..04fc185f785ee71246c6cc4f958c754158f16302 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -3,10 +3,7 @@ dn: $SUFFIX changetype: modify add: aci -aci: (targetfilter = "(&(!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenHOTP))(!(objectClass=ipatokenRadiusConfiguration)))")(target != "ldap:///idnsname=*,cn=dns,$SUFFIX";)(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";;) -aci: (targetattr = "memberOf || memberHost || memberUser")(version 3.0; acl "No anonymous access to member information"; deny (read,search,compare) userdn != "ldap:///all";;) aci: (targetattr = "userpassword || krbprincipalkey || sambalmpassword || sambantpassword")(version 3.0; acl "selfservice:Self can write own password"; allow (write) userdn="ldap:///self";;) -aci: (targetattr = "*")(target = "ldap:///cn=*,ou=SUDOers,$SUFFIX";)(version 3.0; acl "No anonymous access to sudo"; deny (read,search,compare) userdn != "ldap:///all";;) dn: $SUFFIX changetype: modify @@ -65,16 +62,6 @@ dn: cn=computers,cn=accounts,$SUFFIX add: aci aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX";)(version 3.0;acl "Admins can manage host keytab";allow (write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";;) -dn: cn=hbac,$SUFFIX -changetype: modify -add: aci -aci: (targetattr = "*")(version 3.0; acl "No anonymous access to hbac"; deny (read,search,compare) userdn != "ldap:///all";;) - -dn: cn=sudo,$SUFFIX -changetype: modify -add: aci -aci: (targetattr = "*")(version 3.0; acl "No anonymous access to sudo"; deny (read,search,compare) userdn != "ldap:///all";;) - # This is used for the host/service one-time passwordn and keytab indirectors. # We can do a query on a DN to see if an attribute exists. dn: cn=accounts,$SUFFIX diff --git a/install/share/delegation.ldif b/install/share/delegation.ldif index 7bd4e1e2d93b1dde4122ad1bfbe889625d983544..43d13974ffd63ea6ee554c815b911715609149b8 100644 --- a/install/share/delegation.ldif +++ b/install/share/delegation.ldif @@ -580,11 +580,6 @@ dn: $SUFFIX dn: $SUFFIX changetype: modify add: aci -aci: (targetattr = "*")(target = "ldap:///cn=*,cn=roles,cn=accounts,$SUFFIX";)(version 3.0; acl "No anonymous access to roles"; deny (read,search,compare) userdn != "ldap:///all";;) - -dn: $SUFFIX -changetype: modify -add: aci aci: (target = "ldap:///cn=*,cn=roles,cn=accounts,$SUFFIX";)(version 3.0;acl "permission:Add Roles";allow (add) groupdn = "ldap:///cn=Add Roles,cn=permissions,cn=pbac,$SUFFIX";) aci: (target = "ldap:///cn=*,cn=roles,cn=accounts,$SUFFIX";)(version 3.0;acl "permission:Remove Roles";allow (delete) groupdn = "ldap:///cn=Remove Roles,cn=permissions,cn=pbac,$SUFFIX";) aci: (ta
Re: [Freeipa-devel] Status/Question about User life cycle
On 05/19/2014 03:19 PM, Petr Viktorin wrote: Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) On 05/19/2014 01:01 PM, thierry bordaz wrote: Hello Petr, The command moves an entry from staging to 'users'. When doing this there are the following added values: objectClass: mepOriginEntry mepManagedEntry: cn=titi,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com I guess it is the effect of a plugin because the command by itself just does a modrdn. I agree with you, the design present this operation (staging-> 'users') as activating an account. It would make sense to use the 'user-activate' verb rather than 'user-add' as the entry is already added. So if we want to modify an entry that is still in staging, would we need a '--to-stage' for the user-mod command ? If the uids are unique we don't technically need it, but requiring it may still be a good idea, just to make sure the admin knows what they're doing. Code-wise it'll definitely be easier to require the option, and it'll most likely also be a bit better for performance. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
Hello list, Here's a conversation that started internally. I'm making it public. On 05/19/2014 01:00 PM, Martin Kosek wrote: On 05/19/2014 12:46 PM, Petr Viktorin wrote: On 05/19/2014 08:25 AM, Martin Kosek wrote: On 05/19/2014 08:24 AM, Martin Kosek wrote: On 05/16/2014 04:48 PM, thierry bordaz wrote: Hello Martin, I am getting familiar with the freeipa CLI code and started implemented '--to-stage' and '--from-stage'. This really an impressive set of code :-) Great! :-) I completed 'to-stage' and testing '--from-stage'. I have a question regarding the '--from-stage' syntax. 'uid' is a mandatory argument to 'user-add' subcommand. In the design the '--from-stage' option is described with: ipa user-add --from-stage=tuser Note, the design is here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management But as 'uid' is mandatory the command should rather be ipa user-add tuser --from-stage=tuser In that case the option value for '--from-stage' is not required and the command should be ipa user-add tuser --from-stage Is that ok if I implement the command like above or did I miss something ? regards thierry Hmm, no, I think you are right. We can change --from-stage to just Bool parameter. When it is true, it'd mean that get_dn or pre-callback should retrieve the record from stage and use all it's attributes (and add standard default attributes values on top of that). Also CC-ing Petr Viktorin for reference. This operation can't change the user's attributes, can it? I.e., we don't support something like: ipa user-add tuser --from-stage --phone=123456789 --email=newem...@example.com If this is the case, what's the reason for using user-add for this? Wouldn't it be better to make this a separate command, say: ipa user-activate tuser ipa user-activate tuser --from-deleted ipa user-activate tuser --from-deleted --to-staged user-add command does a lot of additional processing besides just taking the values and writing them to LDAP. It fills the UID and GID, sets the non-filled default attributes like Kerberos attributes, adds user as a member of ipausers groups - all that stuff. The same procedures should be also done with the user from stage. This is why I proposed to augment user-add. If there is a better way, I am open to it. That's not a very good reason to bring in all the CLI/API options, most importantly from the user's perspective. Also you'd have to write extra code to e.g. check the user didn't use the other options, and that tends to get messy quite fast. The common processing should be split out into functions* that both commands would call. (Or methods of the `user` object, which may turn out to be more practical.) -- Petr³ ___ 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 12.5.2014 17:46, Misnyovszki Adam wrote: Hi, see my review notes below: On Mon, 05 May 2014 18:41:13 +0200 Petr Vobornik wrote: This patchset updates Bootstrap 2 based RCUE to Bootstrap 3 based PatternFly (v0.2.4) according to plan described at: http://www.redhat.com/archives/freeipa-devel/2014-April/msg00045.html The rest of the patches are mostly response to new CSS styles + some new functionality and simplification of UI: - css cleanup, images cleanup - adjustment of stand-alone pages to PF - adjustment of DOM structure to Bootstap 3 structure - BS 3 enabled to change absolute positioned layout to responsive fluid layout - new activity indicators (since the old didn't fit into PF navigation) - new pager styles + additional behavior - action select transform into dropdown and moved to control-button section, making the header responsive - fluid layout requested removal of computation of columns widths - removal of login.html and logout.html - new login background (the old one did not work with PF styles) - new dialog styles - + additional adjustments to use PF The result is that UI uses most of PatternFly styles and is responsive. Fixes: https://fedorahosted.org/freeipa/ticket/4177 - Better indication of ongoing activity if dialog is opened - working progress could have a border. if it is over a dialog, sometimes it looks messy over text Fixed https://fedorahosted.org/freeipa/ticket/4136 - WebUI unusable on Cellphone screen - when I open the menu in 320x480, and select and navigate to an item, the menu stays open - needs more investigation, if it is freeipa ui issue Fixed - qr code is fixed size in otp tokens, doesn't look nice on small screens not a problem, user just clicks on qr code link Fixed - when a table header is longer, than the actual screen size, overflow hidden occurs, unable to use buttons at the end of the header eg DNS Resource Records, 320x480px, sometimes delete and add button overflows the table, you can only scroll that table with tap not a problem, responsive table works this way I did not encounter overflow hidden issue - scrollbars were present and I could scroll to the icons. - in 320x480, login page configuration text overflows on a white background, especially if there is a login error, which makes the white text unreadable Behavior was improved. https://fedorahosted.org/freeipa/ticket/4255 - Web UI: Display "Loading" message when a list of entries is being loaded see working progress comment above https://fedorahosted.org/freeipa/ticket/3435 - [RFE] Remove width limit in UI ACK - PatternFly 3 handles this very neatly https://fedorahosted.org/freeipa/ticket/3050 - WebUI: it is not clear which row a value belongs to ACK - row color alternation hopefully solves the problem https://fedorahosted.org/freeipa/ticket/4278 - Use Patternfly theme in config and migration pages FreeIPA logo doesn't lead anywhere, no way to navigate to the login page, only by altering the url, or clicking the back button. IMO logo should always lead to login page if not logged in. Logo now points to UI https://fedorahosted.org/freeipa/ticket/4281 - Remove login.html and logout.html ACK https://fedorahosted.org/freeipa/ticket/4282 Other issues: - unit tests have several fails, possibly because of dom changes Fixed - integration tests ran without errors Also, according to the UX meeting with Kyle, this patchset should include the following changes: - placeholder for search, box should be on the left - actions in one place, on the right in search page - actions in one place, on the left in details page - action dropdown list to the right near update button in details page - left align form fields in details page, two columns arrangement if the screen is wide - hbac details pages - leave it as it is, no form modification required - association adder dialog - placeholder for textbox(Filter available), change button text "Filter" - search page title should be changed - use dark variant text - multi value list - "add" to button, with "undo all" button group - multi value list - "delete" should be also a button - left align firefox configuration page steps - ie. every static page - migration should look like login, (~reset_password), text should go to right - error page "return back" should be a button All fixed Thanks Adam The suggestions found by UX review resulted in additional 10 new commits (patch numbers 633-642): I think, that we should switch from patch files to my git branch to avoid sending 1-2MB of patches in each review cycle. http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=patternfly To be exact: git log --pretty=format:%s -47 642 webui: use normal buttons instead of link buttons in multivalued widget 641 webui: move service action panel actions to action dropdown 640 webui: move host action panel actions to
