From rcritten at redhat.com Thu May 1 14:03:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 May 2014 10:03:55 -0400 Subject: [Freeipa-devel] [PATCHES] 0546-0547 Allow alternate "aci" keyword in ACIs In-Reply-To: <53613FDF.6040406@redhat.com> References: <53612455.3000702@redhat.com> <53613224.9080805@redhat.com> <53613FDF.6040406@redhat.com> Message-ID: <5362544B.4040207@redhat.com> Petr Viktorin wrote: > On 04/30/2014 07:25 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Hello, >>> The first patch adds "==" to ACI object to simplify comparisons. >>> The second patch moves existing "tests" to the test suite. >>> >>> The third patch adds support for an alternate "aci" keyword that DS >>> supports (but I couldn't get any documentaion on it). Dogtag adds ACIs >>> with this keyword to cn=config, so we'll need this fix when parsing ACIs >>> there. >>> >>> >>> Rob, you wrote the parser; does this look OK to you? >>> >> >> ACK. >> >> Only minor quibble is you left a couple of print statements in the tests. > > Those are intentional. When a failed test prints something, Nose shows > the output. It's pretty nice for debugging. Ok. > >> As you note, I had some "tests" that I ran when I was implementing the >> aci module. Moving these to formal testing is definitely the right thing >> to do. >> >> I do wonder one thing though. In the equality test I had reversed some >> ordering of things to ensure that things were normalized in the same >> way. For the check_aci_parsing() tests is it worth considering doing >> something similar? > > I'm not sure I follow; what part are you referring to? > > The ordering is problematic for sure; everything relies on dict order. > That's the main reason why in my work I only use this class to parse > ACIs, and I made a stable routine for generating them. > > Until we start running the tests with PYTHONHASHSEED=random, I figured > we can just use them as they are. Ok. I had some vague memory I had stuck a sort() in there to not rely on dict ordering, maybe that was just an intention. > >> I noticed that we are apparently not normalizing target filters because >> there is a space in the DN. Something for later. > > Or not; I'd like to get rid of the export_to_string part completely. > >> There is no ticket. Probably fine since this is mostly just shuffling >> deck chairs. > > Yeah, same thinking here. It's part of the general ACI work. > Alright, push away then. rob From rmeggins at redhat.com Thu May 1 14:10:41 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 01 May 2014 08:10:41 -0600 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <5361229A.7030303@redhat.com> References: <5361229A.7030303@redhat.com> Message-ID: <536255E1.6060305@redhat.com> On 04/30/2014 10:19 AM, Petr Spacek wrote: > Hello list, > > following text summarizes schema & DIT layout for DNSSEC key storage > in LDAP. > > This is subset of full PKCS#11 schema [0]. It stores bare keys with > few metadata attributes when necessary. > > The intention is to make transition to full PKCS#11-in-LDAP schema [0] > as easy as possible. This transition should happen in next minor > version of FreeIPA. > > In theory, the transition should be just adding few object classes to > existing objects and populating few new metadata attributes. Related > object classes are marked below with "(in long-term)". > > Please comment on it soon. We want to implement it ASAP :-) > > > DNSSEC key > ========== > - Asymmetric > - Private key is stored in LDAP as encrypted PKCS#8 blob > - Public key is published in LDAP > - Encrypted with symmetric "DNSSEC master key" (see below) > - Private key - represented as LDAP object with object classes: > ipaEPrivateKey [1] # encrypted data > ipaWrappedKey [2] # pointer to master key, outside scope of pure > PKCS#11 > ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata > - Public key - represented as LDAP object with object classes: > ipaPublicKey [1] # public key data > ipk11PublicKey [3] (in long-term) # PKCS#11 metadata > > > Master key > ========== > - Symmetric > - Stored in LDAP as encrypted blob > - Encrypted with asymmetric "replica key" (see below) > - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys > - A replica uses it's own key for master key en/decryption > - Represented as LDAP object with object classes: > ipaESecretKey [1] > ipk11SecretKey [3] (in long-term) > > Replica key > =========== > - Asymmetric > - Private key is stored on replica's disk only > - Public key for all replicas is stored in LDAP > - Represented as LDAP object with object classes: > ipaPublicKey [1] > ipk11PublicKey [3] (in long-term) > > > DIT layout > ========== > DNSSEC key material > ------------------- > - Container: cn=keys, cn=sec, cn=dns, dc=example > - Private and public keys are stored as separate objects to > accommodate all PKCS#11 metadata. > - We need to decide about object naming: > - One obvious option for RDN is to use uniqueID but I don't like it. > It is hard to read for humans. > - Other option is to use uniqueID+PKCS#11 label or other attributes > to make it more readable. Can we use multi-valued RDN? If not, why? > What are technical reasons behind it? I would encourage you not to use multi-valued RDNs. There aren't any technical reasons - multi-valued RDNs are part of the LDAP standards and all conforming LDAP implementations must support them. However, they are hard to deal with - you _must_ have some sort of DN class/api on the client side to handle them, and not all clients do - many clients expect to be able to just do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. As far as being human readable - the whole goal is that humans _never_ have to look at a DN. If humans have to look at and understand a DN to accomplish a task, then we have failed. Has the DogTag team reviewed this proposal? Their data storage and workflows are similar. > > It is question if we like: > nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda > nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda > more than: > ipk11Label=meaningful_label+ipk11Private=TRUE > ipk11Label=meaningful_label+ipk11Private=FALSE > > DNSSEC key metadata > ------------------- > - Container (per-zone): cn=keys, idnsname=example.net, cn=dns > - Key metadata can be linked to key material via DN or ipk11Id. > - This allows key sharing between zones. > (DNSSEC-metadata will be specified later. That is not important for > key storage.) > > Replica public keys > ------------------- > - Container: cn=DNS,cn= FQDN>,cn=masters,cn=ipa,cn=etc,dc=example > - or it's child object like cn=wrappingKey > > Master keys > ----------- > - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example > - Single key = single object. > - We can use ipk11Label or ipk11Id for naming: > ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. > > > Work flows > ========== > Read DNSSEC private key > ----------------------- > 1) read DNSSEC private key from LDAP > 2) ipaWrappedKey objectClass is present - key is encrypted > 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key > object > 4) use local replica key to decrypt master key > 5) use decrypted master key to decrypt DNSSEC private key > > Add DNSSEC private key > ---------------------- > 1) use local replica key to decrypt master key > 2) encrypt DNSSEC private key with master key > 3) add ipaWrappingKey attribute pointing to master key > 4) store encrypted blob in a new LDAP object > > Add a replica > ------------- > ipa-replica-prepare: > 1) generate a new replica-key pair for the new replica > 2) store key pair to replica-file (don't scream yet :-) > 4) add public key for the new replica to LDAP > 3) fetch master key from LDAP > 4) encrypt master key with new replica public key > 5) store resulting master key blob to LDAP > ipa-replica-install: > 6) generate a new replica-key pair (!) > 7) store new public key to LDAP > 8) remove old public key (from replica-file) from LDAP > 9) fetch master key > 10) decrypt master key using old private key (from replica-file) > 11) encrypt master key using new private key (generated locally) > 12) replace old master key blob in LDAP with new blob (from step 11) > > Delete a replica > ---------------- > This is the tricky part. New master key has to be generated on some > other replica. What should we do if the ipa-replica-manage command was > run on deleted replica? > > I propose to split replica master key roll-over to two phases: > Any machine in IPA domain (including to-be deleted replica): > 1) Delete public key associated with replica from LDAP > 2) Flip a bit in master key metadata and say "this key needs to be > re-generated" > (Maybe we can disable ipk11Wrap boolean to indicate that this key > should not be used for key wrapping.) > > Remaining replicas: > 3) Periodically check that master key is obsolete > 4) Wait for (random period of time) to limit probability of collision > 5) Check that master key is really obsolete and new one is not present > 6) Generate a new master key > 7) Encrypt new master key with all replica-public-keys stored in LDAP > 8) Store new master key blobs to a new LDAP object > (Conflicts are not a problem up to now because we are not > deleting old key. In worst case, we will have multiple new master keys.) > *What should we do now?* > 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if we > have write conflict now?) > ??? Let old keys there and wait until key rotation mechanism > replaces all old DNSSEC keys with new DNSSEC keys encrypted with a new > master key (~ one year)? > 10) Old master key can be deleted when no other object is referencing > to it. > > > Congratulations to people who reached this line and didn't skip > anything :-) > > [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > [1] > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 > [2] > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping > [3] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects > From rcritten at redhat.com Thu May 1 18:55:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 May 2014 14:55:50 -0400 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <1398872755.11303.12.camel@aleeredhat.laptop> References: <1398872755.11303.12.camel@aleeredhat.laptop> Message-ID: <536298B6.9070907@redhat.com> Ade Lee wrote: > I have attached a patch that contains code for the new dogtag DRM plugin > vault functionality. This patch should be applied on top of the ones > used to install a DRM. > > Forthcoming is a patch to actually start using this plugin. All the imports should be at the top of the file. In _create_pem_file there is a ipaserver.install.certs.export_pkcs12() that you can re-use. Similarly install_pem_from_p12() probably does the same thing, and your copy doesn't take the PKCS#12 password as input AFAICT. In _transport_cert_present you can use: from ipaserver.install import certs db = certs.CertDB(self.realm, nssdir=self.sec_dir) return db.has_nickname(self.transport_nick) Should there be error handling around keyclient calls or will that be handled at a different level? Incidentally, installing a replica on F-20 with pki-ca-10.2.0-0.1 against an F-20 master with pki-ca-10.1.1-1 fails with this traceback in pkispawn: File "/usr/sbin/pkispawn", line 514, in main(sys.argv) File "/usr/sbin/pkispawn", line 423, in main info = parser.sd_get_info() File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 463, in sd_get_info info = sd.getSecurityDomainInfo() File "/usr/lib/python2.7/site-packages/pki/system.py", line 44, in getSecurityDomainInfo info.name = response.json()['id'] KeyError: 'id' rob From npmccallum at redhat.com Thu May 1 20:22:13 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 01 May 2014 16:22:13 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1394550599.32465.73.camel@willson.li.ssimo.org> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> Message-ID: <1398975733.2017.1.camel@localhost.localdomain> On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: > On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: > > On Tue, 11 Mar 2014, Jan Pazdziora wrote: > > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > > >> Before this patch, ipa-kdb would load global configuration on startup > > >> and never update it. This means that if global configuration is changed, > > >> the KDC never receives the new configuration until it is restarted. > > >> > > >> This patch enables caching of the global configuration with a timeout of > > >> 60 seconds. > > >> > > >> https://fedorahosted.org/freeipa/ticket/4153 > > > > > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > > >> From: Nathaniel McCallum > > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 > > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration > > >> > > >> Before this patch, ipa-kdb would load global configuration on startup and > > >> never update it. This means that if global configuration is changed, the > > >> KDC never receives the new configuration until it is restarted. > > >> > > >> This patch enables caching of the global configuration with a timeout of > > >> 60 seconds. > > >> > > >> https://fedorahosted.org/freeipa/ticket/4153 > > > > > >I have only read the code and it looks sane, so depending on how much > > >you consider my word about code-reading worth, ack. > > > > > >However, my gut feeling is that my preferred way of handling the issue > > >(without knowing much about the background of the ticket) would > > >probably be a HUP signal handler or something similar, rather than > > >polling for current values with the value timeout. This patch > > >introduces small nondeterminism to the behaviour when the usage of the > > >new values cannot really be enfoced by the admin (without the daemon > > >restart). > > Thing is, we need the update to happen when other, non-root process > > makes the changes -- in our case when IPA server running under httpd > > privileges performs series of MS-RPC calls towards smbd which lead to > > creating certain LDAP objects. httpd couldn't send SIGHUP to a process > > not owned by httpd's effective user (non-root). > > Yes but this is not really the way to go. > > The proper fix is to use syncrepl/persistent search to get a > notification of when we need to reload the configuration. > > On the patch itself I have a NACK due to this syntax used in various > places: function()->attribute > > don't. do. that. ever. > > assign whatever come from the function to a local variable and *check* > it is not null, *then* use it. Attached patch fixes the NACK issue, but does not address the question of the larger approach. Do we need to take a different approach? If so, what is it? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0044.1-Periodically-refresh-global-ipa-kdb-configuration.patch Type: text/x-patch Size: 10963 bytes Desc: not available URL: From tscherf at redhat.com Fri May 2 08:02:48 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Fri, 2 May 2014 10:02:48 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa_backup.py Message-ID: <20140502080247.GZ29357@tscherf.redhat.com> -------------- next part -------------- >From b6acf65fc6e7974aeface18c6ebc91c7134efc10 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Fri, 2 May 2014 09:51:55 +0200 Subject: [PATCH] Fixed typo how to create an example gpg key --- ipaserver/install/ipa_backup.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py index 302a5bd90563835ac27f8530d83c8eb2d18a49a5..37b7a2569bd30dc776fcb6f1e91469a1f17a7b66 100644 --- a/ipaserver/install/ipa_backup.py +++ b/ipaserver/install/ipa_backup.py @@ -42,7 +42,7 @@ from ipalib.constants import CACERT from ConfigParser import SafeConfigParser """ -A test gpg can be generated list this: +A test gpg can be generated like this: # cat >keygen < References: <536101A5.4000509@redhat.com> Message-ID: <20140502083632.GB4914@hendrix.brq.redhat.com> On Wed, Apr 30, 2014 at 03:59:01PM +0200, Tomas Babej wrote: > Hi, > > * patch 180 fixes incorrect hostname usage when connecting to legacy clients > * patch 181 sets up SSSD in debug_level 7 by default > * patch 182 does the same, but on the legacy clients > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > ACK to the general intent of debug_level by default. Have you considered using the python ConfigAPI sssd has to change the sections rather than running a sed script? From amisnyov at redhat.com Fri May 2 12:01:29 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 2 May 2014 14:01:29 +0200 Subject: [Freeipa-devel] plugin registration refactoring for pwpolicy Message-ID: <20140502140129.040d3681@unused-4-246.brq.redhat.com> SSIA Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0019-plugin-registration-refactoring-for-pwpolicy.patch Type: text/x-patch Size: 3830 bytes Desc: not available URL: From npmccallum at redhat.com Fri May 2 15:19:36 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 02 May 2014 11:19:36 -0400 Subject: [Freeipa-devel] plugin registration refactoring for pwpolicy In-Reply-To: <20140502140129.040d3681@unused-4-246.brq.redhat.com> References: <20140502140129.040d3681@unused-4-246.brq.redhat.com> Message-ID: <1399043976.2321.1.camel@localhost.localdomain> On Fri, 2014-05-02 at 14:01 +0200, Misnyovszki Adam wrote: > SSIA > Thanks > Adam Simple enough. ACK. Nathaniel From npmccallum at redhat.com Fri May 2 15:20:40 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 02 May 2014 11:20:40 -0400 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa_backup.py In-Reply-To: <20140502080247.GZ29357@tscherf.redhat.com> References: <20140502080247.GZ29357@tscherf.redhat.com> Message-ID: <1399044040.2321.2.camel@localhost.localdomain> ACK Nathaniel From pspacek at redhat.com Fri May 2 18:48:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 02 May 2014 20:48:18 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <536255E1.6060305@redhat.com> References: <5361229A.7030303@redhat.com> <536255E1.6060305@redhat.com> Message-ID: <5363E872.7060301@redhat.com> On 1.5.2014 16:10, Rich Megginson wrote: > On 04/30/2014 10:19 AM, Petr Spacek wrote: >> Hello list, >> >> following text summarizes schema & DIT layout for DNSSEC key storage in LDAP. >> >> This is subset of full PKCS#11 schema [0]. It stores bare keys with few >> metadata attributes when necessary. >> >> The intention is to make transition to full PKCS#11-in-LDAP schema [0] as >> easy as possible. This transition should happen in next minor version of >> FreeIPA. >> >> In theory, the transition should be just adding few object classes to >> existing objects and populating few new metadata attributes. Related object >> classes are marked below with "(in long-term)". >> >> Please comment on it soon. We want to implement it ASAP :-) >> >> >> DNSSEC key >> ========== >> - Asymmetric >> - Private key is stored in LDAP as encrypted PKCS#8 blob >> - Public key is published in LDAP >> - Encrypted with symmetric "DNSSEC master key" (see below) >> - Private key - represented as LDAP object with object classes: >> ipaEPrivateKey [1] # encrypted data >> ipaWrappedKey [2] # pointer to master key, outside scope of pure PKCS#11 >> ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata >> - Public key - represented as LDAP object with object classes: >> ipaPublicKey [1] # public key data >> ipk11PublicKey [3] (in long-term) # PKCS#11 metadata >> >> >> Master key >> ========== >> - Symmetric >> - Stored in LDAP as encrypted blob >> - Encrypted with asymmetric "replica key" (see below) >> - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys >> - A replica uses it's own key for master key en/decryption >> - Represented as LDAP object with object classes: >> ipaESecretKey [1] >> ipk11SecretKey [3] (in long-term) >> >> Replica key >> =========== >> - Asymmetric >> - Private key is stored on replica's disk only >> - Public key for all replicas is stored in LDAP >> - Represented as LDAP object with object classes: >> ipaPublicKey [1] >> ipk11PublicKey [3] (in long-term) >> >> >> DIT layout >> ========== >> DNSSEC key material >> ------------------- >> - Container: cn=keys, cn=sec, cn=dns, dc=example >> - Private and public keys are stored as separate objects to accommodate all >> PKCS#11 metadata. >> - We need to decide about object naming: >> - One obvious option for RDN is to use uniqueID but I don't like it. It is >> hard to read for humans. >> - Other option is to use uniqueID+PKCS#11 label or other attributes to >> make it more readable. Can we use multi-valued RDN? If not, why? What are >> technical reasons behind it? > > I would encourage you not to use multi-valued RDNs. There aren't any > technical reasons - multi-valued RDNs are part of the LDAP standards and all > conforming LDAP implementations must support them. However, they are hard to > deal with - you _must_ have some sort of DN class/api on the client side to > handle them, and not all clients do - many clients expect to be able to just > do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. > > As far as being human readable - the whole goal is that humans _never_ have to > look at a DN. If humans have to look at and understand a DN to accomplish a > task, then we have failed. I agree, users should not see them. I want to make life easier for administrators and developers *debugging* it. I'm facing UUIDs-only logs and database in oVirt for more than year now and I can tell you that it is horrible, horrible, horrible. It is PITA when I have to debug something in oVirt because I have to search for UUIDs all the time. I want to scream and jump out of the window when I see single log line with 4 or more different UUIDs... :-) > Has the DogTag team reviewed this proposal? Their data storage and workflows > are similar. That is very good point! Nathan, could somebody from DS team (maybe somebody involved in Password Vault) review this "vault without Vault"? Thank you! >> It is question if we like: >> nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda >> nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda >> more than: >> ipk11Label=meaningful_label+ipk11Private=TRUE >> ipk11Label=meaningful_label+ipk11Private=FALSE >> >> DNSSEC key metadata >> ------------------- >> - Container (per-zone): cn=keys, idnsname=example.net, cn=dns >> - Key metadata can be linked to key material via DN or ipk11Id. >> - This allows key sharing between zones. >> (DNSSEC-metadata will be specified later. That is not important for key >> storage.) >> >> Replica public keys >> ------------------- >> - Container: cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example >> - or it's child object like cn=wrappingKey >> >> Master keys >> ----------- >> - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example >> - Single key = single object. >> - We can use ipk11Label or ipk11Id for naming: >> ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. >> >> >> Work flows >> ========== >> Read DNSSEC private key >> ----------------------- >> 1) read DNSSEC private key from LDAP >> 2) ipaWrappedKey objectClass is present - key is encrypted >> 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key object >> 4) use local replica key to decrypt master key >> 5) use decrypted master key to decrypt DNSSEC private key >> >> Add DNSSEC private key >> ---------------------- >> 1) use local replica key to decrypt master key >> 2) encrypt DNSSEC private key with master key >> 3) add ipaWrappingKey attribute pointing to master key >> 4) store encrypted blob in a new LDAP object >> >> Add a replica >> ------------- >> ipa-replica-prepare: >> 1) generate a new replica-key pair for the new replica >> 2) store key pair to replica-file (don't scream yet :-) >> 4) add public key for the new replica to LDAP >> 3) fetch master key from LDAP >> 4) encrypt master key with new replica public key >> 5) store resulting master key blob to LDAP >> ipa-replica-install: >> 6) generate a new replica-key pair (!) >> 7) store new public key to LDAP >> 8) remove old public key (from replica-file) from LDAP >> 9) fetch master key >> 10) decrypt master key using old private key (from replica-file) >> 11) encrypt master key using new private key (generated locally) >> 12) replace old master key blob in LDAP with new blob (from step 11) >> >> Delete a replica >> ---------------- >> This is the tricky part. New master key has to be generated on some other >> replica. What should we do if the ipa-replica-manage command was run on >> deleted replica? >> >> I propose to split replica master key roll-over to two phases: >> Any machine in IPA domain (including to-be deleted replica): >> 1) Delete public key associated with replica from LDAP >> 2) Flip a bit in master key metadata and say "this key needs to be >> re-generated" >> (Maybe we can disable ipk11Wrap boolean to indicate that this key >> should not be used for key wrapping.) >> >> Remaining replicas: >> 3) Periodically check that master key is obsolete >> 4) Wait for (random period of time) to limit probability of collision >> 5) Check that master key is really obsolete and new one is not present >> 6) Generate a new master key >> 7) Encrypt new master key with all replica-public-keys stored in LDAP >> 8) Store new master key blobs to a new LDAP object >> (Conflicts are not a problem up to now because we are not deleting old >> key. In worst case, we will have multiple new master keys.) >> *What should we do now?* >> 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if we have >> write conflict now?) >> ??? Let old keys there and wait until key rotation mechanism replaces >> all old DNSSEC keys with new DNSSEC keys encrypted with a new master key (~ >> one year)? >> 10) Old master key can be deleted when no other object is referencing to it. >> >> >> Congratulations to people who reached this line and didn't skip anything :-) >> >> [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >> [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 >> [2] >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping >> >> [3] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects From simo at redhat.com Fri May 2 18:52:07 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 May 2014 14:52:07 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1398975733.2017.1.camel@localhost.localdomain> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> Message-ID: <1399056727.26263.86.camel@willson.li.ssimo.org> On Thu, 2014-05-01 at 16:22 -0400, Nathaniel McCallum wrote: > On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: > > On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: > > > On Tue, 11 Mar 2014, Jan Pazdziora wrote: > > > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > > > >> Before this patch, ipa-kdb would load global configuration on startup > > > >> and never update it. This means that if global configuration is changed, > > > >> the KDC never receives the new configuration until it is restarted. > > > >> > > > >> This patch enables caching of the global configuration with a timeout of > > > >> 60 seconds. > > > >> > > > >> https://fedorahosted.org/freeipa/ticket/4153 > > > > > > > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > > > >> From: Nathaniel McCallum > > > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 > > > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration > > > >> > > > >> Before this patch, ipa-kdb would load global configuration on startup and > > > >> never update it. This means that if global configuration is changed, the > > > >> KDC never receives the new configuration until it is restarted. > > > >> > > > >> This patch enables caching of the global configuration with a timeout of > > > >> 60 seconds. > > > >> > > > >> https://fedorahosted.org/freeipa/ticket/4153 > > > > > > > >I have only read the code and it looks sane, so depending on how much > > > >you consider my word about code-reading worth, ack. > > > > > > > >However, my gut feeling is that my preferred way of handling the issue > > > >(without knowing much about the background of the ticket) would > > > >probably be a HUP signal handler or something similar, rather than > > > >polling for current values with the value timeout. This patch > > > >introduces small nondeterminism to the behaviour when the usage of the > > > >new values cannot really be enfoced by the admin (without the daemon > > > >restart). > > > Thing is, we need the update to happen when other, non-root process > > > makes the changes -- in our case when IPA server running under httpd > > > privileges performs series of MS-RPC calls towards smbd which lead to > > > creating certain LDAP objects. httpd couldn't send SIGHUP to a process > > > not owned by httpd's effective user (non-root). > > > > Yes but this is not really the way to go. > > > > The proper fix is to use syncrepl/persistent search to get a > > notification of when we need to reload the configuration. > > > > On the patch itself I have a NACK due to this syntax used in various > > places: function()->attribute > > > > don't. do. that. ever. > > > > assign whatever come from the function to a local variable and *check* > > it is not null, *then* use it. > > Attached patch fixes the NACK issue, but does not address the question > of the larger approach. Do we need to take a different approach? If so, > what is it? LGTM I might prefer slightly more explicit names for those temp vars, but that's not a big deal. As for the approach, moving to something like syncrepl would be a good idea. As it would allow us to avoid useless polling and changes would be applaied as soon as they become available as the syncrepl agreement would push them to our client. It does mean we need a way to check that there aren't pending changes coming down the syncrepl pipe, but we can do that synchronously at every entry point in the KDB. After all we do not need to care about a change until the KDC needs something from the KDB. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri May 2 19:07:44 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 02 May 2014 13:07:44 -0600 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <5363E872.7060301@redhat.com> References: <5361229A.7030303@redhat.com> <536255E1.6060305@redhat.com> <5363E872.7060301@redhat.com> Message-ID: <5363ED00.4050800@redhat.com> On 05/02/2014 12:48 PM, Petr Spacek wrote: > On 1.5.2014 16:10, Rich Megginson wrote: >> On 04/30/2014 10:19 AM, Petr Spacek wrote: >>> Hello list, >>> >>> following text summarizes schema & DIT layout for DNSSEC key storage >>> in LDAP. >>> >>> This is subset of full PKCS#11 schema [0]. It stores bare keys with few >>> metadata attributes when necessary. >>> >>> The intention is to make transition to full PKCS#11-in-LDAP schema >>> [0] as >>> easy as possible. This transition should happen in next minor >>> version of >>> FreeIPA. >>> >>> In theory, the transition should be just adding few object classes to >>> existing objects and populating few new metadata attributes. Related >>> object >>> classes are marked below with "(in long-term)". >>> >>> Please comment on it soon. We want to implement it ASAP :-) >>> >>> >>> DNSSEC key >>> ========== >>> - Asymmetric >>> - Private key is stored in LDAP as encrypted PKCS#8 blob >>> - Public key is published in LDAP >>> - Encrypted with symmetric "DNSSEC master key" (see below) >>> - Private key - represented as LDAP object with object classes: >>> ipaEPrivateKey [1] # encrypted data >>> ipaWrappedKey [2] # pointer to master key, outside scope of pure >>> PKCS#11 >>> ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata >>> - Public key - represented as LDAP object with object classes: >>> ipaPublicKey [1] # public key data >>> ipk11PublicKey [3] (in long-term) # PKCS#11 metadata >>> >>> >>> Master key >>> ========== >>> - Symmetric >>> - Stored in LDAP as encrypted blob >>> - Encrypted with asymmetric "replica key" (see below) >>> - 1 replica = 1 blob, n replicas = n blobs encrypted with different >>> keys >>> - A replica uses it's own key for master key en/decryption >>> - Represented as LDAP object with object classes: >>> ipaESecretKey [1] >>> ipk11SecretKey [3] (in long-term) >>> >>> Replica key >>> =========== >>> - Asymmetric >>> - Private key is stored on replica's disk only >>> - Public key for all replicas is stored in LDAP >>> - Represented as LDAP object with object classes: >>> ipaPublicKey [1] >>> ipk11PublicKey [3] (in long-term) >>> >>> >>> DIT layout >>> ========== >>> DNSSEC key material >>> ------------------- >>> - Container: cn=keys, cn=sec, cn=dns, dc=example >>> - Private and public keys are stored as separate objects to >>> accommodate all >>> PKCS#11 metadata. >>> - We need to decide about object naming: >>> - One obvious option for RDN is to use uniqueID but I don't like >>> it. It is >>> hard to read for humans. >>> - Other option is to use uniqueID+PKCS#11 label or other >>> attributes to >>> make it more readable. Can we use multi-valued RDN? If not, why? >>> What are >>> technical reasons behind it? >> >> I would encourage you not to use multi-valued RDNs. There aren't any >> technical reasons - multi-valued RDNs are part of the LDAP standards >> and all >> conforming LDAP implementations must support them. However, they are >> hard to >> deal with - you _must_ have some sort of DN class/api on the client >> side to >> handle them, and not all clients do - many clients expect to be able >> to just >> do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. >> >> As far as being human readable - the whole goal is that humans >> _never_ have to >> look at a DN. If humans have to look at and understand a DN to >> accomplish a >> task, then we have failed. > I agree, users should not see them. I want to make life easier for > administrators and developers *debugging* it. > > I'm facing UUIDs-only logs and database in oVirt for more than year > now and I can tell you that it is horrible, horrible, horrible. It is > PITA when I have to debug something in oVirt because I have to search > for UUIDs all the time. I want to scream and jump out of the window > when I see single log line with 4 or more different UUIDs... :-) I sympathize, having to go through this with Designate, parsing up to 4 UUIDs per debug log line . . . > >> Has the DogTag team reviewed this proposal? Their data storage and >> workflows >> are similar. > That is very good point! Nathan, could somebody from DS team (maybe > somebody involved in Password Vault) review this "vault without Vault"? > > Thank you! > >>> It is question if we like: >>> nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda >>> nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda >>> more than: >>> ipk11Label=meaningful_label+ipk11Private=TRUE >>> ipk11Label=meaningful_label+ipk11Private=FALSE >>> >>> DNSSEC key metadata >>> ------------------- >>> - Container (per-zone): cn=keys, idnsname=example.net, cn=dns >>> - Key metadata can be linked to key material via DN or ipk11Id. >>> - This allows key sharing between zones. >>> (DNSSEC-metadata will be specified later. That is not important for key >>> storage.) >>> >>> Replica public keys >>> ------------------- >>> - Container: cn=DNS,cn=>> FQDN>,cn=masters,cn=ipa,cn=etc,dc=example >>> - or it's child object like cn=wrappingKey >>> >>> Master keys >>> ----------- >>> - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example >>> - Single key = single object. >>> - We can use ipk11Label or ipk11Id for naming: >>> ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. >>> >>> >>> Work flows >>> ========== >>> Read DNSSEC private key >>> ----------------------- >>> 1) read DNSSEC private key from LDAP >>> 2) ipaWrappedKey objectClass is present - key is encrypted >>> 3) read master key denoted by ipaWrappingKey attribute in DNSSEC >>> key object >>> 4) use local replica key to decrypt master key >>> 5) use decrypted master key to decrypt DNSSEC private key >>> >>> Add DNSSEC private key >>> ---------------------- >>> 1) use local replica key to decrypt master key >>> 2) encrypt DNSSEC private key with master key >>> 3) add ipaWrappingKey attribute pointing to master key >>> 4) store encrypted blob in a new LDAP object >>> >>> Add a replica >>> ------------- >>> ipa-replica-prepare: >>> 1) generate a new replica-key pair for the new replica >>> 2) store key pair to replica-file (don't scream yet :-) >>> 4) add public key for the new replica to LDAP >>> 3) fetch master key from LDAP >>> 4) encrypt master key with new replica public key >>> 5) store resulting master key blob to LDAP >>> ipa-replica-install: >>> 6) generate a new replica-key pair (!) >>> 7) store new public key to LDAP >>> 8) remove old public key (from replica-file) from LDAP >>> 9) fetch master key >>> 10) decrypt master key using old private key (from replica-file) >>> 11) encrypt master key using new private key (generated locally) >>> 12) replace old master key blob in LDAP with new blob (from step 11) >>> >>> Delete a replica >>> ---------------- >>> This is the tricky part. New master key has to be generated on some >>> other >>> replica. What should we do if the ipa-replica-manage command was run on >>> deleted replica? >>> >>> I propose to split replica master key roll-over to two phases: >>> Any machine in IPA domain (including to-be deleted replica): >>> 1) Delete public key associated with replica from LDAP >>> 2) Flip a bit in master key metadata and say "this key needs to be >>> re-generated" >>> (Maybe we can disable ipk11Wrap boolean to indicate that this key >>> should not be used for key wrapping.) >>> >>> Remaining replicas: >>> 3) Periodically check that master key is obsolete >>> 4) Wait for (random period of time) to limit probability of collision >>> 5) Check that master key is really obsolete and new one is not >>> present >>> 6) Generate a new master key >>> 7) Encrypt new master key with all replica-public-keys stored in LDAP >>> 8) Store new master key blobs to a new LDAP object >>> (Conflicts are not a problem up to now because we are not >>> deleting old >>> key. In worst case, we will have multiple new master keys.) >>> *What should we do now?* >>> 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if >>> we have >>> write conflict now?) >>> ??? Let old keys there and wait until key rotation mechanism >>> replaces >>> all old DNSSEC keys with new DNSSEC keys encrypted with a new master >>> key (~ >>> one year)? >>> 10) Old master key can be deleted when no other object is >>> referencing to it. >>> >>> >>> Congratulations to people who reached this line and didn't skip >>> anything :-) >>> >>> [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >>> [1] >>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 >>> [2] >>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping >>> >>> >>> [3] >>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects > From npmccallum at redhat.com Fri May 2 21:06:06 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 02 May 2014 17:06:06 -0400 Subject: [Freeipa-devel] bind DN of executing command Message-ID: <1399064766.2321.8.camel@localhost.localdomain> I need the DN of the user who is running the current command. This may be defined as the user who is bound or will bind to execute the LDAP commands I have prepared. Does anyone know how to do this in the FreeIPA api? Nathaniel From npmccallum at redhat.com Fri May 2 21:45:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 02 May 2014 17:45:25 -0400 Subject: [Freeipa-devel] [PATCH 0046] Fix a typo in the otptoken doc string Message-ID: <1399067125.2321.9.camel@localhost.localdomain> Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0046-Fix-a-typo-in-the-otptoken-doc-string.patch Type: text/x-patch Size: 1294 bytes Desc: not available URL: From npmccallum at redhat.com Fri May 2 21:49:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 02 May 2014 17:49:03 -0400 Subject: [Freeipa-devel] [PATCH 0047] kdb: Don't provide password expiration when using only RADIUS Message-ID: <1399067343.2321.11.camel@localhost.localdomain> If the KDC doesn't use the FreeIPA password for authentication, then it is futile to provide this information. Doing so will only confuse the user. It also causes password change dialogues when the password is irrelevant. https://fedorahosted.org/freeipa/ticket/4299 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0047-kdb-Don-t-provide-password-expiration-when-using-onl.patch Type: text/x-patch Size: 1481 bytes Desc: not available URL: From sbose at redhat.com Mon May 5 07:25:43 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 5 May 2014 09:25:43 +0200 Subject: [Freeipa-devel] bind DN of executing command In-Reply-To: <1399064766.2321.8.camel@localhost.localdomain> References: <1399064766.2321.8.camel@localhost.localdomain> Message-ID: <20140505072543.GG4165@localhost.localdomain> On Fri, May 02, 2014 at 05:06:06PM -0400, Nathaniel McCallum wrote: > I need the DN of the user who is running the current command. This may > be defined as the user who is bound or will bind to execute the LDAP > commands I have prepared. > > Does anyone know how to do this in the FreeIPA api? I guess you are looking for ipa user-find --whoami HTH bye, Sumit > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From lkrispen at redhat.com Mon May 5 08:45:04 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 05 May 2014 10:45:04 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <5363E872.7060301@redhat.com> References: <5361229A.7030303@redhat.com> <536255E1.6060305@redhat.com> <5363E872.7060301@redhat.com> Message-ID: <53674F90.1070501@redhat.com> Hi Petr, On 05/02/2014 08:48 PM, Petr Spacek wrote: > On 1.5.2014 16:10, Rich Megginson wrote: >> On 04/30/2014 10:19 AM, Petr Spacek wrote: >>> Hello list, >>> >>> following text summarizes schema & DIT layout for DNSSEC key storage >>> in LDAP. >>> >>> This is subset of full PKCS#11 schema [0]. It stores bare keys with few >>> metadata attributes when necessary. >>> >>> The intention is to make transition to full PKCS#11-in-LDAP schema >>> [0] as >>> easy as possible. This transition should happen in next minor >>> version of >>> FreeIPA. >>> >>> In theory, the transition should be just adding few object classes to >>> existing objects and populating few new metadata attributes. Related >>> object >>> classes are marked below with "(in long-term)". >>> >>> Please comment on it soon. We want to implement it ASAP :-) >>> >>> >>> DNSSEC key >>> ========== >>> - Asymmetric >>> - Private key is stored in LDAP as encrypted PKCS#8 blob >>> - Public key is published in LDAP >>> - Encrypted with symmetric "DNSSEC master key" (see below) >>> - Private key - represented as LDAP object with object classes: >>> ipaEPrivateKey [1] # encrypted data >>> ipaWrappedKey [2] # pointer to master key, outside scope of pure >>> PKCS#11 >>> ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata >>> - Public key - represented as LDAP object with object classes: >>> ipaPublicKey [1] # public key data >>> ipk11PublicKey [3] (in long-term) # PKCS#11 metadata >>> >>> >>> Master key >>> ========== >>> - Symmetric >>> - Stored in LDAP as encrypted blob >>> - Encrypted with asymmetric "replica key" (see below) >>> - 1 replica = 1 blob, n replicas = n blobs encrypted with different >>> keys >>> - A replica uses it's own key for master key en/decryption >>> - Represented as LDAP object with object classes: >>> ipaESecretKey [1] >>> ipk11SecretKey [3] (in long-term) >>> >>> Replica key >>> =========== >>> - Asymmetric >>> - Private key is stored on replica's disk only >>> - Public key for all replicas is stored in LDAP >>> - Represented as LDAP object with object classes: >>> ipaPublicKey [1] >>> ipk11PublicKey [3] (in long-term) >>> >>> >>> DIT layout >>> ========== >>> DNSSEC key material >>> ------------------- >>> - Container: cn=keys, cn=sec, cn=dns, dc=example >>> - Private and public keys are stored as separate objects to >>> accommodate all >>> PKCS#11 metadata. >>> - We need to decide about object naming: >>> - One obvious option for RDN is to use uniqueID but I don't like >>> it. It is >>> hard to read for humans. >>> - Other option is to use uniqueID+PKCS#11 label or other >>> attributes to >>> make it more readable. Can we use multi-valued RDN? If not, why? >>> What are >>> technical reasons behind it? >> >> I would encourage you not to use multi-valued RDNs. There aren't any >> technical reasons - multi-valued RDNs are part of the LDAP standards >> and all >> conforming LDAP implementations must support them. However, they are >> hard to >> deal with - you _must_ have some sort of DN class/api on the client >> side to >> handle them, and not all clients do - many clients expect to be able >> to just >> do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. >> >> As far as being human readable - the whole goal is that humans >> _never_ have to >> look at a DN. If humans have to look at and understand a DN to >> accomplish a >> task, then we have failed. > I agree, users should not see them. I want to make life easier for > administrators and developers *debugging* it. > > I'm facing UUIDs-only logs and database in oVirt for more than year > now and I can tell you that it is horrible, horrible, horrible. It is > PITA when I have to debug something in oVirt because I have to search > for UUIDs all the time. I want to scream and jump out of the window > when I see single log line with 4 or more different UUIDs... :-) > >> Has the DogTag team reviewed this proposal? Their data storage and >> workflows >> are similar. > That is very good point! Nathan, could somebody from DS team (maybe > somebody involved in Password Vault) review this "vault without Vault"? > > Thank you! > >>> It is question if we like: >>> nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda >>> nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda >>> more than: >>> ipk11Label=meaningful_label+ipk11Private=TRUE >>> ipk11Label=meaningful_label+ipk11Private=FALSE there are two goals for choosing the naming attribute(s): they have to be unique in a level of the DIT and they should be meaningful/readable. I agree with Rich that technically nothing excludes multi-valued rdns, but could make things complicated for clients and in my opinion it does not increase readability. In your case: - are there really two entries with the same ipk11label, on private one not ? not all info has to be in the rdn, so you could use ipk11label as naming attribute - couldn't you just use an other attribute as anming attr where you are free to put in what you want eg cn="(True)" - we did define an ipk11uniquid to be used as naming attr for storage objects, but there are no definitions on its structure, you could use it as you like as long as it is unique (could be unique and meaningful and readable) >>> >>> DNSSEC key metadata >>> ------------------- >>> - Container (per-zone): cn=keys, idnsname=example.net, cn=dns >>> - Key metadata can be linked to key material via DN or ipk11Id. >>> - This allows key sharing between zones. >>> (DNSSEC-metadata will be specified later. That is not important for key >>> storage.) >>> >>> Replica public keys >>> ------------------- >>> - Container: cn=DNS,cn=>> FQDN>,cn=masters,cn=ipa,cn=etc,dc=example >>> - or it's child object like cn=wrappingKey >>> >>> Master keys >>> ----------- >>> - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example >>> - Single key = single object. >>> - We can use ipk11Label or ipk11Id for naming: >>> ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. >>> >>> >>> Work flows >>> ========== >>> Read DNSSEC private key >>> ----------------------- >>> 1) read DNSSEC private key from LDAP >>> 2) ipaWrappedKey objectClass is present - key is encrypted >>> 3) read master key denoted by ipaWrappingKey attribute in DNSSEC >>> key object >>> 4) use local replica key to decrypt master key >>> 5) use decrypted master key to decrypt DNSSEC private key >>> >>> Add DNSSEC private key >>> ---------------------- >>> 1) use local replica key to decrypt master key >>> 2) encrypt DNSSEC private key with master key >>> 3) add ipaWrappingKey attribute pointing to master key >>> 4) store encrypted blob in a new LDAP object >>> >>> Add a replica >>> ------------- >>> ipa-replica-prepare: >>> 1) generate a new replica-key pair for the new replica >>> 2) store key pair to replica-file (don't scream yet :-) >>> 4) add public key for the new replica to LDAP >>> 3) fetch master key from LDAP >>> 4) encrypt master key with new replica public key >>> 5) store resulting master key blob to LDAP >>> ipa-replica-install: >>> 6) generate a new replica-key pair (!) >>> 7) store new public key to LDAP >>> 8) remove old public key (from replica-file) from LDAP >>> 9) fetch master key >>> 10) decrypt master key using old private key (from replica-file) >>> 11) encrypt master key using new private key (generated locally) >>> 12) replace old master key blob in LDAP with new blob (from step 11) >>> >>> Delete a replica >>> ---------------- >>> This is the tricky part. New master key has to be generated on some >>> other >>> replica. What should we do if the ipa-replica-manage command was run on >>> deleted replica? >>> >>> I propose to split replica master key roll-over to two phases: >>> Any machine in IPA domain (including to-be deleted replica): >>> 1) Delete public key associated with replica from LDAP >>> 2) Flip a bit in master key metadata and say "this key needs to be >>> re-generated" >>> (Maybe we can disable ipk11Wrap boolean to indicate that this key >>> should not be used for key wrapping.) >>> >>> Remaining replicas: >>> 3) Periodically check that master key is obsolete >>> 4) Wait for (random period of time) to limit probability of collision >>> 5) Check that master key is really obsolete and new one is not >>> present >>> 6) Generate a new master key >>> 7) Encrypt new master key with all replica-public-keys stored in LDAP >>> 8) Store new master key blobs to a new LDAP object >>> (Conflicts are not a problem up to now because we are not >>> deleting old >>> key. In worst case, we will have multiple new master keys.) >>> *What should we do now?* >>> 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if >>> we have >>> write conflict now?) >>> ??? Let old keys there and wait until key rotation mechanism >>> replaces >>> all old DNSSEC keys with new DNSSEC keys encrypted with a new master >>> key (~ >>> one year)? >>> 10) Old master key can be deleted when no other object is >>> referencing to it. >>> >>> >>> Congratulations to people who reached this line and didn't skip >>> anything :-) >>> >>> [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >>> [1] >>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 >>> [2] >>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping >>> >>> >>> [3] >>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects > From jcholast at redhat.com Mon May 5 12:03:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 05 May 2014 14:03:42 +0200 Subject: [Freeipa-devel] [PATCH 0046] Fix a typo in the otptoken doc string In-Reply-To: <1399067125.2321.9.camel@localhost.localdomain> References: <1399067125.2321.9.camel@localhost.localdomain> Message-ID: <53677E1E.2050506@redhat.com> Hi, On 2.5.2014 23:45, Nathaniel McCallum wrote: > Patch attached ACK, but there is one additional occurence of "otp-add" in a comment in install/ui/src/freeipa/otptoken.js. Honza -- Jan Cholasta From amisnyov at redhat.com Mon May 5 12:05:42 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 5 May 2014 14:05:42 +0200 Subject: [Freeipa-devel] [PATCH] 587 webui-ci: adjust id range tests to new validator In-Reply-To: <535A5CE3.1070106@redhat.com> References: <535A5CE3.1070106@redhat.com> Message-ID: <20140505140542.2aa4d1e7@unused-4-246.brq.redhat.com> On Fri, 25 Apr 2014 15:02:27 +0200 Petr Vobornik wrote: > SSIA LGFM, integration tests for range now runs smoothly. ACK Thanks Adam From amisnyov at redhat.com Mon May 5 12:40:50 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 5 May 2014 14:40:50 +0200 Subject: [Freeipa-devel] [PATCH] 588 webui: fix switching between multiple_choice_section choices In-Reply-To: <535A9A53.9080801@redhat.com> References: <535A9A53.9080801@redhat.com> Message-ID: <20140505144050.1fd9afe3@unused-4-246.brq.redhat.com> On Fri, 25 Apr 2014 19:24:35 +0200 Petr Vobornik wrote: > - required indicators are not present for all sections except the last > - validation has wrong color for the same sections > > There was only one layout for all choices. Layout should not be reused > because `create` method will reset layout's rows therefore it worked > properly only for the last choice. > > https://fedorahosted.org/freeipa/ticket/4327 Works as expected, integration and manual tests ran. ACK Thanks Adam From jcholast at redhat.com Mon May 5 12:55:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 05 May 2014 14:55:07 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53674F90.1070501@redhat.com> References: <5361229A.7030303@redhat.com> <536255E1.6060305@redhat.com> <5363E872.7060301@redhat.com> <53674F90.1070501@redhat.com> Message-ID: <53678A2B.8020202@redhat.com> On 5.5.2014 10:45, Ludwig Krispenz wrote: > Hi Petr, > > On 05/02/2014 08:48 PM, Petr Spacek wrote: >> On 1.5.2014 16:10, Rich Megginson wrote: >>> On 04/30/2014 10:19 AM, Petr Spacek wrote: >>>> - We need to decide about object naming: >>>> - One obvious option for RDN is to use uniqueID but I don't like >>>> it. It is >>>> hard to read for humans. >>>> - Other option is to use uniqueID+PKCS#11 label or other >>>> attributes to >>>> make it more readable. Can we use multi-valued RDN? If not, why? >>>> What are >>>> technical reasons behind it? >>> >>> I would encourage you not to use multi-valued RDNs. There aren't any >>> technical reasons - multi-valued RDNs are part of the LDAP standards >>> and all >>> conforming LDAP implementations must support them. However, they are >>> hard to >>> deal with - you _must_ have some sort of DN class/api on the client >>> side to >>> handle them, and not all clients do - many clients expect to be able >>> to just >>> do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. >>> >>> As far as being human readable - the whole goal is that humans >>> _never_ have to >>> look at a DN. If humans have to look at and understand a DN to >>> accomplish a >>> task, then we have failed. >> I agree, users should not see them. I want to make life easier for >> administrators and developers *debugging* it. >> >> I'm facing UUIDs-only logs and database in oVirt for more than year >> now and I can tell you that it is horrible, horrible, horrible. It is >> PITA when I have to debug something in oVirt because I have to search >> for UUIDs all the time. I want to scream and jump out of the window >> when I see single log line with 4 or more different UUIDs... :-) >> >>> Has the DogTag team reviewed this proposal? Their data storage and >>> workflows >>> are similar. >> That is very good point! Nathan, could somebody from DS team (maybe >> somebody involved in Password Vault) review this "vault without Vault"? >> >> Thank you! >> >>>> It is question if we like: >>>> nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda >>>> nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda >>>> more than: >>>> ipk11Label=meaningful_label+ipk11Private=TRUE >>>> ipk11Label=meaningful_label+ipk11Private=FALSE > there are two goals for choosing the naming attribute(s): they have to > be unique in a level of the DIT and they should be meaningful/readable. > I agree with Rich that technically nothing excludes multi-valued rdns, > but could make things complicated for clients and in my opinion it does > not increase readability. > In your case: > - are there really two entries with the same ipk11label, on private one > not ? not all info has to be in the rdn, so you could use ipk11label as > naming attribute > - couldn't you just use an other attribute as anming attr where you are > free to put in what you want eg cn="(True)" > - we did define an ipk11uniquid to be used as naming attr for storage > objects, but there are no definitions on its structure, you could use it > as you like as long as it is unique (could be unique and meaningful and > readable) +1 on the last suggestion Honza -- Jan Cholasta From rcritten at redhat.com Mon May 5 13:56:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 May 2014 09:56:56 -0400 Subject: [Freeipa-devel] bind DN of executing command In-Reply-To: <20140505072543.GG4165@localhost.localdomain> References: <1399064766.2321.8.camel@localhost.localdomain> <20140505072543.GG4165@localhost.localdomain> Message-ID: <536798A8.6000000@redhat.com> Sumit Bose wrote: > On Fri, May 02, 2014 at 05:06:06PM -0400, Nathaniel McCallum wrote: >> I need the DN of the user who is running the current command. This may >> be defined as the user who is bound or will bind to execute the LDAP >> commands I have prepared. >> >> Does anyone know how to do this in the FreeIPA api? > > I guess you are looking for > > ipa user-find --whoami If you're doing this in your own plugin, you get the current principal with: getattr(context, 'principal') Using that you can get the DN of that user with a search like this: "(&(objectclass=posixaccount)(krbprincipalname=%s))" % getattr(context, 'principal') We don't currently have a helper for this. This is rather inefficient in user-find as it searches from the basedn rather than the user container for some reason. rob From amisnyov at redhat.com Mon May 5 14:39:12 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 5 May 2014 16:39:12 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added In-Reply-To: <5360E066.5070804@redhat.com> References: <20140425171648.754632d7@unused-4-246.brq.redhat.com> <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> <5360E066.5070804@redhat.com> Message-ID: <20140505163912.7cb903d1@unused-4-246.brq.redhat.com> On Wed, 30 Apr 2014 13:37:10 +0200 Petr Vobornik wrote: > On 29.4.2014 16:30, Misnyovszki Adam wrote: > > On Fri, 25 Apr 2014 17:16:48 +0200 > > Misnyovszki Adam wrote: > > > >> Hi, > >> this patch adds some static test data for the webui otptoken part. > >> Adam > > > > Attached corrected DN's. > > Thanks > > Adam > > > > 1) Why otptoken_batch_del.json ends with error? Also there might be > a defect in UI that for batch delete operation it asks for batch.json > and not $ENTITY_batch_del.json making otptoken_batch_del.json unused > - out of scope of this patch. > > 2) Why otptoken_mod.json ends with error? > > 3) otptoken_find.json is not needed since the search facet uses > paging (combination of otptoken_get_records.json and > otptoken_find_pkeys.json is enough). > > In general, it's OK to fake the data if there is some bug which > causes errors and we know that it will be fixed. Hi, see the attached, and corrected 18 patch for otptoken static test data. Also, I've added patch 20, for fixing the batch_del command in static webui tests. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0018-3-webui-OTP-token-test-data-added.patch Type: text/x-patch Size: 13653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0020-webui-static-site-delete-command-fixed.patch Type: text/x-patch Size: 1101 bytes Desc: not available URL: From thozza at redhat.com Mon May 5 14:46:25 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 5 May 2014 10:46:25 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0236] Fix crash in create_zone() In-Reply-To: <534D62D5.4010306@redhat.com> References: <534D62D5.4010306@redhat.com> Message-ID: <428156263.347034.1399301185346.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > Fix crash in create_zone(). > > dns_zone_getmgr(zone) call in cleanup section was called even if zone > was NULL. > > This patch should go to master, v4 and v3 branches where applicable. > > You probably need to use debugger to reproduce this crash. I have encountered > it during work on new DNSSEC code ... > > -- > Petr^2 Spacek > Looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Mon May 5 14:56:03 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 5 May 2014 10:56:03 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0237] Handle paths without trailing / in fs_dirs_create() In-Reply-To: <534E8D50.3090204@redhat.com> References: <534E8D50.3090204@redhat.com> Message-ID: <111895784.349662.1399301763115.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > Handle paths without trailing / in fs_dirs_create(). > > This patch should go to all branches with fs_dirs_create() function. > > -- > Petr^2 Spacek > Looks good. ACK Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Mon May 5 14:56:44 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 5 May 2014 10:56:44 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0238] Update .gitignore to skip Eclipse and Autotools file In-Reply-To: <534E8D81.4050802@redhat.com> References: <534E8D81.4050802@redhat.com> Message-ID: <1193898421.350021.1399301804917.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > Update .gitignore to skip Eclipse and Autotools files. > > -- > Petr^2 Spacek > ACK -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pspacek at redhat.com Mon May 5 15:02:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 May 2014 17:02:16 +0200 Subject: [Freeipa-devel] [PATCH 0236] Fix crash in create_zone() In-Reply-To: <428156263.347034.1399301185346.JavaMail.zimbra@redhat.com> References: <534D62D5.4010306@redhat.com> <428156263.347034.1399301185346.JavaMail.zimbra@redhat.com> Message-ID: <5367A7F8.5080309@redhat.com> On 5.5.2014 16:46, Tomas Hozza wrote: >> Fix crash in create_zone(). >> >> dns_zone_getmgr(zone) call in cleanup section was called even if zone >> was NULL. >> >> This patch should go to master, v4 and v3 branches where applicable. >> >> You probably need to use debugger to reproduce this crash. I have encountered >> it during work on new DNSSEC code ... >> >> -- >> Petr^2 Spacek >> > > Looks good. > > ACK. Pushed to master: 7444db8200a38710f69db9d4d9c350615748ba24 -- Petr^2 Spacek From pspacek at redhat.com Mon May 5 15:02:20 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 May 2014 17:02:20 +0200 Subject: [Freeipa-devel] [PATCH 0237] Handle paths without trailing / in fs_dirs_create() In-Reply-To: <111895784.349662.1399301763115.JavaMail.zimbra@redhat.com> References: <534E8D50.3090204@redhat.com> <111895784.349662.1399301763115.JavaMail.zimbra@redhat.com> Message-ID: <5367A7FC.3020001@redhat.com> On 5.5.2014 16:56, Tomas Hozza wrote: >> Hello, >> > >> >Handle paths without trailing / in fs_dirs_create(). >> > >> >This patch should go to all branches with fs_dirs_create() function. >> > >> >-- >> >Petr^2 Spacek >> > > Looks good. > > ACK Pushed to master: 21136d9b6933a733586fba3a83e9b2be050a948d -- Petr^2 Spacek From pspacek at redhat.com Mon May 5 15:02:25 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 May 2014 17:02:25 +0200 Subject: [Freeipa-devel] [PATCH 0238] Update .gitignore to skip Eclipse and Autotools file In-Reply-To: <1193898421.350021.1399301804917.JavaMail.zimbra@redhat.com> References: <534E8D81.4050802@redhat.com> <1193898421.350021.1399301804917.JavaMail.zimbra@redhat.com> Message-ID: <5367A801.2070704@redhat.com> On 5.5.2014 16:56, Tomas Hozza wrote: >> Hello, >> > >> >Update .gitignore to skip Eclipse and Autotools files. >> > >> >-- >> >Petr^2 Spacek >> > > ACK Pushed to master: 5dbb7fa8426cd5512cd7ce99dc6546b7928cfbfb -- Petr^2 Spacek From abokovoy at redhat.com Mon May 5 15:52:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 May 2014 18:52:55 +0300 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <536111C4.1070604@redhat.com> References: <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <536111C4.1070604@redhat.com> Message-ID: <20140505155255.GZ20958@redhat.com> On Wed, 30 Apr 2014, Tomas Babej wrote: >>>> + if (current_time > expire_time && expire_time > 0) { >>>> + LOG_FATAL("kerberos principal in %s is >>>> expired\n", dn); >>>> + errMesg = "Kerberos principal is expired."; >>>> + auth_failed = true; >>>> + goto done; >>>> + } >>>> + } >>> I think indenting is broken for these two brackets. >>> >>> >> Thanks Alexander, fixed. >> >> Updated version attached. >> >> Tomas > >This version is rebased on top of OTP patches, addresses Simo's comments >and brings unit tests to cover the functionality (however, they need to >be applied on top of my patches 183-185). Tested, works fine. I've pushed the main patch to master. The tests will be pushed after the dependency patches will be pushed. -- / Alexander Bokovoy From pvoborni at redhat.com Mon May 5 15:53:37 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 05 May 2014 17:53:37 +0200 Subject: [Freeipa-devel] [PATCH] 587 webui-ci: adjust id range tests to new validator In-Reply-To: <20140505140542.2aa4d1e7@unused-4-246.brq.redhat.com> References: <535A5CE3.1070106@redhat.com> <20140505140542.2aa4d1e7@unused-4-246.brq.redhat.com> Message-ID: <5367B401.4090908@redhat.com> On 5.5.2014 14:05, Misnyovszki Adam wrote: > On Fri, 25 Apr 2014 15:02:27 +0200 > Petr Vobornik wrote: > >> SSIA > > LGFM, integration tests for range now runs smoothly. > > ACK > > Thanks > Adam > Pushed to master: 7eff8ad7dc385070b600ddb2b2ba1f39835718b6 -- Petr Vobornik From pvoborni at redhat.com Mon May 5 15:55:58 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 05 May 2014 17:55:58 +0200 Subject: [Freeipa-devel] [PATCH] 588 webui: fix switching between multiple_choice_section choices In-Reply-To: <20140505144050.1fd9afe3@unused-4-246.brq.redhat.com> References: <535A9A53.9080801@redhat.com> <20140505144050.1fd9afe3@unused-4-246.brq.redhat.com> Message-ID: <5367B48E.6040507@redhat.com> On 5.5.2014 14:40, Misnyovszki Adam wrote: > On Fri, 25 Apr 2014 19:24:35 +0200 > Petr Vobornik wrote: > >> - required indicators are not present for all sections except the last >> - validation has wrong color for the same sections >> >> There was only one layout for all choices. Layout should not be reused >> because `create` method will reset layout's rows therefore it worked >> properly only for the last choice. >> >> https://fedorahosted.org/freeipa/ticket/4327 > > Works as expected, integration and manual tests ran. > ACK > Thanks > Adam > Pushed to master: 093c72d60e94d9545e38f2ad90cb24e6f44cbd62 -- Petr Vobornik From abokovoy at redhat.com Mon May 5 15:58:26 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 May 2014 18:58:26 +0300 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <536111B5.8040500@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> Message-ID: <20140505155826.GA20958@redhat.com> On Wed, 30 Apr 2014, Tomas Babej wrote: > >On 04/25/2014 11:08 AM, Jan Cholasta wrote: >> On 22.4.2014 13:32, Tomas Babej wrote: >>> Thank you for the suggestions. Updated, rebased patch is attached. >>> >> >> This API.txt change from the next patch belongs in this patch: >> >> +capability: datetime_values 2.84 >> >> >> I think you should use the LDAP_GENERALIZED_TIME_FORMAT constant here: >> >> + accepted_formats = ['%Y%m%d%H%M%SZ', # generalized time >> >> >> This is not right: >> >> + elif isinstance(val, datetime.datetime): >> + return val >> >> To actually decode LDAP generalized time attributes to datetime, you >> need to do this: >> >> '2.16.840.1.113719.1.301.4.41.1' : DN, # krbSubTrees >> '2.16.840.1.113719.1.301.4.52.1' : DN, # krbObjectReferences >> '2.16.840.1.113719.1.301.4.53.1' : DN, # krbPrincContainerRef >> + >> + '1.3.6.1.4.1.1466.115.121.1.24' : datetime.datetime, >> } >> >> # In most cases we lookup the syntax from the schema returned by >> >> and this: >> >> return val >> elif target_type is unicode: >> return val.decode('utf-8') >> + elif target_type is datetime.datetime: >> + return datetime.datetime.strptime(val, >> LDAP_GENERALIZED_TIME_FORMAT) >> else: >> return target_type(val) >> except Exception, e: >> >> and add code for formatting datetime values to the textui backend. >> > >Thanks for the review. I fixed all the issues, updated patch is attached. > >I also added unit tests for the new DateTime parameter. Thanks, tested them as part of kerberos principal expiration time patches. Pushed two patches to git master. -- / Alexander Bokovoy From abokovoy at redhat.com Mon May 5 16:02:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 May 2014 19:02:13 +0300 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <536111BD.6000007@redhat.com> References: <52CEC0C9.70905@redhat.com> <530C478E.4080307@redhat.com> <53171423.8030204@redhat.com> <535653C3.7040406@redhat.com> <535A267D.9070106@redhat.com> <536111BD.6000007@redhat.com> Message-ID: <20140505160213.GB20958@redhat.com> On Wed, 30 Apr 2014, Tomas Babej wrote: >On 04/25/2014 11:10 AM, Jan Cholasta wrote: >> On 22.4.2014 13:34, Tomas Babej wrote: >>> Updated, rebased patch attached. >>> >> >> This API.txt change belongs in the previous patch: >> >> +capability: datetime_values 2.84 >> > >Fixed, updated patch attached. > >I also added several tests for the user plugin that cover the feature >(and related refactoring). Thanks. Tested and they work fine. Pushed three patches to master * edb5a0c5344de88cc41f6f73098da88d754cf076 ipalib: Expose krbPrincipalExpiration in CLI * 4568a52953bc8e0193d586ebc3d8bdbd3e3e0fa0 ipatests: Fix formatting errors in test_user_plugin.py * 473a9fd23800b46b4608465ae47da523e8a2861f ipatests: Add coverage for setting krbPrincipalExpiration -- / Alexander Bokovoy From abokovoy at redhat.com Mon May 5 16:07:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 May 2014 19:07:31 +0300 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <20140505155255.GZ20958@redhat.com> References: <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <536111C4.1070604@redhat.com> <20140505155255.GZ20958@redhat.com> Message-ID: <20140505160731.GC20958@redhat.com> On Mon, 05 May 2014, Alexander Bokovoy wrote: >On Wed, 30 Apr 2014, Tomas Babej wrote: >>>>>+ if (current_time > expire_time && expire_time > 0) { >>>>>+ LOG_FATAL("kerberos principal in %s is >>>>>expired\n", dn); >>>>>+ errMesg = "Kerberos principal is expired."; >>>>>+ auth_failed = true; >>>>>+ goto done; >>>>>+ } >>>>>+ } >>>>I think indenting is broken for these two brackets. >>>> >>>> >>>Thanks Alexander, fixed. >>> >>>Updated version attached. >>> >>>Tomas >> >>This version is rebased on top of OTP patches, addresses Simo's comments >>and brings unit tests to cover the functionality (however, they need to >>be applied on top of my patches 183-185). >Tested, works fine. > >I've pushed the main patch to master. The tests will be pushed after the >dependency patches will be pushed. Pushed patch 186 to master * 004071a24626195994265b1bcc3ac616bb09d795 ipatests: Add test for denying expired principals -- / Alexander Bokovoy From abokovoy at redhat.com Mon May 5 16:08:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 May 2014 19:08:36 +0300 Subject: [Freeipa-devel] [PATCHES 180-182] ipatests: Improvements! In-Reply-To: <20140502083632.GB4914@hendrix.brq.redhat.com> References: <536101A5.4000509@redhat.com> <20140502083632.GB4914@hendrix.brq.redhat.com> Message-ID: <20140505160836.GD20958@redhat.com> On Fri, 02 May 2014, Jakub Hrozek wrote: >On Wed, Apr 30, 2014 at 03:59:01PM +0200, Tomas Babej wrote: >> Hi, >> >> * patch 180 fixes incorrect hostname usage when connecting to legacy clients >> * patch 181 sets up SSSD in debug_level 7 by default >> * patch 182 does the same, but on the legacy clients >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> > >ACK to the general intent of debug_level by default. Have you considered >using the python ConfigAPI sssd has to change the sections rather than >running a sed script? I agree. The patchset in current form does work fine for me in the tests. However, I'd rather wait for a new revision which incorporates changes requested by the Jakub. -- / Alexander Bokovoy From npmccallum at redhat.com Mon May 5 16:40:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 May 2014 12:40:04 -0400 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token Message-ID: <1399308004.3102.3.camel@ipa.example.com> Creating tokens for yourself is the most common operation. Making this the default optimizes for the common case. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0048-Default-the-token-owner-to-the-person-adding-the-tok.patch Type: text/x-patch Size: 1320 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 5 16:41:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 05 May 2014 18:41:13 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly Message-ID: <5367BF29.2070901@redhat.com> 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 https://fedorahosted.org/freeipa/ticket/4136 https://fedorahosted.org/freeipa/ticket/4255 https://fedorahosted.org/freeipa/ticket/3435 https://fedorahosted.org/freeipa/ticket/3050 https://fedorahosted.org/freeipa/ticket/4278 https://fedorahosted.org/freeipa/ticket/4281 https://fedorahosted.org/freeipa/ticket/4282 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0628-webui-remove-old-css-for-standalone-pages.patch Type: text/x-patch Size: 3139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0627-webui-ci-select-search-table-item-chrome-issue.patch Type: text/x-patch Size: 1857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0626-webui-use-BS-alerts-in-validation_summary_widget.patch Type: text/x-patch Size: 7119 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0625-webui-adjust-login-page-to-PatternFly.patch Type: text/x-patch Size: 211135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0624-webui-preload-automember-default-group-select-list.patch Type: text/x-patch Size: 1051 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0623-webui-restyle-automember-default-group.patch Type: text/x-patch Size: 2218 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0622-webui-do-not-show-empty-table-footer.patch Type: text/x-patch Size: 4066 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0621-webui-improve-pagination.patch Type: text/x-patch Size: 8585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0620-webui-activity-indicators.patch Type: text/x-patch Size: 32536 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0619-webui-adjust-association-adder-dialog-to-PatternFly.patch Type: text/x-patch Size: 10159 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0618-webui-patternFly-dialog.patch Type: text/x-patch Size: 9571 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0617-webui-move-user-reset-password-action-to-action-drop.patch Type: text/x-patch Size: 2024 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0616-webui-move-certificate-actions-to-action-dropdown.patch Type: text/x-patch Size: 1339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0615-webui-add-confirmation-to-action-dropdown-actions.patch Type: text/x-patch Size: 7054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0614-webui-remove-select-action.patch Type: text/x-patch Size: 7246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0613-webui-add-space-between-action-buttons-s-icon-and-te.patch Type: text/x-patch Size: 1471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0612-webui-add-action-dropdown.patch Type: text/x-patch Size: 16780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0611-webui-remove-action-list-widget.patch Type: text/x-patch Size: 11819 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0610-webui-use-h1-in-facet-title-instead-of-h3.patch Type: text/x-patch Size: 2193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0609-webui-change-breadcrumb-to-PatternFly.patch Type: text/x-patch Size: 7719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0608-webui-allow-multiple-base-section-layouts.patch Type: text/x-patch Size: 14196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0607-webui-display-undo-and-multivalued-delete-buttons-in.patch Type: text/x-patch Size: 10644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0606-webui-adjust-styles-to-PatternFly.patch Type: text/x-patch Size: 35309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0605-webui-change-navigation-from-RCUE-to-PatternFly.patch Type: text/x-patch Size: 12622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0604-webui-remove-column-sizing-in-tables-use-PF-styles.patch Type: text/x-patch Size: 10060 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0603-webui-change-absolutely-positioned-layout-to-fluid.patch Type: text/x-patch Size: 7343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0602-webui-remove-unused-images.patch Type: text/x-patch Size: 27324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0601-webui-remove-unused-collapsible-feature-from-section.patch Type: text/x-patch Size: 13401 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0600-webui-remove-unused-icons.patch Type: text/x-patch Size: 49066 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0599-webui-remove-remnants-of-jquery-ui.patch Type: text/x-patch Size: 284010 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0598-webui-apply-PatternFly-theme-on-migration-pages.patch Type: text/x-patch Size: 11113 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0597-webui-styles-for-alert-icons.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0596-webui-apply-PatternFly-theme-on-config-pages.patch Type: text/x-patch Size: 23859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0595-webui-apply-PatternFly-login-theme-on-reset_password.patch Type: text/x-patch Size: 9081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0594-webui-add-PaternFly-css.patch Type: text/x-patch Size: 461507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0593-webui-remove-login.html.patch Type: text/x-patch Size: 7897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0592-webui-remove-logout.html.patch Type: text/x-patch Size: 2111 bytes Desc: not available URL: From npmccallum at redhat.com Mon May 5 16:42:40 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 May 2014 12:42:40 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens Message-ID: <1399308160.3102.6.camel@ipa.example.com> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0049-Add-support-for-protected-tokens.patch Type: text/x-patch Size: 13903 bytes Desc: not available URL: From npmccallum at redhat.com Mon May 5 17:10:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 May 2014 13:10:16 -0400 Subject: [Freeipa-devel] [PATCH 0050] Fix typo in token UI javascript comment Message-ID: <1399309816.27590.0.camel@ipa.example.com> Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0050-Fix-typo-in-token-UI-javascript-comment.patch Type: text/x-patch Size: 900 bytes Desc: not available URL: From npmccallum at redhat.com Mon May 5 17:22:13 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 May 2014 13:22:13 -0400 Subject: [Freeipa-devel] [PATCH 0046] Fix a typo in the otptoken doc string In-Reply-To: <53677E1E.2050506@redhat.com> References: <1399067125.2321.9.camel@localhost.localdomain> <53677E1E.2050506@redhat.com> Message-ID: <1399310533.27590.1.camel@ipa.example.com> On Mon, 2014-05-05 at 14:03 +0200, Jan Cholasta wrote: > Hi, > > On 2.5.2014 23:45, Nathaniel McCallum wrote: > > Patch attached > > ACK, but there is one additional occurence of "otp-add" in a comment in > install/ui/src/freeipa/otptoken.js. https://www.redhat.com/archives/freeipa-devel/2014-May/msg00039.html Nathaniel From jcholast at redhat.com Mon May 5 17:25:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 05 May 2014 19:25:10 +0200 Subject: [Freeipa-devel] [PATCH 0050] Fix typo in token UI javascript comment In-Reply-To: <1399309816.27590.0.camel@ipa.example.com> References: <1399309816.27590.0.camel@ipa.example.com> Message-ID: <5367C976.9060305@redhat.com> On 5.5.2014 19:10, Nathaniel McCallum wrote: > Attached. > ACK. -- Jan Cholasta From dpal at redhat.com Tue May 6 00:08:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 May 2014 20:08:10 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1399056727.26263.86.camel@willson.li.ssimo.org> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> <1399056727.26263.86.camel@willson.li.ssimo.org> Message-ID: <536827EA.6070700@redhat.com> On 05/02/2014 02:52 PM, Simo Sorce wrote: > On Thu, 2014-05-01 at 16:22 -0400, Nathaniel McCallum wrote: >> On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: >>> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: >>>> On Tue, 11 Mar 2014, Jan Pazdziora wrote: >>>>> On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: >>>>>> Before this patch, ipa-kdb would load global configuration on startup >>>>>> and never update it. This means that if global configuration is changed, >>>>>> the KDC never receives the new configuration until it is restarted. >>>>>> >>>>>> This patch enables caching of the global configuration with a timeout of >>>>>> 60 seconds. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4153 >>>>>> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 >>>>>> From: Nathaniel McCallum >>>>>> Date: Mon, 24 Feb 2014 14:19:13 -0500 >>>>>> Subject: [PATCH] Periodically refresh global ipa-kdb configuration >>>>>> >>>>>> Before this patch, ipa-kdb would load global configuration on startup and >>>>>> never update it. This means that if global configuration is changed, the >>>>>> KDC never receives the new configuration until it is restarted. >>>>>> >>>>>> This patch enables caching of the global configuration with a timeout of >>>>>> 60 seconds. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4153 >>>>> I have only read the code and it looks sane, so depending on how much >>>>> you consider my word about code-reading worth, ack. >>>>> >>>>> However, my gut feeling is that my preferred way of handling the issue >>>>> (without knowing much about the background of the ticket) would >>>>> probably be a HUP signal handler or something similar, rather than >>>>> polling for current values with the value timeout. This patch >>>>> introduces small nondeterminism to the behaviour when the usage of the >>>>> new values cannot really be enfoced by the admin (without the daemon >>>>> restart). >>>> Thing is, we need the update to happen when other, non-root process >>>> makes the changes -- in our case when IPA server running under httpd >>>> privileges performs series of MS-RPC calls towards smbd which lead to >>>> creating certain LDAP objects. httpd couldn't send SIGHUP to a process >>>> not owned by httpd's effective user (non-root). >>> Yes but this is not really the way to go. >>> >>> The proper fix is to use syncrepl/persistent search to get a >>> notification of when we need to reload the configuration. >>> >>> On the patch itself I have a NACK due to this syntax used in various >>> places: function()->attribute >>> >>> don't. do. that. ever. >>> >>> assign whatever come from the function to a local variable and *check* >>> it is not null, *then* use it. >> Attached patch fixes the NACK issue, but does not address the question >> of the larger approach. Do we need to take a different approach? If so, >> what is it? > LGTM > I might prefer slightly more explicit names for those temp vars, but > that's not a big deal. > > As for the approach, moving to something like syncrepl would be a good > idea. As it would allow us to avoid useless polling and changes would be > applaied as soon as they become available as the syncrepl agreement > would push them to our client. It does mean we need a way to check that > there aren't pending changes coming down the syncrepl pipe, but we can > do that synchronously at every entry point in the KDB. After all we do > not need to care about a change until the KDC needs something from the > KDB. > > Simo. > Do we need a ticket for that then? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From ftweedal at redhat.com Tue May 6 00:57:42 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 6 May 2014 10:57:42 +1000 Subject: [Freeipa-devel] minimum python version Message-ID: <20140506005742.GB24202@dhcp-40-8.bne.redhat.com> Hi all, What's are the versions of Python that must be supported in the freeipa codebase? And do older branches have to support earlier versions? Any Python language features that should be avoided, by policy? Forward-portability considerations? I look forward to your responses and will write it up in the IPA new hire guide! Cheers, Fraser From simo at redhat.com Tue May 6 01:28:36 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 May 2014 21:28:36 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <536827EA.6070700@redhat.com> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> <1399056727.26263.86.camel@willson.li.ssimo.org> <536827EA.6070700@redhat.com> Message-ID: <1399339716.26263.153.camel@willson.li.ssimo.org> On Mon, 2014-05-05 at 20:08 -0400, Dmitri Pal wrote: > On 05/02/2014 02:52 PM, Simo Sorce wrote: > > On Thu, 2014-05-01 at 16:22 -0400, Nathaniel McCallum wrote: > >> On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: > >>> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: > >>>> On Tue, 11 Mar 2014, Jan Pazdziora wrote: > >>>>> On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > >>>>>> Before this patch, ipa-kdb would load global configuration on startup > >>>>>> and never update it. This means that if global configuration is changed, > >>>>>> the KDC never receives the new configuration until it is restarted. > >>>>>> > >>>>>> This patch enables caching of the global configuration with a timeout of > >>>>>> 60 seconds. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/4153 > >>>>>> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > >>>>>> From: Nathaniel McCallum > >>>>>> Date: Mon, 24 Feb 2014 14:19:13 -0500 > >>>>>> Subject: [PATCH] Periodically refresh global ipa-kdb configuration > >>>>>> > >>>>>> Before this patch, ipa-kdb would load global configuration on startup and > >>>>>> never update it. This means that if global configuration is changed, the > >>>>>> KDC never receives the new configuration until it is restarted. > >>>>>> > >>>>>> This patch enables caching of the global configuration with a timeout of > >>>>>> 60 seconds. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/4153 > >>>>> I have only read the code and it looks sane, so depending on how much > >>>>> you consider my word about code-reading worth, ack. > >>>>> > >>>>> However, my gut feeling is that my preferred way of handling the issue > >>>>> (without knowing much about the background of the ticket) would > >>>>> probably be a HUP signal handler or something similar, rather than > >>>>> polling for current values with the value timeout. This patch > >>>>> introduces small nondeterminism to the behaviour when the usage of the > >>>>> new values cannot really be enfoced by the admin (without the daemon > >>>>> restart). > >>>> Thing is, we need the update to happen when other, non-root process > >>>> makes the changes -- in our case when IPA server running under httpd > >>>> privileges performs series of MS-RPC calls towards smbd which lead to > >>>> creating certain LDAP objects. httpd couldn't send SIGHUP to a process > >>>> not owned by httpd's effective user (non-root). > >>> Yes but this is not really the way to go. > >>> > >>> The proper fix is to use syncrepl/persistent search to get a > >>> notification of when we need to reload the configuration. > >>> > >>> On the patch itself I have a NACK due to this syntax used in various > >>> places: function()->attribute > >>> > >>> don't. do. that. ever. > >>> > >>> assign whatever come from the function to a local variable and *check* > >>> it is not null, *then* use it. > >> Attached patch fixes the NACK issue, but does not address the question > >> of the larger approach. Do we need to take a different approach? If so, > >> what is it? > > LGTM > > I might prefer slightly more explicit names for those temp vars, but > > that's not a big deal. > > > > As for the approach, moving to something like syncrepl would be a good > > idea. As it would allow us to avoid useless polling and changes would be > > applaied as soon as they become available as the syncrepl agreement > > would push them to our client. It does mean we need a way to check that > > there aren't pending changes coming down the syncrepl pipe, but we can > > do that synchronously at every entry point in the KDB. After all we do > > not need to care about a change until the KDC needs something from the > > KDB. > > > > Simo. > > > Do we need a ticket for that then? Turns out we already have one: https://fedorahosted.org/freeipa/ticket/1302 Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue May 6 05:55:24 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 6 May 2014 08:55:24 +0300 Subject: [Freeipa-devel] minimum python version In-Reply-To: <20140506005742.GB24202@dhcp-40-8.bne.redhat.com> References: <20140506005742.GB24202@dhcp-40-8.bne.redhat.com> Message-ID: <20140506055524.GE20958@redhat.com> On Tue, 06 May 2014, Fraser Tweedale wrote: >Hi all, > >What's are the versions of Python that must be supported in the >freeipa codebase? And do older branches have to support earlier >versions? > >Any Python language features that should be avoided, by policy? >Forward-portability considerations? We attempt to not overcomplicate backport efforts for stable branches. This means we "stuck" mostly with features provided by the Python 2.6 (2.6.6 in RHEL 6, for example). -- / Alexander Bokovoy From jpazdziora at redhat.com Tue May 6 07:58:53 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 6 May 2014 09:58:53 +0200 Subject: [Freeipa-devel] [PATCH 0001] Adding verb to error message to make it less confusing Message-ID: <20140506075853.GA12732@redhat.com> I found error message Failed to data from service file: Failed to get list of services to probe status: in my logs while experimenting with something and it confused me a bit, hence this patch. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -------------- next part -------------- >From 2f56c201b958b2f7b4610ca12cab0bfbc5bd17a9 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora Date: Tue, 6 May 2014 09:52:21 +0200 Subject: [PATCH] Adding verb to error message to make it less confusing. --- install/tools/ipactl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/ipactl b/install/tools/ipactl index 202081d..fd29132 100755 --- a/install/tools/ipactl +++ b/install/tools/ipactl @@ -232,7 +232,7 @@ def ipa_start(options): try: svc_list = get_config(dirsrv) except Exception, e: - emit_err("Failed to data from service file: " + str(e)) + emit_err("Failed to read data from service file: " + str(e)) emit_err("Shutting down") if not options.force: -- 1.9.0 From pvoborni at redhat.com Tue May 6 08:29:32 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 10:29:32 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added In-Reply-To: <20140505163912.7cb903d1@unused-4-246.brq.redhat.com> References: <20140425171648.754632d7@unused-4-246.brq.redhat.com> <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> <5360E066.5070804@redhat.com> <20140505163912.7cb903d1@unused-4-246.brq.redhat.com> Message-ID: <53689D6C.20204@redhat.com> On 5.5.2014 16:39, Misnyovszki Adam wrote: > On Wed, 30 Apr 2014 13:37:10 +0200 > Petr Vobornik wrote: > >> On 29.4.2014 16:30, Misnyovszki Adam wrote: >>> On Fri, 25 Apr 2014 17:16:48 +0200 >>> Misnyovszki Adam wrote: >>> >>>> Hi, >>>> this patch adds some static test data for the webui otptoken part. >>>> Adam >>> >>> Attached corrected DN's. >>> Thanks >>> Adam >>> >> >> 1) Why otptoken_batch_del.json ends with error? Also there might be >> a defect in UI that for batch delete operation it asks for batch.json >> and not $ENTITY_batch_del.json making otptoken_batch_del.json unused >> - out of scope of this patch. >> >> 2) Why otptoken_mod.json ends with error? >> >> 3) otptoken_find.json is not needed since the search facet uses >> paging (combination of otptoken_get_records.json and >> otptoken_find_pkeys.json is enough). >> >> In general, it's OK to fake the data if there is some bug which >> causes errors and we know that it will be fixed. > > Hi, > see the attached, and corrected 18 patch for otptoken static test data. > Also, I've added patch 20, for fixing the batch_del command in static > webui tests. > > Thanks > Adam > Patch 18-3: 1. otptoken_batch.json, otptoken_batch_del.json, otptoken_mod.json have trailing whitespace after commas 2. otptoken_batch.json was obsoleted by patch 20. Should be removed since both patches are in one patchset. Patch 20: ACK -- Petr Vobornik From tscherf at redhat.com Tue May 6 08:48:04 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 6 May 2014 10:48:04 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed various typos in ipa-client-install man page Message-ID: <20140506084804.GA24244@tscherf.redhat.com> -------------- next part -------------- >From d9ccbfca05f46515ef3de3065b33e21cf5debe80 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Tue, 6 May 2014 10:45:04 +0200 Subject: [PATCH] Fixed various typos in ipa-client-install man page --- ipa-client/man/ipa-client-install.1 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-install.1 index 3d72b0c9f5f5c5dec6314adf9eb02f873918bfda..95d13fac97f4a4ee166e9d0a8c7b762c03710003 100644 --- a/ipa-client/man/ipa-client-install.1 +++ b/ipa-client/man/ipa-client-install.1 @@ -28,7 +28,7 @@ By default this configures SSSD to connect to an IPA server for authentication a An authorized user is required to join a client machine to IPA. This can take the form of a kerberos principal or a one\-time password associated with the machine. -This same tool is used to unconfigure IPA and attempts to return the machine to its previous state. Part of this process is to unenroll the host from the IPA server. Unenrollment consists of disabling the prinicipal key on the IPA server so that it may be re\-enrolled. The machine principal in /etc/krb5.keytab (host/@REALM) is used to authenticate to the IPA server to unenroll itself. If this principal does not exist then unenrollment will fail and an administrator will need to disable the host principal (ipa host\-disable ). +This same tool is used to unconfigure IPA and attempts to return the machine to its previous state. Part of this process is to unenroll the host from the IPA server. Unenrollment consists of disabling the principal key on the IPA server so that it may be re\-enrolled. The machine principal in /etc/krb5.keytab (host/@REALM) is used to authenticate to the IPA server to unenroll itself. If this principal does not exist then unenrollment will fail and an administrator will need to disable the host principal (ipa host\-disable ). .SS "Assumptions" The ipa\-client\-install script assumes that the machine has already generated SSH keys. It will not generate SSH keys of its own accord. If SSH keys are not present (e.g when running the ipa\-client\-install in a kickstart, before ever running sshd), they will not be uploaded to the client host entry on the server. @@ -66,11 +66,11 @@ If this has been the case, host can be re\-enrolled using the usual methods. There are two method of authenticating a re\-enrollment: -1. You can use \-\-force\-join option with ipa\-client\-install command. This authenticates the re\-enrollment using the admin's credetials provided via the \-w/\-\-password option. +1. You can use \-\-force\-join option with ipa\-client\-install command. This authenticates the re\-enrollment using the admin's credentials provided via the \-w/\-\-password option. .br 2. If providing the admin's password via the command line is not an option (e.g you want to create a script to re\-enroll a host and keep the admin's password secure), you can use backed up keytab from the previous enrollment of this host to authenticate. See \-\-keytab option. -Consenquences of the re\-enrollment on the host entry: +Consequences of the re\-enrollment on the host entry: 1. A new host certificate is issued .br -- 1.9.0 From tscherf at redhat.com Tue May 6 09:05:05 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 6 May 2014 11:05:05 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-test-task man page Message-ID: <20140506090505.GC24244@tscherf.redhat.com> -------------- next part -------------- >From df6acd55db562c24ec5e88166d31eeabc026a087 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Tue, 6 May 2014 11:03:15 +0200 Subject: [PATCH] Fixed typo in ipa-test-task man page --- ipatests/man/ipa-test-task.1 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipatests/man/ipa-test-task.1 b/ipatests/man/ipa-test-task.1 index 3f523569951c545c9e516f2c1775871d9653d58a..f6717d3f57a30595cc400de29750ce12306abe3f 100644 --- a/ipatests/man/ipa-test-task.1 +++ b/ipatests/man/ipa-test-task.1 @@ -126,8 +126,8 @@ Based on the relationship of the domains configures the IPA DNS for trust. AD DNS needs to be setup manually. .TP -\fBipa\-test\-task estabilish\-trust\-with\-ad HOST AD\fR -Estabilishes trust with Active Directory. Trust type is detected depending on +\fBipa\-test\-task establish\-trust\-with\-ad HOST AD\fR +Establishes trust with Active Directory. Trust type is detected depending on the presence of SfU (Services for Unix) support on the AD. .TP -- 1.9.0 From pvoborni at redhat.com Tue May 6 10:28:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 12:28:54 +0200 Subject: [Freeipa-devel] [PATCH] 16-17 Attribute box in permission UI is too small In-Reply-To: <20140425130646.62310f4f@unused-4-246.brq.redhat.com> References: <20140425130646.62310f4f@unused-4-246.brq.redhat.com> Message-ID: <5368B966.3080109@redhat.com> On 25.4.2014 13:06, Misnyovszki Adam wrote: > Hi, > first patch redesigns attribute box in permission forms, making it > a bigger scrollable checkboxlist. Second one adds a filter field to it > for better user experience, if the checkboxlist would be too large. > Also, webui unit tests for rbac are updated to work properly with the > new widget. > Thanks > Adam > Patch 16: 1. jslint warnings: - aci.js(559): lint warning: undeclared identifier: attr_container - aci.js(590): lint warning: undeclared identifier: attr_container 2. you can reuse existing create method of checkboxes widget since attribute widget inherits from it. The same with create_options - option_widget_base.create_options will do the trick. But be careful, it expects different param. 2a. in patch 17 you will have to have custom create method, but the code can be very similar to radio_widget.create method. Patch 17: 1. jslint warnings: - aci.js(614): lint warning: missing semicolon 2. too big indentation: + that.filter.keyup(function(e) { + that.filter_options(); 3. ("ul.option_widget.attribute_widget li") matches all options in all attribute widgets in the app. Limit the search to this widget by the context parameter ($node). It will also allow you to use simpler selector. -- Petr Vobornik From tbabej at redhat.com Tue May 6 10:49:06 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 May 2014 12:49:06 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-test-task man page In-Reply-To: <20140506090505.GC24244@tscherf.redhat.com> References: <20140506090505.GC24244@tscherf.redhat.com> Message-ID: <5368BE22.9020701@redhat.com> ACK. On 05/06/2014 11:05 AM, Thorsten Scherf wrote: > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue May 6 10:49:17 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 May 2014 12:49:17 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed various typos in ipa-client-install man page In-Reply-To: <20140506084804.GA24244@tscherf.redhat.com> References: <20140506084804.GA24244@tscherf.redhat.com> Message-ID: <5368BE2D.4060806@redhat.com> ACK. On 05/06/2014 10:48 AM, Thorsten Scherf wrote: > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue May 6 11:12:12 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 May 2014 13:12:12 +0200 Subject: [Freeipa-devel] [PATCHES 180-182] ipatests: Improvements! In-Reply-To: <20140505160836.GD20958@redhat.com> References: <536101A5.4000509@redhat.com> <20140502083632.GB4914@hendrix.brq.redhat.com> <20140505160836.GD20958@redhat.com> Message-ID: <5368C38C.6020506@redhat.com> On 05/05/2014 06:08 PM, Alexander Bokovoy wrote: > On Fri, 02 May 2014, Jakub Hrozek wrote: >> On Wed, Apr 30, 2014 at 03:59:01PM +0200, Tomas Babej wrote: >>> Hi, >>> >>> * patch 180 fixes incorrect hostname usage when connecting to legacy >>> clients >>> * patch 181 sets up SSSD in debug_level 7 by default >>> * patch 182 does the same, but on the legacy clients >>> >>> -- >>> Tomas Babej >>> Associate Software Engineer | Red Hat | Identity Management >>> RHCE | Brno Site | IRC: tbabej | freeipa.org >>> >> >> ACK to the general intent of debug_level by default. Have you considered >> using the python ConfigAPI sssd has to change the sections rather than >> running a sed script? > I agree. > > The patchset in current form does work fine for me in the tests. > However, I'd rather wait for a new revision which incorporates changes > requested by the Jakub. > > I'm not sure using python ConfigAPI would be a better option here, for one particular reason - the tests themselves are not run on the machine where we want to change the config. Hence we need to enclose everything we want done on the client in the run_command method. Moving from sed to using python ConfigAPI would mean moving from: + host.run_command(['sed', '-i', + '/debug_level = 7/d', + '/etc/sssd/sssd.conf' + ], raiseonerr=False) + + # Add the debug directive to each section + host.run_command(['sed', '-i', + '/\[*\]/ a\debug_level = 7', + '/etc/sssd/sssd.conf' + ], raiseonerr=False) to creating the python script file of ~10-15 lines on the client and then running it on the client itself via: + host.run_command(['python', 'set_sssd_debug_level.py']) Given that, it does not seem that much simpler than using two sed commands to me. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Tue May 6 11:21:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:21:54 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa_backup.py In-Reply-To: <1399044040.2321.2.camel@localhost.localdomain> References: <20140502080247.GZ29357@tscherf.redhat.com> <1399044040.2321.2.camel@localhost.localdomain> Message-ID: <5368C5D2.7040408@redhat.com> On 2.5.2014 17:20, Nathaniel McCallum wrote: > ACK > > Nathaniel > Pushed to master: 3f3c8eee24f98807ff8a95dd0f6a022b2b3a5bf5 -- Petr Vobornik From pvoborni at redhat.com Tue May 6 11:24:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:24:39 +0200 Subject: [Freeipa-devel] [PATCH 0046] Fix a typo in the otptoken doc string In-Reply-To: <1399310533.27590.1.camel@ipa.example.com> References: <1399067125.2321.9.camel@localhost.localdomain> <53677E1E.2050506@redhat.com> <1399310533.27590.1.camel@ipa.example.com> Message-ID: <5368C677.5070703@redhat.com> On 5.5.2014 19:22, Nathaniel McCallum wrote: > On Mon, 2014-05-05 at 14:03 +0200, Jan Cholasta wrote: >> Hi, >> >> On 2.5.2014 23:45, Nathaniel McCallum wrote: >>> Patch attached >> >> ACK, but there is one additional occurence of "otp-add" in a comment in >> install/ui/src/freeipa/otptoken.js. > > https://www.redhat.com/archives/freeipa-devel/2014-May/msg00039.html > > Nathaniel > Pushed to master: 797974b09fdd078c8ad645c217a464b69ce72f66 -- Petr Vobornik From tbabej at redhat.com Tue May 6 10:50:08 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 May 2014 12:50:08 +0200 Subject: [Freeipa-devel] [PATCH 0001] Adding verb to error message to make it less confusing In-Reply-To: <20140506075853.GA12732@redhat.com> References: <20140506075853.GA12732@redhat.com> Message-ID: <5368BE60.9020206@redhat.com> ACK On 05/06/2014 09:58 AM, Jan Pazdziora wrote: > I found error message > > Failed to data from service file: Failed to get list of services to probe status: > > in my logs while experimenting with something and it confused me > a bit, hence this patch. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue May 6 11:34:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:34:28 +0200 Subject: [Freeipa-devel] [PATCH] 629 webui: otptoken-adder dialog - remove obsolete comment Message-ID: <5368C8C4.9040806@redhat.com> No longer valid. HOTP tokens are also supported. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0629-webui-otptoken-adder-dialog-remove-obsolete-comment.patch Type: text/x-patch Size: 838 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 6 11:35:37 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:35:37 +0200 Subject: [Freeipa-devel] [PATCH 0050] Fix typo in token UI javascript comment In-Reply-To: <5367C976.9060305@redhat.com> References: <1399309816.27590.0.camel@ipa.example.com> <5367C976.9060305@redhat.com> Message-ID: <5368C909.9020608@redhat.com> On 5.5.2014 19:25, Jan Cholasta wrote: > On 5.5.2014 19:10, Nathaniel McCallum wrote: >> Attached. >> > > ACK. > NACK, the comment is no longer valid and should be removed. New patch: http://www.redhat.com/archives/freeipa-devel/2014-May/msg00057.html -- Petr Vobornik From jcholast at redhat.com Tue May 6 11:46:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 06 May 2014 13:46:23 +0200 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <1399308004.3102.3.camel@ipa.example.com> References: <1399308004.3102.3.camel@ipa.example.com> Message-ID: <5368CB8F.8070906@redhat.com> Hi, On 5.5.2014 18:40, Nathaniel McCallum wrote: > Creating tokens for yourself is the most common operation. Making this > the default optimizes for the common case. The user-find call should be inside the if statement. Also please check if there actually is a result, if you run user-find --whoami when authenticated as non-user, the result will be empty. Honza -- Jan Cholasta From pvoborni at redhat.com Tue May 6 11:47:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:47:03 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-test-task man page In-Reply-To: <5368BE22.9020701@redhat.com> References: <20140506090505.GC24244@tscherf.redhat.com> <5368BE22.9020701@redhat.com> Message-ID: <5368CBB7.4020305@redhat.com> On 6.5.2014 12:49, Tomas Babej wrote: > ACK. > > On 05/06/2014 11:05 AM, Thorsten Scherf wrote: >> Pushed to master: 7646cb8e580f11987c98f1ef81179aecf082eea9 -- Petr Vobornik From pvoborni at redhat.com Tue May 6 11:50:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:50:21 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed various typos in ipa-client-install man page In-Reply-To: <5368BE2D.4060806@redhat.com> References: <20140506084804.GA24244@tscherf.redhat.com> <5368BE2D.4060806@redhat.com> Message-ID: <5368CC7D.8020901@redhat.com> On 6.5.2014 12:49, Tomas Babej wrote: > ACK. > Pushed to master: 7cf683b3bc3f8afef6e52d2ff570f2bea77b7a5e -- Petr Vobornik From pvoborni at redhat.com Tue May 6 11:52:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 13:52:42 +0200 Subject: [Freeipa-devel] [PATCH 0001] Adding verb to error message to make it less confusing In-Reply-To: <5368BE60.9020206@redhat.com> References: <20140506075853.GA12732@redhat.com> <5368BE60.9020206@redhat.com> Message-ID: <5368CD0A.9050205@redhat.com> On 6.5.2014 12:50, Tomas Babej wrote: > ACK > > On 05/06/2014 09:58 AM, Jan Pazdziora wrote: >> I found error message >> >> Failed to data from service file: Failed to get list of services to probe status: >> >> in my logs while experimenting with something and it confused me >> a bit, hence this patch. >> >> Pushed to master: d4e1b05484f41ef7a479861c07685dfe5ca1b73b -- Petr Vobornik From pvoborni at redhat.com Tue May 6 12:16:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 14:16:08 +0200 Subject: [Freeipa-devel] plugin registration refactoring for pwpolicy In-Reply-To: <1399043976.2321.1.camel@localhost.localdomain> References: <20140502140129.040d3681@unused-4-246.brq.redhat.com> <1399043976.2321.1.camel@localhost.localdomain> Message-ID: <5368D288.9050906@redhat.com> On 2.5.2014 17:19, Nathaniel McCallum wrote: > On Fri, 2014-05-02 at 14:01 +0200, Misnyovszki Adam wrote: >> SSIA >> Thanks >> Adam > > Simple enough. ACK. > > Nathaniel > Pushed to master: 2c08a16f8f52927332bd5fde31bc855b2d657afc -- Petr Vobornik From amisnyov at redhat.com Tue May 6 12:22:48 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 6 May 2014 14:22:48 +0200 Subject: [Freeipa-devel] [PATCH] 629 webui: otptoken-adder dialog - remove obsolete comment In-Reply-To: <5368C8C4.9040806@redhat.com> References: <5368C8C4.9040806@redhat.com> Message-ID: <20140506142248.0ef201e0@unused-4-246.brq.redhat.com> On Tue, 06 May 2014 13:34:28 +0200 Petr Vobornik wrote: > No longer valid. HOTP tokens are also supported. ACK From npmccallum at redhat.com Tue May 6 12:23:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 08:23:22 -0400 Subject: [Freeipa-devel] [PATCH 0050] Fix typo in token UI javascript comment In-Reply-To: <5368C909.9020608@redhat.com> References: <1399309816.27590.0.camel@ipa.example.com> <5367C976.9060305@redhat.com> <5368C909.9020608@redhat.com> Message-ID: <1399379002.2416.2.camel@ipa.example.com> On Tue, 2014-05-06 at 13:35 +0200, Petr Vobornik wrote: > On 5.5.2014 19:25, Jan Cholasta wrote: > > On 5.5.2014 19:10, Nathaniel McCallum wrote: > >> Attached. > >> > > > > ACK. > > > > NACK, the comment is no longer valid and should be removed. > > New patch: > http://www.redhat.com/archives/freeipa-devel/2014-May/msg00057.html ACK Nathaniel From npmccallum at redhat.com Tue May 6 12:28:42 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 08:28:42 -0400 Subject: [Freeipa-devel] [PATCH 0051] Validate OTP during password change requests Message-ID: <1399379322.2416.3.camel@ipa.example.com> The pwdch extop would just validate the old password before setting the new one. Becuase this operation returns INVALID_CREDENTIALS when the password is wrong, it provides an opportunity to brute force the first factor distinct from the second factor. This patch causes the pwdch extop to validate the OTP as well. This closes the above attack vector. It is also, conveniently, the behavior most users will probably expect. https://fedorahosted.org/freeipa/ticket/4248 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0051-Validate-OTP-during-password-change-requests.patch Type: text/x-patch Size: 16790 bytes Desc: not available URL: From thozza at redhat.com Tue May 6 12:41:10 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 6 May 2014 08:41:10 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <535016B2.2010809@redhat.com> References: <535016B2.2010809@redhat.com> Message-ID: <685055735.646933.1399380070775.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > This patch set attempts to move ldap_parse_master_zoneentry() a little bit > closer to sane code. > > It is preparation for > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > -- > Petr^2 Spacek > Patches look good. ACK. ACKing of version 2 of the patch 242 will follow. The patch 243 introduced new compilation warning that Peter is aware of. Unfortunately we are unable to find the root cause of it, so leaving it as is for now... Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Tue May 6 12:41:34 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 6 May 2014 08:41:34 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <535116B5.20606@redhat.com> References: <535016B2.2010809@redhat.com> <535116B5.20606@redhat.com> Message-ID: <2084648494.647138.1399380094380.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 17.4.2014 20:00, Petr Spacek wrote: > > Hello, > > > > This patch set attempts to move ldap_parse_master_zoneentry() a little bit > > closer to sane code. > > > > It is preparation for > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > bind-dyndb-ldap-pspacek-0242-2-Refactor-master-zone-configuration.patch fixes > zone loading for zones without idnsAllowTransfer attribute in LDAP. > > Previously, the plugin refused to load such zones with error ISC_R_NOTFOUND - > missing attribute was treated as fatal error. > > -- > Petr^2 Spacek > ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From abokovoy at redhat.com Tue May 6 12:56:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 6 May 2014 15:56:56 +0300 Subject: [Freeipa-devel] bind DN of executing command In-Reply-To: <536798A8.6000000@redhat.com> References: <1399064766.2321.8.camel@localhost.localdomain> <20140505072543.GG4165@localhost.localdomain> <536798A8.6000000@redhat.com> Message-ID: <20140506125656.GG20958@redhat.com> On Mon, 05 May 2014, Rob Crittenden wrote: >Sumit Bose wrote: >>On Fri, May 02, 2014 at 05:06:06PM -0400, Nathaniel McCallum wrote: >>>I need the DN of the user who is running the current command. This may >>>be defined as the user who is bound or will bind to execute the LDAP >>>commands I have prepared. >>> >>>Does anyone know how to do this in the FreeIPA api? >> >>I guess you are looking for >> >> ipa user-find --whoami > >If you're doing this in your own plugin, you get the current principal with: > >getattr(context, 'principal') > >Using that you can get the DN of that user with a search like this: > >"(&(objectclass=posixaccount)(krbprincipalname=%s))" % >getattr(context, 'principal') > >We don't currently have a helper for this. > >This is rather inefficient in user-find as it searches from the >basedn rather than the user container for some reason. We have whoami plugin enabled by default in 389-ds in FreeIPA. I'd rather use that extended operation as it will give you proper response from the dirsrv side for the connection. I verified that it gives you a user's DN even when S4U2Proxy is in use. -- / Alexander Bokovoy From npmccallum at redhat.com Tue May 6 13:16:00 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 09:16:00 -0400 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <5368CB8F.8070906@redhat.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> Message-ID: <1399382160.2416.5.camel@ipa.example.com> On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: > Hi, > > On 5.5.2014 18:40, Nathaniel McCallum wrote: > > Creating tokens for yourself is the most common operation. Making this > > the default optimizes for the common case. > > The user-find call should be inside the if statement. This is actually for a reason. See my patch 0049 for further context. > Also please check > if there actually is a result, if you run user-find --whoami when > authenticated as non-user, the result will be empty. Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0048.1-Default-the-token-owner-to-the-person-adding-the-tok.patch Type: text/x-patch Size: 1434 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 6 13:18:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 09:18:14 -0400 Subject: [Freeipa-devel] [PATCH 0051] Validate OTP during password change requests In-Reply-To: <1399379322.2416.3.camel@ipa.example.com> References: <1399379322.2416.3.camel@ipa.example.com> Message-ID: <1399382294.2416.7.camel@ipa.example.com> On Tue, 2014-05-06 at 08:28 -0400, Nathaniel McCallum wrote: > The pwdch extop would just validate the old password before setting the > new one. Becuase this operation returns INVALID_CREDENTIALS when the > password is wrong, it provides an opportunity to brute force the first > factor distinct from the second factor. > > This patch causes the pwdch extop to validate the OTP as well. This > closes the above attack vector. It is also, conveniently, the behavior > most users will probably expect. > > https://fedorahosted.org/freeipa/ticket/4248 This patch was posted for posterity/record. However, on the call this morning we decided NOT to do this validation. Please do not review this patch. :) Nathaniel From npmccallum at redhat.com Tue May 6 13:21:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 09:21:23 -0400 Subject: [Freeipa-devel] bind DN of executing command In-Reply-To: <20140506125656.GG20958@redhat.com> References: <1399064766.2321.8.camel@localhost.localdomain> <20140505072543.GG4165@localhost.localdomain> <536798A8.6000000@redhat.com> <20140506125656.GG20958@redhat.com> Message-ID: <1399382483.2416.10.camel@ipa.example.com> On Tue, 2014-05-06 at 15:56 +0300, Alexander Bokovoy wrote: > On Mon, 05 May 2014, Rob Crittenden wrote: > >Sumit Bose wrote: > >>On Fri, May 02, 2014 at 05:06:06PM -0400, Nathaniel McCallum wrote: > >>>I need the DN of the user who is running the current command. This may > >>>be defined as the user who is bound or will bind to execute the LDAP > >>>commands I have prepared. > >>> > >>>Does anyone know how to do this in the FreeIPA api? > >> > >>I guess you are looking for > >> > >> ipa user-find --whoami > > > >If you're doing this in your own plugin, you get the current principal with: > > > >getattr(context, 'principal') > > > >Using that you can get the DN of that user with a search like this: > > > >"(&(objectclass=posixaccount)(krbprincipalname=%s))" % > >getattr(context, 'principal') > > > >We don't currently have a helper for this. > > > >This is rather inefficient in user-find as it searches from the > >basedn rather than the user container for some reason. > We have whoami plugin enabled by default in 389-ds in FreeIPA. I'd > rather use that extended operation as it will give you proper response > from the dirsrv side for the connection. > > I verified that it gives you a user's DN even when S4U2Proxy is in use. The context of this question is now my patch 0048. I'm currently calling self.api.Command.user_find(whoami=True) (per the first suggestion). Feel free to make suggestions in that review. Nathaniel From npmccallum at redhat.com Tue May 6 13:49:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 09:49:46 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399308160.3102.6.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> Message-ID: <1399384186.2416.13.camel@ipa.example.com> 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 Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0049.1-Add-support-for-protected-tokens.patch Type: text/x-patch Size: 14051 bytes Desc: not available URL: From jcholast at redhat.com Tue May 6 14:11:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 06 May 2014 16:11:20 +0200 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <1399382160.2416.5.camel@ipa.example.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> Message-ID: <5368ED88.5030808@redhat.com> On 6.5.2014 15:16, Nathaniel McCallum wrote: > On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: >> Hi, >> >> On 5.5.2014 18:40, Nathaniel McCallum wrote: >>> Creating tokens for yourself is the most common operation. Making this >>> the default optimizes for the common case. >> >> The user-find call should be inside the if statement. > > This is actually for a reason. See my patch 0049 for further context. IMO something like this would be better: if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in entry_attrs: result = self.api.Command.user_find(whoami=True)['result'] if result: cur_uid = result[0]['uid'][0] prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) if cur_uid != prev_uid: entry_attrs.setdefault('ipatokenprotected', True) > >> Also please check >> if there actually is a result, if you run user-find --whoami when >> authenticated as non-user, the result will be empty. > > Fixed. > > Nathaniel > -- Jan Cholasta From npmccallum at redhat.com Tue May 6 14:51:30 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 10:51:30 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation Message-ID: <1399387890.9864.0.camel@ipa.example.com> Specifying the default in the LDAP Object causes the parameter to be specified for non-add operations. This is especially problematic when performing the modify operation as it causes the primary key to change for every modification. https://fedorahosted.org/freeipa/ticket/4227 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0052-Only-specify-the-ipatokenuniqueid-default-in-the-add.patch Type: text/x-patch Size: 1792 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 6 15:04:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 17:04:46 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1399387890.9864.0.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> Message-ID: <5368FA0E.8070107@redhat.com> On 6.5.2014 16:51, Nathaniel McCallum wrote: > Specifying the default in the LDAP Object causes the parameter to be > specified for non-add operations. This is especially problematic when > performing the modify operation as it causes the primary key to change > for every modification. > > https://fedorahosted.org/freeipa/ticket/4227 > shouldn't removal of `autofill=True,` be enough? -- Petr Vobornik From npmccallum at redhat.com Tue May 6 15:07:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 11:07:43 -0400 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <5368ED88.5030808@redhat.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> Message-ID: <1399388863.9864.1.camel@ipa.example.com> On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote: > On 6.5.2014 15:16, Nathaniel McCallum wrote: > > On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: > >> Hi, > >> > >> On 5.5.2014 18:40, Nathaniel McCallum wrote: > >>> Creating tokens for yourself is the most common operation. Making this > >>> the default optimizes for the common case. > >> > >> The user-find call should be inside the if statement. > > > > This is actually for a reason. See my patch 0049 for further context. > > IMO something like this would be better: > > if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in > entry_attrs: > result = self.api.Command.user_find(whoami=True)['result'] > if result: > cur_uid = result[0]['uid'][0] > prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) > if cur_uid != prev_uid: > entry_attrs.setdefault('ipatokenprotected', True) Fixed (see also my new revision of patch 0049). Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0048.2-Default-the-token-owner-to-the-person-adding-the-tok.patch Type: text/x-patch Size: 1338 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 6 15:08:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 11:08:59 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399384186.2416.13.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> Message-ID: <1399388939.9864.2.camel@ipa.example.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0049.2-Add-support-for-protected-tokens.patch Type: text/x-patch Size: 14434 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 6 15:13:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 11:13:43 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <5368FA0E.8070107@redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> Message-ID: <1399389223.9864.3.camel@ipa.example.com> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > On 6.5.2014 16:51, Nathaniel McCallum wrote: > > Specifying the default in the LDAP Object causes the parameter to be > > specified for non-add operations. This is especially problematic when > > performing the modify operation as it causes the primary key to change > > for every modification. > > > > https://fedorahosted.org/freeipa/ticket/4227 > > > > shouldn't removal of `autofill=True,` be enough? Removing autofill=True results in the default not being used for the otptoken-add operation. That may be a different bug (I'm not sure what the expectation of autofill is). Nathaniel From pspacek at redhat.com Tue May 6 15:15:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 06 May 2014 17:15:31 +0200 Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <685055735.646933.1399380070775.JavaMail.zimbra@redhat.com> References: <535016B2.2010809@redhat.com> <685055735.646933.1399380070775.JavaMail.zimbra@redhat.com> Message-ID: <5368FC93.2090703@redhat.com> On 6.5.2014 14:41, Tomas Hozza wrote: > ----- Original Message ----- >> Hello, >> >> This patch set attempts to move ldap_parse_master_zoneentry() a little bit >> closer to sane code. >> >> It is preparation for >> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >> >> -- >> Petr^2 Spacek >> > > Patches look good. > > ACK. > > ACKing of version 2 of the patch 242 will follow. The patch 243 introduced new compilation > warning that Peter is aware of. Unfortunately we are unable to find the root cause of it, > so leaving it as is for now... I managed to find & fix one problem (see new version of the patch 243) but GCC still complains. ../../src/ldap_helper.c: In function 'update_zone': ../../src/ldap_helper.c:2334:34: error: 'data_changed' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (sync_state == sync_finished && data_changed == ISC_TRUE) ^ ../../src/ldap_helper.c:2218:16: note: 'data_changed' was declared here isc_boolean_t data_changed; On my machine with gcc-4.8.2-7.fc20.x86_64 this happens only with -O2. I'm not able to reproduce this with clang-3.4-6.fc20.x86_64 but it is no so surprising - Clang didn't catch even the first case (fixed by patch version 2). Any hint what is wrong or how to refactor code will be appreciated! ;-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0243-2-Refactor-zone-apex-synchronization-and-serial-mainte.patch Type: text/x-patch Size: 11999 bytes Desc: not available URL: From dpal at redhat.com Tue May 6 15:27:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 06 May 2014 11:27:29 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399388939.9864.2.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> Message-ID: <5368FF61.4010507@redhat.com> On 05/06/2014 11:08 AM, 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 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Have we recorded any new OIDs added as a part of this OTP cleanup in our OID registry? If not we should collect all added attributes and make sure they are recorded. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue May 6 15:34:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 May 2014 17:34:22 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1399389223.9864.3.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> Message-ID: <536900FE.6090901@redhat.com> On 6.5.2014 17:13, Nathaniel McCallum wrote: > On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: >> On 6.5.2014 16:51, Nathaniel McCallum wrote: >>> Specifying the default in the LDAP Object causes the parameter to be >>> specified for non-add operations. This is especially problematic when >>> performing the modify operation as it causes the primary key to change >>> for every modification. >>> >>> https://fedorahosted.org/freeipa/ticket/4227 >>> >> >> shouldn't removal of `autofill=True,` be enough? > > Removing autofill=True results in the default not being used for the > otptoken-add operation. That may be a different bug (I'm not sure what > the expectation of autofill is). > > Nathaniel > Seems to work form me with: diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 --- a/ipalib/plugins/otptoken.py +++ b/ipalib/plugins/otptoken.py @@ -121,9 +121,7 @@ class otptoken(LDAPObject): cli_name='id', label=_('Unique ID'), default_from=lambda: unicode(uuid.uuid4()), - autofill=True, primary_key=True, - flags=('optional_create'), ), StrEnum('type?', label=_('Type'), -- Petr Vobornik From npmccallum at redhat.com Tue May 6 15:38:38 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 11:38:38 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <536900FE.6090901@redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> Message-ID: <1399390718.9864.5.camel@ipa.example.com> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > On 6.5.2014 17:13, Nathaniel McCallum wrote: > > On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > >> On 6.5.2014 16:51, Nathaniel McCallum wrote: > >>> Specifying the default in the LDAP Object causes the parameter to be > >>> specified for non-add operations. This is especially problematic when > >>> performing the modify operation as it causes the primary key to change > >>> for every modification. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4227 > >>> > >> > >> shouldn't removal of `autofill=True,` be enough? > > > > Removing autofill=True results in the default not being used for the > > otptoken-add operation. That may be a different bug (I'm not sure what > > the expectation of autofill is). > > > > Nathaniel > > > > Seems to work form me with: > > diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py > index f68ea7d..623f1f1 100644 > --- a/ipalib/plugins/otptoken.py > +++ b/ipalib/plugins/otptoken.py > @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > cli_name='id', > label=_('Unique ID'), > default_from=lambda: unicode(uuid.uuid4()), > - autofill=True, > primary_key=True, > - flags=('optional_create'), > ), > StrEnum('type?', > label=_('Type'), Doing this causes the ipa otptoken-add command to prompt for the Unique ID. This may be the desired behavior, but it is not how it worked previously (no prompt). Nathaniel From npmccallum at redhat.com Tue May 6 15:46:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 11:46:14 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1399390718.9864.5.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> Message-ID: <1399391174.9864.6.camel@ipa.example.com> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > > On 6.5.2014 17:13, Nathaniel McCallum wrote: > > > On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > > >> On 6.5.2014 16:51, Nathaniel McCallum wrote: > > >>> Specifying the default in the LDAP Object causes the parameter to be > > >>> specified for non-add operations. This is especially problematic when > > >>> performing the modify operation as it causes the primary key to change > > >>> for every modification. > > >>> > > >>> https://fedorahosted.org/freeipa/ticket/4227 > > >>> > > >> > > >> shouldn't removal of `autofill=True,` be enough? > > > > > > Removing autofill=True results in the default not being used for the > > > otptoken-add operation. That may be a different bug (I'm not sure what > > > the expectation of autofill is). > > > > > > Nathaniel > > > > > > > Seems to work form me with: > > > > diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py > > index f68ea7d..623f1f1 100644 > > --- a/ipalib/plugins/otptoken.py > > +++ b/ipalib/plugins/otptoken.py > > @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > > cli_name='id', > > label=_('Unique ID'), > > default_from=lambda: unicode(uuid.uuid4()), > > - autofill=True, > > primary_key=True, > > - flags=('optional_create'), > > ), > > StrEnum('type?', > > label=_('Type'), > > Doing this causes the ipa otptoken-add command to prompt for the Unique > ID. This may be the desired behavior, but it is not how it worked > previously (no prompt). Here is an alternate patch for this second approach. I have no strong opinion on the correct behavior here. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0052a-Only-use-the-ipatokenuniqueid-default-in-the-add-ope.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: From amisnyov at redhat.com Tue May 6 15:54:12 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 6 May 2014 17:54:12 +0200 Subject: [Freeipa-devel] [PATCH] 20 Trust add datetime fix Message-ID: <20140506175412.19ba3659@unused-4-246.brq.redhat.com> Hi, this patch fixes trust add, since now datetime object is returned for 'modifytimestamp', which cannot be split like a string, thus causing an error. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0021-Trust-add-datetime-fix.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 6 15:56:02 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 11:56:02 -0400 Subject: [Freeipa-devel] [PATCH] 20 Trust add datetime fix In-Reply-To: <20140506175412.19ba3659@unused-4-246.brq.redhat.com> References: <20140506175412.19ba3659@unused-4-246.brq.redhat.com> Message-ID: <1399391762.9864.7.camel@ipa.example.com> On Tue, 2014-05-06 at 17:54 +0200, Misnyovszki Adam wrote: > Hi, > this patch fixes trust add, since now datetime object is returned for > 'modifytimestamp', which cannot be split like a string, thus causing an > error. ACK. Nathaniel From amisnyov at redhat.com Tue May 6 15:58:09 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 6 May 2014 17:58:09 +0200 Subject: [Freeipa-devel] [PATCH] 22-23 webui tests extended by checking field disable property Message-ID: <20140506175809.7cfd4238@unused-4-246.brq.redhat.com> Hi, first patch extends webui tests with a callback function, and an assert_disabled function, to check if a field is disabled under certain conditions. Second patch extends range tests with this checking functionality depending on range types. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0022-webui-tests-callback-assert_disabled-feature-added.patch Type: text/x-patch Size: 2469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0023-webui-tests-range-test-extended.patch Type: text/x-patch Size: 1513 bytes Desc: not available URL: From abokovoy at redhat.com Tue May 6 16:15:11 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 6 May 2014 19:15:11 +0300 Subject: [Freeipa-devel] [PATCH] 20 Trust add datetime fix In-Reply-To: <1399391762.9864.7.camel@ipa.example.com> References: <20140506175412.19ba3659@unused-4-246.brq.redhat.com> <1399391762.9864.7.camel@ipa.example.com> Message-ID: <20140506161511.GH20958@redhat.com> On Tue, 06 May 2014, Nathaniel McCallum wrote: >On Tue, 2014-05-06 at 17:54 +0200, Misnyovszki Adam wrote: >> Hi, >> this patch fixes trust add, since now datetime object is returned for >> 'modifytimestamp', which cannot be split like a string, thus causing an >> error. > >ACK. Thanks. Pushed to master: fa7057b72723a7999dffc1de9bdf97d13f12079c -- / Alexander Bokovoy From npmccallum at redhat.com Tue May 6 17:55:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 06 May 2014 13:55:09 -0400 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <20140505155826.GA20958@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> Message-ID: <1399398909.9864.19.camel@ipa.example.com> I know it is a bit late on this, but for the OTP token import script, I have to have support for the full ISO 8601. My plan right now is to use python-dateutil for this. Using dateutil would simplify some of this code. Is there a reason we aren't using dateutil? On Mon, 2014-05-05 at 18:58 +0300, Alexander Bokovoy wrote: > On Wed, 30 Apr 2014, Tomas Babej wrote: > > > >On 04/25/2014 11:08 AM, Jan Cholasta wrote: > >> On 22.4.2014 13:32, Tomas Babej wrote: > >>> Thank you for the suggestions. Updated, rebased patch is attached. > >>> > >> > >> This API.txt change from the next patch belongs in this patch: > >> > >> +capability: datetime_values 2.84 > >> > >> > >> I think you should use the LDAP_GENERALIZED_TIME_FORMAT constant here: > >> > >> + accepted_formats = ['%Y%m%d%H%M%SZ', # generalized time > >> > >> > >> This is not right: > >> > >> + elif isinstance(val, datetime.datetime): > >> + return val > >> > >> To actually decode LDAP generalized time attributes to datetime, you > >> need to do this: > >> > >> '2.16.840.1.113719.1.301.4.41.1' : DN, # krbSubTrees > >> '2.16.840.1.113719.1.301.4.52.1' : DN, # krbObjectReferences > >> '2.16.840.1.113719.1.301.4.53.1' : DN, # krbPrincContainerRef > >> + > >> + '1.3.6.1.4.1.1466.115.121.1.24' : datetime.datetime, > >> } > >> > >> # In most cases we lookup the syntax from the schema returned by > >> > >> and this: > >> > >> return val > >> elif target_type is unicode: > >> return val.decode('utf-8') > >> + elif target_type is datetime.datetime: > >> + return datetime.datetime.strptime(val, > >> LDAP_GENERALIZED_TIME_FORMAT) > >> else: > >> return target_type(val) > >> except Exception, e: > >> > >> and add code for formatting datetime values to the textui backend. > >> > > > >Thanks for the review. I fixed all the issues, updated patch is attached. > > > >I also added unit tests for the new DateTime parameter. > Thanks, tested them as part of kerberos principal expiration time > patches. > > Pushed two patches to git master. > From lslebodn at redhat.com Tue May 6 20:11:38 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 6 May 2014 22:11:38 +0200 Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <5368FC93.2090703@redhat.com> References: <535016B2.2010809@redhat.com> <685055735.646933.1399380070775.JavaMail.zimbra@redhat.com> <5368FC93.2090703@redhat.com> Message-ID: <20140506201137.GA1129@mail.corp.redhat.com> On (06/05/14 17:15), Petr Spacek wrote: >On 6.5.2014 14:41, Tomas Hozza wrote: >>----- Original Message ----- >>>Hello, >>> >>>This patch set attempts to move ldap_parse_master_zoneentry() a little bit >>>closer to sane code. >>> >>>It is preparation for >>>https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >>> >>>-- >>>Petr^2 Spacek >>> >> >>Patches look good. >> >>ACK. >> >>ACKing of version 2 of the patch 242 will follow. The patch 243 introduced new compilation >>warning that Peter is aware of. Unfortunately we are unable to find the root cause of it, >>so leaving it as is for now... > >I managed to find & fix one problem (see new version of the patch >243) but GCC still complains. > >../../src/ldap_helper.c: In function 'update_zone': >../../src/ldap_helper.c:2334:34: error: 'data_changed' may be used >uninitialized in this function [-Werror=maybe-uninitialized] > if (sync_state == sync_finished && data_changed == ISC_TRUE) > ^ >../../src/ldap_helper.c:2218:16: note: 'data_changed' was declared here > isc_boolean_t data_changed; > >On my machine with gcc-4.8.2-7.fc20.x86_64 this happens only with -O2. > The same problem with -01,-Os,-O2 or -O3 I doubt it is false possibive, because I could reproduce it even with gcc-4.9.0-1.fc21.x86_64 >I'm not able to reproduce this with clang-3.4-6.fc20.x86_64 but it is >no so surprising - Clang didn't catch even the first case (fixed by >patch version 2). > >Any hint what is wrong or how to refactor code will be appreciated! ;-) > I think it can be some kind of optimization in function zone_sync_apex. You can try to debug this function with plugin "-O2"-build :-) The warning can be suppresed with initialising variable before the 1st CHECK. It will not work if you try to initialize later. --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -2116,6 +2116,7 @@ zone_sync_apex(const ldap_instance_t * const inst, isc_uint32_t curr_serial; INIT_LIST(rdatalist); + *data_changed = ISC_FALSE; CHECK(setting_get_str("fake_mname", inst->local_settings, &fake_mname)); CHECK(ldap_parse_rrentry(inst->mctx, entry, &name, fake_mname, >-- >Petr^2 Spacek LS From rcritten at redhat.com Tue May 6 20:59:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 May 2014 16:59:55 -0400 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup Message-ID: <53694D4B.60700@redhat.com> Remove some unused files, fix an import which means we don't need to import from ipaserver, fix up Requires so it should work better running on a different box than the IPA server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1107-smartproxy.patch Type: text/x-patch Size: 5658 bytes Desc: not available URL: From jcholast at redhat.com Wed May 7 08:06:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 May 2014 10:06:09 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <1399398909.9864.19.camel@ipa.example.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> Message-ID: <5369E971.4020503@redhat.com> On 6.5.2014 19:55, Nathaniel McCallum wrote: > I know it is a bit late on this, but for the OTP token import script, I > have to have support for the full ISO 8601. My plan right now is to use > python-dateutil for this. > > Using dateutil would simplify some of this code. Is there a reason we > aren't using dateutil? IIRC it was rejected right at the beginning as an overkill. -- Jan Cholasta From jcholast at redhat.com Wed May 7 09:42:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 May 2014 11:42:29 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399388939.9864.2.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> Message-ID: <536A0005.7090101@redhat.com> 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? 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. Honza -- Jan Cholasta From pvoborni at redhat.com Wed May 7 11:01:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 13:01:13 +0200 Subject: [Freeipa-devel] [PATCH] 629 webui: otptoken-adder dialog - remove obsolete comment In-Reply-To: <20140506142248.0ef201e0@unused-4-246.brq.redhat.com> References: <5368C8C4.9040806@redhat.com> <20140506142248.0ef201e0@unused-4-246.brq.redhat.com> Message-ID: <536A1279.5050304@redhat.com> On 6.5.2014 14:22, Misnyovszki Adam wrote: > On Tue, 06 May 2014 13:34:28 +0200 > Petr Vobornik wrote: > >> No longer valid. HOTP tokens are also supported. > > ACK > Pushed to master: c4d79eaf59a8bc50ca2e18d704b240e18d6d6e68 -- Petr Vobornik From tbabej at redhat.com Wed May 7 13:05:35 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 May 2014 15:05:35 +0200 Subject: [Freeipa-devel] [PATCH 0003] freeipa-ci: Remove freeipa packages before distro-sync in build Message-ID: <536A2F9F.3030903@redhat.com> Hi, this fixes the problem on builders, which do distro-sync while having freeipa packages present from previous build run. This causes unnecessary downgrades., which may result into failures (as now with the smartproxy pushed). -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ci-tbabej-0003-Remove-freeipa-packages-before-distro-sync-in-build.patch Type: text/x-patch Size: 991 bytes Desc: not available URL: From npmccallum at redhat.com Wed May 7 13:05:36 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 07 May 2014 09:05:36 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <536A0005.7090101@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> Message-ID: <1399467936.3786.5.camel@ipa.example.com> 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. Nathaniel From amisnyov at redhat.com Wed May 7 13:16:44 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 7 May 2014 15:16:44 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added In-Reply-To: <53689D6C.20204@redhat.com> References: <20140425171648.754632d7@unused-4-246.brq.redhat.com> <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> <5360E066.5070804@redhat.com> <20140505163912.7cb903d1@unused-4-246.brq.redhat.com> <53689D6C.20204@redhat.com> Message-ID: <20140507151644.0a96d348@unused-4-246.brq.redhat.com> On Tue, 06 May 2014 10:29:32 +0200 Petr Vobornik wrote: > On 5.5.2014 16:39, Misnyovszki Adam wrote: > > On Wed, 30 Apr 2014 13:37:10 +0200 > > Petr Vobornik wrote: > > > >> On 29.4.2014 16:30, Misnyovszki Adam wrote: > >>> On Fri, 25 Apr 2014 17:16:48 +0200 > >>> Misnyovszki Adam wrote: > >>> > >>>> Hi, > >>>> this patch adds some static test data for the webui otptoken > >>>> part. Adam > >>> > >>> Attached corrected DN's. > >>> Thanks > >>> Adam > >>> > >> > >> 1) Why otptoken_batch_del.json ends with error? Also there might > >> be a defect in UI that for batch delete operation it asks for > >> batch.json and not $ENTITY_batch_del.json making > >> otptoken_batch_del.json unused > >> - out of scope of this patch. > >> > >> 2) Why otptoken_mod.json ends with error? > >> > >> 3) otptoken_find.json is not needed since the search facet uses > >> paging (combination of otptoken_get_records.json and > >> otptoken_find_pkeys.json is enough). > >> > >> In general, it's OK to fake the data if there is some bug which > >> causes errors and we know that it will be fixed. > > > > Hi, > > see the attached, and corrected 18 patch for otptoken static test > > data. Also, I've added patch 20, for fixing the batch_del command > > in static webui tests. > > > > Thanks > > Adam > > > > Patch 18-3: > > 1. otptoken_batch.json, otptoken_batch_del.json, otptoken_mod.json > have trailing whitespace after commas > 2. otptoken_batch.json was obsoleted by patch 20. Should be removed > since both patches are in one patchset. > > Patch 20: > ACK See attached fix for patch 18 Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0018-4-webui-OTP-token-test-data-added.patch Type: text/x-patch Size: 12404 bytes Desc: not available URL: From amisnyov at redhat.com Wed May 7 13:21:32 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 7 May 2014 15:21:32 +0200 Subject: [Freeipa-devel] [PATCH] 22-23 webui tests extended by checking field disable property In-Reply-To: <20140506175809.7cfd4238@unused-4-246.brq.redhat.com> References: <20140506175809.7cfd4238@unused-4-246.brq.redhat.com> Message-ID: <20140507152132.379302e0@unused-4-246.brq.redhat.com> On Tue, 6 May 2014 17:58:09 +0200 Misnyovszki Adam wrote: > Hi, > first patch extends webui tests with a callback function, and an > assert_disabled function, to check if a field is disabled under > certain conditions. > Second patch extends range tests with this checking functionality > depending on range types. > Thanks > Adam Fixed issue in 22, when the element, which is checked, doesn't exist, test returns false positive. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0022-2-webui-tests-callback-assert_disabled-feature-added.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: From pspacek at redhat.com Wed May 7 13:22:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 07 May 2014 15:22:43 +0200 Subject: [Freeipa-devel] [PATCH 0246-0248] Follow query/transfer/update policies for secure zones In-Reply-To: <5357E6D5.5060704@redhat.com> References: <5357E6D5.5060704@redhat.com> Message-ID: <536A33A3.4070602@redhat.com> On 23.4.2014 18:14, Petr Spacek wrote: > This patch set configures secure zones according to policies in LDAP. Patch 246 v2 fixes incorrect ATTR_NONNULLS usage which causes segfaults when compiled with -O0. Patch 246 v2 obsoletes patch 253. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0246-2-Move-secure-zone-configuration-from-create_zone-to-z.patch Type: text/x-patch Size: 3761 bytes Desc: not available URL: From pspacek at redhat.com Wed May 7 13:24:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 07 May 2014 15:24:22 +0200 Subject: [Freeipa-devel] [PATCH 0244-0245] Add basic support for inline-signingSeparate raw and secure zones in Zone Register In-Reply-To: <5351405B.7000003@redhat.com> References: <5351405B.7000003@redhat.com> Message-ID: <536A3406.8000407@redhat.com> On 18.4.2014 17:10, Petr Spacek wrote: > Hello, > > Add basic support for inline-signing. > > Inline-signing is enabled for zones with idnsSecInlineSigning attribute = TRUE. > > Limitations: > - Signing configuration is hardcoded in create_zone() as magic constants > - idnsSecInlineSigning attribute cannot be changed at run-time > - DNS updates are not supported > - Signing keys have to be pre-generated and stored in > ///keys > directory before named is started > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 Patch 244 v2 fixes incorrect ATTR_NONNULLS usage which causes segfaults when compiled with -O0. Patch 244 v2 obsoletes patch 253. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0244-2-Separate-raw-and-secure-zones-in-Zone-Register.patch Type: text/x-patch Size: 13738 bytes Desc: not available URL: From pspacek at redhat.com Wed May 7 13:27:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 07 May 2014 15:27:19 +0200 Subject: [Freeipa-devel] [PATCH 0251-0256] Add support for NSEC3 In-Reply-To: <53601AD2.9070806@redhat.com> References: <53601AD2.9070806@redhat.com> Message-ID: <536A34B7.5000400@redhat.com> On 29.4.2014 23:34, Petr Spacek wrote: > This patch set adds support for NSEC3. See commit messages for details. Patch 253 was obsoleted by patches 244v2 and 246v2. You can download latest & greatest version from dnssec branch on github: https://github.com/spacekpe/bind-dyndb-ldap/tree/dnssec -- Petr^2 Spacek From tbabej at redhat.com Wed May 7 13:38:40 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 May 2014 15:38:40 +0200 Subject: [Freeipa-devel] [PATCH] 584 migration: fix import of wsgiref.util In-Reply-To: <20140401072515.GE3872@redhat.com> References: <533A60FD.6080707@redhat.com> <20140401072515.GE3872@redhat.com> Message-ID: <536A3760.1010501@redhat.com> On 04/01/2014 09:25 AM, Jan Pazdziora wrote: > On Tue, Apr 01, 2014 at 08:47:25AM +0200, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/4293 >> -- >> Petr Vobornik >> From dc4eaf9d622b4eac9fb3d942b23083bfb903be9a Mon Sep 17 00:00:00 2001 >> From: Petr Vobornik >> Date: Tue, 1 Apr 2014 08:45:08 +0200 >> Subject: [PATCH] migration: fix import of wsgiref.util >> >> https://fedorahosted.org/freeipa/ticket/4293 >> --- >> install/migration/migration.py | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/install/migration/migration.py b/install/migration/migration.py >> index 27e23a59f660c791c12948b4c40406d03b0f0966..acc1ee48dd8744f6abd2d7a59f0d5feb54fc93f9 100644 >> --- a/install/migration/migration.py >> +++ b/install/migration/migration.py >> @@ -23,7 +23,7 @@ Password migration script >> import cgi >> import errno >> import glob >> -import wsgiref >> +from wsgiref.util import request_uri >> >> from ipapython.ipa_log_manager import root_logger >> from ipapython.ipautil import get_ipa_basedn >> @@ -37,7 +37,7 @@ def wsgi_redirect(start_response, loc): >> return [] >> >> def get_ui_url(environ): >> - full_url = wsgiref.util.request_uri(environ) >> + full_url = request_uri(environ) > Sadly, this antipattern seems needed even if the proper solution would > be to fix wsgi to properly export util. Is there bug filed for that. > > Ack based on reading the code and wsgiref documentation where the same > import style is used. > ACK, I did the functional tests as well, works fine. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Wed May 7 13:47:49 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 15:47:49 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check Message-ID: <536A3985.20502@redhat.com> krbpasswordexpiration conversion to number of second since epoch failed because now we get datetime object instead of string. https://fedorahosted.org/freeipa/ticket/4339 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0630-rpcserver-login_password-datetime-fix-in-expiration-.patch Type: text/x-patch Size: 1694 bytes Desc: not available URL: From dpal at redhat.com Wed May 7 13:50:06 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 May 2014 09:50:06 -0400 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <5369E971.4020503@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> <5369E971.4020503@redhat.com> Message-ID: <536A3A0E.8010702@redhat.com> On 05/07/2014 04:06 AM, Jan Cholasta wrote: > On 6.5.2014 19:55, Nathaniel McCallum wrote: >> I know it is a bit late on this, but for the OTP token import script, I >> have to have support for the full ISO 8601. My plan right now is to use >> python-dateutil for this. >> >> Using dateutil would simplify some of this code. Is there a reason we >> aren't using dateutil? > > IIRC it was rejected right at the beginning as an overkill. > What are the alternatives? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed May 7 13:54:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 May 2014 09:54:07 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399467936.3786.5.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> Message-ID: <536A3AFF.5050105@redhat.com> 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. > Nathaniel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From pvoborni at redhat.com Wed May 7 13:54:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 15:54:56 +0200 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <1399388863.9864.1.camel@ipa.example.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> <1399388863.9864.1.camel@ipa.example.com> Message-ID: <536A3B30.3080206@redhat.com> On 6.5.2014 17:07, Nathaniel McCallum wrote: > On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote: >> On 6.5.2014 15:16, Nathaniel McCallum wrote: >>> On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 5.5.2014 18:40, Nathaniel McCallum wrote: >>>>> Creating tokens for yourself is the most common operation. Making this >>>>> the default optimizes for the common case. >>>> >>>> The user-find call should be inside the if statement. >>> >>> This is actually for a reason. See my patch 0049 for further context. >> >> IMO something like this would be better: >> >> if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in >> entry_attrs: >> result = self.api.Command.user_find(whoami=True)['result'] >> if result: >> cur_uid = result[0]['uid'][0] >> prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) >> if cur_uid != prev_uid: >> entry_attrs.setdefault('ipatokenprotected', True) > > Fixed (see also my new revision of patch 0049). > > Nathaniel > I assume that this won't allow to create a token without an owner. Do we want to have this restriction? Usecase: import a batch of hw tokens -- Petr Vobornik From tbabej at redhat.com Wed May 7 14:01:22 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 May 2014 16:01:22 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check In-Reply-To: <536A3985.20502@redhat.com> References: <536A3985.20502@redhat.com> Message-ID: <536A3CB2.6060408@redhat.com> On 05/07/2014 03:47 PM, Petr Vobornik wrote: > krbpasswordexpiration conversion to number of second since epoch failed > because now we get datetime object instead of string. > > https://fedorahosted.org/freeipa/ticket/4339 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel NACK, I don't think this is the right approach. This does not leverage the simplicity which the DateTime parameter refactoring provides. Instead of converting the datetime to the number of the seconds since epoch, and getting the current time represented by the number of seconds since the epoch (using time.time()), why not use datetime module and datetime.datetime.now() to get the current time? Then you could simplify this: + exp = time.mktime(expiration.timetuple()) + if exp <= time.time(): to this: + if expiration <= datetime.datetime.now() -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Wed May 7 14:06:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 07 May 2014 10:06:09 -0400 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <536A3B30.3080206@redhat.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> <1399388863.9864.1.camel@ipa.example.com> <536A3B30.3080206@redhat.com> Message-ID: <1399471569.3786.9.camel@ipa.example.com> On Wed, 2014-05-07 at 15:54 +0200, Petr Vobornik wrote: > On 6.5.2014 17:07, Nathaniel McCallum wrote: > > On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote: > >> On 6.5.2014 15:16, Nathaniel McCallum wrote: > >>> On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: > >>>> Hi, > >>>> > >>>> On 5.5.2014 18:40, Nathaniel McCallum wrote: > >>>>> Creating tokens for yourself is the most common operation. Making this > >>>>> the default optimizes for the common case. > >>>> > >>>> The user-find call should be inside the if statement. > >>> > >>> This is actually for a reason. See my patch 0049 for further context. > >> > >> IMO something like this would be better: > >> > >> if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in > >> entry_attrs: > >> result = self.api.Command.user_find(whoami=True)['result'] > >> if result: > >> cur_uid = result[0]['uid'][0] > >> prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) > >> if cur_uid != prev_uid: > >> entry_attrs.setdefault('ipatokenprotected', True) > > > > Fixed (see also my new revision of patch 0049). > > > > Nathaniel > > > > I assume that this won't allow to create a token without an owner. Do we > want to have this restriction? > > Usecase: import a batch of hw tokens This case is currently very much on my radar (I'm finishing the import script now). To set no owner, just use --owner="". We are testing for key presence here, not the value of the key. So if the key is present with an empty value, no owner will be set. FYI, the import format (RFC 6030) also permits a mechanism for declaring ownership in DN format. Nathaniel From pvoborni at redhat.com Wed May 7 14:26:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 16:26:41 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check In-Reply-To: <536A3CB2.6060408@redhat.com> References: <536A3985.20502@redhat.com> <536A3CB2.6060408@redhat.com> Message-ID: <536A42A1.4070803@redhat.com> On 7.5.2014 16:01, Tomas Babej wrote: > > On 05/07/2014 03:47 PM, Petr Vobornik wrote: >> krbpasswordexpiration conversion to number of second since epoch failed >> because now we get datetime object instead of string. >> >> https://fedorahosted.org/freeipa/ticket/4339 >> >> > NACK, I don't think this is the right approach. This does not leverage > the simplicity which the DateTime parameter refactoring provides. > > Instead of converting the datetime to the number of the seconds since > epoch, and getting the current time represented by the number of seconds > since the epoch (using time.time()), why not use datetime module and > datetime.datetime.now() to get the current time? > > Then you could simplify this: > > + exp = time.mktime(expiration.timetuple()) > + if exp <= time.time(): > > to this: > > + if expiration <= datetime.datetime.now() > Good point, fixed -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0630-1-rpcserver-login_password-datetime-fix-in-expiration-.patch Type: text/x-patch Size: 1550 bytes Desc: not available URL: From pvoborni at redhat.com Wed May 7 14:35:01 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 16:35:01 +0200 Subject: [Freeipa-devel] [PATCH] 584 migration: fix import of wsgiref.util In-Reply-To: <536A3760.1010501@redhat.com> References: <533A60FD.6080707@redhat.com> <20140401072515.GE3872@redhat.com> <536A3760.1010501@redhat.com> Message-ID: <536A4495.30706@redhat.com> On 7.5.2014 15:38, Tomas Babej wrote: > On 04/01/2014 09:25 AM, Jan Pazdziora wrote: >> On Tue, Apr 01, 2014 at 08:47:25AM +0200, Petr Vobornik wrote: >>> https://fedorahosted.org/freeipa/ticket/4293 >>> -- >>> Petr Vobornik >>> From dc4eaf9d622b4eac9fb3d942b23083bfb903be9a Mon Sep 17 00:00:00 2001 >>> From: Petr Vobornik >>> Date: Tue, 1 Apr 2014 08:45:08 +0200 >>> Subject: [PATCH] migration: fix import of wsgiref.util >>> >>> https://fedorahosted.org/freeipa/ticket/4293 >>> --- >>> install/migration/migration.py | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/install/migration/migration.py b/install/migration/migration.py >>> index 27e23a59f660c791c12948b4c40406d03b0f0966..acc1ee48dd8744f6abd2d7a59f0d5feb54fc93f9 100644 >>> --- a/install/migration/migration.py >>> +++ b/install/migration/migration.py >>> @@ -23,7 +23,7 @@ Password migration script >>> import cgi >>> import errno >>> import glob >>> -import wsgiref >>> +from wsgiref.util import request_uri >>> >>> from ipapython.ipa_log_manager import root_logger >>> from ipapython.ipautil import get_ipa_basedn >>> @@ -37,7 +37,7 @@ def wsgi_redirect(start_response, loc): >>> return [] >>> >>> def get_ui_url(environ): >>> - full_url = wsgiref.util.request_uri(environ) >>> + full_url = request_uri(environ) >> Sadly, this antipattern seems needed even if the proper solution would >> be to fix wsgi to properly export util. Is there bug filed for that. >> >> Ack based on reading the code and wsgiref documentation where the same >> import style is used. >> > > ACK, I did the functional tests as well, works fine. > Pushed to master: 86ff28fac8fdb81386ae0b84f352e3b2e8f5a396 -- Petr Vobornik From pvoborni at redhat.com Wed May 7 14:37:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 16:37:13 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check In-Reply-To: <536A436C.10206@redhat.com> References: <536A3985.20502@redhat.com> <536A3CB2.6060408@redhat.com> <536A42A1.4070803@redhat.com> <536A436C.10206@redhat.com> Message-ID: <536A4519.3080601@redhat.com> On 7.5.2014 16:30, Tomas Babej wrote: > > On 05/07/2014 04:26 PM, Petr Vobornik wrote: >> On 7.5.2014 16:01, Tomas Babej wrote: >>> >>> On 05/07/2014 03:47 PM, Petr Vobornik wrote: >>>> krbpasswordexpiration conversion to number of second since epoch failed >>>> because now we get datetime object instead of string. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4339 >>>> >>>> >>> NACK, I don't think this is the right approach. This does not leverage >>> the simplicity which the DateTime parameter refactoring provides. >>> >>> Instead of converting the datetime to the number of the seconds since >>> epoch, and getting the current time represented by the number of seconds >>> since the epoch (using time.time()), why not use datetime module and >>> datetime.datetime.now() to get the current time? >>> >>> Then you could simplify this: >>> >>> + exp = time.mktime(expiration.timetuple()) >>> + if exp <= time.time(): >>> >>> to this: >>> >>> + if expiration <= datetime.datetime.now() >>> >> >> Good point, fixed >> > > Can you also please remove the (now) unused import for module time? > done -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0630-2-rpcserver-login_password-datetime-fix-in-expiration-.patch Type: text/x-patch Size: 1708 bytes Desc: not available URL: From pvoborni at redhat.com Wed May 7 14:57:52 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 May 2014 16:57:52 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added In-Reply-To: <20140507151644.0a96d348@unused-4-246.brq.redhat.com> References: <20140425171648.754632d7@unused-4-246.brq.redhat.com> <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> <5360E066.5070804@redhat.com> <20140505163912.7cb903d1@unused-4-246.brq.redhat.com> <53689D6C.20204@redhat.com> <20140507151644.0a96d348@unused-4-246.brq.redhat.com> Message-ID: <536A49F0.3080103@redhat.com> On 7.5.2014 15:16, Misnyovszki Adam wrote: > On Tue, 06 May 2014 10:29:32 +0200 > Petr Vobornik wrote: > >> On 5.5.2014 16:39, Misnyovszki Adam wrote: >>> On Wed, 30 Apr 2014 13:37:10 +0200 >>> Petr Vobornik wrote: >>> >>>> On 29.4.2014 16:30, Misnyovszki Adam wrote: >>>>> On Fri, 25 Apr 2014 17:16:48 +0200 >>>>> Misnyovszki Adam wrote: >>>>> >>>>>> Hi, >>>>>> this patch adds some static test data for the webui otptoken >>>>>> part. Adam >>>>> >>>>> Attached corrected DN's. >>>>> Thanks >>>>> Adam >>>>> >>>> >>>> 1) Why otptoken_batch_del.json ends with error? Also there might >>>> be a defect in UI that for batch delete operation it asks for >>>> batch.json and not $ENTITY_batch_del.json making >>>> otptoken_batch_del.json unused >>>> - out of scope of this patch. >>>> >>>> 2) Why otptoken_mod.json ends with error? >>>> >>>> 3) otptoken_find.json is not needed since the search facet uses >>>> paging (combination of otptoken_get_records.json and >>>> otptoken_find_pkeys.json is enough). >>>> >>>> In general, it's OK to fake the data if there is some bug which >>>> causes errors and we know that it will be fixed. >>> >>> Hi, >>> see the attached, and corrected 18 patch for otptoken static test >>> data. Also, I've added patch 20, for fixing the batch_del command >>> in static webui tests. >>> >>> Thanks >>> Adam >>> >> >> Patch 18-3: >> >> 1. otptoken_batch.json, otptoken_batch_del.json, otptoken_mod.json >> have trailing whitespace after commas >> 2. otptoken_batch.json was obsoleted by patch 20. Should be removed >> since both patches are in one patchset. >> >> Patch 20: >> ACK > > See attached fix for patch 18 > Thanks > Adam > ACK Pushed to master: * 1ef91701e984c5c9717803a0d3c2e52c81386676 webui OTP token test data added * 23302645aa70613dd1ecc6eb45b6c2ad07588270 webui static site delete command fixed -- Petr Vobornik From simo at redhat.com Wed May 7 15:17:19 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 May 2014 11:17:19 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <536A3AFF.5050105@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> Message-ID: <1399475839.26263.192.camel@willson.li.ssimo.org> 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 ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Wed May 7 14:30:04 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 May 2014 16:30:04 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check In-Reply-To: <536A42A1.4070803@redhat.com> References: <536A3985.20502@redhat.com> <536A3CB2.6060408@redhat.com> <536A42A1.4070803@redhat.com> Message-ID: <536A436C.10206@redhat.com> On 05/07/2014 04:26 PM, Petr Vobornik wrote: > On 7.5.2014 16:01, Tomas Babej wrote: >> >> On 05/07/2014 03:47 PM, Petr Vobornik wrote: >>> krbpasswordexpiration conversion to number of second since epoch failed >>> because now we get datetime object instead of string. >>> >>> https://fedorahosted.org/freeipa/ticket/4339 >>> >>> >> NACK, I don't think this is the right approach. This does not leverage >> the simplicity which the DateTime parameter refactoring provides. >> >> Instead of converting the datetime to the number of the seconds since >> epoch, and getting the current time represented by the number of seconds >> since the epoch (using time.time()), why not use datetime module and >> datetime.datetime.now() to get the current time? >> >> Then you could simplify this: >> >> + exp = time.mktime(expiration.timetuple()) >> + if exp <= time.time(): >> >> to this: >> >> + if expiration <= datetime.datetime.now() >> > > Good point, fixed > Can you also please remove the (now) unused import for module time? -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Wed May 7 15:29:37 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 May 2014 17:29:37 +0200 Subject: [Freeipa-devel] [PATCH 0167] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <20140430124436.GC4991@hendrix.brq.redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> <5360BCF0.1030101@redhat.com> <20140430124436.GC4991@hendrix.brq.redhat.com> Message-ID: <536A5161.7080602@redhat.com> On 04/30/2014 02:44 PM, Jakub Hrozek wrote: > On Wed, Apr 30, 2014 at 11:05:52AM +0200, Tomas Babej wrote: >> On 03/24/2014 03:27 PM, Jan Pazdziora wrote: >>> On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: >>>> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: >>>>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Makes ipa-client-install configure SSSD as the data provider >>>>>> for the sudo service by default. This behaviour can be disabled >>>>>> by using --no-sudo flag. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3358 >>>>> Ack. >>>>> >>>>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without >>>>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers >>>>> added to /etc/nsswitch.conf. >>>>> >>>>> Rerun with --uninstall and run again with the --no-sudo parameter, >>>>> those settings were not longer there. >>>>> >>>> Did you also do the functional test? >>> No. I do not want to get dragged into the discussion of having the >>> correct sssd and sudo and glibc versions and SELinux and stuff. The >>> ticket explicitly talk about setting configuration in config files, >>> which the patch does. >>> >>>> To ack and push this ticket, following >>>> scenario needs to work: >>> Consumption of those configuration changes is really different story, >>> isn't it? >>> >>>> 1) IPA clients enroll against IPA server without --no-sudo >>>> 2) IPA client user logs in, types "sudo -l", gets all allowed commands >>>> (prerequisite is of course to have sudo commands defined on the IPA server) >>>> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all >>>> allowed commands >>>> >>>> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done >>>> >>>> For 3) to work, related systemd service preserving NIS domain name setting >>>> needs to be enabled >>> With the commit message only talking about configuring sssd, I assume >>> the NIS domain name mentioned in the ticket will be done by some other >>> patch. >>> >>> To me, the patch does what is advertised in the commit message, and is >>> in line with what the ticket asks to be done. >>> >> Attached are rebased versions of the patches 113 and 167 (which was >> marked as 157 in the thread previously by mistake). >> >> There is a slight behaviour change in 167, if there is no sudoers line >> in nsswitch.conf, we add both files and sss as sudoers sources. >> >> I also developed CI test that covers the functionality of the IPA - sudo >> integration feature, which is attached. >> >> Please note that the last three tests are expected to fail until: >> >> https://fedorahosted.org/freeipa/ticket/4324 >> >> is fixed. >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> > Hi, > > I haven't done a thorough review, but the patch looks good to me in > general -- in other words, seems to cover what I've been doing manually > for my test setups. > > My only suggestion (maybe for future) would be to split changing the > nsswitch.conf into its own separate helper class or a function, because > you might want to do the same change for automount or other services in > nsswitch.conf. > > But I think this version is OK at the moment. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I created a rather general function for editing the nsswitch.conf as requesting. Updated patch attached. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0167-3-ipa-client-install-Configure-sudo-to-use-SSSD-as-dat.patch Type: text/x-patch Size: 6459 bytes Desc: not available URL: From jhrozek at redhat.com Wed May 7 15:46:03 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 May 2014 17:46:03 +0200 Subject: [Freeipa-devel] [PATCH 0167] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <536A5161.7080602@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> <5360BCF0.1030101@redhat.com> <20140430124436.GC4991@hendrix.brq.redhat.com> <536A5161.7080602@redhat.com> Message-ID: <20140507154603.GH5744@hendrix.brq.redhat.com> On Wed, May 07, 2014 at 05:29:37PM +0200, Tomas Babej wrote: > > On 04/30/2014 02:44 PM, Jakub Hrozek wrote: > > On Wed, Apr 30, 2014 at 11:05:52AM +0200, Tomas Babej wrote: > >> On 03/24/2014 03:27 PM, Jan Pazdziora wrote: > >>> On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: > >>>> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: > >>>>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Makes ipa-client-install configure SSSD as the data provider > >>>>>> for the sudo service by default. This behaviour can be disabled > >>>>>> by using --no-sudo flag. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/3358 > >>>>> Ack. > >>>>> > >>>>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without > >>>>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers > >>>>> added to /etc/nsswitch.conf. > >>>>> > >>>>> Rerun with --uninstall and run again with the --no-sudo parameter, > >>>>> those settings were not longer there. > >>>>> > >>>> Did you also do the functional test? > >>> No. I do not want to get dragged into the discussion of having the > >>> correct sssd and sudo and glibc versions and SELinux and stuff. The > >>> ticket explicitly talk about setting configuration in config files, > >>> which the patch does. > >>> > >>>> To ack and push this ticket, following > >>>> scenario needs to work: > >>> Consumption of those configuration changes is really different story, > >>> isn't it? > >>> > >>>> 1) IPA clients enroll against IPA server without --no-sudo > >>>> 2) IPA client user logs in, types "sudo -l", gets all allowed commands > >>>> (prerequisite is of course to have sudo commands defined on the IPA server) > >>>> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all > >>>> allowed commands > >>>> > >>>> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done > >>>> > >>>> For 3) to work, related systemd service preserving NIS domain name setting > >>>> needs to be enabled > >>> With the commit message only talking about configuring sssd, I assume > >>> the NIS domain name mentioned in the ticket will be done by some other > >>> patch. > >>> > >>> To me, the patch does what is advertised in the commit message, and is > >>> in line with what the ticket asks to be done. > >>> > >> Attached are rebased versions of the patches 113 and 167 (which was > >> marked as 157 in the thread previously by mistake). > >> > >> There is a slight behaviour change in 167, if there is no sudoers line > >> in nsswitch.conf, we add both files and sss as sudoers sources. > >> > >> I also developed CI test that covers the functionality of the IPA - sudo > >> integration feature, which is attached. > >> > >> Please note that the last three tests are expected to fail until: > >> > >> https://fedorahosted.org/freeipa/ticket/4324 > >> > >> is fixed. > >> > >> -- > >> Tomas Babej > >> Associate Software Engineer | Red Hat | Identity Management > >> RHCE | Brno Site | IRC: tbabej | freeipa.org > >> > > Hi, > > > > I haven't done a thorough review, but the patch looks good to me in > > general -- in other words, seems to cover what I've been doing manually > > for my test setups. > > > > My only suggestion (maybe for future) would be to split changing the > > nsswitch.conf into its own separate helper class or a function, because > > you might want to do the same change for automount or other services in > > nsswitch.conf. > > > > But I think this version is OK at the moment. > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > I created a rather general function for editing the nsswitch.conf as > requesting. > > Updated patch attached. Thanks, looks good to me, although I haven't done a thorough review. From npmccallum at redhat.com Wed May 7 15:46:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 07 May 2014 11:46:16 -0400 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <536A3A0E.8010702@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> <5369E971.4020503@redhat.com> <536A3A0E.8010702@redhat.com> Message-ID: <1399477576.3786.17.camel@ipa.example.com> On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote: > On 05/07/2014 04:06 AM, Jan Cholasta wrote: > > On 6.5.2014 19:55, Nathaniel McCallum wrote: > >> I know it is a bit late on this, but for the OTP token import script, I > >> have to have support for the full ISO 8601. My plan right now is to use > >> python-dateutil for this. > >> > >> Using dateutil would simplify some of this code. Is there a reason we > >> aren't using dateutil? > > > > IIRC it was rejected right at the beginning as an overkill. > > > > What are the alternatives? Hand-coded date parsing, AFAICS. That is what we are currently doing. In order to make this sane, we greatly restrict the date formats permitted as input to a small subset of ISO 8601. This is possible because we just tell the users to type the date in one of the supported formats. Unfortunately, I can't make that trade-off in the token import script since I have no control over the input. Since I have to support all of ISO 8601 (including timezone conversions), the dateutils module is pretty much the only option. If we adopt it for OTP import, we might as well throw away our hand-coded date parsing. Nathaniel From dpal at redhat.com Wed May 7 16:15:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 May 2014 12:15:32 -0400 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <1399477576.3786.17.camel@ipa.example.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> <5369E971.4020503@redhat.com> <536A3A0E.8010702@redhat.com> <1399477576.3786.17.camel@ipa.example.com> Message-ID: <536A5C24.5070001@redhat.com> On 05/07/2014 11:46 AM, Nathaniel McCallum wrote: > On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote: >> On 05/07/2014 04:06 AM, Jan Cholasta wrote: >>> On 6.5.2014 19:55, Nathaniel McCallum wrote: >>>> I know it is a bit late on this, but for the OTP token import script, I >>>> have to have support for the full ISO 8601. My plan right now is to use >>>> python-dateutil for this. >>>> >>>> Using dateutil would simplify some of this code. Is there a reason we >>>> aren't using dateutil? >>> IIRC it was rejected right at the beginning as an overkill. >>> >> What are the alternatives? > Hand-coded date parsing, AFAICS. That is what we are currently doing. In > order to make this sane, we greatly restrict the date formats permitted > as input to a small subset of ISO 8601. This is possible because we just > tell the users to type the date in one of the supported formats. > > Unfortunately, I can't make that trade-off in the token import script > since I have no control over the input. Since I have to support all of > ISO 8601 (including timezone conversions), the dateutils module is > pretty much the only option. If we adopt it for OTP import, we might as > well throw away our hand-coded date parsing. > > Nathaniel > > I would leave this till next week for Martin and Petr3 to chime in. I do not have a problem but I am not sure I can assess all the implications. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Wed May 7 20:27:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 May 2014 16:27:52 -0400 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup In-Reply-To: <53694D4B.60700@redhat.com> References: <53694D4B.60700@redhat.com> Message-ID: <536A9748.5030909@redhat.com> Rob Crittenden wrote: > Remove some unused files, fix an import which means we don't need to > import from ipaserver, fix up Requires so it should work better running > on a different box than the IPA server. Found and fixed a couple more minor issues. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1107-2-smartproxy.patch Type: text/x-patch Size: 6318 bytes Desc: not available URL: From rcritten at redhat.com Thu May 8 13:12:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 May 2014 09:12:24 -0400 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup In-Reply-To: <536A9748.5030909@redhat.com> References: <53694D4B.60700@redhat.com> <536A9748.5030909@redhat.com> Message-ID: <536B82B8.8030602@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Remove some unused files, fix an import which means we don't need to >> import from ipaserver, fix up Requires so it should work better running >> on a different box than the IPA server. > > Found and fixed a couple more minor issues. Fix one more issue. This sets the ipa client log to /dev/null to suppress the error ipa: ERROR: Could not create log_dir u'/var/www/.ipa/log' rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1107-3-smartproxy.patch Type: text/x-patch Size: 6585 bytes Desc: not available URL: From hmorris at ilstechnology.com Thu May 8 15:59:14 2014 From: hmorris at ilstechnology.com (Hendri Morris) Date: Thu, 8 May 2014 15:59:14 +0000 Subject: [Freeipa-devel] FreeIPA on AWS EC2 Message-ID: Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). Goes straight to dependency hell. I deployed a multi-server FreeIPA in a enterprise environment and absolutely love the product. Please add AWS to the roadmap! www.ilstechnology.com Hendri Morris Senior Cloud Engineer deviceWISE Operations This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu May 8 16:26:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 08 May 2014 12:26:34 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399475839.26263.192.camel@willson.li.ssimo.org> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> Message-ID: <1399566394.2482.27.camel@ipa.example.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; acl "Users can create and delete tokens"; allow (add, delete) userattr = "ipatokenOwner#SELFDN";) This is what they look like using managedBy (I have not tested this): 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"; allow (read, search, compare) userattr = "managedBy#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"; allow (read, search, compare) userattr = "managedBy#USERDN";) aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can see HOTP details"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = "managedBy#USERDN";) aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "description || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; allow (write) userattr = "managedBy#USERDN";) aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Managers can delete tokens"; allow (delete) userattr = "managedBy#USERDN";) aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) In short: 1. Owner and manager get read, search and compare. 2. Manager gets write (to select attributes) and delete. 3. Users can create self-managed tokens for themselves only. The otptoken-add command should gain the following defaults: 1. The owner defaults to the user adding the token. 2. If owner == user adding token, managedBy defaults to owner. 3. Otherwise, managedBy defaults to None. This means that if neither owner nor managedBy are specified, the default is a self-owned, self-managed token. Likewise, if a different owner is specified, no manager is assumed. rcrit expresses worry that ipalib's ACI parser may not handle the above syntax. This will become clear during testing if we want this approach. Does this look sane? Nathaniel From npmccallum at redhat.com Thu May 8 16:41:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 08 May 2014 12:41:28 -0400 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup In-Reply-To: <536B82B8.8030602@redhat.com> References: <53694D4B.60700@redhat.com> <536A9748.5030909@redhat.com> <536B82B8.8030602@redhat.com> Message-ID: <1399567288.2482.28.camel@ipa.example.com> On Thu, 2014-05-08 at 09:12 -0400, Rob Crittenden wrote: > Rob Crittenden wrote: > > Rob Crittenden wrote: > >> Remove some unused files, fix an import which means we don't need to > >> import from ipaserver, fix up Requires so it should work better running > >> on a different box than the IPA server. > > > > Found and fixed a couple more minor issues. > > Fix one more issue. This sets the ipa client log to /dev/null to > suppress the error > > ipa: ERROR: Could not create log_dir u'/var/www/.ipa/log' What is the purpose of sending the bootstrap logs for smartproxy to /dev/null? Nathaniel From dpal at redhat.com Thu May 8 16:55:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 08 May 2014 12:55:19 -0400 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: References: Message-ID: <536BB6F7.9000402@redhat.com> On 05/08/2014 11:59 AM, Hendri Morris wrote: > > Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point > the client doesn't even install on Amazon Linux (Redhat Clone > Optimized for AWS). Goes straight to dependency hell. I deployed a > multi-server FreeIPA in a enterprise environment and absolutely love > the product. Please add AWS to the roadmap! > > > > > > *www.ilstechnology.com* > ** > *Hendri Morris* > Senior Cloud Engineer > deviceWISE Operations > > > This e-mail may contain information that is confidential, privileged > or otherwise protected from disclosure. If you are not an intended > recipient of this e-mail, do not duplicate or redistribute it by any > means. Please delete it and any attachments and notify the sender that > you have received it in error. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Have you tried this? http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu May 8 17:36:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 May 2014 13:36:20 -0400 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup In-Reply-To: <1399567288.2482.28.camel@ipa.example.com> References: <53694D4B.60700@redhat.com> <536A9748.5030909@redhat.com> <536B82B8.8030602@redhat.com> <1399567288.2482.28.camel@ipa.example.com> Message-ID: <536BC094.3080508@redhat.com> Nathaniel McCallum wrote: > On Thu, 2014-05-08 at 09:12 -0400, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Remove some unused files, fix an import which means we don't need to >>>> import from ipaserver, fix up Requires so it should work better running >>>> on a different box than the IPA server. >>> >>> Found and fixed a couple more minor issues. >> >> Fix one more issue. This sets the ipa client log to /dev/null to >> suppress the error >> >> ipa: ERROR: Could not create log_dir u'/var/www/.ipa/log' > > What is the purpose of sending the bootstrap logs for smartproxy > to /dev/null? It is all client logs. The smartproxy acts as an IPA client and clients log some things in ~/.ipa/log by default. We don't really want these logs in this case, it's logged anyway, and this suppresses the error by writing things to the bit bucket. The other way would be to add an option to not log but that seems like overkill. rob From npmccallum at redhat.com Thu May 8 17:38:18 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 08 May 2014 13:38:18 -0400 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup In-Reply-To: <536BC094.3080508@redhat.com> References: <53694D4B.60700@redhat.com> <536A9748.5030909@redhat.com> <536B82B8.8030602@redhat.com> <1399567288.2482.28.camel@ipa.example.com> <536BC094.3080508@redhat.com> Message-ID: <1399570698.2482.29.camel@ipa.example.com> On Thu, 2014-05-08 at 13:36 -0400, Rob Crittenden wrote: > Nathaniel McCallum wrote: > > On Thu, 2014-05-08 at 09:12 -0400, Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Rob Crittenden wrote: > >>>> Remove some unused files, fix an import which means we don't need to > >>>> import from ipaserver, fix up Requires so it should work better running > >>>> on a different box than the IPA server. > >>> > >>> Found and fixed a couple more minor issues. > >> > >> Fix one more issue. This sets the ipa client log to /dev/null to > >> suppress the error > >> > >> ipa: ERROR: Could not create log_dir u'/var/www/.ipa/log' > > > > What is the purpose of sending the bootstrap logs for smartproxy > > to /dev/null? > > It is all client logs. The smartproxy acts as an IPA client and clients > log some things in ~/.ipa/log by default. We don't really want these > logs in this case, it's logged anyway, and this suppresses the error by > writing things to the bit bucket. > > The other way would be to add an option to not log but that seems like > overkill. That is all that stood out to me. ACK Nathaniel From simo at redhat.com Thu May 8 17:51:21 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 May 2014 13:51:21 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399566394.2482.27.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> Message-ID: <1399571481.2708.2.camel@willson.li.ssimo.org> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; > acl "Users can create and delete tokens"; allow (add, delete) userattr = > "ipatokenOwner#SELFDN";) > > This is what they look like using managedBy (I have not tested this): > > 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"; allow (read, search, compare) > userattr = "managedBy#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"; allow > (read, search, compare) userattr = "managedBy#USERDN";) > > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > see HOTP details"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > "managedBy#USERDN";) > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "description || ipatokenDisabled || ipatokenNotBefore || > ipatokenNotAfter || ipatokenVendor || ipatokenModel || > ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; > allow (write) userattr = "managedBy#USERDN";) > > aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > "Managers can delete tokens"; allow (delete) userattr = > "managedBy#USERDN";) > > aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > userattr = "managedBy#SELFDN";) > > In short: > 1. Owner and manager get read, search and compare. > 2. Manager gets write (to select attributes) and delete. > 3. Users can create self-managed tokens for themselves only. > > The otptoken-add command should gain the following defaults: > 1. The owner defaults to the user adding the token. > 2. If owner == user adding token, managedBy defaults to owner. > 3. Otherwise, managedBy defaults to None. > > This means that if neither owner nor managedBy are specified, the > default is a self-owned, self-managed token. Likewise, if a different > owner is specified, no manager is assumed. > > rcrit expresses worry that ipalib's ACI parser may not handle the above > syntax. This will become clear during testing if we want this approach. > > Does this look sane? I am not entirely sure your ACI syntax is always right for the second set. and perhaps we want to duplicate ACIs in some cases (once for owner once for manager). I think the read ACIs do not need to list managedby ? Do we plan to have a manager that is another regular user but not the owner nor an admin ? In any case I prefer the sytnax that uses managedby, as it has more potential. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu May 8 17:52:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 May 2014 20:52:45 +0300 Subject: [Freeipa-devel] [PATCH 0167] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <20140507154603.GH5744@hendrix.brq.redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> <5360BCF0.1030101@redhat.com> <20140430124436.GC4991@hendrix.brq.redhat.com> <536A5161.7080602@redhat.com> <20140507154603.GH5744@hendrix.brq.redhat.com> Message-ID: <20140508175245.GA18538@redhat.com> On Wed, 07 May 2014, Jakub Hrozek wrote: >On Wed, May 07, 2014 at 05:29:37PM +0200, Tomas Babej wrote: >> >> On 04/30/2014 02:44 PM, Jakub Hrozek wrote: >> > On Wed, Apr 30, 2014 at 11:05:52AM +0200, Tomas Babej wrote: >> >> On 03/24/2014 03:27 PM, Jan Pazdziora wrote: >> >>> On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: >> >>>> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: >> >>>>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: >> >>>>>> Hi, >> >>>>>> >> >>>>>> Makes ipa-client-install configure SSSD as the data provider >> >>>>>> for the sudo service by default. This behaviour can be disabled >> >>>>>> by using --no-sudo flag. >> >>>>>> >> >>>>>> https://fedorahosted.org/freeipa/ticket/3358 >> >>>>> Ack. >> >>>>> >> >>>>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without >> >>>>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers >> >>>>> added to /etc/nsswitch.conf. >> >>>>> >> >>>>> Rerun with --uninstall and run again with the --no-sudo parameter, >> >>>>> those settings were not longer there. >> >>>>> >> >>>> Did you also do the functional test? >> >>> No. I do not want to get dragged into the discussion of having the >> >>> correct sssd and sudo and glibc versions and SELinux and stuff. The >> >>> ticket explicitly talk about setting configuration in config files, >> >>> which the patch does. >> >>> >> >>>> To ack and push this ticket, following >> >>>> scenario needs to work: >> >>> Consumption of those configuration changes is really different story, >> >>> isn't it? >> >>> >> >>>> 1) IPA clients enroll against IPA server without --no-sudo >> >>>> 2) IPA client user logs in, types "sudo -l", gets all allowed commands >> >>>> (prerequisite is of course to have sudo commands defined on the IPA server) >> >>>> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all >> >>>> allowed commands >> >>>> >> >>>> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done >> >>>> >> >>>> For 3) to work, related systemd service preserving NIS domain name setting >> >>>> needs to be enabled >> >>> With the commit message only talking about configuring sssd, I assume >> >>> the NIS domain name mentioned in the ticket will be done by some other >> >>> patch. >> >>> >> >>> To me, the patch does what is advertised in the commit message, and is >> >>> in line with what the ticket asks to be done. >> >>> >> >> Attached are rebased versions of the patches 113 and 167 (which was >> >> marked as 157 in the thread previously by mistake). >> >> >> >> There is a slight behaviour change in 167, if there is no sudoers line >> >> in nsswitch.conf, we add both files and sss as sudoers sources. >> >> >> >> I also developed CI test that covers the functionality of the IPA - sudo >> >> integration feature, which is attached. >> >> >> >> Please note that the last three tests are expected to fail until: >> >> >> >> https://fedorahosted.org/freeipa/ticket/4324 >> >> >> >> is fixed. >> >> >> >> -- >> >> Tomas Babej >> >> Associate Software Engineer | Red Hat | Identity Management >> >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> >> > Hi, >> > >> > I haven't done a thorough review, but the patch looks good to me in >> > general -- in other words, seems to cover what I've been doing manually >> > for my test setups. >> > >> > My only suggestion (maybe for future) would be to split changing the >> > nsswitch.conf into its own separate helper class or a function, because >> > you might want to do the same change for automount or other services in >> > nsswitch.conf. >> > >> > But I think this version is OK at the moment. >> > >> > _______________________________________________ >> > Freeipa-devel mailing list >> > Freeipa-devel at redhat.com >> > https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> I created a rather general function for editing the nsswitch.conf as >> requesting. >> >> Updated patch attached. > >Thanks, looks good to me, although I haven't done a thorough review. ACK from my side too. I spent some time today looking through the Jenkins job with these patches and apart from three failures in the new sudo test suite everything looks fine. These failures were around dozen in past two weeks and this patchset reduces them as a work in progress. Given that the tests only run against in CI and are fresh new, I'm fine with committing the patchset, the fixes can come next week. -- / Alexander Bokovoy From npmccallum at redhat.com Thu May 8 17:57:58 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 08 May 2014 13:57:58 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399571481.2708.2.camel@willson.li.ssimo.org> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> Message-ID: <1399571878.2482.34.camel@ipa.example.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > > = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; > > acl "Users can create and delete tokens"; allow (add, delete) userattr = > > "ipatokenOwner#SELFDN";) > > > > This is what they look like using managedBy (I have not tested this): > > > > 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"; allow (read, search, compare) > > userattr = "managedBy#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"; allow > > (read, search, compare) userattr = "managedBy#USERDN";) > > > > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > > see HOTP details"; allow (read, search, compare) userattr = > > "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > > "managedBy#USERDN";) > > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > "description || ipatokenDisabled || ipatokenNotBefore || > > ipatokenNotAfter || ipatokenVendor || ipatokenModel || > > ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; > > allow (write) userattr = "managedBy#USERDN";) > > > > aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > > "Managers can delete tokens"; allow (delete) userattr = > > "managedBy#USERDN";) > > > > aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > > = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > > userattr = "managedBy#SELFDN";) > > > > In short: > > 1. Owner and manager get read, search and compare. > > 2. Manager gets write (to select attributes) and delete. > > 3. Users can create self-managed tokens for themselves only. > > > > The otptoken-add command should gain the following defaults: > > 1. The owner defaults to the user adding the token. > > 2. If owner == user adding token, managedBy defaults to owner. > > 3. Otherwise, managedBy defaults to None. > > > > This means that if neither owner nor managedBy are specified, the > > default is a self-owned, self-managed token. Likewise, if a different > > owner is specified, no manager is assumed. > > > > rcrit expresses worry that ipalib's ACI parser may not handle the above > > syntax. This will become clear during testing if we want this approach. > > > > Does this look sane? > > I am not entirely sure your ACI syntax is always right for the second > set. and perhaps we want to duplicate ACIs in some cases (once for owner > once for manager). In the patch I am preparing, I migrated it to use the more terse boolean OR. It should be correct. But I will test it thoroughly. > I think the read ACIs do not need to list managedby ? Do we plan to have > a manager that is another regular user but not the owner nor an admin ? Even if we don't plan on it, someone else will use it for that. And managers can't manage what they can't see. One thing I did leave out is adding management to groups: userattr = "managedBy#GROUPDN". > In any case I prefer the sytnax that uses managedby, as it has more > potential. I think I'm inclined to agree. Is there some aid to understand how to use the managedBy attribute in the plugin code? In existing code it all seems to be used as part of a relationship, which is rather less than clear (and very magical). Nathaniel From rcritten at redhat.com Thu May 8 18:25:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 May 2014 14:25:20 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399571878.2482.34.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399571878.2482.34.camel@ipa.example.com> Message-ID: <536BCC10.50408@redhat.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; >>> acl "Users can create and delete tokens"; allow (add, delete) userattr = >>> "ipatokenOwner#SELFDN";) >>> >>> This is what they look like using managedBy (I have not tested this): >>> >>> 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"; allow (read, search, compare) >>> userattr = "managedBy#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"; allow >>> (read, search, compare) userattr = "managedBy#USERDN";) >>> >>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>> see HOTP details"; allow (read, search, compare) userattr = >>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>> "managedBy#USERDN";) >>> >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>> "description || ipatokenDisabled || ipatokenNotBefore || >>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; >>> allow (write) userattr = "managedBy#USERDN";) >>> >>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>> "Managers can delete tokens"; allow (delete) userattr = >>> "managedBy#USERDN";) >>> >>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>> userattr = "managedBy#SELFDN";) >>> >>> In short: >>> 1. Owner and manager get read, search and compare. >>> 2. Manager gets write (to select attributes) and delete. >>> 3. Users can create self-managed tokens for themselves only. >>> >>> The otptoken-add command should gain the following defaults: >>> 1. The owner defaults to the user adding the token. >>> 2. If owner == user adding token, managedBy defaults to owner. >>> 3. Otherwise, managedBy defaults to None. >>> >>> This means that if neither owner nor managedBy are specified, the >>> default is a self-owned, self-managed token. Likewise, if a different >>> owner is specified, no manager is assumed. >>> >>> rcrit expresses worry that ipalib's ACI parser may not handle the above >>> syntax. This will become clear during testing if we want this approach. >>> >>> Does this look sane? >> >> I am not entirely sure your ACI syntax is always right for the second >> set. and perhaps we want to duplicate ACIs in some cases (once for owner >> once for manager). > > In the patch I am preparing, I migrated it to use the more terse boolean > OR. It should be correct. But I will test it thoroughly. > >> I think the read ACIs do not need to list managedby ? Do we plan to have >> a manager that is another regular user but not the owner nor an admin ? > > Even if we don't plan on it, someone else will use it for that. And > managers can't manage what they can't see. One thing I did leave out is > adding management to groups: userattr = "managedBy#GROUPDN". > >> In any case I prefer the sytnax that uses managedby, as it has more >> potential. > > I think I'm inclined to agree. > > Is there some aid to understand how to use the managedBy attribute in > the plugin code? In existing code it all seems to be used as part of a > relationship, which is rather less than clear (and very magical). I don't think there are any docs beyond the DS ACI docs that describe it. We use it both as a list of DNs (USERDN) for hosts managing hosts and services and as a group DN when delegating DNS. rob From redhatrises at gmail.com Fri May 9 02:09:03 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 8 May 2014 20:09:03 -0600 Subject: [Freeipa-devel] [PATCH] Stop ntpd before running ntpdate In-Reply-To: References: <535F4DED.8090004@redhat.com> Message-ID: Re-factored my second patch. :) Gabe On Tue, Apr 29, 2014 at 8:04 PM, Gabe Alford wrote: > Updated patch to not run ntpdate if ntpd is running. > > Gabe > > > > On Tue, Apr 29, 2014 at 8:16 AM, Gabe Alford wrote: > >> Thanks Petr! >> >> Will rework patch to just skip ntpdate if ntpd is already running. >> >> >> On Tue, Apr 29, 2014 at 12:59 AM, Petr Spacek wrote: >> >>> Hello Gabe! >>> >>> >>> On 25.4.2014 16:28, Gabe Alford wrote: >>> >>>> Here is a patch for https://fedorahosted.org/ >>>> freeipa/ticket/3735. >>>> It seemed better to try to stop ntpd before running ntpdate rather than >>>> not >>>> running ntpdate if ntpd was already running. I believe this patch only >>>> applies to the ipa-3-3 branch as ntpdate is not used anymore in the >>>> master. >>>> >>> >>> IMHO we should never stop ntpd if it is running. Plain ntpdate opens >>> potential security hole because attacker can fake NTP answers and force the >>> machine to rewind it's clock to the past. >>> >>> This opens potential for replay attacks/re-suing old compromised keys >>> etc. >>> >>> -- >>> Petr^2 Spacek >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0017-3-ipa-client-install-skip-running-ntpdate-if-ntpd-is-r.patch Type: text/x-patch Size: 2642 bytes Desc: not available URL: From redhatrises at gmail.com Fri May 9 02:14:52 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 8 May 2014 20:14:52 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: References: Message-ID: Hello, Just wondering if there are any takers in reviewing this patch. Gabe On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford wrote: > Hello, > > Patch for the following ticket to add note in documentation about bad uid > ranges: > https://fedorahosted.org/freeipa/ticket/2090 > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Fri May 9 03:09:58 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 8 May 2014 21:09:58 -0600 Subject: [Freeipa-devel] [PATCH 0018] ipa-client-automount should not configure nsswitch.conf Message-ID: Hello, Came across this issue in my environment the other day and thought I would send a quick patch for review for https://fedorahosted.org/freeipa/ticket/3733 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0018-ipa-client-automount-should-not-configure-nsswitch.c.patch Type: text/x-patch Size: 1507 bytes Desc: not available URL: From abokovoy at redhat.com Fri May 9 10:43:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 May 2014 13:43:37 +0300 Subject: [Freeipa-devel] [PATCHES 180-182] ipatests: Improvements! In-Reply-To: <5368C38C.6020506@redhat.com> References: <536101A5.4000509@redhat.com> <20140502083632.GB4914@hendrix.brq.redhat.com> <20140505160836.GD20958@redhat.com> <5368C38C.6020506@redhat.com> Message-ID: <20140509104337.GI1073@redhat.com> On Tue, 06 May 2014, Tomas Babej wrote: > >On 05/05/2014 06:08 PM, Alexander Bokovoy wrote: >> On Fri, 02 May 2014, Jakub Hrozek wrote: >>> On Wed, Apr 30, 2014 at 03:59:01PM +0200, Tomas Babej wrote: >>>> Hi, >>>> >>>> * patch 180 fixes incorrect hostname usage when connecting to legacy >>>> clients >>>> * patch 181 sets up SSSD in debug_level 7 by default >>>> * patch 182 does the same, but on the legacy clients >>>> >>>> -- >>>> Tomas Babej >>>> Associate Software Engineer | Red Hat | Identity Management >>>> RHCE | Brno Site | IRC: tbabej | freeipa.org >>>> >>> >>> ACK to the general intent of debug_level by default. Have you considered >>> using the python ConfigAPI sssd has to change the sections rather than >>> running a sed script? >> I agree. >> >> The patchset in current form does work fine for me in the tests. >> However, I'd rather wait for a new revision which incorporates changes >> requested by the Jakub. >> >> > >I'm not sure using python ConfigAPI would be a better option here, for one >particular reason - the tests themselves are not run on the machine where >we want to change the config. > >Hence we need to enclose everything we want done on the client in the >run_command method. > >Moving from sed to using python ConfigAPI would mean moving from: > >+ host.run_command(['sed', '-i', >+ '/debug_level = 7/d', >+ '/etc/sssd/sssd.conf' >+ ], raiseonerr=False) >+ >+ # Add the debug directive to each section >+ host.run_command(['sed', '-i', >+ '/\[*\]/ a\debug_level = 7', >+ '/etc/sssd/sssd.conf' >+ ], raiseonerr=False) > >to creating the python script file of ~10-15 lines on the client and >then running it on >the client itself via: > >+ host.run_command(['python', 'set_sssd_debug_level.py']) > >Given that, it does not seem that much simpler than using two sed >commands to me. Yes, it is clearly an overkill in this case. ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Fri May 9 10:58:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 May 2014 13:58:32 +0300 Subject: [Freeipa-devel] [PATCHES 180-182] ipatests: Improvements! In-Reply-To: <20140509104337.GI1073@redhat.com> References: <536101A5.4000509@redhat.com> <20140502083632.GB4914@hendrix.brq.redhat.com> <20140505160836.GD20958@redhat.com> <5368C38C.6020506@redhat.com> <20140509104337.GI1073@redhat.com> Message-ID: <20140509105832.GJ1073@redhat.com> On Fri, 09 May 2014, Alexander Bokovoy wrote: >On Tue, 06 May 2014, Tomas Babej wrote: >> >>On 05/05/2014 06:08 PM, Alexander Bokovoy wrote: >>>On Fri, 02 May 2014, Jakub Hrozek wrote: >>>>On Wed, Apr 30, 2014 at 03:59:01PM +0200, Tomas Babej wrote: >>>>>Hi, >>>>> >>>>>* patch 180 fixes incorrect hostname usage when connecting to legacy >>>>>clients >>>>>* patch 181 sets up SSSD in debug_level 7 by default >>>>>* patch 182 does the same, but on the legacy clients >>>>> >>>>>-- >>>>>Tomas Babej >>>>>Associate Software Engineer | Red Hat | Identity Management >>>>>RHCE | Brno Site | IRC: tbabej | freeipa.org >>>>> >>>> >>>>ACK to the general intent of debug_level by default. Have you considered >>>>using the python ConfigAPI sssd has to change the sections rather than >>>>running a sed script? >>>I agree. >>> >>>The patchset in current form does work fine for me in the tests. >>>However, I'd rather wait for a new revision which incorporates changes >>>requested by the Jakub. >>> >>> >> >>I'm not sure using python ConfigAPI would be a better option here, for one >>particular reason - the tests themselves are not run on the machine where >>we want to change the config. >> >>Hence we need to enclose everything we want done on the client in the >>run_command method. >> >>Moving from sed to using python ConfigAPI would mean moving from: >> >>+ host.run_command(['sed', '-i', >>+ '/debug_level = 7/d', >>+ '/etc/sssd/sssd.conf' >>+ ], raiseonerr=False) >>+ >>+ # Add the debug directive to each section >>+ host.run_command(['sed', '-i', >>+ '/\[*\]/ a\debug_level = 7', >>+ '/etc/sssd/sssd.conf' >>+ ], raiseonerr=False) >> >>to creating the python script file of ~10-15 lines on the client and >>then running it on >>the client itself via: >> >>+ host.run_command(['python', 'set_sssd_debug_level.py']) >> >>Given that, it does not seem that much simpler than using two sed >>commands to me. >Yes, it is clearly an overkill in this case. > >ACK. Pushed patches 180-182 to master. -- / Alexander Bokovoy From abokovoy at redhat.com Fri May 9 10:58:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 May 2014 13:58:59 +0300 Subject: [Freeipa-devel] [PATCH 0167] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <20140508175245.GA18538@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> <5360BCF0.1030101@redhat.com> <20140430124436.GC4991@hendrix.brq.redhat.com> <536A5161.7080602@redhat.com> <20140507154603.GH5744@hendrix.brq.redhat.com> <20140508175245.GA18538@redhat.com> Message-ID: <20140509105859.GK1073@redhat.com> On Thu, 08 May 2014, Alexander Bokovoy wrote: >On Wed, 07 May 2014, Jakub Hrozek wrote: >>On Wed, May 07, 2014 at 05:29:37PM +0200, Tomas Babej wrote: >>> >>>On 04/30/2014 02:44 PM, Jakub Hrozek wrote: >>>> On Wed, Apr 30, 2014 at 11:05:52AM +0200, Tomas Babej wrote: >>>>> On 03/24/2014 03:27 PM, Jan Pazdziora wrote: >>>>>> On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: >>>>>>> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: >>>>>>>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Makes ipa-client-install configure SSSD as the data provider >>>>>>>>> for the sudo service by default. This behaviour can be disabled >>>>>>>>> by using --no-sudo flag. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3358 >>>>>>>> Ack. >>>>>>>> >>>>>>>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without >>>>>>>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers >>>>>>>> added to /etc/nsswitch.conf. >>>>>>>> >>>>>>>> Rerun with --uninstall and run again with the --no-sudo parameter, >>>>>>>> those settings were not longer there. >>>>>>>> >>>>>>> Did you also do the functional test? >>>>>> No. I do not want to get dragged into the discussion of having the >>>>>> correct sssd and sudo and glibc versions and SELinux and stuff. The >>>>>> ticket explicitly talk about setting configuration in config files, >>>>>> which the patch does. >>>>>> >>>>>>> To ack and push this ticket, following >>>>>>> scenario needs to work: >>>>>> Consumption of those configuration changes is really different story, >>>>>> isn't it? >>>>>> >>>>>>> 1) IPA clients enroll against IPA server without --no-sudo >>>>>>> 2) IPA client user logs in, types "sudo -l", gets all allowed commands >>>>>>> (prerequisite is of course to have sudo commands defined on the IPA server) >>>>>>> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all >>>>>>> allowed commands >>>>>>> >>>>>>> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done >>>>>>> >>>>>>> For 3) to work, related systemd service preserving NIS domain name setting >>>>>>> needs to be enabled >>>>>> With the commit message only talking about configuring sssd, I assume >>>>>> the NIS domain name mentioned in the ticket will be done by some other >>>>>> patch. >>>>>> >>>>>> To me, the patch does what is advertised in the commit message, and is >>>>>> in line with what the ticket asks to be done. >>>>>> >>>>> Attached are rebased versions of the patches 113 and 167 (which was >>>>> marked as 157 in the thread previously by mistake). >>>>> >>>>> There is a slight behaviour change in 167, if there is no sudoers line >>>>> in nsswitch.conf, we add both files and sss as sudoers sources. >>>>> >>>>> I also developed CI test that covers the functionality of the IPA - sudo >>>>> integration feature, which is attached. >>>>> >>>>> Please note that the last three tests are expected to fail until: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4324 >>>>> >>>>> is fixed. >>>>> >>>>> -- >>>>> Tomas Babej >>>>> Associate Software Engineer | Red Hat | Identity Management >>>>> RHCE | Brno Site | IRC: tbabej | freeipa.org >>>>> >>>> Hi, >>>> >>>> I haven't done a thorough review, but the patch looks good to me in >>>> general -- in other words, seems to cover what I've been doing manually >>>> for my test setups. >>>> >>>> My only suggestion (maybe for future) would be to split changing the >>>> nsswitch.conf into its own separate helper class or a function, because >>>> you might want to do the same change for automount or other services in >>>> nsswitch.conf. >>>> >>>> But I think this version is OK at the moment. >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>>I created a rather general function for editing the nsswitch.conf as >>>requesting. >>> >>>Updated patch attached. >> >>Thanks, looks good to me, although I haven't done a thorough review. >ACK from my side too. I spent some time today looking through the >Jenkins job with these patches and apart from three failures in the new >sudo test suite everything looks fine. These failures were around dozen >in past two weeks and this patchset reduces them as a work in progress. > >Given that the tests only run against in CI and are fresh new, I'm fine >with committing the patchset, the fixes can come next week. Pushed to master. -- / Alexander Bokovoy From tscherf at redhat.com Fri May 9 13:23:39 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Fri, 9 May 2014 15:23:39 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page Message-ID: <20140509132339.GN572@tscherf.redhat.com> -------------- next part -------------- >From a42383b2662697c3a54add7be6546a31d6a39353 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Fri, 9 May 2014 15:21:10 +0200 Subject: [PATCH] Fixed typo in ipa-replica-manage man page --- install/tools/man/ipa-replica-manage.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/man/ipa-replica-manage.1 b/install/tools/man/ipa-replica-manage.1 index a981c72f59e23024110e0d9e8331cd50cbb22130..613b18ca4dc4f71860af82bdb48817b5a01e9d4c 100644 --- a/install/tools/man/ipa-replica-manage.1 +++ b/install/tools/man/ipa-replica-manage.1 @@ -217,7 +217,7 @@ Remove a winsync replication agreement: .SH "PASSSYNC" PassSync is a Windows service that runs on AD Domain Controllers to intercept password changes. It sends these password changes to the IPA LDAP server over TLS. These password changes bypass normal IPA password policy settings and the password is not set to immediately expire. This is because by the time IPA receives the password change it has already been accepted by AD so it is too late to reject it. .TP -IPA maintains a list of DNs that are excempt from password policy. A special user is added automatically when a winsync replication agreement is created. The DN of this user is added to the excemption list stored in passSyncManagersDNs in the entry cn=ipa_pwd_extop,cn=plugins,cn=config. +IPA maintains a list of DNs that are excempt from password policy. A special user is added automatically when a winsync replication agreement is created. The DN of this user is added to the exemption list stored in passSyncManagersDNs in the entry cn=ipa_pwd_extop,cn=plugins,cn=config. .SH "EXIT STATUS" 0 if the command was successful -- 1.9.0 From npmccallum at redhat.com Fri May 9 14:25:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 9 May 2014 10:25:17 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page In-Reply-To: <20140509132339.GN572@tscherf.redhat.com> References: <20140509132339.GN572@tscherf.redhat.com> Message-ID: <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> NACK There is still another typo: "excempt" Fix that an it is an ACK from me. :) Nathaniel ----- Original Message ----- > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From tscherf at redhat.com Fri May 9 15:18:17 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Fri, 9 May 2014 17:18:17 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page In-Reply-To: <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> References: <20140509132339.GN572@tscherf.redhat.com> <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> Message-ID: <20140509151817.GT572@tscherf.redhat.com> On [Fri, 09.05.2014 10:25], Nathaniel McCallum wrote: >NACK > >There is still another typo: "excempt" right, I missed that one. New patch attached. Cheers, Thorsten > >Fix that an it is an ACK from me. :) > >Nathaniel > >----- Original Message ----- >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- From cf9078547397db08f13c5e85d88219beb5b188d8 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Fri, 9 May 2014 17:17:04 +0200 Subject: [PATCH] Fixed typo in ipa-replica-manage man page --- install/tools/man/ipa-replica-manage.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/man/ipa-replica-manage.1 b/install/tools/man/ipa-replica-manage.1 index 613b18ca4dc4f71860af82bdb48817b5a01e9d4c..ab890284dacd8c53b620abf1e36b8d77bb077ba2 100644 --- a/install/tools/man/ipa-replica-manage.1 +++ b/install/tools/man/ipa-replica-manage.1 @@ -217,7 +217,7 @@ Remove a winsync replication agreement: .SH "PASSSYNC" PassSync is a Windows service that runs on AD Domain Controllers to intercept password changes. It sends these password changes to the IPA LDAP server over TLS. These password changes bypass normal IPA password policy settings and the password is not set to immediately expire. This is because by the time IPA receives the password change it has already been accepted by AD so it is too late to reject it. .TP -IPA maintains a list of DNs that are excempt from password policy. A special user is added automatically when a winsync replication agreement is created. The DN of this user is added to the exemption list stored in passSyncManagersDNs in the entry cn=ipa_pwd_extop,cn=plugins,cn=config. +IPA maintains a list of DNs that are except from password policy. A special user is added automatically when a winsync replication agreement is created. The DN of this user is added to the exemption list stored in passSyncManagersDNs in the entry cn=ipa_pwd_extop,cn=plugins,cn=config. .SH "EXIT STATUS" 0 if the command was successful -- 1.9.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From mkosek at redhat.com Fri May 9 19:36:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 May 2014 21:36:48 +0200 Subject: [Freeipa-devel] minimum python version In-Reply-To: <20140506055524.GE20958@redhat.com> References: <20140506005742.GB24202@dhcp-40-8.bne.redhat.com> <20140506055524.GE20958@redhat.com> Message-ID: <536D2E50.7090207@redhat.com> On 05/06/2014 07:55 AM, Alexander Bokovoy wrote: > On Tue, 06 May 2014, Fraser Tweedale wrote: >> Hi all, >> >> What's are the versions of Python that must be supported in the >> freeipa codebase? And do older branches have to support earlier >> versions? >> >> Any Python language features that should be avoided, by policy? >> Forward-portability considerations? > We attempt to not overcomplicate backport efforts for stable > branches. This means we "stuck" mostly with features provided by the > Python 2.6 (2.6.6 in RHEL 6, for example). > In master branch and FreeIPA versions post RHEL-6 (i.e. FreeIPA 3.0.0 based) we require at least Python 2.7. For instance, we already use set literals ({1,2,3}) that require Python 2.7. Martin From mkosek at redhat.com Fri May 9 20:00:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 May 2014 22:00:30 +0200 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: <536BB6F7.9000402@redhat.com> References: <536BB6F7.9000402@redhat.com> Message-ID: <536D33DE.6080102@redhat.com> On 05/08/2014 06:55 PM, Dmitri Pal wrote: > On 05/08/2014 11:59 AM, Hendri Morris wrote: >> >> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >> enterprise environment and absolutely love the product. Please add AWS to the >> roadmap! >> >> >> >> >> >> *www.ilstechnology.com* >> ** >> *Hendri Morris* >> Senior Cloud Engineer >> deviceWISE Operations >> >> >> This e-mail may contain information that is confidential, privileged or >> otherwise protected from disclosure. If you are not an intended recipient of >> this e-mail, do not duplicate or redistribute it by any means. Please delete >> it and any attachments and notify the sender that you have received it in error. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Have you tried this? > http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html Great to hear you like FreeIPA! As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. Martin From npmccallum at redhat.com Fri May 9 21:15:40 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 9 May 2014 17:15:40 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page In-Reply-To: <20140509151817.GT572@tscherf.redhat.com> References: <20140509132339.GN572@tscherf.redhat.com> <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> <20140509151817.GT572@tscherf.redhat.com> Message-ID: <1211699075.2975520.1399670140369.JavaMail.zimbra@redhat.com> ----- Original Message ----- > right, I missed that one. > > New patch attached. NACK again. (Sorry!) You corrected "excempt" to "except" but it should actually be "exempt". Nathaniel From pcix133 at hotmail.com Sat May 10 02:01:01 2014 From: pcix133 at hotmail.com (daiEric) Date: Sat, 10 May 2014 10:01:01 +0800 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: <536D33DE.6080102@redhat.com> References: <536BB6F7.9000402@redhat.com> <536D33DE.6080102@redhat.com> Message-ID: hi Is there any solution to deploy FreeIpa on ubuntu linux? thanks Eric dai > ? 2014?5?10??4:01?"Martin Kosek" ??? > >> On 05/08/2014 06:55 PM, Dmitri Pal wrote: >>> On 05/08/2014 11:59 AM, Hendri Morris wrote: >>> >>> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >>> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >>> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >>> enterprise environment and absolutely love the product. Please add AWS to the >>> roadmap! >>> >>> >>> >>> >>> >>> *www.ilstechnology.com* >>> ** >>> *Hendri Morris* >>> Senior Cloud Engineer >>> deviceWISE Operations >>> >>> >>> This e-mail may contain information that is confidential, privileged or >>> otherwise protected from disclosure. If you are not an intended recipient of >>> this e-mail, do not duplicate or redistribute it by any means. Please delete >>> it and any attachments and notify the sender that you have received it in error. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Have you tried this? >> http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html > > Great to hear you like FreeIPA! > > As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). > > I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From alee at redhat.com Sat May 10 03:38:09 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 09 May 2014 23:38:09 -0400 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <536298B6.9070907@redhat.com> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> Message-ID: <1399693089.26524.14.camel@aleeredhat.laptop> Attached is patch 6-1, which addresses the issues listed below. In addition, there are two additional patches which : 7. disable the automatic install of the DRM in ipa-server-install as decided until Dogtag 10.2 is available. 8. Add the ability to install a DRM replica using ipa-drm-install. The install procedure is now as follows: On Master: 1. ipa-server-install (installs ipa and dogtag CA) 2. ipa-drm-install (installs drm) 3. ipa-replica-prepare On clone: 1. ipa-replica-install (installs ipa replica) 2. ipa-ca-install (installs replica ca) 3. ipa-drm-install On the clone, if you fail to add a replica_file, the install scripts will detect that a DRM has been installed in the security domain, and prompt for a replica file. For this all to work, you will need the newest version of Dogtag 10.2 - which contains fixes that are not yet checked into Dogtag. A build can be found at: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo Ade Note: For convenience, all the DRM patches have been appended to this email. On Thu, 2014-05-01 at 14:55 -0400, Rob Crittenden wrote: > Ade Lee wrote: > > I have attached a patch that contains code for the new dogtag DRM plugin > > vault functionality. This patch should be applied on top of the ones > > used to install a DRM. > > > > Forthcoming is a patch to actually start using this plugin. > > All the imports should be at the top of the file. > done. > In _create_pem_file there is a ipaserver.install.certs.export_pkcs12() > that you can re-use. Similarly install_pem_from_p12() probably does the > same thing, and your copy doesn't take the PKCS#12 password as input AFAICT. > done. > In _transport_cert_present you can use: > > from ipaserver.install import certs > > db = certs.CertDB(self.realm, nssdir=self.sec_dir) > return db.has_nickname(self.transport_nick) > done. > Should there be error handling around keyclient calls or will that be > handled at a different level? > I think the keyclient calls should throw exceptions and the error handling should be performed at a higher level. We can revisit this when we write the code that calls this plugin. > Incidentally, installing a replica on F-20 with pki-ca-10.2.0-0.1 > against an F-20 master with pki-ca-10.1.1-1 fails with this traceback in > pkispawn: > > File "/usr/sbin/pkispawn", line 514, in > main(sys.argv) > File "/usr/sbin/pkispawn", line 423, in main > info = parser.sd_get_info() > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", > line 463, in sd_get_info > info = sd.getSecurityDomainInfo() > File "/usr/lib/python2.7/site-packages/pki/system.py", line 44, in > getSecurityDomainInfo > info.name = response.json()['id'] > KeyError: 'id' > I'll have to look into this. Will fix in another patch. This will be a dogtag patch though. > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 40124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 73390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Added-ipa-drm-install.patch Type: text/x-patch Size: 22704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Added-nolog-to-pkispawn-and-some-additional-fixes-fr.patch Type: text/x-patch Size: 13199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-various-pep-8-issues-and-comments-from-review.patch Type: text/x-patch Size: 31467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-1-Added-dogtag-plugin-for-DRM.patch Type: text/x-patch Size: 23333 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Allow-ipa-replica-install-to-be-used-for-installing-.patch Type: text/x-patch Size: 19638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-set-drm-to-not-install-by-default-with-ipa-server-in.patch Type: text/x-patch Size: 1082 bytes Desc: not available URL: From tscherf at redhat.com Sat May 10 08:44:07 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Sat, 10 May 2014 10:44:07 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page In-Reply-To: <1211699075.2975520.1399670140369.JavaMail.zimbra@redhat.com> References: <20140509132339.GN572@tscherf.redhat.com> <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> <20140509151817.GT572@tscherf.redhat.com> <1211699075.2975520.1399670140369.JavaMail.zimbra@redhat.com> Message-ID: <20140510084406.GU572@tscherf.redhat.com> On [Fri, 09.05.2014 17:15], Nathaniel McCallum wrote: >----- Original Message ----- >> right, I missed that one. >> >> New patch attached. > >NACK again. (Sorry!) > >You corrected "excempt" to "except" but it should actually be "exempt". Arghh. Friday fixes. :( Next try... Cheers, Thorsten -------------- next part -------------- >From 7a9f8232558d7430258c5ff34ffe5942f85f0260 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Sat, 10 May 2014 10:41:44 +0200 Subject: [PATCH] Fixed typo in ipa-replica-manage man page --- install/tools/man/ipa-replica-manage.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/man/ipa-replica-manage.1 b/install/tools/man/ipa-replica-manage.1 index ab890284dacd8c53b620abf1e36b8d77bb077ba2..8a7c78f39eeb6c7902ed99e7bed37e32eb0e92dc 100644 --- a/install/tools/man/ipa-replica-manage.1 +++ b/install/tools/man/ipa-replica-manage.1 @@ -217,7 +217,7 @@ Remove a winsync replication agreement: .SH "PASSSYNC" PassSync is a Windows service that runs on AD Domain Controllers to intercept password changes. It sends these password changes to the IPA LDAP server over TLS. These password changes bypass normal IPA password policy settings and the password is not set to immediately expire. This is because by the time IPA receives the password change it has already been accepted by AD so it is too late to reject it. .TP -IPA maintains a list of DNs that are except from password policy. A special user is added automatically when a winsync replication agreement is created. The DN of this user is added to the exemption list stored in passSyncManagersDNs in the entry cn=ipa_pwd_extop,cn=plugins,cn=config. +IPA maintains a list of DNs that are exempt from password policy. A special user is added automatically when a winsync replication agreement is created. The DN of this user is added to the exemption list stored in passSyncManagersDNs in the entry cn=ipa_pwd_extop,cn=plugins,cn=config. .SH "EXIT STATUS" 0 if the command was successful -- 1.9.0 From npmccallum at redhat.com Sat May 10 16:18:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sat, 10 May 2014 12:18:29 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page In-Reply-To: <20140510084406.GU572@tscherf.redhat.com> References: <20140509132339.GN572@tscherf.redhat.com> <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> <20140509151817.GT572@tscherf.redhat.com> <1211699075.2975520.1399670140369.JavaMail.zimbra@redhat.com> <20140510084406.GU572@tscherf.redhat.com> Message-ID: <1602570201.3054012.1399738709228.JavaMail.zimbra@redhat.com> ACK :) ----- Original Message ----- > Arghh. Friday fixes. :( > > Next try... > > Cheers, > Thorsten > From purpleidea at gmail.com Sun May 11 17:27:39 2014 From: purpleidea at gmail.com (James) Date: Sun, 11 May 2014 13:27:39 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups Message-ID: <1399829259.12254.64.camel@freed> Hi #freeipa, I'm working on improving my puppet-ipa module... One area I'm working on is "better password management"... In any case, here's the problem: I want to give the script the ability to change it. The easy way to do this is to compare what it is currently, to what it is set to. As I'm assuming it's hashed, you have to compare hashes, IOW: /usr/bin/test `hashed(somepass)` = `function_lookup_hash()` Assuming the admin password is stored as a deterministic hash, I need two things: 1) To know how to run the hashing function manually (say from python) 2) To know how to lookup the stored hash manually (say from python) Thanks to ab (#freeipa), I know how to set the admin password: # split by the periods! $domain_split = split("${valid_domain}", '\.') # add dc= to each array element $prefix = prefix($domain_split, 'dc=') $suffix = join($prefix, ',') # eg: dc=example,dc=com $socket_realm = regsubst("${valid_realm}", '\.', '-', 'G') $ldapuri = "ldapi://%2fvar%2frun%2fslapd-${socket_realm}.socket" $admin_password_change = "/usr/bin/ldappasswd -Y EXTERNAL -s ` ${admin_password_exec}` -H ${ldapuri} uid=admin,cn=users,cn=accounts, ${suffix}" I also have the same question for the DM password, however I don't yet know how to set it. If someone has a script for that, I'd love that too! Thanks again! James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Sun May 11 18:59:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 11 May 2014 14:59:52 -0400 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: References: <536BB6F7.9000402@redhat.com> <536D33DE.6080102@redhat.com> Message-ID: <536FC8A8.50008@redhat.com> On 05/09/2014 10:01 PM, daiEric wrote: > hi > Is there any solution to deploy FreeIpa on ubuntu linux? I thought we did a lot to make this happen and it is now possible but to be fair I did not see any instructions and guidelines so I am not sure. > > thanks > Eric dai > > >> ? 2014?5?10??4:01?"Martin Kosek" ??? >> >>> On 05/08/2014 06:55 PM, Dmitri Pal wrote: >>>> On 05/08/2014 11:59 AM, Hendri Morris wrote: >>>> >>>> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >>>> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >>>> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >>>> enterprise environment and absolutely love the product. Please add AWS to the >>>> roadmap! >>>> >>>> >>>> >>>> >>>> >>>> *www.ilstechnology.com* >>>> ** >>>> *Hendri Morris* >>>> Senior Cloud Engineer >>>> deviceWISE Operations >>>> >>>> >>>> This e-mail may contain information that is confidential, privileged or >>>> otherwise protected from disclosure. If you are not an intended recipient of >>>> this e-mail, do not duplicate or redistribute it by any means. Please delete >>>> it and any attachments and notify the sender that you have received it in error. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Have you tried this? >>> http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html >> Great to hear you like FreeIPA! >> >> As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). >> >> I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Sun May 11 19:04:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 11 May 2014 15:04:00 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <1399829259.12254.64.camel@freed> References: <1399829259.12254.64.camel@freed> Message-ID: <536FC9A0.30507@redhat.com> On 05/11/2014 01:27 PM, James wrote: > Hi #freeipa, > > I'm working on improving my puppet-ipa module... > One area I'm working on is "better password management"... > > In any case, here's the problem: > > I want to give the script the ability to change it. The easy way to do > this is to compare what it is currently, to what it is set to. As I'm > assuming it's hashed, you have to compare hashes, IOW: > > /usr/bin/test `hashed(somepass)` = `function_lookup_hash()` This is scary. This means that you expecting to have a hash being stored somewhere else outside the DS. Can you describe the workflow? You want to be able to reset the admin password, right? How do you bind? Using same admin password? Or keytab? > > Assuming the admin password is stored as a deterministic hash, I need > two things: > > 1) To know how to run the hashing function manually (say from python) > 2) To know how to lookup the stored hash manually (say from python) > > Thanks to ab (#freeipa), I know how to set the admin password: > > # split by the periods! > $domain_split = split("${valid_domain}", '\.') > > # add dc= to each array element > $prefix = prefix($domain_split, 'dc=') > $suffix = join($prefix, ',') # eg: dc=example,dc=com > > $socket_realm = regsubst("${valid_realm}", '\.', '-', 'G') > $ldapuri = "ldapi://%2fvar%2frun%2fslapd-${socket_realm}.socket" > > $admin_password_change = "/usr/bin/ldappasswd -Y EXTERNAL -s ` > ${admin_password_exec}` -H ${ldapuri} uid=admin,cn=users,cn=accounts, > ${suffix}" > > I also have the same question for the DM password, however I don't yet > know how to set it. If someone has a script for that, I'd love that too! > > Thanks again! > James > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Sun May 11 22:31:12 2014 From: purpleidea at gmail.com (James) Date: Sun, 11 May 2014 18:31:12 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <536FC9A0.30507@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> Message-ID: On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal wrote: > > This is scary. > This means that you expecting to have a hash being stored somewhere else > outside the DS. Haha, I agree! Actually, worse! I will have the plain text password stored somewhere outside the DS! Let me give you more background: I think this is an atrociously bad idea. However *everybody* stores password credentials poorly in puppet. So in order to do it properly, I've gone to great lengths to support something smarter for puppet-ipa. Most of the code is already done. https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw You'll be very pleased to know it doesn't do anything bad! BUT: I am still going to support the "bad method" of storing the actual password in puppet. Sad, but still used. So I do need to know how to do this bad thing, but if you look at my code, you'll see I'm doing something clever. Once it's all done and tested, I'll blog about it and announce the technique publicly. > > Can you describe the workflow? > You want to be able to reset the admin password, right? > How do you bind? Using same admin password? Or keytab? I don't bind. I'm running as root on the free-ipa server. From dpal at redhat.com Mon May 12 01:02:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 11 May 2014 21:02:14 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> Message-ID: <53701D96.5020909@redhat.com> On 05/11/2014 06:31 PM, James wrote: > On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal wrote: >> This is scary. >> This means that you expecting to have a hash being stored somewhere else >> outside the DS. > Haha, I agree! Actually, worse! I will have the plain text password > stored somewhere outside the DS! Let me give you more background: > > I think this is an atrociously bad idea. However *everybody* stores > password credentials poorly in puppet. So in order to do it properly, > I've gone to great lengths to support something smarter for > puppet-ipa. Most of the code is already done. > Which module do you want me to look at? I am not going to review your whole project :-) > https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw > > You'll be very pleased to know it doesn't do anything bad! BUT: I am > still going to support the "bad method" of storing the actual password > in puppet. Sad, but still used. So I do need to know how to do this > bad thing, but if you look at my code, you'll see I'm doing something > clever. Once it's all done and tested, I'll blog about it and announce > the technique publicly. > >> Can you describe the workflow? >> You want to be able to reset the admin password, right? >> How do you bind? Using same admin password? Or keytab? > I don't bind. I'm running as root on the free-ipa server. But to do an LDAP operation you still need to connect to LDAP. You can use LDAPI in this case but then you do not need to authentocate at all, I think in this case you should be able to overwrite the password without knowing the old one. I do not think we should promote bad and insecure practices around the security product. That defeats the purpose. I strongle suggest avoiding saving any password and resetting the existing password using local root. I think it is possible. If not we need to think about the proper way of solving your use case. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From purpleidea at gmail.com Mon May 12 01:47:30 2014 From: purpleidea at gmail.com (James) Date: Sun, 11 May 2014 21:47:30 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <53701D96.5020909@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> Message-ID: On Sun, May 11, 2014 at 9:02 PM, Dmitri Pal wrote: > On 05/11/2014 06:31 PM, James wrote: >> >> On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal wrote: >>> >>> This is scary. >>> This means that you expecting to have a hash being stored somewhere else >>> outside the DS. >> >> Haha, I agree! Actually, worse! I will have the plain text password >> stored somewhere outside the DS! Let me give you more background: >> >> I think this is an atrociously bad idea. However *everybody* stores >> password credentials poorly in puppet. So in order to do it properly, >> I've gone to great lengths to support something smarter for >> puppet-ipa. Most of the code is already done. >> > > Which module do you want me to look at? > I am not going to review your whole project :-) I just posted it for fun. I wasn't looking for a review, though! The technique is rather complicated, so I'm going to save it for a longer blog post write up when it's finished. > > >> https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw >> >> You'll be very pleased to know it doesn't do anything bad! BUT: I am >> still going to support the "bad method" of storing the actual password >> in puppet. Sad, but still used. So I do need to know how to do this >> bad thing, but if you look at my code, you'll see I'm doing something >> clever. Once it's all done and tested, I'll blog about it and announce >> the technique publicly. >> >>> Can you describe the workflow? >>> You want to be able to reset the admin password, right? >>> How do you bind? Using same admin password? Or keytab? >> >> I don't bind. I'm running as root on the free-ipa server. > > But to do an LDAP operation you still need to connect to LDAP. You can use > LDAPI in this case but then you do not need to authentocate at all, I think > in this case you should be able to overwrite the password without knowing > the old one. > > I do not think we should promote bad and insecure practices around the > security product. That defeats the purpose. I strongle suggest avoiding > saving any password and resetting the existing password using local root. I > think it is possible. If not we need to think about the proper way of > solving your use case. Agreed. Which is why I posted the feature branch early, to hopefully convince the ipa community that I'm going about the password stuff the "right way". Anyways, back to the question: What commands can I use to look up the hash, and compute the hash? (Or simply test if a string password matches the stored password.) Same questions for the DM password. Thanks! > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From mkosek at redhat.com Mon May 12 07:11:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 May 2014 09:11:03 +0200 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> Message-ID: <53707407.9090506@redhat.com> On 05/12/2014 03:47 AM, James wrote: > On Sun, May 11, 2014 at 9:02 PM, Dmitri Pal wrote: >> On 05/11/2014 06:31 PM, James wrote: >>> >>> On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal wrote: >>>> >>>> This is scary. >>>> This means that you expecting to have a hash being stored somewhere else >>>> outside the DS. >>> >>> Haha, I agree! Actually, worse! I will have the plain text password >>> stored somewhere outside the DS! Let me give you more background: >>> >>> I think this is an atrociously bad idea. However *everybody* stores >>> password credentials poorly in puppet. So in order to do it properly, >>> I've gone to great lengths to support something smarter for >>> puppet-ipa. Most of the code is already done. >>> >> >> Which module do you want me to look at? >> I am not going to review your whole project :-) > I just posted it for fun. I wasn't looking for a review, though! > The technique is rather complicated, so I'm going to save it for a > longer blog post write up when it's finished. > >> >> >>> https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw >>> >>> You'll be very pleased to know it doesn't do anything bad! BUT: I am >>> still going to support the "bad method" of storing the actual password >>> in puppet. Sad, but still used. So I do need to know how to do this >>> bad thing, but if you look at my code, you'll see I'm doing something >>> clever. Once it's all done and tested, I'll blog about it and announce >>> the technique publicly. >>> >>>> Can you describe the workflow? >>>> You want to be able to reset the admin password, right? >>>> How do you bind? Using same admin password? Or keytab? >>> >>> I don't bind. I'm running as root on the free-ipa server. >> >> But to do an LDAP operation you still need to connect to LDAP. You can use >> LDAPI in this case but then you do not need to authentocate at all, I think >> in this case you should be able to overwrite the password without knowing >> the old one. >> >> I do not think we should promote bad and insecure practices around the >> security product. That defeats the purpose. I strongle suggest avoiding >> saving any password and resetting the existing password using local root. I >> think it is possible. If not we need to think about the proper way of >> solving your use case. > Agreed. Which is why I posted the feature branch early, to hopefully > convince the ipa community that I'm going about the password stuff the > "right way". > > Anyways, back to the question: > What commands can I use to look up the hash, and compute the hash? (Or > simply test if a string password matches the stored password.) > > Same questions for the DM password. > > Thanks! I sense some very black magic happening in this thread... I do not see any reason for storing the password or hash of the password outside of FreeIPA. As you said, you have a local root access to IPA machine, you can then bind as Directory Manager and see or change any password. 1) Get fbar1;s b64 encoded password hash: # ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket -b 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' userPassword 2) Forcefully change fbar1's password: # ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' -s newpassword Note that the user fbar1 will not be prompted for the new password as the password was changed by DM. As Dmitri wrote, a safer and a better approach would be to have the script run as a special/system user with appropriate privilege, authenticated with a keytab. Such user could then just call "ipa passwd" FreeIPA command. If you are interested in resetting DM password, you can check: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Installation_Guide/Installation_Guide-Common_Usage-Resetting_Passwords.html and http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password Martin From abokovoy at redhat.com Mon May 12 07:43:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 May 2014 10:43:21 +0300 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <53707407.9090506@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> Message-ID: <20140512074321.GA20883@redhat.com> On Mon, 12 May 2014, Martin Kosek wrote: >On 05/12/2014 03:47 AM, James wrote: >> On Sun, May 11, 2014 at 9:02 PM, Dmitri Pal wrote: >>> On 05/11/2014 06:31 PM, James wrote: >>>> >>>> On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal wrote: >>>>> >>>>> This is scary. >>>>> This means that you expecting to have a hash being stored somewhere else >>>>> outside the DS. >>>> >>>> Haha, I agree! Actually, worse! I will have the plain text password >>>> stored somewhere outside the DS! Let me give you more background: >>>> >>>> I think this is an atrociously bad idea. However *everybody* stores >>>> password credentials poorly in puppet. So in order to do it properly, >>>> I've gone to great lengths to support something smarter for >>>> puppet-ipa. Most of the code is already done. >>>> >>> >>> Which module do you want me to look at? >>> I am not going to review your whole project :-) >> I just posted it for fun. I wasn't looking for a review, though! >> The technique is rather complicated, so I'm going to save it for a >> longer blog post write up when it's finished. >> >>> >>> >>>> https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw >>>> >>>> You'll be very pleased to know it doesn't do anything bad! BUT: I am >>>> still going to support the "bad method" of storing the actual password >>>> in puppet. Sad, but still used. So I do need to know how to do this >>>> bad thing, but if you look at my code, you'll see I'm doing something >>>> clever. Once it's all done and tested, I'll blog about it and announce >>>> the technique publicly. >>>> >>>>> Can you describe the workflow? >>>>> You want to be able to reset the admin password, right? >>>>> How do you bind? Using same admin password? Or keytab? >>>> >>>> I don't bind. I'm running as root on the free-ipa server. >>> >>> But to do an LDAP operation you still need to connect to LDAP. You can use >>> LDAPI in this case but then you do not need to authentocate at all, I think >>> in this case you should be able to overwrite the password without knowing >>> the old one. >>> >>> I do not think we should promote bad and insecure practices around the >>> security product. That defeats the purpose. I strongle suggest avoiding >>> saving any password and resetting the existing password using local root. I >>> think it is possible. If not we need to think about the proper way of >>> solving your use case. >> Agreed. Which is why I posted the feature branch early, to hopefully >> convince the ipa community that I'm going about the password stuff the >> "right way". >> >> Anyways, back to the question: >> What commands can I use to look up the hash, and compute the hash? (Or >> simply test if a string password matches the stored password.) >> >> Same questions for the DM password. >> >> Thanks! > >I sense some very black magic happening in this thread... > >I do not see any reason for storing the password or hash of the password >outside of FreeIPA. As you said, you have a local root access to IPA machine, >you can then bind as Directory Manager and see or change any password. > > >1) Get fbar1;s b64 encoded password hash: > ># ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket -b >'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' userPassword > >2) Forcefully change fbar1's password: > ># ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket >'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' -s newpassword s/ldapsearch/ldappasswd/ >Note that the user fbar1 will not be prompted for the new password as the >password was changed by DM. As Dmitri wrote, a safer and a better approach >would be to have the script run as a special/system user with appropriate >privilege, authenticated with a keytab. Such user could then just call "ipa >passwd" FreeIPA command. I think the point here is that puppet-ipa module is run by puppet under root account already, so ldappasswd using ldapi with external auth under root is enough. Introducing another user when you are already root seems to be a bit overbloat in puppet's case. -- / Alexander Bokovoy From tbabej at redhat.com Mon May 12 09:56:28 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 12 May 2014 11:56:28 +0200 Subject: [Freeipa-devel] Sudorule schema inconsistencies Message-ID: <53709ACC.9050604@redhat.com> Hi fellow developers, while working on https://fedorahosted.org/freeipa/ticket/4263 I found some inconsistencies in the attribute naming: There are the following attributes in the schema: * ipasudorunas_user : RunAs Users * ipasudorunas_group : Groups of RunAs Users (and not groups you can RunAsGroup as) This implies that ipasudorunas prefix implicitly talks about RunAsUser and not RunAsGroup. This hypothesis is confirmed by attribute: * ipasudorunasgroup_group : Run with the gid of a specified POSIX group since here the prefix is ipasudorunas*group*. However, * ipasudorunasextuser : RunAs External User (consistent) * ipasudorunasextgroup : RunAs External Group (*inconsistent*, since ipasudorunas prefix means RunAsUser in other attributes. This attribute naming implies semantics of "External Groups of RunAs Users" and not "External group you can RunAsGroup as."). The ticket https://fedorahosted.org/freeipa/ticket/4263 calls for implementation of precisely this "External Groups of RunAs Users". Since ipasudorunasextgroup attribute is taken, we have the following alternatives: 1.) Create new attribute ipasudorunasgroup_extgroup and move semantics of ipasudorunasextgroup there. This frees ipasudorunasextgroup for the 4263's use case. (painful) 2.) Create new attribute with incosistent name, such as ipasudorunasextgroupmembers or ipasudorunasextusergroup. 3.) Do not create new attributes, but use a workaround which adds failed groups as users with % prefix (patch attached). What do you think? -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0999-sudorules-Allow-specifing-RunAsUser-as-external-grou.patch Type: text/x-patch Size: 2255 bytes Desc: not available URL: From jcholast at redhat.com Mon May 12 10:37:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 May 2014 12:37:47 +0200 Subject: [Freeipa-devel] Sudorule schema inconsistencies In-Reply-To: <53709ACC.9050604@redhat.com> References: <53709ACC.9050604@redhat.com> Message-ID: <5370A47B.70505@redhat.com> Hi, On 12.5.2014 11:56, Tomas Babej wrote: > Hi fellow developers, > > while working on https://fedorahosted.org/freeipa/ticket/4263 I found > some inconsistencies in the attribute naming: > > There are the following attributes in the schema: > > * ipasudorunas_user : RunAs Users > * ipasudorunas_group : Groups of RunAs Users (and not groups you can > RunAsGroup as) > > This implies that ipasudorunas prefix implicitly talks about RunAsUser > and not RunAsGroup. This hypothesis is confirmed by attribute: > > * ipasudorunasgroup_group : Run with the gid of a specified POSIX group > > since here the prefix is ipasudorunas*group*. > > However, > > * ipasudorunasextuser : RunAs External User (consistent) > * ipasudorunasextgroup : RunAs External Group (*inconsistent*, since > ipasudorunas prefix means RunAsUser in other attributes. This attribute > naming implies semantics of "External Groups of RunAs Users" and not > "External group you can RunAsGroup as."). > > The ticket https://fedorahosted.org/freeipa/ticket/4263 calls for > implementation of precisely this "External Groups of RunAs Users". Since > ipasudorunasextgroup attribute is taken, we have the following alternatives: > > 1.) Create new attribute ipasudorunasgroup_extgroup and move semantics > of ipasudorunasextgroup there. This frees ipasudorunasextgroup for the > 4263's use case. (painful) > 2.) Create new attribute with incosistent name, such as > ipasudorunasextgroupmembers or ipasudorunasextusergroup. > 3.) Do not create new attributes, but use a workaround which adds failed > groups as users with % prefix (patch attached). > > What do you think? I'm going to point out that ipasudorunas_user etc. is not an actual attribute, it's the ipasudorunas attribute after membership processing. In other words, the ipasudorunas attribute is used for both users and groups. Is there anything stopping you from doing the same thing with ipasudorunasextuser? Honza -- Jan Cholasta From mkosek at redhat.com Mon May 12 11:26:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 May 2014 13:26:43 +0200 Subject: [Freeipa-devel] Sudorule schema inconsistencies In-Reply-To: <53709ACC.9050604@redhat.com> References: <53709ACC.9050604@redhat.com> Message-ID: <5370AFF3.8010504@redhat.com> On 05/12/2014 11:56 AM, Tomas Babej wrote: > Hi fellow developers, > > while working on https://fedorahosted.org/freeipa/ticket/4263 I found > some inconsistencies in the attribute naming: > > There are the following attributes in the schema: > > * ipasudorunas_user : RunAs Users > * ipasudorunas_group : Groups of RunAs Users (and not groups you can > RunAsGroup as) > > This implies that ipasudorunas prefix implicitly talks about RunAsUser > and not RunAsGroup. This hypothesis is confirmed by attribute: > > * ipasudorunasgroup_group : Run with the gid of a specified POSIX group > > since here the prefix is ipasudorunas*group*. > > However, > > * ipasudorunasextuser : RunAs External User (consistent) > * ipasudorunasextgroup : RunAs External Group (*inconsistent*, since > ipasudorunas prefix means RunAsUser in other attributes. This attribute > naming implies semantics of "External Groups of RunAs Users" and not > "External group you can RunAsGroup as."). > > The ticket https://fedorahosted.org/freeipa/ticket/4263 calls for > implementation of precisely this "External Groups of RunAs Users". Since > ipasudorunasextgroup attribute is taken, we have the following alternatives: > > 1.) Create new attribute ipasudorunasgroup_extgroup and move semantics > of ipasudorunasextgroup there. This frees ipasudorunasextgroup for the > 4263's use case. (painful) Painful indeed. I would really prefer to avoid this option, as it would involve change upgrade plugin to migrate all sudo rules, requirement for users to upgrade *all* FreeIPA servers to avoid older servers adding inconsistent SUDO rules etc. etc. > 2.) Create new attribute with incosistent name, such as > ipasudorunasextgroupmembers or ipasudorunasextusergroup. > 3.) Do not create new attributes, but use a workaround which adds failed > groups as users with % prefix (patch attached). > > What do you think? 3) seems to be unprecedented in our code and inconsistent as well. IMO it would be also difficult to process later. '%' is a sudoers syntax specific prefix and we try to make our native tree (cn=sudo) not that much dependent on the exact sudoers syntax. I personally think 2) would be the best choice, though I agree naming will be difficult. ipasudorunasextusergroup is my favorite. But as we discussed in person, in the same patch we will need to make sure all the labeling and doc strings clarifies all this mess. Martin From pvoborni at redhat.com Mon May 12 11:37:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 May 2014 13:37:05 +0200 Subject: [Freeipa-devel] [PATCH] 22-23 webui tests extended by checking field disable property In-Reply-To: <20140507152132.379302e0@unused-4-246.brq.redhat.com> References: <20140506175809.7cfd4238@unused-4-246.brq.redhat.com> <20140507152132.379302e0@unused-4-246.brq.redhat.com> Message-ID: <5370B261.703@redhat.com> On 7.5.2014 15:21, Misnyovszki Adam wrote: > On Tue, 6 May 2014 17:58:09 +0200 > Misnyovszki Adam wrote: > >> Hi, >> first patch extends webui tests with a callback function, and an >> assert_disabled function, to check if a field is disabled under >> certain conditions. >> Second patch extends range tests with this checking functionality >> depending on range types. >> Thanks >> Adam > > Fixed issue in 22, when the element, which is checked, doesn't exist, > test returns false positive. > Thanks > Adam > > ACK and pushed to master: * 5b12367ca85153441c7d0466545bbdbd00a86927 webui tests: callback, assert_disabled feature added * aa437329104d1660d518a5dd0d5961c76a56f380 webui tests: range test extended -- Petr Vobornik From hmorris at ilstechnology.com Mon May 12 11:57:22 2014 From: hmorris at ilstechnology.com (Hendri Morris) Date: Mon, 12 May 2014 11:57:22 +0000 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: <536D33DE.6080102@redhat.com> References: <536BB6F7.9000402@redhat.com>,<536D33DE.6080102@redhat.com> Message-ID: Dmitri - Thanks for your quick reply I was already aware of the link. Thanks though. Martin - You are exactly on point. It is just a packaging issue. How much work would it be to make the dependency tree compatible with the .amzn packages? Unfortunately IPA alone is not enough of a reason for us to drop using Amazon Linux on their EC2 Cloud since there are many tweaks already done that we don't have to track and manage as we would using CentOS. Also using the other Linux AMIs you can miss out on new features (like new instance-types) since it often takes weeks or months for CentOS update their AMIs as Amazon constantly evolves the AWS platform. Here is some output. Most the package library versions look compatible but and appears to conflict only because the pakage name says .amzn instead of .el6. This should be easy to fix on the development side no? [root at ip-9-9-9-9~]# rpm -ivh --nodeps http://mirror.centos.org/centos/6/os/x86_64/Packages/autofs-5.0.5-88.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libipa_hbac-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libipa_hbac-python-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libnl-1.1.4-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libref_array-devel-0.1.1-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtirpc-0.2.1-6.el6_4.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/nfs-utils-1.2.3-39.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/pytalloc-2.0.7-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/samba4-4.0.0-58.el6.rc4.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/sssd-client-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/xmlrpc-c-1.16.24-1210.1840.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/xmlrpc-c-client-1.16.24-1210.1840.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cups-libs-1.4.2-50.el6_4.5.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/gnutls-2.8.5-10.el6_4.2.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/bind-libs-9.8.2-0.17.rc1.el6_4.6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libsss_idmap-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/krb5-libs-1.10.3-10.el6_4.6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/ipa-client-3.0.0-37.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/ipa-python-3.0.0-37.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/oddjob-mkhomedir-0.30-5.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/sssd-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/certmonger-0.61-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libsss_autofs-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libxslt-1.1.26-2.el6_3.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/oddjob-0.30-5.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/nfs-utils-lib-1.1.5-6.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/pyOpenSSL-0.10-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-kerberos-1.1-6.2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-krbV-1.0.90-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-ldap-2.3.10-1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-lxml-2.2.3-1.1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-netaddr-0.7.5-4.el6.noarch.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-nss-0.13-1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/rpcbind-0.2.0-11.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtalloc-2.0.7-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtasn1-2.3-3.el6_2.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtdb-1.2.10-1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtevent-0.9.18-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtiff-3.9.4-9.el6_3.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libpath_utils-0.2.1-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libldb-1.1.13-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libcollection-0.6.0-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libdhash-0.4.2-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libevent-1.4.13-4.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libgssglue-0.1-11.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libini_config-0.6.1-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/keyutils-libs-1.4-4.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/keyutils-1.4-4.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/avahi-libs-0.6.25-12.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/c-ares-1.7.0-6.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64.rpm > out.txt warning: /var/tmp/rpm-tmp.FaAJYs: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 (which is newer than cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64) is already installed file /usr/lib64/libsasl2.so.2.0.23 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/lib64/sasl2/libanonymous.so.2.0.23 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/lib64/sasl2/libsasldb.so.2.0.23 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/sbin/sasldblistusers2 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/sbin/saslpasswd2 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/AUTHORS from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/COPYING from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/NEWS from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/README from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/advanced.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/appconvert.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/components.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/gssapi.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/index.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/install.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/macosx.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/mechanisms.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/options.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/plugprog.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/programming.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/readme.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/sysadmin.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/upgrading.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/windows.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 package keyutils-libs-1.4-4.10.amzn1.x86_64 (which is newer than keyutils-libs-1.4-4.el6.x86_64) is already installed file /lib64/libkeyutils.so.1.3 from install of keyutils-libs-1.4-4.el6.x86_64 conflicts with file from package keyutils-libs-1.4-4.10.amzn1.x86_64 file /usr/share/doc/keyutils-libs-1.4/LICENCE.LGPL from install of keyutils-libs-1.4-4.el6.x86_64 conflicts with file from package keyutils-libs-1.4-4.10.amzn1.x86_64 package krb5-libs-1.10.3-10.26.amzn1.x86_64 (which is newer than krb5-libs-1.10.3-10.el6_4.6.x86_64) is already installed file /usr/share/doc/krb5-libs-1.10.3/README from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /etc/krb5.conf from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libgssapi_krb5.so.2.2 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libgssrpc.so.4.1 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libk5crypto.so.3.1 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libkrb5.so.3.3 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libkrb5support.so.0.1 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/krb5/plugins/kdb/db2.so from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libkadm5clnt_mit.so.8.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libkadm5srv_mit.so.8.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libkdb5.so.6.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libverto-k5ev.so.0.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libverto.so.0.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/doc/krb5-libs-1.10.3/NOTICE from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/locale/en_US/LC_MESSAGES/mit-krb5.mo from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man1/kerberos.1.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/.k5identity.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/.k5login.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/k5identity.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/k5login.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/krb5.conf.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 package libtasn1-2.3-3.4.amzn1.x86_64 (which is newer than libtasn1-2.3-3.el6_2.1.x86_64) is already installed file /usr/share/doc/libtasn1-2.3/AUTHORS from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/COPYING from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/NEWS from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/README from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/ChangeLog from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/TODO from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/THANKS from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/lib64/libtasn1.so.3.1.6 from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/COPYING.LIB from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/libtasn1.pdf from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 package libxslt-1.1.28-3.8.amzn1.x86_64 (which is newer than libxslt-1.1.26-2.el6_3.1.x86_64) is already installed file /usr/bin/xsltproc from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 file /usr/lib64/libexslt.so.0 from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 file /usr/lib64/libxslt.so.1 from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 file /usr/share/man/man1/xsltproc.1.gz from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 (which is newer than bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64) is already installed file /usr/lib64/libbind9.so.80.0.4 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libdns.so.81.4.1 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libisc.so.83.0.3 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libisccc.so.80.0.0 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libisccfg.so.82.0.1 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/liblwres.so.80.0.2 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 [root at ip-9-9-9-9~]# Hendri Morris Senior Cloud Engineer deviceWISE Operations www.ilstechnology.com ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Friday, May 09, 2014 4:00 PM To: dpal at redhat.com; freeipa-devel at redhat.com; Hendri Morris Subject: Re: [Freeipa-devel] FreeIPA on AWS EC2 On 05/08/2014 06:55 PM, Dmitri Pal wrote: > On 05/08/2014 11:59 AM, Hendri Morris wrote: >> >> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >> enterprise environment and absolutely love the product. Please add AWS to the >> roadmap! >> >> >> >> >> >> *www.ilstechnology.com* >> ** >> *Hendri Morris* >> Senior Cloud Engineer >> deviceWISE Operations >> >> >> This e-mail may contain information that is confidential, privileged or >> otherwise protected from disclosure. If you are not an intended recipient of >> this e-mail, do not duplicate or redistribute it by any means. Please delete >> it and any attachments and notify the sender that you have received it in error. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Have you tried this? > http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html Great to hear you like FreeIPA! As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. Martin This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. From hmorris at ilstechnology.com Fri May 9 21:19:26 2014 From: hmorris at ilstechnology.com (Hendri Morris) Date: Fri, 9 May 2014 21:19:26 +0000 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: <536D33DE.6080102@redhat.com> References: <536BB6F7.9000402@redhat.com>,<536D33DE.6080102@redhat.com> Message-ID: Dmitri - Thanks for your quick reply I was already aware of the link. Thanks though. Martin - You are exactly on point. It is just a packaging issue. How much work would it be to make the dependency tree compatible with the .amzn packages? Unfortunately IPA alone is not enough of a reason for us to drop using Amazon Linux on their EC2 Cloud since there are many tweaks already done that we don't have to track and manage as we would using CentOS. Also using the other Linux AMIs you can miss out on new features (like new instance-types) since it often takes weeks or months for CentOS update their AMIs as Amazon constantly evolves the AWS platform. Here is some output. Most the package library versions look compatible but and appears to conflict only because the pakage name says .amzn instead of .el6. This should be easy to fix on the development side no? [root at ip-9-9-9-9~]# rpm -ivh --nodeps http://mirror.centos.org/centos/6/os/x86_64/Packages/autofs-5.0.5-88.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libipa_hbac-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libipa_hbac-python-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libnl-1.1.4-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libref_array-devel-0.1.1-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtirpc-0.2.1-6.el6_4.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/nfs-utils-1.2.3-39.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/pytalloc-2.0.7-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/samba4-4.0.0-58.el6.rc4.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/sssd-client-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/xmlrpc-c-1.16.24-1210.1840.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/xmlrpc-c-client-1.16.24-1210.1840.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cups-libs-1.4.2-50.el6_4.5.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/gnutls-2.8.5-10.el6_4.2.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/bind-libs-9.8.2-0.17.rc1.el6_4.6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libsss_idmap-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/krb5-libs-1.10.3-10.el6_4.6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/ipa-client-3.0.0-37.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/ipa-python-3.0.0-37.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/oddjob-mkhomedir-0.30-5.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/sssd-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/certmonger-0.61-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libsss_autofs-1.9.2-129.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libxslt-1.1.26-2.el6_3.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/oddjob-0.30-5.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/nfs-utils-lib-1.1.5-6.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/pyOpenSSL-0.10-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-kerberos-1.1-6.2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-krbV-1.0.90-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-ldap-2.3.10-1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-lxml-2.2.3-1.1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-netaddr-0.7.5-4.el6.noarch.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-nss-0.13-1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/rpcbind-0.2.0-11.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtalloc-2.0.7-2.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtasn1-2.3-3.el6_2.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtdb-1.2.10-1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtevent-0.9.18-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtiff-3.9.4-9.el6_3.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libpath_utils-0.2.1-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libldb-1.1.13-3.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libcollection-0.6.0-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libdhash-0.4.2-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libevent-1.4.13-4.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libgssglue-0.1-11.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libini_config-0.6.1-9.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/keyutils-libs-1.4-4.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/keyutils-1.4-4.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/avahi-libs-0.6.25-12.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/c-ares-1.7.0-6.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64.rpm > out.txt warning: /var/tmp/rpm-tmp.FaAJYs: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 (which is newer than cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64) is already installed file /usr/lib64/libsasl2.so.2.0.23 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/lib64/sasl2/libanonymous.so.2.0.23 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/lib64/sasl2/libsasldb.so.2.0.23 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/sbin/sasldblistusers2 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/sbin/saslpasswd2 from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/AUTHORS from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/COPYING from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/NEWS from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/README from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/advanced.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/appconvert.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/components.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/gssapi.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/index.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/install.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/macosx.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/mechanisms.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/options.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/plugprog.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/programming.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/readme.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/sysadmin.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/upgrading.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 file /usr/share/doc/cyrus-sasl-lib-2.1.23/windows.html from install of cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 conflicts with file from package cyrus-sasl-lib-2.1.23-13.13.amzn1.x86_64 package keyutils-libs-1.4-4.10.amzn1.x86_64 (which is newer than keyutils-libs-1.4-4.el6.x86_64) is already installed file /lib64/libkeyutils.so.1.3 from install of keyutils-libs-1.4-4.el6.x86_64 conflicts with file from package keyutils-libs-1.4-4.10.amzn1.x86_64 file /usr/share/doc/keyutils-libs-1.4/LICENCE.LGPL from install of keyutils-libs-1.4-4.el6.x86_64 conflicts with file from package keyutils-libs-1.4-4.10.amzn1.x86_64 package krb5-libs-1.10.3-10.26.amzn1.x86_64 (which is newer than krb5-libs-1.10.3-10.el6_4.6.x86_64) is already installed file /usr/share/doc/krb5-libs-1.10.3/README from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /etc/krb5.conf from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libgssapi_krb5.so.2.2 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libgssrpc.so.4.1 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libk5crypto.so.3.1 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libkrb5.so.3.3 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /lib64/libkrb5support.so.0.1 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/krb5/plugins/kdb/db2.so from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libkadm5clnt_mit.so.8.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libkadm5srv_mit.so.8.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libkdb5.so.6.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libverto-k5ev.so.0.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/lib64/libverto.so.0.0 from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/doc/krb5-libs-1.10.3/NOTICE from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/locale/en_US/LC_MESSAGES/mit-krb5.mo from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man1/kerberos.1.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/.k5identity.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/.k5login.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/k5identity.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/k5login.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 file /usr/share/man/man5/krb5.conf.5.gz from install of krb5-libs-1.10.3-10.el6_4.6.x86_64 conflicts with file from package krb5-libs-1.10.3-10.26.amzn1.x86_64 package libtasn1-2.3-3.4.amzn1.x86_64 (which is newer than libtasn1-2.3-3.el6_2.1.x86_64) is already installed file /usr/share/doc/libtasn1-2.3/AUTHORS from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/COPYING from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/NEWS from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/README from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/ChangeLog from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/TODO from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/THANKS from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/lib64/libtasn1.so.3.1.6 from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/COPYING.LIB from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 file /usr/share/doc/libtasn1-2.3/libtasn1.pdf from install of libtasn1-2.3-3.el6_2.1.x86_64 conflicts with file from package libtasn1-2.3-3.4.amzn1.x86_64 package libxslt-1.1.28-3.8.amzn1.x86_64 (which is newer than libxslt-1.1.26-2.el6_3.1.x86_64) is already installed file /usr/bin/xsltproc from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 file /usr/lib64/libexslt.so.0 from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 file /usr/lib64/libxslt.so.1 from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 file /usr/share/man/man1/xsltproc.1.gz from install of libxslt-1.1.26-2.el6_3.1.x86_64 conflicts with file from package libxslt-1.1.28-3.8.amzn1.x86_64 package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 (which is newer than bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64) is already installed file /usr/lib64/libbind9.so.80.0.4 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libdns.so.81.4.1 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libisc.so.83.0.3 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libisccc.so.80.0.0 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/libisccfg.so.82.0.1 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 file /usr/lib64/liblwres.so.80.0.2 from install of bind-libs-32:9.8.2-0.17.rc1.el6_4.6.x86_64 conflicts with file from package bind-libs-32:9.8.2-0.23.rc1.32.amzn1.x86_64 [root at ip-9-9-9-9~]# Hendri Morris Senior Cloud Engineer deviceWISE Operations ILS Technology 5300 Broken Sound Boulevard, Suite 150 Boca Raton, FL 33487 USA Phone +1 561.982.9898 Mobile +1 561.997.4155 Fax +1 561.982.8638 www.ilstechnology.com ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Friday, May 09, 2014 4:00 PM To: dpal at redhat.com; freeipa-devel at redhat.com; Hendri Morris Subject: Re: [Freeipa-devel] FreeIPA on AWS EC2 On 05/08/2014 06:55 PM, Dmitri Pal wrote: > On 05/08/2014 11:59 AM, Hendri Morris wrote: >> >> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >> enterprise environment and absolutely love the product. Please add AWS to the >> roadmap! >> >> >> >> >> >> *www.ilstechnology.com* >> ** >> *Hendri Morris* >> Senior Cloud Engineer >> deviceWISE Operations >> >> >> This e-mail may contain information that is confidential, privileged or >> otherwise protected from disclosure. If you are not an intended recipient of >> this e-mail, do not duplicate or redistribute it by any means. Please delete >> it and any attachments and notify the sender that you have received it in error. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Have you tried this? > http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html Great to hear you like FreeIPA! As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. Martin This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. From rcritten at redhat.com Mon May 12 13:28:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 May 2014 09:28:21 -0400 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: <536FC8A8.50008@redhat.com> References: <536BB6F7.9000402@redhat.com> <536D33DE.6080102@redhat.com> <536FC8A8.50008@redhat.com> Message-ID: <5370CC75.3050700@redhat.com> Dmitri Pal wrote: > On 05/09/2014 10:01 PM, daiEric wrote: >> hi >> Is there any solution to deploy FreeIpa on ubuntu linux? > > I thought we did a lot to make this happen and it is now possible but to > be fair I did not see any instructions and guidelines so I am not sure. AFAIK the server work is still in process. There are client packages available for freeipa-client and sssd, though expect some bumps during installation as it is still a work in progress. rob > >> >> thanks >> Eric dai >> >> >>> ? 2014?5?10??4:01?"Martin Kosek" ??? >>> >>>> On 05/08/2014 06:55 PM, Dmitri Pal wrote: >>>>> On 05/08/2014 11:59 AM, Hendri Morris wrote: >>>>> >>>>> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >>>>> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >>>>> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >>>>> enterprise environment and absolutely love the product. Please add AWS to the >>>>> roadmap! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *www.ilstechnology.com* >>>>> ** >>>>> *Hendri Morris* >>>>> Senior Cloud Engineer >>>>> deviceWISE Operations >>>>> >>>>> >>>>> This e-mail may contain information that is confidential, privileged or >>>>> otherwise protected from disclosure. If you are not an intended recipient of >>>>> this e-mail, do not duplicate or redistribute it by any means. Please delete >>>>> it and any attachments and notify the sender that you have received it in error. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Have you tried this? >>>> http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html >>> Great to hear you like FreeIPA! >>> >>> As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). >>> >>> I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > > From amisnyov at redhat.com Mon May 12 15:46:43 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 12 May 2014 17:46:43 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <5367BF29.2070901@redhat.com> References: <5367BF29.2070901@redhat.com> Message-ID: <20140512174643.60e13a05@unused-4-246.brq.redhat.com> 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 > 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 - 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 - 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 - in 320x480, login page configuration text overflows on a white background, especially if there is a login error, which makes the white text unreadable > 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. > 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 - 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 Thanks Adam From amisnyov at redhat.com Mon May 12 16:13:42 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 12 May 2014 18:13:42 +0200 Subject: [Freeipa-devel] [PATCH] 589-590 webui-ci: save screenshot on test failure In-Reply-To: <5360B70B.7010004@redhat.com> References: <5360B70B.7010004@redhat.com> Message-ID: <20140512181342.09ec4d47@unused-4-246.brq.redhat.com> On Wed, 30 Apr 2014 10:40:43 +0200 Petr Vobornik wrote: > Very handy for debugging failures... > > New decorator: ui_driver.screenshot created. It should be applied on > test methods. > > Screenshot is saved on each exception except SkipTest. > > Configuration: > - add: `save_screenshots: True` to ~/.ipa/ui_test.conf to enable > saving screenshots > - optionally add `screenshot_dir: /path/to/dir` to specify target > directory otherwise screenshots are saved to current directory Hi, LGTM, it even saves screenshots when I use remote testing, so ACK Adam From amisnyov at redhat.com Mon May 12 16:40:05 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 12 May 2014 18:40:05 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1399391174.9864.6.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> Message-ID: <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> On Tue, 06 May 2014 11:46:14 -0400 Nathaniel McCallum wrote: > On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > > On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > > > On 6.5.2014 17:13, Nathaniel McCallum wrote: > > > > On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > > > >> On 6.5.2014 16:51, Nathaniel McCallum wrote: > > > >>> Specifying the default in the LDAP Object causes the > > > >>> parameter to be specified for non-add operations. This is > > > >>> especially problematic when performing the modify operation > > > >>> as it causes the primary key to change for every modification. > > > >>> > > > >>> https://fedorahosted.org/freeipa/ticket/4227 > > > >>> > > > >> > > > >> shouldn't removal of `autofill=True,` be enough? > > > > > > > > Removing autofill=True results in the default not being used > > > > for the otptoken-add operation. That may be a different bug > > > > (I'm not sure what the expectation of autofill is). > > > > > > > > Nathaniel > > > > > > > > > > Seems to work form me with: > > > > > > diff --git a/ipalib/plugins/otptoken.py > > > b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > > > --- a/ipalib/plugins/otptoken.py > > > +++ b/ipalib/plugins/otptoken.py > > > @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > > > cli_name='id', > > > label=_('Unique ID'), > > > default_from=lambda: unicode(uuid.uuid4()), > > > - autofill=True, > > > primary_key=True, > > > - flags=('optional_create'), > > > ), > > > StrEnum('type?', > > > label=_('Type'), > > > > Doing this causes the ipa otptoken-add command to prompt for the > > Unique ID. This may be the desired behavior, but it is not how it > > worked previously (no prompt). > > Here is an alternate patch for this second approach. I have no strong > opinion on the correct behavior here. > > Nathaniel IMO you should update API.txt with ./makeapi Thanks Adam From pvoborni at redhat.com Mon May 12 16:49:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 May 2014 18:49:43 +0200 Subject: [Freeipa-devel] [PATCH 0001] Fixed typo in ipa-replica-manage man page In-Reply-To: <1602570201.3054012.1399738709228.JavaMail.zimbra@redhat.com> References: <20140509132339.GN572@tscherf.redhat.com> <199963735.2779715.1399645517109.JavaMail.zimbra@redhat.com> <20140509151817.GT572@tscherf.redhat.com> <1211699075.2975520.1399670140369.JavaMail.zimbra@redhat.com> <20140510084406.GU572@tscherf.redhat.com> <1602570201.3054012.1399738709228.JavaMail.zimbra@redhat.com> Message-ID: <5370FBA7.8070608@redhat.com> On 10.5.2014 18:18, Nathaniel McCallum wrote: > ACK :) This patch doesn't apply on master. I had to apply it on all the previous revisions. I did the squashing (attached), but please squash them in a future. Pushed to master: 37c238a6ef8f825f85351a5974b4270998bc0661 > > ----- Original Message ----- >> Arghh. Friday fixes. :( >> >> Next try... >> >> Cheers, >> Thorsten >> -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-typo-in-ipa-replica-manage-man-page.patch Type: text/x-patch Size: 1652 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 12 16:54:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 May 2014 18:54:14 +0200 Subject: [Freeipa-devel] [PATCH] 589-590 webui-ci: save screenshot on test failure In-Reply-To: <20140512181342.09ec4d47@unused-4-246.brq.redhat.com> References: <5360B70B.7010004@redhat.com> <20140512181342.09ec4d47@unused-4-246.brq.redhat.com> Message-ID: <5370FCB6.3050809@redhat.com> On 12.5.2014 18:13, Misnyovszki Adam wrote: > On Wed, 30 Apr 2014 10:40:43 +0200 > Petr Vobornik wrote: > >> Very handy for debugging failures... >> >> New decorator: ui_driver.screenshot created. It should be applied on >> test methods. >> >> Screenshot is saved on each exception except SkipTest. >> >> Configuration: >> - add: `save_screenshots: True` to ~/.ipa/ui_test.conf to enable >> saving screenshots >> - optionally add `screenshot_dir: /path/to/dir` to specify target >> directory otherwise screenshots are saved to current directory > > Hi, > LGTM, it even saves screenshots when I use remote testing, so > ACK > > Adam > pushed to master: * 6a61378586eb51eaa271ce492566309b0f68de59 webui-ci: save screenshot on test failure * 6d618853a4d519c8671e2e38f1aaa290a6d62b83 webui-ci: decorate all webui tests with screenshot decorator -- Petr Vobornik From npmccallum at redhat.com Mon May 12 18:50:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 12 May 2014 14:50:43 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> Message-ID: <1399920643.3005.0.camel@ipa.example.com> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: > On Tue, 06 May 2014 11:46:14 -0400 > Nathaniel McCallum wrote: > > > On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > > > On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > > > > On 6.5.2014 17:13, Nathaniel McCallum wrote: > > > > > On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > > > > >> On 6.5.2014 16:51, Nathaniel McCallum wrote: > > > > >>> Specifying the default in the LDAP Object causes the > > > > >>> parameter to be specified for non-add operations. This is > > > > >>> especially problematic when performing the modify operation > > > > >>> as it causes the primary key to change for every modification. > > > > >>> > > > > >>> https://fedorahosted.org/freeipa/ticket/4227 > > > > >>> > > > > >> > > > > >> shouldn't removal of `autofill=True,` be enough? > > > > > > > > > > Removing autofill=True results in the default not being used > > > > > for the otptoken-add operation. That may be a different bug > > > > > (I'm not sure what the expectation of autofill is). > > > > > > > > > > Nathaniel > > > > > > > > > > > > > Seems to work form me with: > > > > > > > > diff --git a/ipalib/plugins/otptoken.py > > > > b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > > > > --- a/ipalib/plugins/otptoken.py > > > > +++ b/ipalib/plugins/otptoken.py > > > > @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > > > > cli_name='id', > > > > label=_('Unique ID'), > > > > default_from=lambda: unicode(uuid.uuid4()), > > > > - autofill=True, > > > > primary_key=True, > > > > - flags=('optional_create'), > > > > ), > > > > StrEnum('type?', > > > > label=_('Type'), > > > > > > Doing this causes the ipa otptoken-add command to prompt for the > > > Unique ID. This may be the desired behavior, but it is not how it > > > worked previously (no prompt). > > > > Here is an alternate patch for this second approach. I have no strong > > opinion on the correct behavior here. > > > > Nathaniel > > IMO you should update API.txt with ./makeapi Running ./makeapi results in no changes to API.txt. Nathaniel From npmccallum at redhat.com Mon May 12 19:02:44 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 12 May 2014 15:02:44 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399571481.2708.2.camel@willson.li.ssimo.org> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> Message-ID: <1399921364.3005.9.camel@ipa.example.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > > = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; > > acl "Users can create and delete tokens"; allow (add, delete) userattr = > > "ipatokenOwner#SELFDN";) > > > > This is what they look like using managedBy (I have not tested this): > > > > 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"; allow (read, search, compare) > > userattr = "managedBy#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"; allow > > (read, search, compare) userattr = "managedBy#USERDN";) > > > > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > > see HOTP details"; allow (read, search, compare) userattr = > > "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > > "managedBy#USERDN";) > > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > "description || ipatokenDisabled || ipatokenNotBefore || > > ipatokenNotAfter || ipatokenVendor || ipatokenModel || > > ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; > > allow (write) userattr = "managedBy#USERDN";) > > > > aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > > "Managers can delete tokens"; allow (delete) userattr = > > "managedBy#USERDN";) > > > > aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > > = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > > userattr = "managedBy#SELFDN";) > > > > In short: > > 1. Owner and manager get read, search and compare. > > 2. Manager gets write (to select attributes) and delete. > > 3. Users can create self-managed tokens for themselves only. > > > > The otptoken-add command should gain the following defaults: > > 1. The owner defaults to the user adding the token. > > 2. If owner == user adding token, managedBy defaults to owner. > > 3. Otherwise, managedBy defaults to None. > > > > This means that if neither owner nor managedBy are specified, the > > default is a self-owned, self-managed token. Likewise, if a different > > owner is specified, no manager is assumed. > > > > rcrit expresses worry that ipalib's ACI parser may not handle the above > > syntax. This will become clear during testing if we want this approach. > > > > Does this look sane? > > I am not entirely sure your ACI syntax is always right for the second > set. and perhaps we want to duplicate ACIs in some cases (once for owner > once for manager). > > I think the read ACIs do not need to list managedby ? Do we plan to have > a manager that is another regular user but not the owner nor an admin ? > > In any case I prefer the sytnax that uses managedby, as it has more > potential. Attached is a new version of the patch which implements the feature using managedBy instead of ipatokenProtected. One important thing needs to be said about this patch. I am not exposing managedBy in either the UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I expose this similar to owner or as a relationship? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0049a-Add-support-managedBy-to-tokens.patch Type: text/x-patch Size: 15254 bytes Desc: not available URL: From dpal at redhat.com Mon May 12 20:15:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 May 2014 16:15:34 -0400 Subject: [Freeipa-devel] FreeIPA on AWS EC2 In-Reply-To: References: <536BB6F7.9000402@redhat.com> <536D33DE.6080102@redhat.com> Message-ID: <53712BE6.9030009@redhat.com> On 05/09/2014 10:01 PM, daiEric wrote: > hi > Is there any solution to deploy FreeIpa on ubuntu linux? OK, so after some investigation it seems that there is none. Some components can be used on Ubuntu but the whole IPA is not built on Ubuntu. We would welcome anyone to take the ownership of this task and make this possible. Thanks Dmitri > > thanks > Eric dai > > >> ? 2014?5?10??4:01?"Martin Kosek" ??? >> >>> On 05/08/2014 06:55 PM, Dmitri Pal wrote: >>>> On 05/08/2014 11:59 AM, Hendri Morris wrote: >>>> >>>> Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the >>>> client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). >>>> Goes straight to dependency hell. I deployed a multi-server FreeIPA in a >>>> enterprise environment and absolutely love the product. Please add AWS to the >>>> roadmap! >>>> >>>> >>>> >>>> >>>> >>>> *www.ilstechnology.com* >>>> ** >>>> *Hendri Morris* >>>> Senior Cloud Engineer >>>> deviceWISE Operations >>>> >>>> >>>> This e-mail may contain information that is confidential, privileged or >>>> otherwise protected from disclosure. If you are not an intended recipient of >>>> this e-mail, do not duplicate or redistribute it by any means. Please delete >>>> it and any attachments and notify the sender that you have received it in error. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Have you tried this? >>> http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html >> Great to hear you like FreeIPA! >> >> As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the "Red Hat clone"). >> >> I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon May 12 20:25:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 May 2014 16:25:07 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <20140512074321.GA20883@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> Message-ID: <53712E23.2010404@redhat.com> On 05/12/2014 03:43 AM, Alexander Bokovoy wrote: > On Mon, 12 May 2014, Martin Kosek wrote: >> On 05/12/2014 03:47 AM, James wrote: >>> On Sun, May 11, 2014 at 9:02 PM, Dmitri Pal wrote: >>>> On 05/11/2014 06:31 PM, James wrote: >>>>> >>>>> On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal wrote: >>>>>> >>>>>> This is scary. >>>>>> This means that you expecting to have a hash being stored >>>>>> somewhere else >>>>>> outside the DS. >>>>> >>>>> Haha, I agree! Actually, worse! I will have the plain text password >>>>> stored somewhere outside the DS! Let me give you more background: >>>>> >>>>> I think this is an atrociously bad idea. However *everybody* stores >>>>> password credentials poorly in puppet. So in order to do it properly, >>>>> I've gone to great lengths to support something smarter for >>>>> puppet-ipa. Most of the code is already done. >>>>> >>>> >>>> Which module do you want me to look at? >>>> I am not going to review your whole project :-) >>> I just posted it for fun. I wasn't looking for a review, though! >>> The technique is rather complicated, so I'm going to save it for a >>> longer blog post write up when it's finished. >>> >>>> >>>> >>>>> https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw >>>>> >>>>> You'll be very pleased to know it doesn't do anything bad! BUT: I am >>>>> still going to support the "bad method" of storing the actual >>>>> password >>>>> in puppet. Sad, but still used. So I do need to know how to do this >>>>> bad thing, but if you look at my code, you'll see I'm doing something >>>>> clever. Once it's all done and tested, I'll blog about it and >>>>> announce >>>>> the technique publicly. >>>>> >>>>>> Can you describe the workflow? >>>>>> You want to be able to reset the admin password, right? >>>>>> How do you bind? Using same admin password? Or keytab? >>>>> >>>>> I don't bind. I'm running as root on the free-ipa server. >>>> >>>> But to do an LDAP operation you still need to connect to LDAP. You >>>> can use >>>> LDAPI in this case but then you do not need to authentocate at all, >>>> I think >>>> in this case you should be able to overwrite the password without >>>> knowing >>>> the old one. >>>> >>>> I do not think we should promote bad and insecure practices around the >>>> security product. That defeats the purpose. I strongle suggest >>>> avoiding >>>> saving any password and resetting the existing password using local >>>> root. I >>>> think it is possible. If not we need to think about the proper way of >>>> solving your use case. >>> Agreed. Which is why I posted the feature branch early, to hopefully >>> convince the ipa community that I'm going about the password stuff the >>> "right way". >>> >>> Anyways, back to the question: >>> What commands can I use to look up the hash, and compute the hash? (Or >>> simply test if a string password matches the stored password.) >>> >>> Same questions for the DM password. >>> >>> Thanks! >> >> I sense some very black magic happening in this thread... >> >> I do not see any reason for storing the password or hash of the password >> outside of FreeIPA. As you said, you have a local root access to IPA >> machine, >> you can then bind as Directory Manager and see or change any password. >> >> >> 1) Get fbar1;s b64 encoded password hash: >> >> # ldapsearch -Y EXTERNAL -H >> ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket -b >> 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' userPassword >> >> 2) Forcefully change fbar1's password: >> >> # ldapsearch -Y EXTERNAL -H >> ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket >> 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' -s newpassword > s/ldapsearch/ldappasswd/ > >> Note that the user fbar1 will not be prompted for the new password as >> the >> password was changed by DM. As Dmitri wrote, a safer and a better >> approach >> would be to have the script run as a special/system user with >> appropriate >> privilege, authenticated with a keytab. Such user could then just >> call "ipa >> passwd" FreeIPA command. > I think the point here is that puppet-ipa module is run by puppet under > root account already, so ldappasswd using ldapi with external auth > under root > is enough. Introducing another user when you are already root seems to > be a bit overbloat in puppet's case. > Yes and this was my point too. If you have root you do not need to know the old password. You can just reset the current one to what you want. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From purpleidea at gmail.com Mon May 12 20:28:22 2014 From: purpleidea at gmail.com (James) Date: Mon, 12 May 2014 16:28:22 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <53712E23.2010404@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> Message-ID: <1399926502.29751.11.camel@freed> On Mon, 2014-05-12 at 16:25 -0400, Dmitri Pal wrote: > Yes and this was my point too. If you have root you do not need to > know > the old password. You can just reset the current one to what you want. I agree, with you. This isn't about functionality, it's about automating functionality. Puppet needs to know if the stored password matches the password it thinks is correct. Without this it would just try and run "setpassword" each run. I will test Martin's command shortly :) Cheers! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Mon May 12 21:11:13 2014 From: purpleidea at gmail.com (James) Date: Mon, 12 May 2014 17:11:13 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <53707407.9090506@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> Message-ID: <1399929073.29751.14.camel@freed> On Mon, 2014-05-12 at 09:11 +0200, Martin Kosek wrote: > 1) Get fbar1;s b64 encoded password hash: > > # ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun% > 2fslapd-EXAMPLE-COM.socket -b > 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' userPassword This seems to work great. I used user 'admin'. I assume this is the same admin user. 1) Is this command something that is stable for use in scripting, or is there a more machine-readable recommended way? 2) How can I compute/compare that hash to my password string? password I selected is 'password'. :) Thanks again! Output is: [root at ipa ~]# ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun% 2fslapd-EXAMPLE-COM.socket -b 'uid=admin,cn=users,cn=accounts,dc=example,dc=com' userPassword SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: userPassword # # admin, users, accounts, example.com dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com userPassword:: e1NTSEF9cjc0OGc3ZThnY1FsWVpwVFNqWU8yMDAreTF2WEZNRjVUSXBQV3c9PQ= = # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa ~]# -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Mon May 12 21:56:05 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 May 2014 17:56:05 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <1399926502.29751.11.camel@freed> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> Message-ID: <53714375.6020605@redhat.com> On 05/12/2014 04:28 PM, James wrote: > On Mon, 2014-05-12 at 16:25 -0400, Dmitri Pal wrote: >> Yes and this was my point too. If you have root you do not need to >> know >> the old password. You can just reset the current one to what you want. > I agree, with you. This isn't about functionality, it's about automating > functionality. Puppet needs to know if the stored password matches the > password it thinks is correct. Without this it would just try and run > "setpassword" each run. > > I will test Martin's command shortly :) > > Cheers! > Is there any other attribute to look at? For example the timestamp when it was last set and base the update on that rather than on matching password values? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From purpleidea at gmail.com Mon May 12 22:07:06 2014 From: purpleidea at gmail.com (James) Date: Mon, 12 May 2014 18:07:06 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <53714375.6020605@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> Message-ID: <1399932426.29751.15.camel@freed> On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: > Is there any other attribute to look at? > For example the timestamp when it was last set and base the update on > that rather than on matching password values? > There are some other solutions, but they are less elegant or don't work consistently. (Eg: bad hacks) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Mon May 12 22:22:55 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 May 2014 18:22:55 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <1399932426.29751.15.camel@freed> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> <1399932426.29751.15.camel@freed> Message-ID: <537149BF.80900@redhat.com> On 05/12/2014 06:07 PM, James wrote: > On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: >> Is there any other attribute to look at? >> For example the timestamp when it was last set and base the update on >> that rather than on matching password values? >> > There are some other solutions, but they are less elegant or don't work > consistently. (Eg: bad hacks) > > I would argue that comparing hashes is the worst hack ever. Can you create a file once you set a password to indicate that password is set? Bottom line - I do not like the approach you are trying to implement and I do not want you to find a way to solve this problem by comparing hashes. It is not a good security hygiene. I would rather suggest patches to puppet to address the issue properly than aid you on this path. Sorry ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From npmccallum at redhat.com Mon May 12 23:39:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 12 May 2014 19:39:07 -0400 Subject: [Freeipa-devel] [WIP] OTP Token Import Message-ID: <1399937947.3005.13.camel@ipa.example.com> The attached patch implements the OTP Token import script. However, it doesn't work. Specifically, at the bottom of the file, when I call otptoken-add, I get: Unknown option: digits If I prefix "ipatoken" to "digits", I get: Unknown option: ipatokendigits If I remove "**options", I get: invalid 'ipatokenuniqueid': Gettext('must be Unicode text', domain='ipa', localedir=None) If I specify the id manually as u'foo', I get: no context.ldap2 in thread 'MainThread' What do I need to do in order to setup and call the otptoken-add command properly? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Import-script.patch Type: text/x-patch Size: 17655 bytes Desc: not available URL: From purpleidea at gmail.com Tue May 13 02:37:17 2014 From: purpleidea at gmail.com (James) Date: Mon, 12 May 2014 22:37:17 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <537149BF.80900@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> <1399932426.29751.15.camel@freed> <537149BF.80900@redhat.com> Message-ID: On Mon, May 12, 2014 at 6:22 PM, Dmitri Pal wrote: > On 05/12/2014 06:07 PM, James wrote: >> >> On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: >>> >>> Is there any other attribute to look at? >>> For example the timestamp when it was last set and base the update on >>> that rather than on matching password values? >>> >> There are some other solutions, but they are less elegant or don't work >> consistently. (Eg: bad hacks) >> >> > I would argue that comparing hashes is the worst hack ever. > Can you create a file once you set a password to indicate that password is > set? Not possible... > > Bottom line - I do not like the approach you are trying to implement and I > do not want you to find a way to solve this problem by comparing hashes. It > is not a good security hygiene. I would rather suggest patches to puppet to > address the issue properly than aid you on this path. I think you are missing the point... It is a bit subtle. Puppet is weird :) Here's what I'll do. I'll finish my other password related work, and then I'll post back with my complete feature branch minus the missing commands that I'm hoping to learn from the ML. I think you'll realize what I'm doing makes a lot of sense. I think you'll also soon agree that I have the only puppet module out there that is managing passwords responsibly. The status quo is that people are storing cleartext passwords _in puppet! tsk tsk. In any case, since when did a project stop it's users from shooting themselves in the foot if they thought that was right? Cheers, James > > Sorry ;-) From pviktori at redhat.com Tue May 13 10:54:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 May 2014 12:54:30 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <536A5C24.5070001@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> <5369E971.4020503@redhat.com> <536A3A0E.8010702@redhat.com> <1399477576.3786.17.camel@ipa.example.com> <536A5C24.5070001@redhat.com> Message-ID: <5371F9E6.5010805@redhat.com> On 05/07/2014 06:15 PM, Dmitri Pal wrote: > On 05/07/2014 11:46 AM, Nathaniel McCallum wrote: >> On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote: >>> On 05/07/2014 04:06 AM, Jan Cholasta wrote: >>>> On 6.5.2014 19:55, Nathaniel McCallum wrote: >>>>> I know it is a bit late on this, but for the OTP token import >>>>> script, I >>>>> have to have support for the full ISO 8601. My plan right now is to >>>>> use >>>>> python-dateutil for this. >>>>> >>>>> Using dateutil would simplify some of this code. Is there a reason we >>>>> aren't using dateutil? >>>> IIRC it was rejected right at the beginning as an overkill. AFAICS python-dateutil allows a lot of formats other than ISO 8601, including "5:50 A.M. on June 13, 1990" or even "09-25-2003". I'd rather stick to something well-defined, and fail hard on potentially ambiguous formats. I dont' see a guarantee that python-dateutil won't change the ad-hoc formats in the future. >>> What are the alternatives? >> Hand-coded date parsing, AFAICS. That is what we are currently doing. In >> order to make this sane, we greatly restrict the date formats permitted >> as input to a small subset of ISO 8601. This is possible because we just >> tell the users to type the date in one of the supported formats. One difference is that we allow using a space instead of 'T' for datetime values. The standard allows omitting the T by mutual agreement, and python-dateutil does support this. >> Unfortunately, I can't make that trade-off in the token import script >> since I have no control over the input. Since I have to support all of >> ISO 8601 (including timezone conversions), the dateutils module is >> pretty much the only option. If we adopt it for OTP import, we might as >> well throw away our hand-coded date parsing. I'm not a fan of the full ISO 8601 beast (sections 5.3-5.5 of RFC3339 sum it up nicely), but it's a standard; if we can convince python-dateutil to only parse ISO 8601 and generalized time, let's use it. >> Nathaniel >> >> > I would leave this till next week for Martin and Petr3 to chime in. > I do not have a problem but I am not sure I can assess all the > implications. -- Petr? From pviktori at redhat.com Tue May 13 11:00:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 May 2014 13:00:48 +0200 Subject: [Freeipa-devel] [PATCH 0003] freeipa-ci: Remove freeipa packages before distro-sync in build In-Reply-To: <536A2F9F.3030903@redhat.com> References: <536A2F9F.3030903@redhat.com> Message-ID: <5371FB60.8000207@redhat.com> On 05/07/2014 03:05 PM, Tomas Babej wrote: > Hi, > > this fixes the problem on builders, which do distro-sync while having > freeipa packages present from previous build run. > > This causes unnecessary downgrades., which may result into failures (as > now with the smartproxy pushed). I've put the 'freeipa-*' in quotes to prevent nasty surprises if there's a freeipa-* file around, and pushed. Commit e04ddf40c1b3e95c4601393bcca40ed55c1cf27b Pull from https://github.com/encukou/freeipa-ci -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ci-tbabej-0003+pviktori-Remove-freeipa-packages-before-distro-sync-in-build.patch Type: text/x-patch Size: 924 bytes Desc: not available URL: From mkosek at redhat.com Tue May 13 11:24:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 May 2014 13:24:47 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <5371F9E6.5010805@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> <5369E971.4020503@redhat.com> <536A3A0E.8010702@redhat.com> <1399477576.3786.17.camel@ipa.example.com> <536A5C24.5070001@redhat.com> <5371F9E6.5010805@redhat.com> Message-ID: <537200FF.5080305@redhat.com> On 05/13/2014 12:54 PM, Petr Viktorin wrote: > On 05/07/2014 06:15 PM, Dmitri Pal wrote: >> On 05/07/2014 11:46 AM, Nathaniel McCallum wrote: >>> On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote: >>>> On 05/07/2014 04:06 AM, Jan Cholasta wrote: >>>>> On 6.5.2014 19:55, Nathaniel McCallum wrote: >>>>>> I know it is a bit late on this, but for the OTP token import >>>>>> script, I >>>>>> have to have support for the full ISO 8601. My plan right now is to >>>>>> use >>>>>> python-dateutil for this. >>>>>> >>>>>> Using dateutil would simplify some of this code. Is there a reason we >>>>>> aren't using dateutil? >>>>> IIRC it was rejected right at the beginning as an overkill. > > AFAICS python-dateutil allows a lot of formats other than ISO 8601, including > "5:50 A.M. on June 13, 1990" or even "09-25-2003". I'd rather stick to > something well-defined, and fail hard on potentially ambiguous formats. I dont' > see a guarantee that python-dateutil won't change the ad-hoc formats in the > future. > >>>> What are the alternatives? >>> Hand-coded date parsing, AFAICS. That is what we are currently doing. In >>> order to make this sane, we greatly restrict the date formats permitted >>> as input to a small subset of ISO 8601. This is possible because we just >>> tell the users to type the date in one of the supported formats. > > One difference is that we allow using a space instead of 'T' for datetime > values. The standard allows omitting the T by mutual agreement, and > python-dateutil does support this. > >>> Unfortunately, I can't make that trade-off in the token import script >>> since I have no control over the input. Since I have to support all of >>> ISO 8601 (including timezone conversions), the dateutils module is >>> pretty much the only option. If we adopt it for OTP import, we might as >>> well throw away our hand-coded date parsing. > > I'm not a fan of the full ISO 8601 beast (sections 5.3-5.5 of RFC3339 sum it up > nicely), but it's a standard; if we can convince python-dateutil to only parse > ISO 8601 and generalized time, let's use it. Let me drop one heretic idea - what about having 2 parameters? GeneralDateTime with the general parsing (via dateutil) for OTP specific use case and then SimplifiedDateTime parameter for plugins that needs just basic date time? I.e. with manual parsing that Tomas already implemented and that was acked on our devel meeting? Martin From mkosek at redhat.com Tue May 13 11:41:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 May 2014 13:41:42 +0200 Subject: [Freeipa-devel] [PATCH] 1107 smartproxy cleanup In-Reply-To: <1399570698.2482.29.camel@ipa.example.com> References: <53694D4B.60700@redhat.com> <536A9748.5030909@redhat.com> <536B82B8.8030602@redhat.com> <1399567288.2482.28.camel@ipa.example.com> <536BC094.3080508@redhat.com> <1399570698.2482.29.camel@ipa.example.com> Message-ID: <537204F6.1040204@redhat.com> On 05/08/2014 07:38 PM, Nathaniel McCallum wrote: > On Thu, 2014-05-08 at 13:36 -0400, Rob Crittenden wrote: >> Nathaniel McCallum wrote: >>> On Thu, 2014-05-08 at 09:12 -0400, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Remove some unused files, fix an import which means we don't need to >>>>>> import from ipaserver, fix up Requires so it should work better running >>>>>> on a different box than the IPA server. >>>>> >>>>> Found and fixed a couple more minor issues. >>>> >>>> Fix one more issue. This sets the ipa client log to /dev/null to >>>> suppress the error >>>> >>>> ipa: ERROR: Could not create log_dir u'/var/www/.ipa/log' >>> >>> What is the purpose of sending the bootstrap logs for smartproxy >>> to /dev/null? >> >> It is all client logs. The smartproxy acts as an IPA client and clients >> log some things in ~/.ipa/log by default. We don't really want these >> logs in this case, it's logged anyway, and this suppresses the error by >> writing things to the bit bucket. >> >> The other way would be to add an option to not log but that seems like >> overkill. > > That is all that stood out to me. ACK > > Nathaniel Pushed to master: 74412dbf88f78b19a54c35e326e173f5344922d0 Martin From jcholast at redhat.com Tue May 13 12:06:38 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 May 2014 14:06:38 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <537200FF.5080305@redhat.com> References: <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> <536111B5.8040500@redhat.com> <20140505155826.GA20958@redhat.com> <1399398909.9864.19.camel@ipa.example.com> <5369E971.4020503@redhat.com> <536A3A0E.8010702@redhat.com> <1399477576.3786.17.camel@ipa.example.com> <536A5C24.5070001@redhat.com> <5371F9E6.5010805@redhat.com> <537200FF.5080305@redhat.com> Message-ID: <53720ACE.6010600@redhat.com> On 13.5.2014 13:24, Martin Kosek wrote: > On 05/13/2014 12:54 PM, Petr Viktorin wrote: >> On 05/07/2014 06:15 PM, Dmitri Pal wrote: >>> On 05/07/2014 11:46 AM, Nathaniel McCallum wrote: >>>> On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote: >>>>> On 05/07/2014 04:06 AM, Jan Cholasta wrote: >>>>>> On 6.5.2014 19:55, Nathaniel McCallum wrote: >>>>>>> I know it is a bit late on this, but for the OTP token import >>>>>>> script, I >>>>>>> have to have support for the full ISO 8601. My plan right now is to >>>>>>> use >>>>>>> python-dateutil for this. >>>>>>> >>>>>>> Using dateutil would simplify some of this code. Is there a reason we >>>>>>> aren't using dateutil? >>>>>> IIRC it was rejected right at the beginning as an overkill. >> >> AFAICS python-dateutil allows a lot of formats other than ISO 8601, including >> "5:50 A.M. on June 13, 1990" or even "09-25-2003". I'd rather stick to >> something well-defined, and fail hard on potentially ambiguous formats. I dont' >> see a guarantee that python-dateutil won't change the ad-hoc formats in the >> future. >> >>>>> What are the alternatives? >>>> Hand-coded date parsing, AFAICS. That is what we are currently doing. In >>>> order to make this sane, we greatly restrict the date formats permitted >>>> as input to a small subset of ISO 8601. This is possible because we just >>>> tell the users to type the date in one of the supported formats. >> >> One difference is that we allow using a space instead of 'T' for datetime >> values. The standard allows omitting the T by mutual agreement, and >> python-dateutil does support this. >> >>>> Unfortunately, I can't make that trade-off in the token import script >>>> since I have no control over the input. Since I have to support all of >>>> ISO 8601 (including timezone conversions), the dateutils module is >>>> pretty much the only option. If we adopt it for OTP import, we might as >>>> well throw away our hand-coded date parsing. >> >> I'm not a fan of the full ISO 8601 beast (sections 5.3-5.5 of RFC3339 sum it up >> nicely), but it's a standard; if we can convince python-dateutil to only parse >> ISO 8601 and generalized time, let's use it. > > Let me drop one heretic idea - what about having 2 parameters? > > GeneralDateTime with the general parsing (via dateutil) for OTP specific use > case and then SimplifiedDateTime parameter for plugins that needs just basic > date time? I.e. with manual parsing that Tomas already implemented and that was > acked on our devel meeting? I don't see why any of this should be supported at the API level. If you need to do some preprocessing, fine, but do it on the client side. -- Jan Cholasta From jcholast at redhat.com Tue May 13 13:13:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 May 2014 15:13:12 +0200 Subject: [Freeipa-devel] [WIP] OTP Token Import In-Reply-To: <1399937947.3005.13.camel@ipa.example.com> References: <1399937947.3005.13.camel@ipa.example.com> Message-ID: <53721A68.7060208@redhat.com> Hi, On 13.5.2014 01:39, Nathaniel McCallum wrote: > The attached patch implements the OTP Token import script. However, it > doesn't work. Specifically, at the bottom of the file, when I call > otptoken-add, I get: Unknown option: digits > > If I prefix "ipatoken" to "digits", I get: Unknown option: > ipatokendigits The attribute is called "ipatokenotpdigits", according to the otptoken plugin. > > If I remove "**options", I get: invalid 'ipatokenuniqueid': > Gettext('must be Unicode text', domain='ipa', localedir=None) I guess you are trying to use a str object for ipauniqueid. You must use a unicode object. > > If I specify the id manually as u'foo', I get: no context.ldap2 in > thread 'MainThread' You need to connect to LDAP with ldap2.connect before running any commands. > > What do I need to do in order to setup and call the otptoken-add command > properly? Is ipa-otptoken-import intended to be run on IPA servers only? Because I don't see anything in the code that would mandate that. Honza -- Jan Cholasta From npmccallum at redhat.com Tue May 13 13:20:54 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 13 May 2014 09:20:54 -0400 Subject: [Freeipa-devel] [WIP] OTP Token Import In-Reply-To: <53721A68.7060208@redhat.com> References: <1399937947.3005.13.camel@ipa.example.com> <53721A68.7060208@redhat.com> Message-ID: <1399987254.2512.5.camel@ipa.example.com> On Tue, 2014-05-13 at 15:13 +0200, Jan Cholasta wrote: > Hi, > > On 13.5.2014 01:39, Nathaniel McCallum wrote: > > The attached patch implements the OTP Token import script. However, it > > doesn't work. Specifically, at the bottom of the file, when I call > > otptoken-add, I get: Unknown option: digits > > > > If I prefix "ipatoken" to "digits", I get: Unknown option: > > ipatokendigits > > The attribute is called "ipatokenotpdigits", according to the otptoken > plugin. Gah! I've been looking at this code too long. > > If I remove "**options", I get: invalid 'ipatokenuniqueid': > > Gettext('must be Unicode text', domain='ipa', localedir=None) > > I guess you are trying to use a str object for ipauniqueid. You must use > a unicode object. Do I need to convert all the strings from the XML parsing to unicode? > > If I specify the id manually as u'foo', I get: no context.ldap2 in > > thread 'MainThread' > > You need to connect to LDAP with ldap2.connect before running any commands. Is there a canonical example of how to do this? > > What do I need to do in order to setup and call the otptoken-add command > > properly? > > Is ipa-otptoken-import intended to be run on IPA servers only? Because I > don't see anything in the code that would mandate that. No. However, this is part of a long conversation previously on this list. The parsing and otptoken_add needs to happen on the client-side because we will catch any failures and write out a client-side "tokens not added" xml file. We also need to do this because this process may take a long time (thousands of tokens) and the HTTP API doesn't have infrastructure for long-running calls. So the requirement here is that it runs on the client side with a direct LDAP connection. The bind user should be the user running the script, not directory manager. Nathaniel From jcholast at redhat.com Tue May 13 13:33:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 May 2014 15:33:10 +0200 Subject: [Freeipa-devel] [WIP] OTP Token Import In-Reply-To: <1399987254.2512.5.camel@ipa.example.com> References: <1399937947.3005.13.camel@ipa.example.com> <53721A68.7060208@redhat.com> <1399987254.2512.5.camel@ipa.example.com> Message-ID: <53721F16.4070205@redhat.com> On 13.5.2014 15:20, Nathaniel McCallum wrote: > On Tue, 2014-05-13 at 15:13 +0200, Jan Cholasta wrote: >> Hi, >> >> On 13.5.2014 01:39, Nathaniel McCallum wrote: >>> The attached patch implements the OTP Token import script. However, it >>> doesn't work. Specifically, at the bottom of the file, when I call >>> otptoken-add, I get: Unknown option: digits >>> >>> If I prefix "ipatoken" to "digits", I get: Unknown option: >>> ipatokendigits >> >> The attribute is called "ipatokenotpdigits", according to the otptoken >> plugin. > > Gah! I've been looking at this code too long. > >>> If I remove "**options", I get: invalid 'ipatokenuniqueid': >>> Gettext('must be Unicode text', domain='ipa', localedir=None) >> >> I guess you are trying to use a str object for ipauniqueid. You must use >> a unicode object. > > Do I need to convert all the strings from the XML parsing to unicode? You need to make sure that values of all Str params are all unicode. > >>> If I specify the id manually as u'foo', I get: no context.ldap2 in >>> thread 'MainThread' >> >> You need to connect to LDAP with ldap2.connect before running any commands. > > Is there a canonical example of how to do this? See CACertManage.ldap_connect in my patch 251.2. > >>> What do I need to do in order to setup and call the otptoken-add command >>> properly? >> >> Is ipa-otptoken-import intended to be run on IPA servers only? Because I >> don't see anything in the code that would mandate that. > > No. However, this is part of a long conversation previously on this > list. The parsing and otptoken_add needs to happen on the client-side > because we will catch any failures and write out a client-side "tokens > not added" xml file. We also need to do this because this process may > take a long time (thousands of tokens) and the HTTP API doesn't have > infrastructure for long-running calls. > > So the requirement here is that it runs on the client side with a direct > LDAP connection. The bind user should be the user running the script, > not directory manager. OK, thanks for clarification. > > Nathaniel > -- Jan Cholasta From pviktori at redhat.com Tue May 13 13:55:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 May 2014 15:55:07 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: References: Message-ID: <5372243B.8000401@redhat.com> On 05/09/2014 04:14 AM, Gabe Alford wrote: > Hello, > > Just wondering if there are any takers in reviewing this patch. Sorry, looks like it fell through the cracks :( AFAIK the &OS; entity should work for both Fedora and RHEL, so it should be possible to only have one copy of the paragraph. Or is there something I missed? > > Gabe > > > > On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford > wrote: > > Hello, > > Patch for the following ticket to add note in documentation about > bad uid ranges: > https://fedorahosted.org/freeipa/ticket/2090 > > Thanks, > > Gabe > -- Petr? From jcholast at redhat.com Tue May 13 14:33:25 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 May 2014 16:33:25 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1399921364.3005.9.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> Message-ID: <53722D35.1060901@redhat.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; >>> acl "Users can create and delete tokens"; allow (add, delete) userattr = >>> "ipatokenOwner#SELFDN";) >>> >>> This is what they look like using managedBy (I have not tested this): >>> >>> 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"; allow (read, search, compare) >>> userattr = "managedBy#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"; allow >>> (read, search, compare) userattr = "managedBy#USERDN";) >>> >>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>> see HOTP details"; allow (read, search, compare) userattr = >>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>> "managedBy#USERDN";) >>> >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>> "description || ipatokenDisabled || ipatokenNotBefore || >>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; >>> allow (write) userattr = "managedBy#USERDN";) >>> >>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>> "Managers can delete tokens"; allow (delete) userattr = >>> "managedBy#USERDN";) >>> >>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>> userattr = "managedBy#SELFDN";) >>> >>> In short: >>> 1. Owner and manager get read, search and compare. >>> 2. Manager gets write (to select attributes) and delete. >>> 3. Users can create self-managed tokens for themselves only. >>> >>> The otptoken-add command should gain the following defaults: >>> 1. The owner defaults to the user adding the token. >>> 2. If owner == user adding token, managedBy defaults to owner. >>> 3. Otherwise, managedBy defaults to None. >>> >>> This means that if neither owner nor managedBy are specified, the >>> default is a self-owned, self-managed token. Likewise, if a different >>> owner is specified, no manager is assumed. >>> >>> rcrit expresses worry that ipalib's ACI parser may not handle the above >>> syntax. This will become clear during testing if we want this approach. >>> >>> Does this look sane? >> >> I am not entirely sure your ACI syntax is always right for the second >> set. and perhaps we want to duplicate ACIs in some cases (once for owner >> once for manager). >> >> I think the read ACIs do not need to list managedby ? Do we plan to have >> a manager that is another regular user but not the owner nor an admin ? >> >> In any case I prefer the sytnax that uses managedby, as it has more >> potential. > > Attached is a new version of the patch which implements the feature > using managedBy instead of ipatokenProtected. One important thing needs > to be said about this patch. I am not exposing managedBy in either the > UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I > expose this similar to owner or as a relationship? I would expose it, as a relationship. (Note that ipatokenowner should ideally be represented as a relationship too, but the framework does not support 1-to-many relationships ATM.) Just curious, why are the ACIs divided like this: aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || description || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP details"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users/managers can see HOTP details"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) IMHO you could make them less complex by dividing them like this: aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || description || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can read token details"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || description || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers can read token details"; allow (read, search, compare) userattr = "managedBy#USERDN";) Would it make sense to keep --protected as a flag in otptoken-add as a shortcut for "entry_attrs['managedby'] = None"? Would it make sense to default managedby to the current bind DN in otptoken-add, even if it's not a user DN? (Do we want to allow running otptoken-add by hosts/services/other non-users?) Is orphaning a token when a user is deleted only if it is not managed by any other users the intended behavior? It just seems sort of strange to me, since it changes the token from unprotected to protected. -- Jan Cholasta From dpal at redhat.com Tue May 13 14:36:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 May 2014 10:36:28 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> <1399932426.29751.15.camel@freed> <537149BF.80900@redhat.com> Message-ID: <53722DEC.3010101@redhat.com> On 05/12/2014 10:37 PM, James wrote: > On Mon, May 12, 2014 at 6:22 PM, Dmitri Pal wrote: >> On 05/12/2014 06:07 PM, James wrote: >>> On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: >>>> Is there any other attribute to look at? >>>> For example the timestamp when it was last set and base the update on >>>> that rather than on matching password values? >>>> >>> There are some other solutions, but they are less elegant or don't work >>> consistently. (Eg: bad hacks) >>> >>> >> I would argue that comparing hashes is the worst hack ever. >> Can you create a file once you set a password to indicate that password is >> set? > Not possible... > >> Bottom line - I do not like the approach you are trying to implement and I >> do not want you to find a way to solve this problem by comparing hashes. It >> is not a good security hygiene. I would rather suggest patches to puppet to >> address the issue properly than aid you on this path. > I think you are missing the point... It is a bit subtle. Puppet is > weird :) Here's what I'll do. I'll finish my other password related > work, and then I'll post back with my complete feature branch minus > the missing commands that I'm hoping to learn from the ML. > > I think you'll realize what I'm doing makes a lot of sense. I think > you'll also soon agree that I have the only puppet module out there > that is managing passwords responsibly. The status quo is that people > are storing cleartext passwords _in puppet! This is their problem. Why would we aid them to do wrong things and make it easier? I really miss the point. Why it is all needed? Why do you need to reset passwords in IPA through puppet? What is the use case? > tsk tsk. In any case, > since when did a project stop it's users from shooting themselves in > the foot if they thought that was right? > > Cheers, > James > > > >> Sorry ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jcholast at redhat.com Tue May 13 14:47:08 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 May 2014 16:47:08 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1399920643.3005.0.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> Message-ID: <5372306C.4040408@redhat.com> On 12.5.2014 20:50, Nathaniel McCallum wrote: > On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: >> On Tue, 06 May 2014 11:46:14 -0400 >> Nathaniel McCallum wrote: >> >>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: >>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: >>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: >>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: >>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: >>>>>>>> Specifying the default in the LDAP Object causes the >>>>>>>> parameter to be specified for non-add operations. This is >>>>>>>> especially problematic when performing the modify operation >>>>>>>> as it causes the primary key to change for every modification. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 >>>>>>>> >>>>>>> >>>>>>> shouldn't removal of `autofill=True,` be enough? >>>>>> >>>>>> Removing autofill=True results in the default not being used >>>>>> for the otptoken-add operation. That may be a different bug >>>>>> (I'm not sure what the expectation of autofill is). >>>>>> >>>>>> Nathaniel >>>>>> >>>>> >>>>> Seems to work form me with: >>>>> >>>>> diff --git a/ipalib/plugins/otptoken.py >>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 >>>>> --- a/ipalib/plugins/otptoken.py >>>>> +++ b/ipalib/plugins/otptoken.py >>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): >>>>> cli_name='id', >>>>> label=_('Unique ID'), >>>>> default_from=lambda: unicode(uuid.uuid4()), >>>>> - autofill=True, >>>>> primary_key=True, >>>>> - flags=('optional_create'), >>>>> ), >>>>> StrEnum('type?', >>>>> label=_('Type'), >>>> >>>> Doing this causes the ipa otptoken-add command to prompt for the >>>> Unique ID. This may be the desired behavior, but it is not how it >>>> worked previously (no prompt). >>> >>> Here is an alternate patch for this second approach. I have no strong >>> opinion on the correct behavior here. >>> >>> Nathaniel >> >> IMO you should update API.txt with ./makeapi > > Running ./makeapi results in no changes to API.txt. This is not right, there *are* changes in the API and build fails for me becase API.txt is not updated. -- Jan Cholasta From dpal at redhat.com Tue May 13 14:40:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 May 2014 10:40:12 -0400 Subject: [Freeipa-devel] [WIP] OTP Token Import In-Reply-To: <53721F16.4070205@redhat.com> References: <1399937947.3005.13.camel@ipa.example.com> <53721A68.7060208@redhat.com> <1399987254.2512.5.camel@ipa.example.com> <53721F16.4070205@redhat.com> Message-ID: <53722ECC.3040108@redhat.com> On 05/13/2014 09:33 AM, Jan Cholasta wrote: > On 13.5.2014 15:20, Nathaniel McCallum wrote: >> On Tue, 2014-05-13 at 15:13 +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 13.5.2014 01:39, Nathaniel McCallum wrote: >>>> The attached patch implements the OTP Token import script. However, it >>>> doesn't work. Specifically, at the bottom of the file, when I call >>>> otptoken-add, I get: Unknown option: digits >>>> >>>> If I prefix "ipatoken" to "digits", I get: Unknown option: >>>> ipatokendigits >>> >>> The attribute is called "ipatokenotpdigits", according to the otptoken >>> plugin. >> >> Gah! I've been looking at this code too long. >> >>>> If I remove "**options", I get: invalid 'ipatokenuniqueid': >>>> Gettext('must be Unicode text', domain='ipa', localedir=None) >>> >>> I guess you are trying to use a str object for ipauniqueid. You must >>> use >>> a unicode object. >> >> Do I need to convert all the strings from the XML parsing to unicode? > > You need to make sure that values of all Str params are all unicode. > >> >>>> If I specify the id manually as u'foo', I get: no context.ldap2 in >>>> thread 'MainThread' >>> >>> You need to connect to LDAP with ldap2.connect before running any >>> commands. >> >> Is there a canonical example of how to do this? > > See CACertManage.ldap_connect in my patch 251.2. > >> >>>> What do I need to do in order to setup and call the otptoken-add >>>> command >>>> properly? >>> >>> Is ipa-otptoken-import intended to be run on IPA servers only? >>> Because I >>> don't see anything in the code that would mandate that. >> >> No. However, this is part of a long conversation previously on this >> list. The parsing and otptoken_add needs to happen on the client-side >> because we will catch any failures and write out a client-side "tokens >> not added" xml file. We also need to do this because this process may >> take a long time (thousands of tokens) and the HTTP API doesn't have >> infrastructure for long-running calls. >> >> So the requirement here is that it runs on the client side with a direct >> LDAP connection. The bind user should be the user running the script, >> not directory manager. > > OK, thanks for clarification. Do not forget to document this part. > >> >> Nathaniel >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From purpleidea at gmail.com Tue May 13 15:46:34 2014 From: purpleidea at gmail.com (James) Date: Tue, 13 May 2014 11:46:34 -0400 Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <53722DEC.3010101@redhat.com> References: <1399829259.12254.64.camel@freed> <536FC9A0.30507@redhat.com> <53701D96.5020909@redhat.com> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> <1399932426.29751.15.camel@freed> <537149BF.80900@redhat.com> <53722DEC.3010101@redhat.com> Message-ID: On Tue, May 13, 2014 at 10:36 AM, Dmitri Pal wrote: > This is their problem. Why would we aid them to do wrong things and make it > easier? > I really miss the point. Why it is all needed? > Why do you need to reset passwords in IPA through puppet? > What is the use case? Give me about a week and I'll post some finished code :) From npmccallum at redhat.com Tue May 13 16:38:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 13 May 2014 12:38:45 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing Message-ID: <1399999125.2512.9.camel@ipa.example.com> This patch adds support for importing tokens using RFC 6030 key container files. This includes decryption support. For sysadmin sanity, any tokens which fail to add will be written to the output file for examination. The main use case here is where a small subset of a large set of tokens fails to validate or add. Using the output file, the sysadmin can attempt to recover these specific tokens. This code is implemented as a server-side script. However, it doesn't actually need to run on the server. This was done because importing is an odd fit for the IPA command framework: 1. We need to write an output file. 2. The operation may be long-running (thousands of tokens). 3. Only admins need to perform this task and it only happens infrequently. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0053-Implement-OTP-token-importing.patch Type: text/x-patch Size: 20517 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 13 16:40:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 13 May 2014 12:40:26 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1399999125.2512.9.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> Message-ID: <1399999226.2512.10.camel@ipa.example.com> On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: > This patch adds support for importing tokens using RFC 6030 key > container files. This includes decryption support. For sysadmin sanity, > any tokens which fail to add will be written to the output file for > examination. The main use case here is where a small subset of a large > set of tokens fails to validate or add. Using the output file, the > sysadmin can attempt to recover these specific tokens. > > This code is implemented as a server-side script. However, it doesn't > actually need to run on the server. This was done because importing is > an odd fit for the IPA command framework: > 1. We need to write an output file. > 2. The operation may be long-running (thousands of tokens). > 3. Only admins need to perform this task and it only happens > infrequently. I forgot to put the link to the ticket in the commit message. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0053-Implement-OTP-token-importing.patch Type: text/x-patch Size: 20563 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 13 16:55:19 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 13 May 2014 12:55:19 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <5372306C.4040408@redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> Message-ID: <1400000119.2512.11.camel@ipa.example.com> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: > On 12.5.2014 20:50, Nathaniel McCallum wrote: > > On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: > >> On Tue, 06 May 2014 11:46:14 -0400 > >> Nathaniel McCallum wrote: > >> > >>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > >>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > >>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: > >>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > >>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: > >>>>>>>> Specifying the default in the LDAP Object causes the > >>>>>>>> parameter to be specified for non-add operations. This is > >>>>>>>> especially problematic when performing the modify operation > >>>>>>>> as it causes the primary key to change for every modification. > >>>>>>>> > >>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 > >>>>>>>> > >>>>>>> > >>>>>>> shouldn't removal of `autofill=True,` be enough? > >>>>>> > >>>>>> Removing autofill=True results in the default not being used > >>>>>> for the otptoken-add operation. That may be a different bug > >>>>>> (I'm not sure what the expectation of autofill is). > >>>>>> > >>>>>> Nathaniel > >>>>>> > >>>>> > >>>>> Seems to work form me with: > >>>>> > >>>>> diff --git a/ipalib/plugins/otptoken.py > >>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > >>>>> --- a/ipalib/plugins/otptoken.py > >>>>> +++ b/ipalib/plugins/otptoken.py > >>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > >>>>> cli_name='id', > >>>>> label=_('Unique ID'), > >>>>> default_from=lambda: unicode(uuid.uuid4()), > >>>>> - autofill=True, > >>>>> primary_key=True, > >>>>> - flags=('optional_create'), > >>>>> ), > >>>>> StrEnum('type?', > >>>>> label=_('Type'), > >>>> > >>>> Doing this causes the ipa otptoken-add command to prompt for the > >>>> Unique ID. This may be the desired behavior, but it is not how it > >>>> worked previously (no prompt). > >>> > >>> Here is an alternate patch for this second approach. I have no strong > >>> opinion on the correct behavior here. > >>> > >>> Nathaniel > >> > >> IMO you should update API.txt with ./makeapi > > > > Running ./makeapi results in no changes to API.txt. > > This is not right, there *are* changes in the API and build fails for me > becase API.txt is not updated. I think maybe I ran it from the wrong branch. Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0052a.1-Only-use-the-ipatokenuniqueid-default-in-the-add-ope.patch Type: text/x-patch Size: 5273 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 13 17:12:48 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 13 May 2014 13:12:48 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <53722D35.1060901@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> Message-ID: <1400001168.2512.20.camel@ipa.example.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; > >>> acl "Users can create and delete tokens"; allow (add, delete) userattr = > >>> "ipatokenOwner#SELFDN";) > >>> > >>> This is what they look like using managedBy (I have not tested this): > >>> > >>> 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"; allow (read, search, compare) > >>> userattr = "managedBy#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"; allow > >>> (read, search, compare) userattr = "managedBy#USERDN";) > >>> > >>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > >>> see HOTP details"; allow (read, search, compare) userattr = > >>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > >>> "managedBy#USERDN";) > >>> > >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>> "description || ipatokenDisabled || ipatokenNotBefore || > >>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > >>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; > >>> allow (write) userattr = "managedBy#USERDN";) > >>> > >>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >>> "Managers can delete tokens"; allow (delete) userattr = > >>> "managedBy#USERDN";) > >>> > >>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > >>> userattr = "managedBy#SELFDN";) > >>> > >>> In short: > >>> 1. Owner and manager get read, search and compare. > >>> 2. Manager gets write (to select attributes) and delete. > >>> 3. Users can create self-managed tokens for themselves only. > >>> > >>> The otptoken-add command should gain the following defaults: > >>> 1. The owner defaults to the user adding the token. > >>> 2. If owner == user adding token, managedBy defaults to owner. > >>> 3. Otherwise, managedBy defaults to None. > >>> > >>> This means that if neither owner nor managedBy are specified, the > >>> default is a self-owned, self-managed token. Likewise, if a different > >>> owner is specified, no manager is assumed. > >>> > >>> rcrit expresses worry that ipalib's ACI parser may not handle the above > >>> syntax. This will become clear during testing if we want this approach. > >>> > >>> Does this look sane? > >> > >> I am not entirely sure your ACI syntax is always right for the second > >> set. and perhaps we want to duplicate ACIs in some cases (once for owner > >> once for manager). > >> > >> I think the read ACIs do not need to list managedby ? Do we plan to have > >> a manager that is another regular user but not the owner nor an admin ? > >> > >> In any case I prefer the sytnax that uses managedby, as it has more > >> potential. > > > > Attached is a new version of the patch which implements the feature > > using managedBy instead of ipatokenProtected. One important thing needs > > to be said about this patch. I am not exposing managedBy in either the > > UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I > > expose this similar to owner or as a relationship? > > I would expose it, as a relationship. (Note that ipatokenowner should > ideally be represented as a relationship too, but the framework does not > support 1-to-many relationships ATM.) So since this is a 1-to-many relationship we shouldn't expose it? Or should I do it like owner is currently done? > > Just curious, why are the ACIs divided like this: > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers > can read basic token info"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > "ipatokenOTPalgorithm || ipatokenOTPdigits || > ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP > details"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > "Users/managers can see HOTP details"; allow (read, search, compare) > userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > IMHO you could make them less complex by dividing them like this: > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || > ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can > read token details"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN";) > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || > ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers > can read token details"; allow (read, search, compare) userattr = > "managedBy#USERDN";) The first set is organized by objectClass. The second by userattr. I have no strong opinion on this matter, though performance is probably a consideration. Do any DS guys want to chime in? > Would it make sense to keep --protected as a flag in otptoken-add as a > shortcut for "entry_attrs['managedby'] = None"? I can't think of a use case for this. The only use case I *can* think of is an admin creating a non-protected token for a user. > Would it make sense to default managedby to the current bind DN in > otptoken-add, even if it's not a user DN? (Do we want to allow running > otptoken-add by hosts/services/other non-users?) No idea. Dmitri? > Is orphaning a token when a user is deleted only if it is not managed by > any other users the intended behavior? It just seems sort of strange to > me, since it changes the token from unprotected to protected. I don't think that is the behavior. We orphan the token if the owner is not listed as a manager. If the owner is listed as a manager, we delete the token. Put another way, protected tokens are orphaned and unprotected tokens are deleted. If I didn't implement that, please point out my bug. Nathaniel From ssorce at redhat.com Tue May 13 19:47:30 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 May 2014 15:47:30 -0400 (EDT) Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: <1399932426.29751.15.camel@freed> References: <1399829259.12254.64.camel@freed> <53707407.9090506@redhat.com> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> <1399932426.29751.15.camel@freed> Message-ID: <1866700509.4810076.1400010450302.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: > > Is there any other attribute to look at? > > For example the timestamp when it was last set and base the update on > > that rather than on matching password values? > > > There are some other solutions, but they are less elegant or don't work > consistently. (Eg: bad hacks) Reading userPassword is a bad hack, that will stop working as soon as we decide to change the default hash type. Do yourself a favor, use a simple bind to check the user password. If the bind succedes you have the right password, and you stop. If it fails you just override the password with whatever you have in puppet. Simo. -- Simo Sorce * Red Hat, Inc. * New York From ssorce at redhat.com Tue May 13 19:51:22 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 May 2014 15:51:22 -0400 (EDT) Subject: [Freeipa-devel] Consistent password hashing and lookups In-Reply-To: References: <1399829259.12254.64.camel@freed> <20140512074321.GA20883@redhat.com> <53712E23.2010404@redhat.com> <1399926502.29751.11.camel@freed> <53714375.6020605@redhat.com> <1399932426.29751.15.camel@freed> <537149BF.80900@redhat.com> Message-ID: <1008626973.4811676.1400010682831.JavaMail.zimbra@redhat.com> b----- Original Message ----- > On Mon, May 12, 2014 at 6:22 PM, Dmitri Pal wrote: > > On 05/12/2014 06:07 PM, James wrote: > >> > >> On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: > >>> > >>> Is there any other attribute to look at? > >>> For example the timestamp when it was last set and base the update on > >>> that rather than on matching password values? > >>> > >> There are some other solutions, but they are less elegant or don't work > >> consistently. (Eg: bad hacks) > >> > >> > > I would argue that comparing hashes is the worst hack ever. > > Can you create a file once you set a password to indicate that password is > > set? > Not possible... > > > > > Bottom line - I do not like the approach you are trying to implement and I > > do not want you to find a way to solve this problem by comparing hashes. It > > is not a good security hygiene. I would rather suggest patches to puppet to > > address the issue properly than aid you on this path. > > I think you are missing the point... It is a bit subtle. Puppet is > weird :) Here's what I'll do. I'll finish my other password related > work, and then I'll post back with my complete feature branch minus > the missing commands that I'm hoping to learn from the ML. > > I think you'll realize what I'm doing makes a lot of sense. I think > you'll also soon agree that I have the only puppet module out there > that is managing passwords responsibly. The status quo is that people > are storing cleartext passwords _in puppet! tsk tsk. In any case, > since when did a project stop it's users from shooting themselves in > the foot if they thought that was right? It is completely unclear to me how you plan to change a password without having the clear text (or equivalent) password. If what you are planning to do is to just write the alreay hashed password in userPassword, it will not work. To add to that, I do not understand why you would do password mangement via puppet, you do not nee dto change local files, FreeIPA is a networked server and you can change passwords over the network already, why would you want to distribute them via puppet ?? Simo. -- Simo Sorce * Red Hat, Inc. * New York From redhatrises at gmail.com Tue May 13 23:05:25 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 13 May 2014 17:05:25 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: <5372243B.8000401@redhat.com> References: <5372243B.8000401@redhat.com> Message-ID: I had a typo with the one of the UIDs which is fixed with this patch. The difference is that Fedora/SSSD treats UIDs of 1000 and below as local system accounts whereas RHEL treats local system accounts at 500 and SSSD local system accounts at 1000. That's why there are conditional paragraphs based on if it is Fedora or RHEL. On Tue, May 13, 2014 at 7:55 AM, Petr Viktorin wrote: > On 05/09/2014 04:14 AM, Gabe Alford wrote: > >> Hello, >> >> Just wondering if there are any takers in reviewing this patch. >> > > Sorry, looks like it fell through the cracks :( > > AFAIK the &OS; entity should work for both Fedora and RHEL, so it should > be possible to only have one copy of the paragraph. Or is there something I > missed? > > >> Gabe >> >> >> >> On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford > > wrote: >> >> Hello, >> >> Patch for the following ticket to add note in documentation about >> bad uid ranges: >> https://fedorahosted.org/freeipa/ticket/2090 >> >> Thanks, >> >> Gabe >> >> > > -- > Petr? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0016-2-DOC-Sometimes-users-set-bad-uid-ranges.patch Type: text/x-patch Size: 2116 bytes Desc: not available URL: From pspacek at redhat.com Wed May 14 08:32:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 14 May 2014 10:32:06 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: References: <5372243B.8000401@redhat.com> Message-ID: <53732A06.2090500@redhat.com> On 14.5.2014 01:05, Gabe Alford wrote: > I had a typo with the one of the UIDs which is fixed with this patch. > > The difference is that Fedora/SSSD treats UIDs of 1000 and below as local > system accounts whereas RHEL treats local system accounts at 500 and SSSD > local system accounts at 1000. That's why there are conditional paragraphs > based on if it is Fedora or RHEL. I think we should define entity (similar to &OS) for this purpose. Please look at FreeIPA_Guide.ent and Identity_Management_Guide.ent. Petr^2 Spacek > On Tue, May 13, 2014 at 7:55 AM, Petr Viktorin wrote: > >> On 05/09/2014 04:14 AM, Gabe Alford wrote: >> >>> Hello, >>> >>> Just wondering if there are any takers in reviewing this patch. >>> >> >> Sorry, looks like it fell through the cracks :( >> >> AFAIK the &OS; entity should work for both Fedora and RHEL, so it should >> be possible to only have one copy of the paragraph. Or is there something I >> missed? >> >> >>> Gabe >>> >>> >>> >>> On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford >> > wrote: >>> >>> Hello, >>> >>> Patch for the following ticket to add note in documentation about >>> bad uid ranges: >>> https://fedorahosted.org/freeipa/ticket/2090 >>> >>> Thanks, >>> >>> Gabe From tbordaz at redhat.com Wed May 14 09:21:17 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 14 May 2014 11:21:17 +0200 Subject: [Freeipa-devel] Asking for help to add new options Message-ID: <5373358D.90301@redhat.com> Hello, Quite beginner in freeipa land, I am trying to add options to 'user-add' sub-command but desperately failing to make it work. I did the following modification: diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 9b21200..0c36e35 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -365,6 +365,20 @@ class user(LDAPObject): csv=True, flags=['no_search'], ), + Flag('tostage?', + doc=_('Create user in staging container'), + flags=('no_search', 'virtual_attribute'), + cli_name='to_stage', + default=False, + ), + Str('uidstaged?', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='from_staged', + label=_('Activate the User currently in the staging container'), + normalizer=lambda value: value.lower(), + ), ) def _normalize_and_validate_email(self, email, config=None): @@ -436,12 +450,16 @@ class user_add(LDAPCreate): msg_summary = _('Added user "%(value)s"') has_output_params = LDAPCreate.has_output_params + user_output_params + + #internal_options = ['tostage', 'uidstaged'] takes_options = LDAPCreate.takes_options + ( Flag('noprivate', cli_name='noprivate', doc=_('Don\'t create user private group'), ), + + ) The command 'ipa user-add --help' succeeds giving me the correct help message. But when I try to add the user it fails: ipa user-add foo --to-stage --first=foo --last=foo ipa: ERROR: Unknown option: tostage This seems to occur because the frontend find this is a 'remaining' option.. but what does it means ? I tried to add the new options as internal options, or with different names, but it gives the same results. I know it is a very novice question, but I have really no idea I should fix it. Anyone know what I am missing ? regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed May 14 09:49:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 May 2014 11:49:51 +0200 Subject: [Freeipa-devel] [PATCH 0018] ipa-client-automount should not configure nsswitch.conf In-Reply-To: References: Message-ID: <53733C3F.90806@redhat.com> On 05/09/2014 05:09 AM, Gabe Alford wrote: > Hello, > > Came across this issue in my environment the other day and > thought I would send a quick patch for review for > https://fedorahosted.org/freeipa/ticket/3733 Thanks for the patch! This works, but configure_nsswitch would now fail if it was called options.sssd=True, as nss_value won't be set. Please remove the if entirely, and perhaps mention in the function's docstring/name that it's for non-SSSD setups only. -- Petr? From pviktori at redhat.com Wed May 14 10:01:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 May 2014 12:01:42 +0200 Subject: [Freeipa-devel] Asking for help to add new options In-Reply-To: <5373358D.90301@redhat.com> References: <5373358D.90301@redhat.com> Message-ID: <53733F06.3070101@redhat.com> On 05/14/2014 11:21 AM, thierry bordaz wrote: > Hello, > > Quite beginner in freeipa land, I am trying to add options to > 'user-add' sub-command but desperately failing to make it work. > I did the following modification: > > diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py > index 9b21200..0c36e35 100644 > --- a/ipalib/plugins/user.py > +++ b/ipalib/plugins/user.py > @@ -365,6 +365,20 @@ class user(LDAPObject): > csv=True, > flags=['no_search'], > ), > + Flag('tostage?', > + doc=_('Create user in staging container'), > + flags=('no_search', 'virtual_attribute'), > + cli_name='to_stage', > + default=False, > + ), > + Str('uidstaged?', > + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', > + pattern_errmsg='may only include letters, numbers, > _, -, . and $', > + maxlength=255, > + cli_name='from_staged', > + label=_('Activate the User currently in the staging > container'), > + normalizer=lambda value: value.lower(), > + ), > ) > > def _normalize_and_validate_email(self, email, config=None): > @@ -436,12 +450,16 @@ class user_add(LDAPCreate): > msg_summary = _('Added user "%(value)s"') > > has_output_params = LDAPCreate.has_output_params + > user_output_params > + > + #internal_options = ['tostage', 'uidstaged'] > > takes_options = LDAPCreate.takes_options + ( > Flag('noprivate', > cli_name='noprivate', > doc=_('Don\'t create user private group'), > ), > + > + > ) > > > The command 'ipa user-add --help' succeeds giving me the correct > help message. But when I try to add the user it fails: > > ipa user-add foo --to-stage --first=foo --last=foo > ipa: ERROR: Unknown option: tostage > > > This seems to occur because the frontend find this is a 'remaining' > option.. but what does it means ? > I tried to add the new options as internal options, or with > different names, but it gives the same results. > I know it is a very novice question, but I have really no idea I > should fix it. Anyone know what I am missing ? > > regards > thierry Hi, Adding these options works for me; I think the most likely reason is you're still using the old version. Did you install the changed file properly? If you're just copying the .py file to /usr/lib, remember to restart Apache. -- Petr? From tbordaz at redhat.com Wed May 14 10:27:16 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 14 May 2014 12:27:16 +0200 Subject: [Freeipa-devel] Asking for help to add new options In-Reply-To: <53733F06.3070101@redhat.com> References: <5373358D.90301@redhat.com> <53733F06.3070101@redhat.com> Message-ID: <53734504.7040409@redhat.com> On 05/14/2014 12:01 PM, Petr Viktorin wrote: > On 05/14/2014 11:21 AM, thierry bordaz wrote: >> Hello, >> >> Quite beginner in freeipa land, I am trying to add options to >> 'user-add' sub-command but desperately failing to make it work. >> I did the following modification: >> >> diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py >> index 9b21200..0c36e35 100644 >> --- a/ipalib/plugins/user.py >> +++ b/ipalib/plugins/user.py >> @@ -365,6 +365,20 @@ class user(LDAPObject): >> csv=True, >> flags=['no_search'], >> ), >> + Flag('tostage?', >> + doc=_('Create user in staging container'), >> + flags=('no_search', 'virtual_attribute'), >> + cli_name='to_stage', >> + default=False, >> + ), >> + Str('uidstaged?', >> + >> pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', >> + pattern_errmsg='may only include letters, numbers, >> _, -, . and $', >> + maxlength=255, >> + cli_name='from_staged', >> + label=_('Activate the User currently in the staging >> container'), >> + normalizer=lambda value: value.lower(), >> + ), >> ) >> >> def _normalize_and_validate_email(self, email, >> config=None): >> @@ -436,12 +450,16 @@ class user_add(LDAPCreate): >> msg_summary = _('Added user "%(value)s"') >> >> has_output_params = LDAPCreate.has_output_params + >> user_output_params >> + >> + #internal_options = ['tostage', 'uidstaged'] >> >> takes_options = LDAPCreate.takes_options + ( >> Flag('noprivate', >> cli_name='noprivate', >> doc=_('Don\'t create user private group'), >> ), >> + >> + >> ) >> >> >> The command 'ipa user-add --help' succeeds giving me the correct >> help message. But when I try to add the user it fails: >> >> ipa user-add foo --to-stage --first=foo --last=foo >> ipa: ERROR: Unknown option: tostage >> >> >> This seems to occur because the frontend find this is a 'remaining' >> option.. but what does it means ? >> I tried to add the new options as internal options, or with >> different names, but it gives the same results. >> I know it is a very novice question, but I have really no idea I >> should fix it. Anyone know what I am missing ? >> >> regards >> thierry > > Hi, > Adding these options works for me; I think the most likely reason is > you're still using the old version. Did you install the changed file > properly? If you're just copying the .py file to /usr/lib, remember to > restart Apache. > Hi Petr, Thanks for the info. I am using the cli, not the web interface and I installed just copying user.py to /usr/lib/python2.7/site-packages/ipalib/plugins/user.py. I believe I am using the new version as the '--help' option shows the new added options '--to-stage' and '--from-stage'. Did you succeed to add a user with something like: ipa user-add foo --to-stage --first=foo --last=foo ? may be something bad with my deployment I am using freeipa 3.3. Did you test on master ? regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed May 14 10:32:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 May 2014 12:32:09 +0200 Subject: [Freeipa-devel] Asking for help to add new options In-Reply-To: <53734504.7040409@redhat.com> References: <5373358D.90301@redhat.com> <53733F06.3070101@redhat.com> <53734504.7040409@redhat.com> Message-ID: <53734629.4080102@redhat.com> On 05/14/2014 12:27 PM, thierry bordaz wrote: > On 05/14/2014 12:01 PM, Petr Viktorin wrote: >> On 05/14/2014 11:21 AM, thierry bordaz wrote: >>> Hello, >>> >>> Quite beginner in freeipa land, I am trying to add options to >>> 'user-add' sub-command but desperately failing to make it work. >>> I did the following modification: >>> >>> diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py >>> index 9b21200..0c36e35 100644 >>> --- a/ipalib/plugins/user.py >>> +++ b/ipalib/plugins/user.py >>> @@ -365,6 +365,20 @@ class user(LDAPObject): >>> csv=True, >>> flags=['no_search'], >>> ), >>> + Flag('tostage?', >>> + doc=_('Create user in staging container'), >>> + flags=('no_search', 'virtual_attribute'), >>> + cli_name='to_stage', >>> + default=False, >>> + ), >>> + Str('uidstaged?', >>> + >>> pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', >>> + pattern_errmsg='may only include letters, numbers, >>> _, -, . and $', >>> + maxlength=255, >>> + cli_name='from_staged', >>> + label=_('Activate the User currently in the staging >>> container'), >>> + normalizer=lambda value: value.lower(), >>> + ), >>> ) >>> >>> def _normalize_and_validate_email(self, email, >>> config=None): >>> @@ -436,12 +450,16 @@ class user_add(LDAPCreate): >>> msg_summary = _('Added user "%(value)s"') >>> >>> has_output_params = LDAPCreate.has_output_params + >>> user_output_params >>> + >>> + #internal_options = ['tostage', 'uidstaged'] >>> >>> takes_options = LDAPCreate.takes_options + ( >>> Flag('noprivate', >>> cli_name='noprivate', >>> doc=_('Don\'t create user private group'), >>> ), >>> + >>> + >>> ) >>> >>> >>> The command 'ipa user-add --help' succeeds giving me the correct >>> help message. But when I try to add the user it fails: >>> >>> ipa user-add foo --to-stage --first=foo --last=foo >>> ipa: ERROR: Unknown option: tostage >>> >>> >>> This seems to occur because the frontend find this is a 'remaining' >>> option.. but what does it means ? >>> I tried to add the new options as internal options, or with >>> different names, but it gives the same results. >>> I know it is a very novice question, but I have really no idea I >>> should fix it. Anyone know what I am missing ? >>> >>> regards >>> thierry >> >> Hi, >> Adding these options works for me; I think the most likely reason is >> you're still using the old version. Did you install the changed file >> properly? If you're just copying the .py file to /usr/lib, remember to >> restart Apache. >> > Hi Petr, > > Thanks for the info. > I am using the cli, not the web interface and I installed just > copying user.py to > /usr/lib/python2.7/site-packages/ipalib/plugins/user.py. > I believe I am using the new version as the '--help' option shows > the new added options '--to-stage' and '--from-stage'. The CLI talks to the server, and the options are validated again at the server. The --help shows only the client part of the picture. Do try restarting Apache (`sudo apachectl graceful`). > Did you succeed to add a user with something like: ipa user-add foo > --to-stage --first=foo --last=foo ? Yes. > may be something bad with my deployment I am using freeipa 3.3. Did > you test on master ? Yes, I tested on master, but I don't think that should be an issue. -- Petr? From pviktori at redhat.com Wed May 14 11:00:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 May 2014 13:00:11 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response In-Reply-To: <20140423134608.541d5f03@unused-4-246.brq.redhat.com> References: <20140416150543.0434eb32@unused-4-246.brq.redhat.com> <534EA4C8.4060308@redhat.com> <20140423134608.541d5f03@unused-4-246.brq.redhat.com> Message-ID: <53734CBB.9050602@redhat.com> On 04/23/2014 01:46 PM, Misnyovszki Adam wrote: > On Wed, 16 Apr 2014 11:42:00 -0400 > Rob Crittenden wrote: > >> Misnyovszki Adam wrote: >>> Hi, >>> this patch enables logging json dumps of request and response, using >>> the --log-payload switch in ipa cli. RFC tag is to ensure that I >>> handled the --log-payload switch correctly in ipa cli. Be careful, >>> it only logs, so --log-payload without -v switch doesn't make the >>> dump visible in command line, -v does! >>> >>> https://fedorahosted.org/freeipa/ticket/4233 >> >> Not a NACK but using -vvv makes this a much simpler operation as you >> can then just compare verbose >= 3. This seems like a lot of work >> just to pretty-print some output. >> >> rob >> > > I've found out, that in RPCClient.create_connection, according to > ipalib/backend.py:164, the variable verbose is not an int, rather a > bool ( verbose=(self.env.verbose >= 2) ), so I decided not to break the > workflow of this variable, but rather create a new one(log-payload). > > I was thinking, making verbose to an int would cause more work than to do > it this way. Maybe, but it would be better. We really want -vvv, it's much easier for the user to crank up the verbosity than to hunt for relevant logging options in the help. If it's too much work, just use (api.env.verbose >= 3) directly. -- Petr? From pviktori at redhat.com Wed May 14 11:05:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 May 2014 13:05:49 +0200 Subject: [Freeipa-devel] [PATCH] 468 Make ipa-client-automount backwards compatible In-Reply-To: <533BB2D1.9090502@redhat.com> References: <533ACC95.9050709@redhat.com> <533AF861.4070106@redhat.com> <533BB2D1.9090502@redhat.com> Message-ID: <53734E0D.9020003@redhat.com> On 04/02/2014 08:48 AM, Martin Kosek wrote: > On 04/01/2014 07:33 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> ipa-client-automount calls automountlocation-show command during the >>> process. Unfortunately, FreeIPA commands are forward compatible only >>> and thus fail the installer. >>> >>> Similarly to ipa-client-install, call XML-RPC interface directly >>> with version fixed to 2.0 (command was already available at that >>> version) to fix the failure. >>> >>> https://fedorahosted.org/freeipa/ticket/4290 >> >> ACK. Tested F-20 client against RHEL 6.5 server. >> >> rob >> > > Thanks. > > Pushed to: > master: 66fb4d5e849a049e95d3ef4fcf2b86217488634d > ipa-3-3: ee2fac9bee6728facfa4525b8f97585f7030a14c > > Martin This breaks master, which uses rpcclient instead of xmlclient. Here is a one-liner fix. Pushed to master: 2478aa42a0cc3b9a061c6a281a99f6acb9b84fca -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0549-ipa-client-automount-Use-rpcclient-not-xmlclient-for.patch Type: text/x-patch Size: 1183 bytes Desc: not available URL: From pviktori at redhat.com Wed May 14 10:50:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 May 2014 12:50:12 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <5360AD85.9010802@redhat.com> References: <535FE8D0.7030608@redhat.com> <1398795455.10424.108.camel@willson.li.ssimo.org> <5360068E.80805@redhat.com> <5360AD85.9010802@redhat.com> Message-ID: <53734A64.9080701@redhat.com> On 04/30/2014 10:00 AM, thierry bordaz wrote: > On 04/29/2014 10:07 PM, Martin Kosek wrote: >> On 04/29/2014 08:17 PM, Simo Sorce wrote: >>> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >>>> This adds the "idnsSecInlineSigning" attribute and related option. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3801 >>>> >>>> Simo, is adding a MAY attribute to an existing objectClass okay? >>>> >>> >>> Not unheard of, however in the past we discovered some schema >>> replication issues that may have an impact, let's make sure DS team also >>> agrees this is not going to cause issue. >>> >>>> From a purely functional pov a MAY attribute will not break any stored >>> object, so it is fine. >>> >>> Simo. >> >> Adding Thierry to the CC list to evaluate the risks, he was already >> involved in fixing related issue in the DS for a similar Dogtag schema >> extension. > Hello, > > When an instance in the topology contains schema extensions like new > MAY attribute, this extension would be propagated to all instances > by replication (no need to copy/merge schema files). This was the > purpose of https://fedorahosted.org/389/ticket/47721. So it is fine > to add new MAY/MUST attribute or new attribute/objectclasses. > > During a replication session, a master will check what schema > definitions (objectclasses/attributes) of the replica extends its > own schema. If such definitions exist the supplier add/replace them > in its schema and its user99.ldif file. In your case if a replica > contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but > not the supplier then the supplier 'learns it' (during a replication > session it initiated) and so an entry containing that new attribute > can be updated on the supplier as well. > There is a similar mechanism, when a replica receives a schema that > contains new definitions, it 'learns' them. > > The fix for 47721 is introduced in 389-ds 1.3.2.17 and after. > It was tested with mixing 1.3.2.17 instance with legacy versions > (1.3.1, 1,3.0..), and the schema on both side converged to a common > one. This, whatever if the extensions are present on both side. > A limitation is that a legacy instance (not having the fix), must > have a replica agreements to/from an instance with the fix. > > regards > thierry > Thanks. This means the patch is good for review. I've just rebased it slightly. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0543.2-dns-Add-idnsSecInlineSigning-attribute-add-dnssec-op.patch Type: text/x-patch Size: 9674 bytes Desc: not available URL: From tbordaz at redhat.com Wed May 14 11:54:41 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 14 May 2014 13:54:41 +0200 Subject: [Freeipa-devel] Asking for help to add new options In-Reply-To: <53734629.4080102@redhat.com> References: <5373358D.90301@redhat.com> <53733F06.3070101@redhat.com> <53734504.7040409@redhat.com> <53734629.4080102@redhat.com> Message-ID: <53735981.4020907@redhat.com> On 05/14/2014 12:32 PM, Petr Viktorin wrote: > On 05/14/2014 12:27 PM, thierry bordaz wrote: >> On 05/14/2014 12:01 PM, Petr Viktorin wrote: >>> On 05/14/2014 11:21 AM, thierry bordaz wrote: >>>> Hello, >>>> >>>> Quite beginner in freeipa land, I am trying to add options to >>>> 'user-add' sub-command but desperately failing to make it work. >>>> I did the following modification: >>>> >>>> diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py >>>> index 9b21200..0c36e35 100644 >>>> --- a/ipalib/plugins/user.py >>>> +++ b/ipalib/plugins/user.py >>>> @@ -365,6 +365,20 @@ class user(LDAPObject): >>>> csv=True, >>>> flags=['no_search'], >>>> ), >>>> + Flag('tostage?', >>>> + doc=_('Create user in staging container'), >>>> + flags=('no_search', 'virtual_attribute'), >>>> + cli_name='to_stage', >>>> + default=False, >>>> + ), >>>> + Str('uidstaged?', >>>> + >>>> pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', >>>> + pattern_errmsg='may only include letters, >>>> numbers, >>>> _, -, . and $', >>>> + maxlength=255, >>>> + cli_name='from_staged', >>>> + label=_('Activate the User currently in the >>>> staging >>>> container'), >>>> + normalizer=lambda value: value.lower(), >>>> + ), >>>> ) >>>> >>>> def _normalize_and_validate_email(self, email, >>>> config=None): >>>> @@ -436,12 +450,16 @@ class user_add(LDAPCreate): >>>> msg_summary = _('Added user "%(value)s"') >>>> >>>> has_output_params = LDAPCreate.has_output_params + >>>> user_output_params >>>> + >>>> + #internal_options = ['tostage', 'uidstaged'] >>>> >>>> takes_options = LDAPCreate.takes_options + ( >>>> Flag('noprivate', >>>> cli_name='noprivate', >>>> doc=_('Don\'t create user private group'), >>>> ), >>>> + >>>> + >>>> ) >>>> >>>> >>>> The command 'ipa user-add --help' succeeds giving me the correct >>>> help message. But when I try to add the user it fails: >>>> >>>> ipa user-add foo --to-stage --first=foo --last=foo >>>> ipa: ERROR: Unknown option: tostage >>>> >>>> >>>> This seems to occur because the frontend find this is a >>>> 'remaining' >>>> option.. but what does it means ? >>>> I tried to add the new options as internal options, or with >>>> different names, but it gives the same results. >>>> I know it is a very novice question, but I have really no idea I >>>> should fix it. Anyone know what I am missing ? >>>> >>>> regards >>>> thierry >>> >>> Hi, >>> Adding these options works for me; I think the most likely reason is >>> you're still using the old version. Did you install the changed file >>> properly? If you're just copying the .py file to /usr/lib, remember to >>> restart Apache. >>> >> Hi Petr, >> >> Thanks for the info. >> I am using the cli, not the web interface and I installed just >> copying user.py to >> /usr/lib/python2.7/site-packages/ipalib/plugins/user.py. >> I believe I am using the new version as the '--help' option shows >> the new added options '--to-stage' and '--from-stage'. > > The CLI talks to the server, and the options are validated again at > the server. The --help shows only the client part of the picture. > Do try restarting Apache (`sudo apachectl graceful`). Thanks Petr, I missed that and now it is working fine. I found it described in your presentation http://www.freeipa.org/images/d/d8/FreeIPA33-server-and-client.pdf :-) Thanks for your precious help. > >> Did you succeed to add a user with something like: ipa user-add foo >> --to-stage --first=foo --last=foo ? > > Yes. > >> may be something bad with my deployment I am using freeipa 3.3. Did >> you test on master ? > > Yes, I tested on master, but I don't think that should be an issue. > > From redhatrises at gmail.com Wed May 14 14:24:39 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 14 May 2014 08:24:39 -0600 Subject: [Freeipa-devel] [PATCH 0018] ipa-client-automount should not configure nsswitch.conf In-Reply-To: <53733C3F.90806@redhat.com> References: <53733C3F.90806@redhat.com> Message-ID: Thanks. Updated patch. On Wed, May 14, 2014 at 3:49 AM, Petr Viktorin wrote: > On 05/09/2014 05:09 AM, Gabe Alford wrote: > >> Hello, >> >> Came across this issue in my environment the other day and >> thought I would send a quick patch for review for >> https://fedorahosted.org/freeipa/ticket/3733 >> > > Thanks for the patch! > > This works, but configure_nsswitch would now fail if it was called > options.sssd=True, as nss_value won't be set. > Please remove the if entirely, and perhaps mention in the function's > docstring/name that it's for non-SSSD setups only. > > -- > Petr? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0018-2-ipa-client-automount-should-not-configure-nsswitch.c.patch Type: text/x-patch Size: 1719 bytes Desc: not available URL: From pvoborni at redhat.com Wed May 14 14:41:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 May 2014 16:41:31 +0200 Subject: [Freeipa-devel] [PATCH] 631 webui: fix regression: enabled gid field on group add Message-ID: <5373809B.707@redhat.com> GID field should be enabled by default since the default group is posix. Was caused by option_widget_base not properly reporting value change while selecting the default value. It has to be notified with delay otherwise the event is consumed by FieldBinder. https://fedorahosted.org/freeipa/ticket/4325 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0631-webui-fix-regression-enabled-gid-field-on-group-add.patch Type: text/x-patch Size: 4315 bytes Desc: not available URL: From redhatrises at gmail.com Wed May 14 14:55:05 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 14 May 2014 08:55:05 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: <53732A06.2090500@redhat.com> References: <5372243B.8000401@redhat.com> <53732A06.2090500@redhat.com> Message-ID: What are your thoughts on this? Added UID and SSSUID entities and cleaned up the original patch down to a regular paragraph. Gabe On Wed, May 14, 2014 at 2:32 AM, Petr Spacek wrote: > On 14.5.2014 01:05, Gabe Alford wrote: > >> I had a typo with the one of the UIDs which is fixed with this patch. >> >> The difference is that Fedora/SSSD treats UIDs of 1000 and below as local >> system accounts whereas RHEL treats local system accounts at 500 and SSSD >> local system accounts at 1000. That's why there are conditional paragraphs >> based on if it is Fedora or RHEL. >> > > I think we should define entity (similar to &OS) for this purpose. > > Please look at FreeIPA_Guide.ent and Identity_Management_Guide.ent. > > Petr^2 Spacek > > > On Tue, May 13, 2014 at 7:55 AM, Petr Viktorin >> wrote: >> >> On 05/09/2014 04:14 AM, Gabe Alford wrote: >>> >>> Hello, >>>> >>>> Just wondering if there are any takers in reviewing this patch. >>>> >>>> >>> Sorry, looks like it fell through the cracks :( >>> >>> AFAIK the &OS; entity should work for both Fedora and RHEL, so it should >>> be possible to only have one copy of the paragraph. Or is there >>> something I >>> missed? >>> >>> >>> Gabe >>>> >>>> >>>> >>>> On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford >>> > wrote: >>>> >>>> Hello, >>>> >>>> Patch for the following ticket to add note in documentation about >>>> bad uid ranges: >>>> https://fedorahosted.org/freeipa/ticket/2090 >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>> > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0016-3-DOC-Sometimes-users-set-bad-uid-ranges.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0019-Define-entity-for-UIDs.patch Type: text/x-patch Size: 1412 bytes Desc: not available URL: From tbabej at redhat.com Wed May 14 14:56:14 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 May 2014 16:56:14 +0200 Subject: [Freeipa-devel] [PATCH 0004] freeipa-ci: Add sudo integration job Message-ID: <5373840E.8050308@redhat.com> Hi, the sudo integration job is already in master, so it's time for the job to be pushed to the upstream test job repository. Tomas -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ci-tbabej-0004-Add-sudo-integration-job.patch Type: text/x-patch Size: 1299 bytes Desc: not available URL: From pspacek at redhat.com Wed May 14 15:11:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 14 May 2014 17:11:19 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: References: <5372243B.8000401@redhat.com> <53732A06.2090500@redhat.com> Message-ID: <53738797.5080208@redhat.com> On 14.5.2014 16:55, Gabe Alford wrote: > What are your thoughts on this? Added UID and SSSUID entities and cleaned > up the original patch down to a regular paragraph. The text itself seems good. Can we think of a better names than UID and SSSUID? Maybe something like MINUID and MINSSSUID? I don't know. Conditional ACK: The patch can be pushed if we can find better names for entities. Thank you for your contribution! Petr^2 Spacek > Gabe > > > On Wed, May 14, 2014 at 2:32 AM, Petr Spacek wrote: > >> On 14.5.2014 01:05, Gabe Alford wrote: >> >>> I had a typo with the one of the UIDs which is fixed with this patch. >>> >>> The difference is that Fedora/SSSD treats UIDs of 1000 and below as local >>> system accounts whereas RHEL treats local system accounts at 500 and SSSD >>> local system accounts at 1000. That's why there are conditional paragraphs >>> based on if it is Fedora or RHEL. >>> >> >> I think we should define entity (similar to &OS) for this purpose. >> >> Please look at FreeIPA_Guide.ent and Identity_Management_Guide.ent. >> >> Petr^2 Spacek >> >> >> On Tue, May 13, 2014 at 7:55 AM, Petr Viktorin >>> wrote: >>> >>> On 05/09/2014 04:14 AM, Gabe Alford wrote: >>>> >>>> Hello, >>>>> >>>>> Just wondering if there are any takers in reviewing this patch. >>>>> >>>>> >>>> Sorry, looks like it fell through the cracks :( >>>> >>>> AFAIK the &OS; entity should work for both Fedora and RHEL, so it should >>>> be possible to only have one copy of the paragraph. Or is there >>>> something I >>>> missed? >>>> >>>> >>>> Gabe >>>>> >>>>> >>>>> >>>>> On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford >>>> > wrote: >>>>> >>>>> Hello, >>>>> >>>>> Patch for the following ticket to add note in documentation about >>>>> bad uid ranges: >>>>> https://fedorahosted.org/freeipa/ticket/2090 >>>>> >>>>> Thanks, >>>>> >>>>> Gabe From redhatrises at gmail.com Wed May 14 16:42:19 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 14 May 2014 10:42:19 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: <53738797.5080208@redhat.com> References: <5372243B.8000401@redhat.com> <53732A06.2090500@redhat.com> <53738797.5080208@redhat.com> Message-ID: MINUID and MINSSSUID sound fine. Gabe On Wed, May 14, 2014 at 9:11 AM, Petr Spacek wrote: > On 14.5.2014 16:55, Gabe Alford wrote: > >> What are your thoughts on this? Added UID and SSSUID entities and cleaned >> up the original patch down to a regular paragraph. >> > > The text itself seems good. Can we think of a better names than UID and > SSSUID? > > Maybe something like MINUID and MINSSSUID? I don't know. > > Conditional ACK: The patch can be pushed if we can find better names for > entities. > > Thank you for your contribution! > > Petr^2 Spacek > > > Gabe >> >> >> On Wed, May 14, 2014 at 2:32 AM, Petr Spacek wrote: >> >> On 14.5.2014 01:05, Gabe Alford wrote: >>> >>> I had a typo with the one of the UIDs which is fixed with this patch. >>>> >>>> The difference is that Fedora/SSSD treats UIDs of 1000 and below as >>>> local >>>> system accounts whereas RHEL treats local system accounts at 500 and >>>> SSSD >>>> local system accounts at 1000. That's why there are conditional >>>> paragraphs >>>> based on if it is Fedora or RHEL. >>>> >>>> >>> I think we should define entity (similar to &OS) for this purpose. >>> >>> Please look at FreeIPA_Guide.ent and Identity_Management_Guide.ent. >>> >>> Petr^2 Spacek >>> >>> >>> On Tue, May 13, 2014 at 7:55 AM, Petr Viktorin >>> >>>> wrote: >>>> >>>> On 05/09/2014 04:14 AM, Gabe Alford wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>>> >>>>>> Just wondering if there are any takers in reviewing this >>>>>> patch. >>>>>> >>>>>> >>>>>> Sorry, looks like it fell through the cracks :( >>>>> >>>>> AFAIK the &OS; entity should work for both Fedora and RHEL, so it >>>>> should >>>>> be possible to only have one copy of the paragraph. Or is there >>>>> something I >>>>> missed? >>>>> >>>>> >>>>> Gabe >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford >>>>> > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Patch for the following ticket to add note in documentation >>>>>> about >>>>>> bad uid ranges: >>>>>> https://fedorahosted.org/freeipa/ticket/2090 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gabe >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0016-4-DOC-Sometimes-users-set-bad-uid-ranges.patch Type: text/x-patch Size: 1693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0019-2-Define-entity-for-UIDs.patch Type: text/x-patch Size: 1427 bytes Desc: not available URL: From npmccallum at redhat.com Wed May 14 18:08:32 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 14 May 2014 14:08:32 -0400 Subject: [Freeipa-devel] OTP Sync Client Design Message-ID: <1400090912.4568.13.camel@ipa.example.com> Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both "ipa env" and "ipa ping" seem to require kinit, so I don't see any obvious examples. Nathaniel From dpal at redhat.com Wed May 14 20:34:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 May 2014 16:34:54 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400090912.4568.13.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> Message-ID: <5373D36E.2000008@redhat.com> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: > Occasionally OTP tokens get out of sync with the server. When this > happens, the user or an admin need to synchronize the token. To this > end, we landed server-side synchronization support, which is a simple > bind with a custom control. This all works with my sample test script. > > Client support is proving a bit more difficult. In the ideal world, the > client would contact LDAP directly and perform the operation. This would > make a man in the middle attack difficult and we can ensure encryption > over the entire operation. > > However, browsers, without server-side assistance, cannot perform this > operation from javascript. This means that, in this case, the first > factor and two second factors must be transmitted to the FreeIPA server > and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). > > This command also needs to be accessible *without* an existing user > login since, if a user's token is out of sync, the user can't login. Is > it possible to expose such an API? If so, how? Both "ipa env" and "ipa > ping" seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, ho t a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. Thoughts? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: UI Integration plans rev3.odt Type: application/vnd.oasis.opendocument.text Size: 63051 bytes Desc: not available URL: From npmccallum at redhat.com Wed May 14 21:23:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 14 May 2014 17:23:34 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <5373D36E.2000008@redhat.com> References: <1400090912.4568.13.camel@ipa.example.com> <5373D36E.2000008@redhat.com> Message-ID: <1400102614.4568.44.camel@ipa.example.com> On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: > On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: > > Occasionally OTP tokens get out of sync with the server. When this > > happens, the user or an admin need to synchronize the token. To this > > end, we landed server-side synchronization support, which is a simple > > bind with a custom control. This all works with my sample test script. > > > > Client support is proving a bit more difficult. In the ideal world, the > > client would contact LDAP directly and perform the operation. This would > > make a man in the middle attack difficult and we can ensure encryption > > over the entire operation. > > > > However, browsers, without server-side assistance, cannot perform this > > operation from javascript. This means that, in this case, the first > > factor and two second factors must be transmitted to the FreeIPA server > > and then proxied to 389. Is this an acceptable compromise? > > Does Javascript have a way to encrypt things? > May be we should do some encryption before sending the values over the wire? > On the other hand we are OK with the form based login so I am not sure > if there is any value. Yes, but I agree there is not a lot of value. > We might have some logic related to permissions i.e. members of the > admin group can only sync on server but I am not sure that is something > we should consider out of box. > > In any way IMO it should be a separate page, other than login page that > can be accessed by anyone. It should be visible outside firewall like > other OTP vendors do. This would allow to use a mobile device to sync up > a token (and potentially change the password). This would be nice. > > This command also needs to be accessible *without* an existing user > > login since, if a user's token is out of sync, the user can't login. Is > > it possible to expose such an API? If so, how? Both "ipa env" and "ipa > > ping" seem to require kinit, so I don't see any obvious examples. > > IMO SSSD should probably have a way to sync the token. > From usability point of view it should be a part of the standard stock > client software, not a part of the IPA client or ipa tools. > It should probably have a good UI integration too if token is used to > login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. > So for that to happen we should probably expose this interface over D-BUS. > This is what we talked about with the desktop folks some time ago. > The attached is the doc and there are diagrams at the end that show what > we decided needs to be done. > Similar to that one can provide a simple otp-sync application that will > sync using command line (but on the other hand may be it should just > warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. > Some thoughts came up while writing this mail: > > a) We can go the complex path and provide password and sync capabilities > in every client. This is a lot of work based on my past experience and > can't be done quickly. See the complexity of the diagrams and flows in > the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. > b) May be IPA should provide a portal/proxy to do self service token > sync and/or password change. This can be a URL. It should be possible to > access it externally outside the firewall. It should be bullet proof. > But then we need just one interface and one call and we can use it from > mobile device or some other system on the internet to self service the > token and then pass authentication. IMO that would save us a lot of time > and effort. I know other OTP vendors went this path and were quite > successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. Nathaniel From dpal at redhat.com Wed May 14 21:35:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 May 2014 17:35:32 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400102614.4568.44.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> <5373D36E.2000008@redhat.com> <1400102614.4568.44.camel@ipa.example.com> Message-ID: <5373E1A4.3050004@redhat.com> On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: > On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: >> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: >>> Occasionally OTP tokens get out of sync with the server. When this >>> happens, the user or an admin need to synchronize the token. To this >>> end, we landed server-side synchronization support, which is a simple >>> bind with a custom control. This all works with my sample test script. >>> >>> Client support is proving a bit more difficult. In the ideal world, the >>> client would contact LDAP directly and perform the operation. This would >>> make a man in the middle attack difficult and we can ensure encryption >>> over the entire operation. >>> >>> However, browsers, without server-side assistance, cannot perform this >>> operation from javascript. This means that, in this case, the first >>> factor and two second factors must be transmitted to the FreeIPA server >>> and then proxied to 389. Is this an acceptable compromise? >> Does Javascript have a way to encrypt things? >> May be we should do some encryption before sending the values over the wire? >> On the other hand we are OK with the form based login so I am not sure >> if there is any value. > Yes, but I agree there is not a lot of value. > >> We might have some logic related to permissions i.e. members of the >> admin group can only sync on server but I am not sure that is something >> we should consider out of box. >> >> In any way IMO it should be a separate page, other than login page that >> can be accessed by anyone. It should be visible outside firewall like >> other OTP vendors do. This would allow to use a mobile device to sync up >> a token (and potentially change the password). > This would be nice. > >>> This command also needs to be accessible *without* an existing user >>> login since, if a user's token is out of sync, the user can't login. Is >>> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >>> ping" seem to require kinit, so I don't see any obvious examples. >> IMO SSSD should probably have a way to sync the token. >> From usability point of view it should be a part of the standard stock >> client software, not a part of the IPA client or ipa tools. >> It should probably have a good UI integration too if token is used to >> login into a laptop. > SSSD has direct access to LDAP right? If so, it can just do a bind with > the added control. That is actually the easiest way. Trying to access > via a third API is probably actually more difficult. > >> So for that to happen we should probably expose this interface over D-BUS. >> This is what we talked about with the desktop folks some time ago. >> The attached is the doc and there are diagrams at the end that show what >> we decided needs to be done. >> Similar to that one can provide a simple otp-sync application that will >> sync using command line (but on the other hand may be it should just >> warp curl?). > How exactly we expose this in GDM is indeed a much more complicated > question and needs to be part of the next phase of integration. I've > CC'd jhrozek for this part. > >> Some thoughts came up while writing this mail: >> >> a) We can go the complex path and provide password and sync capabilities >> in every client. This is a lot of work based on my past experience and >> can't be done quickly. See the complexity of the diagrams and flows in >> the attached doc. And may be it should not be. > The synchronization needs to be added to whatever layer has access to > the LDAP server. How it is exposed from there is specific to each > application. > >> b) May be IPA should provide a portal/proxy to do self service token >> sync and/or password change. This can be a URL. It should be possible to >> access it externally outside the firewall. It should be bullet proof. >> But then we need just one interface and one call and we can use it from >> mobile device or some other system on the internet to self service the >> token and then pass authentication. IMO that would save us a lot of time >> and effort. I know other OTP vendors went this path and were quite >> successful. > +1. This solves the VPN bootstrapping problem. > > However: > > 1. It should be available by default in the FreeIPA installation with a > link from the login page. This is just a matter of product polish. > > 2. In the case of a user logging into GDM, we have a bootstrapping > problem that they can't login without a token, and they can't sync their > token without logging into a browser. GDM/SSSD probably needs to support > this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes. > > Nathaniel > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From npmccallum at redhat.com Wed May 14 21:49:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 14 May 2014 17:49:26 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <5373E1A4.3050004@redhat.com> References: <1400090912.4568.13.camel@ipa.example.com> <5373D36E.2000008@redhat.com> <1400102614.4568.44.camel@ipa.example.com> <5373E1A4.3050004@redhat.com> Message-ID: <1400104166.4568.64.camel@ipa.example.com> On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: > On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: > > On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: > >> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: > >>> Occasionally OTP tokens get out of sync with the server. When this > >>> happens, the user or an admin need to synchronize the token. To this > >>> end, we landed server-side synchronization support, which is a simple > >>> bind with a custom control. This all works with my sample test script. > >>> > >>> Client support is proving a bit more difficult. In the ideal world, the > >>> client would contact LDAP directly and perform the operation. This would > >>> make a man in the middle attack difficult and we can ensure encryption > >>> over the entire operation. > >>> > >>> However, browsers, without server-side assistance, cannot perform this > >>> operation from javascript. This means that, in this case, the first > >>> factor and two second factors must be transmitted to the FreeIPA server > >>> and then proxied to 389. Is this an acceptable compromise? > >> Does Javascript have a way to encrypt things? > >> May be we should do some encryption before sending the values over the wire? > >> On the other hand we are OK with the form based login so I am not sure > >> if there is any value. > > Yes, but I agree there is not a lot of value. > > > >> We might have some logic related to permissions i.e. members of the > >> admin group can only sync on server but I am not sure that is something > >> we should consider out of box. > >> > >> In any way IMO it should be a separate page, other than login page that > >> can be accessed by anyone. It should be visible outside firewall like > >> other OTP vendors do. This would allow to use a mobile device to sync up > >> a token (and potentially change the password). > > This would be nice. > > > >>> This command also needs to be accessible *without* an existing user > >>> login since, if a user's token is out of sync, the user can't login. Is > >>> it possible to expose such an API? If so, how? Both "ipa env" and "ipa > >>> ping" seem to require kinit, so I don't see any obvious examples. > >> IMO SSSD should probably have a way to sync the token. > >> From usability point of view it should be a part of the standard stock > >> client software, not a part of the IPA client or ipa tools. > >> It should probably have a good UI integration too if token is used to > >> login into a laptop. > > SSSD has direct access to LDAP right? If so, it can just do a bind with > > the added control. That is actually the easiest way. Trying to access > > via a third API is probably actually more difficult. > > > >> So for that to happen we should probably expose this interface over D-BUS. > >> This is what we talked about with the desktop folks some time ago. > >> The attached is the doc and there are diagrams at the end that show what > >> we decided needs to be done. > >> Similar to that one can provide a simple otp-sync application that will > >> sync using command line (but on the other hand may be it should just > >> warp curl?). > > How exactly we expose this in GDM is indeed a much more complicated > > question and needs to be part of the next phase of integration. I've > > CC'd jhrozek for this part. > > > >> Some thoughts came up while writing this mail: > >> > >> a) We can go the complex path and provide password and sync capabilities > >> in every client. This is a lot of work based on my past experience and > >> can't be done quickly. See the complexity of the diagrams and flows in > >> the attached doc. And may be it should not be. > > The synchronization needs to be added to whatever layer has access to > > the LDAP server. How it is exposed from there is specific to each > > application. > > > >> b) May be IPA should provide a portal/proxy to do self service token > >> sync and/or password change. This can be a URL. It should be possible to > >> access it externally outside the firewall. It should be bullet proof. > >> But then we need just one interface and one call and we can use it from > >> mobile device or some other system on the internet to self service the > >> token and then pass authentication. IMO that would save us a lot of time > >> and effort. I know other OTP vendors went this path and were quite > >> successful. > > +1. This solves the VPN bootstrapping problem. > > > > However: > > > > 1. It should be available by default in the FreeIPA installation with a > > link from the login page. This is just a matter of product polish. > > > > 2. In the case of a user logging into GDM, we have a bootstrapping > > problem that they can't login without a token, and they can't sync their > > token without logging into a browser. GDM/SSSD probably needs to support > > this natively. > > True but not from day one. > This is why I mentioned a mobile device. > Keeping in mind that FreeOTP is on the mobile device and there is a good > chance that the person who will have a Linux laptop will have a mobile > device. > They can also call a helpdesk and ask the helpdesk engineer to sync the > token for them. > That means that there should be an admin interface that would not > require the first factor just two codes. Yup. Agreed. Just thinking big picture. Nathaniel From dpal at redhat.com Wed May 14 22:23:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 May 2014 18:23:20 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400104166.4568.64.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> <5373D36E.2000008@redhat.com> <1400102614.4568.44.camel@ipa.example.com> <5373E1A4.3050004@redhat.com> <1400104166.4568.64.camel@ipa.example.com> Message-ID: <5373ECD8.30000@redhat.com> On 05/14/2014 05:49 PM, Nathaniel McCallum wrote: > On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: >> On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: >>> On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: >>>> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: >>>>> Occasionally OTP tokens get out of sync with the server. When this >>>>> happens, the user or an admin need to synchronize the token. To this >>>>> end, we landed server-side synchronization support, which is a simple >>>>> bind with a custom control. This all works with my sample test script. >>>>> >>>>> Client support is proving a bit more difficult. In the ideal world, the >>>>> client would contact LDAP directly and perform the operation. This would >>>>> make a man in the middle attack difficult and we can ensure encryption >>>>> over the entire operation. >>>>> >>>>> However, browsers, without server-side assistance, cannot perform this >>>>> operation from javascript. This means that, in this case, the first >>>>> factor and two second factors must be transmitted to the FreeIPA server >>>>> and then proxied to 389. Is this an acceptable compromise? >>>> Does Javascript have a way to encrypt things? >>>> May be we should do some encryption before sending the values over the wire? >>>> On the other hand we are OK with the form based login so I am not sure >>>> if there is any value. >>> Yes, but I agree there is not a lot of value. >>> >>>> We might have some logic related to permissions i.e. members of the >>>> admin group can only sync on server but I am not sure that is something >>>> we should consider out of box. >>>> >>>> In any way IMO it should be a separate page, other than login page that >>>> can be accessed by anyone. It should be visible outside firewall like >>>> other OTP vendors do. This would allow to use a mobile device to sync up >>>> a token (and potentially change the password). >>> This would be nice. >>> >>>>> This command also needs to be accessible *without* an existing user >>>>> login since, if a user's token is out of sync, the user can't login. Is >>>>> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >>>>> ping" seem to require kinit, so I don't see any obvious examples. >>>> IMO SSSD should probably have a way to sync the token. >>>> From usability point of view it should be a part of the standard stock >>>> client software, not a part of the IPA client or ipa tools. >>>> It should probably have a good UI integration too if token is used to >>>> login into a laptop. >>> SSSD has direct access to LDAP right? If so, it can just do a bind with >>> the added control. That is actually the easiest way. Trying to access >>> via a third API is probably actually more difficult. >>> >>>> So for that to happen we should probably expose this interface over D-BUS. >>>> This is what we talked about with the desktop folks some time ago. >>>> The attached is the doc and there are diagrams at the end that show what >>>> we decided needs to be done. >>>> Similar to that one can provide a simple otp-sync application that will >>>> sync using command line (but on the other hand may be it should just >>>> warp curl?). >>> How exactly we expose this in GDM is indeed a much more complicated >>> question and needs to be part of the next phase of integration. I've >>> CC'd jhrozek for this part. >>> >>>> Some thoughts came up while writing this mail: >>>> >>>> a) We can go the complex path and provide password and sync capabilities >>>> in every client. This is a lot of work based on my past experience and >>>> can't be done quickly. See the complexity of the diagrams and flows in >>>> the attached doc. And may be it should not be. >>> The synchronization needs to be added to whatever layer has access to >>> the LDAP server. How it is exposed from there is specific to each >>> application. >>> >>>> b) May be IPA should provide a portal/proxy to do self service token >>>> sync and/or password change. This can be a URL. It should be possible to >>>> access it externally outside the firewall. It should be bullet proof. >>>> But then we need just one interface and one call and we can use it from >>>> mobile device or some other system on the internet to self service the >>>> token and then pass authentication. IMO that would save us a lot of time >>>> and effort. I know other OTP vendors went this path and were quite >>>> successful. >>> +1. This solves the VPN bootstrapping problem. >>> >>> However: >>> >>> 1. It should be available by default in the FreeIPA installation with a >>> link from the login page. This is just a matter of product polish. >>> >>> 2. In the case of a user logging into GDM, we have a bootstrapping >>> problem that they can't login without a token, and they can't sync their >>> token without logging into a browser. GDM/SSSD probably needs to support >>> this natively. >> True but not from day one. >> This is why I mentioned a mobile device. >> Keeping in mind that FreeOTP is on the mobile device and there is a good >> chance that the person who will have a Linux laptop will have a mobile >> device. >> They can also call a helpdesk and ask the helpdesk engineer to sync the >> token for them. >> That means that there should be an admin interface that would not >> require the first factor just two codes. > Yup. Agreed. Just thinking big picture. > > Nathaniel > > So it looks like that we agree that: a) IPA should provide a special page to do resync and or password change. b) This page can be linked off the login page c) Desktop would need to be integrated (in future but not now) d) There should be an internal page/CLI that would allow admin or token owner to resync the token without providing the first factor (future). It also occurred to me that the workflow can be: User can't log in He calls helpdesk Admin disables his token for a period of time (day, hour - policy defined) allowing user to log in and resync it User logs with the password part User goes to his portal because he knows that token will be auto reenabled after some time. User resyncs the token Token auto enables itself IMO this would be a nice optimization in future. We can also recommend always having a backup software token on the mobile device just in case. Bottom line: in modern world portal + backup alternative token on mobile device would address most of the scenarios, also people will tell us what problems they face and what we should address next. We probably should have a "Token owner guide" that would talk about these scenarios and help people to resolve them. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Thu May 15 07:52:12 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 May 2014 03:52:12 -0400 (EDT) Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400090912.4568.13.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> Message-ID: <261626348.6107829.1400140332870.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Occasionally OTP tokens get out of sync with the server. When this > happens, the user or an admin need to synchronize the token. To this > end, we landed server-side synchronization support, which is a simple > bind with a custom control. This all works with my sample test script. > > Client support is proving a bit more difficult. In the ideal world, the > client would contact LDAP directly and perform the operation. This would > make a man in the middle attack difficult and we can ensure encryption > over the entire operation. > > However, browsers, without server-side assistance, cannot perform this > operation from javascript. This means that, in this case, the first > factor and two second factors must be transmitted to the FreeIPA server > and then proxied to 389. Is this an acceptable compromise? > > This command also needs to be accessible *without* an existing user > login since, if a user's token is out of sync, the user can't login. Is > it possible to expose such an API? If so, how? Both "ipa env" and "ipa > ping" seem to require kinit, so I don't see any obvious examples. Sounds to me this should be done via a separate page not from javascript, then you do not have to deal with the chicken-egg issue of framework authentication ... yeah custom code's not great but the problem here seems quite limited to re-synchronization only. Simo. From pvoborni at redhat.com Thu May 15 08:15:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 May 2014 10:15:15 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <261626348.6107829.1400140332870.JavaMail.zimbra@redhat.com> References: <1400090912.4568.13.camel@ipa.example.com> <261626348.6107829.1400140332870.JavaMail.zimbra@redhat.com> Message-ID: <53747793.9040102@redhat.com> On 15.5.2014 09:52, Simo Sorce wrote: > > > ----- Original Message ----- >> Occasionally OTP tokens get out of sync with the server. When this >> happens, the user or an admin need to synchronize the token. To this >> end, we landed server-side synchronization support, which is a simple >> bind with a custom control. This all works with my sample test script. >> >> Client support is proving a bit more difficult. In the ideal world, the >> client would contact LDAP directly and perform the operation. This would >> make a man in the middle attack difficult and we can ensure encryption >> over the entire operation. >> >> However, browsers, without server-side assistance, cannot perform this >> operation from javascript. This means that, in this case, the first >> factor and two second factors must be transmitted to the FreeIPA server >> and then proxied to 389. Is this an acceptable compromise? >> >> This command also needs to be accessible *without* an existing user >> login since, if a user's token is out of sync, the user can't login. Is >> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >> ping" seem to require kinit, so I don't see any obvious examples. > > Sounds to me this should be done via a separate page not from javascript, > then you do not have to deal with the chicken-egg issue of framework > authentication ... yeah custom code's not great but the problem here seems > quite limited to re-synchronization only. > > Simo. > IMO it should be similar to ipaserver.rpcserver.login_password and change_password methods. Then it could be use from various UIs - main IPA Web UI, separate page, some CLI app... -- Petr Vobornik From pvoborni at redhat.com Thu May 15 11:40:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 May 2014 13:40:15 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <5373ECD8.30000@redhat.com> References: <1400090912.4568.13.camel@ipa.example.com> <5373D36E.2000008@redhat.com> <1400102614.4568.44.camel@ipa.example.com> <5373E1A4.3050004@redhat.com> <1400104166.4568.64.camel@ipa.example.com> <5373ECD8.30000@redhat.com> Message-ID: <5374A79F.8050003@redhat.com> On 15.5.2014 00:23, Dmitri Pal wrote: > On 05/14/2014 05:49 PM, Nathaniel McCallum wrote: >> On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: >>> On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: >>>> On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: >>>>> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: >>>>>> Occasionally OTP tokens get out of sync with the server. When this >>>>>> happens, the user or an admin need to synchronize the token. To this >>>>>> end, we landed server-side synchronization support, which is a simple >>>>>> bind with a custom control. This all works with my sample test >>>>>> script. >>>>>> >>>>>> Client support is proving a bit more difficult. In the ideal >>>>>> world, the >>>>>> client would contact LDAP directly and perform the operation. This >>>>>> would >>>>>> make a man in the middle attack difficult and we can ensure >>>>>> encryption >>>>>> over the entire operation. >>>>>> >>>>>> However, browsers, without server-side assistance, cannot perform >>>>>> this >>>>>> operation from javascript. This means that, in this case, the first >>>>>> factor and two second factors must be transmitted to the FreeIPA >>>>>> server >>>>>> and then proxied to 389. Is this an acceptable compromise? >>>>> Does Javascript have a way to encrypt things? >>>>> May be we should do some encryption before sending the values over >>>>> the wire? >>>>> On the other hand we are OK with the form based login so I am not sure >>>>> if there is any value. >>>> Yes, but I agree there is not a lot of value. >>>> >>>>> We might have some logic related to permissions i.e. members of the >>>>> admin group can only sync on server but I am not sure that is >>>>> something >>>>> we should consider out of box. >>>>> >>>>> In any way IMO it should be a separate page, other than login page >>>>> that >>>>> can be accessed by anyone. It should be visible outside firewall like >>>>> other OTP vendors do. This would allow to use a mobile device to >>>>> sync up >>>>> a token (and potentially change the password). >>>> This would be nice. >>>> >>>>>> This command also needs to be accessible *without* an existing user >>>>>> login since, if a user's token is out of sync, the user can't >>>>>> login. Is >>>>>> it possible to expose such an API? If so, how? Both "ipa env" and >>>>>> "ipa >>>>>> ping" seem to require kinit, so I don't see any obvious examples. >>>>> IMO SSSD should probably have a way to sync the token. >>>>> From usability point of view it should be a part of the standard >>>>> stock >>>>> client software, not a part of the IPA client or ipa tools. >>>>> It should probably have a good UI integration too if token is used to >>>>> login into a laptop. >>>> SSSD has direct access to LDAP right? If so, it can just do a bind with >>>> the added control. That is actually the easiest way. Trying to access >>>> via a third API is probably actually more difficult. >>>> >>>>> So for that to happen we should probably expose this interface over >>>>> D-BUS. >>>>> This is what we talked about with the desktop folks some time ago. >>>>> The attached is the doc and there are diagrams at the end that show >>>>> what >>>>> we decided needs to be done. >>>>> Similar to that one can provide a simple otp-sync application that >>>>> will >>>>> sync using command line (but on the other hand may be it should just >>>>> warp curl?). >>>> How exactly we expose this in GDM is indeed a much more complicated >>>> question and needs to be part of the next phase of integration. I've >>>> CC'd jhrozek for this part. >>>> >>>>> Some thoughts came up while writing this mail: >>>>> >>>>> a) We can go the complex path and provide password and sync >>>>> capabilities >>>>> in every client. This is a lot of work based on my past experience and >>>>> can't be done quickly. See the complexity of the diagrams and flows in >>>>> the attached doc. And may be it should not be. >>>> The synchronization needs to be added to whatever layer has access to >>>> the LDAP server. How it is exposed from there is specific to each >>>> application. >>>> >>>>> b) May be IPA should provide a portal/proxy to do self service token >>>>> sync and/or password change. This can be a URL. It should be >>>>> possible to >>>>> access it externally outside the firewall. It should be bullet proof. >>>>> But then we need just one interface and one call and we can use it >>>>> from >>>>> mobile device or some other system on the internet to self service the >>>>> token and then pass authentication. IMO that would save us a lot of >>>>> time >>>>> and effort. I know other OTP vendors went this path and were quite >>>>> successful. >>>> +1. This solves the VPN bootstrapping problem. >>>> >>>> However: >>>> >>>> 1. It should be available by default in the FreeIPA installation with a >>>> link from the login page. This is just a matter of product polish. >>>> >>>> 2. In the case of a user logging into GDM, we have a bootstrapping >>>> problem that they can't login without a token, and they can't sync >>>> their >>>> token without logging into a browser. GDM/SSSD probably needs to >>>> support >>>> this natively. >>> True but not from day one. >>> This is why I mentioned a mobile device. >>> Keeping in mind that FreeOTP is on the mobile device and there is a good >>> chance that the person who will have a Linux laptop will have a mobile >>> device. >>> They can also call a helpdesk and ask the helpdesk engineer to sync the >>> token for them. >>> That means that there should be an admin interface that would not >>> require the first factor just two codes. >> Yup. Agreed. Just thinking big picture. >> >> Nathaniel >> >> > So it looks like that we agree that: > > a) IPA should provide a special page to do resync and or password change. +1 These pages should not point to our UI but they might provide a mechanism for redirecting to other page on success if supplied. We already provide separate page for password reset which can be exposed. http://pvoborni.fedorapeople.org/ui/reset_password.html > b) This page can be linked off the login page in addition to the separate pages, the otp-sync interface might be also integrated in Web UI app in a same way as password reset: http://pvoborni.fedorapeople.org/videos/reset_pw_on_login.webm > c) Desktop would need to be integrated (in future but not now) > d) There should be an internal page/CLI that would allow admin or token > owner to resync the token without providing the first factor (future). > > It also occurred to me that the workflow can be: > User can't log in > He calls helpdesk > Admin disables his token for a period of time (day, hour - policy > defined) allowing user to log in and resync it > User logs with the password part > User goes to his portal because he knows that token will be auto > reenabled after some time. > User resyncs the token > Token auto enables itself > > IMO this would be a nice optimization in future. > We can also recommend always having a backup software token on the > mobile device just in case. > > Bottom line: in modern world portal + backup alternative token on mobile > device would address most of the scenarios, also people will tell us > what problems they face and what we should address next. > > We probably should have a "Token owner guide" that would talk about > these scenarios and help people to resolve them. > > -- Petr Vobornik From pvoborni at redhat.com Thu May 15 13:58:57 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 May 2014 15:58:57 +0200 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu Message-ID: <5374C821.60004@redhat.com> Just an idea: there is only one top level item in self service menu -> no point of having this level. This patch replaces top level with second menu level original: * http://pvoborni.fedorapeople.org/images/self-service-menu-2levels.png new: * http://pvoborni.fedorapeople.org/images/self-service-menu-1level.png -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0632-webui-simplify-self-service-menu.patch Type: text/x-patch Size: 1149 bytes Desc: not available URL: From jhrozek at redhat.com Thu May 15 14:57:01 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 15 May 2014 16:57:01 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400102614.4568.44.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> <5373D36E.2000008@redhat.com> <1400102614.4568.44.camel@ipa.example.com> Message-ID: <20140515145701.GG29987@hendrix.redhat.com> On Wed, May 14, 2014 at 05:23:34PM -0400, Nathaniel McCallum wrote: > > IMO SSSD should probably have a way to sync the token. > > From usability point of view it should be a part of the standard stock > > client software, not a part of the IPA client or ipa tools. > > It should probably have a good UI integration too if token is used to > > login into a laptop. > > SSSD has direct access to LDAP right? If so, it can just do a bind with > the added control. That is actually the easiest way. Trying to access > via a third API is probably actually more difficult. Yes, SSSD uses the machine's account (the keytab), so whatever info you can read using the machine credentials is avaibale to the SSSD. From jcholast at redhat.com Thu May 15 15:46:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 May 2014 17:46:53 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <535A2226.6080803@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A2226.6080803@redhat.com> Message-ID: <5374E16D.9050509@redhat.com> On 25.4.2014 10:51, Jan Cholasta wrote: > On 24.4.2014 23:16, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>> Some in-line, a whole ton of data appended to end. >>>> >>>> Jan Cholasta wrote: >>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> >>>>>>> 247 >>>>>>> >>>>>>> We've been burned by hardcoded timeouts in the past. Should this be >>>>>>> configurable? This module doesn't currently do any logging but it >>>>>>> might >>>>>>> be worth spitting out a "waiting" message, at least for debugging. >>>>> >>>>> Added a timeout argument. >>>> >>>> Did you forget to send this one, I didn't see an update to 247. >>> >>> Are you sure you have 247.1 (now 247.2)? >>> >>> I can see at >>> >>> that I have sent the correct version of the patches. >> >> The call has a timeout, the callers don't use it. I guess it'll do for >> now, but these almost always come back to bite us. > > Well, I can add --certmonger-timeout option to ipa-cacert-manage, if > that's what you want. > >> >>> >>>>>>> >>>>>>> 251 >>>>>>> >>>>>>> The tool should provide some feedback while it's running. For the >>>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>>> what is >>>>>>> going on, something in between nothing and full debug output. >>>>> >>>>> Added some messages about what's going on. >>>> >>>> I dpn't see an update to 251 either. >>> >>> Please make sure you have 251.1 (now 251.2). >> >> There is a little bit more output but there are still very long periods >> of waiting between any visual activity, particularly when doing it on an >> IPA self-signed CA. > > This stuff takes time :-) What would you like to see in the output, > that's not already there? > >>>> >>>> I think the ipa-cacert-manage man page is missing one really important >>>> piece: why would you ever need to run this? And when? >>> >>> Added a paragraph about this. >> >> It's better, couple of comments: >> >> Add "the" in between renew and CA in "used to manually renew CA >> certificate of" and "When IPA CA...". > > OK. > >> I haven't had any luck renewing >> the CA certificate yet. I see that it is tracked now. I started moving >> the system clock forward in order to get to renewal and about the 3rd >> iteration the requests started failing with an XML error. Did you see >> this? >> >> [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most >> recent call last): >> [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 344, in >> wsgi_execute >> [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = >> self.Command[name](*args, **options) >> [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >> __call__ >> [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = >> self.run(*args, **options) >> [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run >> [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = >> self.execute(*args, **options) >> [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 382, in >> execute >> [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = >> api.Command['cert_show'](unicode(serial))['result'] >> [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >> __call__ >> [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = >> self.run(*args, **options) >> [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run >> [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = >> self.execute(*args, **options) >> [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 514, in >> execute >> [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] >> result=self.Backend.ra.get_certificate(serial_number) >> [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >> 1502, in get_certificate >> [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result >> = self.get_parse_result_xml(http_body, parse_display_cert_xml) >> [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >> 1363, in get_parse_result_xml >> [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = >> etree.fromstring(xml_text, parser) >> [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File >> "lxml.etree.pyx", line 3032, in lxml.etree.fromstring >> (src/lxml/lxml.etree.c:68129) >> [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File >> "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument >> (src/lxml/lxml.etree.c:102493) >> [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File >> "parser.pxi", line 1673, in lxml.etree._parseDoc >> (src/lxml/lxml.etree.c:101322) >> [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File >> "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc >> (src/lxml/lxml.etree.c:96504) >> [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File >> "parser.pxi", line 582, in >> lxml.etree._ParserContext._handleParseResultDoc >> (src/lxml/lxml.etree.c:91308) >> [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File >> "parser.pxi", line 683, in lxml.etree._handleParseResult >> (src/lxml/lxml.etree.c:92494) >> [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File >> "parser.pxi", line 633, in lxml.etree._raiseParseError >> (src/lxml/lxml.etree.c:91957) >> [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: >> None >> [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: >> [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: >> cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8VP! Z! >> > gm! >> >> 3VCtgMvPVk >> 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', >> >> principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, >> version=u'2.51'): XMLSyntaxError > > I have never seen this. The error message does not say much... Is there > anything interesting in other logs? I was able to get the CA certificate to be renewed after moving system time forward step by step. One thing I haven't noticed before is that the renewed certificate's validity never exceeds that of the original certificate. This is most likely Dogtag issue (something along the lines of "certificate validity cannot exceed validity of the CA certificate", except it shouldn't apply to the CA certificate itself). There were other issues here and there, all of them were caused by race conditions between concurrent renewals (unreachable CA, XML syntax errors, etc. because Dogtag was stopped by stop_pkicad in another request, CMS internal error because it used old subsystem cert to authenticate to LDAP while the cert was being renewed, etc.) and all of them could be fixed by restarting relevant IPA services and resubmitting the requests manually. Some synchronization is really missing there. > >> >> I noticed that in the external CA case we still have certmonger tracking >> the CA. What will it do at expiration? > > It syslogs the message in patch 252, for the lack of better notification > mechanism. > >> >> /etc/ipa/ca.crt isn't being updated on renewal. > > That will be dealt with in the next batch of patches. > >> >> rob > > -- Jan Cholasta From pviktori at redhat.com Fri May 16 09:16:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 May 2014 11:16:04 +0200 Subject: [Freeipa-devel] [PATCH 0018] ipa-client-automount should not configure nsswitch.conf In-Reply-To: References: <53733C3F.90806@redhat.com> Message-ID: <5375D754.1070803@redhat.com> On 05/14/2014 04:24 PM, Gabe Alford wrote: > Thanks. Updated patch. Great! ACK, there's just some whitespace left in the patch. Removed trailing whitespace, pushed to master: 98102832789412f567a96693dfe27b0e00cc98e5 > > > On Wed, May 14, 2014 at 3:49 AM, Petr Viktorin > wrote: > > On 05/09/2014 05:09 AM, Gabe Alford wrote: > > Hello, > > Came across this issue in my environment the other day and > thought I would send a quick patch for review for > https://fedorahosted.org/__freeipa/ticket/3733 > > > > Thanks for the patch! > > This works, but configure_nsswitch would now fail if it was called > options.sssd=True, as nss_value won't be set. > Please remove the if entirely, and perhaps mention in the function's > docstring/name that it's for non-SSSD setups only. > > -- > Petr? > > -- Petr? From mkosek at redhat.com Fri May 16 11:54:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 May 2014 13:54:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <536012E1.6080702@redhat.com> References: <536012E1.6080702@redhat.com> Message-ID: <5375FC60.40708@redhat.com> On 04/29/2014 11:00 PM, Petr Viktorin wrote: > Patch 0540 adds a bunch of managed read ACIs for user, as discussed previously > [0]. > > Patch 0541 is some minor refactoring for the next part. > > Patch 0542 sets the read acces to addressbook attributes to anonymous when > upgrading from pre-4.0. > I first this by checking if the update is run from ipa-server-install or not, > but then I realized the logic I want is simple: if the global anon read ACI > exists, we want to preserve its spirit by setting addressbook attribute ACI to > anonymous. > > > [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et al. > 540: Looks good! The only attributes I am concerned about are special IPA attributes: - ipauniqueid - ipasshpubkey - ipauserauthtype - userclass I personally do not think they should be included in POSIX attributes permissions, they are far from POSIX definition... What about creating one more permission "System: Read User IPA Attributes" as these are specific to FreeIPA use and allowing that permission for all authenticated users? 541, 542: ACK for both, works fine in both new installation and upgrade. Martin From mkosek at redhat.com Fri May 16 12:00:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 May 2014 14:00:36 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI In-Reply-To: <53601381.9050207@redhat.com> References: <53601381.9050207@redhat.com> Message-ID: <5375FDE4.3070400@redhat.com> 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. Martin From mkosek at redhat.com Fri May 16 12:30:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 May 2014 14:30:04 +0200 Subject: [Freeipa-devel] [PATCH] 0455 Replace "replica admins read access" ACI with a permission In-Reply-To: <536113C2.40704@redhat.com> References: <536113C2.40704@redhat.com> Message-ID: <537604CC.30404@redhat.com> 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. Martin From pviktori at redhat.com Fri May 16 13:12:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 May 2014 15:12:43 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges In-Reply-To: References: <5372243B.8000401@redhat.com> <53732A06.2090500@redhat.com> <53738797.5080208@redhat.com> Message-ID: <53760ECB.2070506@redhat.com> On 05/14/2014 06:42 PM, Gabe Alford wrote: > MINUID and MINSSSUID sound fine. > > Gabe Thanks! Pushed to docs master: 4978945ab168b471a15a6d5536ca397e934fe8fc > On Wed, May 14, 2014 at 9:11 AM, Petr Spacek > wrote: > > On 14.5.2014 16:55, Gabe Alford wrote: > > What are your thoughts on this? Added UID and SSSUID entities > and cleaned > up the original patch down to a regular paragraph. > > > The text itself seems good. Can we think of a better names than UID > and SSSUID? > > Maybe something like MINUID and MINSSSUID? I don't know. > > Conditional ACK: The patch can be pushed if we can find better names > for entities. > > Thank you for your contribution! > > Petr^2 Spacek > > > Gabe > > > On Wed, May 14, 2014 at 2:32 AM, Petr Spacek > wrote: > > On 14.5.2014 01:05, Gabe Alford wrote: > > I had a typo with the one of the UIDs which is fixed > with this patch. > > The difference is that Fedora/SSSD treats UIDs of 1000 > and below as local > system accounts whereas RHEL treats local system > accounts at 500 and SSSD > local system accounts at 1000. That's why there are > conditional paragraphs > based on if it is Fedora or RHEL. > > > I think we should define entity (similar to &OS) for this > purpose. > > Please look at FreeIPA_Guide.ent and > Identity_Management_Guide.ent. > > Petr^2 Spacek > > > On Tue, May 13, 2014 at 7:55 AM, Petr Viktorin > > > > wrote: > > On 05/09/2014 04:14 AM, Gabe Alford wrote: > > > Hello, > > > Just wondering if there are any takers > in reviewing this patch. > > > Sorry, looks like it fell through the cracks :( > > AFAIK the &OS; entity should work for both Fedora > and RHEL, so it should > be possible to only have one copy of the paragraph. > Or is there > something I > missed? > > > Gabe > > > > > On Mon, Apr 21, 2014 at 5:48 PM, Gabe Alford > > >__> wrote: > > Hello, > > Patch for the following ticket to add > note in documentation about > bad uid ranges: > https://fedorahosted.org/__freeipa/ticket/2090 > > > Thanks, > > Gabe > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Petr? From kybaker at redhat.com Fri May 16 13:19:56 2014 From: kybaker at redhat.com (Kyle Baker) Date: Fri, 16 May 2014 09:19:56 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <5374C821.60004@redhat.com> References: <5374C821.60004@redhat.com> Message-ID: <19668514.1407315.1400246396767.JavaMail.zimbra@redhat.com> Hey Petr, I would actually say the inverse here. Your second option creates unnecessary nesting which we should avoid if possible. We would only want to go to multiple levels in the nav if the number of items in the nav got unwieldy, we then should categorize. Since there are only two items the simplest and clearest way to display them is as they are in the original screenshot. Kyle ----- Original Message ----- > Just an idea: > > there is only one top level item in self service menu -> no point of > having this level. > > This patch replaces top level with second menu level > > original: > * http://pvoborni.fedorapeople.org/images/self-service-menu-2levels.png > new: > * http://pvoborni.fedorapeople.org/images/self-service-menu-1level.png > -- > Petr Vobornik > From pvoborni at redhat.com Fri May 16 13:47:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 16 May 2014 15:47:21 +0200 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <19668514.1407315.1400246396767.JavaMail.zimbra@redhat.com> References: <5374C821.60004@redhat.com> <19668514.1407315.1400246396767.JavaMail.zimbra@redhat.com> Message-ID: <537616E9.40003@redhat.com> On 16.5.2014 15:19, Kyle Baker wrote: > Hey Petr, I would actually say the inverse here. Your second option > creates unnecessary nesting which we should avoid if possible. We > would only want to go to multiple levels in the nav if the number of > items in the nav got unwieldy, we then should categorize. Since there > are only two items the simplest and clearest way to display them is > as they are in the original screenshot. > > Kyle I'm not sure if I understand you correctly. This patch is *removing* one level of nesting, not creating a new one. From: - Identity -- Users -- OTP Tokens To: - Users - OTP Tokens > > ----- Original Message ----- >> Just an idea: >> >> there is only one top level item in self service menu -> no point >> of having this level. >> >> This patch replaces top level with second menu level >> >> original: * >> http://pvoborni.fedorapeople.org/images/self-service-menu-2levels.png >> >> >> new: * >> http://pvoborni.fedorapeople.org/images/self-service-menu-1level.png >> >> -- >> Petr Vobornik >> -- Petr Vobornik From kybaker at redhat.com Fri May 16 13:58:50 2014 From: kybaker at redhat.com (Kyle Baker) Date: Fri, 16 May 2014 09:58:50 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <537616E9.40003@redhat.com> References: <5374C821.60004@redhat.com> <19668514.1407315.1400246396767.JavaMail.zimbra@redhat.com> <537616E9.40003@redhat.com> Message-ID: <1186937918.1440499.1400248730140.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 16.5.2014 15:19, Kyle Baker wrote: > > Hey Petr, I would actually say the inverse here. Your second option > > creates unnecessary nesting which we should avoid if possible. We > > would only want to go to multiple levels in the nav if the number of > > items in the nav got unwieldy, we then should categorize. Since there > > are only two items the simplest and clearest way to display them is > > as they are in the original screenshot. > > > > Kyle > > I'm not sure if I understand you correctly. > > This patch is *removing* one level of nesting, not creating a new one. > > From: > - Identity > -- Users > -- OTP Tokens > > To: > - Users > - OTP Tokens Ah, sorry about that I got the images switched. This is much better, ACK > > > > > > ----- Original Message ----- > >> Just an idea: > >> > >> there is only one top level item in self service menu -> no point > >> of having this level. > >> > >> This patch replaces top level with second menu level > >> > >> original: * > >> http://pvoborni.fedorapeople.org/images/self-service-menu-2levels.png > >> > >> > >> new: * > >> http://pvoborni.fedorapeople.org/images/self-service-menu-1level.png > >> > >> > -- > >> Petr Vobornik > >> > > > -- > Petr Vobornik > From pviktori at redhat.com Fri May 16 14:33:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 May 2014 16:33:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <5375FC60.40708@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> Message-ID: <537621AB.4040103@redhat.com> On 05/16/2014 01:54 PM, Martin Kosek wrote: > On 04/29/2014 11:00 PM, Petr Viktorin wrote: >> Patch 0540 adds a bunch of managed read ACIs for user, as discussed previously >> [0]. >> >> Patch 0541 is some minor refactoring for the next part. >> >> Patch 0542 sets the read acces to addressbook attributes to anonymous when >> upgrading from pre-4.0. >> I first this by checking if the update is run from ipa-server-install or not, >> but then I realized the logic I want is simple: if the global anon read ACI >> exists, we want to preserve its spirit by setting addressbook attribute ACI to >> anonymous. >> >> >> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et al. >> > > 540: > > Looks good! The only attributes I am concerned about are special IPA attributes: > > - ipauniqueid > - ipasshpubkey > - ipauserauthtype > - userclass > > I personally do not think they should be included in POSIX attributes > permissions, they are far from POSIX definition... > > What about creating one more permission "System: Read User IPA Attributes" as > these are specific to FreeIPA use and allowing that permission for all > authenticated users? Sounds reasonable. I assume we want this one to be also set to anonymous when upgrading from old versions. Attaching updated patches. > 541, 542: > ACK for both, works fine in both new installation and upgrade. > > Martin > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0540.2-Add-managed-read-permissions-to-user.patch Type: text/x-patch Size: 3998 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0541.2-update_managed_permissions-Pass-around-anonymous-ACI.patch Type: text/x-patch Size: 4962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0542.2-Set-user-addressbook-IPA-attribute-read-ACI-to-anony.patch Type: text/x-patch Size: 4174 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 19 12:58:57 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 May 2014 14:58:57 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <20140512174643.60e13a05@unused-4-246.brq.redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> Message-ID: <537A0011.5050207@redhat.com> 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 action dropdown 639 webui-ci: assert_action_list_action 638 webui: use dark color for facet titles without pkey 637 webui: association adder dialog - change find label to filter 636 webui: certificate search - select search attribute only when defined 635 webui: change control buttons to normal buttons 634 webui: add search box placeholder text 633 webui: adjust header controls alignment 628 webui: remove old css for standalone pages 627 webui-ci: select search table item - chrome issue 626 webui: use BS alerts in validation_summary_widget 625 webui: adjust login page to PatternFly 624 webui: preload automember default group select list 623 webui: restyle automember default group 622 webui: do not show empty table footer 621 webui: improve pagination 620 webui: activity indicators 619 webui: adjust association adder dialog to PatternFly 618 webui: patternFly dialog 617 webui: move user reset password action to action dropdown 616 webui: move certificate actions to action dropdown 615 webui: add confirmation to action dropdown actions 614 webui: remove select action 613 webui: add space between action buttons's icon and text 612 webui: add action dropdown 611 webui: remove action list widget 610 webui: use h1 in facet title instead of h3 609 webui: change breadcrumb to PatternFly 608 webui: allow multiple base section layouts 607 webui: display undo and multivalued delete buttons in input-group 606 webui: adjust styles to PatternFly 605 webui: change navigation from RCUE to PatternFly 604 webui: remove column sizing in tables, use PF styles 603 webui: change absolutely positioned layout to fluid 602 webui: remove unused images 601 webui: remove unused collapsible feature from section 600 webui: remove unused icons 599 webui: remove remnants of jquery-ui 598 webui: apply PatternFly theme on migration pages 597 webui: styles for alert icons 596 webui: apply PatternFly theme on config pages 595 webui: apply PatternFly login theme on reset_password.html 594 webui: add PaternFly css 593 webui: remove login.html 592 webui: remove logout.html -- Petr Vobornik From pviktori at redhat.com Mon May 19 13:19:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 May 2014 15:19:48 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <5379E462.2040400@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> Message-ID: <537A04F4.3010906@redhat.com> 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=newemail at 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? From pviktori at redhat.com Mon May 19 13:27:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 May 2014 15:27:00 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A04F4.3010906@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> Message-ID: <537A06A4.2080902@redhat.com> 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=newemail at 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? From pviktori at redhat.com Mon May 19 13:27:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 May 2014 15:27:53 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI In-Reply-To: <5375FDE4.3070400@redhat.com> References: <53601381.9050207@redhat.com> <5375FDE4.3070400@redhat.com> Message-ID: <537A06D9.4010000@redhat.com> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0544.2-Remove-the-global-anonymous-read-ACI.patch Type: text/x-patch Size: 13334 bytes Desc: not available URL: From jcholast at redhat.com Mon May 19 13:54:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 19 May 2014 15:54:37 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A04F4.3010906@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> Message-ID: <537A0D1D.1040900@redhat.com> 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=newemail at 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 From pviktori at redhat.com Mon May 19 13:53:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 May 2014 15:53:17 +0200 Subject: [Freeipa-devel] [PATCH] 0455 Replace "replica admins read access" ACI with a permission In-Reply-To: <537604CC.30404@redhat.com> References: <536113C2.40704@redhat.com> <537604CC.30404@redhat.com> Message-ID: <537A0CCD.2000003@redhat.com> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0545.2-Replace-replica-admins-read-access-ACI-with-a-permis.patch Type: text/x-patch Size: 6506 bytes Desc: not available URL: From tbordaz at redhat.com Mon May 19 14:03:28 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 19 May 2014 16:03:28 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A0D1D.1040900@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> Message-ID: <537A0F30.9030409@redhat.com> 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=newemail at 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.) >> > > From jcholast at redhat.com Mon May 19 14:22:01 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 19 May 2014 16:22:01 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A0F30.9030409@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> Message-ID: <537A1389.6050408@redhat.com> 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=newemail at 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 From tbordaz at redhat.com Mon May 19 14:34:24 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 19 May 2014 16:34:24 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A1389.6050408@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> Message-ID: <537A1670.6050206@redhat.com> 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=newemail at 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.) >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon May 19 14:44:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 19 May 2014 16:44:17 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A1670.6050206@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> Message-ID: <537A18C1.9080702@redhat.com> 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=newemail at 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 From tbordaz at redhat.com Mon May 19 14:45:11 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 19 May 2014 16:45:11 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A18C1.9080702@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> Message-ID: <537A18F7.7010703@redhat.com> 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=newemail at 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.) >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From mkosek at redhat.com Tue May 20 06:08:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 May 2014 08:08:56 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A04F4.3010906@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> Message-ID: <537AF178.8040106@redhat.com> 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=newemail at 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 From mkosek at redhat.com Tue May 20 06:28:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 May 2014 08:28:48 +0200 Subject: [Freeipa-devel] Is CA certificate storage correct? Message-ID: <537AF620.6090802@redhat.com> 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. From jcholast at redhat.com Tue May 20 09:16:15 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 20 May 2014 11:16:15 +0200 Subject: [Freeipa-devel] Is CA certificate storage correct? In-Reply-To: <537AF620.6090802@redhat.com> References: <537AF620.6090802@redhat.com> Message-ID: <537B1D5F.6000305@redhat.com> On 20.5.2014 08:28, Martin Kosek wrote: > 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? There is no such relation, ipaKey* attributes apply to all of the cACertificate attributes. > > 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? No. > > 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? > No. -- Jan Cholasta From pspacek at redhat.com Tue May 20 12:12:30 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 May 2014 14:12:30 +0200 Subject: [Freeipa-devel] [PATCH WIP] DNSSEC key synchronization daemon Message-ID: <537B46AE.70404@redhat.com> Hello, I'm working on DNSSEC key-synchronization daemon for IPA 4.0. At the moment, I have a daemon which is able to read list of zones from LDAP and configure OpenDNSSEC (aka ODS) to generate keys for those zones. Neither the reverse direction ODS->LDAP nor LDAP->BIND synchronization is implemented yet. I would like to hear your opinions on this code: https://github.com/spacekpe/ipadnssecd.git Integration with IPA installer is missing at the moment so you have to install in manually: 1) Read file ods-install: How to configure ODS on IPA server. 2) Read file ipadnssecd-install: How to configure "ipadnssecd" on IPA server. 3) Run keydaemon.py *under ods user*: sudo -u ods ./keydaemon.py It should automatically synchronize list of DNSSEC-enabled zones in LDAP with list of zones managed by ODS. Use command: $ sudo -u ods ods-ksmutil zone list to see list of zones in ODS. Please keep in mind that only zones with attribute idnsSecInlineSigning = TRUE should be present in ODS. I.e. zone should be deleted from ODS if you change attribute idnsSecInlineSigning to FALSE. Synchronization should be near real-time. Thank you for your time! -- Petr^2 Spacek From tbabej at redhat.com Tue May 20 16:15:37 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 20 May 2014 18:15:37 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin Message-ID: <537B7FA9.9000909@redhat.com> Hi, the following set of patches fixes: https://fedorahosted.org/freeipa/ticket/4274 https://fedorahosted.org/freeipa/ticket/4263 https://fedorahosted.org/freeipa/ticket/4324 https://fedorahosted.org/freeipa/ticket/4340 https://fedorahosted.org/freeipa/ticket/4341 and additional minor issues. The improvemed CI test coverage for the sudorule plugin is added as a bonus. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0196-ipatests-test_sudo-Add-tests-for-allowing-hosts-via-.patch Type: text/x-patch Size: 2625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0195-sudorule-Enforce-category-ALL-checks-on-dirsrv-level.patch Type: text/x-patch Size: 4943 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0194-sudorule-Fix-the-order-of-the-parameters-to-have-les.patch Type: text/x-patch Size: 2984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0193-sudorule-Make-sure-all-the-relevant-attributes-are-c.patch Type: text/x-patch Size: 4375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0192-sudorule-Allow-adding-deny-commands-when-command-cat.patch Type: text/x-patch Size: 1176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0191-sudorule-Include-externalhost-and-ipasudorunasextgro.patch Type: text/x-patch Size: 1216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0190-sudorule-Make-sure-sudoRunAsGroup-is-dereferencing-t.patch Type: text/x-patch Size: 2864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0189-sudorule-Allow-using-external-groups-as-groups-of-ru.patch Type: text/x-patch Size: 11320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0188-sudorule-Allow-using-hostmasks-for-setting-allowed-h.patch Type: text/x-patch Size: 13366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0187-sudorule-PEP8-fixes-in-sudorule.py.patch Type: text/x-patch Size: 15215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0197-ipatests-test_sudo-Add-coverage-for-external-entries.patch Type: text/x-patch Size: 6890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0198-ipatests-test_sudo-Add-coverage-for-category-ALL-val.patch Type: text/x-patch Size: 15765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0199-ipatests-test_sudo-Fix-assertions-not-assuming-runas.patch Type: text/x-patch Size: 4708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0200-ipatests-test_sudo-Do-not-expect-enumeration-of-runa.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0201-ipatests-test_sudo-Expect-root-listed-out-if-no-RunA.patch Type: text/x-patch Size: 1544 bytes Desc: not available URL: From rcritten at redhat.com Tue May 20 19:38:42 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 May 2014 15:38:42 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <5374E16D.9050509@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A2226.6080803@redhat.com> <5374E16D.9050509@redhat.com> Message-ID: <537BAF42.5060502@redhat.com> Jan Cholasta wrote: > On 25.4.2014 10:51, Jan Cholasta wrote: >> On 24.4.2014 23:16, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>>> Some in-line, a whole ton of data appended to end. >>>>> >>>>> Jan Cholasta wrote: >>>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> >>>>>>>> 247 >>>>>>>> >>>>>>>> We've been burned by hardcoded timeouts in the past. Should this be >>>>>>>> configurable? This module doesn't currently do any logging but it >>>>>>>> might >>>>>>>> be worth spitting out a "waiting" message, at least for debugging. >>>>>> >>>>>> Added a timeout argument. >>>>> >>>>> Did you forget to send this one, I didn't see an update to 247. >>>> >>>> Are you sure you have 247.1 (now 247.2)? >>>> >>>> I can see at >>>> >>>> that I have sent the correct version of the patches. >>> >>> The call has a timeout, the callers don't use it. I guess it'll do for >>> now, but these almost always come back to bite us. >> >> Well, I can add --certmonger-timeout option to ipa-cacert-manage, if >> that's what you want. >> >>> >>>> >>>>>>>> >>>>>>>> 251 >>>>>>>> >>>>>>>> The tool should provide some feedback while it's running. For the >>>>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>>>> what is >>>>>>>> going on, something in between nothing and full debug output. >>>>>> >>>>>> Added some messages about what's going on. >>>>> >>>>> I dpn't see an update to 251 either. >>>> >>>> Please make sure you have 251.1 (now 251.2). >>> >>> There is a little bit more output but there are still very long periods >>> of waiting between any visual activity, particularly when doing it on an >>> IPA self-signed CA. >> >> This stuff takes time :-) What would you like to see in the output, >> that's not already there? >> >>>>> >>>>> I think the ipa-cacert-manage man page is missing one really important >>>>> piece: why would you ever need to run this? And when? >>>> >>>> Added a paragraph about this. >>> >>> It's better, couple of comments: >>> >>> Add "the" in between renew and CA in "used to manually renew CA >>> certificate of" and "When IPA CA...". >> >> OK. >> >>> I haven't had any luck renewing >>> the CA certificate yet. I see that it is tracked now. I started moving >>> the system clock forward in order to get to renewal and about the 3rd >>> iteration the requests started failing with an XML error. Did you see >>> this? >>> >>> [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most >>> recent call last): >>> [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 344, in >>> wsgi_execute >>> [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = >>> self.Command[name](*args, **options) >>> [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>> __call__ >>> [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = >>> self.run(*args, **options) >>> [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run >>> [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = >>> self.execute(*args, **options) >>> [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 382, in >>> execute >>> [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = >>> api.Command['cert_show'](unicode(serial))['result'] >>> [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>> __call__ >>> [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = >>> self.run(*args, **options) >>> [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run >>> [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = >>> self.execute(*args, **options) >>> [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 514, in >>> execute >>> [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] >>> result=self.Backend.ra.get_certificate(serial_number) >>> [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>> 1502, in get_certificate >>> [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result >>> = self.get_parse_result_xml(http_body, parse_display_cert_xml) >>> [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File >>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>> 1363, in get_parse_result_xml >>> [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = >>> etree.fromstring(xml_text, parser) >>> [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File >>> "lxml.etree.pyx", line 3032, in lxml.etree.fromstring >>> (src/lxml/lxml.etree.c:68129) >>> [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File >>> "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument >>> (src/lxml/lxml.etree.c:102493) >>> [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File >>> "parser.pxi", line 1673, in lxml.etree._parseDoc >>> (src/lxml/lxml.etree.c:101322) >>> [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File >>> "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc >>> (src/lxml/lxml.etree.c:96504) >>> [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File >>> "parser.pxi", line 582, in >>> lxml.etree._ParserContext._handleParseResultDoc >>> (src/lxml/lxml.etree.c:91308) >>> [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File >>> "parser.pxi", line 683, in lxml.etree._handleParseResult >>> (src/lxml/lxml.etree.c:92494) >>> [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File >>> "parser.pxi", line 633, in lxml.etree._raiseParseError >>> (src/lxml/lxml.etree.c:91957) >>> [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: >>> None >>> [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: >>> [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: >>> cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8V! P! >>> > Z! >>> >> gm! >>> >>> 3VCtgMvPVk >>> 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', >>> >>> >>> principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, >>> version=u'2.51'): XMLSyntaxError >> >> I have never seen this. The error message does not say much... Is there >> anything interesting in other logs? > > I was able to get the CA certificate to be renewed after moving system > time forward step by step. > > One thing I haven't noticed before is that the renewed certificate's > validity never exceeds that of the original certificate. This is most > likely Dogtag issue (something along the lines of "certificate validity > cannot exceed validity of the CA certificate", except it shouldn't apply > to the CA certificate itself). > > There were other issues here and there, all of them were caused by race > conditions between concurrent renewals (unreachable CA, XML syntax > errors, etc. because Dogtag was stopped by stop_pkicad in another > request, CMS internal error because it used old subsystem cert to > authenticate to LDAP while the cert was being renewed, etc.) and all of > them could be fixed by restarting relevant IPA services and resubmitting > the requests manually. Some synchronization is really missing there. I hadn't noticed that, but my CA was issued externally so I expected this. I also saw the bumps during renewal but things always tended to smooth out, with the errors generally restricted to restarts and certmonger. This backtrace was the only thing that really stood out. IIRC at this point things were pretty much blocked. In any case, these patches basically seem to work. I never did work out whether the above error was due to dogtag, IPA or something else. rob From mkosek at redhat.com Tue May 20 20:30:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 May 2014 22:30:05 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537B821F.1000901@redhat.com> References: <537B821F.1000901@redhat.com> Message-ID: <537BBB4D.8030000@redhat.com> I am sharing the question below with the list as I think the information is useful and relevant for everyone interested in this feature. See answers in the text. On 05/20/2014 06:26 PM, thierry bordaz wrote: > Hello Martin, Petr, > > I implemented 'user-add --to-stage' in a very simple way. Basically rather > than filling the 'accounts' container it fills the 'staged users' container. > It helped me to start digging into the code. > > Now I am looking at details of this entry. Especially the attributes > present when the entry is in staging container. So far, the entry is > looking like: > > ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" -w > Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb1 > dn: uid=tb1,cn=staged > users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d > c=redhat,dc=com > displayName: tb1 tb1 > cn: tb1 tb1 > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipasshuser > objectClass: ipaSshGroupOfPubKeys > loginShell: /bin/sh > initials: tt > gecos: tb1 tb1 > sn: tb1 > homeDirectory: /home/tb1 > uid: tb1 > mail: tb1 at idm.lab.bos.redhat.com > krbPrincipalName: tb1 at IDM.LAB.BOS.REDHAT.COM > givenName: tb1 > ipaUniqueID: 5556123c-e036-11e3-9915-001a4a104ecd > uidNumber: 646400005 > gidNumber: 646400005 > memberOf: > cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= > com > > > As you can see it contains extra objectclasses and some attributes are set > (like uidNumber or gidNumber). > According to the design that the entry should rather look like: > > > dn: uid=tb1,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d > c=redhat,dc=com > displayName: tb1 tb1 > cn: tb1 tb1 > objectClass: top > objectClass: organizationalperson > objectClass:krbprincipalaux > objectClass: posixaccount > loginShell: autogenerated > sn: tb1 > homeDirectory: /home/tb1 > uid: tb1 > krbPrincipalName: tb1 at IDM.LAB.BOS.REDHAT.COM > uidNumber: -1 > gidNumber: -1 > > Is that correct ? user-add sets the uidNumber and gidNumber to -1, meaning that these numbers should be autogenerated by a plugin. If the plugin scope is updated according to design to disregard staging users container, the number should stay -1 until the entry is really moved to active users container. The same applies for ipaUniqueId, just the generation triggering text is "autogenerate". > Then when the entry get activated ('ipa user-activate tb1 --from-stage), we > should have the attribute being generated > uidNumber/gidNumber/ipaUniqueId... My understanding is that those > attributes should be generate by DS plugins when the entry is moved to > 'accounts' container. So playing with plugin scope would help to have > staged users without all these attributes and 'accounts' users with them. Right. > > What is not clear to me is the chapter related to the 'placeholders'. My > understanding is that it should be a kind of template defining how to fill > attribute values. I am looking for some code/doc dealing with placeholders > but I do not know where to start from. Do you know any pointers on this. I tried to write down the reasons for using placeholders in this section: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholders Placeholder allows provisioning systems to specify only some attributes of for example posixAccount objectclass while not having to fill all the MUST attributes. I think the example with filled "homeDirectory: /home/tuser" tells it all - homeDirectory is filled, other attributes are left for FreeIPA to generate based on it's settings. As for UID and GID, you do not need to do anything - "-1" already means autogenerate the values. Attributes not controlled by a plugin needs to be controlled by the command that moves user from staging users to active users - following list shows how should be the values generated: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholder_Definition HTH, Martin From mkosek at redhat.com Wed May 21 06:03:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 May 2014 08:03:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <537621AB.4040103@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> Message-ID: <537C41A3.2090103@redhat.com> On 05/16/2014 04:33 PM, Petr Viktorin wrote: > On 05/16/2014 01:54 PM, Martin Kosek wrote: >> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed previously >>> [0]. >>> >>> Patch 0541 is some minor refactoring for the next part. >>> >>> Patch 0542 sets the read acces to addressbook attributes to anonymous when >>> upgrading from pre-4.0. >>> I first this by checking if the update is run from ipa-server-install or not, >>> but then I realized the logic I want is simple: if the global anon read ACI >>> exists, we want to preserve its spirit by setting addressbook attribute ACI to >>> anonymous. >>> >>> >>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et >>> al. >>> >> >> 540: >> >> Looks good! The only attributes I am concerned about are special IPA attributes: >> >> - ipauniqueid >> - ipasshpubkey >> - ipauserauthtype >> - userclass >> >> I personally do not think they should be included in POSIX attributes >> permissions, they are far from POSIX definition... >> >> What about creating one more permission "System: Read User IPA Attributes" as >> these are specific to FreeIPA use and allowing that permission for all >> authenticated users? > > Sounds reasonable. I assume we want this one to be also set to anonymous when > upgrading from old versions. > Attaching updated patches. Ok, looks good. I am now just pondering whether "System: Read User POSIX Attributes" is the right name for the permission as there are not just POSIX attributes, but also attributes from organizationalPerson or inetOrgPerson objectclasses. Maybe we should name it "System: Read User Core Attributes" or "System: Read User Basic Attributes"? Simo, any preference? Also, I just realized we forgot memberOf attribute - it needs to be available to authenticated users otherwise group membership will fall apart. > >> 541, 542: >> ACK for both, works fine in both new installation and upgrade. >> >> Martin >> > From mkosek at redhat.com Wed May 21 06:08:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 May 2014 08:08:14 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI In-Reply-To: <537A06D9.4010000@redhat.com> References: <53601381.9050207@redhat.com> <5375FDE4.3070400@redhat.com> <537A06D9.4010000@redhat.com> Message-ID: <537C42CE.3030307@redhat.com> On 05/19/2014 03:27 PM, Petr Viktorin wrote: > 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. I tested upgrade from 3.3.5 to 4.0 and in SUFFIX I still had some of the ACIs left: (targetattr = "*")(target = "ldap:///cn=*,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test")(version 3.0; acl "No anonymous access to roles"; deny (read,search,compare) userdn != "ldap:///all";) (targetattr = "*")(target = "ldap:///cn=*,ou=SUDOers,dc=mkosek-fedora20,dc=test")(version 3.0; acl "No anonymous access to sudo"; deny (read,search,compare) userdn != "ldap:///all";) The problem is that you used your testing suffix instead of suffix variable. Martin From mkosek at redhat.com Wed May 21 06:09:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 May 2014 08:09:23 +0200 Subject: [Freeipa-devel] [PATCH] 0455 Replace "replica admins read access" ACI with a permission In-Reply-To: <537A0CCD.2000003@redhat.com> References: <536113C2.40704@redhat.com> <537604CC.30404@redhat.com> <537A0CCD.2000003@redhat.com> Message-ID: <537C4313.5060402@redhat.com> On 05/19/2014 03:53 PM, Petr Viktorin wrote: > 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. > > Yup, that's better - ACK! Martin From pviktori at redhat.com Wed May 21 08:00:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 May 2014 10:00:35 +0200 Subject: [Freeipa-devel] [PATCH] 0455 Replace "replica admins read access" ACI with a permission In-Reply-To: <537C4313.5060402@redhat.com> References: <536113C2.40704@redhat.com> <537604CC.30404@redhat.com> <537A0CCD.2000003@redhat.com> <537C4313.5060402@redhat.com> Message-ID: <537C5D23.7040806@redhat.com> On 05/21/2014 08:09 AM, Martin Kosek wrote: > On 05/19/2014 03:53 PM, Petr Viktorin wrote: >> 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. >> >> > > Yup, that's better - ACK! Thanks, pushed to master: 86f943ca180a72c4cfa3a8a03226f2471a97981b -- Petr? From pvoborni at redhat.com Wed May 21 08:15:52 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 May 2014 10:15:52 +0200 Subject: [Freeipa-devel] [PATCH] 643 Increase Java stack size for Web UI build on aarch64 Message-ID: <537C60B8.6030506@redhat.com> Fixes build failure on aarch64: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2328356 Successful scratch build: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2332222 One patch is for upstream, second for fedora package. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0643-Increase-Java-stack-size-for-Web-UI-build-on-aarch64.patch Type: text/x-patch Size: 813 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Increase-Java-Stack-size-for-Web-UI-build-on-aarch64.patch Type: text/x-patch Size: 1487 bytes Desc: not available URL: From abokovoy at redhat.com Wed May 21 08:30:09 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 21 May 2014 11:30:09 +0300 Subject: [Freeipa-devel] [PATCH] 643 Increase Java stack size for Web UI build on aarch64 In-Reply-To: <537C60B8.6030506@redhat.com> References: <537C60B8.6030506@redhat.com> Message-ID: <20140521083009.GG23849@redhat.com> On Wed, 21 May 2014, Petr Vobornik wrote: >Fixes build failure on aarch64: >http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2328356 > >Successful scratch build: >http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2332222 > >One patch is for upstream, second for fedora package. ACK. >-- >Petr Vobornik >From 8f1aa5f0160bafb0e79e3b342fda326a194c9cd5 Mon Sep 17 00:00:00 2001 >From: Petr Vobornik >Date: Wed, 21 May 2014 10:06:03 +0200 >Subject: [PATCH] Increase Java stack size for Web UI build on aarch64 > >--- > freeipa.spec.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 2f76c9dde3aeb349956a96687de1f266e38130f6..a6591e208aba495f2ab40f1b1a3d3a4f83b7ce15 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -343,7 +343,7 @@ This package contains tests that verify IPA functionality. > %setup -n freeipa-%{version} -q > > %build >-%ifarch ppc %{power64} s390 s390x >+%ifarch ppc %{power64} s390 s390x aarch64 > # UI compilation segfaulted on some arches when the stack was lower (#1040576) > export JAVA_STACK_SIZE="8m" > %endif >-- >1.9.0 > >From a291203c66c74e37dcf674089745c5a19bd00c6e Mon Sep 17 00:00:00 2001 >From: Petr Vobornik >Date: Wed, 21 May 2014 09:38:23 +0200 >Subject: [PATCH] Increase Java Stack size for Web UI build on aarch64 > >--- > freeipa.spec | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > >diff --git a/freeipa.spec b/freeipa.spec >index 3fa12fa..c5df634 100644 >--- a/freeipa.spec >+++ b/freeipa.spec >@@ -12,7 +12,7 @@ > > Name: freeipa > Version: 3.3.5 >-Release: 2%{?dist} >+Release: 3%{?dist} > Summary: The Identity, Policy and Audit system > > Group: System Environment/Base >@@ -378,7 +378,7 @@ done > # Fedora spec file only: END > > %build >-%ifarch ppc %{power64} s390 s390x >+%ifarch ppc %{power64} s390 s390x aarch64 > # UI compilation segfaulted on some arches when the stack was lower (#1040576) > export JAVA_STACK_SIZE="8m" > %endif >@@ -928,6 +928,9 @@ fi > %endif # ONLY_CLIENT > > %changelog >+* Wed May 21 2014 Petr Vobornik 3.3.5-3 >+- Increase Java stack size for Web UI build on aarch64 >+ > * Wed Apr 16 2014 Peter Robinson 3.3.5-2 > - Add rhino as dependency to fix FTBFS > >@@ -1207,7 +1210,7 @@ fi > - Rebuilt for glibc bug#747377 > > * Wed Oct 19 2011 Alexander Bokovoy - 2.1.3-4 >-- clean up spec >+- clean up spec > - Depend on sssd >= 1.6.2 for better user experience > > * Tue Oct 18 2011 Alexander Bokovoy - 2.1.3-3 >-- >1.9.0 > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy From pspacek at redhat.com Wed May 21 09:33:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 May 2014 11:33:47 +0200 Subject: [Freeipa-devel] [PATCH 0251-0256] Add support for NSEC3 In-Reply-To: <536A34B7.5000400@redhat.com> References: <53601AD2.9070806@redhat.com> <536A34B7.5000400@redhat.com> Message-ID: <537C72FB.5030300@redhat.com> On 7.5.2014 15:27, Petr Spacek wrote: > On 29.4.2014 23:34, Petr Spacek wrote: >> This patch set adds support for NSEC3. See commit messages for details. > > Patch 253 was obsoleted by patches 244v2 and 246v2. > > You can download latest & greatest version from dnssec branch on github: > > https://github.com/spacekpe/bind-dyndb-ldap/tree/dnssec Patch 256v2 removes dead code from zone_master_reconfigure_nsec3param() function. You can download latest & greatest version from dnssec branch on github. This doesn't solve a race condition somewhere in start-up sequence, I'm looking into it. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0256-2-Add-support-for-NSEC3.patch Type: text/x-patch Size: 5015 bytes Desc: not available URL: From ssorce at redhat.com Wed May 21 10:14:02 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 21 May 2014 06:14:02 -0400 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <537C41A3.2090103@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> Message-ID: <1400667242.7561.12.camel@willson.li.ssimo.org> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: > On 05/16/2014 04:33 PM, Petr Viktorin wrote: > > On 05/16/2014 01:54 PM, Martin Kosek wrote: > >> On 04/29/2014 11:00 PM, Petr Viktorin wrote: > >>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed previously > >>> [0]. > >>> > >>> Patch 0541 is some minor refactoring for the next part. > >>> > >>> Patch 0542 sets the read acces to addressbook attributes to anonymous when > >>> upgrading from pre-4.0. > >>> I first this by checking if the update is run from ipa-server-install or not, > >>> but then I realized the logic I want is simple: if the global anon read ACI > >>> exists, we want to preserve its spirit by setting addressbook attribute ACI to > >>> anonymous. > >>> > >>> > >>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et > >>> al. > >>> > >> > >> 540: > >> > >> Looks good! The only attributes I am concerned about are special IPA attributes: > >> > >> - ipauniqueid > >> - ipasshpubkey > >> - ipauserauthtype > >> - userclass > >> > >> I personally do not think they should be included in POSIX attributes > >> permissions, they are far from POSIX definition... > >> > >> What about creating one more permission "System: Read User IPA Attributes" as > >> these are specific to FreeIPA use and allowing that permission for all > >> authenticated users? > > > > Sounds reasonable. I assume we want this one to be also set to anonymous when > > upgrading from old versions. > > Attaching updated patches. > > Ok, looks good. > > I am now just pondering whether "System: Read User POSIX Attributes" is the > right name for the permission as there are not just POSIX attributes, but also > attributes from organizationalPerson or inetOrgPerson objectclasses. > > Maybe we should name it "System: Read User Core Attributes" or "System: Read > User Basic Attributes"? Simo, any preference? We could use: "System: Read User Standard Attributes" but the 'posix' version is also ok to me. Simo. From thozza at redhat.com Wed May 21 11:56:18 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 21 May 2014 13:56:18 +0200 Subject: [Freeipa-devel] [PATCH 0251-0256] Add support for NSEC3 In-Reply-To: <537C72FB.5030300@redhat.com> References: <53601AD2.9070806@redhat.com> <536A34B7.5000400@redhat.com> <537C72FB.5030300@redhat.com> Message-ID: <537C9462.4070400@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/21/2014 11:33 AM, Petr Spacek wrote: > On 7.5.2014 15:27, Petr Spacek wrote: >> On 29.4.2014 23:34, Petr Spacek wrote: >>> This patch set adds support for NSEC3. See commit messages for details. >> >> Patch 253 was obsoleted by patches 244v2 and 246v2. >> >> You can download latest & greatest version from dnssec branch on github: >> >> https://github.com/spacekpe/bind-dyndb-ldap/tree/dnssec > > Patch 256v2 removes dead code from zone_master_reconfigure_nsec3param() > function. > > You can download latest & greatest version from dnssec branch on github. > > This doesn't solve a race condition somewhere in start-up sequence, I'm > looking into it. > Hi. I tested and reviewed patches 244-256 (all latest versions) and tested the https://github.com/spacekpe/bind-dyndb-ldap/tree/dnssec HEAD. Everything works as expected in constraints described in commit messages. There is still a race condition with signing that Petr is aware of and is working on it. (The zone is sometimes not signed if started using systemd). So I'm ACKing the patch-set 244-256 Regards, Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTfJRdAAoJEMWIetUdnzwtzW0H/ifMHoW8p3gapxBxt3nmWtT4 rlGZAU0V9dwO8DAsEM2J73ZIehzoEPOX2c8CGqa3uZwuph9fH4gwqDOfw452ho5B YqfI84hU18ncOHq5TXtu2SiwFqHWZveFATihx4Ds/Cg01KNSWeZ7bHzaaHQOlFOg FFl7CAX5raNgIY97H1nJxs1AfmTWGFDC3oRDpbA1NXIYvWFprri/WNnREFNLTwsW knxdxuS4pVpL9keQJUnQwbFbY12XqdGEhFgT8mwd0B9LEHsk1fTeat/P9rtOPPFF ot81VoJ3bPs5eUZ9TdiyP4Ur6Y0fGfoIMUXTyDJ5/OarkOi+tAZoPLn1Gz60N3E= =AWBQ -----END PGP SIGNATURE----- From thozza at redhat.com Wed May 21 12:07:57 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 21 May 2014 08:07:57 -0400 (EDT) Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <20140227141937.GA32698@mail.corp.redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> Message-ID: <1507577075.4625567.1400674077283.JavaMail.zimbra@redhat.com> ----- Original Message ----- > ehlo, > > I did some reviews of bind-dyndb-ldap last week and it was little bit > annoying > to export special CFLAGS for bind9 header files. It can be automatically > detected in configure script using utility isc-config. > > Attached patch should improve this and CFLAGS needn't be exported. > > LS > ACK. Works like a charm... Thanks! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From tbordaz at redhat.com Wed May 21 14:01:33 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 21 May 2014 16:01:33 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537BBB4D.8030000@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> Message-ID: <537CB1BD.80707@redhat.com> On 05/20/2014 10:30 PM, Martin Kosek wrote: > I am sharing the question below with the list as I think the > information is useful and relevant for everyone interested in this > feature. See answers in the text. > > On 05/20/2014 06:26 PM, thierry bordaz wrote: >> Hello Martin, Petr, >> >> I implemented 'user-add --to-stage' in a very simple way. >> Basically rather >> than filling the 'accounts' container it fills the 'staged users' >> container. >> It helped me to start digging into the code. >> >> Now I am looking at details of this entry. Especially the attributes >> present when the entry is in staging container. So far, the entry is >> looking like: >> >> ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" -w >> Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb1 >> dn: uid=tb1,cn=staged >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d >> c=redhat,dc=com >> displayName: tb1 tb1 >> cn: tb1 tb1 >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: ipasshuser >> objectClass: ipaSshGroupOfPubKeys >> loginShell: /bin/sh >> initials: tt >> gecos: tb1 tb1 >> sn: tb1 >> homeDirectory: /home/tb1 >> uid: tb1 >> mail: tb1 at idm.lab.bos.redhat.com >> krbPrincipalName: tb1 at IDM.LAB.BOS.REDHAT.COM >> givenName: tb1 >> ipaUniqueID: 5556123c-e036-11e3-9915-001a4a104ecd >> uidNumber: 646400005 >> gidNumber: 646400005 >> memberOf: >> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >> com >> >> >> As you can see it contains extra objectclasses and some >> attributes are set >> (like uidNumber or gidNumber). >> According to the design that the entry should rather look like: >> >> >> dn: uid=tb1,cn=staged >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d >> c=redhat,dc=com >> displayName: tb1 tb1 >> cn: tb1 tb1 >> objectClass: top >> objectClass: organizationalperson >> objectClass:krbprincipalaux >> objectClass: posixaccount >> loginShell: autogenerated >> sn: tb1 >> homeDirectory: /home/tb1 >> uid: tb1 >> krbPrincipalName: tb1 at IDM.LAB.BOS.REDHAT.COM >> uidNumber: -1 >> gidNumber: -1 >> >> Is that correct ? > > user-add sets the uidNumber and gidNumber to -1, meaning that these > numbers should be autogenerated by a plugin. If the plugin scope is > updated according to design to disregard staging users container, the > number should stay -1 until the entry is really moved to active users > container. > > The same applies for ipaUniqueId, just the generation triggering text > is "autogenerate". > > >> Then when the entry get activated ('ipa user-activate tb1 >> --from-stage), we >> should have the attribute being generated >> uidNumber/gidNumber/ipaUniqueId... My understanding is that those >> attributes should be generate by DS plugins when the entry is >> moved to >> 'accounts' container. So playing with plugin scope would help to >> have >> staged users without all these attributes and 'accounts' users >> with them. > > Right. > >> >> What is not clear to me is the chapter related to the >> 'placeholders'. My >> understanding is that it should be a kind of template defining >> how to fill >> attribute values. I am looking for some code/doc dealing with >> placeholders >> but I do not know where to start from. Do you know any pointers >> on this. > > I tried to write down the reasons for using placeholders in this section: > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholders > > Placeholder allows provisioning systems to specify only some > attributes of for example posixAccount objectclass while not having to > fill all the MUST attributes. > > I think the example with filled "homeDirectory: /home/tuser" tells it > all - homeDirectory is filled, other attributes are left for FreeIPA > to generate based on it's settings. > > As for UID and GID, you do not need to do anything - "-1" already > means autogenerate the values. Attributes not controlled by a plugin > needs to be controlled by the command that moves user from staging > users to active users - following list shows how should be the values > generated: Hello, Thanks for all these detailed descriptions. Just to be sure to be on the same page, here is my understanding of the provisioning templates and placeholder definitions. An administrator can provide a provisioning template. I suppose it would be a file containing a lines of placeholder definitions. * Where is located the template file ? Is there a standard repository where templates are put ? (somewhere under /etc/ipa/* ?) * Is there an already defined syntax for the provisionning template. ('$' is separator attr/value, %{} is substitute pattern...). If not, is it possible to user ': ' as separator ? * What is the priority. The user can provide the 'homeDirectory' through different methods. Is it ok to use the following order: o the CLI option o the provisionning template o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) For example, if it exists the provisioning template: /etc/ipa/provisioning/shell-user.template roomnumber$-2 homeDirectory$/home/net/shell-%{uid} loginShell$?shell-plugin-autogenerate? the command: ipa user-add tuser --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a staging entry: dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX ... roomNumber: 1234 homeDirectory: /tmp/tuser loginShell: shell-plugin-autogenerate Then a private DS plugin (catching shell-plugin-autogenerate) generate the loginShell value when the entry becomes active. the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would create a staging entry: dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX ... roomNumber: -2 homeDirectory: /tmp/tuser loginShell: shell-plugin-autogenerate the command: ipa user-add tuser --to-stage would create a staging entry: dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX ... roomNumber: -2 homeDirectory: /home/net/shell-tuser loginShell: shell-plugin-autogenerate In case the provisioning template does not define 'homeDirectory', then the created entry would take the value from the ipa config definition: dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX ... roomNumber: -2 homeDirectory: /home/tuser loginShell: shell-plugin-autogenerate best regards thierry > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholder_Definition > > > HTH, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed May 21 16:23:31 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 May 2014 18:23:31 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <535637A5.1020107@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> Message-ID: <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> Updated patches attached Patch 33 removed. Patches should be applied in order: 0029-0032, 0034-0040, 0047, 0041-0042, 0045-0046 -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0029-3-Allows-to-sort-non-text-entries.patch Type: text/x-patch Size: 1845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0030-3-DNSName-type.patch Type: text/x-patch Size: 4157 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0031-3-DNSNameParam-parameter.patch Type: text/x-patch Size: 5363 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0032-3-dns_name_values-capability-added.patch Type: text/x-patch Size: 4482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0034-3-get_ancestors_primary_keys-clone.patch Type: text/x-patch Size: 17348 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0035-3-CLI-conversion-of-DNSName-type.patch Type: text/x-patch Size: 1140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0036-3-DNSName-conversion-in-ipaldap.patch Type: text/x-patch Size: 1744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0037-3-Modified-has_output-attributes.patch Type: text/x-patch Size: 2925 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0038-3-Modified-dns-related-global-functions.patch Type: text/x-patch Size: 15371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0039-3-Modified-records-and-zone-parameters-to-use-DNSNameP.patch Type: text/x-patch Size: 45590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0040-3-Modified-record-and-zone-class-to-support-IDN.patch Type: text/x-patch Size: 27672 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0041-3-_domain_name_validatord-moved-from-DNS-to-realmdomai.patch Type: text/x-patch Size: 2788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0042-3-move-hostname-validation-from-DNS-to-hosts.patch Type: text/x-patch Size: 1840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0045-3-DNS-modified-tests.patch Type: text/x-patch Size: 57143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0046-3-DNS-new-tests.patch Type: text/x-patch Size: 34437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0047-3-PTR-record-target-can-be-relative.patch Type: text/x-patch Size: 4147 bytes Desc: not available URL: From simo at redhat.com Wed May 21 18:14:23 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 21 May 2014 14:14:23 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537CB1BD.80707@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> Message-ID: <1400696063.7561.31.camel@willson.li.ssimo.org> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: > Hello, > > Thanks for all these detailed descriptions. > Just to be sure to be on the same page, here is my understanding of > the provisioning templates and placeholder definitions. An > administrator can provide a provisioning template. I suppose it > would be a file containing a lines of placeholder definitions. > > * Where is located the template file ? Is there a standard > repository where templates are put ? (somewhere under /etc/ipa/* ?) FreeIPA is a multi-master system, a file stored in a file would be extremely cumbersome to use as it would require the admin to manually copy it for every new replica and then keep it in sync. It would also make it hard to change 'on-line'. Placeholders should be defined in an object similar to cn=ipaConfig,cn=etc,$suffix > * Is there an already defined syntax for the provisionning > template. ('$' is separator attr/value, %{} is substitute > pattern...). If not, is it possible to user ': ' as > separator ? Using initial and final ? like in Martin's example doesn't work ? > * What is the priority. The user can provide the 'homeDirectory' > through different methods. Is it ok to use the following order: > o the CLI option > o the provisionning template > o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) > > For example, if it exists the provisioning template: > /etc/ipa/provisioning/shell-user.template > > roomnumber$-2 > homeDirectory$/home/net/shell-%{uid} > loginShell$?shell-plugin-autogenerate? I do not understand this, we are not building a templating engine here, you only have 2 options: 1) a required (MUST) attribute has an explicit value 2) a require (MUST) attribute has a placeholder value the placeholder value is fixed per type, and what it is substituted with uses the same rules as the current code uses to autogenerate values. > the command: ipa user-add tuser > --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a > staging entry: > > dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > ... > roomNumber: 1234 > homeDirectory: /tmp/tuser > loginShell: shell-plugin-autogenerate loginShell is a MAY attribute, not a MUST attribute, so nothing should be stored at all in the staged entry unless explicitly provided for by the admin. > Then a private DS plugin (catching shell-plugin-autogenerate) > generate the loginShell value when the entry becomes active. > > > the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would > create a staging entry: > > dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > ... > roomNumber: -2 > homeDirectory: /tmp/tuser > loginShell: shell-plugin-autogenerate roomNumber is also a MAY, so what would cause it to be set at -2, and why ? > the command: ipa user-add tuser --to-stage would create a staging entry: > > dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > ... > roomNumber: -2 > homeDirectory: /home/net/shell-tuser > loginShell: shell-plugin-autogenerate homeDirectory should be something like: ?placeholder? IMO, we do not really want to play templating here. > In case the provisioning template does not define 'homeDirectory', > then the created entry would take the value from the ipa config > definition: that value should be taken and applied at the time the user is unstaged and brought in the actual tree, not at the time a user is staged. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed May 21 19:06:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 May 2014 21:06:58 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <1400696063.7561.31.camel@willson.li.ssimo.org> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> Message-ID: <537CF952.60301@redhat.com> On 05/21/2014 08:14 PM, Simo Sorce wrote: > On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >> Hello, >> >> Thanks for all these detailed descriptions. >> Just to be sure to be on the same page, here is my understanding of >> the provisioning templates and placeholder definitions. An >> administrator can provide a provisioning template. I suppose it >> would be a file containing a lines of placeholder definitions. >> >> * Where is located the template file ? Is there a standard >> repository where templates are put ? (somewhere under /etc/ipa/* ?) > > FreeIPA is a multi-master system, a file stored in a file would be > extremely cumbersome to use as it would require the admin to manually > copy it for every new replica and then keep it in sync. > It would also make it hard to change 'on-line'. > > Placeholders should be defined in an object similar to > cn=ipaConfig,cn=etc,$suffix > >> * Is there an already defined syntax for the provisionning >> template. ('$' is separator attr/value, %{} is substitute >> pattern...). If not, is it possible to user ': ' as >> separator ? > > Using initial and final ? like in Martin's example doesn't work ? > >> * What is the priority. The user can provide the 'homeDirectory' >> through different methods. Is it ok to use the following order: >> o the CLI option >> o the provisionning template >> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >> >> For example, if it exists the provisioning template: >> /etc/ipa/provisioning/shell-user.template >> >> roomnumber$-2 >> homeDirectory$/home/net/shell-%{uid} >> loginShell$?shell-plugin-autogenerate? > > I do not understand this, we are not building a templating engine here, > you only have 2 options: > 1) a required (MUST) attribute has an explicit value > 2) a require (MUST) attribute has a placeholder value > > the placeholder value is fixed per type, and what it is substituted with > uses the same rules as the current code uses to autogenerate values. > >> the command: ipa user-add tuser >> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >> staging entry: >> >> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >> ... >> roomNumber: 1234 >> homeDirectory: /tmp/tuser >> loginShell: shell-plugin-autogenerate > > loginShell is a MAY attribute, not a MUST attribute, so nothing should > be stored at all in the staged entry unless explicitly provided for by > the admin. > >> Then a private DS plugin (catching shell-plugin-autogenerate) >> generate the loginShell value when the entry becomes active. >> >> >> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would >> create a staging entry: >> >> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >> ... >> roomNumber: -2 >> homeDirectory: /tmp/tuser >> loginShell: shell-plugin-autogenerate > > roomNumber is also a MAY, so what would cause it to be set at -2, and > why ? > >> the command: ipa user-add tuser --to-stage would create a staging entry: >> >> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >> ... >> roomNumber: -2 >> homeDirectory: /home/net/shell-tuser >> loginShell: shell-plugin-autogenerate > > homeDirectory should be something like: ?placeholder? IMO, we do not > really want to play templating here. > >> In case the provisioning template does not define 'homeDirectory', >> then the created entry would take the value from the ipa config >> definition: > > that value should be taken and applied at the time the user is unstaged > and brought in the actual tree, not at the time a user is staged. > > HTH, > Simo. > Hello Thierry and Simo, I think Thierry was confused with this part of the design: " This format of placeholders gives enough space for future enhancements. For example, Administrator could configure a new template "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. Such value would be replaced by "/home/net/tuser if user uid attribute is set to tuser " My intention when writing this design was to enable future use of configurable placeholders, i.e. a value "?someplaceholder?" could be turn into "/custom/path/%{uid}". But I meant that this can be considered as a future enhancement. For now, I think implementing a placeholder "-1" for numerical values and "?autogenerate?" for string ones a good start. Martin From dpal at redhat.com Wed May 21 20:00:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 21 May 2014 16:00:01 -0400 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537A18F7.7010703@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> Message-ID: <537D05C1.3010808@redhat.com> On 05/19/2014 10:45 AM, thierry bordaz wrote: > 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=newemail at 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 I like the idea of different verbs for different hives. Something like: Adding directly to stage via CLI: ipa user-stage Removing from stage: user-unstage (user is gone) Stage to Main -> activate; <- deactivate Main to delete -> del; <-restore or undelete Delete to stage -> I think we can use ipa user-stage command with --deleted=user or similar This is just an example. Pick the commands the way you see fit better but IMO CLI should provide the whole cycle of moving entries around and it should be very unambiguous what each means. Please do not forget to update the design based on the results of this discussion. >>> >>>> >>>>> >>>>> >>>>>> >>>>>>>> >>>>>>>> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed May 21 20:11:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 21 May 2014 16:11:18 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537CF952.60301@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> Message-ID: <537D0866.60706@redhat.com> On 05/21/2014 03:06 PM, Martin Kosek wrote: > On 05/21/2014 08:14 PM, Simo Sorce wrote: >> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>> Hello, >>> >>> Thanks for all these detailed descriptions. >>> Just to be sure to be on the same page, here is my >>> understanding of >>> the provisioning templates and placeholder definitions. An >>> administrator can provide a provisioning template. I suppose it >>> would be a file containing a lines of placeholder definitions. >>> >>> * Where is located the template file ? Is there a standard >>> repository where templates are put ? (somewhere under >>> /etc/ipa/* ?) >> >> FreeIPA is a multi-master system, a file stored in a file would be >> extremely cumbersome to use as it would require the admin to manually >> copy it for every new replica and then keep it in sync. >> It would also make it hard to change 'on-line'. >> >> Placeholders should be defined in an object similar to >> cn=ipaConfig,cn=etc,$suffix >> >>> * Is there an already defined syntax for the provisionning >>> template. ('$' is separator attr/value, %{} is >>> substitute >>> pattern...). If not, is it possible to user ': ' as >>> separator ? >> >> Using initial and final ? like in Martin's example doesn't work ? >> >>> * What is the priority. The user can provide the 'homeDirectory' >>> through different methods. Is it ok to use the following >>> order: >>> o the CLI option >>> o the provisionning template >>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>> >>> For example, if it exists the provisioning template: >>> /etc/ipa/provisioning/shell-user.template >>> >>> roomnumber$-2 >>> homeDirectory$/home/net/shell-%{uid} >>> loginShell$?shell-plugin-autogenerate? >> >> I do not understand this, we are not building a templating engine here, >> you only have 2 options: >> 1) a required (MUST) attribute has an explicit value >> 2) a require (MUST) attribute has a placeholder value >> >> the placeholder value is fixed per type, and what it is substituted with >> uses the same rules as the current code uses to autogenerate values. >> >>> the command: ipa user-add tuser >>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>> staging entry: >>> >>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>> ... >>> roomNumber: 1234 >>> homeDirectory: /tmp/tuser >>> loginShell: shell-plugin-autogenerate >> >> loginShell is a MAY attribute, not a MUST attribute, so nothing should >> be stored at all in the staged entry unless explicitly provided for by >> the admin. >> >>> Then a private DS plugin (catching shell-plugin-autogenerate) >>> generate the loginShell value when the entry becomes active. >>> >>> >>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage >>> would >>> create a staging entry: >>> >>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>> ... >>> roomNumber: -2 >>> homeDirectory: /tmp/tuser >>> loginShell: shell-plugin-autogenerate >> >> roomNumber is also a MAY, so what would cause it to be set at -2, and >> why ? >> >>> the command: ipa user-add tuser --to-stage would create a >>> staging entry: >>> >>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>> ... >>> roomNumber: -2 >>> homeDirectory: /home/net/shell-tuser >>> loginShell: shell-plugin-autogenerate >> >> homeDirectory should be something like: ?placeholder? IMO, we do not >> really want to play templating here. >> >>> In case the provisioning template does not define 'homeDirectory', >>> then the created entry would take the value from the ipa config >>> definition: >> >> that value should be taken and applied at the time the user is unstaged >> and brought in the actual tree, not at the time a user is staged. >> >> HTH, >> Simo. >> > > Hello Thierry and Simo, > > I think Thierry was confused with this part of the design: > > " > This format of placeholders gives enough space for future > enhancements. For example, Administrator could configure a new > template "myhomedirtemplate$/home/net/%{uid}" and use it in the staged > LDAP entry. Such value would be replaced by "/home/net/tuser if user > uid attribute is set to tuser > " > > My intention when writing this design was to enable future use of > configurable placeholders, i.e. a value "?someplaceholder?" could be > turn into "/custom/path/%{uid}". But I meant that this can be > considered as a future enhancement. For now, I think implementing a > placeholder "-1" for numerical values and "?autogenerate?" for string > ones a good start. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please consider the flow: user added staged -> activated/moved to main tree -> deleted/moved to deleted tree -> staged back At the first step his IPA user ID and UID should be undefined and autogenerated. On the last step his IPAUserID and UID should be preserved. The main use case is that this is the user who left the company who comes back again. His files should be still owned by him unless admin forces a flush of his IDs (new switch???) when he moves user from deleted to staged. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From tbordaz at redhat.com Thu May 22 07:51:10 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 22 May 2014 09:51:10 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537CF952.60301@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> Message-ID: <537DAC6E.1030505@redhat.com> On 05/21/2014 09:06 PM, Martin Kosek wrote: > On 05/21/2014 08:14 PM, Simo Sorce wrote: >> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>> Hello, >>> >>> Thanks for all these detailed descriptions. >>> Just to be sure to be on the same page, here is my >>> understanding of >>> the provisioning templates and placeholder definitions. An >>> administrator can provide a provisioning template. I suppose it >>> would be a file containing a lines of placeholder definitions. >>> >>> * Where is located the template file ? Is there a standard >>> repository where templates are put ? (somewhere under >>> /etc/ipa/* ?) >> >> FreeIPA is a multi-master system, a file stored in a file would be >> extremely cumbersome to use as it would require the admin to manually >> copy it for every new replica and then keep it in sync. >> It would also make it hard to change 'on-line'. >> >> Placeholders should be defined in an object similar to >> cn=ipaConfig,cn=etc,$suffix >> >>> * Is there an already defined syntax for the provisionning >>> template. ('$' is separator attr/value, %{} is >>> substitute >>> pattern...). If not, is it possible to user ': ' as >>> separator ? >> >> Using initial and final ? like in Martin's example doesn't work ? >> >>> * What is the priority. The user can provide the 'homeDirectory' >>> through different methods. Is it ok to use the following >>> order: >>> o the CLI option >>> o the provisionning template >>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>> >>> For example, if it exists the provisioning template: >>> /etc/ipa/provisioning/shell-user.template >>> >>> roomnumber$-2 >>> homeDirectory$/home/net/shell-%{uid} >>> loginShell$?shell-plugin-autogenerate? >> >> I do not understand this, we are not building a templating engine here, >> you only have 2 options: >> 1) a required (MUST) attribute has an explicit value >> 2) a require (MUST) attribute has a placeholder value >> >> the placeholder value is fixed per type, and what it is substituted with >> uses the same rules as the current code uses to autogenerate values. >> >>> the command: ipa user-add tuser >>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>> staging entry: >>> >>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>> ... >>> roomNumber: 1234 >>> homeDirectory: /tmp/tuser >>> loginShell: shell-plugin-autogenerate >> >> loginShell is a MAY attribute, not a MUST attribute, so nothing should >> be stored at all in the staged entry unless explicitly provided for by >> the admin. >> >>> Then a private DS plugin (catching shell-plugin-autogenerate) >>> generate the loginShell value when the entry becomes active. >>> >>> >>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage >>> would >>> create a staging entry: >>> >>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>> ... >>> roomNumber: -2 >>> homeDirectory: /tmp/tuser >>> loginShell: shell-plugin-autogenerate >> >> roomNumber is also a MAY, so what would cause it to be set at -2, and >> why ? >> >>> the command: ipa user-add tuser --to-stage would create a >>> staging entry: >>> >>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>> ... >>> roomNumber: -2 >>> homeDirectory: /home/net/shell-tuser >>> loginShell: shell-plugin-autogenerate >> >> homeDirectory should be something like: ?placeholder? IMO, we do not >> really want to play templating here. >> >>> In case the provisioning template does not define 'homeDirectory', >>> then the created entry would take the value from the ipa config >>> definition: >> >> that value should be taken and applied at the time the user is unstaged >> and brought in the actual tree, not at the time a user is staged. >> >> HTH, >> Simo. >> > > Hello Thierry and Simo, > > I think Thierry was confused with this part of the design: > > " > This format of placeholders gives enough space for future > enhancements. For example, Administrator could configure a new > template "myhomedirtemplate$/home/net/%{uid}" and use it in the staged > LDAP entry. Such value would be replaced by "/home/net/tuser if user > uid attribute is set to tuser > " > > My intention when writing this design was to enable future use of > configurable placeholders, i.e. a value "?someplaceholder?" could be > turn into "/custom/path/%{uid}". But I meant that this can be > considered as a future enhancement. For now, I think implementing a > placeholder "-1" for numerical values and "?autogenerate?" for string > ones a good start. > > Martin Hello Martin and Simo, Thanks for your feedbacks. I liked the idea of configurable placeholders and I was thinking it already existed a kind of template engine that I had to follow. Now I understand that in a first step, I have to make it run only with '-1|?autogenerate?' placeholders and for MUST attribute only. Sorry for the confusion. Thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu May 22 08:37:16 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 22 May 2014 10:37:16 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check In-Reply-To: <536A4519.3080601@redhat.com> References: <536A3985.20502@redhat.com> <536A3CB2.6060408@redhat.com> <536A42A1.4070803@redhat.com> <536A436C.10206@redhat.com> <536A4519.3080601@redhat.com> Message-ID: <537DB73C.2020304@redhat.com> On 05/07/2014 04:37 PM, Petr Vobornik wrote: > On 7.5.2014 16:30, Tomas Babej wrote: >> >> On 05/07/2014 04:26 PM, Petr Vobornik wrote: >>> On 7.5.2014 16:01, Tomas Babej wrote: >>>> >>>> On 05/07/2014 03:47 PM, Petr Vobornik wrote: >>>>> krbpasswordexpiration conversion to number of second since epoch >>>>> failed >>>>> because now we get datetime object instead of string. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4339 >>>>> >>>>> >>>> NACK, I don't think this is the right approach. This does not leverage >>>> the simplicity which the DateTime parameter refactoring provides. >>>> >>>> Instead of converting the datetime to the number of the seconds since >>>> epoch, and getting the current time represented by the number of >>>> seconds >>>> since the epoch (using time.time()), why not use datetime module and >>>> datetime.datetime.now() to get the current time? >>>> >>>> Then you could simplify this: >>>> >>>> + exp = time.mktime(expiration.timetuple()) >>>> + if exp <= time.time(): >>>> >>>> to this: >>>> >>>> + if expiration <= datetime.datetime.now() >>>> >>> >>> Good point, fixed >>> >> >> Can you also please remove the (now) unused import for module time? >> > done > ACK. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Thu May 22 08:47:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 10:47:14 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537D05C1.3010808@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> Message-ID: <537DB992.3050900@redhat.com> On 05/21/2014 10:00 PM, Dmitri Pal wrote: > On 05/19/2014 10:45 AM, thierry bordaz wrote: >> 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=newemail at 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 > > > I like the idea of different verbs for different hives. > Something like: > > Adding directly to stage via CLI: ipa user-stage > Removing from stage: user-unstage (user is gone) > Stage to Main -> activate; <- deactivate > Main to delete -> del; <-restore or undelete > Delete to stage -> I think we can use ipa user-stage command with > --deleted=user or similar To be honest, I don't like this idea. Too many names are confusing, if we can find a consistent option to cut the number of names down we should do it. IMO This is the worst part of Git: http://assets.osteele.com/images/2008/git-transport.png . We can do better. Another good thing would be if options did not affect the applicability of other options (too much). For example in your proposal there'd be something like: ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... ipa user-stage --deleted=tuser # We should avoid this, if only for the reason that it makes the help text confusing. My proposal would be that the move commands use the verb for the target and an option for the source, and add/mod use an option for the container: 1) adding a new user (to active) ipa user-add tuser ... (to stage) ipa user-add tuser --staged ... (to deleted) ipa user-add tuser --deleted ... (*) 2) moving to main (from stage) ipa user-activate tuser (**) (from del) ipa user-activate tuser --deleted 3) moving to deleted (from active) ipa user-del tuser (from stage) ipa user-del tuser --staged 4) moving to stage (from active) ipa user-stage tuser (from del) ipa user-stage tuser --deleted 5) modifying (in active) ipa user-mod tuser ... (in stage) ipa user-mod tuser --staged ... (in del) ipa user-mod tuser --deleted ... Five commands (two of which are user-specific), plus two fairly consistent options. If the delete container isn't configured, the --deleted option is illegal and `user-del` deletes permanently. (*) may be useful in some situations? (**) for full consistency this would be `ipa user-activate --staged`, but this is a good exception to make. > This is just an example. Pick the commands the way you see fit better > but IMO CLI should provide the whole cycle of moving entries around and > it should be very unambiguous what each means. > > Please do not forget to update the design based on the results of this > discussion. > > > > > >>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Petr? From pviktori at redhat.com Thu May 22 13:07:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 15:07:47 +0200 Subject: [Freeipa-devel] [PATCH] 0550 ipalib.cli: Add filename argument to ipa console Message-ID: <537DF6A3.8020000@redhat.com> Hello, I find the `ipa console` command quite useful for testing, and it's bothered me that it can't execute a script. Fixing this helps me. Would it help anyone else? This would need a ticket + design doc before it's pushed. Compare: $ (echo 'print 1'; echo 'print 2') | ipa console (Custom IPA interactive Python console) >>> 1 >>> 2 >>> [no newline] $ ipa console <(echo 'print 1'; echo 'print 2') 1 2 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0550-ipalib.cli-Add-filename-argument-to-ipa-console.patch Type: text/x-patch Size: 1923 bytes Desc: not available URL: From pviktori at redhat.com Thu May 22 13:07:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 15:07:48 +0200 Subject: [Freeipa-devel] [PATCH] 0551 ldap2.find_entries: Do not modify attrs_list in-place Message-ID: <537DF6A4.2020806@redhat.com> This fixes https://fedorahosted.org/freeipa/ticket/4349. See the ticket for a description. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0551-ldap2.find_entries-Do-not-modify-attrs_list-in-place.patch Type: text/x-patch Size: 2016 bytes Desc: not available URL: From pviktori at redhat.com Thu May 22 13:07:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 15:07:50 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions Message-ID: <537DF6A6.7020001@redhat.com> Hello, Here I start upgrading the existing default permissions to the new Managed style. https://fedorahosted.org/freeipa/ticket/4346 The patches rely on my patch 0551 (https://fedorahosted.org/freeipa/ticket/4349) You may run into what seems to be a 389 bug. If you get a "Midair Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running ipa-ldap-updater again. I'm working with Ludwig on this one. The operation is now described at http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions If there user has modified an old default permission, a warning is logged the replacement permission is not added/updated. The user needs to evaluate the situation: either update the old permission to match the original default, or remove the old permission, and then run ipa-ldap-updater will create the new one. Is bailing out the right thing to do if the old entry was modified? It could be possible to parse the permission, figure out the changes the user made, and apply them to the new one, but that seems like too much guesswork to me. On the other hand, my approach has a downside as well: if the 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's now no way to upgrade while allowing access but keeping that attribute off-limits, short of writing deny a ACI by hand. How big a problem is this? It might be worth it to create a special tool that upgrades a single permission and allows setting the excluded/included attributes explicitly. There are some interesting scenarios to think about with respect to upgrades and user changes: * Upgrade to old version, e.g. - have IPA 3.2 master, IPA 3.2 replica - upgrade master to 4.0 (old permissions are updated) - then upgrade replica to 3.3 (old permissions are added again!) This is AFAIK not supported but it does happen. We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will always add the old permissions, but with this patch, a subsequent upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old permissions again. Tied to that is another scenario: * Re-create permissions with old names - have IPA 4.0 master - Create a permission named 'Modify Sudo rule' - Upgrade to IPA 4.1 Here we need to make sure the new permission is *not* removed, because a new 'Modify Sudo rule' permission is no longer special in any way. To ensure this the updater only removes old-style permissions. One thing that can happen when 4.0 masters are still mixed with 3.x is that an old permission named 'Modify Sudo rule' is added on the old server. Any update to 4.0+ will remove that. Old-style default permissions were sorta-kinda managed by IPA itself anyway, so users should expect this. We should still point it out in the docs though, since I expect some users to start messing with the permissions before upgrading all of the infrastructure to 4.0. The second patch upgrades sudorule permissions, this server as an example of how the will work. The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0552-Add-mechanism-for-updating-permissions-to-managed.patch Type: text/x-patch Size: 5457 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0553-Convert-Sudo-rule-default-permissions-to-managed.patch Type: text/x-patch Size: 6658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0554-Add-missing-attributes-to-Modify-Sudo-rule-permissio.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: From jcholast at redhat.com Thu May 22 13:36:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 22 May 2014 15:36:21 +0200 Subject: [Freeipa-devel] [PATCH] 0551 ldap2.find_entries: Do not modify attrs_list in-place In-Reply-To: <537DF6A4.2020806@redhat.com> References: <537DF6A4.2020806@redhat.com> Message-ID: <537DFD55.4030607@redhat.com> On 22.5.2014 15:07, Petr Viktorin wrote: > This fixes https://fedorahosted.org/freeipa/ticket/4349. > > See the ticket for a description. Looks OK to me, ACK. -- Jan Cholasta From mkosek at redhat.com Thu May 22 13:35:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 May 2014 15:35:29 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537D0866.60706@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> Message-ID: <537DFD21.7040704@redhat.com> On 05/21/2014 10:11 PM, Dmitri Pal wrote: > On 05/21/2014 03:06 PM, Martin Kosek wrote: >> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>> Hello, >>>> >>>> Thanks for all these detailed descriptions. >>>> Just to be sure to be on the same page, here is my understanding of >>>> the provisioning templates and placeholder definitions. An >>>> administrator can provide a provisioning template. I suppose it >>>> would be a file containing a lines of placeholder definitions. >>>> >>>> * Where is located the template file ? Is there a standard >>>> repository where templates are put ? (somewhere under /etc/ipa/* ?) >>> >>> FreeIPA is a multi-master system, a file stored in a file would be >>> extremely cumbersome to use as it would require the admin to manually >>> copy it for every new replica and then keep it in sync. >>> It would also make it hard to change 'on-line'. >>> >>> Placeholders should be defined in an object similar to >>> cn=ipaConfig,cn=etc,$suffix >>> >>>> * Is there an already defined syntax for the provisionning >>>> template. ('$' is separator attr/value, %{} is substitute >>>> pattern...). If not, is it possible to user ': ' as >>>> separator ? >>> >>> Using initial and final ? like in Martin's example doesn't work ? >>> >>>> * What is the priority. The user can provide the 'homeDirectory' >>>> through different methods. Is it ok to use the following order: >>>> o the CLI option >>>> o the provisionning template >>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>>> >>>> For example, if it exists the provisioning template: >>>> /etc/ipa/provisioning/shell-user.template >>>> >>>> roomnumber$-2 >>>> homeDirectory$/home/net/shell-%{uid} >>>> loginShell$?shell-plugin-autogenerate? >>> >>> I do not understand this, we are not building a templating engine here, >>> you only have 2 options: >>> 1) a required (MUST) attribute has an explicit value >>> 2) a require (MUST) attribute has a placeholder value >>> >>> the placeholder value is fixed per type, and what it is substituted with >>> uses the same rules as the current code uses to autogenerate values. >>> >>>> the command: ipa user-add tuser >>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>>> staging entry: >>>> >>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>> ... >>>> roomNumber: 1234 >>>> homeDirectory: /tmp/tuser >>>> loginShell: shell-plugin-autogenerate >>> >>> loginShell is a MAY attribute, not a MUST attribute, so nothing should >>> be stored at all in the staged entry unless explicitly provided for by >>> the admin. >>> >>>> Then a private DS plugin (catching shell-plugin-autogenerate) >>>> generate the loginShell value when the entry becomes active. >>>> >>>> >>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would >>>> create a staging entry: >>>> >>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>> ... >>>> roomNumber: -2 >>>> homeDirectory: /tmp/tuser >>>> loginShell: shell-plugin-autogenerate >>> >>> roomNumber is also a MAY, so what would cause it to be set at -2, and >>> why ? >>> >>>> the command: ipa user-add tuser --to-stage would create a staging entry: >>>> >>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>> ... >>>> roomNumber: -2 >>>> homeDirectory: /home/net/shell-tuser >>>> loginShell: shell-plugin-autogenerate >>> >>> homeDirectory should be something like: ?placeholder? IMO, we do not >>> really want to play templating here. >>> >>>> In case the provisioning template does not define 'homeDirectory', >>>> then the created entry would take the value from the ipa config >>>> definition: >>> >>> that value should be taken and applied at the time the user is unstaged >>> and brought in the actual tree, not at the time a user is staged. >>> >>> HTH, >>> Simo. >>> >> >> Hello Thierry and Simo, >> >> I think Thierry was confused with this part of the design: >> >> " >> This format of placeholders gives enough space for future enhancements. For >> example, Administrator could configure a new template >> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. >> Such value would be replaced by "/home/net/tuser if user uid attribute is set >> to tuser >> " >> >> My intention when writing this design was to enable future use of >> configurable placeholders, i.e. a value "?someplaceholder?" could be turn >> into "/custom/path/%{uid}". But I meant that this can be considered as a >> future enhancement. For now, I think implementing a placeholder "-1" for >> numerical values and "?autogenerate?" for string ones a good start. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Please consider the flow: user added staged -> activated/moved to main tree -> > deleted/moved to deleted tree -> staged back > At the first step his IPA user ID and UID should be undefined and autogenerated. > On the last step his IPAUserID and UID should be preserved. The main use case > is that this is the user who left the company who comes back again. His files > should be still owned by him unless admin forces a flush of his IDs (new > switch???) when he moves user from deleted to staged. > Right, the life-cycle feature should work like that naturally, given that only attributes with "-1" or "autogenerate" are generated. If admin wants to re-generate the IDs, all he would need to do is to change the attributes back to "-1" after/before moving the user to staging. Question is when it should be done (in deleted tree, in staging tree or after activation) and what API/command we choose. Admin may want to change not only the UID/GID, but maybe also a home directory (user may be in a different department) so we should make it general. Maybe we should let user-mod support modification in staging area? Like $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged or $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted Martin From pviktori at redhat.com Thu May 22 14:03:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 16:03:41 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI In-Reply-To: <537C42CE.3030307@redhat.com> References: <53601381.9050207@redhat.com> <5375FDE4.3070400@redhat.com> <537A06D9.4010000@redhat.com> <537C42CE.3030307@redhat.com> Message-ID: <537E03BD.8070505@redhat.com> On 05/21/2014 08:08 AM, Martin Kosek wrote: > On 05/19/2014 03:27 PM, Petr Viktorin wrote: >> 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. > > I tested upgrade from 3.3.5 to 4.0 and in SUFFIX I still had some of the ACIs left: > > (targetattr = "*")(target = > "ldap:///cn=*,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test")(version 3.0; > acl "No anonymous access to roles"; deny (read,search,compare) userdn != > "ldap:///all";) > > (targetattr = "*")(target = > "ldap:///cn=*,ou=SUDOers,dc=mkosek-fedora20,dc=test")(version 3.0; acl "No > anonymous access to sudo"; deny (read,search,compare) userdn != "ldap:///all";) > > The problem is that you used your testing suffix instead of suffix variable. Shame on me. I've updated & rebased the patch. I've also made a git hook yell at me when I commit something containing "BRQ", hopefully this won't happen again. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0544.3-Remove-the-global-anonymous-read-ACI.patch Type: text/x-patch Size: 12789 bytes Desc: not available URL: From npmccallum at redhat.com Thu May 22 14:06:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 10:06:46 -0400 Subject: [Freeipa-devel] [PATCH] 0550 ipalib.cli: Add filename argument to ipa console In-Reply-To: <537DF6A3.8020000@redhat.com> References: <537DF6A3.8020000@redhat.com> Message-ID: <1400767606.2964.2.camel@ipa.example.com> On Thu, 2014-05-22 at 15:07 +0200, Petr Viktorin wrote: > Hello, > I find the `ipa console` command quite useful for testing, and it's > bothered me that it can't execute a script. Fixing this helps me. Would > it help anyone else? > > This would need a ticket + design doc before it's pushed. > > > Compare: > $ (echo 'print 1'; echo 'print 2') | ipa console > (Custom IPA interactive Python console) > >>> 1 > >>> 2 > > >>> [no newline] > > $ ipa console <(echo 'print 1'; echo 'print 2') > 1 > 2 Looks helpful to me. ACK Also, FTR, at first I thought it looked weird to have the open() outside of the with statement. But this is because you only want to catch the IOError during the open() operation. So the behavior in this patch is correct. Nathaniel From npmccallum at redhat.com Thu May 22 14:12:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 10:12:03 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1400000119.2512.11.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> Message-ID: <1400767923.2964.3.camel@ipa.example.com> On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: > On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: > > On 12.5.2014 20:50, Nathaniel McCallum wrote: > > > On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: > > >> On Tue, 06 May 2014 11:46:14 -0400 > > >> Nathaniel McCallum wrote: > > >> > > >>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > > >>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > > >>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: > > >>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > > >>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: > > >>>>>>>> Specifying the default in the LDAP Object causes the > > >>>>>>>> parameter to be specified for non-add operations. This is > > >>>>>>>> especially problematic when performing the modify operation > > >>>>>>>> as it causes the primary key to change for every modification. > > >>>>>>>> > > >>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 > > >>>>>>>> > > >>>>>>> > > >>>>>>> shouldn't removal of `autofill=True,` be enough? > > >>>>>> > > >>>>>> Removing autofill=True results in the default not being used > > >>>>>> for the otptoken-add operation. That may be a different bug > > >>>>>> (I'm not sure what the expectation of autofill is). > > >>>>>> > > >>>>>> Nathaniel > > >>>>>> > > >>>>> > > >>>>> Seems to work form me with: > > >>>>> > > >>>>> diff --git a/ipalib/plugins/otptoken.py > > >>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > > >>>>> --- a/ipalib/plugins/otptoken.py > > >>>>> +++ b/ipalib/plugins/otptoken.py > > >>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > > >>>>> cli_name='id', > > >>>>> label=_('Unique ID'), > > >>>>> default_from=lambda: unicode(uuid.uuid4()), > > >>>>> - autofill=True, > > >>>>> primary_key=True, > > >>>>> - flags=('optional_create'), > > >>>>> ), > > >>>>> StrEnum('type?', > > >>>>> label=_('Type'), > > >>>> > > >>>> Doing this causes the ipa otptoken-add command to prompt for the > > >>>> Unique ID. This may be the desired behavior, but it is not how it > > >>>> worked previously (no prompt). > > >>> > > >>> Here is an alternate patch for this second approach. I have no strong > > >>> opinion on the correct behavior here. > > >>> > > >>> Nathaniel > > >> > > >> IMO you should update API.txt with ./makeapi > > > > > > Running ./makeapi results in no changes to API.txt. > > > > This is not right, there *are* changes in the API and build fails for me > > becase API.txt is not updated. > > I think maybe I ran it from the wrong branch. Fixed. I still need a review of this. It is pretty trivial. Nathaniel From pviktori at redhat.com Thu May 22 14:20:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 16:20:09 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <1400667242.7561.12.camel@willson.li.ssimo.org> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> Message-ID: <537E0799.2000408@redhat.com> On 05/21/2014 12:14 PM, Simo Sorce wrote: > On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >> On 05/16/2014 04:33 PM, Petr Viktorin wrote: >>> On 05/16/2014 01:54 PM, Martin Kosek wrote: >>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>>>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed previously >>>>> [0]. >>>>> >>>>> Patch 0541 is some minor refactoring for the next part. >>>>> >>>>> Patch 0542 sets the read acces to addressbook attributes to anonymous when >>>>> upgrading from pre-4.0. >>>>> I first this by checking if the update is run from ipa-server-install or not, >>>>> but then I realized the logic I want is simple: if the global anon read ACI >>>>> exists, we want to preserve its spirit by setting addressbook attribute ACI to >>>>> anonymous. >>>>> >>>>> >>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et >>>>> al. >>>>> >>>> >>>> 540: >>>> >>>> Looks good! The only attributes I am concerned about are special IPA attributes: >>>> >>>> - ipauniqueid >>>> - ipasshpubkey >>>> - ipauserauthtype >>>> - userclass >>>> >>>> I personally do not think they should be included in POSIX attributes >>>> permissions, they are far from POSIX definition... >>>> >>>> What about creating one more permission "System: Read User IPA Attributes" as >>>> these are specific to FreeIPA use and allowing that permission for all >>>> authenticated users? >>> >>> Sounds reasonable. I assume we want this one to be also set to anonymous when >>> upgrading from old versions. >>> Attaching updated patches. >> >> Ok, looks good. >> >> I am now just pondering whether "System: Read User POSIX Attributes" is the >> right name for the permission as there are not just POSIX attributes, but also >> attributes from organizationalPerson or inetOrgPerson objectclasses. >> >> Maybe we should name it "System: Read User Core Attributes" or "System: Read >> User Basic Attributes"? Simo, any preference? > > We could use: "System: Read User Standard Attributes" I've used this one, then. > > but the 'posix' version is also ok to me. On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: > Also, I just realized we forgot memberOf attribute - it needs to be available > to authenticated users otherwise group membership will fall apart. Good catch. Added. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0540.3-Add-managed-read-permissions-to-user.patch Type: text/x-patch Size: 4293 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0541.3-update_managed_permissions-Pass-around-anonymous-ACI.patch Type: text/x-patch Size: 4962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0542.3-Set-user-addressbook-IPA-attribute-read-ACI-to-anony.patch Type: text/x-patch Size: 4174 bytes Desc: not available URL: From npmccallum at redhat.com Thu May 22 14:21:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 10:21:17 -0400 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <1399471569.3786.9.camel@ipa.example.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> <1399388863.9864.1.camel@ipa.example.com> <536A3B30.3080206@redhat.com> <1399471569.3786.9.camel@ipa.example.com> Message-ID: <1400768477.2964.4.camel@ipa.example.com> I still need a review on this. On Wed, 2014-05-07 at 10:06 -0400, Nathaniel McCallum wrote: > On Wed, 2014-05-07 at 15:54 +0200, Petr Vobornik wrote: > > On 6.5.2014 17:07, Nathaniel McCallum wrote: > > > On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote: > > >> On 6.5.2014 15:16, Nathaniel McCallum wrote: > > >>> On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: > > >>>> Hi, > > >>>> > > >>>> On 5.5.2014 18:40, Nathaniel McCallum wrote: > > >>>>> Creating tokens for yourself is the most common operation. Making this > > >>>>> the default optimizes for the common case. > > >>>> > > >>>> The user-find call should be inside the if statement. > > >>> > > >>> This is actually for a reason. See my patch 0049 for further context. > > >> > > >> IMO something like this would be better: > > >> > > >> if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in > > >> entry_attrs: > > >> result = self.api.Command.user_find(whoami=True)['result'] > > >> if result: > > >> cur_uid = result[0]['uid'][0] > > >> prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) > > >> if cur_uid != prev_uid: > > >> entry_attrs.setdefault('ipatokenprotected', True) > > > > > > Fixed (see also my new revision of patch 0049). > > > > > > Nathaniel > > > > > > > I assume that this won't allow to create a token without an owner. Do we > > want to have this restriction? > > > > Usecase: import a batch of hw tokens > > This case is currently very much on my radar (I'm finishing the import > script now). To set no owner, just use --owner="". We are testing for > key presence here, not the value of the key. So if the key is present > with an empty value, no owner will be set. > > FYI, the import format (RFC 6030) also permits a mechanism for declaring > ownership in DN format. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Thu May 22 14:30:55 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 10:30:55 -0400 Subject: [Freeipa-devel] [PATCH 0047] kdb: Don't provide password expiration when using only RADIUS In-Reply-To: <1399067343.2321.11.camel@localhost.localdomain> References: <1399067343.2321.11.camel@localhost.localdomain> Message-ID: <1400769055.2964.5.camel@ipa.example.com> On Fri, 2014-05-02 at 17:49 -0400, Nathaniel McCallum wrote: > If the KDC doesn't use the FreeIPA password for authentication, then it > is futile to provide this information. Doing so will only confuse the > user. It also causes password change dialogues when the password is > irrelevant. > > https://fedorahosted.org/freeipa/ticket/4299 This new version fixes a small logic bug. This should be an easy review. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0047.1-kdb-Don-t-provide-password-expiration-when-using-onl.patch Type: text/x-patch Size: 1239 bytes Desc: not available URL: From tbordaz at redhat.com Thu May 22 14:33:14 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 22 May 2014 16:33:14 +0200 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users Message-ID: <537E0AAA.5090100@redhat.com> Hello, In order to provision staged users (account inactivated) with there initial values: /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 ----------------- Added user "tb20" ----------------- User login: tb20 First name: tb20 Last name: tb20 Full name: tb20 tb20 Display name: tb20 tb20 Initials: tt Home directory: /home/tb20 GECOS: tb20 tb20 Login shell: /bin/sh Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM Email address: tb20 at idm.lab.bos.redhat.com UID: -1 GID: -1 Account disabled: true Password: False Kerberos keys available: False ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: tb20 at idm.lab.bos.redhat.com krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM givenName: tb20 initials: tt I needed to resctrict the scope of the following plugins: dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config nsslapd-pluginarg1: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=MemberOf Plugin,cn=plugins,cn=config memberofentryscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com In fact I need them to not modify the added entry when it is added under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". Now is it possible to limit those plugins scope to the 'cn=accounts' part of the tree ? I guess not. If it is not possible, a solution is to make the scope multi-valued attributes or to introduce a new config attribute '*notInScope' also multi-valued. A problem is the 'cn=ipaUniqueID uniqueness' that rely on the 'attribute uniqueness' plugin with a argv[ ], not really convenient to pass 2 multivalued attributes. If anyone is having others solutions it would help me a lot :-) thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu May 22 14:38:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 May 2014 16:38:44 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537DB992.3050900@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> Message-ID: <537E0BF4.4040806@redhat.com> On 05/22/2014 10:47 AM, Petr Viktorin wrote: > On 05/21/2014 10:00 PM, Dmitri Pal wrote: >> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>> 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=newemail at 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 >> >> >> I like the idea of different verbs for different hives. >> Something like: >> >> Adding directly to stage via CLI: ipa user-stage >> Removing from stage: user-unstage (user is gone) >> Stage to Main -> activate; <- deactivate >> Main to delete -> del; <-restore or undelete >> Delete to stage -> I think we can use ipa user-stage command with >> --deleted=user or similar > > To be honest, I don't like this idea. > Too many names are confusing, if we can find a consistent option to cut the > number of names down we should do it. > IMO This is the worst part of Git: > http://assets.osteele.com/images/2008/git-transport.png . We can do better. > > Another good thing would be if options did not affect the applicability of > other options (too much). For example in your proposal there'd be something like: > ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... > ipa user-stage --deleted=tuser # > We should avoid this, if only for the reason that it makes the help text > confusing. > > > My proposal would be that the move commands use the verb for the target and an > option for the source, and add/mod use an option for the container: > > 1) adding a new user > (to active) ipa user-add tuser ... > (to stage) ipa user-add tuser --staged ... > (to deleted) ipa user-add tuser --deleted ... (*) > > 2) moving to main > (from stage) ipa user-activate tuser (**) > (from del) ipa user-activate tuser --deleted > > 3) moving to deleted > (from active) ipa user-del tuser > (from stage) ipa user-del tuser --staged > > 4) moving to stage > (from active) ipa user-stage tuser > (from del) ipa user-stage tuser --deleted > > 5) modifying > (in active) ipa user-mod tuser ... > (in stage) ipa user-mod tuser --staged ... > (in del) ipa user-mod tuser --deleted ... > > Five commands (two of which are user-specific), plus two fairly consistent > options. > > If the delete container isn't configured, the --deleted option is illegal and > `user-del` deletes permanently. > > > (*) may be useful in some situations? I personally cannot imagine such situation - I would not add this command. If somebody needs that, he can workaround with ipa user-add tuser --staged ipa user-del tuser --staged ... and report us the use case when it's needed. But I general, Petr's proposal makes sense to me, I would go for it. (and update the design as Dmitri correctly proposed). Martin From abokovoy at redhat.com Thu May 22 14:43:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 May 2014 17:43:30 +0300 Subject: [Freeipa-devel] [PATCH 0047] kdb: Don't provide password expiration when using only RADIUS In-Reply-To: <1400769055.2964.5.camel@ipa.example.com> References: <1399067343.2321.11.camel@localhost.localdomain> <1400769055.2964.5.camel@ipa.example.com> Message-ID: <20140522144330.GJ23849@redhat.com> On Thu, 22 May 2014, Nathaniel McCallum wrote: >On Fri, 2014-05-02 at 17:49 -0400, Nathaniel McCallum wrote: >> If the KDC doesn't use the FreeIPA password for authentication, then it >> is futile to provide this information. Doing so will only confuse the >> user. It also causes password change dialogues when the password is >> irrelevant. >> >> https://fedorahosted.org/freeipa/ticket/4299 > >This new version fixes a small logic bug. This should be an easy review. ACK. > >Nathaniel >>From 9764b91aa976ca1ed48885d5ace555b6b263080a Mon Sep 17 00:00:00 2001 >From: Nathaniel McCallum >Date: Fri, 2 May 2014 14:55:07 -0400 >Subject: [PATCH] kdb: Don't provide password expiration when using only RADIUS > >If the KDC doesn't use the FreeIPA password for authentication, then it is >futile to provide this information. Doing so will only confuse the user. It >also causes password change dialogues when the password is irrelevant. > >https://fedorahosted.org/freeipa/ticket/4299 >--- > daemons/ipa-kdb/ipa_kdb_principals.c | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c >index f0be76ea7b36efe3540429f7e31ffbc582edd060..d2be98886ef865eaabf7d5935994281ec262a2c8 100644 >--- a/daemons/ipa-kdb/ipa_kdb_principals.c >+++ b/daemons/ipa-kdb/ipa_kdb_principals.c >@@ -429,6 +429,10 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, > switch (ret) { > case 0: > entry->pw_expiration = restime; >+ >+ /* If we are using only RADIUS, we don't know expiration. */ >+ if (ua == IPADB_USER_AUTH_RADIUS) >+ entry->pw_expiration = 0; > case ENOENT: > break; > default: >-- >1.9.3 > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy From pviktori at redhat.com Thu May 22 14:45:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 16:45:01 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1400767923.2964.3.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> Message-ID: <537E0D6D.50608@redhat.com> On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: > On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: >> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: >>> On 12.5.2014 20:50, Nathaniel McCallum wrote: >>>> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: >>>>> On Tue, 06 May 2014 11:46:14 -0400 >>>>> Nathaniel McCallum wrote: >>>>> >>>>>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: >>>>>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: >>>>>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: >>>>>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: >>>>>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: >>>>>>>>>>> Specifying the default in the LDAP Object causes the >>>>>>>>>>> parameter to be specified for non-add operations. This is >>>>>>>>>>> especially problematic when performing the modify operation >>>>>>>>>>> as it causes the primary key to change for every modification. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> shouldn't removal of `autofill=True,` be enough? >>>>>>>>> >>>>>>>>> Removing autofill=True results in the default not being used >>>>>>>>> for the otptoken-add operation. That may be a different bug >>>>>>>>> (I'm not sure what the expectation of autofill is). >>>>>>>>> >>>>>>>>> Nathaniel >>>>>>>>> >>>>>>>> >>>>>>>> Seems to work form me with: >>>>>>>> >>>>>>>> diff --git a/ipalib/plugins/otptoken.py >>>>>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 >>>>>>>> --- a/ipalib/plugins/otptoken.py >>>>>>>> +++ b/ipalib/plugins/otptoken.py >>>>>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): >>>>>>>> cli_name='id', >>>>>>>> label=_('Unique ID'), >>>>>>>> default_from=lambda: unicode(uuid.uuid4()), >>>>>>>> - autofill=True, >>>>>>>> primary_key=True, >>>>>>>> - flags=('optional_create'), >>>>>>>> ), >>>>>>>> StrEnum('type?', >>>>>>>> label=_('Type'), >>>>>>> >>>>>>> Doing this causes the ipa otptoken-add command to prompt for the >>>>>>> Unique ID. This may be the desired behavior, but it is not how it >>>>>>> worked previously (no prompt). >>>>>> >>>>>> Here is an alternate patch for this second approach. I have no strong >>>>>> opinion on the correct behavior here. >>>>>> >>>>>> Nathaniel >>>>> >>>>> IMO you should update API.txt with ./makeapi >>>> >>>> Running ./makeapi results in no changes to API.txt. >>> >>> This is not right, there *are* changes in the API and build fails for me >>> becase API.txt is not updated. >> >> I think maybe I ran it from the wrong branch. Fixed. > > I still need a review of this. It is pretty trivial. > > Nathaniel This still prompts for the unique ID on add: $ ipa otptoken-add Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: I don't think that's the intended behavior. -- Petr? From pviktori at redhat.com Thu May 22 14:46:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 16:46:30 +0200 Subject: [Freeipa-devel] [PATCH 0047] kdb: Don't provide password expiration when using only RADIUS In-Reply-To: <20140522144330.GJ23849@redhat.com> References: <1399067343.2321.11.camel@localhost.localdomain> <1400769055.2964.5.camel@ipa.example.com> <20140522144330.GJ23849@redhat.com> Message-ID: <537E0DC6.6020406@redhat.com> On 05/22/2014 04:43 PM, Alexander Bokovoy wrote: > On Thu, 22 May 2014, Nathaniel McCallum wrote: >> On Fri, 2014-05-02 at 17:49 -0400, Nathaniel McCallum wrote: >>> If the KDC doesn't use the FreeIPA password for authentication, then it >>> is futile to provide this information. Doing so will only confuse the >>> user. It also causes password change dialogues when the password is >>> irrelevant. >>> >>> https://fedorahosted.org/freeipa/ticket/4299 >> >> This new version fixes a small logic bug. This should be an easy review. > ACK. > Pushed to master: 58f8ebf49148172c6f3b1d22bcd7ea0fb3fb21c7 -- Petr? From npmccallum at redhat.com Thu May 22 14:53:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 10:53:34 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <537E0D6D.50608@redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> <537E0D6D.50608@redhat.com> Message-ID: <1400770414.2746.3.camel@ipa.example.com> On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote: > On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: > > On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: > >> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: > >>> On 12.5.2014 20:50, Nathaniel McCallum wrote: > >>>> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: > >>>>> On Tue, 06 May 2014 11:46:14 -0400 > >>>>> Nathaniel McCallum wrote: > >>>>> > >>>>>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > >>>>>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > >>>>>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: > >>>>>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > >>>>>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: > >>>>>>>>>>> Specifying the default in the LDAP Object causes the > >>>>>>>>>>> parameter to be specified for non-add operations. This is > >>>>>>>>>>> especially problematic when performing the modify operation > >>>>>>>>>>> as it causes the primary key to change for every modification. > >>>>>>>>>>> > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> shouldn't removal of `autofill=True,` be enough? > >>>>>>>>> > >>>>>>>>> Removing autofill=True results in the default not being used > >>>>>>>>> for the otptoken-add operation. That may be a different bug > >>>>>>>>> (I'm not sure what the expectation of autofill is). > >>>>>>>>> > >>>>>>>>> Nathaniel > >>>>>>>>> > >>>>>>>> > >>>>>>>> Seems to work form me with: > >>>>>>>> > >>>>>>>> diff --git a/ipalib/plugins/otptoken.py > >>>>>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > >>>>>>>> --- a/ipalib/plugins/otptoken.py > >>>>>>>> +++ b/ipalib/plugins/otptoken.py > >>>>>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > >>>>>>>> cli_name='id', > >>>>>>>> label=_('Unique ID'), > >>>>>>>> default_from=lambda: unicode(uuid.uuid4()), > >>>>>>>> - autofill=True, > >>>>>>>> primary_key=True, > >>>>>>>> - flags=('optional_create'), > >>>>>>>> ), > >>>>>>>> StrEnum('type?', > >>>>>>>> label=_('Type'), > >>>>>>> > >>>>>>> Doing this causes the ipa otptoken-add command to prompt for the > >>>>>>> Unique ID. This may be the desired behavior, but it is not how it > >>>>>>> worked previously (no prompt). > >>>>>> > >>>>>> Here is an alternate patch for this second approach. I have no strong > >>>>>> opinion on the correct behavior here. > >>>>>> > >>>>>> Nathaniel > >>>>> > >>>>> IMO you should update API.txt with ./makeapi > >>>> > >>>> Running ./makeapi results in no changes to API.txt. > >>> > >>> This is not right, there *are* changes in the API and build fails for me > >>> becase API.txt is not updated. > >> > >> I think maybe I ran it from the wrong branch. Fixed. > > > > I still need a review of this. It is pretty trivial. > > > > Nathaniel > > This still prompts for the unique ID on add: > > $ ipa otptoken-add > Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: > > I don't think that's the intended behavior. Hence the alternate patch (0052a). If we don't want to prompt, we'll need to use the first patch (0052). I have no strong opinion on the correct behavior and I am fine with merging either patch. Nathaniel From npmccallum at redhat.com Thu May 22 15:00:24 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 11:00:24 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1400770414.2746.3.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> <537E0D6D.50608@redhat.com> <1400770414.2746.3.camel@ipa.example.com> Message-ID: <1400770824.2746.4.camel@ipa.example.com> On Thu, 2014-05-22 at 10:53 -0400, Nathaniel McCallum wrote: > On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote: > > On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: > > > On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: > > >> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: > > >>> On 12.5.2014 20:50, Nathaniel McCallum wrote: > > >>>> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: > > >>>>> On Tue, 06 May 2014 11:46:14 -0400 > > >>>>> Nathaniel McCallum wrote: > > >>>>> > > >>>>>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > > >>>>>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > > >>>>>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: > > >>>>>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > > >>>>>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: > > >>>>>>>>>>> Specifying the default in the LDAP Object causes the > > >>>>>>>>>>> parameter to be specified for non-add operations. This is > > >>>>>>>>>>> especially problematic when performing the modify operation > > >>>>>>>>>>> as it causes the primary key to change for every modification. > > >>>>>>>>>>> > > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> shouldn't removal of `autofill=True,` be enough? > > >>>>>>>>> > > >>>>>>>>> Removing autofill=True results in the default not being used > > >>>>>>>>> for the otptoken-add operation. That may be a different bug > > >>>>>>>>> (I'm not sure what the expectation of autofill is). > > >>>>>>>>> > > >>>>>>>>> Nathaniel > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> Seems to work form me with: > > >>>>>>>> > > >>>>>>>> diff --git a/ipalib/plugins/otptoken.py > > >>>>>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > > >>>>>>>> --- a/ipalib/plugins/otptoken.py > > >>>>>>>> +++ b/ipalib/plugins/otptoken.py > > >>>>>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > > >>>>>>>> cli_name='id', > > >>>>>>>> label=_('Unique ID'), > > >>>>>>>> default_from=lambda: unicode(uuid.uuid4()), > > >>>>>>>> - autofill=True, > > >>>>>>>> primary_key=True, > > >>>>>>>> - flags=('optional_create'), > > >>>>>>>> ), > > >>>>>>>> StrEnum('type?', > > >>>>>>>> label=_('Type'), > > >>>>>>> > > >>>>>>> Doing this causes the ipa otptoken-add command to prompt for the > > >>>>>>> Unique ID. This may be the desired behavior, but it is not how it > > >>>>>>> worked previously (no prompt). > > >>>>>> > > >>>>>> Here is an alternate patch for this second approach. I have no strong > > >>>>>> opinion on the correct behavior here. > > >>>>>> > > >>>>>> Nathaniel > > >>>>> > > >>>>> IMO you should update API.txt with ./makeapi > > >>>> > > >>>> Running ./makeapi results in no changes to API.txt. > > >>> > > >>> This is not right, there *are* changes in the API and build fails for me > > >>> becase API.txt is not updated. > > >> > > >> I think maybe I ran it from the wrong branch. Fixed. > > > > > > I still need a review of this. It is pretty trivial. > > > > > > Nathaniel > > > > This still prompts for the unique ID on add: > > > > $ ipa otptoken-add > > Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: > > > > I don't think that's the intended behavior. > > Hence the alternate patch (0052a). If we don't want to prompt, we'll > need to use the first patch (0052). I have no strong opinion on the > correct behavior and I am fine with merging either patch. Attached is the non-alternate (0052) with the api updated. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0052.1-Only-specify-the-ipatokenuniqueid-default-in-the-add.patch Type: text/x-patch Size: 5934 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 22 15:13:34 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 22 May 2014 17:13:34 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <1400770824.2746.4.camel@ipa.example.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> <537E0D6D.50608@redhat.com> <1400770414.2746.3.camel@ipa.example.com> <1400770824.2746.4.camel@ipa.example.com> Message-ID: <537E141E.7010906@redhat.com> On 22.5.2014 17:00, Nathaniel McCallum wrote: > On Thu, 2014-05-22 at 10:53 -0400, Nathaniel McCallum wrote: >> On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote: >>> On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: >>>> On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: >>>>> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: >>>>>> On 12.5.2014 20:50, Nathaniel McCallum wrote: >>>>>>> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: >>>>>>>> On Tue, 06 May 2014 11:46:14 -0400 >>>>>>>> Nathaniel McCallum wrote: >>>>>>>> >>>>>>>>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: >>>>>>>>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: >>>>>>>>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: >>>>>>>>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: >>>>>>>>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: >>>>>>>>>>>>>> Specifying the default in the LDAP Object causes the >>>>>>>>>>>>>> parameter to be specified for non-add operations. This is >>>>>>>>>>>>>> especially problematic when performing the modify operation >>>>>>>>>>>>>> as it causes the primary key to change for every modification. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> shouldn't removal of `autofill=True,` be enough? >>>>>>>>>>>> >>>>>>>>>>>> Removing autofill=True results in the default not being used >>>>>>>>>>>> for the otptoken-add operation. That may be a different bug >>>>>>>>>>>> (I'm not sure what the expectation of autofill is). >>>>>>>>>>>> >>>>>>>>>>>> Nathaniel >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Seems to work form me with: >>>>>>>>>>> >>>>>>>>>>> diff --git a/ipalib/plugins/otptoken.py >>>>>>>>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 >>>>>>>>>>> --- a/ipalib/plugins/otptoken.py >>>>>>>>>>> +++ b/ipalib/plugins/otptoken.py >>>>>>>>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): >>>>>>>>>>> cli_name='id', >>>>>>>>>>> label=_('Unique ID'), >>>>>>>>>>> default_from=lambda: unicode(uuid.uuid4()), >>>>>>>>>>> - autofill=True, >>>>>>>>>>> primary_key=True, >>>>>>>>>>> - flags=('optional_create'), >>>>>>>>>>> ), >>>>>>>>>>> StrEnum('type?', >>>>>>>>>>> label=_('Type'), >>>>>>>>>> >>>>>>>>>> Doing this causes the ipa otptoken-add command to prompt for the >>>>>>>>>> Unique ID. This may be the desired behavior, but it is not how it >>>>>>>>>> worked previously (no prompt). >>>>>>>>> >>>>>>>>> Here is an alternate patch for this second approach. I have no strong >>>>>>>>> opinion on the correct behavior here. >>>>>>>>> >>>>>>>>> Nathaniel >>>>>>>> >>>>>>>> IMO you should update API.txt with ./makeapi >>>>>>> >>>>>>> Running ./makeapi results in no changes to API.txt. >>>>>> >>>>>> This is not right, there *are* changes in the API and build fails for me >>>>>> becase API.txt is not updated. >>>>> >>>>> I think maybe I ran it from the wrong branch. Fixed. >>>> >>>> I still need a review of this. It is pretty trivial. >>>> >>>> Nathaniel >>> >>> This still prompts for the unique ID on add: >>> >>> $ ipa otptoken-add >>> Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: >>> >>> I don't think that's the intended behavior. >> >> Hence the alternate patch (0052a). If we don't want to prompt, we'll >> need to use the first patch (0052). I have no strong opinion on the >> correct behavior and I am fine with merging either patch. > > Attached is the non-alternate (0052) with the api updated. > > Nathaniel IMO 52a is better if used by hand and it keeps code cleaner. It might not be ideal though if used from a script because of nonexistent --unattended/-u option which would disable prompt (set env.interactive=False ?). -- Petr Vobornik From pviktori at redhat.com Thu May 22 15:33:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 17:33:01 +0200 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <537E141E.7010906@redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> <537E0D6D.50608@redhat.com> <1400770414.2746.3.camel@ipa.example.com> <1400770824.2746.4.camel@ipa.example.com> <537E141E.7010906@redhat.com> Message-ID: <537E18AD.6010300@redhat.com> On 05/22/2014 05:13 PM, Petr Vobornik wrote: > On 22.5.2014 17:00, Nathaniel McCallum wrote: >> On Thu, 2014-05-22 at 10:53 -0400, Nathaniel McCallum wrote: >>> On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote: >>>> On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: >>>>> On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: >>>>>> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: >>>>>>> On 12.5.2014 20:50, Nathaniel McCallum wrote: >>>>>>>> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: >>>>>>>>> On Tue, 06 May 2014 11:46:14 -0400 >>>>>>>>> Nathaniel McCallum wrote: >>>>>>>>> >>>>>>>>>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: >>>>>>>>>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: >>>>>>>>>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: >>>>>>>>>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: >>>>>>>>>>>>>>> Specifying the default in the LDAP Object causes the >>>>>>>>>>>>>>> parameter to be specified for non-add operations. This is >>>>>>>>>>>>>>> especially problematic when performing the modify operation >>>>>>>>>>>>>>> as it causes the primary key to change for every >>>>>>>>>>>>>>> modification. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> shouldn't removal of `autofill=True,` be enough? >>>>>>>>>>>>> >>>>>>>>>>>>> Removing autofill=True results in the default not being used >>>>>>>>>>>>> for the otptoken-add operation. That may be a different bug >>>>>>>>>>>>> (I'm not sure what the expectation of autofill is). >>>>>>>>>>>>> >>>>>>>>>>>>> Nathaniel >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Seems to work form me with: >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/ipalib/plugins/otptoken.py >>>>>>>>>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 >>>>>>>>>>>> --- a/ipalib/plugins/otptoken.py >>>>>>>>>>>> +++ b/ipalib/plugins/otptoken.py >>>>>>>>>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): >>>>>>>>>>>> cli_name='id', >>>>>>>>>>>> label=_('Unique ID'), >>>>>>>>>>>> default_from=lambda: unicode(uuid.uuid4()), >>>>>>>>>>>> - autofill=True, >>>>>>>>>>>> primary_key=True, >>>>>>>>>>>> - flags=('optional_create'), >>>>>>>>>>>> ), >>>>>>>>>>>> StrEnum('type?', >>>>>>>>>>>> label=_('Type'), >>>>>>>>>>> >>>>>>>>>>> Doing this causes the ipa otptoken-add command to prompt for the >>>>>>>>>>> Unique ID. This may be the desired behavior, but it is not >>>>>>>>>>> how it >>>>>>>>>>> worked previously (no prompt). >>>>>>>>>> >>>>>>>>>> Here is an alternate patch for this second approach. I have no >>>>>>>>>> strong >>>>>>>>>> opinion on the correct behavior here. >>>>>>>>>> >>>>>>>>>> Nathaniel >>>>>>>>> >>>>>>>>> IMO you should update API.txt with ./makeapi >>>>>>>> >>>>>>>> Running ./makeapi results in no changes to API.txt. >>>>>>> >>>>>>> This is not right, there *are* changes in the API and build fails >>>>>>> for me >>>>>>> becase API.txt is not updated. >>>>>> >>>>>> I think maybe I ran it from the wrong branch. Fixed. >>>>> >>>>> I still need a review of this. It is pretty trivial. >>>>> >>>>> Nathaniel >>>> >>>> This still prompts for the unique ID on add: >>>> >>>> $ ipa otptoken-add >>>> Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: >>>> >>>> I don't think that's the intended behavior. >>> >>> Hence the alternate patch (0052a). If we don't want to prompt, we'll >>> need to use the first patch (0052). I have no strong opinion on the >>> correct behavior and I am fine with merging either patch. >> >> Attached is the non-alternate (0052) with the api updated. >> >> Nathaniel > > IMO 52a is better if used by hand and it keeps code cleaner. I don't think that should influence the design of the CLI that much. > It might > not be ideal though if used from a script because of nonexistent > --unattended/-u option which would disable prompt (set > env.interactive=False ?). Right. ACK to the non-prompting version (0052.1). -- Petr? From tbordaz at redhat.com Thu May 22 15:52:03 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 22 May 2014 17:52:03 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537E0BF4.4040806@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> Message-ID: <537E1D23.6080703@redhat.com> On 05/22/2014 04:38 PM, Martin Kosek wrote: > On 05/22/2014 10:47 AM, Petr Viktorin wrote: >> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>> 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=newemail at 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 >>> >>> I like the idea of different verbs for different hives. >>> Something like: >>> >>> Adding directly to stage via CLI: ipa user-stage >>> Removing from stage: user-unstage (user is gone) >>> Stage to Main -> activate; <- deactivate >>> Main to delete -> del; <-restore or undelete >>> Delete to stage -> I think we can use ipa user-stage command with >>> --deleted=user or similar >> To be honest, I don't like this idea. >> Too many names are confusing, if we can find a consistent option to cut the >> number of names down we should do it. >> IMO This is the worst part of Git: >> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >> >> Another good thing would be if options did not affect the applicability of >> other options (too much). For example in your proposal there'd be something like: >> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >> ipa user-stage --deleted=tuser # >> We should avoid this, if only for the reason that it makes the help text >> confusing. >> >> >> My proposal would be that the move commands use the verb for the target and an >> option for the source, and add/mod use an option for the container: >> >> 1) adding a new user >> (to active) ipa user-add tuser ... >> (to stage) ipa user-add tuser --staged ... >> (to deleted) ipa user-add tuser --deleted ... (*) >> >> 2) moving to main >> (from stage) ipa user-activate tuser (**) >> (from del) ipa user-activate tuser --deleted >> >> 3) moving to deleted >> (from active) ipa user-del tuser >> (from stage) ipa user-del tuser --staged >> >> 4) moving to stage >> (from active) ipa user-stage tuser >> (from del) ipa user-stage tuser --deleted >> >> 5) modifying >> (in active) ipa user-mod tuser ... >> (in stage) ipa user-mod tuser --staged ... >> (in del) ipa user-mod tuser --deleted ... >> >> Five commands (two of which are user-specific), plus two fairly consistent >> options. >> >> If the delete container isn't configured, the --deleted option is illegal and >> `user-del` deletes permanently. >> >> >> (*) may be useful in some situations? > I personally cannot imagine such situation - I would not add this command. If > somebody needs that, he can workaround with > > ipa user-add tuser --staged > ipa user-del tuser --staged > > ... and report us the use case when it's needed. But I general, Petr's proposal > makes sense to me, I would go for it. (and update the design as Dmitri > correctly proposed). > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, I will update the design following Petr proposal. Great one ! However I was thinking to a sligthly different proposal. For example if we have 3 states: staging, active, inactive. 1) adding a user (...to active) ipa user-add# ( after the command ipaUniqueID=) (... to staging) ipa user-add --stage# (after the command ipaUniqueID=generate) So here we can not add a user directly into inactive state 2) activating the user (staging to active) ipa user-activate# (after the command ipaUniqueID=) (inactive to active) ipa user-activate --inactive# (after the command ipaUniqueID=) 3) inactivate the user (active to inactive) ipa user-inactivate# (after the command ipaUniqueID=) Here there is no possibility to move back an active entry to staging, because in staging the entries do not have ipaUniqueID set 4) modify the user (from active) ipa user-mod # (after the command ipaUniqueID=) (from inactive) ipa user-mod --inactive# (after the command ipaUniqueID=) (from staging) ipa user-mod --stage # (after the command ipaUniqueID=generate) 5) delete user (staging to delete) ipa user-del (inactive to delete) ipa user-del --inactive Here the entries are definitely removed -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu May 22 16:24:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 May 2014 18:24:36 +0200 Subject: [Freeipa-devel] [PATCH] 0550 ipalib.cli: Add filename argument to ipa console In-Reply-To: <1400767606.2964.2.camel@ipa.example.com> References: <537DF6A3.8020000@redhat.com> <1400767606.2964.2.camel@ipa.example.com> Message-ID: <537E24C4.7060207@redhat.com> On 05/22/2014 04:06 PM, Nathaniel McCallum wrote: > On Thu, 2014-05-22 at 15:07 +0200, Petr Viktorin wrote: >> Hello, >> I find the `ipa console` command quite useful for testing, and it's >> bothered me that it can't execute a script. Fixing this helps me. Would >> it help anyone else? >> >> This would need a ticket + design doc before it's pushed. >> >> >> Compare: >> $ (echo 'print 1'; echo 'print 2') | ipa console >> (Custom IPA interactive Python console) >> >>> 1 >> >>> 2 >> >> >>> [no newline] >> >> $ ipa console <(echo 'print 1'; echo 'print 2') >> 1 >> 2 > > Looks helpful to me. ACK Thanks! Filed ticket: https://fedorahosted.org/freeipa/ticket/4351 Added to http://www.freeipa.org/page/V4_Minor_Enhancements instead of writing a design page Added link to ticket and pushed to master: 4d7351ef070176283d7626ae2501a4ad7acc093e > > Also, FTR, at first I thought it looked weird to have the open() outside > of the with statement. But this is because you only want to catch the > IOError during the open() operation. So the behavior in this patch is > correct. Yeah, I couldn't use the common shortcut this time. -- Petr? From npmccallum at redhat.com Thu May 22 16:30:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 22 May 2014 12:30:34 -0400 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <537E141E.7010906@redhat.com> References: <1399387890.9864.0.camel@ipa.example.com> <5368FA0E.8070107@redhat.com> <1399389223.9864.3.camel@ipa.example.com> <536900FE.6090901@redhat.com> <1399390718.9864.5.camel@ipa.example.com> <1399391174.9864.6.camel@ipa.example.com> <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> <537E0D6D.50608@redhat.com> <1400770414.2746.3.camel@ipa.example.com> <1400770824.2746.4.camel@ipa.example.com> <537E141E.7010906@redhat.com> Message-ID: <1400776234.2746.7.camel@ipa.example.com> On Thu, 2014-05-22 at 17:13 +0200, Petr Vobornik wrote: > On 22.5.2014 17:00, Nathaniel McCallum wrote: > > On Thu, 2014-05-22 at 10:53 -0400, Nathaniel McCallum wrote: > >> On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote: > >>> On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: > >>>> On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: > >>>>> On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: > >>>>>> On 12.5.2014 20:50, Nathaniel McCallum wrote: > >>>>>>> On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: > >>>>>>>> On Tue, 06 May 2014 11:46:14 -0400 > >>>>>>>> Nathaniel McCallum wrote: > >>>>>>>> > >>>>>>>>> On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: > >>>>>>>>>> On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: > >>>>>>>>>>> On 6.5.2014 17:13, Nathaniel McCallum wrote: > >>>>>>>>>>>> On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: > >>>>>>>>>>>>> On 6.5.2014 16:51, Nathaniel McCallum wrote: > >>>>>>>>>>>>>> Specifying the default in the LDAP Object causes the > >>>>>>>>>>>>>> parameter to be specified for non-add operations. This is > >>>>>>>>>>>>>> especially problematic when performing the modify operation > >>>>>>>>>>>>>> as it causes the primary key to change for every modification. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4227 > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> shouldn't removal of `autofill=True,` be enough? > >>>>>>>>>>>> > >>>>>>>>>>>> Removing autofill=True results in the default not being used > >>>>>>>>>>>> for the otptoken-add operation. That may be a different bug > >>>>>>>>>>>> (I'm not sure what the expectation of autofill is). > >>>>>>>>>>>> > >>>>>>>>>>>> Nathaniel > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Seems to work form me with: > >>>>>>>>>>> > >>>>>>>>>>> diff --git a/ipalib/plugins/otptoken.py > >>>>>>>>>>> b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 > >>>>>>>>>>> --- a/ipalib/plugins/otptoken.py > >>>>>>>>>>> +++ b/ipalib/plugins/otptoken.py > >>>>>>>>>>> @@ -121,9 +121,7 @@ class otptoken(LDAPObject): > >>>>>>>>>>> cli_name='id', > >>>>>>>>>>> label=_('Unique ID'), > >>>>>>>>>>> default_from=lambda: unicode(uuid.uuid4()), > >>>>>>>>>>> - autofill=True, > >>>>>>>>>>> primary_key=True, > >>>>>>>>>>> - flags=('optional_create'), > >>>>>>>>>>> ), > >>>>>>>>>>> StrEnum('type?', > >>>>>>>>>>> label=_('Type'), > >>>>>>>>>> > >>>>>>>>>> Doing this causes the ipa otptoken-add command to prompt for the > >>>>>>>>>> Unique ID. This may be the desired behavior, but it is not how it > >>>>>>>>>> worked previously (no prompt). > >>>>>>>>> > >>>>>>>>> Here is an alternate patch for this second approach. I have no strong > >>>>>>>>> opinion on the correct behavior here. > >>>>>>>>> > >>>>>>>>> Nathaniel > >>>>>>>> > >>>>>>>> IMO you should update API.txt with ./makeapi > >>>>>>> > >>>>>>> Running ./makeapi results in no changes to API.txt. > >>>>>> > >>>>>> This is not right, there *are* changes in the API and build fails for me > >>>>>> becase API.txt is not updated. > >>>>> > >>>>> I think maybe I ran it from the wrong branch. Fixed. > >>>> > >>>> I still need a review of this. It is pretty trivial. > >>>> > >>>> Nathaniel > >>> > >>> This still prompts for the unique ID on add: > >>> > >>> $ ipa otptoken-add > >>> Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: > >>> > >>> I don't think that's the intended behavior. > >> > >> Hence the alternate patch (0052a). If we don't want to prompt, we'll > >> need to use the first patch (0052). I have no strong opinion on the > >> correct behavior and I am fine with merging either patch. > > > > Attached is the non-alternate (0052) with the api updated. > > > > Nathaniel > > IMO 52a is better if used by hand and it keeps code cleaner. It might > not be ideal though if used from a script because of nonexistent > --unattended/-u option which would disable prompt (set > env.interactive=False ?). It only prompts if the id is not specified. If you are using it in a script you can just create your own random UUID and specify it. This is exactly what I do in the import script patch. Nathaniel From simo at redhat.com Thu May 22 17:21:26 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 May 2014 13:21:26 -0400 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537E1D23.6080703@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> Message-ID: <1400779286.7561.93.camel@willson.li.ssimo.org> On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote: > On 05/22/2014 04:38 PM, Martin Kosek wrote: > > On 05/22/2014 10:47 AM, Petr Viktorin wrote: > >> On 05/21/2014 10:00 PM, Dmitri Pal wrote: > >>> On 05/19/2014 10:45 AM, thierry bordaz wrote: > >>>> 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=newemail at 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 > >>> > >>> I like the idea of different verbs for different hives. > >>> Something like: > >>> > >>> Adding directly to stage via CLI: ipa user-stage > >>> Removing from stage: user-unstage (user is gone) > >>> Stage to Main -> activate; <- deactivate > >>> Main to delete -> del; <-restore or undelete > >>> Delete to stage -> I think we can use ipa user-stage command with > >>> --deleted=user or similar > >> To be honest, I don't like this idea. > >> Too many names are confusing, if we can find a consistent option to cut the > >> number of names down we should do it. > >> IMO This is the worst part of Git: > >> http://assets.osteele.com/images/2008/git-transport.png . We can do better. > >> > >> Another good thing would be if options did not affect the applicability of > >> other options (too much). For example in your proposal there'd be something like: > >> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... > >> ipa user-stage --deleted=tuser # > >> We should avoid this, if only for the reason that it makes the help text > >> confusing. > >> > >> > >> My proposal would be that the move commands use the verb for the target and an > >> option for the source, and add/mod use an option for the container: > >> > >> 1) adding a new user > >> (to active) ipa user-add tuser ... > >> (to stage) ipa user-add tuser --staged ... > >> (to deleted) ipa user-add tuser --deleted ... (*) > >> > >> 2) moving to main > >> (from stage) ipa user-activate tuser (**) > >> (from del) ipa user-activate tuser --deleted > >> > >> 3) moving to deleted > >> (from active) ipa user-del tuser > >> (from stage) ipa user-del tuser --staged > >> > >> 4) moving to stage > >> (from active) ipa user-stage tuser > >> (from del) ipa user-stage tuser --deleted > >> > >> 5) modifying > >> (in active) ipa user-mod tuser ... > >> (in stage) ipa user-mod tuser --staged ... > >> (in del) ipa user-mod tuser --deleted ... > >> > >> Five commands (two of which are user-specific), plus two fairly consistent > >> options. > >> > >> If the delete container isn't configured, the --deleted option is illegal and > >> `user-del` deletes permanently. > >> > >> > >> (*) may be useful in some situations? > > I personally cannot imagine such situation - I would not add this command. If > > somebody needs that, he can workaround with > > > > ipa user-add tuser --staged > > ipa user-del tuser --staged > > > > ... and report us the use case when it's needed. But I general, Petr's proposal > > makes sense to me, I would go for it. (and update the design as Dmitri > > correctly proposed). > > > > Martin > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello, > > I will update the design following Petr proposal. Great one ! > However I was thinking to a sligthly different proposal. For > example if we have 3 states: staging, active, inactive. > 1) adding a user > > (...to active) ipa user-add# ( after the command > ipaUniqueID=) > (... to staging) ipa user-add --stage# (after the command > ipaUniqueID=generate) > > So here we can not add a user directly into inactive state > > 2) activating the user > > (staging to active) ipa user-activate# (after the command > ipaUniqueID=) > (inactive to active) ipa user-activate --inactive# (after the > command ipaUniqueID=) > > 3) inactivate the user > > (active to inactive) ipa user-inactivate# (after the command > ipaUniqueID=) > > Here there is no possibility to move back an active entry to > staging, because in staging > the entries do not have ipaUniqueID set Do we ever want to allow to move a user from active to staging ? I can't find a case where my answer is yes. >From my POV a user once it leaves staging is either active or deleted, in my mind there is no reason ever to move a user into staging. In what case does it make sense ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 22 17:25:02 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 May 2014 13:25:02 -0400 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <1400768477.2964.4.camel@ipa.example.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> <1399388863.9864.1.camel@ipa.example.com> <536A3B30.3080206@redhat.com> <1399471569.3786.9.camel@ipa.example.com> <1400768477.2964.4.camel@ipa.example.com> Message-ID: <1400779502.7561.94.camel@willson.li.ssimo.org> On Thu, 2014-05-22 at 10:21 -0400, Nathaniel McCallum wrote: > I still need a review on this. LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 22 17:27:54 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 May 2014 13:27:54 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537DFD21.7040704@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> Message-ID: <1400779674.7561.97.camel@willson.li.ssimo.org> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: > On 05/21/2014 10:11 PM, Dmitri Pal wrote: > > On 05/21/2014 03:06 PM, Martin Kosek wrote: > >> On 05/21/2014 08:14 PM, Simo Sorce wrote: > >>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: > >>>> Hello, > >>>> > >>>> Thanks for all these detailed descriptions. > >>>> Just to be sure to be on the same page, here is my understanding of > >>>> the provisioning templates and placeholder definitions. An > >>>> administrator can provide a provisioning template. I suppose it > >>>> would be a file containing a lines of placeholder definitions. > >>>> > >>>> * Where is located the template file ? Is there a standard > >>>> repository where templates are put ? (somewhere under /etc/ipa/* ?) > >>> > >>> FreeIPA is a multi-master system, a file stored in a file would be > >>> extremely cumbersome to use as it would require the admin to manually > >>> copy it for every new replica and then keep it in sync. > >>> It would also make it hard to change 'on-line'. > >>> > >>> Placeholders should be defined in an object similar to > >>> cn=ipaConfig,cn=etc,$suffix > >>> > >>>> * Is there an already defined syntax for the provisionning > >>>> template. ('$' is separator attr/value, %{} is substitute > >>>> pattern...). If not, is it possible to user ': ' as > >>>> separator ? > >>> > >>> Using initial and final ? like in Martin's example doesn't work ? > >>> > >>>> * What is the priority. The user can provide the 'homeDirectory' > >>>> through different methods. Is it ok to use the following order: > >>>> o the CLI option > >>>> o the provisionning template > >>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) > >>>> > >>>> For example, if it exists the provisioning template: > >>>> /etc/ipa/provisioning/shell-user.template > >>>> > >>>> roomnumber$-2 > >>>> homeDirectory$/home/net/shell-%{uid} > >>>> loginShell$?shell-plugin-autogenerate? > >>> > >>> I do not understand this, we are not building a templating engine here, > >>> you only have 2 options: > >>> 1) a required (MUST) attribute has an explicit value > >>> 2) a require (MUST) attribute has a placeholder value > >>> > >>> the placeholder value is fixed per type, and what it is substituted with > >>> uses the same rules as the current code uses to autogenerate values. > >>> > >>>> the command: ipa user-add tuser > >>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a > >>>> staging entry: > >>>> > >>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > >>>> ... > >>>> roomNumber: 1234 > >>>> homeDirectory: /tmp/tuser > >>>> loginShell: shell-plugin-autogenerate > >>> > >>> loginShell is a MAY attribute, not a MUST attribute, so nothing should > >>> be stored at all in the staged entry unless explicitly provided for by > >>> the admin. > >>> > >>>> Then a private DS plugin (catching shell-plugin-autogenerate) > >>>> generate the loginShell value when the entry becomes active. > >>>> > >>>> > >>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would > >>>> create a staging entry: > >>>> > >>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > >>>> ... > >>>> roomNumber: -2 > >>>> homeDirectory: /tmp/tuser > >>>> loginShell: shell-plugin-autogenerate > >>> > >>> roomNumber is also a MAY, so what would cause it to be set at -2, and > >>> why ? > >>> > >>>> the command: ipa user-add tuser --to-stage would create a staging entry: > >>>> > >>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > >>>> ... > >>>> roomNumber: -2 > >>>> homeDirectory: /home/net/shell-tuser > >>>> loginShell: shell-plugin-autogenerate > >>> > >>> homeDirectory should be something like: ?placeholder? IMO, we do not > >>> really want to play templating here. > >>> > >>>> In case the provisioning template does not define 'homeDirectory', > >>>> then the created entry would take the value from the ipa config > >>>> definition: > >>> > >>> that value should be taken and applied at the time the user is unstaged > >>> and brought in the actual tree, not at the time a user is staged. > >>> > >>> HTH, > >>> Simo. > >>> > >> > >> Hello Thierry and Simo, > >> > >> I think Thierry was confused with this part of the design: > >> > >> " > >> This format of placeholders gives enough space for future enhancements. For > >> example, Administrator could configure a new template > >> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. > >> Such value would be replaced by "/home/net/tuser if user uid attribute is set > >> to tuser > >> " > >> > >> My intention when writing this design was to enable future use of > >> configurable placeholders, i.e. a value "?someplaceholder?" could be turn > >> into "/custom/path/%{uid}". But I meant that this can be considered as a > >> future enhancement. For now, I think implementing a placeholder "-1" for > >> numerical values and "?autogenerate?" for string ones a good start. > >> > >> Martin > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > > Please consider the flow: user added staged -> activated/moved to main tree -> > > deleted/moved to deleted tree -> staged back > > At the first step his IPA user ID and UID should be undefined and autogenerated. > > On the last step his IPAUserID and UID should be preserved. The main use case > > is that this is the user who left the company who comes back again. His files > > should be still owned by him unless admin forces a flush of his IDs (new > > switch???) when he moves user from deleted to staged. > > > > Right, the life-cycle feature should work like that naturally, given that only > attributes with "-1" or "autogenerate" are generated. > > If admin wants to re-generate the IDs, all he would need to do is to change the > attributes back to "-1" after/before moving the user to staging. Question is > when it should be done (in deleted tree, in staging tree or after activation) > and what API/command we choose. TBH I question the whole idea of "moving to staging", in what case would that make sense ? > Admin may want to change not only the UID/GID, but maybe also a home directory > (user may be in a different department) so we should make it general. Maybe we > should let user-mod support modification in staging area? Like > > $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged > > or > > $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted The reason why we have the 'deleted' area is to be able to preserve the user intact ... I would almost want to ask to explicitly not allow modifications to deleted users (admin can always use ldapmodify if they *really* need to play some game here). Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Fri May 23 05:01:37 2014 From: purpleidea at gmail.com (James) Date: Fri, 23 May 2014 01:01:37 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals Message-ID: I'm trying to understand some of the FreeIPA replication internals so that I can better know how to do this properly in Puppet without storing any secret information in Puppet, and so that automating FreeIPA is awesome. Please point me to any docs, if there is reading I could be doing :) Here are some open questions I have: 1) Is the GPG file created with ipa-replica-prepare using a symmetric password and is that password equal to the dm_password ? If not, where do the pub/priv key pairs come from and how do they get transferred to the replica. 2) If I have root on the IPA server (actually all of them) how can I run ipa-replica-prepare without needing interactive prompting for entering the password. It's not possible with puppet. Is there another (possibly less user friendly even) method to "prepare" the replica? What is prepare actually doing? 3) With a multi master setup, what happens if I run the same action (eg: user-mod or user-add or user-del) on more than one server. Can I run it on any server? What if I run different user-mod commands of the same user on different masters. Is there split brain? Are all the transactions and writes synchronous across the whole cluster? Please point me to a doc that explains this FAQ stuff if possible. Sorry for the noise Thanks again, James From jcholast at redhat.com Fri May 23 05:45:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 May 2014 07:45:17 +0200 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <1400768477.2964.4.camel@ipa.example.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> <1399388863.9864.1.camel@ipa.example.com> <536A3B30.3080206@redhat.com> <1399471569.3786.9.camel@ipa.example.com> <1400768477.2964.4.camel@ipa.example.com> Message-ID: <537EE06D.50004@redhat.com> On 22.5.2014 16:21, Nathaniel McCallum wrote: > I still need a review on this. > > On Wed, 2014-05-07 at 10:06 -0400, Nathaniel McCallum wrote: >> On Wed, 2014-05-07 at 15:54 +0200, Petr Vobornik wrote: >>> On 6.5.2014 17:07, Nathaniel McCallum wrote: >>>> On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote: >>>>> On 6.5.2014 15:16, Nathaniel McCallum wrote: >>>>>> On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 5.5.2014 18:40, Nathaniel McCallum wrote: >>>>>>>> Creating tokens for yourself is the most common operation. Making this >>>>>>>> the default optimizes for the common case. >>>>>>> >>>>>>> The user-find call should be inside the if statement. >>>>>> >>>>>> This is actually for a reason. See my patch 0049 for further context. >>>>> >>>>> IMO something like this would be better: >>>>> >>>>> if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in >>>>> entry_attrs: >>>>> result = self.api.Command.user_find(whoami=True)['result'] >>>>> if result: >>>>> cur_uid = result[0]['uid'][0] >>>>> prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) >>>>> if cur_uid != prev_uid: >>>>> entry_attrs.setdefault('ipatokenprotected', True) >>>> >>>> Fixed (see also my new revision of patch 0049). >>>> >>>> Nathaniel >>>> >>> >>> I assume that this won't allow to create a token without an owner. Do we >>> want to have this restriction? >>> >>> Usecase: import a batch of hw tokens >> >> This case is currently very much on my radar (I'm finishing the import >> script now). To set no owner, just use --owner="". We are testing for >> key presence here, not the value of the key. So if the key is present >> with an empty value, no owner will be set. >> >> FYI, the import format (RFC 6030) also permits a mechanism for declaring >> ownership in DN format. >> >> Nathaniel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK. -- Jan Cholasta From jcholast at redhat.com Fri May 23 05:48:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 May 2014 07:48:21 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <1400779674.7561.97.camel@willson.li.ssimo.org> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> Message-ID: <537EE125.20404@redhat.com> On 22.5.2014 19:27, Simo Sorce wrote: > On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: >> On 05/21/2014 10:11 PM, Dmitri Pal wrote: >>> On 05/21/2014 03:06 PM, Martin Kosek wrote: >>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>>>> Hello, >>>>>> >>>>>> Thanks for all these detailed descriptions. >>>>>> Just to be sure to be on the same page, here is my understanding of >>>>>> the provisioning templates and placeholder definitions. An >>>>>> administrator can provide a provisioning template. I suppose it >>>>>> would be a file containing a lines of placeholder definitions. >>>>>> >>>>>> * Where is located the template file ? Is there a standard >>>>>> repository where templates are put ? (somewhere under /etc/ipa/* ?) >>>>> >>>>> FreeIPA is a multi-master system, a file stored in a file would be >>>>> extremely cumbersome to use as it would require the admin to manually >>>>> copy it for every new replica and then keep it in sync. >>>>> It would also make it hard to change 'on-line'. >>>>> >>>>> Placeholders should be defined in an object similar to >>>>> cn=ipaConfig,cn=etc,$suffix >>>>> >>>>>> * Is there an already defined syntax for the provisionning >>>>>> template. ('$' is separator attr/value, %{} is substitute >>>>>> pattern...). If not, is it possible to user ': ' as >>>>>> separator ? >>>>> >>>>> Using initial and final ? like in Martin's example doesn't work ? >>>>> >>>>>> * What is the priority. The user can provide the 'homeDirectory' >>>>>> through different methods. Is it ok to use the following order: >>>>>> o the CLI option >>>>>> o the provisionning template >>>>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>>>>> >>>>>> For example, if it exists the provisioning template: >>>>>> /etc/ipa/provisioning/shell-user.template >>>>>> >>>>>> roomnumber$-2 >>>>>> homeDirectory$/home/net/shell-%{uid} >>>>>> loginShell$?shell-plugin-autogenerate? >>>>> >>>>> I do not understand this, we are not building a templating engine here, >>>>> you only have 2 options: >>>>> 1) a required (MUST) attribute has an explicit value >>>>> 2) a require (MUST) attribute has a placeholder value >>>>> >>>>> the placeholder value is fixed per type, and what it is substituted with >>>>> uses the same rules as the current code uses to autogenerate values. >>>>> >>>>>> the command: ipa user-add tuser >>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>>>>> staging entry: >>>>>> >>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>> ... >>>>>> roomNumber: 1234 >>>>>> homeDirectory: /tmp/tuser >>>>>> loginShell: shell-plugin-autogenerate >>>>> >>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should >>>>> be stored at all in the staged entry unless explicitly provided for by >>>>> the admin. >>>>> >>>>>> Then a private DS plugin (catching shell-plugin-autogenerate) >>>>>> generate the loginShell value when the entry becomes active. >>>>>> >>>>>> >>>>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would >>>>>> create a staging entry: >>>>>> >>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>> ... >>>>>> roomNumber: -2 >>>>>> homeDirectory: /tmp/tuser >>>>>> loginShell: shell-plugin-autogenerate >>>>> >>>>> roomNumber is also a MAY, so what would cause it to be set at -2, and >>>>> why ? >>>>> >>>>>> the command: ipa user-add tuser --to-stage would create a staging entry: >>>>>> >>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>> ... >>>>>> roomNumber: -2 >>>>>> homeDirectory: /home/net/shell-tuser >>>>>> loginShell: shell-plugin-autogenerate >>>>> >>>>> homeDirectory should be something like: ?placeholder? IMO, we do not >>>>> really want to play templating here. >>>>> >>>>>> In case the provisioning template does not define 'homeDirectory', >>>>>> then the created entry would take the value from the ipa config >>>>>> definition: >>>>> >>>>> that value should be taken and applied at the time the user is unstaged >>>>> and brought in the actual tree, not at the time a user is staged. >>>>> >>>>> HTH, >>>>> Simo. >>>>> >>>> >>>> Hello Thierry and Simo, >>>> >>>> I think Thierry was confused with this part of the design: >>>> >>>> " >>>> This format of placeholders gives enough space for future enhancements. For >>>> example, Administrator could configure a new template >>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. >>>> Such value would be replaced by "/home/net/tuser if user uid attribute is set >>>> to tuser >>>> " >>>> >>>> My intention when writing this design was to enable future use of >>>> configurable placeholders, i.e. a value "?someplaceholder?" could be turn >>>> into "/custom/path/%{uid}". But I meant that this can be considered as a >>>> future enhancement. For now, I think implementing a placeholder "-1" for >>>> numerical values and "?autogenerate?" for string ones a good start. >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> Please consider the flow: user added staged -> activated/moved to main tree -> >>> deleted/moved to deleted tree -> staged back >>> At the first step his IPA user ID and UID should be undefined and autogenerated. >>> On the last step his IPAUserID and UID should be preserved. The main use case >>> is that this is the user who left the company who comes back again. His files >>> should be still owned by him unless admin forces a flush of his IDs (new >>> switch???) when he moves user from deleted to staged. >>> >> >> Right, the life-cycle feature should work like that naturally, given that only >> attributes with "-1" or "autogenerate" are generated. >> >> If admin wants to re-generate the IDs, all he would need to do is to change the >> attributes back to "-1" after/before moving the user to staging. Question is >> when it should be done (in deleted tree, in staging tree or after activation) >> and what API/command we choose. > > TBH I question the whole idea of "moving to staging", in what case would > that make sense ? > >> Admin may want to change not only the UID/GID, but maybe also a home directory >> (user may be in a different department) so we should make it general. Maybe we >> should let user-mod support modification in staging area? Like >> >> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged >> >> or >> >> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted > > The reason why we have the 'deleted' area is to be able to preserve the > user intact ... I would almost want to ask to explicitly not allow > modifications to deleted users (admin can always use ldapmodify if they > *really* need to play some game here). +1, it seemed strange to me that modifying deleted user was allowed as well. > > Simo. > -- Jan Cholasta From mkosek at redhat.com Fri May 23 06:29:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 08:29:01 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537E1D23.6080703@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> Message-ID: <537EEAAD.7020308@redhat.com> On 05/22/2014 05:52 PM, thierry bordaz wrote: > On 05/22/2014 04:38 PM, Martin Kosek wrote: >> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>>> 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=newemail at 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 >>>> >>>> I like the idea of different verbs for different hives. >>>> Something like: >>>> >>>> Adding directly to stage via CLI: ipa user-stage >>>> Removing from stage: user-unstage (user is gone) >>>> Stage to Main -> activate; <- deactivate >>>> Main to delete -> del; <-restore or undelete >>>> Delete to stage -> I think we can use ipa user-stage command with >>>> --deleted=user or similar >>> To be honest, I don't like this idea. >>> Too many names are confusing, if we can find a consistent option to cut the >>> number of names down we should do it. >>> IMO This is the worst part of Git: >>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >>> >>> Another good thing would be if options did not affect the applicability of >>> other options (too much). For example in your proposal there'd be something >>> like: >>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >>> ipa user-stage --deleted=tuser # >>> We should avoid this, if only for the reason that it makes the help text >>> confusing. >>> >>> >>> My proposal would be that the move commands use the verb for the target and an >>> option for the source, and add/mod use an option for the container: >>> >>> 1) adding a new user >>> (to active) ipa user-add tuser ... >>> (to stage) ipa user-add tuser --staged ... >>> (to deleted) ipa user-add tuser --deleted ... (*) >>> >>> 2) moving to main >>> (from stage) ipa user-activate tuser (**) >>> (from del) ipa user-activate tuser --deleted >>> >>> 3) moving to deleted >>> (from active) ipa user-del tuser >>> (from stage) ipa user-del tuser --staged >>> >>> 4) moving to stage >>> (from active) ipa user-stage tuser >>> (from del) ipa user-stage tuser --deleted >>> >>> 5) modifying >>> (in active) ipa user-mod tuser ... >>> (in stage) ipa user-mod tuser --staged ... >>> (in del) ipa user-mod tuser --deleted ... >>> >>> Five commands (two of which are user-specific), plus two fairly consistent >>> options. >>> >>> If the delete container isn't configured, the --deleted option is illegal and >>> `user-del` deletes permanently. >>> >>> >>> (*) may be useful in some situations? >> I personally cannot imagine such situation - I would not add this command. If >> somebody needs that, he can workaround with >> >> ipa user-add tuser --staged >> ipa user-del tuser --staged >> >> ... and report us the use case when it's needed. But I general, Petr's proposal >> makes sense to me, I would go for it. (and update the design as Dmitri >> correctly proposed). >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello, > > I will update the design following Petr proposal. Great one ! > However I was thinking to a sligthly different proposal. For > example if we have 3 states: staging, active, inactive. I personally think that inactive state may be confusing. Is inactive deleted user? Or staged user? Or active disabled user (user-disable command)? Inactive state would have too many meanings. The previously proposed states active, staging and deleted sounds clearer to me. > 1) adding a user > > (...to active) ipa user-add# ( after the command > ipaUniqueID=) > (... to staging) ipa user-add --stage# (after the command > ipaUniqueID=generate) > > So here we can not add a user directly into inactive state If by inactive you mean deleted, then yes. > > 2) activating the user > > (staging to active) ipa user-activate# (after the command > ipaUniqueID=) > (inactive to active) ipa user-activate --inactive# (after the > command ipaUniqueID=) --inactive -> --deleted > > 3) inactivate the user > > (active to inactive) ipa user-inactivate# (after the command > ipaUniqueID=) > > Here there is no possibility to move back an active entry to > staging, because in staging > the entries do not have ipaUniqueID set Why is having ipaUniqueID attribute a problem for a staged user? The command to "inactivate" the user is user-del. > > 4) modify the user > > (from active) ipa user-mod # (after the command > ipaUniqueID=) > (from inactive) ipa user-mod --inactive# (after the > command ipaUniqueID=) --inactive -> --deleted > (from staging) ipa user-mod --stage # (after the command > ipaUniqueID=generate) > > > 5) delete user > > (staging to delete) ipa user-del > (inactive to delete) ipa user-del --inactive > > Here the entries are definitely removed I would stick to original proposal: (from active) ipa user-del tuser (from stage) ipa user-del tuser --staged Martin From mkosek at redhat.com Fri May 23 06:33:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 08:33:02 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537EE125.20404@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> Message-ID: <537EEB9E.4050306@redhat.com> On 05/23/2014 07:48 AM, Jan Cholasta wrote: > On 22.5.2014 19:27, Simo Sorce wrote: >> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: >>> On 05/21/2014 10:11 PM, Dmitri Pal wrote: >>>> On 05/21/2014 03:06 PM, Martin Kosek wrote: >>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Thanks for all these detailed descriptions. >>>>>>> Just to be sure to be on the same page, here is my understanding of >>>>>>> the provisioning templates and placeholder definitions. An >>>>>>> administrator can provide a provisioning template. I suppose it >>>>>>> would be a file containing a lines of placeholder definitions. >>>>>>> >>>>>>> * Where is located the template file ? Is there a standard >>>>>>> repository where templates are put ? (somewhere under >>>>>>> /etc/ipa/* ?) >>>>>> >>>>>> FreeIPA is a multi-master system, a file stored in a file would be >>>>>> extremely cumbersome to use as it would require the admin to manually >>>>>> copy it for every new replica and then keep it in sync. >>>>>> It would also make it hard to change 'on-line'. >>>>>> >>>>>> Placeholders should be defined in an object similar to >>>>>> cn=ipaConfig,cn=etc,$suffix >>>>>> >>>>>>> * Is there an already defined syntax for the provisionning >>>>>>> template. ('$' is separator attr/value, %{} is substitute >>>>>>> pattern...). If not, is it possible to user ': ' as >>>>>>> separator ? >>>>>> >>>>>> Using initial and final ? like in Martin's example doesn't work ? >>>>>> >>>>>>> * What is the priority. The user can provide the 'homeDirectory' >>>>>>> through different methods. Is it ok to use the following order: >>>>>>> o the CLI option >>>>>>> o the provisionning template >>>>>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>>>>>> >>>>>>> For example, if it exists the provisioning template: >>>>>>> /etc/ipa/provisioning/shell-user.template >>>>>>> >>>>>>> roomnumber$-2 >>>>>>> homeDirectory$/home/net/shell-%{uid} >>>>>>> loginShell$?shell-plugin-autogenerate? >>>>>> >>>>>> I do not understand this, we are not building a templating engine here, >>>>>> you only have 2 options: >>>>>> 1) a required (MUST) attribute has an explicit value >>>>>> 2) a require (MUST) attribute has a placeholder value >>>>>> >>>>>> the placeholder value is fixed per type, and what it is substituted with >>>>>> uses the same rules as the current code uses to autogenerate values. >>>>>> >>>>>>> the command: ipa user-add tuser >>>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>>>>>> staging entry: >>>>>>> >>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>> ... >>>>>>> roomNumber: 1234 >>>>>>> homeDirectory: /tmp/tuser >>>>>>> loginShell: shell-plugin-autogenerate >>>>>> >>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should >>>>>> be stored at all in the staged entry unless explicitly provided for by >>>>>> the admin. >>>>>> >>>>>>> Then a private DS plugin (catching shell-plugin-autogenerate) >>>>>>> generate the loginShell value when the entry becomes active. >>>>>>> >>>>>>> >>>>>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would >>>>>>> create a staging entry: >>>>>>> >>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>> ... >>>>>>> roomNumber: -2 >>>>>>> homeDirectory: /tmp/tuser >>>>>>> loginShell: shell-plugin-autogenerate >>>>>> >>>>>> roomNumber is also a MAY, so what would cause it to be set at -2, and >>>>>> why ? >>>>>> >>>>>>> the command: ipa user-add tuser --to-stage would create a staging >>>>>>> entry: >>>>>>> >>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>> ... >>>>>>> roomNumber: -2 >>>>>>> homeDirectory: /home/net/shell-tuser >>>>>>> loginShell: shell-plugin-autogenerate >>>>>> >>>>>> homeDirectory should be something like: ?placeholder? IMO, we do not >>>>>> really want to play templating here. >>>>>> >>>>>>> In case the provisioning template does not define 'homeDirectory', >>>>>>> then the created entry would take the value from the ipa config >>>>>>> definition: >>>>>> >>>>>> that value should be taken and applied at the time the user is unstaged >>>>>> and brought in the actual tree, not at the time a user is staged. >>>>>> >>>>>> HTH, >>>>>> Simo. >>>>>> >>>>> >>>>> Hello Thierry and Simo, >>>>> >>>>> I think Thierry was confused with this part of the design: >>>>> >>>>> " >>>>> This format of placeholders gives enough space for future enhancements. For >>>>> example, Administrator could configure a new template >>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. >>>>> Such value would be replaced by "/home/net/tuser if user uid attribute is set >>>>> to tuser >>>>> " >>>>> >>>>> My intention when writing this design was to enable future use of >>>>> configurable placeholders, i.e. a value "?someplaceholder?" could be turn >>>>> into "/custom/path/%{uid}". But I meant that this can be considered as a >>>>> future enhancement. For now, I think implementing a placeholder "-1" for >>>>> numerical values and "?autogenerate?" for string ones a good start. >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> >>>> Please consider the flow: user added staged -> activated/moved to main tree -> >>>> deleted/moved to deleted tree -> staged back >>>> At the first step his IPA user ID and UID should be undefined and >>>> autogenerated. >>>> On the last step his IPAUserID and UID should be preserved. The main use case >>>> is that this is the user who left the company who comes back again. His files >>>> should be still owned by him unless admin forces a flush of his IDs (new >>>> switch???) when he moves user from deleted to staged. >>>> >>> >>> Right, the life-cycle feature should work like that naturally, given that only >>> attributes with "-1" or "autogenerate" are generated. >>> >>> If admin wants to re-generate the IDs, all he would need to do is to change the >>> attributes back to "-1" after/before moving the user to staging. Question is >>> when it should be done (in deleted tree, in staging tree or after activation) >>> and what API/command we choose. >> >> TBH I question the whole idea of "moving to staging", in what case would >> that make sense ? >> >>> Admin may want to change not only the UID/GID, but maybe also a home directory >>> (user may be in a different department) so we should make it general. Maybe we >>> should let user-mod support modification in staging area? Like >>> >>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged >>> >>> or >>> >>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted >> >> The reason why we have the 'deleted' area is to be able to preserve the >> user intact ... I would almost want to ask to explicitly not allow >> modifications to deleted users (admin can always use ldapmodify if they >> *really* need to play some game here). > > +1, it seemed strange to me that modifying deleted user was allowed as well. Hm, ok, let us not have an API to modify deleted user then. As for active -> staging users flow, I only think of one scenario: 1) Operator moves staged user to active users 2) Operator realizes that his mouse slipped and he moved a wrong person 3) Operator wants to move the person quickly back to staged before anyone notices :) Martin From tbordaz at redhat.com Fri May 23 07:34:15 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 May 2014 09:34:15 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537EEAAD.7020308@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <537EEAAD.7020308@redhat.com> Message-ID: <537EF9F7.9010909@redhat.com> On 05/23/2014 08:29 AM, Martin Kosek wrote: > On 05/22/2014 05:52 PM, thierry bordaz wrote: >> On 05/22/2014 04:38 PM, Martin Kosek wrote: >>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>>>> 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=newemail at 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 >>>>> I like the idea of different verbs for different hives. >>>>> Something like: >>>>> >>>>> Adding directly to stage via CLI: ipa user-stage >>>>> Removing from stage: user-unstage (user is gone) >>>>> Stage to Main -> activate; <- deactivate >>>>> Main to delete -> del; <-restore or undelete >>>>> Delete to stage -> I think we can use ipa user-stage command with >>>>> --deleted=user or similar >>>> To be honest, I don't like this idea. >>>> Too many names are confusing, if we can find a consistent option to cut the >>>> number of names down we should do it. >>>> IMO This is the worst part of Git: >>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >>>> >>>> Another good thing would be if options did not affect the applicability of >>>> other options (too much). For example in your proposal there'd be something >>>> like: >>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >>>> ipa user-stage --deleted=tuser # >>>> We should avoid this, if only for the reason that it makes the help text >>>> confusing. >>>> >>>> >>>> My proposal would be that the move commands use the verb for the target and an >>>> option for the source, and add/mod use an option for the container: >>>> >>>> 1) adding a new user >>>> (to active) ipa user-add tuser ... >>>> (to stage) ipa user-add tuser --staged ... >>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>> >>>> 2) moving to main >>>> (from stage) ipa user-activate tuser (**) >>>> (from del) ipa user-activate tuser --deleted >>>> >>>> 3) moving to deleted >>>> (from active) ipa user-del tuser >>>> (from stage) ipa user-del tuser --staged >>>> >>>> 4) moving to stage >>>> (from active) ipa user-stage tuser >>>> (from del) ipa user-stage tuser --deleted >>>> >>>> 5) modifying >>>> (in active) ipa user-mod tuser ... >>>> (in stage) ipa user-mod tuser --staged ... >>>> (in del) ipa user-mod tuser --deleted ... >>>> >>>> Five commands (two of which are user-specific), plus two fairly consistent >>>> options. >>>> >>>> If the delete container isn't configured, the --deleted option is illegal and >>>> `user-del` deletes permanently. >>>> >>>> >>>> (*) may be useful in some situations? >>> I personally cannot imagine such situation - I would not add this command. If >>> somebody needs that, he can workaround with >>> >>> ipa user-add tuser --staged >>> ipa user-del tuser --staged >>> >>> ... and report us the use case when it's needed. But I general, Petr's proposal >>> makes sense to me, I would go for it. (and update the design as Dmitri >>> correctly proposed). >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello, >> >> I will update the design following Petr proposal. Great one ! >> However I was thinking to a sligthly different proposal. For >> example if we have 3 states: staging, active, inactive. > I personally think that inactive state may be confusing. Is inactive deleted > user? Or staged user? Or active disabled user (user-disable command)? Inactive > state would have too many meanings. The previously proposed states active, > staging and deleted sounds clearer to me. Correct. Inactive is confusing and I prefer 'disabled'. For me a 'disabled' used is a user that has been 'active' (should I say 'enabled'). That means he/she has a uidNumber/guidNUmber/ipaUniqueiD set... , in addition it is in a dedicated container and likely 'nsaccountlock: yes'. >> 1) adding a user >> >> (...to active) ipa user-add# ( after the command >> ipaUniqueID=) >> (... to staging) ipa user-add --stage# (after the command >> ipaUniqueID=generate) >> >> So here we can not add a user directly into inactive state > If by inactive you mean deleted, then yes. Yes I was meaning 'inactive' as 'deleted' in Petr proposal. I do not like very much the word 'deleted' because in term of LDAP it has a different meaning. In term of User life cycle, I have a feeling that 'delete' is a final state, we can not return from 'delete'. This is why I prefered 'inactive' or now 'disabled'. > >> 2) activating the user >> >> (staging to active) ipa user-activate# (after the command >> ipaUniqueID=) >> (inactive to active) ipa user-activate --inactive# (after the >> command ipaUniqueID=) > --inactive -> --deleted > >> 3) inactivate the user >> >> (active to inactive) ipa user-inactivate# (after the command >> ipaUniqueID=) >> >> Here there is no possibility to move back an active entry to >> staging, because in staging >> the entries do not have ipaUniqueID set > Why is having ipaUniqueID attribute a problem for a staged user? My understanding is that an account moves from 'staging' to 'active' when we receive a formal approval. Before the approval, the ipaUniqueID is 'generate' and after it is a valid account. For example, the user attribute should be: Staging Active Disabled ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID: abc-def-ghi-jkl uidNumber: -1 uidNumber: 1234uidNumber: 1234 gidNumber: -1 gidNumber: 1234gidNumber: 1234 attribute memberof: * : nsaccountlock: true nsaccountlock: false nsaccountlock: true > > The command to "inactivate" the user is user-del. > >> 4) modify the user >> >> (from active) ipa user-mod # (after the command >> ipaUniqueID=) >> (from inactive) ipa user-mod --inactive# (after the >> command ipaUniqueID=) > --inactive -> --deleted > >> (from staging) ipa user-mod --stage # (after the command >> ipaUniqueID=generate) >> >> >> 5) delete user >> >> (staging to delete) ipa user-del >> (inactive to delete) ipa user-del --inactive >> >> Here the entries are definitely removed > I would stick to original proposal: > > (from active) ipa user-del tuser > (from stage) ipa user-del tuser --staged Is this command to move entry from active/staging into delete container. How to delete definitely an entry ? with a option like '--remove' ? > > Martin From mkosek at redhat.com Fri May 23 08:04:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 10:04:45 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537EF9F7.9010909@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <537EEAAD.7020308@redhat.com> <537EF9F7.9010909@redhat.com> Message-ID: <537F011D.8090001@redhat.com> On 05/23/2014 09:34 AM, thierry bordaz wrote: > On 05/23/2014 08:29 AM, Martin Kosek wrote: >> On 05/22/2014 05:52 PM, thierry bordaz wrote: >>> On 05/22/2014 04:38 PM, Martin Kosek wrote: >>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>>>>> 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=newemail at 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 >>>>>> I like the idea of different verbs for different hives. >>>>>> Something like: >>>>>> >>>>>> Adding directly to stage via CLI: ipa user-stage >>>>>> Removing from stage: user-unstage (user is gone) >>>>>> Stage to Main -> activate; <- deactivate >>>>>> Main to delete -> del; <-restore or undelete >>>>>> Delete to stage -> I think we can use ipa user-stage command with >>>>>> --deleted=user or similar >>>>> To be honest, I don't like this idea. >>>>> Too many names are confusing, if we can find a consistent option to cut the >>>>> number of names down we should do it. >>>>> IMO This is the worst part of Git: >>>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >>>>> >>>>> Another good thing would be if options did not affect the applicability of >>>>> other options (too much). For example in your proposal there'd be something >>>>> like: >>>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >>>>> ipa user-stage --deleted=tuser # >>>>> We should avoid this, if only for the reason that it makes the help text >>>>> confusing. >>>>> >>>>> >>>>> My proposal would be that the move commands use the verb for the target >>>>> and an >>>>> option for the source, and add/mod use an option for the container: >>>>> >>>>> 1) adding a new user >>>>> (to active) ipa user-add tuser ... >>>>> (to stage) ipa user-add tuser --staged ... >>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>> >>>>> 2) moving to main >>>>> (from stage) ipa user-activate tuser (**) >>>>> (from del) ipa user-activate tuser --deleted >>>>> >>>>> 3) moving to deleted >>>>> (from active) ipa user-del tuser >>>>> (from stage) ipa user-del tuser --staged >>>>> >>>>> 4) moving to stage >>>>> (from active) ipa user-stage tuser >>>>> (from del) ipa user-stage tuser --deleted >>>>> >>>>> 5) modifying >>>>> (in active) ipa user-mod tuser ... >>>>> (in stage) ipa user-mod tuser --staged ... >>>>> (in del) ipa user-mod tuser --deleted ... >>>>> >>>>> Five commands (two of which are user-specific), plus two fairly consistent >>>>> options. >>>>> >>>>> If the delete container isn't configured, the --deleted option is illegal and >>>>> `user-del` deletes permanently. >>>>> >>>>> >>>>> (*) may be useful in some situations? >>>> I personally cannot imagine such situation - I would not add this command. If >>>> somebody needs that, he can workaround with >>>> >>>> ipa user-add tuser --staged >>>> ipa user-del tuser --staged >>>> >>>> ... and report us the use case when it's needed. But I general, Petr's >>>> proposal >>>> makes sense to me, I would go for it. (and update the design as Dmitri >>>> correctly proposed). >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Hello, >>> >>> I will update the design following Petr proposal. Great one ! >>> However I was thinking to a sligthly different proposal. For >>> example if we have 3 states: staging, active, inactive. >> I personally think that inactive state may be confusing. Is inactive deleted >> user? Or staged user? Or active disabled user (user-disable command)? Inactive >> state would have too many meanings. The previously proposed states active, >> staging and deleted sounds clearer to me. > Correct. Inactive is confusing and I prefer 'disabled'. > For me a 'disabled' used is a user that has been 'active' (should I say > 'enabled'). That means he/she has a uidNumber/guidNUmber/ipaUniqueiD set... , > in addition it is in a dedicated container and likely 'nsaccountlock: yes'. In terms of FreeIPA vocabulary, disabled user is a user in an active user container, but switch to disabled (nsaccountlock is yes). It can be easile enabled with "ipa user-enable" command. I.e. "disabled user" term is already taken and actively user for other state. >>> 1) adding a user >>> >>> (...to active) ipa user-add# ( after the command >>> ipaUniqueID=) >>> (... to staging) ipa user-add --stage# (after the command >>> ipaUniqueID=generate) >>> >>> So here we can not add a user directly into inactive state >> If by inactive you mean deleted, then yes. > Yes I was meaning 'inactive' as 'deleted' in Petr proposal. > I do not like very much the word 'deleted' because in term of LDAP it has a > different meaning. > In term of User life cycle, I have a feeling that 'delete' is a final state, we > can not return from 'delete'. This is why I prefered 'inactive' or now 'disabled'. Ok, I see your point in the meaning from LDAP POV. However, we cannot use 'inactive' as it is confusing and we cannot use 'disabled' as it is already used in other scenario. That leaves us with 'delete' state which IMO is consistent in FreeIPA vocabulary - user is moved to *deleted users* container with user-*del* command. >>> 2) activating the user >>> >>> (staging to active) ipa user-activate# (after the command >>> ipaUniqueID=) >>> (inactive to active) ipa user-activate --inactive# (after the >>> command ipaUniqueID=) >> --inactive -> --deleted >> >>> 3) inactivate the user >>> >>> (active to inactive) ipa user-inactivate# (after the command >>> ipaUniqueID=) >>> >>> Here there is no possibility to move back an active entry to >>> staging, because in staging >>> the entries do not have ipaUniqueID set >> Why is having ipaUniqueID attribute a problem for a staged user? > My understanding is that an account moves from 'staging' to 'active' when we > receive a formal approval. Right. > Before the approval, the ipaUniqueID is 'generate' > and after it is a valid account. Right. > > For example, the user attribute should be: > > Staging Active Disabled > ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID: > abc-def-ghi-jkl > uidNumber: -1 uidNumber: 1234uidNumber: 1234 > gidNumber: -1 gidNumber: 1234gidNumber: 1234 > attribute memberof: * memberof>: > nsaccountlock: true nsaccountlock: false > nsaccountlock: true Nice overview, we may even add it to design. Looks correct to me, though I still do not undestand practical reasons why a user moved from active to staged container cannot have ipaUniqueID already generated. >> >> The command to "inactivate" the user is user-del. >> >>> 4) modify the user >>> >>> (from active) ipa user-mod # (after the command >>> ipaUniqueID=) >>> (from inactive) ipa user-mod --inactive# (after the >>> command ipaUniqueID=) >> --inactive -> --deleted >> >>> (from staging) ipa user-mod --stage # (after the command >>> ipaUniqueID=generate) >>> >>> >>> 5) delete user >>> >>> (staging to delete) ipa user-del >>> (inactive to delete) ipa user-del --inactive >>> >>> Here the entries are definitely removed >> I would stick to original proposal: >> >> (from active) ipa user-del tuser >> (from stage) ipa user-del tuser --staged > Is this command to move entry from active/staging into delete container. > How to delete definitely an entry ? with a option like '--remove' ? The move from active users to deleted users container was planned to be done by a plugin so that a simple ldapdelete can be called and the user is saved: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User To delete permanently, we could offer ipa user-del tuser --deleted command. (Or do not offer the command at all and force admins to use ldapdelete to *permanently* delete the account). Missing this API should not be a problem as in most small-scale deployments, advanced user life-cycle will not be enabled. Martin From tbordaz at redhat.com Fri May 23 08:07:27 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 May 2014 10:07:27 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <1400779286.7561.93.camel@willson.li.ssimo.org> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <1400779286.7561.93.camel@willson.li.ssimo.org> Message-ID: <537F01BF.1090703@redhat.com> On 05/22/2014 07:21 PM, Simo Sorce wrote: > On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote: >> On 05/22/2014 04:38 PM, Martin Kosek wrote: >>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>>>> 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=newemail at 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 >>>>> I like the idea of different verbs for different hives. >>>>> Something like: >>>>> >>>>> Adding directly to stage via CLI: ipa user-stage >>>>> Removing from stage: user-unstage (user is gone) >>>>> Stage to Main -> activate; <- deactivate >>>>> Main to delete -> del; <-restore or undelete >>>>> Delete to stage -> I think we can use ipa user-stage command with >>>>> --deleted=user or similar >>>> To be honest, I don't like this idea. >>>> Too many names are confusing, if we can find a consistent option to cut the >>>> number of names down we should do it. >>>> IMO This is the worst part of Git: >>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >>>> >>>> Another good thing would be if options did not affect the applicability of >>>> other options (too much). For example in your proposal there'd be something like: >>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >>>> ipa user-stage --deleted=tuser # >>>> We should avoid this, if only for the reason that it makes the help text >>>> confusing. >>>> >>>> >>>> My proposal would be that the move commands use the verb for the target and an >>>> option for the source, and add/mod use an option for the container: >>>> >>>> 1) adding a new user >>>> (to active) ipa user-add tuser ... >>>> (to stage) ipa user-add tuser --staged ... >>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>> >>>> 2) moving to main >>>> (from stage) ipa user-activate tuser (**) >>>> (from del) ipa user-activate tuser --deleted >>>> >>>> 3) moving to deleted >>>> (from active) ipa user-del tuser >>>> (from stage) ipa user-del tuser --staged >>>> >>>> 4) moving to stage >>>> (from active) ipa user-stage tuser >>>> (from del) ipa user-stage tuser --deleted >>>> >>>> 5) modifying >>>> (in active) ipa user-mod tuser ... >>>> (in stage) ipa user-mod tuser --staged ... >>>> (in del) ipa user-mod tuser --deleted ... >>>> >>>> Five commands (two of which are user-specific), plus two fairly consistent >>>> options. >>>> >>>> If the delete container isn't configured, the --deleted option is illegal and >>>> `user-del` deletes permanently. >>>> >>>> >>>> (*) may be useful in some situations? >>> I personally cannot imagine such situation - I would not add this command. If >>> somebody needs that, he can workaround with >>> >>> ipa user-add tuser --staged >>> ipa user-del tuser --staged >>> >>> ... and report us the use case when it's needed. But I general, Petr's proposal >>> makes sense to me, I would go for it. (and update the design as Dmitri >>> correctly proposed). >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello, >> >> I will update the design following Petr proposal. Great one ! >> However I was thinking to a sligthly different proposal. For >> example if we have 3 states: staging, active, inactive. >> 1) adding a user >> >> (...to active) ipa user-add# ( after the command >> ipaUniqueID=) >> (... to staging) ipa user-add --stage# (after the command >> ipaUniqueID=generate) >> >> So here we can not add a user directly into inactive state >> >> 2) activating the user >> >> (staging to active) ipa user-activate# (after the command >> ipaUniqueID=) >> (inactive to active) ipa user-activate --inactive# (after the >> command ipaUniqueID=) >> >> 3) inactivate the user >> >> (active to inactive) ipa user-inactivate# (after the command >> ipaUniqueID=) >> >> Here there is no possibility to move back an active entry to >> staging, because in staging >> the entries do not have ipaUniqueID set > Do we ever want to allow to move a user from active to staging ? > > I can't find a case where my answer is yes. > > From my POV a user once it leaves staging is either active or deleted, > in my mind there is no reason ever to move a user into staging. > > In what case does it make sense ? > > Simo. > Hi Simo, When moving an entry 'staging' -> 'active', some attributes are set (at least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes are set for ever even if later the entry is moved 'active'->'deleted'. One can imagine that an administrator is not "happy" with the values computed. For example, he would prefer uidNumber to be computed from an other range. For that, moving back the entry from 'active' -> 'staging' would be an option (if those attributes are 'reset'). I do not know if it is a valid use case but IMHO I would prefere he moves the entry 'active'->'delete' then delete the entry and recreate a new one. regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri May 23 08:13:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 May 2014 10:13:18 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537EEB9E.4050306@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> Message-ID: <537F031E.8070701@redhat.com> On 05/23/2014 08:33 AM, Martin Kosek wrote: > On 05/23/2014 07:48 AM, Jan Cholasta wrote: >> On 22.5.2014 19:27, Simo Sorce wrote: >>> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: >>>> On 05/21/2014 10:11 PM, Dmitri Pal wrote: >>>>> On 05/21/2014 03:06 PM, Martin Kosek wrote: >>>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Thanks for all these detailed descriptions. >>>>>>>> Just to be sure to be on the same page, here is my understanding of >>>>>>>> the provisioning templates and placeholder definitions. An >>>>>>>> administrator can provide a provisioning template. I suppose it >>>>>>>> would be a file containing a lines of placeholder definitions. >>>>>>>> >>>>>>>> * Where is located the template file ? Is there a standard >>>>>>>> repository where templates are put ? (somewhere under >>>>>>>> /etc/ipa/* ?) >>>>>>> >>>>>>> FreeIPA is a multi-master system, a file stored in a file would be >>>>>>> extremely cumbersome to use as it would require the admin to manually >>>>>>> copy it for every new replica and then keep it in sync. >>>>>>> It would also make it hard to change 'on-line'. >>>>>>> >>>>>>> Placeholders should be defined in an object similar to >>>>>>> cn=ipaConfig,cn=etc,$suffix >>>>>>> >>>>>>>> * Is there an already defined syntax for the provisionning >>>>>>>> template. ('$' is separator attr/value, %{} is substitute >>>>>>>> pattern...). If not, is it possible to user ': ' as >>>>>>>> separator ? >>>>>>> >>>>>>> Using initial and final ? like in Martin's example doesn't work ? >>>>>>> >>>>>>>> * What is the priority. The user can provide the 'homeDirectory' >>>>>>>> through different methods. Is it ok to use the following order: >>>>>>>> o the CLI option >>>>>>>> o the provisionning template >>>>>>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>>>>>>> >>>>>>>> For example, if it exists the provisioning template: >>>>>>>> /etc/ipa/provisioning/shell-user.template >>>>>>>> >>>>>>>> roomnumber$-2 >>>>>>>> homeDirectory$/home/net/shell-%{uid} >>>>>>>> loginShell$?shell-plugin-autogenerate? >>>>>>> >>>>>>> I do not understand this, we are not building a templating engine here, >>>>>>> you only have 2 options: >>>>>>> 1) a required (MUST) attribute has an explicit value >>>>>>> 2) a require (MUST) attribute has a placeholder value >>>>>>> >>>>>>> the placeholder value is fixed per type, and what it is substituted with >>>>>>> uses the same rules as the current code uses to autogenerate values. >>>>>>> >>>>>>>> the command: ipa user-add tuser >>>>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>>>>>>> staging entry: >>>>>>>> >>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>> ... >>>>>>>> roomNumber: 1234 >>>>>>>> homeDirectory: /tmp/tuser >>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>> >>>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should >>>>>>> be stored at all in the staged entry unless explicitly provided for by >>>>>>> the admin. >>>>>>> >>>>>>>> Then a private DS plugin (catching shell-plugin-autogenerate) >>>>>>>> generate the loginShell value when the entry becomes active. >>>>>>>> >>>>>>>> >>>>>>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would >>>>>>>> create a staging entry: >>>>>>>> >>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>> ... >>>>>>>> roomNumber: -2 >>>>>>>> homeDirectory: /tmp/tuser >>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>> >>>>>>> roomNumber is also a MAY, so what would cause it to be set at -2, and >>>>>>> why ? >>>>>>> >>>>>>>> the command: ipa user-add tuser --to-stage would create a staging >>>>>>>> entry: >>>>>>>> >>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>> ... >>>>>>>> roomNumber: -2 >>>>>>>> homeDirectory: /home/net/shell-tuser >>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>> >>>>>>> homeDirectory should be something like: ?placeholder? IMO, we do not >>>>>>> really want to play templating here. >>>>>>> >>>>>>>> In case the provisioning template does not define 'homeDirectory', >>>>>>>> then the created entry would take the value from the ipa config >>>>>>>> definition: >>>>>>> >>>>>>> that value should be taken and applied at the time the user is unstaged >>>>>>> and brought in the actual tree, not at the time a user is staged. >>>>>>> >>>>>>> HTH, >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> Hello Thierry and Simo, >>>>>> >>>>>> I think Thierry was confused with this part of the design: >>>>>> >>>>>> " >>>>>> This format of placeholders gives enough space for future enhancements. For >>>>>> example, Administrator could configure a new template >>>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. >>>>>> Such value would be replaced by "/home/net/tuser if user uid attribute is set >>>>>> to tuser >>>>>> " >>>>>> >>>>>> My intention when writing this design was to enable future use of >>>>>> configurable placeholders, i.e. a value "?someplaceholder?" could be turn >>>>>> into "/custom/path/%{uid}". But I meant that this can be considered as a >>>>>> future enhancement. For now, I think implementing a placeholder "-1" for >>>>>> numerical values and "?autogenerate?" for string ones a good start. >>>>>> >>>>>> Martin >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> >>>>> Please consider the flow: user added staged -> activated/moved to main tree -> >>>>> deleted/moved to deleted tree -> staged back >>>>> At the first step his IPA user ID and UID should be undefined and >>>>> autogenerated. >>>>> On the last step his IPAUserID and UID should be preserved. The main use case >>>>> is that this is the user who left the company who comes back again. His files >>>>> should be still owned by him unless admin forces a flush of his IDs (new >>>>> switch???) when he moves user from deleted to staged. >>>>> >>>> >>>> Right, the life-cycle feature should work like that naturally, given that only >>>> attributes with "-1" or "autogenerate" are generated. >>>> >>>> If admin wants to re-generate the IDs, all he would need to do is to change the >>>> attributes back to "-1" after/before moving the user to staging. Question is >>>> when it should be done (in deleted tree, in staging tree or after activation) >>>> and what API/command we choose. >>> >>> TBH I question the whole idea of "moving to staging", in what case would >>> that make sense ? >>> >>>> Admin may want to change not only the UID/GID, but maybe also a home directory >>>> (user may be in a different department) so we should make it general. Maybe we >>>> should let user-mod support modification in staging area? Like >>>> >>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged >>>> >>>> or >>>> >>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted >>> >>> The reason why we have the 'deleted' area is to be able to preserve the >>> user intact ... I would almost want to ask to explicitly not allow >>> modifications to deleted users (admin can always use ldapmodify if they >>> *really* need to play some game here). >> >> +1, it seemed strange to me that modifying deleted user was allowed as well. > > Hm, ok, let us not have an API to modify deleted user then. Here's a scenario: - automember is set to add users the appropriate groups when userclass is set to "junior admin", or "senior admin" - Johnny the Junior Admin leaves the company, is deleted - After some time Johnny joins again as Senior Admin I think in this case we'd want to set the userclass to "senior admin" before restoring the user. Other changes (e.g. a name change) can be done after restoring the user, but it still seems cleaner for me if they could be done on the deleted user (or if the deleted user could be restored to stage first). There may be other plugins that run on add and expect current information. > As for active -> staging users flow, I only think of one scenario: > > 1) Operator moves staged user to active users > 2) Operator realizes that his mouse slipped and he moved a wrong person > 3) Operator wants to move the person quickly back to staged before anyone > notices :) > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Petr? From tbordaz at redhat.com Fri May 23 08:22:54 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 May 2014 10:22:54 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537F011D.8090001@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <537EEAAD.7020308@redhat.com> <537EF9F7.9010909@redhat.com> <537F011D.8090001@redhat.com> Message-ID: <537F055E.1010200@redhat.com> On 05/23/2014 10:04 AM, Martin Kosek wrote: > On 05/23/2014 09:34 AM, thierry bordaz wrote: >> On 05/23/2014 08:29 AM, Martin Kosek wrote: >>> On 05/22/2014 05:52 PM, thierry bordaz wrote: >>>> On 05/22/2014 04:38 PM, Martin Kosek wrote: >>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>>>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>>>>>> 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=newemail at 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 >>>>>>> I like the idea of different verbs for different hives. >>>>>>> Something like: >>>>>>> >>>>>>> Adding directly to stage via CLI: ipa user-stage >>>>>>> Removing from stage: user-unstage (user is gone) >>>>>>> Stage to Main -> activate; <- deactivate >>>>>>> Main to delete -> del; <-restore or undelete >>>>>>> Delete to stage -> I think we can use ipa user-stage command with >>>>>>> --deleted=user or similar >>>>>> To be honest, I don't like this idea. >>>>>> Too many names are confusing, if we can find a consistent option to cut the >>>>>> number of names down we should do it. >>>>>> IMO This is the worst part of Git: >>>>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >>>>>> >>>>>> Another good thing would be if options did not affect the applicability of >>>>>> other options (too much). For example in your proposal there'd be something >>>>>> like: >>>>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >>>>>> ipa user-stage --deleted=tuser # >>>>>> We should avoid this, if only for the reason that it makes the help text >>>>>> confusing. >>>>>> >>>>>> >>>>>> My proposal would be that the move commands use the verb for the target >>>>>> and an >>>>>> option for the source, and add/mod use an option for the container: >>>>>> >>>>>> 1) adding a new user >>>>>> (to active) ipa user-add tuser ... >>>>>> (to stage) ipa user-add tuser --staged ... >>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>> >>>>>> 2) moving to main >>>>>> (from stage) ipa user-activate tuser (**) >>>>>> (from del) ipa user-activate tuser --deleted >>>>>> >>>>>> 3) moving to deleted >>>>>> (from active) ipa user-del tuser >>>>>> (from stage) ipa user-del tuser --staged >>>>>> >>>>>> 4) moving to stage >>>>>> (from active) ipa user-stage tuser >>>>>> (from del) ipa user-stage tuser --deleted >>>>>> >>>>>> 5) modifying >>>>>> (in active) ipa user-mod tuser ... >>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>> >>>>>> Five commands (two of which are user-specific), plus two fairly consistent >>>>>> options. >>>>>> >>>>>> If the delete container isn't configured, the --deleted option is illegal and >>>>>> `user-del` deletes permanently. >>>>>> >>>>>> >>>>>> (*) may be useful in some situations? >>>>> I personally cannot imagine such situation - I would not add this command. If >>>>> somebody needs that, he can workaround with >>>>> >>>>> ipa user-add tuser --staged >>>>> ipa user-del tuser --staged >>>>> >>>>> ... and report us the use case when it's needed. But I general, Petr's >>>>> proposal >>>>> makes sense to me, I would go for it. (and update the design as Dmitri >>>>> correctly proposed). >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Hello, >>>> >>>> I will update the design following Petr proposal. Great one ! >>>> However I was thinking to a sligthly different proposal. For >>>> example if we have 3 states: staging, active, inactive. >>> I personally think that inactive state may be confusing. Is inactive deleted >>> user? Or staged user? Or active disabled user (user-disable command)? Inactive >>> state would have too many meanings. The previously proposed states active, >>> staging and deleted sounds clearer to me. >> Correct. Inactive is confusing and I prefer 'disabled'. >> For me a 'disabled' used is a user that has been 'active' (should I say >> 'enabled'). That means he/she has a uidNumber/guidNUmber/ipaUniqueiD set... , >> in addition it is in a dedicated container and likely 'nsaccountlock: yes'. > In terms of FreeIPA vocabulary, disabled user is a user in an active user > container, but switch to disabled (nsaccountlock is yes). It can be easile > enabled with "ipa user-enable" command. I.e. "disabled user" term is already > taken and actively user for other state. > >>>> 1) adding a user >>>> >>>> (...to active) ipa user-add# ( after the command >>>> ipaUniqueID=) >>>> (... to staging) ipa user-add --stage# (after the command >>>> ipaUniqueID=generate) >>>> >>>> So here we can not add a user directly into inactive state >>> If by inactive you mean deleted, then yes. >> Yes I was meaning 'inactive' as 'deleted' in Petr proposal. >> I do not like very much the word 'deleted' because in term of LDAP it has a >> different meaning. >> In term of User life cycle, I have a feeling that 'delete' is a final state, we >> can not return from 'delete'. This is why I prefered 'inactive' or now 'disabled'. > Ok, I see your point in the meaning from LDAP POV. However, we cannot use > 'inactive' as it is confusing and we cannot use 'disabled' as it is already > used in other scenario. That leaves us with 'delete' state which IMO is > consistent in FreeIPA vocabulary - user is moved to *deleted users* container > with user-*del* command. Ok I understand. 'delete' is the right choice, I vote for it and will update the design. > >>>> 2) activating the user >>>> >>>> (staging to active) ipa user-activate# (after the command >>>> ipaUniqueID=) >>>> (inactive to active) ipa user-activate --inactive# (after the >>>> command ipaUniqueID=) >>> --inactive -> --deleted >>> >>>> 3) inactivate the user >>>> >>>> (active to inactive) ipa user-inactivate# (after the command >>>> ipaUniqueID=) >>>> >>>> Here there is no possibility to move back an active entry to >>>> staging, because in staging >>>> the entries do not have ipaUniqueID set >>> Why is having ipaUniqueID attribute a problem for a staged user? >> My understanding is that an account moves from 'staging' to 'active' when we >> receive a formal approval. > Right. Here what is not clear to me is what is this approval. Would it be a user granted the autorization to run 'ipa user-activate', or an attribute set in the 'staging' entry (a task could them 'activate' all the staging entries which receive the approval), or a kind of 'approved group' that contains the DN of approved entries, or... > >> Before the approval, the ipaUniqueID is 'generate' >> and after it is a valid account. > Right. > >> For example, the user attribute should be: >> >> Staging Active Disabled >> ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID: >> abc-def-ghi-jkl >> uidNumber: -1 uidNumber: 1234uidNumber: 1234 >> gidNumber: -1 gidNumber: 1234gidNumber: 1234 >> attribute memberof: * > memberof>: >> nsaccountlock: true nsaccountlock: false >> nsaccountlock: true > Nice overview, we may even add it to design. Looks correct to me, though I > still do not undestand practical reasons why a user moved from active to staged > container cannot have ipaUniqueID already generated. I think an advantage of having 'active'->'staging' is that the customer has not to understand some constraint of the state machine. Everything is allowed staging<-->active<-->delete. On the opposite I believe * the entries in staging will not have the same "properties". Some may have ipaUniqueID/uidNumber set, some others may not. * What would be the real difference between 'staging' and 'delete'. It looks like the same state. > >>> The command to "inactivate" the user is user-del. >>> >>>> 4) modify the user >>>> >>>> (from active) ipa user-mod # (after the command >>>> ipaUniqueID=) >>>> (from inactive) ipa user-mod --inactive# (after the >>>> command ipaUniqueID=) >>> --inactive -> --deleted >>> >>>> (from staging) ipa user-mod --stage # (after the command >>>> ipaUniqueID=generate) >>>> >>>> >>>> 5) delete user >>>> >>>> (staging to delete) ipa user-del >>>> (inactive to delete) ipa user-del --inactive >>>> >>>> Here the entries are definitely removed >>> I would stick to original proposal: >>> >>> (from active) ipa user-del tuser >>> (from stage) ipa user-del tuser --staged >> Is this command to move entry from active/staging into delete container. >> How to delete definitely an entry ? with a option like '--remove' ? > The move from active users to deleted users container was planned to be done by > a plugin so that a simple ldapdelete can be called and the user is saved: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User > > To delete permanently, we could offer > > ipa user-del tuser --deleted > > command. (Or do not offer the command at all and force admins to use ldapdelete > to *permanently* delete the account). Missing this API should not be a problem > as in most small-scale deployments, advanced user life-cycle will not be enabled. > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri May 23 08:50:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 May 2014 11:50:59 +0300 Subject: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation In-Reply-To: <537E18AD.6010300@redhat.com> References: <20140512184005.1f1c77c4@unused-4-246.brq.redhat.com> <1399920643.3005.0.camel@ipa.example.com> <5372306C.4040408@redhat.com> <1400000119.2512.11.camel@ipa.example.com> <1400767923.2964.3.camel@ipa.example.com> <537E0D6D.50608@redhat.com> <1400770414.2746.3.camel@ipa.example.com> <1400770824.2746.4.camel@ipa.example.com> <537E141E.7010906@redhat.com> <537E18AD.6010300@redhat.com> Message-ID: <20140523085059.GK23849@redhat.com> On Thu, 22 May 2014, Petr Viktorin wrote: >On 05/22/2014 05:13 PM, Petr Vobornik wrote: >>On 22.5.2014 17:00, Nathaniel McCallum wrote: >>>On Thu, 2014-05-22 at 10:53 -0400, Nathaniel McCallum wrote: >>>>On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote: >>>>>On 05/22/2014 04:12 PM, Nathaniel McCallum wrote: >>>>>>On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote: >>>>>>>On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote: >>>>>>>>On 12.5.2014 20:50, Nathaniel McCallum wrote: >>>>>>>>>On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote: >>>>>>>>>>On Tue, 06 May 2014 11:46:14 -0400 >>>>>>>>>>Nathaniel McCallum wrote: >>>>>>>>>> >>>>>>>>>>>On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote: >>>>>>>>>>>>>On 6.5.2014 17:13, Nathaniel McCallum wrote: >>>>>>>>>>>>>>On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote: >>>>>>>>>>>>>>>On 6.5.2014 16:51, Nathaniel McCallum wrote: >>>>>>>>>>>>>>>>Specifying the default in the LDAP Object causes the >>>>>>>>>>>>>>>>parameter to be specified for non-add operations. This is >>>>>>>>>>>>>>>>especially problematic when performing the modify operation >>>>>>>>>>>>>>>>as it causes the primary key to change for every >>>>>>>>>>>>>>>>modification. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>https://fedorahosted.org/freeipa/ticket/4227 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>shouldn't removal of `autofill=True,` be enough? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Removing autofill=True results in the default not being used >>>>>>>>>>>>>>for the otptoken-add operation. That may be a different bug >>>>>>>>>>>>>>(I'm not sure what the expectation of autofill is). >>>>>>>>>>>>>> >>>>>>>>>>>>>>Nathaniel >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>Seems to work form me with: >>>>>>>>>>>>> >>>>>>>>>>>>>diff --git a/ipalib/plugins/otptoken.py >>>>>>>>>>>>>b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644 >>>>>>>>>>>>>--- a/ipalib/plugins/otptoken.py >>>>>>>>>>>>>+++ b/ipalib/plugins/otptoken.py >>>>>>>>>>>>>@@ -121,9 +121,7 @@ class otptoken(LDAPObject): >>>>>>>>>>>>> cli_name='id', >>>>>>>>>>>>> label=_('Unique ID'), >>>>>>>>>>>>> default_from=lambda: unicode(uuid.uuid4()), >>>>>>>>>>>>>- autofill=True, >>>>>>>>>>>>> primary_key=True, >>>>>>>>>>>>>- flags=('optional_create'), >>>>>>>>>>>>> ), >>>>>>>>>>>>> StrEnum('type?', >>>>>>>>>>>>> label=_('Type'), >>>>>>>>>>>> >>>>>>>>>>>>Doing this causes the ipa otptoken-add command to prompt for the >>>>>>>>>>>>Unique ID. This may be the desired behavior, but it is not >>>>>>>>>>>>how it >>>>>>>>>>>>worked previously (no prompt). >>>>>>>>>>> >>>>>>>>>>>Here is an alternate patch for this second approach. I have no >>>>>>>>>>>strong >>>>>>>>>>>opinion on the correct behavior here. >>>>>>>>>>> >>>>>>>>>>>Nathaniel >>>>>>>>>> >>>>>>>>>>IMO you should update API.txt with ./makeapi >>>>>>>>> >>>>>>>>>Running ./makeapi results in no changes to API.txt. >>>>>>>> >>>>>>>>This is not right, there *are* changes in the API and build fails >>>>>>>>for me >>>>>>>>becase API.txt is not updated. >>>>>>> >>>>>>>I think maybe I ran it from the wrong branch. Fixed. >>>>>> >>>>>>I still need a review of this. It is pretty trivial. >>>>>> >>>>>>Nathaniel >>>>> >>>>>This still prompts for the unique ID on add: >>>>> >>>>>$ ipa otptoken-add >>>>>Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]: >>>>> >>>>>I don't think that's the intended behavior. >>>> >>>>Hence the alternate patch (0052a). If we don't want to prompt, we'll >>>>need to use the first patch (0052). I have no strong opinion on the >>>>correct behavior and I am fine with merging either patch. >>> >>>Attached is the non-alternate (0052) with the api updated. >>> >>>Nathaniel >> >>IMO 52a is better if used by hand and it keeps code cleaner. > >I don't think that should influence the design of the CLI that much. > >>It might >>not be ideal though if used from a script because of nonexistent >>--unattended/-u option which would disable prompt (set >>env.interactive=False ?). > >Right. > > >ACK to the non-prompting version (0052.1). Pushed to master * 3f26ff8c37ef3f8a484220f8e514bb2691905d47 Only specify the ipatokenuniqueid default in the add operation -- / Alexander Bokovoy From jcholast at redhat.com Fri May 23 08:55:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 May 2014 10:55:10 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537F031E.8070701@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F031E.8070701@redhat.com> Message-ID: <537F0CEE.5070904@redhat.com> On 23.5.2014 10:13, Petr Viktorin wrote: > On 05/23/2014 08:33 AM, Martin Kosek wrote: >> On 05/23/2014 07:48 AM, Jan Cholasta wrote: >>> On 22.5.2014 19:27, Simo Sorce wrote: >>>> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: >>>>> On 05/21/2014 10:11 PM, Dmitri Pal wrote: >>>>>> On 05/21/2014 03:06 PM, Martin Kosek wrote: >>>>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>>>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Thanks for all these detailed descriptions. >>>>>>>>> Just to be sure to be on the same page, here is my >>>>>>>>> understanding of >>>>>>>>> the provisioning templates and placeholder definitions. An >>>>>>>>> administrator can provide a provisioning template. I >>>>>>>>> suppose it >>>>>>>>> would be a file containing a lines of placeholder >>>>>>>>> definitions. >>>>>>>>> >>>>>>>>> * Where is located the template file ? Is there a >>>>>>>>> standard >>>>>>>>> repository where templates are put ? (somewhere under >>>>>>>>> /etc/ipa/* ?) >>>>>>>> >>>>>>>> FreeIPA is a multi-master system, a file stored in a file would be >>>>>>>> extremely cumbersome to use as it would require the admin to >>>>>>>> manually >>>>>>>> copy it for every new replica and then keep it in sync. >>>>>>>> It would also make it hard to change 'on-line'. >>>>>>>> >>>>>>>> Placeholders should be defined in an object similar to >>>>>>>> cn=ipaConfig,cn=etc,$suffix >>>>>>>> >>>>>>>>> * Is there an already defined syntax for the >>>>>>>>> provisionning >>>>>>>>> template. ('$' is separator attr/value, %{} is >>>>>>>>> substitute >>>>>>>>> pattern...). If not, is it possible to user >>>>>>>>> ': ' as >>>>>>>>> separator ? >>>>>>>> >>>>>>>> Using initial and final ? like in Martin's example doesn't work ? >>>>>>>> >>>>>>>>> * What is the priority. The user can provide the >>>>>>>>> 'homeDirectory' >>>>>>>>> through different methods. Is it ok to use the >>>>>>>>> following order: >>>>>>>>> o the CLI option >>>>>>>>> o the provisionning template >>>>>>>>> o the default config value (in >>>>>>>>> cn=ipaConfig,cn=etc,$SUFFIX) >>>>>>>>> >>>>>>>>> For example, if it exists the provisioning template: >>>>>>>>> /etc/ipa/provisioning/shell-user.template >>>>>>>>> >>>>>>>>> roomnumber$-2 >>>>>>>>> homeDirectory$/home/net/shell-%{uid} >>>>>>>>> loginShell$?shell-plugin-autogenerate? >>>>>>>> >>>>>>>> I do not understand this, we are not building a templating >>>>>>>> engine here, >>>>>>>> you only have 2 options: >>>>>>>> 1) a required (MUST) attribute has an explicit value >>>>>>>> 2) a require (MUST) attribute has a placeholder value >>>>>>>> >>>>>>>> the placeholder value is fixed per type, and what it is >>>>>>>> substituted with >>>>>>>> uses the same rules as the current code uses to autogenerate >>>>>>>> values. >>>>>>>> >>>>>>>>> the command: ipa user-add tuser >>>>>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would >>>>>>>>> create a >>>>>>>>> staging entry: >>>>>>>>> >>>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>>> ... >>>>>>>>> roomNumber: 1234 >>>>>>>>> homeDirectory: /tmp/tuser >>>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>>> >>>>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing >>>>>>>> should >>>>>>>> be stored at all in the staged entry unless explicitly provided >>>>>>>> for by >>>>>>>> the admin. >>>>>>>> >>>>>>>>> Then a private DS plugin (catching >>>>>>>>> shell-plugin-autogenerate) >>>>>>>>> generate the loginShell value when the entry becomes >>>>>>>>> active. >>>>>>>>> >>>>>>>>> >>>>>>>>> the command: ipa user-add tuser >>>>>>>>> --homedir=/tmp/tuser--to-stage would >>>>>>>>> create a staging entry: >>>>>>>>> >>>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>>> ... >>>>>>>>> roomNumber: -2 >>>>>>>>> homeDirectory: /tmp/tuser >>>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>>> >>>>>>>> roomNumber is also a MAY, so what would cause it to be set at >>>>>>>> -2, and >>>>>>>> why ? >>>>>>>> >>>>>>>>> the command: ipa user-add tuser --to-stage would create >>>>>>>>> a staging >>>>>>>>> entry: >>>>>>>>> >>>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>>> ... >>>>>>>>> roomNumber: -2 >>>>>>>>> homeDirectory: /home/net/shell-tuser >>>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>>> >>>>>>>> homeDirectory should be something like: ?placeholder? IMO, we do >>>>>>>> not >>>>>>>> really want to play templating here. >>>>>>>> >>>>>>>>> In case the provisioning template does not define >>>>>>>>> 'homeDirectory', >>>>>>>>> then the created entry would take the value from the ipa >>>>>>>>> config >>>>>>>>> definition: >>>>>>>> >>>>>>>> that value should be taken and applied at the time the user is >>>>>>>> unstaged >>>>>>>> and brought in the actual tree, not at the time a user is staged. >>>>>>>> >>>>>>>> HTH, >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> Hello Thierry and Simo, >>>>>>> >>>>>>> I think Thierry was confused with this part of the design: >>>>>>> >>>>>>> " >>>>>>> This format of placeholders gives enough space for future >>>>>>> enhancements. For >>>>>>> example, Administrator could configure a new template >>>>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged >>>>>>> LDAP entry. >>>>>>> Such value would be replaced by "/home/net/tuser if user uid >>>>>>> attribute is set >>>>>>> to tuser >>>>>>> " >>>>>>> >>>>>>> My intention when writing this design was to enable future use of >>>>>>> configurable placeholders, i.e. a value "?someplaceholder?" could >>>>>>> be turn >>>>>>> into "/custom/path/%{uid}". But I meant that this can be >>>>>>> considered as a >>>>>>> future enhancement. For now, I think implementing a placeholder >>>>>>> "-1" for >>>>>>> numerical values and "?autogenerate?" for string ones a good start. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> >>>>>> Please consider the flow: user added staged -> activated/moved to >>>>>> main tree -> >>>>>> deleted/moved to deleted tree -> staged back >>>>>> At the first step his IPA user ID and UID should be undefined and >>>>>> autogenerated. >>>>>> On the last step his IPAUserID and UID should be preserved. The >>>>>> main use case >>>>>> is that this is the user who left the company who comes back >>>>>> again. His files >>>>>> should be still owned by him unless admin forces a flush of his >>>>>> IDs (new >>>>>> switch???) when he moves user from deleted to staged. >>>>>> >>>>> >>>>> Right, the life-cycle feature should work like that naturally, >>>>> given that only >>>>> attributes with "-1" or "autogenerate" are generated. >>>>> >>>>> If admin wants to re-generate the IDs, all he would need to do is >>>>> to change the >>>>> attributes back to "-1" after/before moving the user to staging. >>>>> Question is >>>>> when it should be done (in deleted tree, in staging tree or after >>>>> activation) >>>>> and what API/command we choose. >>>> >>>> TBH I question the whole idea of "moving to staging", in what case >>>> would >>>> that make sense ? >>>> >>>>> Admin may want to change not only the UID/GID, but maybe also a >>>>> home directory >>>>> (user may be in a different department) so we should make it >>>>> general. Maybe we >>>>> should let user-mod support modification in staging area? Like >>>>> >>>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged >>>>> >>>>> or >>>>> >>>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted >>>> >>>> The reason why we have the 'deleted' area is to be able to preserve the >>>> user intact ... I would almost want to ask to explicitly not allow >>>> modifications to deleted users (admin can always use ldapmodify if they >>>> *really* need to play some game here). >>> >>> +1, it seemed strange to me that modifying deleted user was allowed >>> as well. >> >> Hm, ok, let us not have an API to modify deleted user then. > > Here's a scenario: > - automember is set to add users the appropriate groups when userclass > is set to "junior admin", or "senior admin" > - Johnny the Junior Admin leaves the company, is deleted > - After some time Johnny joins again as Senior Admin > > I think in this case we'd want to set the userclass to "senior admin" > before restoring the user. I don't agree, IMO this should be done after restoring the user, the same way as you would "promote" any other active user. > Other changes (e.g. a name change) can be done after restoring the user, > but it still seems cleaner for me if they could be done on the deleted > user (or if the deleted user could be restored to stage first). There > may be other plugins that run on add and expect current information. > > >> As for active -> staging users flow, I only think of one scenario: >> >> 1) Operator moves staged user to active users >> 2) Operator realizes that his mouse slipped and he moved a wrong person >> 3) Operator wants to move the person quickly back to staged before anyone >> notices :) >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > -- Jan Cholasta From abokovoy at redhat.com Fri May 23 08:53:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 May 2014 11:53:34 +0300 Subject: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token In-Reply-To: <537EE06D.50004@redhat.com> References: <1399308004.3102.3.camel@ipa.example.com> <5368CB8F.8070906@redhat.com> <1399382160.2416.5.camel@ipa.example.com> <5368ED88.5030808@redhat.com> <1399388863.9864.1.camel@ipa.example.com> <536A3B30.3080206@redhat.com> <1399471569.3786.9.camel@ipa.example.com> <1400768477.2964.4.camel@ipa.example.com> <537EE06D.50004@redhat.com> Message-ID: <20140523085334.GL23849@redhat.com> On Fri, 23 May 2014, Jan Cholasta wrote: >On 22.5.2014 16:21, Nathaniel McCallum wrote: >>I still need a review on this. >> >>On Wed, 2014-05-07 at 10:06 -0400, Nathaniel McCallum wrote: >>>On Wed, 2014-05-07 at 15:54 +0200, Petr Vobornik wrote: >>>>On 6.5.2014 17:07, Nathaniel McCallum wrote: >>>>>On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote: >>>>>>On 6.5.2014 15:16, Nathaniel McCallum wrote: >>>>>>>On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote: >>>>>>>>Hi, >>>>>>>> >>>>>>>>On 5.5.2014 18:40, Nathaniel McCallum wrote: >>>>>>>>>Creating tokens for yourself is the most common operation. Making this >>>>>>>>>the default optimizes for the common case. >>>>>>>> >>>>>>>>The user-find call should be inside the if statement. >>>>>>> >>>>>>>This is actually for a reason. See my patch 0049 for further context. >>>>>> >>>>>>IMO something like this would be better: >>>>>> >>>>>> if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in >>>>>>entry_attrs: >>>>>> result = self.api.Command.user_find(whoami=True)['result'] >>>>>> if result: >>>>>> cur_uid = result[0]['uid'][0] >>>>>> prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) >>>>>> if cur_uid != prev_uid: >>>>>> entry_attrs.setdefault('ipatokenprotected', True) >>>>> >>>>>Fixed (see also my new revision of patch 0049). >>>>> >>>>>Nathaniel >>>>> >>>> >>>>I assume that this won't allow to create a token without an owner. Do we >>>>want to have this restriction? >>>> >>>>Usecase: import a batch of hw tokens >>> >>>This case is currently very much on my radar (I'm finishing the import >>>script now). To set no owner, just use --owner="". We are testing for >>>key presence here, not the value of the key. So if the key is present >>>with an empty value, no owner will be set. >>> >>>FYI, the import format (RFC 6030) also permits a mechanism for declaring >>>ownership in DN format. >>> >>>Nathaniel >>> >>>_______________________________________________ >>>Freeipa-devel mailing list >>>Freeipa-devel at redhat.com >>>https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >>_______________________________________________ >>Freeipa-devel mailing list >>Freeipa-devel at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-devel >> > >ACK. > Pushed to master * db7d0219bac72daa270ee28d5db5c18ea41fb8b1 Default the token owner to the person adding the token -- / Alexander Bokovoy From mkosek at redhat.com Fri May 23 08:55:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 10:55:39 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537F055E.1010200@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <537EEAAD.7020308@redhat.com> <537EF9F7.9010909@redhat.com> <537F011D.8090001@redhat.com> <537F055E.1010200@redhat.com> Message-ID: <537F0D0B.6070804@redhat.com> On 05/23/2014 10:22 AM, thierry bordaz wrote: > On 05/23/2014 10:04 AM, Martin Kosek wrote: >> On 05/23/2014 09:34 AM, thierry bordaz wrote: ... >>>>> 3) inactivate the user >>>>> >>>>> (active to inactive) ipa user-inactivate# (after the command >>>>> ipaUniqueID=) >>>>> >>>>> Here there is no possibility to move back an active entry to >>>>> staging, because in staging >>>>> the entries do not have ipaUniqueID set >>>> Why is having ipaUniqueID attribute a problem for a staged user? >>> My understanding is that an account moves from 'staging' to 'active' when we >>> receive a formal approval. >> Right. > > Here what is not clear to me is what is this approval. > Would it be a user granted the autorization to run 'ipa user-activate', or an > attribute set in the 'staging' entry (a task could them 'activate' all the > staging entries which receive the approval), or a kind of 'approved group' that > contains the DN of approved entries, or... We do not need to care about what approval is in a particular deployment, what we need to care about is how to give privileges to someone to do the activation (ipa user-activate). This should be solved via standard permission/ACI to MODRDN from staging area to active users area (the MODRDN ACI you did) that can be assigned to group of privileged operators. >> >>> Before the approval, the ipaUniqueID is 'generate' >>> and after it is a valid account. >> Right. >> >>> For example, the user attribute should be: >>> >>> Staging Active Disabled >>> ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID: >>> abc-def-ghi-jkl >>> uidNumber: -1 uidNumber: 1234uidNumber: 1234 >>> gidNumber: -1 gidNumber: 1234gidNumber: 1234 >>> attribute memberof: * >> memberof>: >>> nsaccountlock: true nsaccountlock: false >>> nsaccountlock: true >> Nice overview, we may even add it to design. Looks correct to me, though I >> still do not undestand practical reasons why a user moved from active to staged >> container cannot have ipaUniqueID already generated. > I think an advantage of having 'active'->'staging' is that the customer has not > to understand some constraint of the state machine. Everything is allowed > staging<-->active<-->delete. > > On the opposite I believe > > * the entries in staging will not have the same "properties". Some may > have ipaUniqueID/uidNumber set, some others may not. > * What would be the real difference between 'staging' and 'delete'. It > looks like the same state. It is true that the entries will be similar from attributes and values POV. However, they will be different in a meaning. Staging area may contain dozen recently provisioned users *planned* to be activated after the approval is made, while the deleted users container may contain hundreds or thousands of users deleted long time ago. But from LDAP behavior POV, the users will be similar - you cannot BIND to them, you cannot kinit with them. Martin From mkosek at redhat.com Fri May 23 08:59:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 10:59:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <537E0799.2000408@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> Message-ID: <537F0E0E.3020204@redhat.com> On 05/22/2014 04:20 PM, Petr Viktorin wrote: > On 05/21/2014 12:14 PM, Simo Sorce wrote: >> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>> On 05/16/2014 04:33 PM, Petr Viktorin wrote: >>>> On 05/16/2014 01:54 PM, Martin Kosek wrote: >>>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>>>>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed >>>>>> previously >>>>>> [0]. >>>>>> >>>>>> Patch 0541 is some minor refactoring for the next part. >>>>>> >>>>>> Patch 0542 sets the read acces to addressbook attributes to anonymous when >>>>>> upgrading from pre-4.0. >>>>>> I first this by checking if the update is run from ipa-server-install or >>>>>> not, >>>>>> but then I realized the logic I want is simple: if the global anon read ACI >>>>>> exists, we want to preserve its spirit by setting addressbook attribute >>>>>> ACI to >>>>>> anonymous. >>>>>> >>>>>> >>>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et >>>>>> al. >>>>>> >>>>> >>>>> 540: >>>>> >>>>> Looks good! The only attributes I am concerned about are special IPA >>>>> attributes: >>>>> >>>>> - ipauniqueid >>>>> - ipasshpubkey >>>>> - ipauserauthtype >>>>> - userclass >>>>> >>>>> I personally do not think they should be included in POSIX attributes >>>>> permissions, they are far from POSIX definition... >>>>> >>>>> What about creating one more permission "System: Read User IPA Attributes" as >>>>> these are specific to FreeIPA use and allowing that permission for all >>>>> authenticated users? >>>> >>>> Sounds reasonable. I assume we want this one to be also set to anonymous when >>>> upgrading from old versions. >>>> Attaching updated patches. >>> >>> Ok, looks good. >>> >>> I am now just pondering whether "System: Read User POSIX Attributes" is the >>> right name for the permission as there are not just POSIX attributes, but also >>> attributes from organizationalPerson or inetOrgPerson objectclasses. >>> >>> Maybe we should name it "System: Read User Core Attributes" or "System: Read >>> User Basic Attributes"? Simo, any preference? >> >> We could use: "System: Read User Standard Attributes" > > I've used this one, then. > >> >> but the 'posix' version is also ok to me. > > On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >> Also, I just realized we forgot memberOf attribute - it needs to be available >> to authenticated users otherwise group membership will fall apart. > > Good catch. Added. > We are very close to push this one - I have just one last concern about userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 from user, now we added it to be read by default. This results in this warning during upgrade: Excluded attributes for System: Read User Addressbook Attributes: userpkcs12 Simo (or others), is this OK or do we want to keep hiding userpkcs12 by default? Martin From tbordaz at redhat.com Fri May 23 09:01:38 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 May 2014 11:01:38 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537F0D0B.6070804@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <537EEAAD.7020308@redhat.com> <537EF9F7.9010909@redhat.com> <537F011D.8090001@redhat.com> <537F055E.1010200@redhat.com> <537F0D0B.6070804@redhat.com> Message-ID: <537F0E72.3040906@redhat.com> On 05/23/2014 10:55 AM, Martin Kosek wrote: > On 05/23/2014 10:22 AM, thierry bordaz wrote: >> On 05/23/2014 10:04 AM, Martin Kosek wrote: >>> On 05/23/2014 09:34 AM, thierry bordaz wrote: > ... >>>>>> 3) inactivate the user >>>>>> >>>>>> (active to inactive) ipa user-inactivate# (after the command >>>>>> ipaUniqueID=) >>>>>> >>>>>> Here there is no possibility to move back an active entry to >>>>>> staging, because in staging >>>>>> the entries do not have ipaUniqueID set >>>>> Why is having ipaUniqueID attribute a problem for a staged user? >>>> My understanding is that an account moves from 'staging' to 'active' when we >>>> receive a formal approval. >>> Right. >> Here what is not clear to me is what is this approval. >> Would it be a user granted the autorization to run 'ipa user-activate', or an >> attribute set in the 'staging' entry (a task could them 'activate' all the >> staging entries which receive the approval), or a kind of 'approved group' that >> contains the DN of approved entries, or... > We do not need to care about what approval is in a particular deployment, what > we need to care about is how to give privileges to someone to do the activation > (ipa user-activate). This should be solved via standard permission/ACI to > MODRDN from staging area to active users area (the MODRDN ACI you did) that can > be assigned to group of privileged operators. > >>>> Before the approval, the ipaUniqueID is 'generate' >>>> and after it is a valid account. >>> Right. >>> >>>> For example, the user attribute should be: >>>> >>>> Staging Active Disabled >>>> ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID: >>>> abc-def-ghi-jkl >>>> uidNumber: -1 uidNumber: 1234uidNumber: 1234 >>>> gidNumber: -1 gidNumber: 1234gidNumber: 1234 >>>> attribute memberof: * >>> memberof>: >>>> nsaccountlock: true nsaccountlock: false >>>> nsaccountlock: true >>> Nice overview, we may even add it to design. Looks correct to me, though I >>> still do not undestand practical reasons why a user moved from active to staged >>> container cannot have ipaUniqueID already generated. >> I think an advantage of having 'active'->'staging' is that the customer has not >> to understand some constraint of the state machine. Everything is allowed >> staging<-->active<-->delete. >> >> On the opposite I believe >> >> * the entries in staging will not have the same "properties". Some may >> have ipaUniqueID/uidNumber set, some others may not. >> * What would be the real difference between 'staging' and 'delete'. It >> looks like the same state. > It is true that the entries will be similar from attributes and values POV. > However, they will be different in a meaning. Staging area may contain dozen > recently provisioned users *planned* to be activated after the approval is > made, while the deleted users container may contain hundreds or thousands of > users deleted long time ago. > > But from LDAP behavior POV, the users will be similar - you cannot BIND to > them, you cannot kinit with them. > > Martin ok thanks for the clarifications :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri May 23 10:42:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 12:42:26 +0200 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: References: Message-ID: <537F2612.7050101@redhat.com> On 05/23/2014 07:01 AM, James wrote: > I'm trying to understand some of the FreeIPA replication internals so > that I can better know how to do this properly in Puppet without > storing any secret information in Puppet, and so that automating > FreeIPA is awesome. > > Please point me to any docs, if there is reading I could be doing :) > > Here are some open questions I have: > > 1) Is the GPG file created with ipa-replica-prepare using a symmetric > password and is that password equal to the dm_password ? If not, where > do the pub/priv key pairs come from and how do they get transferred to > the replica. Yes. Grep for function expand_replica_info in FreeIPA git. > > 2) If I have root on the IPA server (actually all of them) how can I > run ipa-replica-prepare without needing interactive prompting for > entering the password. It's not possible with puppet. Is there another > (possibly less user friendly even) method to "prepare" the replica? > What is prepare actually doing? For, you can for example use --password for passing the DM password. > 3) With a multi master setup, what happens if I run the same action > (eg: user-mod or user-add or user-del) on more than one server. I would not do that, you risk replication conflicts on entries or attributes. More here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > Can I > run it on any server? Yes. > What if I run different user-mod commands of the > same user on different masters. Is there split brain? Then you get a replication conflict. I think in case of attributes, last modification wins. > Are all the > transactions and writes synchronous across the whole cluster? They are not synchronous, it takes some time for a change to replica to all masters. > Please > point me to a doc that explains this FAQ stuff if possible. Sorry for > the noise You should be able to get a reasonable starting information here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html or here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html HTH, Martin From mkosek at redhat.com Fri May 23 12:26:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 14:26:21 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI In-Reply-To: <537E03BD.8070505@redhat.com> References: <53601381.9050207@redhat.com> <5375FDE4.3070400@redhat.com> <537A06D9.4010000@redhat.com> <537C42CE.3030307@redhat.com> <537E03BD.8070505@redhat.com> Message-ID: <537F3E6D.5090004@redhat.com> On 05/22/2014 04:03 PM, Petr Viktorin wrote: > On 05/21/2014 08:08 AM, Martin Kosek wrote: >> On 05/19/2014 03:27 PM, Petr Viktorin wrote: >>> 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. >> >> I tested upgrade from 3.3.5 to 4.0 and in SUFFIX I still had some of the ACIs >> left: >> >> (targetattr = "*")(target = >> "ldap:///cn=*,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test")(version 3.0; >> acl "No anonymous access to roles"; deny (read,search,compare) userdn != >> "ldap:///all";) >> >> (targetattr = "*")(target = >> "ldap:///cn=*,ou=SUDOers,dc=mkosek-fedora20,dc=test")(version 3.0; acl "No >> anonymous access to sudo"; deny (read,search,compare) userdn != "ldap:///all";) >> >> The problem is that you used your testing suffix instead of suffix variable. > > Shame on me. I've updated & rebased the patch. > > I've also made a git hook yell at me when I commit something containing "BRQ", > hopefully this won't happen again. Would it make sense to publish your FreeIPA git hooks somewhere on http://www.freeipa.org/page/Contribute/Code or your github and link it? I think it already contains couple gems that may help other people prevent basic errors like this one. Otherwise, the patch worked fine - ACK! I would like it to be pushed as soon as user ACI patch is pushed so that we have some time to find issues. Martin From dpal at redhat.com Fri May 23 13:28:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 23 May 2014 09:28:14 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <537F2612.7050101@redhat.com> References: <537F2612.7050101@redhat.com> Message-ID: <537F4CEE.3040001@redhat.com> On 05/23/2014 06:42 AM, Martin Kosek wrote: > On 05/23/2014 07:01 AM, James wrote: >> I'm trying to understand some of the FreeIPA replication internals so >> that I can better know how to do this properly in Puppet without >> storing any secret information in Puppet, and so that automating >> FreeIPA is awesome. >> >> Please point me to any docs, if there is reading I could be doing :) >> >> Here are some open questions I have: >> >> 1) Is the GPG file created with ipa-replica-prepare using a symmetric >> password and is that password equal to the dm_password ? If not, where >> do the pub/priv key pairs come from and how do they get transferred to >> the replica. > Yes. Grep for function expand_replica_info in FreeIPA git. > >> 2) If I have root on the IPA server (actually all of them) how can I >> run ipa-replica-prepare without needing interactive prompting for >> entering the password. It's not possible with puppet. Is there another >> (possibly less user friendly even) method to "prepare" the replica? >> What is prepare actually doing? > For, you can for example use --password for passing the DM password. I guess the question is more: If I am root is there any way to do the operation without providing the password but rather using something like LDAPI to drive the operation. The issue is that if you use puppet there is no way to get the password dynamically from some kind of source without baking it into the scripts. Baking passwords into scripts is bad so to avoid it there needs to be a way for root to install replica without it. I am not sure it is currently possible though. > > >> 3) With a multi master setup, what happens if I run the same action >> (eg: user-mod or user-add or user-del) on more than one server. > I would not do that, you risk replication conflicts on entries or attributes. > More here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > >> Can I >> run it on any server? > Yes. > >> What if I run different user-mod commands of the >> same user on different masters. Is there split brain? > Then you get a replication conflict. I think in case of attributes, last > modification wins. > >> Are all the >> transactions and writes synchronous across the whole cluster? > They are not synchronous, it takes some time for a change to replica to all > masters. > >> Please >> point me to a doc that explains this FAQ stuff if possible. Sorry for >> the noise > You should be able to get a reasonable starting information here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html > > or here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html > > HTH, > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Fri May 23 13:44:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 15:44:56 +0200 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <537F4CEE.3040001@redhat.com> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> Message-ID: <537F50D8.2080306@redhat.com> On 05/23/2014 03:28 PM, Dmitri Pal wrote: > On 05/23/2014 06:42 AM, Martin Kosek wrote: >> On 05/23/2014 07:01 AM, James wrote: >>> I'm trying to understand some of the FreeIPA replication internals so >>> that I can better know how to do this properly in Puppet without >>> storing any secret information in Puppet, and so that automating >>> FreeIPA is awesome. >>> >>> Please point me to any docs, if there is reading I could be doing :) >>> >>> Here are some open questions I have: >>> >>> 1) Is the GPG file created with ipa-replica-prepare using a symmetric >>> password and is that password equal to the dm_password ? If not, where >>> do the pub/priv key pairs come from and how do they get transferred to >>> the replica. >> Yes. Grep for function expand_replica_info in FreeIPA git. >> >>> 2) If I have root on the IPA server (actually all of them) how can I >>> run ipa-replica-prepare without needing interactive prompting for >>> entering the password. It's not possible with puppet. Is there another >>> (possibly less user friendly even) method to "prepare" the replica? >>> What is prepare actually doing? >> For, you can for example use --password for passing the DM password. > > I guess the question is more: > If I am root is there any way to do the operation without providing the > password but rather using something like LDAPI to drive the operation. > The issue is that if you use puppet there is no way to get the password > dynamically from some kind of source without baking it into the scripts. > Baking passwords into scripts is bad so to avoid it there needs to be a way for > root to install replica without it. I am not sure it is currently possible though. One cannot easily improve ipa-replica-prepare to work through LDAPI as we also need to encypher the replica info package - and we cannot do that without clear text DM password. The right way seems to be rather the RFE you filed: https://fedorahosted.org/freeipa/ticket/2888 Martin From rcritten at redhat.com Fri May 23 13:46:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 May 2014 09:46:22 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <537F4CEE.3040001@redhat.com> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> Message-ID: <537F512E.7040509@redhat.com> Dmitri Pal wrote: > On 05/23/2014 06:42 AM, Martin Kosek wrote: >> On 05/23/2014 07:01 AM, James wrote: >>> I'm trying to understand some of the FreeIPA replication internals so >>> that I can better know how to do this properly in Puppet without >>> storing any secret information in Puppet, and so that automating >>> FreeIPA is awesome. >>> >>> Please point me to any docs, if there is reading I could be doing :) >>> >>> Here are some open questions I have: >>> >>> 1) Is the GPG file created with ipa-replica-prepare using a symmetric >>> password and is that password equal to the dm_password ? If not, where >>> do the pub/priv key pairs come from and how do they get transferred to >>> the replica. >> Yes. Grep for function expand_replica_info in FreeIPA git. >> >>> 2) If I have root on the IPA server (actually all of them) how can I >>> run ipa-replica-prepare without needing interactive prompting for >>> entering the password. It's not possible with puppet. Is there another >>> (possibly less user friendly even) method to "prepare" the replica? >>> What is prepare actually doing? >> For, you can for example use --password for passing the DM password. > > I guess the question is more: > If I am root is there any way to do the operation without providing the > password but rather using something like LDAPI to drive the operation. > The issue is that if you use puppet there is no way to get the password > dynamically from some kind of source without baking it into the scripts. > Baking passwords into scripts is bad so to avoid it there needs to be a > way for root to install replica without it. I am not sure it is > currently possible though. No, there is nothing special root can do. There is no server yet that root could do anything with. We still need the DM password to do a lot of installation, so either you bake that into the replica file or it is provided at install time. There are good and bad points to both. rob From rcritten at redhat.com Fri May 23 14:13:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 May 2014 10:13:45 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537EEB9E.4050306@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> Message-ID: <537F5799.9060906@redhat.com> Martin Kosek wrote: > On 05/23/2014 07:48 AM, Jan Cholasta wrote: >> On 22.5.2014 19:27, Simo Sorce wrote: >>> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: >>>> On 05/21/2014 10:11 PM, Dmitri Pal wrote: >>>>> On 05/21/2014 03:06 PM, Martin Kosek wrote: >>>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Thanks for all these detailed descriptions. >>>>>>>> Just to be sure to be on the same page, here is my understanding of >>>>>>>> the provisioning templates and placeholder definitions. An >>>>>>>> administrator can provide a provisioning template. I suppose it >>>>>>>> would be a file containing a lines of placeholder definitions. >>>>>>>> >>>>>>>> * Where is located the template file ? Is there a standard >>>>>>>> repository where templates are put ? (somewhere under >>>>>>>> /etc/ipa/* ?) >>>>>>> >>>>>>> FreeIPA is a multi-master system, a file stored in a file would be >>>>>>> extremely cumbersome to use as it would require the admin to manually >>>>>>> copy it for every new replica and then keep it in sync. >>>>>>> It would also make it hard to change 'on-line'. >>>>>>> >>>>>>> Placeholders should be defined in an object similar to >>>>>>> cn=ipaConfig,cn=etc,$suffix >>>>>>> >>>>>>>> * Is there an already defined syntax for the provisionning >>>>>>>> template. ('$' is separator attr/value, %{} is substitute >>>>>>>> pattern...). If not, is it possible to user ': ' as >>>>>>>> separator ? >>>>>>> >>>>>>> Using initial and final ? like in Martin's example doesn't work ? >>>>>>> >>>>>>>> * What is the priority. The user can provide the 'homeDirectory' >>>>>>>> through different methods. Is it ok to use the following order: >>>>>>>> o the CLI option >>>>>>>> o the provisionning template >>>>>>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) >>>>>>>> >>>>>>>> For example, if it exists the provisioning template: >>>>>>>> /etc/ipa/provisioning/shell-user.template >>>>>>>> >>>>>>>> roomnumber$-2 >>>>>>>> homeDirectory$/home/net/shell-%{uid} >>>>>>>> loginShell$?shell-plugin-autogenerate? >>>>>>> >>>>>>> I do not understand this, we are not building a templating engine here, >>>>>>> you only have 2 options: >>>>>>> 1) a required (MUST) attribute has an explicit value >>>>>>> 2) a require (MUST) attribute has a placeholder value >>>>>>> >>>>>>> the placeholder value is fixed per type, and what it is substituted with >>>>>>> uses the same rules as the current code uses to autogenerate values. >>>>>>> >>>>>>>> the command: ipa user-add tuser >>>>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a >>>>>>>> staging entry: >>>>>>>> >>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>> ... >>>>>>>> roomNumber: 1234 >>>>>>>> homeDirectory: /tmp/tuser >>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>> >>>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should >>>>>>> be stored at all in the staged entry unless explicitly provided for by >>>>>>> the admin. >>>>>>> >>>>>>>> Then a private DS plugin (catching shell-plugin-autogenerate) >>>>>>>> generate the loginShell value when the entry becomes active. >>>>>>>> >>>>>>>> >>>>>>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would >>>>>>>> create a staging entry: >>>>>>>> >>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>> ... >>>>>>>> roomNumber: -2 >>>>>>>> homeDirectory: /tmp/tuser >>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>> >>>>>>> roomNumber is also a MAY, so what would cause it to be set at -2, and >>>>>>> why ? >>>>>>> >>>>>>>> the command: ipa user-add tuser --to-stage would create a staging >>>>>>>> entry: >>>>>>>> >>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>> ... >>>>>>>> roomNumber: -2 >>>>>>>> homeDirectory: /home/net/shell-tuser >>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>> >>>>>>> homeDirectory should be something like: ?placeholder? IMO, we do not >>>>>>> really want to play templating here. >>>>>>> >>>>>>>> In case the provisioning template does not define 'homeDirectory', >>>>>>>> then the created entry would take the value from the ipa config >>>>>>>> definition: >>>>>>> >>>>>>> that value should be taken and applied at the time the user is unstaged >>>>>>> and brought in the actual tree, not at the time a user is staged. >>>>>>> >>>>>>> HTH, >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> Hello Thierry and Simo, >>>>>> >>>>>> I think Thierry was confused with this part of the design: >>>>>> >>>>>> " >>>>>> This format of placeholders gives enough space for future enhancements. For >>>>>> example, Administrator could configure a new template >>>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. >>>>>> Such value would be replaced by "/home/net/tuser if user uid attribute is set >>>>>> to tuser >>>>>> " >>>>>> >>>>>> My intention when writing this design was to enable future use of >>>>>> configurable placeholders, i.e. a value "?someplaceholder?" could be turn >>>>>> into "/custom/path/%{uid}". But I meant that this can be considered as a >>>>>> future enhancement. For now, I think implementing a placeholder "-1" for >>>>>> numerical values and "?autogenerate?" for string ones a good start. >>>>>> >>>>>> Martin >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> >>>>> Please consider the flow: user added staged -> activated/moved to main tree -> >>>>> deleted/moved to deleted tree -> staged back >>>>> At the first step his IPA user ID and UID should be undefined and >>>>> autogenerated. >>>>> On the last step his IPAUserID and UID should be preserved. The main use case >>>>> is that this is the user who left the company who comes back again. His files >>>>> should be still owned by him unless admin forces a flush of his IDs (new >>>>> switch???) when he moves user from deleted to staged. >>>>> >>>> >>>> Right, the life-cycle feature should work like that naturally, given that only >>>> attributes with "-1" or "autogenerate" are generated. >>>> >>>> If admin wants to re-generate the IDs, all he would need to do is to change the >>>> attributes back to "-1" after/before moving the user to staging. Question is >>>> when it should be done (in deleted tree, in staging tree or after activation) >>>> and what API/command we choose. >>> >>> TBH I question the whole idea of "moving to staging", in what case would >>> that make sense ? >>> >>>> Admin may want to change not only the UID/GID, but maybe also a home directory >>>> (user may be in a different department) so we should make it general. Maybe we >>>> should let user-mod support modification in staging area? Like >>>> >>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged >>>> >>>> or >>>> >>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted >>> >>> The reason why we have the 'deleted' area is to be able to preserve the >>> user intact ... I would almost want to ask to explicitly not allow >>> modifications to deleted users (admin can always use ldapmodify if they >>> *really* need to play some game here). >> >> +1, it seemed strange to me that modifying deleted user was allowed as well. > > Hm, ok, let us not have an API to modify deleted user then. > > As for active -> staging users flow, I only think of one scenario: > > 1) Operator moves staged user to active users > 2) Operator realizes that his mouse slipped and he moved a wrong person > 3) Operator wants to move the person quickly back to staged before anyone > notices :) This, I believe, has already been covered, but I'm concerned with the (over)use of active/inactive in this discussion. I think use of "inactive" and "active" to describe users might be confusing since there is already an account enable/disable command. This on top of unlock, are there now 3 possible boolean states a user can be in? locked/unlocked, enabled/disabled, active/inactive, plus deleted/active and staged/active? rob From mkosek at redhat.com Fri May 23 14:36:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 May 2014 16:36:22 +0200 Subject: [Freeipa-devel] Is CA certificate storage correct? In-Reply-To: <537B1D5F.6000305@redhat.com> References: <537AF620.6090802@redhat.com> <537B1D5F.6000305@redhat.com> Message-ID: <537F5CE6.1000500@redhat.com> On 05/20/2014 11:16 AM, Jan Cholasta wrote: > On 20.5.2014 08:28, Martin Kosek wrote: >> 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? > > There is no such relation, ipaKey* attributes apply to all of the cACertificate > attributes. > >> >> 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? > > No. Could you then please state some example in http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store with more than one cACertificate;binary? I think it would greatly help understand the relation of the new schema attributes and cACertificate. As you can see, it may be pretty confusing. Martin From ssorce at redhat.com Fri May 23 14:50:59 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 10:50:59 -0400 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <537F0E0E.3020204@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> Message-ID: <1400856659.7561.124.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 10:59 +0200, Martin Kosek wrote: > On 05/22/2014 04:20 PM, Petr Viktorin wrote: > > On 05/21/2014 12:14 PM, Simo Sorce wrote: > >> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: > >>> On 05/16/2014 04:33 PM, Petr Viktorin wrote: > >>>> On 05/16/2014 01:54 PM, Martin Kosek wrote: > >>>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: > >>>>>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed > >>>>>> previously > >>>>>> [0]. > >>>>>> > >>>>>> Patch 0541 is some minor refactoring for the next part. > >>>>>> > >>>>>> Patch 0542 sets the read acces to addressbook attributes to anonymous when > >>>>>> upgrading from pre-4.0. > >>>>>> I first this by checking if the update is run from ipa-server-install or > >>>>>> not, > >>>>>> but then I realized the logic I want is simple: if the global anon read ACI > >>>>>> exists, we want to preserve its spirit by setting addressbook attribute > >>>>>> ACI to > >>>>>> anonymous. > >>>>>> > >>>>>> > >>>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et > >>>>>> al. > >>>>>> > >>>>> > >>>>> 540: > >>>>> > >>>>> Looks good! The only attributes I am concerned about are special IPA > >>>>> attributes: > >>>>> > >>>>> - ipauniqueid > >>>>> - ipasshpubkey > >>>>> - ipauserauthtype > >>>>> - userclass > >>>>> > >>>>> I personally do not think they should be included in POSIX attributes > >>>>> permissions, they are far from POSIX definition... > >>>>> > >>>>> What about creating one more permission "System: Read User IPA Attributes" as > >>>>> these are specific to FreeIPA use and allowing that permission for all > >>>>> authenticated users? > >>>> > >>>> Sounds reasonable. I assume we want this one to be also set to anonymous when > >>>> upgrading from old versions. > >>>> Attaching updated patches. > >>> > >>> Ok, looks good. > >>> > >>> I am now just pondering whether "System: Read User POSIX Attributes" is the > >>> right name for the permission as there are not just POSIX attributes, but also > >>> attributes from organizationalPerson or inetOrgPerson objectclasses. > >>> > >>> Maybe we should name it "System: Read User Core Attributes" or "System: Read > >>> User Basic Attributes"? Simo, any preference? > >> > >> We could use: "System: Read User Standard Attributes" > > > > I've used this one, then. > > > >> > >> but the 'posix' version is also ok to me. > > > > On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: > >> Also, I just realized we forgot memberOf attribute - it needs to be available > >> to authenticated users otherwise group membership will fall apart. > > > > Good catch. Added. > > > > We are very close to push this one - I have just one last concern about > userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 from user, > now we added it to be read by default. This results in this warning during upgrade: > > Excluded attributes for System: Read User Addressbook Attributes: userpkcs12 > > Simo (or others), is this OK or do we want to keep hiding userpkcs12 by default? Is there any client that needs access to that information that we are aware of ? Simo. From simo at redhat.com Fri May 23 14:53:57 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 10:53:57 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537EEB9E.4050306@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> Message-ID: <1400856837.7561.127.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 08:33 +0200, Martin Kosek wrote: > On 05/23/2014 07:48 AM, Jan Cholasta wrote: > > On 22.5.2014 19:27, Simo Sorce wrote: > >> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: > >>> On 05/21/2014 10:11 PM, Dmitri Pal wrote: > >>>> On 05/21/2014 03:06 PM, Martin Kosek wrote: > >>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: > >>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Thanks for all these detailed descriptions. > >>>>>>> Just to be sure to be on the same page, here is my understanding of > >>>>>>> the provisioning templates and placeholder definitions. An > >>>>>>> administrator can provide a provisioning template. I suppose it > >>>>>>> would be a file containing a lines of placeholder definitions. > >>>>>>> > >>>>>>> * Where is located the template file ? Is there a standard > >>>>>>> repository where templates are put ? (somewhere under > >>>>>>> /etc/ipa/* ?) > >>>>>> > >>>>>> FreeIPA is a multi-master system, a file stored in a file would be > >>>>>> extremely cumbersome to use as it would require the admin to manually > >>>>>> copy it for every new replica and then keep it in sync. > >>>>>> It would also make it hard to change 'on-line'. > >>>>>> > >>>>>> Placeholders should be defined in an object similar to > >>>>>> cn=ipaConfig,cn=etc,$suffix > >>>>>> > >>>>>>> * Is there an already defined syntax for the provisionning > >>>>>>> template. ('$' is separator attr/value, %{} is substitute > >>>>>>> pattern...). If not, is it possible to user ': ' as > >>>>>>> separator ? > >>>>>> > >>>>>> Using initial and final ? like in Martin's example doesn't work ? > >>>>>> > >>>>>>> * What is the priority. The user can provide the 'homeDirectory' > >>>>>>> through different methods. Is it ok to use the following order: > >>>>>>> o the CLI option > >>>>>>> o the provisionning template > >>>>>>> o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX) > >>>>>>> > >>>>>>> For example, if it exists the provisioning template: > >>>>>>> /etc/ipa/provisioning/shell-user.template > >>>>>>> > >>>>>>> roomnumber$-2 > >>>>>>> homeDirectory$/home/net/shell-%{uid} > >>>>>>> loginShell$?shell-plugin-autogenerate? > >>>>>> > >>>>>> I do not understand this, we are not building a templating engine here, > >>>>>> you only have 2 options: > >>>>>> 1) a required (MUST) attribute has an explicit value > >>>>>> 2) a require (MUST) attribute has a placeholder value > >>>>>> > >>>>>> the placeholder value is fixed per type, and what it is substituted with > >>>>>> uses the same rules as the current code uses to autogenerate values. > >>>>>> > >>>>>>> the command: ipa user-add tuser > >>>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a > >>>>>>> staging entry: > >>>>>>> > >>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > >>>>>>> ... > >>>>>>> roomNumber: 1234 > >>>>>>> homeDirectory: /tmp/tuser > >>>>>>> loginShell: shell-plugin-autogenerate > >>>>>> > >>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should > >>>>>> be stored at all in the staged entry unless explicitly provided for by > >>>>>> the admin. > >>>>>> > >>>>>>> Then a private DS plugin (catching shell-plugin-autogenerate) > >>>>>>> generate the loginShell value when the entry becomes active. > >>>>>>> > >>>>>>> > >>>>>>> the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would > >>>>>>> create a staging entry: > >>>>>>> > >>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > >>>>>>> ... > >>>>>>> roomNumber: -2 > >>>>>>> homeDirectory: /tmp/tuser > >>>>>>> loginShell: shell-plugin-autogenerate > >>>>>> > >>>>>> roomNumber is also a MAY, so what would cause it to be set at -2, and > >>>>>> why ? > >>>>>> > >>>>>>> the command: ipa user-add tuser --to-stage would create a staging > >>>>>>> entry: > >>>>>>> > >>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX > >>>>>>> ... > >>>>>>> roomNumber: -2 > >>>>>>> homeDirectory: /home/net/shell-tuser > >>>>>>> loginShell: shell-plugin-autogenerate > >>>>>> > >>>>>> homeDirectory should be something like: ?placeholder? IMO, we do not > >>>>>> really want to play templating here. > >>>>>> > >>>>>>> In case the provisioning template does not define 'homeDirectory', > >>>>>>> then the created entry would take the value from the ipa config > >>>>>>> definition: > >>>>>> > >>>>>> that value should be taken and applied at the time the user is unstaged > >>>>>> and brought in the actual tree, not at the time a user is staged. > >>>>>> > >>>>>> HTH, > >>>>>> Simo. > >>>>>> > >>>>> > >>>>> Hello Thierry and Simo, > >>>>> > >>>>> I think Thierry was confused with this part of the design: > >>>>> > >>>>> " > >>>>> This format of placeholders gives enough space for future enhancements. For > >>>>> example, Administrator could configure a new template > >>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry. > >>>>> Such value would be replaced by "/home/net/tuser if user uid attribute is set > >>>>> to tuser > >>>>> " > >>>>> > >>>>> My intention when writing this design was to enable future use of > >>>>> configurable placeholders, i.e. a value "?someplaceholder?" could be turn > >>>>> into "/custom/path/%{uid}". But I meant that this can be considered as a > >>>>> future enhancement. For now, I think implementing a placeholder "-1" for > >>>>> numerical values and "?autogenerate?" for string ones a good start. > >>>>> > >>>>> Martin > >>>>> > >>>>> _______________________________________________ > >>>>> Freeipa-devel mailing list > >>>>> Freeipa-devel at redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>> > >>>> > >>>> Please consider the flow: user added staged -> activated/moved to main tree -> > >>>> deleted/moved to deleted tree -> staged back > >>>> At the first step his IPA user ID and UID should be undefined and > >>>> autogenerated. > >>>> On the last step his IPAUserID and UID should be preserved. The main use case > >>>> is that this is the user who left the company who comes back again. His files > >>>> should be still owned by him unless admin forces a flush of his IDs (new > >>>> switch???) when he moves user from deleted to staged. > >>>> > >>> > >>> Right, the life-cycle feature should work like that naturally, given that only > >>> attributes with "-1" or "autogenerate" are generated. > >>> > >>> If admin wants to re-generate the IDs, all he would need to do is to change the > >>> attributes back to "-1" after/before moving the user to staging. Question is > >>> when it should be done (in deleted tree, in staging tree or after activation) > >>> and what API/command we choose. > >> > >> TBH I question the whole idea of "moving to staging", in what case would > >> that make sense ? > >> > >>> Admin may want to change not only the UID/GID, but maybe also a home directory > >>> (user may be in a different department) so we should make it general. Maybe we > >>> should let user-mod support modification in staging area? Like > >>> > >>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged > >>> > >>> or > >>> > >>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted > >> > >> The reason why we have the 'deleted' area is to be able to preserve the > >> user intact ... I would almost want to ask to explicitly not allow > >> modifications to deleted users (admin can always use ldapmodify if they > >> *really* need to play some game here). > > > > +1, it seemed strange to me that modifying deleted user was allowed as well. > > Hm, ok, let us not have an API to modify deleted user then. > > As for active -> staging users flow, I only think of one scenario: > > 1) Operator moves staged user to active users > 2) Operator realizes that his mouse slipped and he moved a wrong person > 3) Operator wants to move the person quickly back to staged before anyone > notices :) Sorry I do not think it is a good reason. The admin can simply disable the user if he was so clumsy. Moving it back to staging is wrong IMO, because the user will have a number of attributes added during the 'un'staging process, and will not be pristine anyway, so the admin will not really cover any track in here. By allowing to perform these actions we instead break down the process a little bit and may cause confusion (and more work that should not be necessary). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri May 23 14:55:30 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 10:55:30 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537F5799.9060906@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> Message-ID: <1400856930.7561.129.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: > This, I believe, has already been covered, but I'm concerned with the > (over)use of active/inactive in this discussion. > > I think use of "inactive" and "active" to describe users might be > confusing since there is already an account enable/disable command. > This > on top of unlock, are there now 3 possible boolean states a user can > be > in? locked/unlocked, enabled/disabled, active/inactive, plus > deleted/active and staged/active? > Agree, we should only have "ipa user-unstage " and not call this operations with words like active/inactive. User's in the staging area are not inactive, they are *not* users yet in the first place. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri May 23 15:03:18 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 11:03:18 -0400 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537F01BF.1090703@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <1400779286.7561.93.camel@willson.li.ssimo.org> <537F01BF.1090703@redhat.com> Message-ID: <1400857398.7561.137.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote: > On 05/22/2014 07:21 PM, Simo Sorce wrote: > > On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote: > >> On 05/22/2014 04:38 PM, Martin Kosek wrote: > >>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: > >>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: > >>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: > >>>>>> 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=newemail at 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 > >>>>> I like the idea of different verbs for different hives. > >>>>> Something like: > >>>>> > >>>>> Adding directly to stage via CLI: ipa user-stage > >>>>> Removing from stage: user-unstage (user is gone) > >>>>> Stage to Main -> activate; <- deactivate > >>>>> Main to delete -> del; <-restore or undelete > >>>>> Delete to stage -> I think we can use ipa user-stage command with > >>>>> --deleted=user or similar > >>>> To be honest, I don't like this idea. > >>>> Too many names are confusing, if we can find a consistent option to cut the > >>>> number of names down we should do it. > >>>> IMO This is the worst part of Git: > >>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. > >>>> > >>>> Another good thing would be if options did not affect the applicability of > >>>> other options (too much). For example in your proposal there'd be something like: > >>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... > >>>> ipa user-stage --deleted=tuser # > >>>> We should avoid this, if only for the reason that it makes the help text > >>>> confusing. > >>>> > >>>> > >>>> My proposal would be that the move commands use the verb for the target and an > >>>> option for the source, and add/mod use an option for the container: > >>>> > >>>> 1) adding a new user > >>>> (to active) ipa user-add tuser ... > >>>> (to stage) ipa user-add tuser --staged ... > >>>> (to deleted) ipa user-add tuser --deleted ... (*) > >>>> > >>>> 2) moving to main > >>>> (from stage) ipa user-activate tuser (**) > >>>> (from del) ipa user-activate tuser --deleted > >>>> > >>>> 3) moving to deleted > >>>> (from active) ipa user-del tuser > >>>> (from stage) ipa user-del tuser --staged > >>>> > >>>> 4) moving to stage > >>>> (from active) ipa user-stage tuser > >>>> (from del) ipa user-stage tuser --deleted > >>>> > >>>> 5) modifying > >>>> (in active) ipa user-mod tuser ... > >>>> (in stage) ipa user-mod tuser --staged ... > >>>> (in del) ipa user-mod tuser --deleted ... > >>>> > >>>> Five commands (two of which are user-specific), plus two fairly consistent > >>>> options. > >>>> > >>>> If the delete container isn't configured, the --deleted option is illegal and > >>>> `user-del` deletes permanently. > >>>> > >>>> > >>>> (*) may be useful in some situations? > >>> I personally cannot imagine such situation - I would not add this command. If > >>> somebody needs that, he can workaround with > >>> > >>> ipa user-add tuser --staged > >>> ipa user-del tuser --staged > >>> > >>> ... and report us the use case when it's needed. But I general, Petr's proposal > >>> makes sense to me, I would go for it. (and update the design as Dmitri > >>> correctly proposed). > >>> > >>> Martin > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> Hello, > >> > >> I will update the design following Petr proposal. Great one ! > >> However I was thinking to a sligthly different proposal. For > >> example if we have 3 states: staging, active, inactive. > >> 1) adding a user > >> > >> (...to active) ipa user-add# ( after the command > >> ipaUniqueID=) > >> (... to staging) ipa user-add --stage# (after the command > >> ipaUniqueID=generate) > >> > >> So here we can not add a user directly into inactive state > >> > >> 2) activating the user > >> > >> (staging to active) ipa user-activate# (after the command > >> ipaUniqueID=) > >> (inactive to active) ipa user-activate --inactive# (after the > >> command ipaUniqueID=) > >> > >> 3) inactivate the user > >> > >> (active to inactive) ipa user-inactivate# (after the command > >> ipaUniqueID=) > >> > >> Here there is no possibility to move back an active entry to > >> staging, because in staging > >> the entries do not have ipaUniqueID set > > Do we ever want to allow to move a user from active to staging ? > > > > I can't find a case where my answer is yes. > > > > From my POV a user once it leaves staging is either active or deleted, > > in my mind there is no reason ever to move a user into staging. > > > > In what case does it make sense ? > > > > Simo. > > > Hi Simo, > > When moving an entry 'staging' -> 'active', some attributes are set (at > least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes > are set for ever even if later the entry is moved 'active'->'deleted'. > One can imagine that an administrator is not "happy" with the values > computed. For example, he would prefer uidNumber to be computed from an > other range. No, this is not in play. The reason we have been requested the 'deleted' area is for regulatory purposes where the administrators are *mandated* to keep users intact *especially* for uniquely identifying IDs. > For that, moving back the entry from 'active' -> 'staging' would be an > option (if those attributes are 'reset'). No, if the admins does not like uid numbers or unique ids, what it really means is that the admin just wanted to delete the original user and recreate a completely new one with the same name. In that case the admin should do just that. In the rare case when the admin really want to delete-and-preserve, and later on change some uniquely identifying attributes he has already 2 ways: 1) 'un'delete the user and *then* change the ids, simple, straightforward. 2) use ldamodify to change the entry while in the deleted area. > I do not know if it is a valid use case but IMHO I would prefere he > moves the entry 'active'->'delete' then delete the entry and recreate a > new one. You can do it, see above. I think the only operations allowed should be the following: 1. add user in staging area 2. un-stage user 3. move user to delete area 4. un-delete user In all cases users in the staging or deleted area cannot be modified via ipa commands I do not think any other operation should be 'aided' by ipa tools unless there is overwhelming request motivated by reasonable work-flows to do anything else. If there is this request we can add more in the future. Admins that need to change stuff can do so when the user is 'live', or can use ldapmodify and directly access the entries in LDAP. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Fri May 23 15:18:18 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 May 2014 17:18:18 +0200 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <1400857398.7561.137.camel@willson.li.ssimo.org> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <1400779286.7561.93.camel@willson.li.ssimo.org> <537F01BF.1090703@redhat.com> <1400857398.7561.137.camel@willson.li.ssimo.org> Message-ID: <537F66BA.8060006@redhat.com> On 05/23/2014 05:03 PM, Simo Sorce wrote: > On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote: >> On 05/22/2014 07:21 PM, Simo Sorce wrote: >>> On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote: >>>> On 05/22/2014 04:38 PM, Martin Kosek wrote: >>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: >>>>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: >>>>>>>> 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=newemail at 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 >>>>>>> I like the idea of different verbs for different hives. >>>>>>> Something like: >>>>>>> >>>>>>> Adding directly to stage via CLI: ipa user-stage >>>>>>> Removing from stage: user-unstage (user is gone) >>>>>>> Stage to Main -> activate; <- deactivate >>>>>>> Main to delete -> del; <-restore or undelete >>>>>>> Delete to stage -> I think we can use ipa user-stage command with >>>>>>> --deleted=user or similar >>>>>> To be honest, I don't like this idea. >>>>>> Too many names are confusing, if we can find a consistent option to cut the >>>>>> number of names down we should do it. >>>>>> IMO This is the worst part of Git: >>>>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. >>>>>> >>>>>> Another good thing would be if options did not affect the applicability of >>>>>> other options (too much). For example in your proposal there'd be something like: >>>>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... >>>>>> ipa user-stage --deleted=tuser # >>>>>> We should avoid this, if only for the reason that it makes the help text >>>>>> confusing. >>>>>> >>>>>> >>>>>> My proposal would be that the move commands use the verb for the target and an >>>>>> option for the source, and add/mod use an option for the container: >>>>>> >>>>>> 1) adding a new user >>>>>> (to active) ipa user-add tuser ... >>>>>> (to stage) ipa user-add tuser --staged ... >>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>> >>>>>> 2) moving to main >>>>>> (from stage) ipa user-activate tuser (**) >>>>>> (from del) ipa user-activate tuser --deleted >>>>>> >>>>>> 3) moving to deleted >>>>>> (from active) ipa user-del tuser >>>>>> (from stage) ipa user-del tuser --staged >>>>>> >>>>>> 4) moving to stage >>>>>> (from active) ipa user-stage tuser >>>>>> (from del) ipa user-stage tuser --deleted >>>>>> >>>>>> 5) modifying >>>>>> (in active) ipa user-mod tuser ... >>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>> >>>>>> Five commands (two of which are user-specific), plus two fairly consistent >>>>>> options. >>>>>> >>>>>> If the delete container isn't configured, the --deleted option is illegal and >>>>>> `user-del` deletes permanently. >>>>>> >>>>>> >>>>>> (*) may be useful in some situations? >>>>> I personally cannot imagine such situation - I would not add this command. If >>>>> somebody needs that, he can workaround with >>>>> >>>>> ipa user-add tuser --staged >>>>> ipa user-del tuser --staged >>>>> >>>>> ... and report us the use case when it's needed. But I general, Petr's proposal >>>>> makes sense to me, I would go for it. (and update the design as Dmitri >>>>> correctly proposed). >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Hello, >>>> >>>> I will update the design following Petr proposal. Great one ! >>>> However I was thinking to a sligthly different proposal. For >>>> example if we have 3 states: staging, active, inactive. >>>> 1) adding a user >>>> >>>> (...to active) ipa user-add# ( after the command >>>> ipaUniqueID=) >>>> (... to staging) ipa user-add --stage# (after the command >>>> ipaUniqueID=generate) >>>> >>>> So here we can not add a user directly into inactive state >>>> >>>> 2) activating the user >>>> >>>> (staging to active) ipa user-activate# (after the command >>>> ipaUniqueID=) >>>> (inactive to active) ipa user-activate --inactive# (after the >>>> command ipaUniqueID=) >>>> >>>> 3) inactivate the user >>>> >>>> (active to inactive) ipa user-inactivate# (after the command >>>> ipaUniqueID=) >>>> >>>> Here there is no possibility to move back an active entry to >>>> staging, because in staging >>>> the entries do not have ipaUniqueID set >>> Do we ever want to allow to move a user from active to staging ? >>> >>> I can't find a case where my answer is yes. >>> >>> From my POV a user once it leaves staging is either active or deleted, >>> in my mind there is no reason ever to move a user into staging. >>> >>> In what case does it make sense ? >>> >>> Simo. >>> >> Hi Simo, >> >> When moving an entry 'staging' -> 'active', some attributes are set (at >> least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes >> are set for ever even if later the entry is moved 'active'->'deleted'. >> One can imagine that an administrator is not "happy" with the values >> computed. For example, he would prefer uidNumber to be computed from an >> other range. > No, this is not in play. The reason we have been requested the 'deleted' > area is for regulatory purposes where the administrators are *mandated* > to keep users intact *especially* for uniquely identifying IDs. Ok I agree. Now I was thinking to an other reason an administrator would appreciate 'active' -> 'stage'. The move 'stage' -> 'active' requires an approval. Then the policy changes and some active users now needs an additional approval. It would be a possibility to return the active user to the staging area. > >> For that, moving back the entry from 'active' -> 'staging' would be an >> option (if those attributes are 'reset'). > No, if the admins does not like uid numbers or unique ids, what it > really means is that the admin just wanted to delete the original user > and recreate a completely new one with the same name. In that case the > admin should do just that. > > In the rare case when the admin really want to delete-and-preserve, and > later on change some uniquely identifying attributes he has already 2 > ways: > 1) 'un'delete the user and *then* change the ids, simple, > straightforward. > 2) use ldamodify to change the entry while in the deleted area. > >> I do not know if it is a valid use case but IMHO I would prefere he >> moves the entry 'active'->'delete' then delete the entry and recreate a >> new one. > You can do it, see above. > > I think the only operations allowed should be the following: > > 1. add user in staging area > 2. un-stage user > 3. move user to delete area > 4. un-delete user > In all cases users in the staging or deleted area cannot be modified via > ipa commands > > I do not think any other operation should be 'aided' by ipa tools unless > there is overwhelming request motivated by reasonable work-flows to do > anything else. If there is this request we can add more in the future. > Admins that need to change stuff can do so when the user is 'live', or > can use ldapmodify and directly access the entries in LDAP. > > Simo. > From simo at redhat.com Fri May 23 15:33:26 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 11:33:26 -0400 Subject: [Freeipa-devel] Status/Question about User life cycle In-Reply-To: <537F66BA.8060006@redhat.com> References: <5376254D.7050700@redhat.com> <5379A394.4000908@redhat.com> <5379A3BC.3050908@redhat.com> <5379E0F8.7000106@redhat.com> <5379E462.2040400@redhat.com> <537A04F4.3010906@redhat.com> <537A0D1D.1040900@redhat.com> <537A0F30.9030409@redhat.com> <537A1389.6050408@redhat.com> <537A1670.6050206@redhat.com> <537A18C1.9080702@redhat.com> <537A18F7.7010703@redhat.com> <537D05C1.3010808@redhat.com> <537DB992.3050900@redhat.com> <537E0BF4.4040806@redhat.com> <537E1D23.6080703@redhat.com> <1400779286.7561.93.camel@willson.li.ssimo.org> <537F01BF.1090703@redhat.com> <1400857398.7561.137.camel@willson.li.ssimo.org> <537F66BA.8060006@redhat.com> Message-ID: <1400859206.7561.142.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 17:18 +0200, thierry bordaz wrote: > On 05/23/2014 05:03 PM, Simo Sorce wrote: > > On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote: > >> On 05/22/2014 07:21 PM, Simo Sorce wrote: > >>> On Thu, 2014-05-22 at 17:52 +0200, thierry bordaz wrote: > >>>> On 05/22/2014 04:38 PM, Martin Kosek wrote: > >>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: > >>>>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote: > >>>>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote: > >>>>>>>> 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=newemail at 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 > >>>>>>> I like the idea of different verbs for different hives. > >>>>>>> Something like: > >>>>>>> > >>>>>>> Adding directly to stage via CLI: ipa user-stage > >>>>>>> Removing from stage: user-unstage (user is gone) > >>>>>>> Stage to Main -> activate; <- deactivate > >>>>>>> Main to delete -> del; <-restore or undelete > >>>>>>> Delete to stage -> I think we can use ipa user-stage command with > >>>>>>> --deleted=user or similar > >>>>>> To be honest, I don't like this idea. > >>>>>> Too many names are confusing, if we can find a consistent option to cut the > >>>>>> number of names down we should do it. > >>>>>> IMO This is the worst part of Git: > >>>>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better. > >>>>>> > >>>>>> Another good thing would be if options did not affect the applicability of > >>>>>> other options (too much). For example in your proposal there'd be something like: > >>>>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ...... > >>>>>> ipa user-stage --deleted=tuser # > >>>>>> We should avoid this, if only for the reason that it makes the help text > >>>>>> confusing. > >>>>>> > >>>>>> > >>>>>> My proposal would be that the move commands use the verb for the target and an > >>>>>> option for the source, and add/mod use an option for the container: > >>>>>> > >>>>>> 1) adding a new user > >>>>>> (to active) ipa user-add tuser ... > >>>>>> (to stage) ipa user-add tuser --staged ... > >>>>>> (to deleted) ipa user-add tuser --deleted ... (*) > >>>>>> > >>>>>> 2) moving to main > >>>>>> (from stage) ipa user-activate tuser (**) > >>>>>> (from del) ipa user-activate tuser --deleted > >>>>>> > >>>>>> 3) moving to deleted > >>>>>> (from active) ipa user-del tuser > >>>>>> (from stage) ipa user-del tuser --staged > >>>>>> > >>>>>> 4) moving to stage > >>>>>> (from active) ipa user-stage tuser > >>>>>> (from del) ipa user-stage tuser --deleted > >>>>>> > >>>>>> 5) modifying > >>>>>> (in active) ipa user-mod tuser ... > >>>>>> (in stage) ipa user-mod tuser --staged ... > >>>>>> (in del) ipa user-mod tuser --deleted ... > >>>>>> > >>>>>> Five commands (two of which are user-specific), plus two fairly consistent > >>>>>> options. > >>>>>> > >>>>>> If the delete container isn't configured, the --deleted option is illegal and > >>>>>> `user-del` deletes permanently. > >>>>>> > >>>>>> > >>>>>> (*) may be useful in some situations? > >>>>> I personally cannot imagine such situation - I would not add this command. If > >>>>> somebody needs that, he can workaround with > >>>>> > >>>>> ipa user-add tuser --staged > >>>>> ipa user-del tuser --staged > >>>>> > >>>>> ... and report us the use case when it's needed. But I general, Petr's proposal > >>>>> makes sense to me, I would go for it. (and update the design as Dmitri > >>>>> correctly proposed). > >>>>> > >>>>> Martin > >>>>> > >>>>> _______________________________________________ > >>>>> Freeipa-devel mailing list > >>>>> Freeipa-devel at redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>> Hello, > >>>> > >>>> I will update the design following Petr proposal. Great one ! > >>>> However I was thinking to a sligthly different proposal. For > >>>> example if we have 3 states: staging, active, inactive. > >>>> 1) adding a user > >>>> > >>>> (...to active) ipa user-add# ( after the command > >>>> ipaUniqueID=) > >>>> (... to staging) ipa user-add --stage# (after the command > >>>> ipaUniqueID=generate) > >>>> > >>>> So here we can not add a user directly into inactive state > >>>> > >>>> 2) activating the user > >>>> > >>>> (staging to active) ipa user-activate# (after the command > >>>> ipaUniqueID=) > >>>> (inactive to active) ipa user-activate --inactive# (after the > >>>> command ipaUniqueID=) > >>>> > >>>> 3) inactivate the user > >>>> > >>>> (active to inactive) ipa user-inactivate# (after the command > >>>> ipaUniqueID=) > >>>> > >>>> Here there is no possibility to move back an active entry to > >>>> staging, because in staging > >>>> the entries do not have ipaUniqueID set > >>> Do we ever want to allow to move a user from active to staging ? > >>> > >>> I can't find a case where my answer is yes. > >>> > >>> From my POV a user once it leaves staging is either active or deleted, > >>> in my mind there is no reason ever to move a user into staging. > >>> > >>> In what case does it make sense ? > >>> > >>> Simo. > >>> > >> Hi Simo, > >> > >> When moving an entry 'staging' -> 'active', some attributes are set (at > >> least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes > >> are set for ever even if later the entry is moved 'active'->'deleted'. > >> One can imagine that an administrator is not "happy" with the values > >> computed. For example, he would prefer uidNumber to be computed from an > >> other range. > > No, this is not in play. The reason we have been requested the 'deleted' > > area is for regulatory purposes where the administrators are *mandated* > > to keep users intact *especially* for uniquely identifying IDs. > > Ok I agree. > Now I was thinking to an other reason an administrator would appreciate > 'active' -> 'stage'. > The move 'stage' -> 'active' requires an approval. Then the policy > changes and some active users now needs an additional approval. > It would be a possibility to return the active user to the staging area. I think you should simply disable users in that case, I do not see the case where it would be a requirement to completely remove them, and if that is really required the easiest way would still to just move the users in the deleted area and then un-delete them. But I think your scenario is quite unlikely. The staging area is mostly to allow automated provisioning systems to add a 'simple' LDAP object and then let the ipa tools augment all there is to augment before making the user really active. In fact, in some cases moving the user from staging to active will probably be a cron-job or similar automated system. I think we need to think about the staging area as "user with incomplete information" area. It is true we will also use the staging area in work-flows that require multi-step authorizations, but once a user is approved it doesn't really make sense to put it back IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Fri May 23 15:47:17 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 May 2014 17:47:17 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537F031E.8070701@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F031E.8070701@redhat.com> Message-ID: <537F6D85.6040103@redhat.com> On 05/23/2014 10:13 AM, Petr Viktorin wrote: > On 05/23/2014 08:33 AM, Martin Kosek wrote: >> On 05/23/2014 07:48 AM, Jan Cholasta wrote: >>> On 22.5.2014 19:27, Simo Sorce wrote: >>>> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote: >>>>> On 05/21/2014 10:11 PM, Dmitri Pal wrote: >>>>>> On 05/21/2014 03:06 PM, Martin Kosek wrote: >>>>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote: >>>>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Thanks for all these detailed descriptions. >>>>>>>>> Just to be sure to be on the same page, here is my >>>>>>>>> understanding of >>>>>>>>> the provisioning templates and placeholder definitions. An >>>>>>>>> administrator can provide a provisioning template. I >>>>>>>>> suppose it >>>>>>>>> would be a file containing a lines of placeholder >>>>>>>>> definitions. >>>>>>>>> >>>>>>>>> * Where is located the template file ? Is there a >>>>>>>>> standard >>>>>>>>> repository where templates are put ? (somewhere under >>>>>>>>> /etc/ipa/* ?) >>>>>>>> >>>>>>>> FreeIPA is a multi-master system, a file stored in a file would be >>>>>>>> extremely cumbersome to use as it would require the admin to >>>>>>>> manually >>>>>>>> copy it for every new replica and then keep it in sync. >>>>>>>> It would also make it hard to change 'on-line'. >>>>>>>> >>>>>>>> Placeholders should be defined in an object similar to >>>>>>>> cn=ipaConfig,cn=etc,$suffix >>>>>>>> >>>>>>>>> * Is there an already defined syntax for the >>>>>>>>> provisionning >>>>>>>>> template. ('$' is separator attr/value, %{} >>>>>>>>> is substitute >>>>>>>>> pattern...). If not, is it possible to user >>>>>>>>> ': ' as >>>>>>>>> separator ? >>>>>>>> >>>>>>>> Using initial and final ? like in Martin's example doesn't work ? >>>>>>>> >>>>>>>>> * What is the priority. The user can provide the >>>>>>>>> 'homeDirectory' >>>>>>>>> through different methods. Is it ok to use the >>>>>>>>> following order: >>>>>>>>> o the CLI option >>>>>>>>> o the provisionning template >>>>>>>>> o the default config value (in >>>>>>>>> cn=ipaConfig,cn=etc,$SUFFIX) >>>>>>>>> >>>>>>>>> For example, if it exists the provisioning template: >>>>>>>>> /etc/ipa/provisioning/shell-user.template >>>>>>>>> >>>>>>>>> roomnumber$-2 >>>>>>>>> homeDirectory$/home/net/shell-%{uid} >>>>>>>>> loginShell$?shell-plugin-autogenerate? >>>>>>>> >>>>>>>> I do not understand this, we are not building a templating >>>>>>>> engine here, >>>>>>>> you only have 2 options: >>>>>>>> 1) a required (MUST) attribute has an explicit value >>>>>>>> 2) a require (MUST) attribute has a placeholder value >>>>>>>> >>>>>>>> the placeholder value is fixed per type, and what it is >>>>>>>> substituted with >>>>>>>> uses the same rules as the current code uses to autogenerate >>>>>>>> values. >>>>>>>> >>>>>>>>> the command: ipa user-add tuser >>>>>>>>> --homedir=/tmp/tuser--roomnumber=1234 --to-stage would >>>>>>>>> create a >>>>>>>>> staging entry: >>>>>>>>> >>>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>>> ... >>>>>>>>> roomNumber: 1234 >>>>>>>>> homeDirectory: /tmp/tuser >>>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>>> >>>>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing >>>>>>>> should >>>>>>>> be stored at all in the staged entry unless explicitly provided >>>>>>>> for by >>>>>>>> the admin. >>>>>>>> >>>>>>>>> Then a private DS plugin (catching >>>>>>>>> shell-plugin-autogenerate) >>>>>>>>> generate the loginShell value when the entry becomes >>>>>>>>> active. >>>>>>>>> >>>>>>>>> >>>>>>>>> the command: ipa user-add tuser >>>>>>>>> --homedir=/tmp/tuser--to-stage would >>>>>>>>> create a staging entry: >>>>>>>>> >>>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>>> ... >>>>>>>>> roomNumber: -2 >>>>>>>>> homeDirectory: /tmp/tuser >>>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>>> >>>>>>>> roomNumber is also a MAY, so what would cause it to be set at >>>>>>>> -2, and >>>>>>>> why ? >>>>>>>> >>>>>>>>> the command: ipa user-add tuser --to-stage would create >>>>>>>>> a staging >>>>>>>>> entry: >>>>>>>>> >>>>>>>>> dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX >>>>>>>>> ... >>>>>>>>> roomNumber: -2 >>>>>>>>> homeDirectory: /home/net/shell-tuser >>>>>>>>> loginShell: shell-plugin-autogenerate >>>>>>>> >>>>>>>> homeDirectory should be something like: ?placeholder? IMO, we >>>>>>>> do not >>>>>>>> really want to play templating here. >>>>>>>> >>>>>>>>> In case the provisioning template does not define >>>>>>>>> 'homeDirectory', >>>>>>>>> then the created entry would take the value from the >>>>>>>>> ipa config >>>>>>>>> definition: >>>>>>>> >>>>>>>> that value should be taken and applied at the time the user is >>>>>>>> unstaged >>>>>>>> and brought in the actual tree, not at the time a user is staged. >>>>>>>> >>>>>>>> HTH, >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> Hello Thierry and Simo, >>>>>>> >>>>>>> I think Thierry was confused with this part of the design: >>>>>>> >>>>>>> " >>>>>>> This format of placeholders gives enough space for future >>>>>>> enhancements. For >>>>>>> example, Administrator could configure a new template >>>>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged >>>>>>> LDAP entry. >>>>>>> Such value would be replaced by "/home/net/tuser if user uid >>>>>>> attribute is set >>>>>>> to tuser >>>>>>> " >>>>>>> >>>>>>> My intention when writing this design was to enable future use of >>>>>>> configurable placeholders, i.e. a value "?someplaceholder?" >>>>>>> could be turn >>>>>>> into "/custom/path/%{uid}". But I meant that this can be >>>>>>> considered as a >>>>>>> future enhancement. For now, I think implementing a placeholder >>>>>>> "-1" for >>>>>>> numerical values and "?autogenerate?" for string ones a good start. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> >>>>>> Please consider the flow: user added staged -> activated/moved to >>>>>> main tree -> >>>>>> deleted/moved to deleted tree -> staged back >>>>>> At the first step his IPA user ID and UID should be undefined and >>>>>> autogenerated. >>>>>> On the last step his IPAUserID and UID should be preserved. The >>>>>> main use case >>>>>> is that this is the user who left the company who comes back >>>>>> again. His files >>>>>> should be still owned by him unless admin forces a flush of his >>>>>> IDs (new >>>>>> switch???) when he moves user from deleted to staged. >>>>>> >>>>> >>>>> Right, the life-cycle feature should work like that naturally, >>>>> given that only >>>>> attributes with "-1" or "autogenerate" are generated. >>>>> >>>>> If admin wants to re-generate the IDs, all he would need to do is >>>>> to change the >>>>> attributes back to "-1" after/before moving the user to staging. >>>>> Question is >>>>> when it should be done (in deleted tree, in staging tree or after >>>>> activation) >>>>> and what API/command we choose. >>>> >>>> TBH I question the whole idea of "moving to staging", in what case >>>> would >>>> that make sense ? >>>> >>>>> Admin may want to change not only the UID/GID, but maybe also a >>>>> home directory >>>>> (user may be in a different department) so we should make it >>>>> general. Maybe we >>>>> should let user-mod support modification in staging area? Like >>>>> >>>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged >>>>> >>>>> or >>>>> >>>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted >>>> >>>> The reason why we have the 'deleted' area is to be able to preserve >>>> the >>>> user intact ... I would almost want to ask to explicitly not allow >>>> modifications to deleted users (admin can always use ldapmodify if >>>> they >>>> *really* need to play some game here). >>> >>> +1, it seemed strange to me that modifying deleted user was allowed >>> as well. >> >> Hm, ok, let us not have an API to modify deleted user then. > > Here's a scenario: > - automember is set to add users the appropriate groups when userclass > is set to "junior admin", or "senior admin" > - Johnny the Junior Admin leaves the company, is deleted > - After some time Johnny joins again as Senior Admin > > I think in this case we'd want to set the userclass to "senior admin" > before restoring the user. > Other changes (e.g. a name change) can be done after restoring the > user, but it still seems cleaner for me if they could be done on the > deleted user (or if the deleted user could be restored to stage > first). There may be other plugins that run on add and expect current > information. About membership. I think it could be risky to keep membership in 'delete' or 'stage'. Those entries are not valid user and should not belong to any active group. Should we keep membership attributes in those state or let the plugin recompute the valid values when the entry is back to active ? > > >> As for active -> staging users flow, I only think of one scenario: >> >> 1) Operator moves staged user to active users >> 2) Operator realizes that his mouse slipped and he moved a wrong person >> 3) Operator wants to move the person quickly back to staged before >> anyone >> notices :) >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > From simo at redhat.com Fri May 23 17:01:38 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 13:01:38 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <537F6D85.6040103@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F031E.8070701@redhat.com> <537F6D85.6040103@redhat.com> Message-ID: <1400864498.7561.155.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 17:47 +0200, thierry bordaz wrote: > About membership. I think it could be risky to keep membership in > 'delete' or 'stage'. Those entries are not valid user and should not > belong to any active group. Should we keep membership attributes in > those state or let the plugin recompute the valid values when the > entry > is back to active ? > Recompute. When a user is deleted it loses the memberships, when it is reactivated then new memberships need to be computed or explicitly added. Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Fri May 23 21:05:44 2014 From: purpleidea at gmail.com (James) Date: Fri, 23 May 2014 17:05:44 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <537F2612.7050101@redhat.com> References: <537F2612.7050101@redhat.com> Message-ID: <1400879144.23683.96.camel@freed> On Fri, 2014-05-23 at 12:42 +0200, Martin Kosek wrote: > On 05/23/2014 07:01 AM, James wrote: > > I'm trying to understand some of the FreeIPA replication internals so > > that I can better know how to do this properly in Puppet without > > storing any secret information in Puppet, and so that automating > > FreeIPA is awesome. > > > > Please point me to any docs, if there is reading I could be doing :) > > > > Here are some open questions I have: > > > > 1) Is the GPG file created with ipa-replica-prepare using a symmetric > > password and is that password equal to the dm_password ? If not, where > > do the pub/priv key pairs come from and how do they get transferred to > > the replica. > > Yes. Grep for function expand_replica_info in FreeIPA git. Found it, very helpful, thanks! > > > > > 2) If I have root on the IPA server (actually all of them) how can I > > run ipa-replica-prepare without needing interactive prompting for > > entering the password. It's not possible with puppet. Is there another > > (possibly less user friendly even) method to "prepare" the replica? > > What is prepare actually doing? > > For, you can for example use --password for passing the DM password. Good to know, but I'd like to avoid knowing the password actually. More in the other thread... > > > > 3) With a multi master setup, what happens if I run the same action > > (eg: user-mod or user-add or user-del) on more than one server. > > I would not do that, you risk replication conflicts on entries or attributes. > More here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html If the exact same action is run on different servers at the same time, will it still cause a replication conflict, or will it auto-resolve ? > > > Can I > > run it on any server? > > Yes. > > > What if I run different user-mod commands of the > > same user on different masters. Is there split brain? > > Then you get a replication conflict. I think in case of attributes, last > modification wins. > > > Are all the > > transactions and writes synchronous across the whole cluster? > > They are not synchronous, it takes some time for a change to replica to all > masters. > > > Please > > point me to a doc that explains this FAQ stuff if possible. Sorry for > > the noise > > You should be able to get a reasonable starting information here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html > > or here: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html This is good information, thanks. I will have to do my homework and come back when I have more questions. Thanks again, James > > HTH, > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Fri May 23 21:09:08 2014 From: purpleidea at gmail.com (James) Date: Fri, 23 May 2014 17:09:08 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <537F4CEE.3040001@redhat.com> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> Message-ID: <1400879348.23683.98.camel@freed> On Fri, 2014-05-23 at 09:28 -0400, Dmitri Pal wrote: > I guess the question is more: > If I am root is there any way to do the operation without providing > the > password but rather using something like LDAPI to drive the operation. > The issue is that if you use puppet there is no way to get the > password > dynamically from some kind of source without baking it into the > scripts. > Baking passwords into scripts is bad so to avoid it there needs to be > a > way for root to install replica without it. I am not sure it is > currently possible though. This is correct... It makes sense to me that there could be some way to do it without actually knowing the plain-text password as long as there is an existing secure channel to the new host. More on this in another mail... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Fri May 23 21:16:50 2014 From: purpleidea at gmail.com (James) Date: Fri, 23 May 2014 17:16:50 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <537F50D8.2080306@redhat.com> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> <537F50D8.2080306@redhat.com> Message-ID: <1400879810.23683.106.camel@freed> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote: > One cannot easily improve ipa-replica-prepare to work through LDAPI as > we also > need to encypher the replica info package - and we cannot do that > without clear > text DM password. > > The right way seems to be rather the RFE you filed: > https://fedorahosted.org/freeipa/ticket/2888 > > Martin Here is the model I am considering: Since each replica in a multi-master cluster is said to be functionally "identical" once they're all setup, I'd actually like to try and match this elegant symmetry that you've provided with an equally symmetrical (or homogeneous, rather) design. That's to say I want the config management parts to "be identical" on each host. What this means: * It should be possible to parallelize a good chunk of the setup, if I were to bring up a cluster of four hosts at the same time. * It's convenient if each individual host follows the same initial ipa-server-install process, but that there is a secondary "join with my peer" process. * In theory, if I set up two identical freeipa servers with the same options (but different hostnames) I would like to be able to introduce them to each other at a later date and join them (even if this means that we pick one as the source of the data and the others data gets overwritten) Does this help explain the need? For an example of peering that works this way and is symmetrical with configuration management, my puppet-gluster module does this. Cheers, and thanks for reading. James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From npmccallum at redhat.com Fri May 23 21:19:50 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 23 May 2014 17:19:50 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400090912.4568.13.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> Message-ID: <1400879990.2513.23.camel@ipa.example.com> On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: > Occasionally OTP tokens get out of sync with the server. When this > happens, the user or an admin need to synchronize the token. To this > end, we landed server-side synchronization support, which is a simple > bind with a custom control. This all works with my sample test script. > > Client support is proving a bit more difficult. In the ideal world, the > client would contact LDAP directly and perform the operation. This would > make a man in the middle attack difficult and we can ensure encryption > over the entire operation. > > However, browsers, without server-side assistance, cannot perform this > operation from javascript. This means that, in this case, the first > factor and two second factors must be transmitted to the FreeIPA server > and then proxied to 389. Is this an acceptable compromise? > > This command also needs to be accessible *without* an existing user > login since, if a user's token is out of sync, the user can't login. Is > it possible to expose such an API? If so, how? Both "ipa env" and "ipa > ping" seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Second, I can create a Command subclass, similar to the passwd plugin. This will create both the client- and server-side components. However, there is no way to disable the server-side authentication. I think that solving the second of these problems is the most reusable. Just as an example, the ping command currently requires authentication but does not need to do so. The passwd Command too shouldn't need to authenticate before executing the command because the command authenticates itself. I think it very likely that we are going to have need for other Command subclasses in the future which do not require authentication. However, implementing this approach is rather difficult as it will require a refactoring of rpcserver.py. The code in rpcserver.py contains many layering violations and the class structure is rather unclear (look, for instance, at the different orders in which xmlrpc and jsonrpc classes inherit from their parent classes). The current problem forcing this refactoring is that authentication appears to happen across several different layers, but always before the command to be executed is unmarshalled. We need to invert this order: the command needs to be unmarshalled first in order to determine whether or not authentication is necessary. I don't think that switching this order is practical without constraining authentication to a single layer (or two: session and krb5) late in the request process. Git tells me that lots of people have touched this code, so I'm hoping for good feedback! ;) Alternatively, we could create a way to inject cli commands without having Command subclasses. Isolating these concerns is itself probably a good design choice. Ideally we'd have a structure where the Command class itself inherits from a CLICommand class and a ServerMethod class. But this too will be a massive refactoring, perhaps even bigger than the rpcserver.py refactoring. So, which assumption should we break: #1 or #2? And who wants to help me do it? Also, I am all ears for easier solutions for this feature. Nathaniel From simo at redhat.com Fri May 23 23:49:10 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 19:49:10 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <1400879810.23683.106.camel@freed> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> <537F50D8.2080306@redhat.com> <1400879810.23683.106.camel@freed> Message-ID: <1400888950.7561.167.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 17:16 -0400, James wrote: > On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote: > > One cannot easily improve ipa-replica-prepare to work through LDAPI as > > we also > > need to encypher the replica info package - and we cannot do that > > without clear > > text DM password. > > > > The right way seems to be rather the RFE you filed: > > https://fedorahosted.org/freeipa/ticket/2888 > > > > Martin > > Here is the model I am considering: > > Since each replica in a multi-master cluster is said to be functionally > "identical" once they're all setup, I'd actually like to try and match > this elegant symmetry that you've provided with an equally symmetrical > (or homogeneous, rather) design. That's to say I want the config > management parts to "be identical" on each host. > > What this means: > * It should be possible to parallelize a good chunk of the setup, if I > were to bring up a cluster of four hosts at the same time. > > * It's convenient if each individual host follows the same initial > ipa-server-install process, but that there is a secondary "join with my > peer" process. > > * In theory, if I set up two identical freeipa servers with the same > options (but different hostnames) I would like to be able to introduce > them to each other at a later date and join them (even if this means > that we pick one as the source of the data and the others data gets > overwritten) What is the point really ? You get this "symmetrical" install by doing a useless install of all fours and then practically redoing the install for 3 of the 4. Might as well just install 1 first and then do the other 3 in parallel, less CPU gets wasted. > Does this help explain the need? For an example of peering that works > this way and is symmetrical with configuration management, my > puppet-gluster module does this. I think this is a case where aesthetics clash with reality. Reality requires a serialization due to the need of having a common CA that releases certificates and a common KDC database that release keytabs for all services before all of them are installed. Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Sat May 24 01:26:15 2014 From: purpleidea at gmail.com (James) Date: Fri, 23 May 2014 21:26:15 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <1400888950.7561.167.camel@willson.li.ssimo.org> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> <537F50D8.2080306@redhat.com> <1400879810.23683.106.camel@freed> <1400888950.7561.167.camel@willson.li.ssimo.org> Message-ID: On Fri, May 23, 2014 at 7:49 PM, Simo Sorce wrote: > On Fri, 2014-05-23 at 17:16 -0400, James wrote: >> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote: >> > One cannot easily improve ipa-replica-prepare to work through LDAPI as >> > we also >> > need to encypher the replica info package - and we cannot do that >> > without clear >> > text DM password. >> > >> > The right way seems to be rather the RFE you filed: >> > https://fedorahosted.org/freeipa/ticket/2888 >> > >> > Martin >> >> Here is the model I am considering: >> >> Since each replica in a multi-master cluster is said to be functionally >> "identical" once they're all setup, I'd actually like to try and match >> this elegant symmetry that you've provided with an equally symmetrical >> (or homogeneous, rather) design. That's to say I want the config >> management parts to "be identical" on each host. >> >> What this means: >> * It should be possible to parallelize a good chunk of the setup, if I >> were to bring up a cluster of four hosts at the same time. >> >> * It's convenient if each individual host follows the same initial >> ipa-server-install process, but that there is a secondary "join with my >> peer" process. >> >> * In theory, if I set up two identical freeipa servers with the same >> options (but different hostnames) I would like to be able to introduce >> them to each other at a later date and join them (even if this means >> that we pick one as the source of the data and the others data gets >> overwritten) > > What is the point really ? > > You get this "symmetrical" install by doing a useless install of all > fours and then practically redoing the install for 3 of the 4. Might as > well just install 1 first and then do the other 3 in parallel, less CPU > gets wasted. This might actually be a good approach. I'll be trying to prototype some things this week, and I'll try this out. > >> Does this help explain the need? For an example of peering that works >> this way and is symmetrical with configuration management, my >> puppet-gluster module does this. > > I think this is a case where aesthetics clash with reality. I think I agree. The exception is that if the hosts are not all the same, this makes specifying the config management bits significantly harder. If they're the same, you can use a common pattern for all hosts. This gives you a sort of "high availability" at the config management level, meaning that if the host you designated as #1 is down, you'd still be able to continue. > Reality requires a serialization due to the need of having a common CA > that releases certificates and a common KDC database that release > keytabs for all services before all of them are installed. Thank you for your input. One of my goals is to satisfy your requirements on the "security" side. I'm sure you wouldn't approve of the status quo of storing the dm_password and admin_password in puppet. Me neither :) From simo at redhat.com Sat May 24 02:50:29 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 22:50:29 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> <537F50D8.2080306@redhat.com> <1400879810.23683.106.camel@freed> <1400888950.7561.167.camel@willson.li.ssimo.org> Message-ID: <1400899829.7561.170.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 21:26 -0400, James wrote: > On Fri, May 23, 2014 at 7:49 PM, Simo Sorce wrote: > > On Fri, 2014-05-23 at 17:16 -0400, James wrote: > >> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote: > >> > One cannot easily improve ipa-replica-prepare to work through LDAPI as > >> > we also > >> > need to encypher the replica info package - and we cannot do that > >> > without clear > >> > text DM password. > >> > > >> > The right way seems to be rather the RFE you filed: > >> > https://fedorahosted.org/freeipa/ticket/2888 > >> > > >> > Martin > >> > >> Here is the model I am considering: > >> > >> Since each replica in a multi-master cluster is said to be functionally > >> "identical" once they're all setup, I'd actually like to try and match > >> this elegant symmetry that you've provided with an equally symmetrical > >> (or homogeneous, rather) design. That's to say I want the config > >> management parts to "be identical" on each host. > >> > >> What this means: > >> * It should be possible to parallelize a good chunk of the setup, if I > >> were to bring up a cluster of four hosts at the same time. > >> > >> * It's convenient if each individual host follows the same initial > >> ipa-server-install process, but that there is a secondary "join with my > >> peer" process. > >> > >> * In theory, if I set up two identical freeipa servers with the same > >> options (but different hostnames) I would like to be able to introduce > >> them to each other at a later date and join them (even if this means > >> that we pick one as the source of the data and the others data gets > >> overwritten) > > > > What is the point really ? > > > > You get this "symmetrical" install by doing a useless install of all > > fours and then practically redoing the install for 3 of the 4. Might as > > well just install 1 first and then do the other 3 in parallel, less CPU > > gets wasted. > This might actually be a good approach. I'll be trying to prototype > some things this week, and I'll try this out. > > > > >> Does this help explain the need? For an example of peering that works > >> this way and is symmetrical with configuration management, my > >> puppet-gluster module does this. > > > > I think this is a case where aesthetics clash with reality. > I think I agree. The exception is that if the hosts are not all the > same, this makes specifying the config management bits significantly > harder. If they're the same, you can use a common pattern for all > hosts. This gives you a sort of "high availability" at the config > management level, meaning that if the host you designated as #1 is > down, you'd still be able to continue. > > > Reality requires a serialization due to the need of having a common CA > > that releases certificates and a common KDC database that release > > keytabs for all services before all of them are installed. > > Thank you for your input. One of my goals is to satisfy your > requirements on the "security" side. I'm sure you wouldn't approve of > the status quo of storing the dm_password and admin_password in > puppet. Me neither :) No, but those need to be accessible to the user, I think you can create a meta-package that contains those password when you create the first master, encrypted in a gpg file with private keys only stored in the freeipa servers. Then you can move them around w/o puppet knowing what they contain, although puppet will have to transfer at least public keys around. Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Sat May 24 02:57:51 2014 From: purpleidea at gmail.com (James) Date: Fri, 23 May 2014 22:57:51 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <1400899829.7561.170.camel@willson.li.ssimo.org> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> <537F50D8.2080306@redhat.com> <1400879810.23683.106.camel@freed> <1400888950.7561.167.camel@willson.li.ssimo.org> <1400899829.7561.170.camel@willson.li.ssimo.org> Message-ID: <1400900271.23683.120.camel@freed> On Fri, 2014-05-23 at 22:50 -0400, Simo Sorce wrote: > No, but those need to be accessible to the user, I think you can > create > a meta-package that contains those password when you create the first > master, encrypted in a gpg file with private keys only stored in the > freeipa servers. I do something similar for the admin. https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw I'll blog (as docs) about the details shortly. > > Then you can move them around w/o puppet knowing what they contain, > although puppet will have to transfer at least public keys around. Are you okay with each individual ipa server having a different pub/private keypair, and a gpg encrypted file being passed around containing the cleartext dm_password ? The private key on each host wouldn't be able to have a password, _and_ ultimately someone with root could get the cleartext password, where as the current status quo probably hashes it. So I would see this as less secure. > > Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From simo at redhat.com Sat May 24 03:35:08 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 May 2014 23:35:08 -0400 Subject: [Freeipa-devel] Understanding FreeIPA replica internals In-Reply-To: <1400900271.23683.120.camel@freed> References: <537F2612.7050101@redhat.com> <537F4CEE.3040001@redhat.com> <537F50D8.2080306@redhat.com> <1400879810.23683.106.camel@freed> <1400888950.7561.167.camel@willson.li.ssimo.org> <1400899829.7561.170.camel@willson.li.ssimo.org> <1400900271.23683.120.camel@freed> Message-ID: <1400902508.7561.175.camel@willson.li.ssimo.org> On Fri, 2014-05-23 at 22:57 -0400, James wrote: > On Fri, 2014-05-23 at 22:50 -0400, Simo Sorce wrote: > > No, but those need to be accessible to the user, I think you can > > create > > a meta-package that contains those password when you create the first > > master, encrypted in a gpg file with private keys only stored in the > > freeipa servers. > I do something similar for the admin. > https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw > I'll blog (as docs) about the details shortly. > > > > > Then you can move them around w/o puppet knowing what they contain, > > although puppet will have to transfer at least public keys around. > Are you okay with each individual ipa server having a different > pub/private keypair, and a gpg encrypted file being passed around > containing the cleartext dm_password ? The private key on each host > wouldn't be able to have a password, _and_ ultimately someone with root > could get the cleartext password, where as the current status quo > probably hashes it. So I would see this as less secure. The problem is, you need to use those password for the install, so you have to have them somehow available on the systems themselves, especially if you autogenerate them. The admin will need to know to go on the systems, read and memorize/save elsewhere the passwords and delete the gpg files. We are bootstrapping the system here, so something needs to know those secrets. The CA private certificate is also on one of those systems, so if you decide puppet has access to them you have to come to terms with the fact puppet will have access to the keys of the kingdom. If you do not like that ... don't use puppet and manually install. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Sun May 25 19:29:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Sun, 25 May 2014 21:29:59 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <1400856659.7561.124.camel@willson.li.ssimo.org> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> Message-ID: <538244B7.8010200@redhat.com> On 05/23/2014 04:50 PM, Simo Sorce wrote: > On Fri, 2014-05-23 at 10:59 +0200, Martin Kosek wrote: >> On 05/22/2014 04:20 PM, Petr Viktorin wrote: >>> On 05/21/2014 12:14 PM, Simo Sorce wrote: >>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>> On 05/16/2014 04:33 PM, Petr Viktorin wrote: >>>>>> On 05/16/2014 01:54 PM, Martin Kosek wrote: >>>>>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>>>>>>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed >>>>>>>> previously >>>>>>>> [0]. >>>>>>>> >>>>>>>> Patch 0541 is some minor refactoring for the next part. >>>>>>>> >>>>>>>> Patch 0542 sets the read acces to addressbook attributes to anonymous when >>>>>>>> upgrading from pre-4.0. >>>>>>>> I first this by checking if the update is run from ipa-server-install or >>>>>>>> not, >>>>>>>> but then I realized the logic I want is simple: if the global anon read ACI >>>>>>>> exists, we want to preserve its spirit by setting addressbook attribute >>>>>>>> ACI to >>>>>>>> anonymous. >>>>>>>> >>>>>>>> >>>>>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et >>>>>>>> al. >>>>>>>> >>>>>>> >>>>>>> 540: >>>>>>> >>>>>>> Looks good! The only attributes I am concerned about are special IPA >>>>>>> attributes: >>>>>>> >>>>>>> - ipauniqueid >>>>>>> - ipasshpubkey >>>>>>> - ipauserauthtype >>>>>>> - userclass >>>>>>> >>>>>>> I personally do not think they should be included in POSIX attributes >>>>>>> permissions, they are far from POSIX definition... >>>>>>> >>>>>>> What about creating one more permission "System: Read User IPA Attributes" as >>>>>>> these are specific to FreeIPA use and allowing that permission for all >>>>>>> authenticated users? >>>>>> >>>>>> Sounds reasonable. I assume we want this one to be also set to anonymous when >>>>>> upgrading from old versions. >>>>>> Attaching updated patches. >>>>> >>>>> Ok, looks good. >>>>> >>>>> I am now just pondering whether "System: Read User POSIX Attributes" is the >>>>> right name for the permission as there are not just POSIX attributes, but also >>>>> attributes from organizationalPerson or inetOrgPerson objectclasses. >>>>> >>>>> Maybe we should name it "System: Read User Core Attributes" or "System: Read >>>>> User Basic Attributes"? Simo, any preference? >>>> >>>> We could use: "System: Read User Standard Attributes" >>> >>> I've used this one, then. >>> >>>> >>>> but the 'posix' version is also ok to me. >>> >>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>> Also, I just realized we forgot memberOf attribute - it needs to be available >>>> to authenticated users otherwise group membership will fall apart. >>> >>> Good catch. Added. >>> >> >> We are very close to push this one - I have just one last concern about >> userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 from user, >> now we added it to be read by default. This results in this warning during upgrade: >> >> Excluded attributes for System: Read User Addressbook Attributes: userpkcs12 >> >> Simo (or others), is this OK or do we want to keep hiding userpkcs12 by default? > > Is there any client that needs access to that information that we are > aware of ? > > Simo. I do not think so. Rob, do you know? Martin From mkosek at redhat.com Mon May 26 05:49:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 May 2014 07:49:59 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <1400856930.7561.129.camel@willson.li.ssimo.org> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> Message-ID: <5382D607.5070407@redhat.com> On 05/23/2014 04:55 PM, Simo Sorce wrote: > On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >> This, I believe, has already been covered, but I'm concerned with the >> (over)use of active/inactive in this discussion. >> >> I think use of "inactive" and "active" to describe users might be >> confusing since there is already an account enable/disable command. >> This >> on top of unlock, are there now 3 possible boolean states a user can >> be >> in? locked/unlocked, enabled/disabled, active/inactive, plus >> deleted/active and staged/active? >> > Agree, we should only have "ipa user-unstage " and not call > this operations with words like active/inactive. > > User's in the staging area are not inactive, they are *not* users yet in > the first place. > > Simo. > Ok. Let us consolidate the decisions, I think we are now running in circles. Let me start from Petr3's API proposal which was a functionally complete proposal and start from there: On 05/22/2014 10:47 AM, Petr Viktorin wrote: > ... > My proposal would be that the move commands use the verb for the target and an > option for the source, and add/mod use an option for the container: > > 1) adding a new user > (to active) ipa user-add tuser ... > (to stage) ipa user-add tuser --staged ... Ok. > (to deleted) ipa user-add tuser --deleted ... (*) Not needed. > 2) moving to main > (from stage) ipa user-activate tuser (**) > (from del) ipa user-activate tuser --deleted We need both, alternative is Simo's proposal: ipa user-unstage ipa user-undelete I personally like unstage and undelete commands, I would go with those. > 3) moving to deleted > (from active) ipa user-del tuser Ok. > (from stage) ipa user-del tuser --staged IMO staged deleted users should not be moved to deleted container, but simply permanently deleted. As Simo noted, staged user are not real users, just incomplete users. > 4) moving to stage > (from active) ipa user-stage tuser > (from del) ipa user-stage tuser --deleted None of the commands are needed for the basic workflow. > 5) modifying > (in active) ipa user-mod tuser ... Ok. > (in stage) ipa user-mod tuser --staged ... Simo did not like this command, I would personally add it. As long as we have "ipa user-add --staged", we should also have an option to delete and modify user in staged area. > (in del) ipa user-mod tuser --deleted ... Not needed. Is this acceptable for everyone? If yes, the next step would be for Thierry to update the design page with new proposals. Martin From jcholast at redhat.com Mon May 26 07:33:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 May 2014 09:33:47 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382D607.5070407@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> Message-ID: <5382EE5B.5050802@redhat.com> On 26.5.2014 07:49, Martin Kosek wrote: > On 05/23/2014 04:55 PM, Simo Sorce wrote: >> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>> This, I believe, has already been covered, but I'm concerned with the >>> (over)use of active/inactive in this discussion. >>> >>> I think use of "inactive" and "active" to describe users might be >>> confusing since there is already an account enable/disable command. >>> This >>> on top of unlock, are there now 3 possible boolean states a user can >>> be >>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>> deleted/active and staged/active? >>> >> Agree, we should only have "ipa user-unstage " and not call >> this operations with words like active/inactive. >> >> User's in the staging area are not inactive, they are *not* users yet in >> the first place. >> >> Simo. >> > > Ok. Let us consolidate the decisions, I think we are now running in > circles. Let me start from Petr3's API proposal which was a functionally > complete proposal and start from there: > > On 05/22/2014 10:47 AM, Petr Viktorin wrote: > > ... > > My proposal would be that the move commands use the verb for the > target and an > > option for the source, and add/mod use an option for the container: > > > > 1) adding a new user > > (to active) ipa user-add tuser ... > > (to stage) ipa user-add tuser --staged ... > > Ok. > > > (to deleted) ipa user-add tuser --deleted ... (*) > > Not needed. > > > 2) moving to main > > (from stage) ipa user-activate tuser (**) > > (from del) ipa user-activate tuser --deleted > > We need both, alternative is Simo's proposal: > > ipa user-unstage > ipa user-undelete > > I personally like unstage and undelete commands, I would go with those. > > > > 3) moving to deleted > > (from active) ipa user-del tuser > > Ok. > > > (from stage) ipa user-del tuser --staged > > IMO staged deleted users should not be moved to deleted container, but > simply permanently deleted. As Simo noted, staged user are not real > users, just incomplete users. > > > 4) moving to stage > > (from active) ipa user-stage tuser > > (from del) ipa user-stage tuser --deleted > > None of the commands are needed for the basic workflow. > > > 5) modifying > > (in active) ipa user-mod tuser ... > > Ok. > > > (in stage) ipa user-mod tuser --staged ... > > Simo did not like this command, I would personally add it. As long as we > have "ipa user-add --staged", we should also have an option to delete > and modify user in staged area. +1 > > > (in del) ipa user-mod tuser --deleted ... > > Not needed. > > Is this acceptable for everyone? If yes, the next step would be for > Thierry to update the design page with new proposals. > > Martin Are users in different containers using the same uid allowed? If not, do we need the --staged/--deleted flags on anything but user-add/user-find? -- Jan Cholasta From mkosek at redhat.com Mon May 26 07:41:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 May 2014 09:41:32 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400879990.2513.23.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> <1400879990.2513.23.camel@ipa.example.com> Message-ID: <5382F02C.9000701@redhat.com> On 05/23/2014 11:19 PM, Nathaniel McCallum wrote: > On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: >> Occasionally OTP tokens get out of sync with the server. When this >> happens, the user or an admin need to synchronize the token. To this >> end, we landed server-side synchronization support, which is a simple >> bind with a custom control. This all works with my sample test script. >> >> Client support is proving a bit more difficult. In the ideal world, the >> client would contact LDAP directly and perform the operation. This would >> make a man in the middle attack difficult and we can ensure encryption >> over the entire operation. >> >> However, browsers, without server-side assistance, cannot perform this >> operation from javascript. This means that, in this case, the first >> factor and two second factors must be transmitted to the FreeIPA server >> and then proxied to 389. Is this an acceptable compromise? >> >> This command also needs to be accessible *without* an existing user >> login since, if a user's token is out of sync, the user can't login. Is >> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >> ping" seem to require kinit, so I don't see any obvious examples. > > Thanks everyone for your feedback. This particular feature is proving > difficult to implement, even with our agreed upon design. To reiterate > this design: there will be an HTTP method by which to synchronize > tokens. > > There are two assumptions in the code which are making this difficult: > 1. All cli commands are Command subclasses. > 2. All Command subclasses create authenticated server methods. > > There are thus two ways to tackle this problem. > > First, I can create a standard POST method in rpcserver.py. This is not > very modular. But the biggest problem is that there is no way to create > the cli-side command to call it (assumption #1). > > Second, I can create a Command subclass, similar to the passwd plugin. > This will create both the client- and server-side components. However, > there is no way to disable the server-side authentication. > > I think that solving the second of these problems is the most reusable. > Just as an example, the ping command currently requires authentication > but does not need to do so. The passwd Command too shouldn't need to > authenticate before executing the command because the command > authenticates itself. > > I think it very likely that we are going to have need for other Command > subclasses in the future which do not require authentication. > > However, implementing this approach is rather difficult as it will > require a refactoring of rpcserver.py. The code in rpcserver.py contains > many layering violations and the class structure is rather unclear > (look, for instance, at the different orders in which xmlrpc and jsonrpc > classes inherit from their parent classes). > > The current problem forcing this refactoring is that authentication > appears to happen across several different layers, but always before the > command to be executed is unmarshalled. We need to invert this order: > the command needs to be unmarshalled first in order to determine whether > or not authentication is necessary. I don't think that switching this > order is practical without constraining authentication to a single layer > (or two: session and krb5) late in the request process. > > Git tells me that lots of people have touched this code, so I'm hoping > for good feedback! ;) > > Alternatively, we could create a way to inject cli commands without > having Command subclasses. Isolating these concerns is itself probably a > good design choice. Ideally we'd have a structure where the Command > class itself inherits from a CLICommand class and a ServerMethod class. > But this too will be a massive refactoring, perhaps even bigger than the > rpcserver.py refactoring. > > So, which assumption should we break: #1 or #2? And who wants to help me > do it? Also, I am all ears for easier solutions for this feature. > > Nathaniel Hi Nathaniel, These are all good ideas, it is true that we are sometimes hitting framework limitations which will force to rewrite some parts, Petr Viktorin already have couple of wished refactorings in mind. What you are suggesting sounds as a pretty massive refactorings touching basic framework parts that have not been touched for long years. Refactorings of this scale would take months of planning and execution. Question is, does this use case warrants such big change? AFAIK, we need to solve following use cases: 1) Admin wants to manipulate user's token via Web UI/CLI - easy to do, admin is authenticated and can run any commands 2) User wants to re-synchronize token via Web UI: easy to do, create POST callback and a Web UI page. IMO, Web UI will be the most used synchronization interface for users, it is usually not very frequent operation so Web UI can guide user through the procedure (as compared to plain CLI). 3) User wants to re-synchronize a token via CLI: given the framework is not ready for this kind of unauthenticated operation and refactorings would take massive amount of time, can we simply avoid using the framework and provide a standalone CLI utility "ipa-token-resync" and deploy it in freeipa-client package? The utility can then call the LDAP operation directly and wrap it in a nice CLI interface for the user. Martin From jcholast at redhat.com Mon May 26 07:56:40 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 May 2014 09:56:40 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1400879990.2513.23.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> <1400879990.2513.23.camel@ipa.example.com> Message-ID: <5382F3B8.7030802@redhat.com> On 23.5.2014 23:19, Nathaniel McCallum wrote: > On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: >> Occasionally OTP tokens get out of sync with the server. When this >> happens, the user or an admin need to synchronize the token. To this >> end, we landed server-side synchronization support, which is a simple >> bind with a custom control. This all works with my sample test script. >> >> Client support is proving a bit more difficult. In the ideal world, the >> client would contact LDAP directly and perform the operation. This would >> make a man in the middle attack difficult and we can ensure encryption >> over the entire operation. >> >> However, browsers, without server-side assistance, cannot perform this >> operation from javascript. This means that, in this case, the first >> factor and two second factors must be transmitted to the FreeIPA server >> and then proxied to 389. Is this an acceptable compromise? >> >> This command also needs to be accessible *without* an existing user >> login since, if a user's token is out of sync, the user can't login. Is >> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >> ping" seem to require kinit, so I don't see any obvious examples. > > Thanks everyone for your feedback. This particular feature is proving > difficult to implement, even with our agreed upon design. To reiterate > this design: there will be an HTTP method by which to synchronize > tokens. > > There are two assumptions in the code which are making this difficult: > 1. All cli commands are Command subclasses. > 2. All Command subclasses create authenticated server methods. > > There are thus two ways to tackle this problem. > > First, I can create a standard POST method in rpcserver.py. This is not > very modular. But the biggest problem is that there is no way to create > the cli-side command to call it (assumption #1). Well, you could derive the command from ipalib.frontend.Local and manually call the POST method from it. > > Second, I can create a Command subclass, similar to the passwd plugin. > This will create both the client- and server-side components. However, > there is no way to disable the server-side authentication. > > I think that solving the second of these problems is the most reusable. > Just as an example, the ping command currently requires authentication > but does not need to do so. The passwd Command too shouldn't need to > authenticate before executing the command because the command > authenticates itself. > > I think it very likely that we are going to have need for other Command > subclasses in the future which do not require authentication. > > However, implementing this approach is rather difficult as it will > require a refactoring of rpcserver.py. The code in rpcserver.py contains > many layering violations and the class structure is rather unclear > (look, for instance, at the different orders in which xmlrpc and jsonrpc > classes inherit from their parent classes). > > The current problem forcing this refactoring is that authentication > appears to happen across several different layers, but always before the > command to be executed is unmarshalled. We need to invert this order: > the command needs to be unmarshalled first in order to determine whether > or not authentication is necessary. I don't think that switching this > order is practical without constraining authentication to a single layer > (or two: session and krb5) late in the request process. > > Git tells me that lots of people have touched this code, so I'm hoping > for good feedback! ;) > > Alternatively, we could create a way to inject cli commands without > having Command subclasses. Isolating these concerns is itself probably a > good design choice. Ideally we'd have a structure where the Command > class itself inherits from a CLICommand class and a ServerMethod class. > But this too will be a massive refactoring, perhaps even bigger than the > rpcserver.py refactoring. > > So, which assumption should we break: #1 or #2? And who wants to help me > do it? Also, I am all ears for easier solutions for this feature. I would go for the refactoring, the rpcserver code does indeed need some love. > > Nathaniel -- Jan Cholasta From tbordaz at redhat.com Mon May 26 08:12:38 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 26 May 2014 10:12:38 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382D607.5070407@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> Message-ID: <5382F776.6090606@redhat.com> On 05/26/2014 07:49 AM, Martin Kosek wrote: > On 05/23/2014 04:55 PM, Simo Sorce wrote: >> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>> This, I believe, has already been covered, but I'm concerned with the >>> (over)use of active/inactive in this discussion. >>> >>> I think use of "inactive" and "active" to describe users might be >>> confusing since there is already an account enable/disable command. >>> This >>> on top of unlock, are there now 3 possible boolean states a user can >>> be >>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>> deleted/active and staged/active? >>> >> Agree, we should only have "ipa user-unstage " and not call >> this operations with words like active/inactive. >> >> User's in the staging area are not inactive, they are *not* users yet in >> the first place. >> >> Simo. >> > > Ok. Let us consolidate the decisions, I think we are now running in > circles. Let me start from Petr3's API proposal which was a > functionally complete proposal and start from there: > > On 05/22/2014 10:47 AM, Petr Viktorin wrote: > > ... > > My proposal would be that the move commands use the verb for the > target and an > > option for the source, and add/mod use an option for the container: > > > > 1) adding a new user > > (to active) ipa user-add tuser ... > > (to stage) ipa user-add tuser --staged ... > > Ok. > > > (to deleted) ipa user-add tuser --deleted ... (*) > > Not needed. > > > 2) moving to main > > (from stage) ipa user-activate tuser (**) > > (from del) ipa user-activate tuser --deleted > > We need both, alternative is Simo's proposal: > > ipa user-unstage > ipa user-undelete > > I personally like unstage and undelete commands, I would go with those. > > > > 3) moving to deleted > > (from active) ipa user-del tuser > > Ok. > > > (from stage) ipa user-del tuser --staged > > IMO staged deleted users should not be moved to deleted container, but > simply permanently deleted. As Simo noted, staged user are not real > users, just incomplete users. +1 > > > 4) moving to stage > > (from active) ipa user-stage tuser > > (from del) ipa user-stage tuser --deleted > > None of the commands are needed for the basic workflow. > > > 5) modifying > > (in active) ipa user-mod tuser ... > > Ok. > > > (in stage) ipa user-mod tuser --staged ... > > Simo did not like this command, I would personally add it. As long as > we have "ipa user-add --staged", we should also have an option to > delete and modify user in staged area. > > > (in del) ipa user-mod tuser --deleted ... > > Not needed. When a user that left the organisation is coming back we will move his entry 'delete' to 'active'. Now if the administrator wants the user to come back but with some changes, he may need this option. For example if by the time he left, the default homeDirectory changed the administrator may want to update its value. > > Is this acceptable for everyone? If yes, the next step would be for > Thierry to update the design page with new proposals. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon May 26 08:18:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 May 2014 10:18:11 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382EE5B.5050802@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5382EE5B.5050802@redhat.com> Message-ID: <5382F8C3.6040009@redhat.com> On 05/26/2014 09:33 AM, Jan Cholasta wrote: > On 26.5.2014 07:49, Martin Kosek wrote: ... >> > 5) modifying >> > (in active) ipa user-mod tuser ... >> >> Ok. >> >> > (in stage) ipa user-mod tuser --staged ... >> >> Simo did not like this command, I would personally add it. As long as we >> have "ipa user-add --staged", we should also have an option to delete >> and modify user in staged area. > > +1 > >> >> > (in del) ipa user-mod tuser --deleted ... >> >> Not needed. >> >> Is this acceptable for everyone? If yes, the next step would be for >> Thierry to update the design page with new proposals. >> >> Martin > > Are users in different containers using the same uid allowed? Say you had a John Doe (uid jdoe) working in a company couple years ago. jdoe left and is now in deleted accounts tree. Jane Doe joins the company now and question is - do we want to allow Jane taking the same uid as John had? I am thinking we should not allow that. Maybe we should allow override with --force or having a global option. Another related topic is - do we want to enforce staged user to always have UID RDN? Isn't that limiting? When writing http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Create_a_User_-_by_provisioning_system I proposed that we should also be able to unstage a minimal record like this: dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson cn: Test User sn: User nsAccountLock: True > If not, do we need the --staged/--deleted flags on anything but > user-add/user-find? I see your point, but I think we should make admins to be very explicit when manipulating users any area other than the active users area. As Simo noted, these are not real users, just incomplete user records. Martin From mkosek at redhat.com Mon May 26 08:33:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 May 2014 10:33:47 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> Message-ID: <5382FC6B.8040402@redhat.com> On 05/21/2014 06:23 PM, Martin Basti wrote: > Updated patches attached > > Patch 33 removed. > > Patches should be applied in order: 0029-0032, 0034-0040, 0047, > 0041-0042, 0045-0046 FYI, I just did an upgrade from 3.3.5 to 4.0 with these patches applied and this is what I got: # rpm -Uvh --force ~/freeipa-master/dist/rpms/freeipa-*Preparing... ################################# [100%] Updating / installing... 1:freeipa-python-3.3.90GITd4dd8c4-0################################# [ 7%] 2:freeipa-client-3.3.90GITd4dd8c4-0################################# [ 13%] Could not load host key: /etc/ssh/ssh_host_dsa_key 3:freeipa-admintools-3.3.90GITd4dd8################################# [ 20%] 4:freeipa-server-3.3.90GITd4dd8c4-0################################# [ 27%] 5:freeipa-server-trust-ad-3.3.90GIT################################# [ 33%] 6:freeipa-server-foreman-smartproxy################################# [ 40%] 7:freeipa-tests-3.3.90GITd4dd8c4-0.################################# [ 47%] 8:freeipa-debuginfo-3.3.90GITd4dd8c################################# [ 53%] Cleaning up / removing... 9:freeipa-tests-3.3.5-1.fc20 ################################# [ 60%] 10:freeipa-debuginfo-3.3.5-1.fc20 ################################# [ 67%] 11:freeipa-server-trust-ad-3.3.5-1.f################################# [ 73%] 12:freeipa-server-3.3.5-1.fc20 ################################# [ 80%] 13:freeipa-admintools-3.3.5-1.fc20 ################################# [ 87%] 14:freeipa-client-3.3.5-1.fc20 ################################# [ 93%] 15:freeipa-python-3.3.5-1.fc20 ################################# [100%] Upgrade failed with list.remove(x): x not in list IPA upgrade failed. Unexpected error AttributeError: 'DNSName' object has no attribute 'endswith' ipaupgrade.log: 2014-05-26T08:32:28Z DEBUG Created connection context.ldap2 2014-05-26T08:32:28Z DEBUG raw: dns_is_enabled() 2014-05-26T08:32:28Z DEBUG dns_is_enabled() 2014-05-26T08:32:28Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-MKOSEK-FEDORA20-TEST.socket conn= 2014-05-26T08:32:28Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2014-05-26T08:32:28Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2014-05-26T08:32:28Z DEBUG raw: dnsrecord_find(u'mkosek-fedora20.test', u'ipa-ca') 2014-05-26T08:32:28Z DEBUG dnsrecord_find(, u'ipa-ca', structured=False, all=False, raw=False, pkey_only=False) 2014-05-26T08:32:28Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 1113, in main add_ca_dns_records() File "/usr/sbin/ipa-upgradeconfig", line 809, in add_ca_dns_records bind.convert_ipa_ca_cnames(api.env.domain) File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 853, in convert_ipa_ca_cnames cnames = get_rr(domain_name, IPA_CA_RECORD, "CNAME") File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 369, in get_rr ret = api.Command.dnsrecord_find(unicode(zone), unicode(name)) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run result = self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1869, in execute base_dn = self.api.Object[self.obj.parent_object].get_dn(*args[:-1]) File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1714, in get_dn if zone.endswith(u'.'): 2014-05-26T08:32:28Z DEBUG The ipa-upgradeconfig command failed, exception: AttributeError: 'DNSName' object has no attribute 'endswith' Martin From tbordaz at redhat.com Mon May 26 08:52:13 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 26 May 2014 10:52:13 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382F8C3.6040009@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5382EE5B.5050802@redhat.com> <5382F8C3.6040009@redhat.com> Message-ID: <538300BD.9040205@redhat.com> On 05/26/2014 10:18 AM, Martin Kosek wrote: > On 05/26/2014 09:33 AM, Jan Cholasta wrote: >> On 26.5.2014 07:49, Martin Kosek wrote: > ... >>> > 5) modifying >>> > (in active) ipa user-mod tuser ... >>> >>> Ok. >>> >>> > (in stage) ipa user-mod tuser --staged ... >>> >>> Simo did not like this command, I would personally add it. As long as we >>> have "ipa user-add --staged", we should also have an option to delete >>> and modify user in staged area. >> +1 >> >>> > (in del) ipa user-mod tuser --deleted ... >>> >>> Not needed. >>> >>> Is this acceptable for everyone? If yes, the next step would be for >>> Thierry to update the design page with new proposals. >>> >>> Martin >> Are users in different containers using the same uid allowed? > Say you had a John Doe (uid jdoe) working in a company couple years ago. jdoe > left and is now in deleted accounts tree. Jane Doe joins the company now and > question is - do we want to allow Jane taking the same uid as John had? I am > thinking we should not allow that. Maybe we should allow override with --force > or having a global option. I agree, 'John Doe' should keep its uid and 'Jane Doe' should pickup a different one. So that means attribute uniqueness scope should covers the differents containers (stage, delete, active) and likely all the DIT. But then for generated attributes (like 'ipaUniqueid') it is a problem because in 'stage' most/all entries will have 'ipaUniqueId: generate'. So for such attributes, 'stage' container should be excluded from the scope. If 'ipa user-mod --stage' is allowed to modify ipaUniqueiD, uniqueness will not be enforced. > > Another related topic is - do we want to enforce staged user to always have UID > RDN? Isn't that limiting? When writing > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Create_a_User_-_by_provisioning_system > > I proposed that we should also be able to unstage a minimal record like this: > > dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com > objectClass: top > objectClass: organizationalperson > cn: Test User > sn: User > nsAccountLock: True > >> If not, do we need the --staged/--deleted flags on anything but >> user-add/user-find? > I see your point, but I think we should make admins to be very explicit when > manipulating users any area other than the active users area. As Simo noted, > these are not real users, just incomplete user records. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Mon May 26 08:58:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 26 May 2014 11:58:34 +0300 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382F8C3.6040009@redhat.com> References: <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5382EE5B.5050802@redhat.com> <5382F8C3.6040009@redhat.com> Message-ID: <20140526085834.GU23849@redhat.com> On Mon, 26 May 2014, Martin Kosek wrote: >On 05/26/2014 09:33 AM, Jan Cholasta wrote: >> On 26.5.2014 07:49, Martin Kosek wrote: >... >>> > 5) modifying >>> > (in active) ipa user-mod tuser ... >>> >>> Ok. >>> >>> > (in stage) ipa user-mod tuser --staged ... >>> >>> Simo did not like this command, I would personally add it. As long as we >>> have "ipa user-add --staged", we should also have an option to delete >>> and modify user in staged area. >> >> +1 >> >>> >>> > (in del) ipa user-mod tuser --deleted ... >>> >>> Not needed. >>> >>> Is this acceptable for everyone? If yes, the next step would be for >>> Thierry to update the design page with new proposals. >>> >>> Martin >> >> Are users in different containers using the same uid allowed? > >Say you had a John Doe (uid jdoe) working in a company couple years ago. jdoe >left and is now in deleted accounts tree. Jane Doe joins the company now and >question is - do we want to allow Jane taking the same uid as John had? I am >thinking we should not allow that. Maybe we should allow override with --force >or having a global option. This is pretty much a company policy thing. Not everyone will even want to have this workflow implemented and even if they would, a policy to keep the same uid (as opposed to uidNumber) is a separate one. Thus, I'd rather have it optional with --force or get uid transformed to uid=deleted+jdoe,cn=users... and given a way to handle conflicts when getting deleted uids resurrected. -- / Alexander Bokovoy From pviktori at redhat.com Mon May 26 10:04:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 12:04:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <538244B7.8010200@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> Message-ID: <538311AE.4090502@redhat.com> On 05/25/2014 09:29 PM, Martin Kosek wrote: > On 05/23/2014 04:50 PM, Simo Sorce wrote: >> On Fri, 2014-05-23 at 10:59 +0200, Martin Kosek wrote: >>> On 05/22/2014 04:20 PM, Petr Viktorin wrote: >>>> On 05/21/2014 12:14 PM, Simo Sorce wrote: >>>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>>> On 05/16/2014 04:33 PM, Petr Viktorin wrote: >>>>>>> On 05/16/2014 01:54 PM, Martin Kosek wrote: >>>>>>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>>>>>>>> Patch 0540 adds a bunch of managed read ACIs for user, as >>>>>>>>> discussed >>>>>>>>> previously >>>>>>>>> [0]. >>>>>>>>> >>>>>>>>> Patch 0541 is some minor refactoring for the next part. >>>>>>>>> >>>>>>>>> Patch 0542 sets the read acces to addressbook attributes to >>>>>>>>> anonymous when >>>>>>>>> upgrading from pre-4.0. >>>>>>>>> I first this by checking if the update is run from >>>>>>>>> ipa-server-install or >>>>>>>>> not, >>>>>>>>> but then I realized the logic I want is simple: if the global >>>>>>>>> anon read ACI >>>>>>>>> exists, we want to preserve its spirit by setting addressbook >>>>>>>>> attribute >>>>>>>>> ACI to >>>>>>>>> anonymous. >>>>>>>>> >>>>>>>>> >>>>>>>>> [0] >>>>>>>>> http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html >>>>>>>>> et >>>>>>>>> al. >>>>>>>>> >>>>>>>> >>>>>>>> 540: >>>>>>>> >>>>>>>> Looks good! The only attributes I am concerned about are special >>>>>>>> IPA >>>>>>>> attributes: >>>>>>>> >>>>>>>> - ipauniqueid >>>>>>>> - ipasshpubkey >>>>>>>> - ipauserauthtype >>>>>>>> - userclass >>>>>>>> >>>>>>>> I personally do not think they should be included in POSIX >>>>>>>> attributes >>>>>>>> permissions, they are far from POSIX definition... >>>>>>>> >>>>>>>> What about creating one more permission "System: Read User IPA >>>>>>>> Attributes" as >>>>>>>> these are specific to FreeIPA use and allowing that permission >>>>>>>> for all >>>>>>>> authenticated users? >>>>>>> >>>>>>> Sounds reasonable. I assume we want this one to be also set to >>>>>>> anonymous when >>>>>>> upgrading from old versions. >>>>>>> Attaching updated patches. >>>>>> >>>>>> Ok, looks good. >>>>>> >>>>>> I am now just pondering whether "System: Read User POSIX >>>>>> Attributes" is the >>>>>> right name for the permission as there are not just POSIX >>>>>> attributes, but also >>>>>> attributes from organizationalPerson or inetOrgPerson objectclasses. >>>>>> >>>>>> Maybe we should name it "System: Read User Core Attributes" or >>>>>> "System: Read >>>>>> User Basic Attributes"? Simo, any preference? >>>>> >>>>> We could use: "System: Read User Standard Attributes" >>>> >>>> I've used this one, then. >>>> >>>>> >>>>> but the 'posix' version is also ok to me. >>>> >>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>> Also, I just realized we forgot memberOf attribute - it needs to be >>>>> available >>>>> to authenticated users otherwise group membership will fall apart. >>>> >>>> Good catch. Added. >>>> >>> >>> We are very close to push this one - I have just one last concern about >>> userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 >>> from user, >>> now we added it to be read by default. This results in this warning >>> during upgrade: >>> >>> Excluded attributes for System: Read User Addressbook Attributes: >>> userpkcs12 >>> >>> Simo (or others), is this OK or do we want to keep hiding userpkcs12 >>> by default? >> >> Is there any client that needs access to that information that we are >> aware of ? >> >> Simo. > > I do not think so. Rob, do you know? This was my mistake. We never allowed non-admins to see that attribute by default, so we shouldn't start now. I'm glad the updater caught it, sorry that I didn't. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0540.4-Add-managed-read-permissions-to-user.patch Type: text/x-patch Size: 4279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0541.4-update_managed_permissions-Pass-around-anonymous-ACI.patch Type: text/x-patch Size: 4962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0542.4-Set-user-addressbook-IPA-attribute-read-ACI-to-anony.patch Type: text/x-patch Size: 4174 bytes Desc: not available URL: From mkosek at redhat.com Mon May 26 10:09:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 May 2014 12:09:09 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <538311AE.4090502@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> <538311AE.4090502@redhat.com> Message-ID: <538312C5.8000807@redhat.com> On 05/26/2014 12:04 PM, Petr Viktorin wrote: > On 05/25/2014 09:29 PM, Martin Kosek wrote: >> On 05/23/2014 04:50 PM, Simo Sorce wrote: >>> On Fri, 2014-05-23 at 10:59 +0200, Martin Kosek wrote: >>>> On 05/22/2014 04:20 PM, Petr Viktorin wrote: >>>>> On 05/21/2014 12:14 PM, Simo Sorce wrote: >>>>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>>>> On 05/16/2014 04:33 PM, Petr Viktorin wrote: >>>>>>>> On 05/16/2014 01:54 PM, Martin Kosek wrote: >>>>>>>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>>>>>>>>> Patch 0540 adds a bunch of managed read ACIs for user, as >>>>>>>>>> discussed >>>>>>>>>> previously >>>>>>>>>> [0]. >>>>>>>>>> >>>>>>>>>> Patch 0541 is some minor refactoring for the next part. >>>>>>>>>> >>>>>>>>>> Patch 0542 sets the read acces to addressbook attributes to >>>>>>>>>> anonymous when >>>>>>>>>> upgrading from pre-4.0. >>>>>>>>>> I first this by checking if the update is run from >>>>>>>>>> ipa-server-install or >>>>>>>>>> not, >>>>>>>>>> but then I realized the logic I want is simple: if the global >>>>>>>>>> anon read ACI >>>>>>>>>> exists, we want to preserve its spirit by setting addressbook >>>>>>>>>> attribute >>>>>>>>>> ACI to >>>>>>>>>> anonymous. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [0] >>>>>>>>>> http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html >>>>>>>>>> et >>>>>>>>>> al. >>>>>>>>>> >>>>>>>>> >>>>>>>>> 540: >>>>>>>>> >>>>>>>>> Looks good! The only attributes I am concerned about are special >>>>>>>>> IPA >>>>>>>>> attributes: >>>>>>>>> >>>>>>>>> - ipauniqueid >>>>>>>>> - ipasshpubkey >>>>>>>>> - ipauserauthtype >>>>>>>>> - userclass >>>>>>>>> >>>>>>>>> I personally do not think they should be included in POSIX >>>>>>>>> attributes >>>>>>>>> permissions, they are far from POSIX definition... >>>>>>>>> >>>>>>>>> What about creating one more permission "System: Read User IPA >>>>>>>>> Attributes" as >>>>>>>>> these are specific to FreeIPA use and allowing that permission >>>>>>>>> for all >>>>>>>>> authenticated users? >>>>>>>> >>>>>>>> Sounds reasonable. I assume we want this one to be also set to >>>>>>>> anonymous when >>>>>>>> upgrading from old versions. >>>>>>>> Attaching updated patches. >>>>>>> >>>>>>> Ok, looks good. >>>>>>> >>>>>>> I am now just pondering whether "System: Read User POSIX >>>>>>> Attributes" is the >>>>>>> right name for the permission as there are not just POSIX >>>>>>> attributes, but also >>>>>>> attributes from organizationalPerson or inetOrgPerson objectclasses. >>>>>>> >>>>>>> Maybe we should name it "System: Read User Core Attributes" or >>>>>>> "System: Read >>>>>>> User Basic Attributes"? Simo, any preference? >>>>>> >>>>>> We could use: "System: Read User Standard Attributes" >>>>> >>>>> I've used this one, then. >>>>> >>>>>> >>>>>> but the 'posix' version is also ok to me. >>>>> >>>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>>> Also, I just realized we forgot memberOf attribute - it needs to be >>>>>> available >>>>>> to authenticated users otherwise group membership will fall apart. >>>>> >>>>> Good catch. Added. >>>>> >>>> >>>> We are very close to push this one - I have just one last concern about >>>> userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 >>>> from user, >>>> now we added it to be read by default. This results in this warning >>>> during upgrade: >>>> >>>> Excluded attributes for System: Read User Addressbook Attributes: >>>> userpkcs12 >>>> >>>> Simo (or others), is this OK or do we want to keep hiding userpkcs12 >>>> by default? >>> >>> Is there any client that needs access to that information that we are >>> aware of ? >>> >>> Simo. >> >> I do not think so. Rob, do you know? > > This was my mistake. We never allowed non-admins to see that attribute by > default, so we shouldn't start now. ack, we probably had a good reason and it is much safer to keep this decision. > I'm glad the updater caught it, sorry that I didn't. Actually, that means that you made the security checks in the updater right :-) I diffed the change in the patch and it removed the last obstacle I saw with this patch set. Thus, ACK for all 3. Martin From pviktori at redhat.com Mon May 26 10:13:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 12:13:22 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <538312C5.8000807@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> <538311AE.4090502@redhat.com> <538312C5.8000807@redhat.com> Message-ID: <538313C2.7020007@redhat.com> On 05/26/2014 12:09 PM, Martin Kosek wrote: > On 05/26/2014 12:04 PM, Petr Viktorin wrote: >> On 05/25/2014 09:29 PM, Martin Kosek wrote: >>> On 05/23/2014 04:50 PM, Simo Sorce wrote: >>>> On Fri, 2014-05-23 at 10:59 +0200, Martin Kosek wrote: >>>>> On 05/22/2014 04:20 PM, Petr Viktorin wrote: >>>>>> On 05/21/2014 12:14 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>>>>> On 05/16/2014 04:33 PM, Petr Viktorin wrote: >>>>>>>>> On 05/16/2014 01:54 PM, Martin Kosek wrote: >>>>>>>>>> On 04/29/2014 11:00 PM, Petr Viktorin wrote: >>>>>>>>>>> Patch 0540 adds a bunch of managed read ACIs for user, as >>>>>>>>>>> discussed >>>>>>>>>>> previously >>>>>>>>>>> [0]. >>>>>>>>>>> >>>>>>>>>>> Patch 0541 is some minor refactoring for the next part. >>>>>>>>>>> >>>>>>>>>>> Patch 0542 sets the read acces to addressbook attributes to >>>>>>>>>>> anonymous when >>>>>>>>>>> upgrading from pre-4.0. >>>>>>>>>>> I first this by checking if the update is run from >>>>>>>>>>> ipa-server-install or >>>>>>>>>>> not, >>>>>>>>>>> but then I realized the logic I want is simple: if the global >>>>>>>>>>> anon read ACI >>>>>>>>>>> exists, we want to preserve its spirit by setting addressbook >>>>>>>>>>> attribute >>>>>>>>>>> ACI to >>>>>>>>>>> anonymous. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [0] >>>>>>>>>>> http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html >>>>>>>>>>> et >>>>>>>>>>> al. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 540: >>>>>>>>>> >>>>>>>>>> Looks good! The only attributes I am concerned about are special >>>>>>>>>> IPA >>>>>>>>>> attributes: >>>>>>>>>> >>>>>>>>>> - ipauniqueid >>>>>>>>>> - ipasshpubkey >>>>>>>>>> - ipauserauthtype >>>>>>>>>> - userclass >>>>>>>>>> >>>>>>>>>> I personally do not think they should be included in POSIX >>>>>>>>>> attributes >>>>>>>>>> permissions, they are far from POSIX definition... >>>>>>>>>> >>>>>>>>>> What about creating one more permission "System: Read User IPA >>>>>>>>>> Attributes" as >>>>>>>>>> these are specific to FreeIPA use and allowing that permission >>>>>>>>>> for all >>>>>>>>>> authenticated users? >>>>>>>>> >>>>>>>>> Sounds reasonable. I assume we want this one to be also set to >>>>>>>>> anonymous when >>>>>>>>> upgrading from old versions. >>>>>>>>> Attaching updated patches. >>>>>>>> >>>>>>>> Ok, looks good. >>>>>>>> >>>>>>>> I am now just pondering whether "System: Read User POSIX >>>>>>>> Attributes" is the >>>>>>>> right name for the permission as there are not just POSIX >>>>>>>> attributes, but also >>>>>>>> attributes from organizationalPerson or inetOrgPerson objectclasses. >>>>>>>> >>>>>>>> Maybe we should name it "System: Read User Core Attributes" or >>>>>>>> "System: Read >>>>>>>> User Basic Attributes"? Simo, any preference? >>>>>>> >>>>>>> We could use: "System: Read User Standard Attributes" >>>>>> >>>>>> I've used this one, then. >>>>>> >>>>>>> >>>>>>> but the 'posix' version is also ok to me. >>>>>> >>>>>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote: >>>>>>> Also, I just realized we forgot memberOf attribute - it needs to be >>>>>>> available >>>>>>> to authenticated users otherwise group membership will fall apart. >>>>>> >>>>>> Good catch. Added. >>>>>> >>>>> >>>>> We are very close to push this one - I have just one last concern about >>>>> userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 >>>>> from user, >>>>> now we added it to be read by default. This results in this warning >>>>> during upgrade: >>>>> >>>>> Excluded attributes for System: Read User Addressbook Attributes: >>>>> userpkcs12 >>>>> >>>>> Simo (or others), is this OK or do we want to keep hiding userpkcs12 >>>>> by default? >>>> >>>> Is there any client that needs access to that information that we are >>>> aware of ? >>>> >>>> Simo. >>> >>> I do not think so. Rob, do you know? >> >> This was my mistake. We never allowed non-admins to see that attribute by >> default, so we shouldn't start now. > > ack, we probably had a good reason and it is much safer to keep this decision. > >> I'm glad the updater caught it, sorry that I didn't. > > Actually, that means that you made the security checks in the updater right :-) > > I diffed the change in the patch and it removed the last obstacle I saw with > this patch set. Thus, ACK for all 3. Thanks for the thorough review! Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 -- Petr? From pviktori at redhat.com Mon May 26 10:15:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 12:15:56 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI In-Reply-To: <537F3E6D.5090004@redhat.com> References: <53601381.9050207@redhat.com> <5375FDE4.3070400@redhat.com> <537A06D9.4010000@redhat.com> <537C42CE.3030307@redhat.com> <537E03BD.8070505@redhat.com> <537F3E6D.5090004@redhat.com> Message-ID: <5383145C.1090805@redhat.com> On 05/23/2014 02:26 PM, Martin Kosek wrote: > On 05/22/2014 04:03 PM, Petr Viktorin wrote: >> On 05/21/2014 08:08 AM, Martin Kosek wrote: >>> On 05/19/2014 03:27 PM, Petr Viktorin wrote: >>>> 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. >>> >>> I tested upgrade from 3.3.5 to 4.0 and in SUFFIX I still had some of the ACIs >>> left: >>> >>> (targetattr = "*")(target = >>> "ldap:///cn=*,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test")(version 3.0; >>> acl "No anonymous access to roles"; deny (read,search,compare) userdn != >>> "ldap:///all";) >>> >>> (targetattr = "*")(target = >>> "ldap:///cn=*,ou=SUDOers,dc=mkosek-fedora20,dc=test")(version 3.0; acl "No >>> anonymous access to sudo"; deny (read,search,compare) userdn != "ldap:///all";) >>> >>> The problem is that you used your testing suffix instead of suffix variable. >> >> Shame on me. I've updated & rebased the patch. >> >> I've also made a git hook yell at me when I commit something containing "BRQ", >> hopefully this won't happen again. > > Would it make sense to publish your FreeIPA git hooks somewhere on > http://www.freeipa.org/page/Contribute/Code or your github and link it? I think > it already contains couple gems that may help other people prevent basic errors > like this one. Sure, I'll document it a bit and publish. > Otherwise, the patch worked fine - ACK! > > I would like it to be pushed as soon as user ACI patch is pushed so that we > have some time to find issues. Thanks! Pushed to master: 193ced0bd7a9a26e7b25f08b023ee21302acaac7 -- Petr? From pviktori at redhat.com Mon May 26 10:26:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 12:26:40 +0200 Subject: [Freeipa-devel] [HEADS UP] Read ACI rework is now in master Message-ID: <538316E0.60405@redhat.com> All FreeIPA developers, hang on to your hats (be they red or otherwise)! In master, the global ACI granting read/search/compare rights to anyyone has been and removed in favor of granular managed permissions. Please help test the change. Emergency override: If you find an issue, first report it and then give the following ldif to ldapmodify to restore the global anonymous ACI. Replace both instances of $SUFFIX by the DN that `ipa env basedn` gives you. 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";) Relevant ticket: https://fedorahosted.org/freeipa/ticket/3566 -- Petr? From pvoborni at redhat.com Mon May 26 10:32:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 26 May 2014 12:32:30 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <5382F02C.9000701@redhat.com> References: <1400090912.4568.13.camel@ipa.example.com> <1400879990.2513.23.camel@ipa.example.com> <5382F02C.9000701@redhat.com> Message-ID: <5383183E.9000909@redhat.com> On 26.5.2014 09:41, Martin Kosek wrote: > On 05/23/2014 11:19 PM, Nathaniel McCallum wrote: >> On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: >>> Occasionally OTP tokens get out of sync with the server. When this >>> happens, the user or an admin need to synchronize the token. To this >>> end, we landed server-side synchronization support, which is a simple >>> bind with a custom control. This all works with my sample test script. >>> >>> Client support is proving a bit more difficult. In the ideal world, the >>> client would contact LDAP directly and perform the operation. This would >>> make a man in the middle attack difficult and we can ensure encryption >>> over the entire operation. >>> >>> However, browsers, without server-side assistance, cannot perform this >>> operation from javascript. This means that, in this case, the first >>> factor and two second factors must be transmitted to the FreeIPA server >>> and then proxied to 389. Is this an acceptable compromise? >>> >>> This command also needs to be accessible *without* an existing user >>> login since, if a user's token is out of sync, the user can't login. Is >>> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >>> ping" seem to require kinit, so I don't see any obvious examples. >> >> Thanks everyone for your feedback. This particular feature is proving >> difficult to implement, even with our agreed upon design. To reiterate >> this design: there will be an HTTP method by which to synchronize >> tokens. >> >> There are two assumptions in the code which are making this difficult: >> 1. All cli commands are Command subclasses. >> 2. All Command subclasses create authenticated server methods. >> >> There are thus two ways to tackle this problem. >> >> First, I can create a standard POST method in rpcserver.py. This is not >> very modular. But the biggest problem is that there is no way to create >> the cli-side command to call it (assumption #1). >> >> Second, I can create a Command subclass, similar to the passwd plugin. >> This will create both the client- and server-side components. However, >> there is no way to disable the server-side authentication. >> >> I think that solving the second of these problems is the most reusable. >> Just as an example, the ping command currently requires authentication >> but does not need to do so. The passwd Command too shouldn't need to >> authenticate before executing the command because the command >> authenticates itself. >> >> I think it very likely that we are going to have need for other Command >> subclasses in the future which do not require authentication. It would be useful for `json_metadata` and `i18n` commands. Also I would like to see a global web ui configuration which could be read prior to authentication, e.g., to get allowed authentication methods( we have a ticket to disable forms-based auth). >> >> However, implementing this approach is rather difficult as it will >> require a refactoring of rpcserver.py. The code in rpcserver.py contains >> many layering violations and the class structure is rather unclear >> (look, for instance, at the different orders in which xmlrpc and jsonrpc >> classes inherit from their parent classes). >> >> The current problem forcing this refactoring is that authentication >> appears to happen across several different layers, but always before the >> command to be executed is unmarshalled. We need to invert this order: >> the command needs to be unmarshalled first in order to determine whether >> or not authentication is necessary. I don't think that switching this >> order is practical without constraining authentication to a single layer >> (or two: session and krb5) late in the request process. >> >> Git tells me that lots of people have touched this code, so I'm hoping >> for good feedback! ;) >> >> Alternatively, we could create a way to inject cli commands without >> having Command subclasses. Isolating these concerns is itself probably a >> good design choice. Ideally we'd have a structure where the Command >> class itself inherits from a CLICommand class and a ServerMethod class. >> But this too will be a massive refactoring, perhaps even bigger than the >> rpcserver.py refactoring. >> >> So, which assumption should we break: #1 or #2? And who wants to help me >> do it? Also, I am all ears for easier solutions for this feature. >> >> Nathaniel > > Hi Nathaniel, > > These are all good ideas, it is true that we are sometimes hitting framework > limitations which will force to rewrite some parts, Petr Viktorin already have > couple of wished refactorings in mind. > > What you are suggesting sounds as a pretty massive refactorings touching basic > framework parts that have not been touched for long years. Refactorings of > this scale would take months of planning and execution. > > Question is, does this use case warrants such big change? AFAIK, we need to > solve following use cases: > > 1) Admin wants to manipulate user's token via Web UI/CLI - easy to do, admin is > authenticated and can run any commands > > 2) User wants to re-synchronize token via Web UI: easy to do, create POST > callback and a Web UI page. IMO, Web UI will be the most used synchronization > interface for users, it is usually not very frequent operation so Web UI can > guide user through the procedure (as compared to plain CLI). > > 3) User wants to re-synchronize a token via CLI: given the framework is not > ready for this kind of unauthenticated operation and refactorings would take > massive amount of time, can we simply avoid using the framework and provide a > standalone CLI utility "ipa-token-resync" and deploy it in freeipa-client > package? The utility can then call the LDAP operation directly and wrap it in a > nice CLI interface for the user. > > Martin > From long-term perspective, I'm for the refactoring. But if there is no time and if we want the feature, combination of Martin's #1 and #2 would a sufficient solution. Both could be just an interface for the same logic. -- Petr Vobornik From pviktori at redhat.com Mon May 26 10:39:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 12:39:57 +0200 Subject: [Freeipa-devel] [PATCH] 0551 ldap2.find_entries: Do not modify attrs_list in-place In-Reply-To: <537DFD55.4030607@redhat.com> References: <537DF6A4.2020806@redhat.com> <537DFD55.4030607@redhat.com> Message-ID: <538319FD.8020902@redhat.com> On 05/22/2014 03:36 PM, Jan Cholasta wrote: > On 22.5.2014 15:07, Petr Viktorin wrote: >> This fixes https://fedorahosted.org/freeipa/ticket/4349. >> >> See the ticket for a description. > > Looks OK to me, ACK. > Thanks, pushed to master: 988b2cebf4bf6657eb50f5ecc57bd39425739b8b -- Petr? From pviktori at redhat.com Mon May 26 10:48:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 12:48:51 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <53734A64.9080701@redhat.com> References: <535FE8D0.7030608@redhat.com> <1398795455.10424.108.camel@willson.li.ssimo.org> <5360068E.80805@redhat.com> <5360AD85.9010802@redhat.com> <53734A64.9080701@redhat.com> Message-ID: <53831C13.9020506@redhat.com> On 05/14/2014 12:50 PM, Petr Viktorin wrote: > On 04/30/2014 10:00 AM, thierry bordaz wrote: >> On 04/29/2014 10:07 PM, Martin Kosek wrote: >>> On 04/29/2014 08:17 PM, Simo Sorce wrote: >>>> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >>>>> This adds the "idnsSecInlineSigning" attribute and related option. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3801 >>>>> >>>>> Simo, is adding a MAY attribute to an existing objectClass okay? >>>>> >>>> >>>> Not unheard of, however in the past we discovered some schema >>>> replication issues that may have an impact, let's make sure DS team >>>> also >>>> agrees this is not going to cause issue. >>>> >>>>> From a purely functional pov a MAY attribute will not break any stored >>>> object, so it is fine. >>>> >>>> Simo. >>> >>> Adding Thierry to the CC list to evaluate the risks, he was already >>> involved in fixing related issue in the DS for a similar Dogtag schema >>> extension. >> Hello, >> >> When an instance in the topology contains schema extensions like new >> MAY attribute, this extension would be propagated to all instances >> by replication (no need to copy/merge schema files). This was the >> purpose of https://fedorahosted.org/389/ticket/47721. So it is fine >> to add new MAY/MUST attribute or new attribute/objectclasses. >> >> During a replication session, a master will check what schema >> definitions (objectclasses/attributes) of the replica extends its >> own schema. If such definitions exist the supplier add/replace them >> in its schema and its user99.ldif file. In your case if a replica >> contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but >> not the supplier then the supplier 'learns it' (during a replication >> session it initiated) and so an entry containing that new attribute >> can be updated on the supplier as well. >> There is a similar mechanism, when a replica receives a schema that >> contains new definitions, it 'learns' them. >> >> The fix for 47721 is introduced in 389-ds 1.3.2.17 and after. >> It was tested with mixing 1.3.2.17 instance with legacy versions >> (1.3.1, 1,3.0..), and the schema on both side converged to a common >> one. This, whatever if the extensions are present on both side. >> A limitation is that a legacy instance (not having the fix), must >> have a replica agreements to/from an instance with the fix. >> >> regards >> thierry >> > > Thanks. This means the patch is good for review. > I've just rebased it slightly. Another rebase in VERSION was necessary. Still looking for a review. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0543.3-dns-Add-idnsSecInlineSigning-attribute-add-dnssec-op.patch Type: text/x-patch Size: 9711 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 26 11:11:44 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 26 May 2014 13:11:44 +0200 Subject: [Freeipa-devel] [PATCH] 630 rpcserver: login_password datetime fix in expiration check In-Reply-To: <537DB73C.2020304@redhat.com> References: <536A3985.20502@redhat.com> <536A3CB2.6060408@redhat.com> <536A42A1.4070803@redhat.com> <536A436C.10206@redhat.com> <536A4519.3080601@redhat.com> <537DB73C.2020304@redhat.com> Message-ID: <53832170.6030100@redhat.com> On 22.5.2014 10:37, Tomas Babej wrote: > > On 05/07/2014 04:37 PM, Petr Vobornik wrote: >> On 7.5.2014 16:30, Tomas Babej wrote: >>> >>> On 05/07/2014 04:26 PM, Petr Vobornik wrote: >>>> On 7.5.2014 16:01, Tomas Babej wrote: >>>>> >>>>> On 05/07/2014 03:47 PM, Petr Vobornik wrote: >>>>>> krbpasswordexpiration conversion to number of second since epoch >>>>>> failed >>>>>> because now we get datetime object instead of string. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4339 >>>>>> >>>>>> >>>>> NACK, I don't think this is the right approach. This does not leverage >>>>> the simplicity which the DateTime parameter refactoring provides. >>>>> >>>>> Instead of converting the datetime to the number of the seconds since >>>>> epoch, and getting the current time represented by the number of >>>>> seconds >>>>> since the epoch (using time.time()), why not use datetime module and >>>>> datetime.datetime.now() to get the current time? >>>>> >>>>> Then you could simplify this: >>>>> >>>>> + exp = time.mktime(expiration.timetuple()) >>>>> + if exp <= time.time(): >>>>> >>>>> to this: >>>>> >>>>> + if expiration <= datetime.datetime.now() >>>>> >>>> >>>> Good point, fixed >>>> >>> >>> Can you also please remove the (now) unused import for module time? >>> >> done >> > > ACK. > Pushed to master: 1e96475a77280bbdc883c66e0dc451ef0559c5fb -- Petr Vobornik From pvoborni at redhat.com Mon May 26 11:27:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 26 May 2014 13:27:16 +0200 Subject: [Freeipa-devel] [PATCH] 643 Increase Java stack size for Web UI build on aarch64 In-Reply-To: <20140521083009.GG23849@redhat.com> References: <537C60B8.6030506@redhat.com> <20140521083009.GG23849@redhat.com> Message-ID: <53832514.10004@redhat.com> On 21.5.2014 10:30, Alexander Bokovoy wrote: > On Wed, 21 May 2014, Petr Vobornik wrote: >> Fixes build failure on aarch64: >> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2328356 >> >> Successful scratch build: >> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2332222 >> >> One patch is for upstream, second for fedora package. > ACK. pushed to master: * 8cde6f0d6e6b43c83f192ff8c1ff6107fa0736aa Increase Java stack size for Web UI build on aarch64 -- Petr Vobornik From pviktori at redhat.com Mon May 26 11:38:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 13:38:12 +0200 Subject: [Freeipa-devel] ACI "Midair collision" bug (Was: [PATCHES] 0552-0554 Upgrading write permissions) In-Reply-To: <537DF6A6.7020001@redhat.com> References: <537DF6A6.7020001@redhat.com> Message-ID: <538327A4.6020000@redhat.com> On 05/22/2014 03:07 PM, Petr Viktorin wrote: > Hello, > Here I start upgrading the existing default permissions to the new > Managed style. > > https://fedorahosted.org/freeipa/ticket/4346 > > The patches rely on my patch 0551 > (https://fedorahosted.org/freeipa/ticket/4349) > You may run into what seems to be a 389 bug. If you get a "Midair > Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running > ipa-ldap-updater again. I'm working with Ludwig on this one. > This bug is indeed in 389 and there's a fix. I'll test with the current build to verify. I'm re-sending some of our private comunication to the list, in case anyone wants to try reproducing the issue. On 05/26/2014 11:27 AM, Ludwig Krispenz wrote: > > Hi, > > I now consitently reproduced the issue and debugged it. It is in fact a case, where in sorting the values of an attribute in some cases another comparison function was used. The current state of the 1.3.2 branch partially fixes and/or prevents the problem by using another defaultcomparison function, with a current build the test scenario passed. > Maybe you can try the rpms at > > http://copr-be.cloud.fedoraproject.org/results/lkrispen/132test/fedora-20-x86_64/389-ds-base-1.3.2.16-20140526081843.fc17/ > > We will need to provide an official 1.3.217 (and should fix a few more locations which could lead to the problem. > > Regards, > Ludwig On 05/21/2014 01:19 PM, Petr Viktorin wrote: > > Steps to reproduce: > - Install "master" & "replica" on FreeIPA from the f20 repos > (freeipa-server-3.3.5-1) > - Upgrade "master" to my #4344 WIP branch > - RPMs: http://fedorapeople.org/~pviktori/rpms/freeipa-2f9399d/ > - source: git pull http://github.com/encukou/freeipa ticket-4344-wip > - Run ipa-ldap-updater on the "replica" > - The problem appears on master. > > I can confirm that things work after a restart. > > > > Commands used to reproduce: > > $ ldapsearch -x -h localhost -D 'cn=Directory Manager' -w 12345678 -o > ldif-wrap=no -b dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com -s base > aci | grep -i 'Modify Sudo rule' > aci: (targetattr = "description || ipaenabledflag || usercategory || > hostcategory || cmdcategory || ipasudorunasusercategory || > ipasudorunasgroupcategory || externaluser || ipasudorunasextuser || > ipasudorunasextgroup || memberdenycmd || memberallowcmd || > memberuser")(target = > "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com")(version > 3.0;acl "permission:Modify Sudo rule";allow (write) groupdn = > "ldap:///cn=Modify Sudo > rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > > aci: (targetattr = "cmdcategory || description || externalhost || > externaluser || hostcategory || hostmask || ipaenabledflag || > ipasudoopt || ipasudorunas || ipasudorunasextgroup || > ipasudorunasextuser || ipasudorunasgroup || ipasudorunasgroupcategory > || ipasudorunasusercategory || memberallowcmd || memberdenycmd || > memberhost || memberuser || sudonotafter || sudonotbefore || sudoorder > || usercategory")(targetfilter = "(objectclass=ipasudorule)")(version > 3.0;acl "permission:System: Modify Sudo rule";allow (add) groupdn = > "ldap:///cn=System: Modify Sudo > rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > > # System: Modify Sudo rule, permissions, pbac, idm.lab.eng.brq.redhat.com > dn: cn=System: Modify Sudo > rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > # Modify Sudo rule, permissions, pbac, idm.lab.eng.brq.redhat.com > dn: cn=Modify Sudo > rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > > > $ ldapmodify -x -h localhost -D 'cn=Directory Manager' -w 12345678 > dn: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > changetype: modify > delete: aci > aci: (targetattr = "description || ipaenabledflag || usercategory || > hostcategory || cmdcategory || ipasudorunasusercategory || > ipasudorunasgroupcategory || externaluser || ipasudorunasextuser || > ipasudorunasextgroup || memberdenycmd || memberallowcmd || > memberuser")(target = > "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com")(version > 3.0;acl "permission:Modify Sudo rule";allow (write) groupdn = > "ldap:///cn=Modify Sudo > rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";) > > > modifying entry "dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > ldap_modify: No such attribute (16) -- Petr? From pviktori at redhat.com Mon May 26 14:44:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 16:44:09 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <537DF6A6.7020001@redhat.com> References: <537DF6A6.7020001@redhat.com> Message-ID: <53835339.1040900@redhat.com> On 05/22/2014 03:07 PM, Petr Viktorin wrote: > Hello, > Here I start upgrading the existing default permissions to the new > Managed style. > > https://fedorahosted.org/freeipa/ticket/4346 > > The patches rely on my patch 0551 > (https://fedorahosted.org/freeipa/ticket/4349) > You may run into what seems to be a 389 bug. If you get a "Midair > Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running > ipa-ldap-updater again. I'm working with Ludwig on this one. > > > > The operation is now described at > http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions > > > If there user has modified an old default permission, a warning is > logged the replacement permission is not added/updated. The user needs > to evaluate the situation: either update the old permission to match the > original default, or remove the old permission, and then run > ipa-ldap-updater will create the new one. > Is bailing out the right thing to do if the old entry was modified? > It could be possible to parse the permission, figure out the changes the > user made, and apply them to the new one, but that seems like too much > guesswork to me. > On the other hand, my approach has a downside as well: if the > 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's > now no way to upgrade while allowing access but keeping that attribute > off-limits, short of writing deny a ACI by hand. How big a problem is > this? It might be worth it to create a special tool that upgrades a > single permission and allows setting the excluded/included attributes > explicitly. > > > > There are some interesting scenarios to think about with respect to > upgrades and user changes: > > * Upgrade to old version, e.g. > - have IPA 3.2 master, IPA 3.2 replica > - upgrade master to 4.0 (old permissions are updated) > - then upgrade replica to 3.3 (old permissions are added again!) > > This is AFAIK not supported but it does happen. > We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will > always add the old permissions, but with this patch, a subsequent > upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old > permissions again. > > Tied to that is another scenario: > > * Re-create permissions with old names > - have IPA 4.0 master > - Create a permission named 'Modify Sudo rule' > - Upgrade to IPA 4.1 > > Here we need to make sure the new permission is *not* removed, because a > new 'Modify Sudo rule' permission is no longer special in any way. To > ensure this the updater only removes old-style permissions. > > One thing that can happen when 4.0 masters are still mixed with 3.x is > that an old permission named 'Modify Sudo rule' is added on the old > server. Any update to 4.0+ will remove that. > Old-style default permissions were sorta-kinda managed by IPA itself > anyway, so users should expect this. We should still point it out in the > docs though, since I expect some users to start messing with the > permissions before upgrading all of the infrastructure to 4.0. > > > The second patch upgrades sudorule permissions, this server as an > example of how the will work. > The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 The user read permissions patches had a conflict with these; attaching rebased version. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0552.2-Add-mechanism-for-updating-permissions-to-managed.patch Type: text/x-patch Size: 5699 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0553.2-Convert-Sudo-rule-default-permissions-to-managed.patch Type: text/x-patch Size: 6658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0554.2-Add-missing-attributes-to-Modify-Sudo-rule-permissio.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: From jcholast at redhat.com Mon May 26 14:57:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 May 2014 16:57:05 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1400001168.2512.20.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> Message-ID: <53835641.7040001@redhat.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; >>>>> acl "Users can create and delete tokens"; allow (add, delete) userattr = >>>>> "ipatokenOwner#SELFDN";) >>>>> >>>>> This is what they look like using managedBy (I have not tested this): >>>>> >>>>> 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"; allow (read, search, compare) >>>>> userattr = "managedBy#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"; allow >>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>> >>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>> "managedBy#USERDN";) >>>>> >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; >>>>> allow (write) userattr = "managedBy#USERDN";) >>>>> >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>> "managedBy#USERDN";) >>>>> >>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>>>> userattr = "managedBy#SELFDN";) >>>>> >>>>> In short: >>>>> 1. Owner and manager get read, search and compare. >>>>> 2. Manager gets write (to select attributes) and delete. >>>>> 3. Users can create self-managed tokens for themselves only. >>>>> >>>>> The otptoken-add command should gain the following defaults: >>>>> 1. The owner defaults to the user adding the token. >>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>> 3. Otherwise, managedBy defaults to None. >>>>> >>>>> This means that if neither owner nor managedBy are specified, the >>>>> default is a self-owned, self-managed token. Likewise, if a different >>>>> owner is specified, no manager is assumed. >>>>> >>>>> rcrit expresses worry that ipalib's ACI parser may not handle the above >>>>> syntax. This will become clear during testing if we want this approach. >>>>> >>>>> Does this look sane? >>>> >>>> I am not entirely sure your ACI syntax is always right for the second >>>> set. and perhaps we want to duplicate ACIs in some cases (once for owner >>>> once for manager). >>>> >>>> I think the read ACIs do not need to list managedby ? Do we plan to have >>>> a manager that is another regular user but not the owner nor an admin ? >>>> >>>> In any case I prefer the sytnax that uses managedby, as it has more >>>> potential. >>> >>> Attached is a new version of the patch which implements the feature >>> using managedBy instead of ipatokenProtected. One important thing needs >>> to be said about this patch. I am not exposing managedBy in either the >>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>> expose this similar to owner or as a relationship? >> >> I would expose it, as a relationship. (Note that ipatokenowner should >> ideally be represented as a relationship too, but the framework does not >> support 1-to-many relationships ATM.) > > So since this is a 1-to-many relationship we shouldn't expose it? > > Or should I do it like owner is currently done? Do it like managedby is done in the host plugin (see "attribute_members", "relationships", etc.) > >> >> Just curious, why are the ACIs divided like this: >> >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers >> can read basic token info"; allow (read, search, compare) userattr = >> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >> "ipatokenOTPalgorithm || ipatokenOTPdigits || >> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP >> details"; allow (read, search, compare) userattr = >> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >> "Users/managers can see HOTP details"; allow (read, search, compare) >> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >> >> IMHO you could make them less complex by dividing them like this: >> >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can >> read token details"; allow (read, search, compare) userattr = >> "ipatokenOwner#USERDN";) >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers >> can read token details"; allow (read, search, compare) userattr = >> "managedBy#USERDN";) > > The first set is organized by objectClass. The second by userattr. I > have no strong opinion on this matter, though performance is probably a > consideration. Do any DS guys want to chime in? I would still like to know someone else's opinion on this, but if there's none, let's keep it your way. > >> Would it make sense to keep --protected as a flag in otptoken-add as a >> shortcut for "entry_attrs['managedby'] = None"? > > I can't think of a use case for this. The only use case I *can* think of > is an admin creating a non-protected token for a user. OK. > >> Would it make sense to default managedby to the current bind DN in >> otptoken-add, even if it's not a user DN? (Do we want to allow running >> otptoken-add by hosts/services/other non-users?) > > No idea. Dmitri? We can add this later if necessary. > >> Is orphaning a token when a user is deleted only if it is not managed by >> any other users the intended behavior? It just seems sort of strange to >> me, since it changes the token from unprotected to protected. > > I don't think that is the behavior. We orphan the token if the owner is > not listed as a manager. If the owner is listed as a manager, we delete > the token. > > Put another way, protected tokens are orphaned and unprotected tokens > are deleted. > > If I didn't implement that, please point out my bug. Sorry, my bad, your code is right. You can make it simpler, though: orphan = [x for x in token.get('managedby', []) if x == dn] (The "len() == 0" check is not necessary and using list comprehensions makes the code more readable than using filter.) > > Nathaniel > -- Jan Cholasta From pvoborni at redhat.com Mon May 26 15:08:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 26 May 2014 17:08:42 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <537A0011.5050207@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> Message-ID: <538358FA.6070304@redhat.com> On 19.5.2014 14:58, Petr Vobornik wrote: > 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 action dropdown > 639 webui-ci: assert_action_list_action > 638 webui: use dark color for facet titles without pkey > 637 webui: association adder dialog - change find label to filter > 636 webui: certificate search - select search attribute only when defined > 635 webui: change control buttons to normal buttons > 634 webui: add search box placeholder text > 633 webui: adjust header controls alignment > 628 webui: remove old css for standalone pages > 627 webui-ci: select search table item - chrome issue > 626 webui: use BS alerts in validation_summary_widget > 625 webui: adjust login page to PatternFly > 624 webui: preload automember default group select list > 623 webui: restyle automember default group > 622 webui: do not show empty table footer > 621 webui: improve pagination > 620 webui: activity indicators > 619 webui: adjust association adder dialog to PatternFly > 618 webui: patternFly dialog > 617 webui: move user reset password action to action dropdown > 616 webui: move certificate actions to action dropdown > 615 webui: add confirmation to action dropdown actions > 614 webui: remove select action > 613 webui: add space between action buttons's icon and text > 612 webui: add action dropdown > 611 webui: remove action list widget > 610 webui: use h1 in facet title instead of h3 > 609 webui: change breadcrumb to PatternFly > 608 webui: allow multiple base section layouts > 607 webui: display undo and multivalued delete buttons in input-group > 606 webui: adjust styles to PatternFly > 605 webui: change navigation from RCUE to PatternFly > 604 webui: remove column sizing in tables, use PF styles > 603 webui: change absolutely positioned layout to fluid > 602 webui: remove unused images > 601 webui: remove unused collapsible feature from section > 600 webui: remove unused icons > 599 webui: remove remnants of jquery-ui > 598 webui: apply PatternFly theme on migration pages > 597 webui: styles for alert icons > 596 webui: apply PatternFly theme on config pages > 595 webui: apply PatternFly login theme on reset_password.html > 594 webui: add PaternFly css > 593 webui: remove login.html > 592 webui: remove logout.html The branch was rebased and commit 644 webui: move radius proxy action panel commands to header actions http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/commit/?h=patternfly&id=a0591297adaec404ad1142651d2f6ce1a61e6164 was added. -- Petr Vobornik From pviktori at redhat.com Mon May 26 16:20:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 18:20:49 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <537B7FA9.9000909@redhat.com> References: <537B7FA9.9000909@redhat.com> Message-ID: <538369E1.5020300@redhat.com> On 05/20/2014 06:15 PM, Tomas Babej wrote: > Hi, > > the following set of patches fixes: > > https://fedorahosted.org/freeipa/ticket/4274 > https://fedorahosted.org/freeipa/ticket/4263 > https://fedorahosted.org/freeipa/ticket/4324 > https://fedorahosted.org/freeipa/ticket/4340 > https://fedorahosted.org/freeipa/ticket/4341 > > and additional minor issues. > > The improvemed CI test coverage for the sudorule plugin is added as a bonus. Thanks! I haven't tested yet; here are my comments on the code. 0187 - sudorule: PEP8 fixes in sudorule.py This change: > @@ -527,11 +551,15 @@ def pre_callback(self, ldap, dn, found, not_found, *keys, **options): > _entry_attrs = ldap.get_entry(dn, self.obj.default_attributes) > except errors.NotFound: > self.obj.handle_not_found(*keys) > - if is_all(_entry_attrs, 'hostcategory'): > - raise errors.MutuallyExclusiveError(reason=_("hosts cannot be added when host category='all'")) > + > + if is_all(self._entry_attrs, 'hostcategory'): > + raise errors.MutuallyExclusiveError( > + reason=_("hosts cannot be added when host category='all'")) > + > return add_external_pre_callback('host', ldap, dn, keys, options) adds `self` to `self._entry_attrs`. That should be a part of the next patch. Git tip: `git log --word-diff` helps a lot when you play with whitespace (Speaking of PEP8, if you could remove the baseldap star import from sudorule.py, it would be great...) General thoughts: Would it be possible to merge schema_compat.uldif and install/updates/10-schema_compat.update into one file? Is the uldif special somehow? I guess this is a question for Rob. It would be nice to add a link to some schema-compat-entry-attribute documentation to these files. 0188 - sudorule: Allow using hostmasks for setting allowed hosts Here: > --- a/install/updates/40-delegation.update > +++ b/install/updates/40-delegation.update > @@ -174,7 +174,7 @@ default:member: cn=Sudo Administrator,cn=privileges,cn=pbac,$SUFFIX > dn: $SUFFIX > add:aci: '(target = "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Add Sudo rule";allow (add) groupdn = "ldap:///cn=Add Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' > add:aci: '(target = "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Delete Sudo rule";allow (delete) groupdn = "ldap:///cn=Delete Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' > -add:aci: '(targetattr = "description || ipaenabledflag || usercategory || hostcategory || cmdcategory || ipasudorunasusercategory || ipasudorunasgroupcategory || externaluser || ipasudorunasextuser || ipasudorunasextgroup || memberdenycmd || memberallowcmd || memberuser")(target = "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Modify Sudo rule";allow (write) groupdn = "ldap:///cn=Modify Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' > +add:aci: '(targetattr = "description || ipaenabledflag || usercategory || hostcategory || cmdcategory || ipasudorunasusercategory || ipasudorunasgroupcategory || externaluser || ipasudorunasextuser || ipasudorunasextgroup || memberdenycmd || memberallowcmd || memberuser || hostmask")(target = "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Modify Sudo rule";allow (write) groupdn = "ldap:///cn=Modify Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' > > remove:aci: '(targetattr = "description")(target = "ldap:///sudocmd=*,cn=sudocmds,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Modify Sudo command";allow (write) groupdn = "ldap:///cn=Modify Sudo command,cn=permissions,cn=pbac,$SUFFIX";)' > remove:aci: '(target = "ldap:///sudocmd=*,cn=sudocmds,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Delete Sudo command";allow (delete) groupdn = "ldap:///cn=Delete Sudo command,cn=permissions,cn=pbac,$SUFFIX";)' you'll want to remove the old ACI before adding the new version. In get_options of sudorule_add_host and sudorule_remove_host, it would be DRY-er to put the hostmask in a shared variable. You write: > - _entry_attrs = ldap.get_entry(dn, self.obj.default_attributes) > + self._entry_attrs = ldap.get_entry(dn, self.obj.default_attributes) Never store anything on the Command object. They're currently singletons. Another thread could change _entry_attrs to a different value. This affects all the other uses of self._entry_attrs, of course. In: > + num_added = len(new_masks.difference(old_masks)) and: > + entry_attrs['hostmask'] = list(old_masks.union(new_masks)) and: > + num_added = len(removed_masks.intersection(old_masks)) etc.: with two sets, you can use the `-`, `|`, and `&` operators. Since you're touching this: > + return add_external_post_callback('memberhost', 'host', 'externalhost', > + ldap, completed, failed, dn, > + entry_attrs, keys, options) it would be nice to pass the arguments by name, for clarity and to avoid mistakes. I guess this should be in the PEP8 patch, too. 0189 sudorule: Allow using external groups as groups of runAsUsers In sudorule_add_runasuser and sudorule_remove_runasuser, could you again pass the arguments by name? I'd welcome comment explaining why completed=0. If you could throw in a comment for add_external_post_callback explaining the inputs and outputs, it would be great -- I'm getting quite lost in this code. (I'd even go as far as changing the signature of *_external_post_callback -- AFAICS, in all the places we call it, we do `*keys, **options` wrong, and the `completed` argument is not useful at all. Most of the calls are from sudorule so it would make sense to do it in this patchset.) And a heads-up: the change to "permission:Modify Sudo rule" conflicts with my ACI work. Let me know if there are problems. 0190 sudorule: Make sure sudoRunAsGroup is dereferencing the correct attribute Looks good 0191 sudorule: Include externalhost and ipasudorunasextgroup in the list of default attributes Looks good 0192 sudorule: Allow adding deny commands when command category set to ALL Looks good 0193 sudorule: Make sure all the relevant attributes are checked when setting category to ALL Wow, haven't seen a copyright year change in some time. We are sloppy with those. Portions of the file are still from 2010 so you should definitely leave that year in, though. Actually I think the proper year field would read "2010,2011,2012,2013,2014". I am not a lawyer. You're missing the `_` for the hostcategory error message. Did you think about using something like _("%s cannot be set to 'all' while there are %s")? 0194 sudorule: Fix the order of the parameters to have less chaotic output Looks fine 0195-sudorule-Enforce-category-ALL-checks-on-dirsrv-level.patch Looks fine 0196-0198 (Add tests) Looks fine. Just remind me, why is this all in integration tests? Couldn't it at least some of it be in the main test suite? It looks to me like most of it doesn't need multiple machines. 0199-0201 (test fixes) OK -- Petr? From npmccallum at redhat.com Mon May 26 16:23:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 26 May 2014 12:23:43 -0400 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <5382F3B8.7030802@redhat.com> References: <1400090912.4568.13.camel@ipa.example.com> <1400879990.2513.23.camel@ipa.example.com> <5382F3B8.7030802@redhat.com> Message-ID: <1401121423.29756.2.camel@ipa.example.com> On Mon, 2014-05-26 at 09:56 +0200, Jan Cholasta wrote: > On 23.5.2014 23:19, Nathaniel McCallum wrote: > > On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: > >> Occasionally OTP tokens get out of sync with the server. When this > >> happens, the user or an admin need to synchronize the token. To this > >> end, we landed server-side synchronization support, which is a simple > >> bind with a custom control. This all works with my sample test script. > >> > >> Client support is proving a bit more difficult. In the ideal world, the > >> client would contact LDAP directly and perform the operation. This would > >> make a man in the middle attack difficult and we can ensure encryption > >> over the entire operation. > >> > >> However, browsers, without server-side assistance, cannot perform this > >> operation from javascript. This means that, in this case, the first > >> factor and two second factors must be transmitted to the FreeIPA server > >> and then proxied to 389. Is this an acceptable compromise? > >> > >> This command also needs to be accessible *without* an existing user > >> login since, if a user's token is out of sync, the user can't login. Is > >> it possible to expose such an API? If so, how? Both "ipa env" and "ipa > >> ping" seem to require kinit, so I don't see any obvious examples. > > > > Thanks everyone for your feedback. This particular feature is proving > > difficult to implement, even with our agreed upon design. To reiterate > > this design: there will be an HTTP method by which to synchronize > > tokens. > > > > There are two assumptions in the code which are making this difficult: > > 1. All cli commands are Command subclasses. > > 2. All Command subclasses create authenticated server methods. > > > > There are thus two ways to tackle this problem. > > > > First, I can create a standard POST method in rpcserver.py. This is not > > very modular. But the biggest problem is that there is no way to create > > the cli-side command to call it (assumption #1). > > Well, you could derive the command from ipalib.frontend.Local and > manually call the POST method from it. This still creates a (NoOp) server-side RPC method, right? We can probably just accept this as a drawback for now and move on. After a future refactoring of rpcserver.py, we can move the manual POST method into this server-side RPC method. > > Second, I can create a Command subclass, similar to the passwd plugin. > > This will create both the client- and server-side components. However, > > there is no way to disable the server-side authentication. > > > > I think that solving the second of these problems is the most reusable. > > Just as an example, the ping command currently requires authentication > > but does not need to do so. The passwd Command too shouldn't need to > > authenticate before executing the command because the command > > authenticates itself. > > > > I think it very likely that we are going to have need for other Command > > subclasses in the future which do not require authentication. > > > > However, implementing this approach is rather difficult as it will > > require a refactoring of rpcserver.py. The code in rpcserver.py contains > > many layering violations and the class structure is rather unclear > > (look, for instance, at the different orders in which xmlrpc and jsonrpc > > classes inherit from their parent classes). > > > > The current problem forcing this refactoring is that authentication > > appears to happen across several different layers, but always before the > > command to be executed is unmarshalled. We need to invert this order: > > the command needs to be unmarshalled first in order to determine whether > > or not authentication is necessary. I don't think that switching this > > order is practical without constraining authentication to a single layer > > (or two: session and krb5) late in the request process. > > > > Git tells me that lots of people have touched this code, so I'm hoping > > for good feedback! ;) > > > > Alternatively, we could create a way to inject cli commands without > > having Command subclasses. Isolating these concerns is itself probably a > > good design choice. Ideally we'd have a structure where the Command > > class itself inherits from a CLICommand class and a ServerMethod class. > > But this too will be a massive refactoring, perhaps even bigger than the > > rpcserver.py refactoring. > > > > So, which assumption should we break: #1 or #2? And who wants to help me > > do it? Also, I am all ears for easier solutions for this feature. > > I would go for the refactoring, the rpcserver code does indeed need some > love. > > > > > Nathaniel > From pviktori at redhat.com Mon May 26 18:01:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 20:01:03 +0200 Subject: [Freeipa-devel] [PATCH 0004] freeipa-ci: Add sudo integration job In-Reply-To: <5373840E.8050308@redhat.com> References: <5373840E.8050308@redhat.com> Message-ID: <5383815F.9000608@redhat.com> On 05/14/2014 04:56 PM, Tomas Babej wrote: > Hi, > > the sudo integration job is already in master, so it's time for the job > to be pushed to the upstream test job repository. > > Tomas Thanks, ACK, pushed to CI master: c691941610f2d431867938e6438f36d7ec3cddc1 -- Petr? git pull https://github.com/encukou/freeipa-ci.git master From pviktori at redhat.com Mon May 26 18:52:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 May 2014 20:52:52 +0200 Subject: [Freeipa-devel] My git post-commit hook (Was: [PATCH] 0544 Remove the global anonymous read ACI) In-Reply-To: <5383145C.1090805@redhat.com> References: <53601381.9050207@redhat.com> <5375FDE4.3070400@redhat.com> <537A06D9.4010000@redhat.com> <537C42CE.3030307@redhat.com> <537E03BD.8070505@redhat.com> <537F3E6D.5090004@redhat.com> <5383145C.1090805@redhat.com> Message-ID: <53838D84.80703@redhat.com> On 05/26/2014 12:15 PM, Petr Viktorin wrote: > On 05/23/2014 02:26 PM, Martin Kosek wrote: >> On 05/22/2014 04:03 PM, Petr Viktorin wrote: >>> On 05/21/2014 08:08 AM, Martin Kosek wrote: [...] >>>> The problem is that you used your testing suffix instead of suffix >>>> variable. >>> >>> Shame on me. I've updated & rebased the patch. >>> >>> I've also made a git hook yell at me when I commit something >>> containing "BRQ", >>> hopefully this won't happen again. >> >> Would it make sense to publish your FreeIPA git hooks somewhere on >> http://www.freeipa.org/page/Contribute/Code or your github and link >> it? I think >> it already contains couple gems that may help other people prevent >> basic errors >> like this one. > > Sure, I'll document it a bit and publish. I've put my post-commit hook here: https://github.com/encukou/ipa-tools/blob/master/hooks/post-commit.example It's still a bunch of examples however, and sometimes the output is not too understandable by itself, so I can't in good conscience recommend it to someone just starting to hack on FreeIPA. Feel free to use & improve it though. -- Petr? From ftweedal at redhat.com Tue May 27 07:00:45 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 27 May 2014 17:00:45 +1000 Subject: [Freeipa-devel] faster ways to build/test dogtag? Message-ID: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> Hi all, I've been working on a fix for a profile issue (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I find the scripts/compose_pki_core_packages -> yum install -> test cycle frustratingly slow on idm.lab.bos. Is there a quicker way to build and test the software - particularly as part of the larger IPA/certmonger/dogtag ecosystem? Cheers, Fraser From pviktori at redhat.com Tue May 27 08:44:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 May 2014 10:44:48 +0200 Subject: [Freeipa-devel] [PATCHES] 0555-0556 Add IPA version number to the install logs Message-ID: <53845080.8040401@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/4219 AFAIK the "vendor version" (e.g. 4.0.0-0.fc20) was not available to IPA, so I have it added to version.py when building packages. I wonder if there's an easier way to do this. The second patch logs the version in all the installation commands. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0555-ipalib.version-Add-VENDOR_VERSION.patch Type: text/x-patch Size: 2969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0556-admin-tools-Log-IPA-version.patch Type: text/x-patch Size: 6485 bytes Desc: not available URL: From tbordaz at redhat.com Tue May 27 09:14:52 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 11:14:52 +0200 Subject: [Freeipa-devel] Supported Staged entries Message-ID: <5384578C.6090603@redhat.com> Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: tb17 at idm.lab.bos.redhat.com krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 646400009 gidNumber: 646400009 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: tb20 at idm.lab.bos.redhat.com krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue May 27 09:16:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 May 2014 12:16:17 +0300 Subject: [Freeipa-devel] [PATCHES] 0555-0556 Add IPA version number to the install logs In-Reply-To: <53845080.8040401@redhat.com> References: <53845080.8040401@redhat.com> Message-ID: <20140527091617.GX23849@redhat.com> On Tue, 27 May 2014, Petr Viktorin wrote: > Hello, > > This fixes https://fedorahosted.org/freeipa/ticket/4219 > > AFAIK the "vendor version" (e.g. 4.0.0-0.fc20) was not available to IPA, so > I have it added to version.py when building packages. I wonder if there's an > easier way to do this. > > The second patch logs the version in all the installation commands. ACK to both, thanks! -- / Alexander Bokovoy From jcholast at redhat.com Tue May 27 09:53:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 May 2014 11:53:23 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384578C.6090603@redhat.com> References: <5384578C.6090603@redhat.com> Message-ID: <53846093.4030302@redhat.com> On 27.5.2014 11:14, thierry bordaz wrote: > Hello, > > Me again !!! > > Thanks to all your inputs, the discussion about User_life_cycle > clarified a lot workflow/command verbs. > > Now I have a doubt about what would be an entry in staging > (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add > --stage), would be the only support way to create stage entry. > > An active entry is looking like (with krb* attributes if the > userpassword is defined): > > dn: > uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > displayName: tb15 tb15 > cn: tb15 tb15 > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipasshuser > objectClass: ipaSshGroupOfPubKeys > objectClass: mepOriginEntry > loginShell: /bin/sh > gecos: tb15 tb15 > sn: tb15 > homeDirectory: /home/tb17 > uid: tb17 > mail: tb17 at idm.lab.bos.redhat.com > krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM > givenName: tb15 > initials: tt > ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd > uidNumber: 646400009 > gidNumber: 646400009 > mepManagedEntry: > cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, > dc=com > memberOf: > cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= > com > nsAccountLock: False > > > A staged entry created by 'ipa user-add --stage' may look like the > following. This kind of entry is easy to activate 'ipa user-unstage' > > dn: uid=tb20,cn=staged > users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > dc=redhat,dc=com > displayName: tb20 tb20 > cn: tb20 tb20 > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipasshuser > objectClass: ipaSshGroupOfPubKeys > loginShell: /bin/sh > uidNumber: -1 > ipaUniqueID: autogenerate > gidNumber: -1 > gecos: tb20 tb20 > sn: tb20 > homeDirectory: /home/tb20 > uid: tb20 > mail: tb20 at idm.lab.bos.redhat.com > krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM > givenName: tb20 > initials: tt > nsAccountLock: True > > Now are we going to support the following entries for 'ipa user-unstage' > > dn: cn=tb20,cn=staged > users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > dc=redhat,dc=com > objectClass: top > objectClass: person > sn: tb20 > cn: tb20 > nsAccountLock: True > > or > > dn: uid=tb20,cn=staged > users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > dc=redhat,dc=com > objectClass: top > objectClass: person > objectClass: posixAccount > sn: tb20 > cn: tb20 tb20 > uid: tb20 > uidNumber: -1 > gidNumber: -1 > homeDirectory: /home/tb20 > nsAccountLock: True > > > thanks > thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. -- Jan Cholasta From jcholast at redhat.com Tue May 27 10:01:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 May 2014 12:01:20 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382F8C3.6040009@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5382EE5B.5050802@redhat.com> <5382F8C3.6040009@redhat.com> Message-ID: <53846270.9050509@redhat.com> On 26.5.2014 10:18, Martin Kosek wrote: > On 05/26/2014 09:33 AM, Jan Cholasta wrote: >> On 26.5.2014 07:49, Martin Kosek wrote: > ... >>> > 5) modifying >>> > (in active) ipa user-mod tuser ... >>> >>> Ok. >>> >>> > (in stage) ipa user-mod tuser --staged ... >>> >>> Simo did not like this command, I would personally add it. As long as we >>> have "ipa user-add --staged", we should also have an option to delete >>> and modify user in staged area. >> >> +1 >> >>> >>> > (in del) ipa user-mod tuser --deleted ... >>> >>> Not needed. >>> >>> Is this acceptable for everyone? If yes, the next step would be for >>> Thierry to update the design page with new proposals. >>> >>> Martin >> >> Are users in different containers using the same uid allowed? > > Say you had a John Doe (uid jdoe) working in a company couple years ago. jdoe > left and is now in deleted accounts tree. Jane Doe joins the company now and > question is - do we want to allow Jane taking the same uid as John had? I am > thinking we should not allow that. Maybe we should allow override with --force > or having a global option. > > Another related topic is - do we want to enforce staged user to always have UID > RDN? Isn't that limiting? When writing > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Create_a_User_-_by_provisioning_system > > I proposed that we should also be able to unstage a minimal record like this: > > dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com > objectClass: top > objectClass: organizationalperson > cn: Test User > sn: User > nsAccountLock: True > >> If not, do we need the --staged/--deleted flags on anything but >> user-add/user-find? > > I see your point, but I think we should make admins to be very explicit when > manipulating users any area other than the active users area. As Simo noted, > these are not real users, just incomplete user records. If they are not users, they should not be managed by the user plugin in the first place. (But I guess people are so used to abusing IPA's object model that they don't care. Oh well.) > > Martin > -- Jan Cholasta From pviktori at redhat.com Tue May 27 10:09:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 May 2014 12:09:45 +0200 Subject: [Freeipa-devel] [PATCHES] 0555-0556 Add IPA version number to the install logs In-Reply-To: <20140527091617.GX23849@redhat.com> References: <53845080.8040401@redhat.com> <20140527091617.GX23849@redhat.com> Message-ID: <53846469.2090302@redhat.com> On 05/27/2014 11:16 AM, Alexander Bokovoy wrote: > On Tue, 27 May 2014, Petr Viktorin wrote: >> Hello, >> >> This fixes https://fedorahosted.org/freeipa/ticket/4219 >> >> AFAIK the "vendor version" (e.g. 4.0.0-0.fc20) was not available to >> IPA, so I have it added to version.py when building packages. I wonder >> if there's an easier way to do this. >> >> The second patch logs the version in all the installation commands. > ACK to both, thanks! Thanks for the review. Pushed to master: d6a4da30de37b2a3f1a3b4b8f8dd6dc0da3e1b50 -- Petr? From mkosek at redhat.com Tue May 27 10:20:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 12:20:46 +0200 Subject: [Freeipa-devel] faster ways to build/test dogtag? In-Reply-To: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> References: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> Message-ID: <538466FE.5040500@redhat.com> On 05/27/2014 09:00 AM, Fraser Tweedale wrote: > Hi all, > > I've been working on a fix for a profile issue > (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I > find the scripts/compose_pki_core_packages -> yum install -> test > cycle frustratingly slow on idm.lab.bos. Is there a quicker way > to build and test the software - particularly as part of the larger > IPA/certmonger/dogtag ecosystem? > > Cheers, > > Fraser I am not sure about dogtag - you would need to ask on pki-devel mailing list. As for FreeIPA - I use a home-grown synchronization script that puts modified python file in my local git directly into my test VM system so I do not need to compile and install FreeIPA rpms every time. Martin From pvoborni at redhat.com Tue May 27 10:49:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 May 2014 12:49:27 +0200 Subject: [Freeipa-devel] [PATCH] 645 webui: display only dialogs which belong to current facet Message-ID: <53846DB7.40403@redhat.com> Dialog instances no longer directly call IPA.opened_dialog methods. It's handled through events (decoupled from dialog's POV). IPA.open_dialogs with assistance of ApplicationController makes sure that there is only one dialog opened at the same time. It also makes sure to hide all dialogs, which are not global dialogs and did not originate from current facet, when switching facets. https://fedorahosted.org/freeipa/ticket/4348 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0645-webui-display-only-dialogs-which-belong-to-current-f.patch Type: text/x-patch Size: 8686 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 27 10:50:07 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 May 2014 12:50:07 +0200 Subject: [Freeipa-devel] [PATCH] 646 webui: handle back button when unauthenticated Message-ID: <53846DDF.2070808@redhat.com> using browser history when unauthenticated causes transition to the original and/or preceding facets. But nothing works since all commands fail due to expired credentials in session. These changes make sure that user stays on login screen if he misses valid session credentials while he wants to switch to facet which requires authentication. https://fedorahosted.org/freeipa/ticket/4353 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0646-webui-handle-back-button-when-unauthenticated.patch Type: text/x-patch Size: 8630 bytes Desc: not available URL: From mkosek at redhat.com Tue May 27 11:01:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 13:01:16 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <53846093.4030302@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> Message-ID: <5384707C.60705@redhat.com> On 05/27/2014 11:53 AM, Jan Cholasta wrote: > On 27.5.2014 11:14, thierry bordaz wrote: >> Hello, >> >> Me again !!! >> >> Thanks to all your inputs, the discussion about User_life_cycle >> clarified a lot workflow/command verbs. >> >> Now I have a doubt about what would be an entry in staging >> (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add >> --stage), would be the only support way to create stage entry. >> >> An active entry is looking like (with krb* attributes if the >> userpassword is defined): >> >> dn: >> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> displayName: tb15 tb15 >> cn: tb15 tb15 >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: ipasshuser >> objectClass: ipaSshGroupOfPubKeys >> objectClass: mepOriginEntry >> loginShell: /bin/sh >> gecos: tb15 tb15 >> sn: tb15 >> homeDirectory: /home/tb17 >> uid: tb17 >> mail: tb17 at idm.lab.bos.redhat.com >> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >> givenName: tb15 >> initials: tt >> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >> uidNumber: 646400009 >> gidNumber: 646400009 >> mepManagedEntry: >> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >> dc=com >> memberOf: >> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >> com >> nsAccountLock: False >> >> >> A staged entry created by 'ipa user-add --stage' may look like the >> following. This kind of entry is easy to activate 'ipa user-unstage' >> >> dn: uid=tb20,cn=staged >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >> dc=redhat,dc=com >> displayName: tb20 tb20 >> cn: tb20 tb20 >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: ipasshuser >> objectClass: ipaSshGroupOfPubKeys >> loginShell: /bin/sh >> uidNumber: -1 >> ipaUniqueID: autogenerate >> gidNumber: -1 >> gecos: tb20 tb20 >> sn: tb20 >> homeDirectory: /home/tb20 >> uid: tb20 >> mail: tb20 at idm.lab.bos.redhat.com >> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >> givenName: tb20 >> initials: tt >> nsAccountLock: True >> >> Now are we going to support the following entries for 'ipa user-unstage' >> >> dn: cn=tb20,cn=staged >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >> dc=redhat,dc=com >> objectClass: top >> objectClass: person >> sn: tb20 >> cn: tb20 >> nsAccountLock: True >> >> or >> >> dn: uid=tb20,cn=staged >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >> dc=redhat,dc=com >> objectClass: top >> objectClass: person >> objectClass: posixAccount >> sn: tb20 >> cn: tb20 tb20 >> uid: tb20 >> uidNumber: -1 >> gidNumber: -1 >> homeDirectory: /home/tb20 >> nsAccountLock: True >> >> >> thanks >> thierry > > IIUC unstaging a user will do something like this: > > staged_user = ldap.get_entry(staged_dn, ['*']) > api.Command.user_add(**staged_user) > > So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the particular user... Simo, what is your take on this? Thanks, Martin From pvoborni at redhat.com Tue May 27 11:15:44 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 May 2014 13:15:44 +0200 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible Message-ID: <538473E0.6070702@redhat.com> This is just a first draft of implementation of https://fedorahosted.org/freeipa/ticket/4345 It introduces a `freeipa/extend` module which should serve as a more stable API for Web UI plugins. I think it requires further discussion - what to have there, the level of abstraction... Other patches fixes navigation/router to support custom URL path patterns. The usage of facet.create_hash(router) method in patch #649 is questionable. The WIP patch contains an example of a plugin which uses this functionality. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0651-webui-plugin-API.patch Type: text/x-patch Size: 3256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0650-webui-add-parent-link-to-widgets-in-ContainerMixin.patch Type: text/x-patch Size: 1860 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0649-webui-create-hash-for-generic-facet.patch Type: text/x-patch Size: 1701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0648-webui-support-standalone-facets-in-navigation-module.patch Type: text/x-patch Size: 2206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0647-webui-fix-excessive-registration-of-state-change-eve.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0716-API-browser-plugin.patch Type: text/x-patch Size: 14170 bytes Desc: not available URL: From mkosek at redhat.com Tue May 27 11:16:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 13:16:16 +0200 Subject: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install In-Reply-To: <20140418160134.79627e82@unused-4-246.brq.redhat.com> References: <20140417145728.7fafe198@unused-4-246.brq.redhat.com> <534FE0F2.6070603@redhat.com> <534FE35F.3070607@redhat.com> <20140418160134.79627e82@unused-4-246.brq.redhat.com> Message-ID: <53847400.6030809@redhat.com> On 04/18/2014 04:01 PM, Misnyovszki Adam wrote: > On Thu, 17 Apr 2014 16:21:19 +0200 > Martin Kosek wrote: > >> On 04/17/2014 04:10 PM, Rob Crittenden wrote: >>> Misnyovszki Adam wrote: >>>> Hi, >>>> this patch modifies ipa-server-install to warn the user, if there >>>> is a lack of entropy, also runs generate-rndc-key.sh before named >>>> restart, to ensure, that it can start before systemd timeouts. >>> >>> I think the exception should be logged in check_entropy() in case >>> this every does fail (the file name changes, the format changes, >>> etc). >>> >>> There should be a try/except around the run() call. >>> >>> I noticed that /etc/rndc.key isn't removed on uninstall, which I >>> guess means the same key will be re-used. Should we be removing >>> that? >>> >>> rob >> >> Also, bare exceptions are bad! >> >> + except: >> + service.print_msg("Could not determine entropy, possible >> long delays") >> >> Next, you do all the checks in ipa-server-install, while they should >> be in service files, like krbinstance.py so that it is also checked >> in other installers, like ipa-replica-install. >> >> Same for DNS, it should be a separate step in bindinstance.py so that >> when the installation is hanging, you can see >> >> [X/Y] Generating rndc key file >> >> and know that it is hanging on that part. >> >> I would not misuse "service.print_msg" for regular messages, I would >> only do the >> >> service.print_msg("WARNING: Your system is running out of entropy, >> expect long delays!") >> >> others can be either turn into separate installation step or debug >> log message. >> >> Martin > > Hi, > according to personal discussion with Martin, see the corrected patch! > Thanks > Adam > ACK. Pushed to master: 71c6d2f1eb9610a0e0a994a6cfd78fdf9bb9d1fa Given that Adam no longer works in the Adam and cannot update the patch, I did couple very minor fixes - description is in the commit message. Martin From pviktori at redhat.com Tue May 27 11:27:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 May 2014 13:27:40 +0200 Subject: [Freeipa-devel] [PATCH] 0557 pwpolicy-mod: Fix crash when priority is changed Message-ID: <538476AC.5040500@redhat.com> See the ticket & commit message. https://fedorahosted.org/freeipa/ticket/4309 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0557-pwpolicy-mod-Fix-crash-when-priority-is-changed.patch Type: text/x-patch Size: 5134 bytes Desc: not available URL: From ssorce at redhat.com Tue May 27 12:16:24 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 08:16:24 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384707C.60705@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> Message-ID: <1401192984.7561.176.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: > On 05/27/2014 11:53 AM, Jan Cholasta wrote: > > On 27.5.2014 11:14, thierry bordaz wrote: > >> Hello, > >> > >> Me again !!! > >> > >> Thanks to all your inputs, the discussion about User_life_cycle > >> clarified a lot workflow/command verbs. > >> > >> Now I have a doubt about what would be an entry in staging > >> (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add > >> --stage), would be the only support way to create stage entry. > >> > >> An active entry is looking like (with krb* attributes if the > >> userpassword is defined): > >> > >> dn: > >> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >> displayName: tb15 tb15 > >> cn: tb15 tb15 > >> objectClass: top > >> objectClass: person > >> objectClass: organizationalperson > >> objectClass: inetorgperson > >> objectClass: inetuser > >> objectClass: posixaccount > >> objectClass: krbprincipalaux > >> objectClass: krbticketpolicyaux > >> objectClass: ipaobject > >> objectClass: ipasshuser > >> objectClass: ipaSshGroupOfPubKeys > >> objectClass: mepOriginEntry > >> loginShell: /bin/sh > >> gecos: tb15 tb15 > >> sn: tb15 > >> homeDirectory: /home/tb17 > >> uid: tb17 > >> mail: tb17 at idm.lab.bos.redhat.com > >> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM > >> givenName: tb15 > >> initials: tt > >> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd > >> uidNumber: 646400009 > >> gidNumber: 646400009 > >> mepManagedEntry: > >> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, > >> dc=com > >> memberOf: > >> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= > >> com > >> nsAccountLock: False > >> > >> > >> A staged entry created by 'ipa user-add --stage' may look like the > >> following. This kind of entry is easy to activate 'ipa user-unstage' > >> > >> dn: uid=tb20,cn=staged > >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >> dc=redhat,dc=com > >> displayName: tb20 tb20 > >> cn: tb20 tb20 > >> objectClass: top > >> objectClass: person > >> objectClass: organizationalperson > >> objectClass: inetorgperson > >> objectClass: inetuser > >> objectClass: posixaccount > >> objectClass: krbprincipalaux > >> objectClass: krbticketpolicyaux > >> objectClass: ipaobject > >> objectClass: ipasshuser > >> objectClass: ipaSshGroupOfPubKeys > >> loginShell: /bin/sh > >> uidNumber: -1 > >> ipaUniqueID: autogenerate > >> gidNumber: -1 > >> gecos: tb20 tb20 > >> sn: tb20 > >> homeDirectory: /home/tb20 > >> uid: tb20 > >> mail: tb20 at idm.lab.bos.redhat.com > >> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM > >> givenName: tb20 > >> initials: tt > >> nsAccountLock: True > >> > >> Now are we going to support the following entries for 'ipa user-unstage' > >> > >> dn: cn=tb20,cn=staged > >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >> dc=redhat,dc=com > >> objectClass: top > >> objectClass: person > >> sn: tb20 > >> cn: tb20 > >> nsAccountLock: True > >> > >> or > >> > >> dn: uid=tb20,cn=staged > >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >> dc=redhat,dc=com > >> objectClass: top > >> objectClass: person > >> objectClass: posixAccount > >> sn: tb20 > >> cn: tb20 tb20 > >> uid: tb20 > >> uidNumber: -1 > >> gidNumber: -1 > >> homeDirectory: /home/tb20 > >> nsAccountLock: True > >> > >> > >> thanks > >> thierry > > > > IIUC unstaging a user will do something like this: > > > > staged_user = ldap.get_entry(staged_dn, ['*']) > > api.Command.user_add(**staged_user) > > > > So IMO virtually any kind of entry should be supported in the staging tree. > > The workflow will be different from what Jan suggested, but yes, we should > support wide range of entries. I suspect some provisioning systems may even > write entries with different RDN - i.e. with CN for example. > > About the unstaging - we already spoke about it, we will need to consolidate > current operations in user-add and user-mod in common functions that will be > called by those commands and user-unstage command. > > I imagine user-unstage command would then do: > > 1) MODRDN from staged users to active users > 2) Update user with the same default as user-add, if RDN is different than UID, > it should be converted to UID > > I wonder how should be the step 2) authorized LDAP-wise. The easiest way to > make it happen is to give the operator making unstage operator write > permission/ACI to active users, but it may not be the ideal way - we would want > to limit the write permission only to the actual unstage operation of the > particular user... Simo, what is your take on this? My take is that users need to be created with uid= as the RDN or the operation should be refused. We have still some rules for what our users need to look like. Simo. From mkosek at redhat.com Tue May 27 12:19:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 14:19:32 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401192984.7561.176.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> Message-ID: <538482D4.1040503@redhat.com> On 05/27/2014 02:16 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: >> On 05/27/2014 11:53 AM, Jan Cholasta wrote: >>> On 27.5.2014 11:14, thierry bordaz wrote: >>>> Hello, >>>> >>>> Me again !!! >>>> >>>> Thanks to all your inputs, the discussion about User_life_cycle >>>> clarified a lot workflow/command verbs. >>>> >>>> Now I have a doubt about what would be an entry in staging >>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add >>>> --stage), would be the only support way to create stage entry. >>>> >>>> An active entry is looking like (with krb* attributes if the >>>> userpassword is defined): >>>> >>>> dn: >>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>> displayName: tb15 tb15 >>>> cn: tb15 tb15 >>>> objectClass: top >>>> objectClass: person >>>> objectClass: organizationalperson >>>> objectClass: inetorgperson >>>> objectClass: inetuser >>>> objectClass: posixaccount >>>> objectClass: krbprincipalaux >>>> objectClass: krbticketpolicyaux >>>> objectClass: ipaobject >>>> objectClass: ipasshuser >>>> objectClass: ipaSshGroupOfPubKeys >>>> objectClass: mepOriginEntry >>>> loginShell: /bin/sh >>>> gecos: tb15 tb15 >>>> sn: tb15 >>>> homeDirectory: /home/tb17 >>>> uid: tb17 >>>> mail: tb17 at idm.lab.bos.redhat.com >>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >>>> givenName: tb15 >>>> initials: tt >>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >>>> uidNumber: 646400009 >>>> gidNumber: 646400009 >>>> mepManagedEntry: >>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >>>> dc=com >>>> memberOf: >>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >>>> com >>>> nsAccountLock: False >>>> >>>> >>>> A staged entry created by 'ipa user-add --stage' may look like the >>>> following. This kind of entry is easy to activate 'ipa user-unstage' >>>> >>>> dn: uid=tb20,cn=staged >>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>> dc=redhat,dc=com >>>> displayName: tb20 tb20 >>>> cn: tb20 tb20 >>>> objectClass: top >>>> objectClass: person >>>> objectClass: organizationalperson >>>> objectClass: inetorgperson >>>> objectClass: inetuser >>>> objectClass: posixaccount >>>> objectClass: krbprincipalaux >>>> objectClass: krbticketpolicyaux >>>> objectClass: ipaobject >>>> objectClass: ipasshuser >>>> objectClass: ipaSshGroupOfPubKeys >>>> loginShell: /bin/sh >>>> uidNumber: -1 >>>> ipaUniqueID: autogenerate >>>> gidNumber: -1 >>>> gecos: tb20 tb20 >>>> sn: tb20 >>>> homeDirectory: /home/tb20 >>>> uid: tb20 >>>> mail: tb20 at idm.lab.bos.redhat.com >>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>> givenName: tb20 >>>> initials: tt >>>> nsAccountLock: True >>>> >>>> Now are we going to support the following entries for 'ipa user-unstage' >>>> >>>> dn: cn=tb20,cn=staged >>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>> dc=redhat,dc=com >>>> objectClass: top >>>> objectClass: person >>>> sn: tb20 >>>> cn: tb20 >>>> nsAccountLock: True >>>> >>>> or >>>> >>>> dn: uid=tb20,cn=staged >>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>> dc=redhat,dc=com >>>> objectClass: top >>>> objectClass: person >>>> objectClass: posixAccount >>>> sn: tb20 >>>> cn: tb20 tb20 >>>> uid: tb20 >>>> uidNumber: -1 >>>> gidNumber: -1 >>>> homeDirectory: /home/tb20 >>>> nsAccountLock: True >>>> >>>> >>>> thanks >>>> thierry >>> >>> IIUC unstaging a user will do something like this: >>> >>> staged_user = ldap.get_entry(staged_dn, ['*']) >>> api.Command.user_add(**staged_user) >>> >>> So IMO virtually any kind of entry should be supported in the staging tree. >> >> The workflow will be different from what Jan suggested, but yes, we should >> support wide range of entries. I suspect some provisioning systems may even >> write entries with different RDN - i.e. with CN for example. >> >> About the unstaging - we already spoke about it, we will need to consolidate >> current operations in user-add and user-mod in common functions that will be >> called by those commands and user-unstage command. >> >> I imagine user-unstage command would then do: >> >> 1) MODRDN from staged users to active users >> 2) Update user with the same default as user-add, if RDN is different than UID, >> it should be converted to UID >> >> I wonder how should be the step 2) authorized LDAP-wise. The easiest way to >> make it happen is to give the operator making unstage operator write >> permission/ACI to active users, but it may not be the ideal way - we would want >> to limit the write permission only to the actual unstage operation of the >> particular user... Simo, what is your take on this? > > My take is that users need to be created with uid= as the RDN or > the operation should be refused. We have still some rules for what our > users need to look like. > > Simo. Hm, I was more relaxed in my original RFE and allowed records like: dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson cn: Test User sn: User nsAccountLock: True RDN is just part of the problem though - note that the user-unstage command would also need to generate the default attributes for the user (including kerberos principal ones) - and we need to somehow authorize that LDAP modify operation. Martin From ssorce at redhat.com Tue May 27 12:22:54 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 08:22:54 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <538482D4.1040503@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> Message-ID: <1401193374.7561.178.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: > On 05/27/2014 02:16 PM, Simo Sorce wrote: > > On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: > >> On 05/27/2014 11:53 AM, Jan Cholasta wrote: > >>> On 27.5.2014 11:14, thierry bordaz wrote: > >>>> Hello, > >>>> > >>>> Me again !!! > >>>> > >>>> Thanks to all your inputs, the discussion about User_life_cycle > >>>> clarified a lot workflow/command verbs. > >>>> > >>>> Now I have a doubt about what would be an entry in staging > >>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add > >>>> --stage), would be the only support way to create stage entry. > >>>> > >>>> An active entry is looking like (with krb* attributes if the > >>>> userpassword is defined): > >>>> > >>>> dn: > >>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >>>> displayName: tb15 tb15 > >>>> cn: tb15 tb15 > >>>> objectClass: top > >>>> objectClass: person > >>>> objectClass: organizationalperson > >>>> objectClass: inetorgperson > >>>> objectClass: inetuser > >>>> objectClass: posixaccount > >>>> objectClass: krbprincipalaux > >>>> objectClass: krbticketpolicyaux > >>>> objectClass: ipaobject > >>>> objectClass: ipasshuser > >>>> objectClass: ipaSshGroupOfPubKeys > >>>> objectClass: mepOriginEntry > >>>> loginShell: /bin/sh > >>>> gecos: tb15 tb15 > >>>> sn: tb15 > >>>> homeDirectory: /home/tb17 > >>>> uid: tb17 > >>>> mail: tb17 at idm.lab.bos.redhat.com > >>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM > >>>> givenName: tb15 > >>>> initials: tt > >>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd > >>>> uidNumber: 646400009 > >>>> gidNumber: 646400009 > >>>> mepManagedEntry: > >>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, > >>>> dc=com > >>>> memberOf: > >>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= > >>>> com > >>>> nsAccountLock: False > >>>> > >>>> > >>>> A staged entry created by 'ipa user-add --stage' may look like the > >>>> following. This kind of entry is easy to activate 'ipa user-unstage' > >>>> > >>>> dn: uid=tb20,cn=staged > >>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>>> dc=redhat,dc=com > >>>> displayName: tb20 tb20 > >>>> cn: tb20 tb20 > >>>> objectClass: top > >>>> objectClass: person > >>>> objectClass: organizationalperson > >>>> objectClass: inetorgperson > >>>> objectClass: inetuser > >>>> objectClass: posixaccount > >>>> objectClass: krbprincipalaux > >>>> objectClass: krbticketpolicyaux > >>>> objectClass: ipaobject > >>>> objectClass: ipasshuser > >>>> objectClass: ipaSshGroupOfPubKeys > >>>> loginShell: /bin/sh > >>>> uidNumber: -1 > >>>> ipaUniqueID: autogenerate > >>>> gidNumber: -1 > >>>> gecos: tb20 tb20 > >>>> sn: tb20 > >>>> homeDirectory: /home/tb20 > >>>> uid: tb20 > >>>> mail: tb20 at idm.lab.bos.redhat.com > >>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM > >>>> givenName: tb20 > >>>> initials: tt > >>>> nsAccountLock: True > >>>> > >>>> Now are we going to support the following entries for 'ipa user-unstage' > >>>> > >>>> dn: cn=tb20,cn=staged > >>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>>> dc=redhat,dc=com > >>>> objectClass: top > >>>> objectClass: person > >>>> sn: tb20 > >>>> cn: tb20 > >>>> nsAccountLock: True > >>>> > >>>> or > >>>> > >>>> dn: uid=tb20,cn=staged > >>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>>> dc=redhat,dc=com > >>>> objectClass: top > >>>> objectClass: person > >>>> objectClass: posixAccount > >>>> sn: tb20 > >>>> cn: tb20 tb20 > >>>> uid: tb20 > >>>> uidNumber: -1 > >>>> gidNumber: -1 > >>>> homeDirectory: /home/tb20 > >>>> nsAccountLock: True > >>>> > >>>> > >>>> thanks > >>>> thierry > >>> > >>> IIUC unstaging a user will do something like this: > >>> > >>> staged_user = ldap.get_entry(staged_dn, ['*']) > >>> api.Command.user_add(**staged_user) > >>> > >>> So IMO virtually any kind of entry should be supported in the staging tree. > >> > >> The workflow will be different from what Jan suggested, but yes, we should > >> support wide range of entries. I suspect some provisioning systems may even > >> write entries with different RDN - i.e. with CN for example. > >> > >> About the unstaging - we already spoke about it, we will need to consolidate > >> current operations in user-add and user-mod in common functions that will be > >> called by those commands and user-unstage command. > >> > >> I imagine user-unstage command would then do: > >> > >> 1) MODRDN from staged users to active users > >> 2) Update user with the same default as user-add, if RDN is different than UID, > >> it should be converted to UID > >> > >> I wonder how should be the step 2) authorized LDAP-wise. The easiest way to > >> make it happen is to give the operator making unstage operator write > >> permission/ACI to active users, but it may not be the ideal way - we would want > >> to limit the write permission only to the actual unstage operation of the > >> particular user... Simo, what is your take on this? > > > > My take is that users need to be created with uid= as the RDN or > > the operation should be refused. We have still some rules for what our > > users need to look like. > > > > Simo. > > Hm, I was more relaxed in my original RFE and allowed records like: > > dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com > objectClass: top > objectClass: organizationalperson > cn: Test User > sn: User > nsAccountLock: True > > RDN is just part of the problem though - note that the user-unstage command > would also need to generate the default attributes for the user (including > kerberos principal ones) - and we need to somehow authorize that LDAP modify > operation. My idea was that we read the entry and create a new on in the user area, and once the operation is completed we delete the entry from the staging area. This way creating a user has always the same workflow from the framework pov, the staging are entry just "fills up the initial user creation form". Simo. From pvoborni at redhat.com Tue May 27 12:28:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 May 2014 14:28:22 +0200 Subject: [Freeipa-devel] Should normal user see his krbt and password policies? Message-ID: <538484E6.8010306@redhat.com> Recent removal of global read-only ACI affects current self-service page. Now it displays error dialog with two errors: * None: password policy not found * an internal error has occurred They are results of: * pwpolicy-show --user=username * krbtpolicy-show username commands. The second one is an obvious bug: https://fedorahosted.org/freeipa/ticket/4354 The question is whether normal user should see this information or not. If yes, we should fix default permissions. If not, we should fix Web UI. -- Petr Vobornik From jcholast at redhat.com Tue May 27 12:32:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 May 2014 14:32:06 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401193374.7561.178.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> Message-ID: <538485C6.3020207@redhat.com> On 27.5.2014 14:22, Simo Sorce wrote: > On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: >> On 05/27/2014 02:16 PM, Simo Sorce wrote: >>> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: >>>> On 05/27/2014 11:53 AM, Jan Cholasta wrote: >>>>> On 27.5.2014 11:14, thierry bordaz wrote: >>>>>> Hello, >>>>>> >>>>>> Me again !!! >>>>>> >>>>>> Thanks to all your inputs, the discussion about User_life_cycle >>>>>> clarified a lot workflow/command verbs. >>>>>> >>>>>> Now I have a doubt about what would be an entry in staging >>>>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add >>>>>> --stage), would be the only support way to create stage entry. >>>>>> >>>>>> An active entry is looking like (with krb* attributes if the >>>>>> userpassword is defined): >>>>>> >>>>>> dn: >>>>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>> displayName: tb15 tb15 >>>>>> cn: tb15 tb15 >>>>>> objectClass: top >>>>>> objectClass: person >>>>>> objectClass: organizationalperson >>>>>> objectClass: inetorgperson >>>>>> objectClass: inetuser >>>>>> objectClass: posixaccount >>>>>> objectClass: krbprincipalaux >>>>>> objectClass: krbticketpolicyaux >>>>>> objectClass: ipaobject >>>>>> objectClass: ipasshuser >>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>> objectClass: mepOriginEntry >>>>>> loginShell: /bin/sh >>>>>> gecos: tb15 tb15 >>>>>> sn: tb15 >>>>>> homeDirectory: /home/tb17 >>>>>> uid: tb17 >>>>>> mail: tb17 at idm.lab.bos.redhat.com >>>>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >>>>>> givenName: tb15 >>>>>> initials: tt >>>>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >>>>>> uidNumber: 646400009 >>>>>> gidNumber: 646400009 >>>>>> mepManagedEntry: >>>>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >>>>>> dc=com >>>>>> memberOf: >>>>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >>>>>> com >>>>>> nsAccountLock: False >>>>>> >>>>>> >>>>>> A staged entry created by 'ipa user-add --stage' may look like the >>>>>> following. This kind of entry is easy to activate 'ipa user-unstage' >>>>>> >>>>>> dn: uid=tb20,cn=staged >>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>> dc=redhat,dc=com >>>>>> displayName: tb20 tb20 >>>>>> cn: tb20 tb20 >>>>>> objectClass: top >>>>>> objectClass: person >>>>>> objectClass: organizationalperson >>>>>> objectClass: inetorgperson >>>>>> objectClass: inetuser >>>>>> objectClass: posixaccount >>>>>> objectClass: krbprincipalaux >>>>>> objectClass: krbticketpolicyaux >>>>>> objectClass: ipaobject >>>>>> objectClass: ipasshuser >>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>> loginShell: /bin/sh >>>>>> uidNumber: -1 >>>>>> ipaUniqueID: autogenerate >>>>>> gidNumber: -1 >>>>>> gecos: tb20 tb20 >>>>>> sn: tb20 >>>>>> homeDirectory: /home/tb20 >>>>>> uid: tb20 >>>>>> mail: tb20 at idm.lab.bos.redhat.com >>>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>>> givenName: tb20 >>>>>> initials: tt >>>>>> nsAccountLock: True >>>>>> >>>>>> Now are we going to support the following entries for 'ipa user-unstage' >>>>>> >>>>>> dn: cn=tb20,cn=staged >>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>> dc=redhat,dc=com >>>>>> objectClass: top >>>>>> objectClass: person >>>>>> sn: tb20 >>>>>> cn: tb20 >>>>>> nsAccountLock: True >>>>>> >>>>>> or >>>>>> >>>>>> dn: uid=tb20,cn=staged >>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>> dc=redhat,dc=com >>>>>> objectClass: top >>>>>> objectClass: person >>>>>> objectClass: posixAccount >>>>>> sn: tb20 >>>>>> cn: tb20 tb20 >>>>>> uid: tb20 >>>>>> uidNumber: -1 >>>>>> gidNumber: -1 >>>>>> homeDirectory: /home/tb20 >>>>>> nsAccountLock: True >>>>>> >>>>>> >>>>>> thanks >>>>>> thierry >>>>> >>>>> IIUC unstaging a user will do something like this: >>>>> >>>>> staged_user = ldap.get_entry(staged_dn, ['*']) >>>>> api.Command.user_add(**staged_user) >>>>> >>>>> So IMO virtually any kind of entry should be supported in the staging tree. >>>> >>>> The workflow will be different from what Jan suggested, but yes, we should >>>> support wide range of entries. I suspect some provisioning systems may even >>>> write entries with different RDN - i.e. with CN for example. >>>> >>>> About the unstaging - we already spoke about it, we will need to consolidate >>>> current operations in user-add and user-mod in common functions that will be >>>> called by those commands and user-unstage command. >>>> >>>> I imagine user-unstage command would then do: >>>> >>>> 1) MODRDN from staged users to active users >>>> 2) Update user with the same default as user-add, if RDN is different than UID, >>>> it should be converted to UID >>>> >>>> I wonder how should be the step 2) authorized LDAP-wise. The easiest way to >>>> make it happen is to give the operator making unstage operator write >>>> permission/ACI to active users, but it may not be the ideal way - we would want >>>> to limit the write permission only to the actual unstage operation of the >>>> particular user... Simo, what is your take on this? >>> >>> My take is that users need to be created with uid= as the RDN or >>> the operation should be refused. We have still some rules for what our >>> users need to look like. >>> >>> Simo. >> >> Hm, I was more relaxed in my original RFE and allowed records like: >> >> dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com >> objectClass: top >> objectClass: organizationalperson >> cn: Test User >> sn: User >> nsAccountLock: True >> >> RDN is just part of the problem though - note that the user-unstage command >> would also need to generate the default attributes for the user (including >> kerberos principal ones) - and we need to somehow authorize that LDAP modify >> operation. > > My idea was that we read the entry and create a new on in the user area, > and once the operation is completed we delete the entry from the staging > area. This way creating a user has always the same workflow from the > framework pov, the staging are entry just "fills up the initial user > creation form". +1, exactly what I thought it should do in my original comment. > > Simo. -- Jan Cholasta From tbordaz at redhat.com Tue May 27 12:40:28 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 14:40:28 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <538485C6.3020207@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> Message-ID: <538487BC.3070506@redhat.com> On 05/27/2014 02:32 PM, Jan Cholasta wrote: > On 27.5.2014 14:22, Simo Sorce wrote: >> On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: >>> On 05/27/2014 02:16 PM, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: >>>>> On 05/27/2014 11:53 AM, Jan Cholasta wrote: >>>>>> On 27.5.2014 11:14, thierry bordaz wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Me again !!! >>>>>>> >>>>>>> Thanks to all your inputs, the discussion about >>>>>>> User_life_cycle >>>>>>> clarified a lot workflow/command verbs. >>>>>>> >>>>>>> Now I have a doubt about what would be an entry in staging >>>>>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa >>>>>>> user-add >>>>>>> --stage), would be the only support way to create stage entry. >>>>>>> >>>>>>> An active entry is looking like (with krb* attributes if the >>>>>>> userpassword is defined): >>>>>>> >>>>>>> dn: >>>>>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>> displayName: tb15 tb15 >>>>>>> cn: tb15 tb15 >>>>>>> objectClass: top >>>>>>> objectClass: person >>>>>>> objectClass: organizationalperson >>>>>>> objectClass: inetorgperson >>>>>>> objectClass: inetuser >>>>>>> objectClass: posixaccount >>>>>>> objectClass: krbprincipalaux >>>>>>> objectClass: krbticketpolicyaux >>>>>>> objectClass: ipaobject >>>>>>> objectClass: ipasshuser >>>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>>> objectClass: mepOriginEntry >>>>>>> loginShell: /bin/sh >>>>>>> gecos: tb15 tb15 >>>>>>> sn: tb15 >>>>>>> homeDirectory: /home/tb17 >>>>>>> uid: tb17 >>>>>>> mail: tb17 at idm.lab.bos.redhat.com >>>>>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >>>>>>> givenName: tb15 >>>>>>> initials: tt >>>>>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >>>>>>> uidNumber: 646400009 >>>>>>> gidNumber: 646400009 >>>>>>> mepManagedEntry: >>>>>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >>>>>>> dc=com >>>>>>> memberOf: >>>>>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >>>>>>> >>>>>>> com >>>>>>> nsAccountLock: False >>>>>>> >>>>>>> >>>>>>> A staged entry created by 'ipa user-add --stage' may look >>>>>>> like the >>>>>>> following. This kind of entry is easy to activate 'ipa >>>>>>> user-unstage' >>>>>>> >>>>>>> dn: uid=tb20,cn=staged >>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>> dc=redhat,dc=com >>>>>>> displayName: tb20 tb20 >>>>>>> cn: tb20 tb20 >>>>>>> objectClass: top >>>>>>> objectClass: person >>>>>>> objectClass: organizationalperson >>>>>>> objectClass: inetorgperson >>>>>>> objectClass: inetuser >>>>>>> objectClass: posixaccount >>>>>>> objectClass: krbprincipalaux >>>>>>> objectClass: krbticketpolicyaux >>>>>>> objectClass: ipaobject >>>>>>> objectClass: ipasshuser >>>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>>> loginShell: /bin/sh >>>>>>> uidNumber: -1 >>>>>>> ipaUniqueID: autogenerate >>>>>>> gidNumber: -1 >>>>>>> gecos: tb20 tb20 >>>>>>> sn: tb20 >>>>>>> homeDirectory: /home/tb20 >>>>>>> uid: tb20 >>>>>>> mail: tb20 at idm.lab.bos.redhat.com >>>>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>>>> givenName: tb20 >>>>>>> initials: tt >>>>>>> nsAccountLock: True >>>>>>> >>>>>>> Now are we going to support the following entries for 'ipa >>>>>>> user-unstage' >>>>>>> >>>>>>> dn: cn=tb20,cn=staged >>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>> dc=redhat,dc=com >>>>>>> objectClass: top >>>>>>> objectClass: person >>>>>>> sn: tb20 >>>>>>> cn: tb20 >>>>>>> nsAccountLock: True >>>>>>> >>>>>>> or >>>>>>> >>>>>>> dn: uid=tb20,cn=staged >>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>> dc=redhat,dc=com >>>>>>> objectClass: top >>>>>>> objectClass: person >>>>>>> objectClass: posixAccount >>>>>>> sn: tb20 >>>>>>> cn: tb20 tb20 >>>>>>> uid: tb20 >>>>>>> uidNumber: -1 >>>>>>> gidNumber: -1 >>>>>>> homeDirectory: /home/tb20 >>>>>>> nsAccountLock: True >>>>>>> >>>>>>> >>>>>>> thanks >>>>>>> thierry >>>>>> >>>>>> IIUC unstaging a user will do something like this: >>>>>> >>>>>> staged_user = ldap.get_entry(staged_dn, ['*']) >>>>>> api.Command.user_add(**staged_user) >>>>>> >>>>>> So IMO virtually any kind of entry should be supported in the >>>>>> staging tree. >>>>> >>>>> The workflow will be different from what Jan suggested, but yes, >>>>> we should >>>>> support wide range of entries. I suspect some provisioning systems >>>>> may even >>>>> write entries with different RDN - i.e. with CN for example. >>>>> >>>>> About the unstaging - we already spoke about it, we will need to >>>>> consolidate >>>>> current operations in user-add and user-mod in common functions >>>>> that will be >>>>> called by those commands and user-unstage command. >>>>> >>>>> I imagine user-unstage command would then do: >>>>> >>>>> 1) MODRDN from staged users to active users >>>>> 2) Update user with the same default as user-add, if RDN is >>>>> different than UID, >>>>> it should be converted to UID >>>>> >>>>> I wonder how should be the step 2) authorized LDAP-wise. The >>>>> easiest way to >>>>> make it happen is to give the operator making unstage operator write >>>>> permission/ACI to active users, but it may not be the ideal way - >>>>> we would want >>>>> to limit the write permission only to the actual unstage operation >>>>> of the >>>>> particular user... Simo, what is your take on this? >>>> >>>> My take is that users need to be created with uid= as the RDN or >>>> the operation should be refused. We have still some rules for what our >>>> users need to look like. >>>> >>>> Simo. >>> >>> Hm, I was more relaxed in my original RFE and allowed records like: >>> >>> dn: cn=Test User,cn=staged >>> users,cn=accounts,cn=provisioning,dc=example,dc=com >>> objectClass: top >>> objectClass: organizationalperson >>> cn: Test User >>> sn: User >>> nsAccountLock: True >>> >>> RDN is just part of the problem though - note that the user-unstage >>> command >>> would also need to generate the default attributes for the user >>> (including >>> kerberos principal ones) - and we need to somehow authorize that >>> LDAP modify >>> operation. >> >> My idea was that we read the entry and create a new on in the user area, >> and once the operation is completed we delete the entry from the staging >> area. This way creating a user has always the same workflow from the >> framework pov, the staging are entry just "fills up the initial user >> creation form". > > +1, exactly what I thought it should do in my original comment. If we use staging entry as a template for a new active entry could be difficult with uniqueness plugin (uid, ipaUniqueid,...). If we want those plugin to have both containers in their scope, we need to delete the stage entry before creating the active one. > >> >> Simo. > > From tbordaz at redhat.com Tue May 27 12:59:02 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 14:59:02 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <538482D4.1040503@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> Message-ID: <53848C16.6070809@redhat.com> On 05/27/2014 02:19 PM, Martin Kosek wrote: > On 05/27/2014 02:16 PM, Simo Sorce wrote: >> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: >>> On 05/27/2014 11:53 AM, Jan Cholasta wrote: >>>> On 27.5.2014 11:14, thierry bordaz wrote: >>>>> Hello, >>>>> >>>>> Me again !!! >>>>> >>>>> Thanks to all your inputs, the discussion about User_life_cycle >>>>> clarified a lot workflow/command verbs. >>>>> >>>>> Now I have a doubt about what would be an entry in staging >>>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add >>>>> --stage), would be the only support way to create stage entry. >>>>> >>>>> An active entry is looking like (with krb* attributes if the >>>>> userpassword is defined): >>>>> >>>>> dn: >>>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>> displayName: tb15 tb15 >>>>> cn: tb15 tb15 >>>>> objectClass: top >>>>> objectClass: person >>>>> objectClass: organizationalperson >>>>> objectClass: inetorgperson >>>>> objectClass: inetuser >>>>> objectClass: posixaccount >>>>> objectClass: krbprincipalaux >>>>> objectClass: krbticketpolicyaux >>>>> objectClass: ipaobject >>>>> objectClass: ipasshuser >>>>> objectClass: ipaSshGroupOfPubKeys >>>>> objectClass: mepOriginEntry >>>>> loginShell: /bin/sh >>>>> gecos: tb15 tb15 >>>>> sn: tb15 >>>>> homeDirectory: /home/tb17 >>>>> uid: tb17 >>>>> mail: tb17 at idm.lab.bos.redhat.com >>>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >>>>> givenName: tb15 >>>>> initials: tt >>>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >>>>> uidNumber: 646400009 >>>>> gidNumber: 646400009 >>>>> mepManagedEntry: >>>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >>>>> dc=com >>>>> memberOf: >>>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >>>>> com >>>>> nsAccountLock: False >>>>> >>>>> >>>>> A staged entry created by 'ipa user-add --stage' may look like the >>>>> following. This kind of entry is easy to activate 'ipa user-unstage' >>>>> >>>>> dn: uid=tb20,cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>> dc=redhat,dc=com >>>>> displayName: tb20 tb20 >>>>> cn: tb20 tb20 >>>>> objectClass: top >>>>> objectClass: person >>>>> objectClass: organizationalperson >>>>> objectClass: inetorgperson >>>>> objectClass: inetuser >>>>> objectClass: posixaccount >>>>> objectClass: krbprincipalaux >>>>> objectClass: krbticketpolicyaux >>>>> objectClass: ipaobject >>>>> objectClass: ipasshuser >>>>> objectClass: ipaSshGroupOfPubKeys >>>>> loginShell: /bin/sh >>>>> uidNumber: -1 >>>>> ipaUniqueID: autogenerate >>>>> gidNumber: -1 >>>>> gecos: tb20 tb20 >>>>> sn: tb20 >>>>> homeDirectory: /home/tb20 >>>>> uid: tb20 >>>>> mail: tb20 at idm.lab.bos.redhat.com >>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>> givenName: tb20 >>>>> initials: tt >>>>> nsAccountLock: True >>>>> >>>>> Now are we going to support the following entries for 'ipa user-unstage' >>>>> >>>>> dn: cn=tb20,cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>> dc=redhat,dc=com >>>>> objectClass: top >>>>> objectClass: person >>>>> sn: tb20 >>>>> cn: tb20 >>>>> nsAccountLock: True >>>>> >>>>> or >>>>> >>>>> dn: uid=tb20,cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>> dc=redhat,dc=com >>>>> objectClass: top >>>>> objectClass: person >>>>> objectClass: posixAccount >>>>> sn: tb20 >>>>> cn: tb20 tb20 >>>>> uid: tb20 >>>>> uidNumber: -1 >>>>> gidNumber: -1 >>>>> homeDirectory: /home/tb20 >>>>> nsAccountLock: True >>>>> >>>>> >>>>> thanks >>>>> thierry >>>> IIUC unstaging a user will do something like this: >>>> >>>> staged_user = ldap.get_entry(staged_dn, ['*']) >>>> api.Command.user_add(**staged_user) >>>> >>>> So IMO virtually any kind of entry should be supported in the staging tree. >>> The workflow will be different from what Jan suggested, but yes, we should >>> support wide range of entries. I suspect some provisioning systems may even >>> write entries with different RDN - i.e. with CN for example. >>> >>> About the unstaging - we already spoke about it, we will need to consolidate >>> current operations in user-add and user-mod in common functions that will be >>> called by those commands and user-unstage command. >>> >>> I imagine user-unstage command would then do: >>> >>> 1) MODRDN from staged users to active users >>> 2) Update user with the same default as user-add, if RDN is different than UID, >>> it should be converted to UID >>> >>> I wonder how should be the step 2) authorized LDAP-wise. The easiest way to >>> make it happen is to give the operator making unstage operator write >>> permission/ACI to active users, but it may not be the ideal way - we would want >>> to limit the write permission only to the actual unstage operation of the >>> particular user... Simo, what is your take on this? >> My take is that users need to be created with uid= as the RDN or >> the operation should be refused. We have still some rules for what our >> users need to look like. >> >> Simo. > Hm, I was more relaxed in my original RFE and allowed records like: > > dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com > objectClass: top > objectClass: organizationalperson > cn: Test User > sn: User > nsAccountLock: True > > RDN is just part of the problem though - note that the user-unstage command > would also need to generate the default attributes for the user (including > kerberos principal ones) - and we need to somehow authorize that LDAP modify > operation. > > Martin In short, a large kind of entries should be supported in staging and we can not assum that provisioning in staging was done through FreeIPA CLI. Now if an entry was not created by FreeIPA CLI ('ipa user-add --stage') it could be impossible to update/unstage the entry with FreeIPA CLI . For example with those two entries. 'ipa user-mod TestUser --stage' or 'ipa user-unstage TestUser' are unable to select the correct entry # Created from provisioning system dn: cn=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson objectClass: posixAccount cn: Test User sn: User uid: xxx ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 nsAccountLock: True # Created from the FreeIPA CLI dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson objectClass: posixAccount cn: Test User sn: User uid: Test User ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 nsAccountLock: True -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Tue May 27 13:08:13 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 09:08:13 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <538487BC.3070506@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> Message-ID: <1401196093.7561.185.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote: > On 05/27/2014 02:32 PM, Jan Cholasta wrote: > > On 27.5.2014 14:22, Simo Sorce wrote: > >> On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: > >>> On 05/27/2014 02:16 PM, Simo Sorce wrote: > >>>> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: > >>>>> On 05/27/2014 11:53 AM, Jan Cholasta wrote: > >>>>>> On 27.5.2014 11:14, thierry bordaz wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Me again !!! > >>>>>>> > >>>>>>> Thanks to all your inputs, the discussion about > >>>>>>> User_life_cycle > >>>>>>> clarified a lot workflow/command verbs. > >>>>>>> > >>>>>>> Now I have a doubt about what would be an entry in staging > >>>>>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa > >>>>>>> user-add > >>>>>>> --stage), would be the only support way to create stage entry. > >>>>>>> > >>>>>>> An active entry is looking like (with krb* attributes if the > >>>>>>> userpassword is defined): > >>>>>>> > >>>>>>> dn: > >>>>>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >>>>>>> displayName: tb15 tb15 > >>>>>>> cn: tb15 tb15 > >>>>>>> objectClass: top > >>>>>>> objectClass: person > >>>>>>> objectClass: organizationalperson > >>>>>>> objectClass: inetorgperson > >>>>>>> objectClass: inetuser > >>>>>>> objectClass: posixaccount > >>>>>>> objectClass: krbprincipalaux > >>>>>>> objectClass: krbticketpolicyaux > >>>>>>> objectClass: ipaobject > >>>>>>> objectClass: ipasshuser > >>>>>>> objectClass: ipaSshGroupOfPubKeys > >>>>>>> objectClass: mepOriginEntry > >>>>>>> loginShell: /bin/sh > >>>>>>> gecos: tb15 tb15 > >>>>>>> sn: tb15 > >>>>>>> homeDirectory: /home/tb17 > >>>>>>> uid: tb17 > >>>>>>> mail: tb17 at idm.lab.bos.redhat.com > >>>>>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM > >>>>>>> givenName: tb15 > >>>>>>> initials: tt > >>>>>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd > >>>>>>> uidNumber: 646400009 > >>>>>>> gidNumber: 646400009 > >>>>>>> mepManagedEntry: > >>>>>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, > >>>>>>> dc=com > >>>>>>> memberOf: > >>>>>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= > >>>>>>> > >>>>>>> com > >>>>>>> nsAccountLock: False > >>>>>>> > >>>>>>> > >>>>>>> A staged entry created by 'ipa user-add --stage' may look > >>>>>>> like the > >>>>>>> following. This kind of entry is easy to activate 'ipa > >>>>>>> user-unstage' > >>>>>>> > >>>>>>> dn: uid=tb20,cn=staged > >>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>>>>>> dc=redhat,dc=com > >>>>>>> displayName: tb20 tb20 > >>>>>>> cn: tb20 tb20 > >>>>>>> objectClass: top > >>>>>>> objectClass: person > >>>>>>> objectClass: organizationalperson > >>>>>>> objectClass: inetorgperson > >>>>>>> objectClass: inetuser > >>>>>>> objectClass: posixaccount > >>>>>>> objectClass: krbprincipalaux > >>>>>>> objectClass: krbticketpolicyaux > >>>>>>> objectClass: ipaobject > >>>>>>> objectClass: ipasshuser > >>>>>>> objectClass: ipaSshGroupOfPubKeys > >>>>>>> loginShell: /bin/sh > >>>>>>> uidNumber: -1 > >>>>>>> ipaUniqueID: autogenerate > >>>>>>> gidNumber: -1 > >>>>>>> gecos: tb20 tb20 > >>>>>>> sn: tb20 > >>>>>>> homeDirectory: /home/tb20 > >>>>>>> uid: tb20 > >>>>>>> mail: tb20 at idm.lab.bos.redhat.com > >>>>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM > >>>>>>> givenName: tb20 > >>>>>>> initials: tt > >>>>>>> nsAccountLock: True > >>>>>>> > >>>>>>> Now are we going to support the following entries for 'ipa > >>>>>>> user-unstage' > >>>>>>> > >>>>>>> dn: cn=tb20,cn=staged > >>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>>>>>> dc=redhat,dc=com > >>>>>>> objectClass: top > >>>>>>> objectClass: person > >>>>>>> sn: tb20 > >>>>>>> cn: tb20 > >>>>>>> nsAccountLock: True > >>>>>>> > >>>>>>> or > >>>>>>> > >>>>>>> dn: uid=tb20,cn=staged > >>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>>>>>> dc=redhat,dc=com > >>>>>>> objectClass: top > >>>>>>> objectClass: person > >>>>>>> objectClass: posixAccount > >>>>>>> sn: tb20 > >>>>>>> cn: tb20 tb20 > >>>>>>> uid: tb20 > >>>>>>> uidNumber: -1 > >>>>>>> gidNumber: -1 > >>>>>>> homeDirectory: /home/tb20 > >>>>>>> nsAccountLock: True > >>>>>>> > >>>>>>> > >>>>>>> thanks > >>>>>>> thierry > >>>>>> > >>>>>> IIUC unstaging a user will do something like this: > >>>>>> > >>>>>> staged_user = ldap.get_entry(staged_dn, ['*']) > >>>>>> api.Command.user_add(**staged_user) > >>>>>> > >>>>>> So IMO virtually any kind of entry should be supported in the > >>>>>> staging tree. > >>>>> > >>>>> The workflow will be different from what Jan suggested, but yes, > >>>>> we should > >>>>> support wide range of entries. I suspect some provisioning systems > >>>>> may even > >>>>> write entries with different RDN - i.e. with CN for example. > >>>>> > >>>>> About the unstaging - we already spoke about it, we will need to > >>>>> consolidate > >>>>> current operations in user-add and user-mod in common functions > >>>>> that will be > >>>>> called by those commands and user-unstage command. > >>>>> > >>>>> I imagine user-unstage command would then do: > >>>>> > >>>>> 1) MODRDN from staged users to active users > >>>>> 2) Update user with the same default as user-add, if RDN is > >>>>> different than UID, > >>>>> it should be converted to UID > >>>>> > >>>>> I wonder how should be the step 2) authorized LDAP-wise. The > >>>>> easiest way to > >>>>> make it happen is to give the operator making unstage operator write > >>>>> permission/ACI to active users, but it may not be the ideal way - > >>>>> we would want > >>>>> to limit the write permission only to the actual unstage operation > >>>>> of the > >>>>> particular user... Simo, what is your take on this? > >>>> > >>>> My take is that users need to be created with uid= as the RDN or > >>>> the operation should be refused. We have still some rules for what our > >>>> users need to look like. > >>>> > >>>> Simo. > >>> > >>> Hm, I was more relaxed in my original RFE and allowed records like: > >>> > >>> dn: cn=Test User,cn=staged > >>> users,cn=accounts,cn=provisioning,dc=example,dc=com > >>> objectClass: top > >>> objectClass: organizationalperson > >>> cn: Test User > >>> sn: User > >>> nsAccountLock: True > >>> > >>> RDN is just part of the problem though - note that the user-unstage > >>> command > >>> would also need to generate the default attributes for the user > >>> (including > >>> kerberos principal ones) - and we need to somehow authorize that > >>> LDAP modify > >>> operation. > >> > >> My idea was that we read the entry and create a new on in the user area, > >> and once the operation is completed we delete the entry from the staging > >> area. This way creating a user has always the same workflow from the > >> framework pov, the staging are entry just "fills up the initial user > >> creation form". > > > > +1, exactly what I thought it should do in my original comment. > > If we use staging entry as a template for a new active entry could be > difficult with uniqueness plugin (uid, ipaUniqueid,...). ipaUniqueid will not be a problem, staging entries should not get one at all, or if they get one, we just ignore it in unstaging, and the new user gets a new one. uid uniqueness would be a problem if we enforce uniqueness in staging too. > If we want those plugin to have both containers in their scope, we need > to delete the stage entry before creating the active one. The issue with deleting in advance is that we risk to lose entries if we have a framework issue after we delete the entry but before we create a new one. I am thinking we may not want to enforce uniqueness over staging, though that could cause issues too, as the entry will have to be checked explicitly in advance, OTOH if you are using a staging process, then probably the provisioning system already have a way to create and enforce name uniqueness, so maybe it is not such a big deal ? Or alternatively that we create the new user with a RDN we rename after the staging entry is deleted; like: add uid=thierry-from-staging,cn=users,cn=accounts del uid=thierry,cn=users,cn=staging modrdn uid=thierry-from-staging -> uid=thierry I am not sure what is the best method, perhaps we should make a list of pros/cons an then decide. Simo. From ssorce at redhat.com Tue May 27 13:10:23 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 09:10:23 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <53848C16.6070809@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <53848C16.6070809@redhat.com> Message-ID: <1401196223.7561.187.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 14:59 +0200, thierry bordaz wrote: > Now if an entry was not created by FreeIPA CLI ('ipa user-add > --stage') it could be impossible to update/unstage the entry with > FreeIPA CLI . > For example with those two entries. 'ipa user-mod TestUser --stage' or > 'ipa user-unstage TestUser' are unable to select the correct entry > Keep in mind that use case #1 for the staging are is "non-freeipa" provisioning systems. So it is pretty much granted in the large majority of cases entries will not be created by freeipa tools, which is why I also do not want to "move" them, but only use them as templates for actual user creation. Simo. From mkosek at redhat.com Tue May 27 13:21:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 15:21:06 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401196093.7561.185.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> Message-ID: <53849142.8030709@redhat.com> On 05/27/2014 03:08 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote: >> On 05/27/2014 02:32 PM, Jan Cholasta wrote: >>> On 27.5.2014 14:22, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: >>>>> On 05/27/2014 02:16 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: >>>>>>> On 05/27/2014 11:53 AM, Jan Cholasta wrote: >>>>>>>> On 27.5.2014 11:14, thierry bordaz wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Me again !!! >>>>>>>>> >>>>>>>>> Thanks to all your inputs, the discussion about >>>>>>>>> User_life_cycle >>>>>>>>> clarified a lot workflow/command verbs. >>>>>>>>> >>>>>>>>> Now I have a doubt about what would be an entry in staging >>>>>>>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa >>>>>>>>> user-add >>>>>>>>> --stage), would be the only support way to create stage entry. >>>>>>>>> >>>>>>>>> An active entry is looking like (with krb* attributes if the >>>>>>>>> userpassword is defined): >>>>>>>>> >>>>>>>>> dn: >>>>>>>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>>>> displayName: tb15 tb15 >>>>>>>>> cn: tb15 tb15 >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> objectClass: organizationalperson >>>>>>>>> objectClass: inetorgperson >>>>>>>>> objectClass: inetuser >>>>>>>>> objectClass: posixaccount >>>>>>>>> objectClass: krbprincipalaux >>>>>>>>> objectClass: krbticketpolicyaux >>>>>>>>> objectClass: ipaobject >>>>>>>>> objectClass: ipasshuser >>>>>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>>>>> objectClass: mepOriginEntry >>>>>>>>> loginShell: /bin/sh >>>>>>>>> gecos: tb15 tb15 >>>>>>>>> sn: tb15 >>>>>>>>> homeDirectory: /home/tb17 >>>>>>>>> uid: tb17 >>>>>>>>> mail: tb17 at idm.lab.bos.redhat.com >>>>>>>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >>>>>>>>> givenName: tb15 >>>>>>>>> initials: tt >>>>>>>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >>>>>>>>> uidNumber: 646400009 >>>>>>>>> gidNumber: 646400009 >>>>>>>>> mepManagedEntry: >>>>>>>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >>>>>>>>> dc=com >>>>>>>>> memberOf: >>>>>>>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >>>>>>>>> >>>>>>>>> com >>>>>>>>> nsAccountLock: False >>>>>>>>> >>>>>>>>> >>>>>>>>> A staged entry created by 'ipa user-add --stage' may look >>>>>>>>> like the >>>>>>>>> following. This kind of entry is easy to activate 'ipa >>>>>>>>> user-unstage' >>>>>>>>> >>>>>>>>> dn: uid=tb20,cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>>>> dc=redhat,dc=com >>>>>>>>> displayName: tb20 tb20 >>>>>>>>> cn: tb20 tb20 >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> objectClass: organizationalperson >>>>>>>>> objectClass: inetorgperson >>>>>>>>> objectClass: inetuser >>>>>>>>> objectClass: posixaccount >>>>>>>>> objectClass: krbprincipalaux >>>>>>>>> objectClass: krbticketpolicyaux >>>>>>>>> objectClass: ipaobject >>>>>>>>> objectClass: ipasshuser >>>>>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>>>>> loginShell: /bin/sh >>>>>>>>> uidNumber: -1 >>>>>>>>> ipaUniqueID: autogenerate >>>>>>>>> gidNumber: -1 >>>>>>>>> gecos: tb20 tb20 >>>>>>>>> sn: tb20 >>>>>>>>> homeDirectory: /home/tb20 >>>>>>>>> uid: tb20 >>>>>>>>> mail: tb20 at idm.lab.bos.redhat.com >>>>>>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>>>>>> givenName: tb20 >>>>>>>>> initials: tt >>>>>>>>> nsAccountLock: True >>>>>>>>> >>>>>>>>> Now are we going to support the following entries for 'ipa >>>>>>>>> user-unstage' >>>>>>>>> >>>>>>>>> dn: cn=tb20,cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>>>> dc=redhat,dc=com >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> sn: tb20 >>>>>>>>> cn: tb20 >>>>>>>>> nsAccountLock: True >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> dn: uid=tb20,cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>>>> dc=redhat,dc=com >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> objectClass: posixAccount >>>>>>>>> sn: tb20 >>>>>>>>> cn: tb20 tb20 >>>>>>>>> uid: tb20 >>>>>>>>> uidNumber: -1 >>>>>>>>> gidNumber: -1 >>>>>>>>> homeDirectory: /home/tb20 >>>>>>>>> nsAccountLock: True >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> thierry >>>>>>>> >>>>>>>> IIUC unstaging a user will do something like this: >>>>>>>> >>>>>>>> staged_user = ldap.get_entry(staged_dn, ['*']) >>>>>>>> api.Command.user_add(**staged_user) >>>>>>>> >>>>>>>> So IMO virtually any kind of entry should be supported in the >>>>>>>> staging tree. >>>>>>> >>>>>>> The workflow will be different from what Jan suggested, but yes, >>>>>>> we should >>>>>>> support wide range of entries. I suspect some provisioning systems >>>>>>> may even >>>>>>> write entries with different RDN - i.e. with CN for example. >>>>>>> >>>>>>> About the unstaging - we already spoke about it, we will need to >>>>>>> consolidate >>>>>>> current operations in user-add and user-mod in common functions >>>>>>> that will be >>>>>>> called by those commands and user-unstage command. >>>>>>> >>>>>>> I imagine user-unstage command would then do: >>>>>>> >>>>>>> 1) MODRDN from staged users to active users >>>>>>> 2) Update user with the same default as user-add, if RDN is >>>>>>> different than UID, >>>>>>> it should be converted to UID >>>>>>> >>>>>>> I wonder how should be the step 2) authorized LDAP-wise. The >>>>>>> easiest way to >>>>>>> make it happen is to give the operator making unstage operator write >>>>>>> permission/ACI to active users, but it may not be the ideal way - >>>>>>> we would want >>>>>>> to limit the write permission only to the actual unstage operation >>>>>>> of the >>>>>>> particular user... Simo, what is your take on this? >>>>>> >>>>>> My take is that users need to be created with uid= as the RDN or >>>>>> the operation should be refused. We have still some rules for what our >>>>>> users need to look like. >>>>>> >>>>>> Simo. >>>>> >>>>> Hm, I was more relaxed in my original RFE and allowed records like: >>>>> >>>>> dn: cn=Test User,cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=example,dc=com >>>>> objectClass: top >>>>> objectClass: organizationalperson >>>>> cn: Test User >>>>> sn: User >>>>> nsAccountLock: True >>>>> >>>>> RDN is just part of the problem though - note that the user-unstage >>>>> command >>>>> would also need to generate the default attributes for the user >>>>> (including >>>>> kerberos principal ones) - and we need to somehow authorize that >>>>> LDAP modify >>>>> operation. >>>> >>>> My idea was that we read the entry and create a new on in the user area, >>>> and once the operation is completed we delete the entry from the staging >>>> area. This way creating a user has always the same workflow from the >>>> framework pov, the staging are entry just "fills up the initial user >>>> creation form". >>> >>> +1, exactly what I thought it should do in my original comment. >> >> If we use staging entry as a template for a new active entry could be >> difficult with uniqueness plugin (uid, ipaUniqueid,...). > > ipaUniqueid will not be a problem, staging entries should not get one at > all, or if they get one, we just ignore it in unstaging, and the new > user gets a new one. > > uid uniqueness would be a problem if we enforce uniqueness in staging > too. > >> If we want those plugin to have both containers in their scope, we need >> to delete the stage entry before creating the active one. > > The issue with deleting in advance is that we risk to lose entries if we > have a framework issue after we delete the entry but before we create a > new one. > > I am thinking we may not want to enforce uniqueness over staging, though > that could cause issues too, as the entry will have to be checked > explicitly in advance, OTOH if you are using a staging process, then > probably the provisioning system already have a way to create and > enforce name uniqueness, so maybe it is not such a big deal ? > > > Or alternatively that we create the new user with a RDN we rename after > the staging entry is deleted; like: > > add uid=thierry-from-staging,cn=users,cn=accounts > del uid=thierry,cn=users,cn=staging > modrdn uid=thierry-from-staging -> uid=thierry > > I am not sure what is the best method, perhaps we should make a list of > pros/cons an then decide. > > Simo. This topic was already discussed in the past, see following part of the design: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP One of the biggest concern was that to allow operator unstage a user, he would need to have a delete ACI in staging container AND add ACI in the active users area - which would also allow him to create any user he wishes in the users area. This is the reason why we preferred to do and control it via MODRDN and the reason why Thierry implemented the new ACI for controlling MODRDN operation: https://fedorahosted.org/389/ticket/47553 Martin From jcholast at redhat.com Tue May 27 13:23:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 May 2014 15:23:26 +0200 Subject: [Freeipa-devel] OTP Sync Client Design In-Reply-To: <1401121423.29756.2.camel@ipa.example.com> References: <1400090912.4568.13.camel@ipa.example.com> <1400879990.2513.23.camel@ipa.example.com> <5382F3B8.7030802@redhat.com> <1401121423.29756.2.camel@ipa.example.com> Message-ID: <538491CE.5070101@redhat.com> On 26.5.2014 18:23, Nathaniel McCallum wrote: > On Mon, 2014-05-26 at 09:56 +0200, Jan Cholasta wrote: >> On 23.5.2014 23:19, Nathaniel McCallum wrote: >>> On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: >>>> Occasionally OTP tokens get out of sync with the server. When this >>>> happens, the user or an admin need to synchronize the token. To this >>>> end, we landed server-side synchronization support, which is a simple >>>> bind with a custom control. This all works with my sample test script. >>>> >>>> Client support is proving a bit more difficult. In the ideal world, the >>>> client would contact LDAP directly and perform the operation. This would >>>> make a man in the middle attack difficult and we can ensure encryption >>>> over the entire operation. >>>> >>>> However, browsers, without server-side assistance, cannot perform this >>>> operation from javascript. This means that, in this case, the first >>>> factor and two second factors must be transmitted to the FreeIPA server >>>> and then proxied to 389. Is this an acceptable compromise? >>>> >>>> This command also needs to be accessible *without* an existing user >>>> login since, if a user's token is out of sync, the user can't login. Is >>>> it possible to expose such an API? If so, how? Both "ipa env" and "ipa >>>> ping" seem to require kinit, so I don't see any obvious examples. >>> >>> Thanks everyone for your feedback. This particular feature is proving >>> difficult to implement, even with our agreed upon design. To reiterate >>> this design: there will be an HTTP method by which to synchronize >>> tokens. >>> >>> There are two assumptions in the code which are making this difficult: >>> 1. All cli commands are Command subclasses. >>> 2. All Command subclasses create authenticated server methods. >>> >>> There are thus two ways to tackle this problem. >>> >>> First, I can create a standard POST method in rpcserver.py. This is not >>> very modular. But the biggest problem is that there is no way to create >>> the cli-side command to call it (assumption #1). >> >> Well, you could derive the command from ipalib.frontend.Local and >> manually call the POST method from it. > > This still creates a (NoOp) server-side RPC method, right? We can > probably just accept this as a drawback for now and move on. After a > future refactoring of rpcserver.py, we can move the manual POST method > into this server-side RPC method. I agree, I think there's no harm in having a placeholder RPC method. -- Jan Cholasta From tbordaz at redhat.com Tue May 27 13:24:31 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 15:24:31 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401196223.7561.187.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <53848C16.6070809@redhat.com> <1401196223.7561.187.camel@willson.li.ssimo.org> Message-ID: <5384920F.6030402@redhat.com> On 05/27/2014 03:10 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 14:59 +0200, thierry bordaz wrote: >> Now if an entry was not created by FreeIPA CLI ('ipa user-add >> --stage') it could be impossible to update/unstage the entry with >> FreeIPA CLI . >> For example with those two entries. 'ipa user-mod TestUser --stage' or >> 'ipa user-unstage TestUser' are unable to select the correct entry >> > Keep in mind that use case #1 for the staging are is "non-freeipa" > provisioning systems. So it is pretty much granted in the large majority > of cases entries will not be created by freeipa tools, which is why I > also do not want to "move" them, but only use them as templates for > actual user creation. > > Simo. > Ok. Good to know, I was thinking 'non-freeipa' provisioning to be a corner case and I was wrong it is the common case. Now to make a user active, 'ipa user-unstage tuser' will be the unique way. To be able to select the appropriate entry, I think we need to limit the RDN attribute to 'uid'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue May 27 13:38:10 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 15:38:10 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401196093.7561.185.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> Message-ID: <53849542.5090603@redhat.com> On 05/27/2014 03:08 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote: >> On 05/27/2014 02:32 PM, Jan Cholasta wrote: >>> On 27.5.2014 14:22, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: >>>>> On 05/27/2014 02:16 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: >>>>>>> On 05/27/2014 11:53 AM, Jan Cholasta wrote: >>>>>>>> On 27.5.2014 11:14, thierry bordaz wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Me again !!! >>>>>>>>> >>>>>>>>> Thanks to all your inputs, the discussion about >>>>>>>>> User_life_cycle >>>>>>>>> clarified a lot workflow/command verbs. >>>>>>>>> >>>>>>>>> Now I have a doubt about what would be an entry in staging >>>>>>>>> (objectclass/attribute). Also I wonder if ipa CLI (ipa >>>>>>>>> user-add >>>>>>>>> --stage), would be the only support way to create stage entry. >>>>>>>>> >>>>>>>>> An active entry is looking like (with krb* attributes if the >>>>>>>>> userpassword is defined): >>>>>>>>> >>>>>>>>> dn: >>>>>>>>> uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>>>>> displayName: tb15 tb15 >>>>>>>>> cn: tb15 tb15 >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> objectClass: organizationalperson >>>>>>>>> objectClass: inetorgperson >>>>>>>>> objectClass: inetuser >>>>>>>>> objectClass: posixaccount >>>>>>>>> objectClass: krbprincipalaux >>>>>>>>> objectClass: krbticketpolicyaux >>>>>>>>> objectClass: ipaobject >>>>>>>>> objectClass: ipasshuser >>>>>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>>>>> objectClass: mepOriginEntry >>>>>>>>> loginShell: /bin/sh >>>>>>>>> gecos: tb15 tb15 >>>>>>>>> sn: tb15 >>>>>>>>> homeDirectory: /home/tb17 >>>>>>>>> uid: tb17 >>>>>>>>> mail: tb17 at idm.lab.bos.redhat.com >>>>>>>>> krbPrincipalName: tb17 at IDM.LAB.BOS.REDHAT.COM >>>>>>>>> givenName: tb15 >>>>>>>>> initials: tt >>>>>>>>> ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd >>>>>>>>> uidNumber: 646400009 >>>>>>>>> gidNumber: 646400009 >>>>>>>>> mepManagedEntry: >>>>>>>>> cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, >>>>>>>>> dc=com >>>>>>>>> memberOf: >>>>>>>>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= >>>>>>>>> >>>>>>>>> com >>>>>>>>> nsAccountLock: False >>>>>>>>> >>>>>>>>> >>>>>>>>> A staged entry created by 'ipa user-add --stage' may look >>>>>>>>> like the >>>>>>>>> following. This kind of entry is easy to activate 'ipa >>>>>>>>> user-unstage' >>>>>>>>> >>>>>>>>> dn: uid=tb20,cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>>>> dc=redhat,dc=com >>>>>>>>> displayName: tb20 tb20 >>>>>>>>> cn: tb20 tb20 >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> objectClass: organizationalperson >>>>>>>>> objectClass: inetorgperson >>>>>>>>> objectClass: inetuser >>>>>>>>> objectClass: posixaccount >>>>>>>>> objectClass: krbprincipalaux >>>>>>>>> objectClass: krbticketpolicyaux >>>>>>>>> objectClass: ipaobject >>>>>>>>> objectClass: ipasshuser >>>>>>>>> objectClass: ipaSshGroupOfPubKeys >>>>>>>>> loginShell: /bin/sh >>>>>>>>> uidNumber: -1 >>>>>>>>> ipaUniqueID: autogenerate >>>>>>>>> gidNumber: -1 >>>>>>>>> gecos: tb20 tb20 >>>>>>>>> sn: tb20 >>>>>>>>> homeDirectory: /home/tb20 >>>>>>>>> uid: tb20 >>>>>>>>> mail: tb20 at idm.lab.bos.redhat.com >>>>>>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>>>>>> givenName: tb20 >>>>>>>>> initials: tt >>>>>>>>> nsAccountLock: True >>>>>>>>> >>>>>>>>> Now are we going to support the following entries for 'ipa >>>>>>>>> user-unstage' >>>>>>>>> >>>>>>>>> dn: cn=tb20,cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>>>> dc=redhat,dc=com >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> sn: tb20 >>>>>>>>> cn: tb20 >>>>>>>>> nsAccountLock: True >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> dn: uid=tb20,cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>>>>>> dc=redhat,dc=com >>>>>>>>> objectClass: top >>>>>>>>> objectClass: person >>>>>>>>> objectClass: posixAccount >>>>>>>>> sn: tb20 >>>>>>>>> cn: tb20 tb20 >>>>>>>>> uid: tb20 >>>>>>>>> uidNumber: -1 >>>>>>>>> gidNumber: -1 >>>>>>>>> homeDirectory: /home/tb20 >>>>>>>>> nsAccountLock: True >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> thierry >>>>>>>> IIUC unstaging a user will do something like this: >>>>>>>> >>>>>>>> staged_user = ldap.get_entry(staged_dn, ['*']) >>>>>>>> api.Command.user_add(**staged_user) >>>>>>>> >>>>>>>> So IMO virtually any kind of entry should be supported in the >>>>>>>> staging tree. >>>>>>> The workflow will be different from what Jan suggested, but yes, >>>>>>> we should >>>>>>> support wide range of entries. I suspect some provisioning systems >>>>>>> may even >>>>>>> write entries with different RDN - i.e. with CN for example. >>>>>>> >>>>>>> About the unstaging - we already spoke about it, we will need to >>>>>>> consolidate >>>>>>> current operations in user-add and user-mod in common functions >>>>>>> that will be >>>>>>> called by those commands and user-unstage command. >>>>>>> >>>>>>> I imagine user-unstage command would then do: >>>>>>> >>>>>>> 1) MODRDN from staged users to active users >>>>>>> 2) Update user with the same default as user-add, if RDN is >>>>>>> different than UID, >>>>>>> it should be converted to UID >>>>>>> >>>>>>> I wonder how should be the step 2) authorized LDAP-wise. The >>>>>>> easiest way to >>>>>>> make it happen is to give the operator making unstage operator write >>>>>>> permission/ACI to active users, but it may not be the ideal way - >>>>>>> we would want >>>>>>> to limit the write permission only to the actual unstage operation >>>>>>> of the >>>>>>> particular user... Simo, what is your take on this? >>>>>> My take is that users need to be created with uid= as the RDN or >>>>>> the operation should be refused. We have still some rules for what our >>>>>> users need to look like. >>>>>> >>>>>> Simo. >>>>> Hm, I was more relaxed in my original RFE and allowed records like: >>>>> >>>>> dn: cn=Test User,cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=example,dc=com >>>>> objectClass: top >>>>> objectClass: organizationalperson >>>>> cn: Test User >>>>> sn: User >>>>> nsAccountLock: True >>>>> >>>>> RDN is just part of the problem though - note that the user-unstage >>>>> command >>>>> would also need to generate the default attributes for the user >>>>> (including >>>>> kerberos principal ones) - and we need to somehow authorize that >>>>> LDAP modify >>>>> operation. >>>> My idea was that we read the entry and create a new on in the user area, >>>> and once the operation is completed we delete the entry from the staging >>>> area. This way creating a user has always the same workflow from the >>>> framework pov, the staging are entry just "fills up the initial user >>>> creation form". >>> +1, exactly what I thought it should do in my original comment. >> If we use staging entry as a template for a new active entry could be >> difficult with uniqueness plugin (uid, ipaUniqueid,...). > ipaUniqueid will not be a problem, staging entries should not get one at > all, or if they get one, we just ignore it in unstaging, and the new > user gets a new one. Yes I agree, scope of ipaUniqueId uniqueness should not look at 'stage'. Having ipaUniqueId depends on the entry objectclass. But I think 'uid' should be a mandatory RDN and if it is inherited from 'ipaObject' the entry will have 'ipaUniqueId'. > > uid uniqueness would be a problem if we enforce uniqueness in staging > too. It was the use case of 'John Doe' (uid=jdoe) being active/delete and a new stage user 'Jenny Doe' should be forced to pick up a different uid. So yes in my mind, uid scope should cover the full suffix. > >> If we want those plugin to have both containers in their scope, we need >> to delete the stage entry before creating the active one. > The issue with deleting in advance is that we risk to lose entries if we > have a framework issue after we delete the entry but before we create a > new one. > > I am thinking we may not want to enforce uniqueness over staging, though > that could cause issues too, as the entry will have to be checked > explicitly in advance, OTOH if you are using a staging process, then > probably the provisioning system already have a way to create and > enforce name uniqueness, so maybe it is not such a big deal ? > > > Or alternatively that we create the new user with a RDN we rename after > the staging entry is deleted; like: > > add uid=thierry-from-staging,cn=users,cn=accounts > del uid=thierry,cn=users,cn=staging > modrdn uid=thierry-from-staging -> uid=thierry > > I am not sure what is the best method, perhaps we should make a list of > pros/cons an then decide. > > Simo. > From pspacek at redhat.com Tue May 27 13:54:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 May 2014 15:54:02 +0200 Subject: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading Message-ID: <538498FA.7070609@redhat.com> Hello, Fix race condition during zone loading. DNS zone has to be added to DNS view before dns_zone_load() is called. It is necessary to prevent dns_zone_load() from racing with dns_zone_setview(). This race condition sometimes prevents zone from being signed. Now the unsigned zone is visible until signing process is complete. This mimics BIND behavior for in-line signed zones. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek From pspacek at redhat.com Tue May 27 13:59:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 May 2014 15:59:51 +0200 Subject: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading In-Reply-To: <538498FA.7070609@redhat.com> References: <538498FA.7070609@redhat.com> Message-ID: <53849A57.4040106@redhat.com> On 27.5.2014 15:54, Petr Spacek wrote: > Fix race condition during zone loading. > > DNS zone has to be added to DNS view before dns_zone_load() is called. > It is necessary to prevent dns_zone_load() from racing with dns_zone_setview(). > > This race condition sometimes prevents zone from being signed. > Now the unsigned zone is visible until signing process is complete. This > mimics BIND behavior for in-line signed zones. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 And here is the patch... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0257-Fix-race-condition-during-zone-loading.patch Type: text/x-patch Size: 5197 bytes Desc: not available URL: From sbose at redhat.com Tue May 27 14:01:41 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 27 May 2014 16:01:41 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140415091338.GE4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> Message-ID: <20140527140141.GA30381@localhost.localdomain> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > Hi, > > I have started to write a design page for 'Migrating existing > environments to Trust' > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > https://fedorahosted.org/freeipa/ticket/3979 . > while working on a new version of the page with more details on design and implementation I came across the following problem. On the IPA server there should be a way for SSSD to deliver unmodified data (no view applied) or views other than the one for the IPA server to processes which delivers user and group data to other clients. This are mainly the extdom and the compat plugin of dirsrv. The two currently use standard glibc calls like getpwnam_r() to get the needed data from SSSD. While they can read the view objects form the LDAP tree there is no way to read the original data for users from trusted domains because it is only in the cache of SSSD. I'm looking for a way to allow SSSD to deliver the data without changing the protocol used by the NSS responder. One way I can think of is to use a new socket like /var/lib/sss/pipes/nss_noview and create a small library for the extdom and compat plugin to use the new socket. With this the plugin have to apply the views on their own if needed. Another way would be a new command for the NSS responder with two arguments, the view name (or empty for unmodified data) and a blob which contains the data for the corresponding request like e.g. getpwnam_r() or getgrgid_r(). Here the plugins have to use some new calls but all view processing can happen in sssd and the plugins can deliver the data directly. A drawback in both cases is that the memcache cannot be used. If someone has suggestions for SSSD or other ways how to deliver user and group data to client with other views than the IPA server I'm all ears. bye, Sumit From pvoborni at redhat.com Tue May 27 14:10:45 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 May 2014 16:10:45 +0200 Subject: [Freeipa-devel] Should normal user see his krbt and password policies? In-Reply-To: <538484E6.8010306@redhat.com> References: <538484E6.8010306@redhat.com> Message-ID: <53849CE5.8000101@redhat.com> On 27.5.2014 14:28, Petr Vobornik wrote: > Recent removal of global read-only ACI affects current self-service page. > > Now it displays error dialog with two errors: > * None: password policy not found > * an internal error has occurred > > They are results of: > * pwpolicy-show --user=username > * krbtpolicy-show username > commands. > > The second one is an obvious bug: > https://fedorahosted.org/freeipa/ticket/4354 > > The question is whether normal user should see this information or not. > > If yes, we should fix default permissions. If not, we should fix Web UI. A ticket for Web UI was created since the user can also browse other users. https://fedorahosted.org/freeipa/ticket/4355 Nevertheless, the original question still stands. -- Petr Vobornik From mkosek at redhat.com Tue May 27 14:20:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 16:20:33 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <53835339.1040900@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> Message-ID: <53849F31.2050508@redhat.com> On 05/26/2014 04:44 PM, Petr Viktorin wrote: > On 05/22/2014 03:07 PM, Petr Viktorin wrote: >> Hello, >> Here I start upgrading the existing default permissions to the new >> Managed style. >> >> https://fedorahosted.org/freeipa/ticket/4346 >> >> The patches rely on my patch 0551 >> (https://fedorahosted.org/freeipa/ticket/4349) >> You may run into what seems to be a 389 bug. If you get a "Midair >> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >> ipa-ldap-updater again. I'm working with Ludwig on this one. >> >> >> >> The operation is now described at >> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >> >> >> >> If there user has modified an old default permission, a warning is >> logged the replacement permission is not added/updated. The user needs >> to evaluate the situation: either update the old permission to match the >> original default, or remove the old permission, and then run >> ipa-ldap-updater will create the new one. >> Is bailing out the right thing to do if the old entry was modified? Forcing user to remove old permission and create new one seems as a too much work to me. After the upgrade, we need to be sure that the managed permissions is there. What is the problem of having both 2 permissions in the DS? The old modified permission and the new system managed one? As we are dealing with allow permissions, having 2 of them should be harmless. >> It could be possible to parse the permission, figure out the changes the >> user made, and apply them to the new one, but that seems like too much >> guesswork to me. Maybe we could do the same we do with managed permissions upgrades? Only allow differences in the list of attributes? I am thinking that people could hotfix missing attributes at permissions themselves (like adding description to sudorule permission), this would lead to duplicate permissions later. What we could do when old ACI differs only in allowed attributes is to compare it to defaults and set whitelist and blacklist attributes of the new managed permission. Then we can safely delete the old ACI (with warning). If you think this is too much work, we can keep the old behavior and just add duplicate ACI. >> On the other hand, my approach has a downside as well: if the >> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's >> now no way to upgrade while allowing access but keeping that attribute >> off-limits, short of writing deny a ACI by hand. How big a problem is >> this? It might be worth it to create a special tool that upgrades a >> single permission and allows setting the excluded/included attributes >> explicitly. This problem would be removed with my approach proposed above. >> There are some interesting scenarios to think about with respect to >> upgrades and user changes: >> >> * Upgrade to old version, e.g. >> - have IPA 3.2 master, IPA 3.2 replica >> - upgrade master to 4.0 (old permissions are updated) >> - then upgrade replica to 3.3 (old permissions are added again!) >> >> This is AFAIK not supported but it does happen. >> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >> always add the old permissions, but with this patch, a subsequent >> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old >> permissions again. Hm, I think this is the best option we have. We should warn about this behavior in our release notes though. >> Tied to that is another scenario: >> >> * Re-create permissions with old names >> - have IPA 4.0 master >> - Create a permission named 'Modify Sudo rule' >> - Upgrade to IPA 4.1 >> >> Here we need to make sure the new permission is *not* removed, because a >> new 'Modify Sudo rule' permission is no longer special in any way. To >> ensure this the updater only removes old-style permissions. Right, we can decide based on objectclasses - whether permissionsv2 OC is there or not. >> >> One thing that can happen when 4.0 masters are still mixed with 3.x is >> that an old permission named 'Modify Sudo rule' is added on the old >> server. Any update to 4.0+ will remove that. >> Old-style default permissions were sorta-kinda managed by IPA itself >> anyway, so users should expect this. We should still point it out in the >> docs though, since I expect some users to start messing with the >> permissions before upgrading all of the infrastructure to 4.0. +1, I would just point out that behavior in the release notes. >> The second patch upgrades sudorule permissions, this server as an >> example of how the will work. >> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 > > The user read permissions patches had a conflict with these; attaching rebased > version. Now the actual review 552.2: worked fine for me. Some updates will probably be needed though, based on the discussion above. 553.2: 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? Looks like a noop to me, it was also never part of our add ACIs. I tried to strip that down to just "description" and I was still able to add a whole new SUDO rule. Ludwig, is that correct - does DS ignore (should it?) targetattr part of add ACI? 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it ineffective. Privileged user still cannot update all SUDO rule attributes. Besides that, the ACIs were working fine. Martin From ssorce at redhat.com Tue May 27 14:27:58 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 10:27:58 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <53849142.8030709@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> Message-ID: <1401200878.7561.193.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: > This topic was already discussed in the past, see following part of > the design: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP > > One of the biggest concern was that to allow operator unstage a user, > he would > need to have a delete ACI in staging container AND add ACI in the > active users > area - which would also allow him to create any user he wishes in the > users area. > > This is the reason why we preferred to do and control it via MODRDN > and the > reason why Thierry implemented the new ACI for controlling MODRDN > operation: > > https://fedorahosted.org/389/ticket/47553 > I know that's why we did it, but I had a hard look since then, and I believe we cannot really use that method. The reason is simply that we do not control who adds the user object and our reason to do the staging is to make it simple for an external provisioning system to create a basic user entry the way it knows how to, with only the attributes the provisioning system cares about. But this means we have no guarantee of what objectclasses are available on the object, so we have no guarantees all the necessary structureal objectclasses have been added in the staging object. We have to recreate the user object in order to be able to add all the right structural objectclasses as those can only be added at object creation time in an LDAPv3 compliant LDAP server. Recreating the object will also allow you to deal with the other case you brought forward where the provisioning system used CN as the RDN, but we want uid. I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue. Perhaps the best way is to create a new "proxy-API" to "promote" users from a staging area. This service will have the privilege to create users using its own credentials instead of those of the operator. This can be done later, meanwhile we will have to accept operators need the privilege to create users. Simo. From mkosek at redhat.com Tue May 27 14:35:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 May 2014 16:35:44 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401200878.7561.193.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> Message-ID: <5384A2C0.1050500@redhat.com> On 05/27/2014 04:27 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: >> This topic was already discussed in the past, see following part of >> the design: >> >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >> >> One of the biggest concern was that to allow operator unstage a user, >> he would >> need to have a delete ACI in staging container AND add ACI in the >> active users >> area - which would also allow him to create any user he wishes in the >> users area. >> >> This is the reason why we preferred to do and control it via MODRDN >> and the >> reason why Thierry implemented the new ACI for controlling MODRDN >> operation: >> >> https://fedorahosted.org/389/ticket/47553 >> > > I know that's why we did it, but I had a hard look since then, and I > believe we cannot really use that method. > > The reason is simply that we do not control who adds the user object and > our reason to do the staging is to make it simple for an external > provisioning system to create a basic user entry the way it knows how > to, with only the attributes the provisioning system cares about. > > But this means we have no guarantee of what objectclasses are available > on the object, so we have no guarantees all the necessary structureal > objectclasses have been added in the staging object. > > We have to recreate the user object in order to be able to add all the > right structural objectclasses as those can only be added at object > creation time in an LDAPv3 compliant LDAP server. > > Recreating the object will also allow you to deal with the other case > you brought forward where the provisioning system used CN as the RDN, > but we want uid. > > I understand it gives operators a higher privilege, but I think we'll > have to think harder how to properly handle the issue. > > Perhaps the best way is to create a new "proxy-API" to "promote" users > from a staging area. This service will have the privilege to create > users using its own credentials instead of those of the operator. > > This can be done later, meanwhile we will have to accept operators need > the privilege to create users. > > Simo. Ok, the point about structural objectclasses is a strong one. Thierry, you what to do - this should be noted in the design page... Martin From pviktori at redhat.com Tue May 27 14:56:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 May 2014 16:56:21 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <538313C2.7020007@redhat.com> References: <536012E1.6080702@redhat.com> <5375FC60.40708@redhat.com> <537621AB.4040103@redhat.com> <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> <538311AE.4090502@redhat.com> <538312C5.8000807@redhat.com> <538313C2.7020007@redhat.com> Message-ID: <5384A795.5090704@redhat.com> On 05/26/2014 12:13 PM, Petr Viktorin wrote: [...] > > Thanks for the thorough review! > Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 Okay guys, we have another issue: user-add (and the migration plugin) needs access to cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the originfilter for '(objectclass=disable)'. Do we want to give read access to all users, or just user admins? -- Petr? From abokovoy at redhat.com Tue May 27 15:01:54 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 May 2014 18:01:54 +0300 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <5384A795.5090704@redhat.com> References: <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> <538311AE.4090502@redhat.com> <538312C5.8000807@redhat.com> <538313C2.7020007@redhat.com> <5384A795.5090704@redhat.com> Message-ID: <20140527150154.GY23849@redhat.com> On Tue, 27 May 2014, Petr Viktorin wrote: >On 05/26/2014 12:13 PM, Petr Viktorin wrote: >[...] >> >>Thanks for the thorough review! >>Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 > > >Okay guys, we have another issue: >user-add (and the migration plugin) needs access to cn=UPG >Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the >originfilter for '(objectclass=disable)'. > >Do we want to give read access to all users, or just user admins? I would say user admins. If something more substantial fails, we'll extend the access. -- / Alexander Bokovoy From ssorce at redhat.com Tue May 27 15:13:16 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 11:13:16 -0400 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <20140527150154.GY23849@redhat.com> References: <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> <538311AE.4090502@redhat.com> <538312C5.8000807@redhat.com> <538313C2.7020007@redhat.com> <5384A795.5090704@redhat.com> <20140527150154.GY23849@redhat.com> Message-ID: <1401203596.2598.0.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 18:01 +0300, Alexander Bokovoy wrote: > On Tue, 27 May 2014, Petr Viktorin wrote: > >On 05/26/2014 12:13 PM, Petr Viktorin wrote: > >[...] > >> > >>Thanks for the thorough review! > >>Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 > > > > > >Okay guys, we have another issue: > >user-add (and the migration plugin) needs access to cn=UPG > >Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the > >originfilter for '(objectclass=disable)'. > > > >Do we want to give read access to all users, or just user admins? > I would say user admins. If something more substantial fails, we'll > extend the access. > ACK From tbordaz at redhat.com Tue May 27 15:55:21 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 17:55:21 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384A2C0.1050500@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> Message-ID: <5384B569.6080806@redhat.com> On 05/27/2014 04:35 PM, Martin Kosek wrote: > On 05/27/2014 04:27 PM, Simo Sorce wrote: >> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: >>> This topic was already discussed in the past, see following part of >>> the design: >>> >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>> >>> One of the biggest concern was that to allow operator unstage a user, >>> he would >>> need to have a delete ACI in staging container AND add ACI in the >>> active users >>> area - which would also allow him to create any user he wishes in the >>> users area. >>> >>> This is the reason why we preferred to do and control it via MODRDN >>> and the >>> reason why Thierry implemented the new ACI for controlling MODRDN >>> operation: >>> >>> https://fedorahosted.org/389/ticket/47553 >>> >> I know that's why we did it, but I had a hard look since then, and I >> believe we cannot really use that method. >> >> The reason is simply that we do not control who adds the user object and >> our reason to do the staging is to make it simple for an external >> provisioning system to create a basic user entry the way it knows how >> to, with only the attributes the provisioning system cares about. >> >> But this means we have no guarantee of what objectclasses are available >> on the object, so we have no guarantees all the necessary structureal >> objectclasses have been added in the staging object. >> >> We have to recreate the user object in order to be able to add all the >> right structural objectclasses as those can only be added at object >> creation time in an LDAPv3 compliant LDAP server. Both approach looks possible: * adding required structural OC+AT in the existing entry * creating a new entry with all structural OC+AT and update the AT values with what exists in the stage entry but I think the second one would be simpler to implement. Here again uid uniqueness is a difficulty: if 'uid' exists in stage entry we need to delete the stage entry before adding the active one. There is a risk to loose the entry if the add fails. Also it is important to apply DEL/ADD on the same replica so that DEL csn < ADD csn. >> >> Recreating the object will also allow you to deal with the other case >> you brought forward where the provisioning system used CN as the RDN, >> but we want uid. I am not sure: if some provisioning systems created the two entries # entry 1 dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: account uid: xxx ou: TestUser # entry 2 dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: posixAccount cn: TestUser uid: TestUser ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value. Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2. I think it would simplify the problem if we enforce that staged entries have 'uid' RDN. >> >> I understand it gives operators a higher privilege, but I think we'll >> have to think harder how to properly handle the issue. A possibility is to create a "pre-active" status, between 'stage' and 'active'. The 'stage' container contains raw provisioned entries. 'pre-active' a copy of the 'stage' entry with all the structural objectclasses. If 'pre-active' is out of the scope of uid uniqueness, we can add the 'pre-active' entry before removing the 'stage' entry (and rollback in case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' -> 'active'. >> >> Perhaps the best way is to create a new "proxy-API" to "promote" users >> from a staging area. This service will have the privilege to create >> users using its own credentials instead of those of the operator. >> >> This can be done later, meanwhile we will have to accept operators need >> the privilege to create users. >> >> Simo. > Ok, the point about structural objectclasses is a strong one. Thierry, you what > to do - this should be noted in the design page... > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Tue May 27 16:06:11 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 12:06:11 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384B569.6080806@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> Message-ID: <1401206771.2598.5.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote: > On 05/27/2014 04:35 PM, Martin Kosek wrote: > > On 05/27/2014 04:27 PM, Simo Sorce wrote: > >> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: > >>> This topic was already discussed in the past, see following part of > >>> the design: > >>> > >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP > >>> > >>> One of the biggest concern was that to allow operator unstage a user, > >>> he would > >>> need to have a delete ACI in staging container AND add ACI in the > >>> active users > >>> area - which would also allow him to create any user he wishes in the > >>> users area. > >>> > >>> This is the reason why we preferred to do and control it via MODRDN > >>> and the > >>> reason why Thierry implemented the new ACI for controlling MODRDN > >>> operation: > >>> > >>> https://fedorahosted.org/389/ticket/47553 > >>> > >> I know that's why we did it, but I had a hard look since then, and I > >> believe we cannot really use that method. > >> > >> The reason is simply that we do not control who adds the user object and > >> our reason to do the staging is to make it simple for an external > >> provisioning system to create a basic user entry the way it knows how > >> to, with only the attributes the provisioning system cares about. > >> > >> But this means we have no guarantee of what objectclasses are available > >> on the object, so we have no guarantees all the necessary structureal > >> objectclasses have been added in the staging object. > >> > >> We have to recreate the user object in order to be able to add all the > >> right structural objectclasses as those can only be added at object > >> creation time in an LDAPv3 compliant LDAP server. > Both approach looks possible: > > * adding required structural OC+AT in the existing entry > * creating a new entry with all structural OC+AT and update the AT > values with what exists in the stage entry > > but I think the second one would be simpler to implement. My assessment too. > Here again uid uniqueness is a difficulty: if 'uid' exists in stage > entry we need to delete the stage entry before adding the active one. > There is a risk to loose the entry if the add fails. Also it is > important to apply DEL/ADD on the same replica so that DEL csn < ADD csn. I think the solution is to not have the uid uniqueness plugin look into the staging tree. I think it is fair to put the burden of not creatoing conflicting uids in the provisioning system the drives creating the staged entries. If a staged entry has a conflicting uid then at unstaging time we will throw an error and the admin will have to fix the staged entry (either remove it and ask the provisioning people to re-provision, or modifying it). > >> Recreating the object will also allow you to deal with the other case > >> you brought forward where the provisioning system used CN as the RDN, > >> but we want uid. > > I am not sure: if some provisioning systems created the two entries > > # entry 1 > dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com > objectClass: top > objectClass: account > uid: xxx > ou: TestUser > > # entry 2 > dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com > objectClass: top > objectClass: posixAccount > cn: TestUser > uid: TestUser > ipaUniqueID: autogenerate > uidNumber: -1 > gidNumber: -1 > > > If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value. > Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2. > > I think it would simplify the problem if we enforce that staged entries have 'uid' RDN. To be honest I do not see the problem. We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. > >> I understand it gives operators a higher privilege, but I think we'll > >> have to think harder how to properly handle the issue. > A possibility is to create a "pre-active" status, between 'stage' and > 'active'. > The 'stage' container contains raw provisioned entries. 'pre-active' a > copy of the 'stage' entry with all the structural objectclasses. > > If 'pre-active' is out of the scope of uid uniqueness, we can add the > 'pre-active' entry before removing the 'stage' entry (and rollback in > case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' > -> 'active'. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. Simo. From tbordaz at redhat.com Tue May 27 16:39:48 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 18:39:48 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401206771.2598.5.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> Message-ID: <5384BFD4.3020307@redhat.com> On 05/27/2014 06:06 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote: >> On 05/27/2014 04:35 PM, Martin Kosek wrote: >>> On 05/27/2014 04:27 PM, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: >>>>> This topic was already discussed in the past, see following part of >>>>> the design: >>>>> >>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>>> >>>>> One of the biggest concern was that to allow operator unstage a user, >>>>> he would >>>>> need to have a delete ACI in staging container AND add ACI in the >>>>> active users >>>>> area - which would also allow him to create any user he wishes in the >>>>> users area. >>>>> >>>>> This is the reason why we preferred to do and control it via MODRDN >>>>> and the >>>>> reason why Thierry implemented the new ACI for controlling MODRDN >>>>> operation: >>>>> >>>>> https://fedorahosted.org/389/ticket/47553 >>>>> >>>> I know that's why we did it, but I had a hard look since then, and I >>>> believe we cannot really use that method. >>>> >>>> The reason is simply that we do not control who adds the user object and >>>> our reason to do the staging is to make it simple for an external >>>> provisioning system to create a basic user entry the way it knows how >>>> to, with only the attributes the provisioning system cares about. >>>> >>>> But this means we have no guarantee of what objectclasses are available >>>> on the object, so we have no guarantees all the necessary structureal >>>> objectclasses have been added in the staging object. >>>> >>>> We have to recreate the user object in order to be able to add all the >>>> right structural objectclasses as those can only be added at object >>>> creation time in an LDAPv3 compliant LDAP server. >> Both approach looks possible: >> >> * adding required structural OC+AT in the existing entry >> * creating a new entry with all structural OC+AT and update the AT >> values with what exists in the stage entry >> >> but I think the second one would be simpler to implement. > My assessment too. > >> Here again uid uniqueness is a difficulty: if 'uid' exists in stage >> entry we need to delete the stage entry before adding the active one. >> There is a risk to loose the entry if the add fails. Also it is >> important to apply DEL/ADD on the same replica so that DEL csn < ADD csn. > I think the solution is to not have the uid uniqueness plugin look into > the staging tree. I think it is fair to put the burden of not creatoing > conflicting uids in the provisioning system the drives creating the > staged entries. > > If a staged entry has a conflicting uid then at unstaging time we will > throw an error and the admin will have to fix the staged entry (either > remove it and ask the provisioning people to re-provision, or modifying > it). Ok great. > >>>> Recreating the object will also allow you to deal with the other case >>>> you brought forward where the provisioning system used CN as the RDN, >>>> but we want uid. >> I am not sure: if some provisioning systems created the two entries >> >> # entry 1 >> dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com >> objectClass: top >> objectClass: account >> uid: xxx >> ou: TestUser >> >> # entry 2 >> dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com >> objectClass: top >> objectClass: posixAccount >> cn: TestUser >> uid: TestUser >> ipaUniqueID: autogenerate >> uidNumber: -1 >> gidNumber: -1 >> >> >> If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value. >> Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2. >> >> I think it would simplify the problem if we enforce that staged entries have 'uid' RDN. > To be honest I do not see the problem. > > We just need to care about the 'uid' attribute in the staged entry, and > pick that to generate the RDN of the user in the active tree. If there > are conflicts the 'unstage' will fail cleanly, as the 'add' operation > will just fail (due to non unique RDN) and the admin will have to take > care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. > >>>> I understand it gives operators a higher privilege, but I think we'll >>>> have to think harder how to properly handle the issue. >> A possibility is to create a "pre-active" status, between 'stage' and >> 'active'. >> The 'stage' container contains raw provisioned entries. 'pre-active' a >> copy of the 'stage' entry with all the structural objectclasses. >> >> If 'pre-active' is out of the scope of uid uniqueness, we can add the >> 'pre-active' entry before removing the 'stage' entry (and rollback in >> case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' >> -> 'active'. > Sounds like a lot of complexity for a problem we do not really have, all > we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. > > Simo. > From ssorce at redhat.com Tue May 27 16:56:09 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 12:56:09 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384BFD4.3020307@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> Message-ID: <1401209769.2598.9.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: > On 05/27/2014 06:06 PM, Simo Sorce wrote: > > We just need to care about the 'uid' attribute in the staged entry, and > > pick that to generate the RDN of the user in the active tree. If there > > are conflicts the 'unstage' will fail cleanly, as the 'add' operation > > will just fail (due to non unique RDN) and the admin will have to take > > care of the situation. > In that case the provisioning system created a staging entry > ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE > It could be an issue for the provisioning system to retrieve the entry > it created. Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. > > Sounds like a lot of complexity for a problem we do not really have, all > > we need is to not enforce uniqueness in staging. > > This proposal was also to limit the operator privilege to do MODRDN from > 'pre-active' to 'active', instead ADD on 'active'. It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. Simo. From tbordaz at redhat.com Tue May 27 17:59:10 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 May 2014 19:59:10 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401209769.2598.9.camel@willson.li.ssimo.org> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> Message-ID: <5384D26E.5000802@redhat.com> On 05/27/2014 06:56 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>> We just need to care about the 'uid' attribute in the staged entry, and >>> pick that to generate the RDN of the user in the active tree. If there >>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>> will just fail (due to non unique RDN) and the admin will have to take >>> care of the situation. >> In that case the provisioning system created a staging entry >> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >> It could be an issue for the provisioning system to retrieve the entry >> it created. > Too bad for the provisioning system, we are not going to allow users to > have a form that does not use uid in the RDN in IPA. > >>> Sounds like a lot of complexity for a problem we do not really have, all >>> we need is to not enforce uniqueness in staging. >> This proposal was also to limit the operator privilege to do MODRDN from >> 'pre-active' to 'active', instead ADD on 'active'. > It is not useful, the operator still needs to be able to create in > pre-active ... so it can still create what it wants. yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? > > Simo. > From ssorce at redhat.com Tue May 27 18:08:34 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 14:08:34 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384D26E.5000802@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> Message-ID: <1401214114.2598.15.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: > On 05/27/2014 06:56 PM, Simo Sorce wrote: > > On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: > >> On 05/27/2014 06:06 PM, Simo Sorce wrote: > >>> We just need to care about the 'uid' attribute in the staged entry, and > >>> pick that to generate the RDN of the user in the active tree. If there > >>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation > >>> will just fail (due to non unique RDN) and the admin will have to take > >>> care of the situation. > >> In that case the provisioning system created a staging entry > >> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE > >> It could be an issue for the provisioning system to retrieve the entry > >> it created. > > Too bad for the provisioning system, we are not going to allow users to > > have a form that does not use uid in the RDN in IPA. > > > >>> Sounds like a lot of complexity for a problem we do not really have, all > >>> we need is to not enforce uniqueness in staging. > >> This proposal was also to limit the operator privilege to do MODRDN from > >> 'pre-active' to 'active', instead ADD on 'active'. > > It is not useful, the operator still needs to be able to create in > > pre-active ... so it can still create what it wants. > > yes that is correct. > Does it address the security concern, if the operator that is allowed to > add in 'staging'/'pre-active' is different from the one allowed to move > the entry in 'active' ? Well it really depends on 'who' the operator is. We would like to be able to allow a 'junior admin/helpdesk person' to just press a button to activate a user, but that shouldn't drive our design if it makes other things clumsy or suboptimal. The less privileged operator problem can always be solved by a middle-man script that has higher privileges. So we nee to give priority to getting the workflow right in terms of the way it works. I think re-creating the user object gives us better chances at handling the overall workflow and fixing up entries accordingly to the management framework view of what a user needs to look like, so in the end I prefer that route. Simo. From abokovoy at redhat.com Tue May 27 18:14:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 May 2014 21:14:45 +0300 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401214114.2598.15.camel@willson.li.ssimo.org> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> Message-ID: <20140527181445.GA10924@redhat.com> On Tue, 27 May 2014, Simo Sorce wrote: >On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >> On 05/27/2014 06:56 PM, Simo Sorce wrote: >> > On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >> >> On 05/27/2014 06:06 PM, Simo Sorce wrote: >> >>> We just need to care about the 'uid' attribute in the staged entry, and >> >>> pick that to generate the RDN of the user in the active tree. If there >> >>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >> >>> will just fail (due to non unique RDN) and the admin will have to take >> >>> care of the situation. >> >> In that case the provisioning system created a staging entry >> >> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >> >> It could be an issue for the provisioning system to retrieve the entry >> >> it created. >> > Too bad for the provisioning system, we are not going to allow users to >> > have a form that does not use uid in the RDN in IPA. >> > >> >>> Sounds like a lot of complexity for a problem we do not really have, all >> >>> we need is to not enforce uniqueness in staging. >> >> This proposal was also to limit the operator privilege to do MODRDN from >> >> 'pre-active' to 'active', instead ADD on 'active'. >> > It is not useful, the operator still needs to be able to create in >> > pre-active ... so it can still create what it wants. >> >> yes that is correct. >> Does it address the security concern, if the operator that is allowed to >> add in 'staging'/'pre-active' is different from the one allowed to move >> the entry in 'active' ? > >Well it really depends on 'who' the operator is. > >We would like to be able to allow a 'junior admin/helpdesk person' to >just press a button to activate a user, but that shouldn't drive our >design if it makes other things clumsy or suboptimal. > >The less privileged operator problem can always be solved by a >middle-man script that has higher privileges. So we nee to give priority >to getting the workflow right in terms of the way it works. > >I think re-creating the user object gives us better chances at handling >the overall workflow and fixing up entries accordingly to the management >framework view of what a user needs to look like, so in the end I prefer >that route. I agree. It also opens us a way to handle import of any foreign schema person if staged object uses extensibleObject object class where we are in control of what exactly will get into the actual tree. -- / Alexander Bokovoy From ssorce at redhat.com Tue May 27 18:18:34 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 14:18:34 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <20140527181445.GA10924@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> Message-ID: <1401214714.2598.17.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: > On Tue, 27 May 2014, Simo Sorce wrote: > >On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: > >> On 05/27/2014 06:56 PM, Simo Sorce wrote: > >> > On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: > >> >> On 05/27/2014 06:06 PM, Simo Sorce wrote: > >> >>> We just need to care about the 'uid' attribute in the staged entry, and > >> >>> pick that to generate the RDN of the user in the active tree. If there > >> >>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation > >> >>> will just fail (due to non unique RDN) and the admin will have to take > >> >>> care of the situation. > >> >> In that case the provisioning system created a staging entry > >> >> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE > >> >> It could be an issue for the provisioning system to retrieve the entry > >> >> it created. > >> > Too bad for the provisioning system, we are not going to allow users to > >> > have a form that does not use uid in the RDN in IPA. > >> > > >> >>> Sounds like a lot of complexity for a problem we do not really have, all > >> >>> we need is to not enforce uniqueness in staging. > >> >> This proposal was also to limit the operator privilege to do MODRDN from > >> >> 'pre-active' to 'active', instead ADD on 'active'. > >> > It is not useful, the operator still needs to be able to create in > >> > pre-active ... so it can still create what it wants. > >> > >> yes that is correct. > >> Does it address the security concern, if the operator that is allowed to > >> add in 'staging'/'pre-active' is different from the one allowed to move > >> the entry in 'active' ? > > > >Well it really depends on 'who' the operator is. > > > >We would like to be able to allow a 'junior admin/helpdesk person' to > >just press a button to activate a user, but that shouldn't drive our > >design if it makes other things clumsy or suboptimal. > > > >The less privileged operator problem can always be solved by a > >middle-man script that has higher privileges. So we nee to give priority > >to getting the workflow right in terms of the way it works. > > > >I think re-creating the user object gives us better chances at handling > >the overall workflow and fixing up entries accordingly to the management > >framework view of what a user needs to look like, so in the end I prefer > >that route. > I agree. It also opens us a way to handle import of any foreign schema > person if staged object uses extensibleObject object class where we are > in control of what exactly will get into the actual tree. Right it allows us to do things like filter out objectclass or attributes the provisioning system adds but that the admin does not want in the final entry. This is not something we may want to build into the solution from day zero, but it gives us the option to build it more easily, as a framework filter on the 'unstage' operation. (We so need to be able to copy additional objectclasses and their attributes from day 0 though). Simo. From jhrozek at redhat.com Tue May 27 18:23:33 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 27 May 2014 20:23:33 +0200 Subject: [Freeipa-devel] faster ways to build/test dogtag? In-Reply-To: <538466FE.5040500@redhat.com> References: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> <538466FE.5040500@redhat.com> Message-ID: <20140527182333.GS6330@hendrix.brq.redhat.com> On Tue, May 27, 2014 at 12:20:46PM +0200, Martin Kosek wrote: > On 05/27/2014 09:00 AM, Fraser Tweedale wrote: > > Hi all, > > > > I've been working on a fix for a profile issue > > (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I > > find the scripts/compose_pki_core_packages -> yum install -> test > > cycle frustratingly slow on idm.lab.bos. Is there a quicker way > > to build and test the software - particularly as part of the larger > > IPA/certmonger/dogtag ecosystem? > > > > Cheers, > > > > Fraser > > I am not sure about dogtag - you would need to ask on pki-devel mailing list. > > As for FreeIPA - I use a home-grown synchronization script that puts modified > python file in my local git directly into my test VM system so I do not need to > compile and install FreeIPA rpms every time. > > Martin Alternatively, I've been building RPMs locally (you can use ramdisk for added speed bonus) and then rsync-ed them to the target VM. From jhrozek at redhat.com Tue May 27 18:57:44 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 27 May 2014 20:57:44 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140527140141.GA30381@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> Message-ID: <20140527185744.GT6330@hendrix.brq.redhat.com> On Tue, May 27, 2014 at 04:01:41PM +0200, Sumit Bose wrote: > On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > > Hi, > > > > I have started to write a design page for 'Migrating existing > > environments to Trust' > > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > > https://fedorahosted.org/freeipa/ticket/3979 . > > > > while working on a new version of the page with more details on design > and implementation I came across the following problem. On the IPA > server there should be a way for SSSD to deliver unmodified data (no > view applied) or views other than the one for the IPA server to > processes which delivers user and group data to other clients. This are > mainly the extdom and the compat plugin of dirsrv. btw in the previous discussion, you proposed to get rid of the extdom plugin completely, is it still the plan? > > The two currently use standard glibc calls like getpwnam_r() to get the > needed data from SSSD. While they can read the view objects form the > LDAP tree there is no way to read the original data for users from > trusted domains because it is only in the cache of SSSD. > > I'm looking for a way to allow SSSD to deliver the data without changing > the protocol used by the NSS responder. > > One way I can think of is to use a new socket like > /var/lib/sss/pipes/nss_noview and create a small library for the extdom > and compat plugin to use the new socket. With this the plugin have to > apply the views on their own if needed. Can we have a separate memory cache for the original view (or per-view) in this case used by this new small library? Since the memory cache has a fixed size and it would be used by a single process only, we wouldn't risk growing the memory consumption too much.. The NSS responder would have to be aware of multiple memory caches, which might be ugly, though.. > > Another way would be a new command for the NSS responder with two > arguments, the view name (or empty for unmodified data) and a blob which > contains the data for the corresponding request like e.g. getpwnam_r() or > getgrgid_r(). Here the plugins have to use some new calls but all view > processing can happen in sssd and the plugins can deliver the data > directly. So there would be a special call in the nss client library (getpwnam_ipa()?) just for the server mode? Then I think the previous suggestion souds better to me, I think we should keep the current client library minimal and stable. > > A drawback in both cases is that the memcache cannot be used. > > If someone has suggestions for SSSD or other ways how to deliver user > and group data to client with other views than the IPA server I'm all > ears. > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Tue May 27 18:59:52 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 27 May 2014 14:59:52 -0400 Subject: [Freeipa-devel] [PATCH 0054] Change OTPSyncRequest structure to use OctetString Message-ID: <1401217192.29756.6.camel@ipa.example.com> This change has two motivations: 1. Clients don't have to parse the string. 2. Future token types may have new formats. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0054-Change-OTPSyncRequest-structure-to-use-OctetString.patch Type: text/x-patch Size: 9522 bytes Desc: not available URL: From simo at redhat.com Tue May 27 19:52:20 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 15:52:20 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140527140141.GA30381@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> Message-ID: <1401220340.2598.31.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: > On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > > Hi, > > > > I have started to write a design page for 'Migrating existing > > environments to Trust' > > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > > https://fedorahosted.org/freeipa/ticket/3979 . > > > > while working on a new version of the page with more details on design > and implementation I came across the following problem. On the IPA > server there should be a way for SSSD to deliver unmodified data (no > view applied) or views other than the one for the IPA server to > processes which delivers user and group data to other clients. This are > mainly the extdom and the compat plugin of dirsrv. > > The two currently use standard glibc calls like getpwnam_r() to get the > needed data from SSSD. While they can read the view objects form the > LDAP tree there is no way to read the original data for users from > trusted domains because it is only in the cache of SSSD. > > I'm looking for a way to allow SSSD to deliver the data without changing > the protocol used by the NSS responder. > > One way I can think of is to use a new socket like > /var/lib/sss/pipes/nss_noview and create a small library for the extdom > and compat plugin to use the new socket. With this the plugin have to > apply the views on their own if needed. > > Another way would be a new command for the NSS responder with two > arguments, the view name (or empty for unmodified data) and a blob which > contains the data for the corresponding request like e.g. getpwnam_r() or > getgrgid_r(). Here the plugins have to use some new calls but all view > processing can happen in sssd and the plugins can deliver the data > directly. > > A drawback in both cases is that the memcache cannot be used. > > If someone has suggestions for SSSD or other ways how to deliver user > and group data to client with other views than the IPA server I'm all > ears. Ok this one is hard to deal with in a way that will satisfy every possible user. I think what we need to aim is simplicity and predictability at the expense of flexibility. What I mean is that freeipa servers should be allowed to only stick to one view, the default view for external users. And then the extdom plugin will be allowed to overlay a different view for specific clients. But the default view is the baseline, no special behavior. If you need to 're'-override some attributes in specific views, so be it. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue May 27 19:57:54 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 May 2014 15:57:54 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140527185744.GT6330@hendrix.brq.redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <20140527185744.GT6330@hendrix.brq.redhat.com> Message-ID: <1401220674.2598.34.camel@willson.li.ssimo.org> On Tue, 2014-05-27 at 20:57 +0200, Jakub Hrozek wrote: > On Tue, May 27, 2014 at 04:01:41PM +0200, Sumit Bose wrote: > > On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > > > Hi, > > > > > > I have started to write a design page for 'Migrating existing > > > environments to Trust' > > > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > > > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > > > https://fedorahosted.org/freeipa/ticket/3979 . > > > > > > > while working on a new version of the page with more details on design > > and implementation I came across the following problem. On the IPA > > server there should be a way for SSSD to deliver unmodified data (no > > view applied) or views other than the one for the IPA server to > > processes which delivers user and group data to other clients. This are > > mainly the extdom and the compat plugin of dirsrv. > > btw in the previous discussion, you proposed to get rid of the extdom > plugin completely, is it still the plan? Is this possible at all ? We'd break existing clients that rely on it. > > The two currently use standard glibc calls like getpwnam_r() to get the > > needed data from SSSD. While they can read the view objects form the > > LDAP tree there is no way to read the original data for users from > > trusted domains because it is only in the cache of SSSD. > > > > I'm looking for a way to allow SSSD to deliver the data without changing > > the protocol used by the NSS responder. > > > > One way I can think of is to use a new socket like > > /var/lib/sss/pipes/nss_noview and create a small library for the extdom > > and compat plugin to use the new socket. With this the plugin have to > > apply the views on their own if needed. > > Can we have a separate memory cache for the original view (or per-view) > in this case used by this new small library? Since the memory cache has > a fixed size and it would be used by a single process only, we wouldn't > risk growing the memory consumption too much.. > > The NSS responder would have to be aware of multiple memory caches, > which might be ugly, though.. no see my other reply, at most we can get a cache in extdom if we really care, but we shouldn't have special behavior in sssd for this feature. One server has one canonical view, and IPA server should be bound to the default view and not be able to be configured to use any other 'view'. In other words, 'views' are really only for ipa clients, not for the servers themselves. > > > > Another way would be a new command for the NSS responder with two > > arguments, the view name (or empty for unmodified data) and a blob which > > contains the data for the corresponding request like e.g. getpwnam_r() or > > getgrgid_r(). Here the plugins have to use some new calls but all view > > processing can happen in sssd and the plugins can deliver the data > > directly. > > So there would be a special call in the nss client library > (getpwnam_ipa()?) just for the server mode? Then I think the previous > suggestion souds better to me, I think we should keep the current client > library minimal and stable. I am against it indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York From alee at redhat.com Tue May 27 21:57:40 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 27 May 2014 17:57:40 -0400 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <1399693089.26524.14.camel@aleeredhat.laptop> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> <1399693089.26524.14.camel@aleeredhat.laptop> Message-ID: <1401227860.9297.9.camel@aleeredhat.laptop> There have been a couple of changes in the Dogtag interface, that require some changes in the IPA patches. Also, I had to add back a function in order to rebase to the latest IPA code. Most are the patches are as before, attached to this email by default. The latest Dogtag 10.2 build with the relevant changes needed to work with these patches is at: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ Ade On Fri, 2014-05-09 at 23:38 -0400, Ade Lee wrote: > Attached is patch 6-1, which addresses the issues listed below. > In addition, there are two additional patches which : > > 7. disable the automatic install of the DRM in ipa-server-install as > decided until Dogtag 10.2 is available. > > 8. Add the ability to install a DRM replica using ipa-drm-install. > > The install procedure is now as follows: > > On Master: > 1. ipa-server-install (installs ipa and dogtag CA) > 2. ipa-drm-install (installs drm) > 3. ipa-replica-prepare > > On clone: > 1. ipa-replica-install (installs ipa replica) > 2. ipa-ca-install (installs replica ca) > 3. ipa-drm-install > > On the clone, if you fail to add a replica_file, the install scripts > will detect that a DRM has been installed in the security domain, and > prompt for a replica file. > > For this all to work, you will need the newest version of Dogtag 10.2 - > which contains fixes that are not yet checked into Dogtag. A build can > be found at: > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo > > Ade > > Note: For convenience, all the DRM patches have been appended to this > email. > > On Thu, 2014-05-01 at 14:55 -0400, Rob Crittenden wrote: > > Ade Lee wrote: > > > I have attached a patch that contains code for the new dogtag DRM plugin > > > vault functionality. This patch should be applied on top of the ones > > > used to install a DRM. > > > > > > Forthcoming is a patch to actually start using this plugin. > > > > All the imports should be at the top of the file. > > > done. > > > In _create_pem_file there is a ipaserver.install.certs.export_pkcs12() > > that you can re-use. Similarly install_pem_from_p12() probably does the > > same thing, and your copy doesn't take the PKCS#12 password as input AFAICT. > > > done. > > In _transport_cert_present you can use: > > > > from ipaserver.install import certs > > > > db = certs.CertDB(self.realm, nssdir=self.sec_dir) > > return db.has_nickname(self.transport_nick) > > > done. > > Should there be error handling around keyclient calls or will that be > > handled at a different level? > > > I think the keyclient calls should throw exceptions and the error > handling should be performed at a higher level. We can revisit this when > we write the code that calls this plugin. > > > Incidentally, installing a replica on F-20 with pki-ca-10.2.0-0.1 > > against an F-20 master with pki-ca-10.1.1-1 fails with this traceback in > > pkispawn: > > > > File "/usr/sbin/pkispawn", line 514, in > > main(sys.argv) > > File "/usr/sbin/pkispawn", line 423, in main > > info = parser.sd_get_info() > > File > > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", > > line 463, in sd_get_info > > info = sd.getSecurityDomainInfo() > > File "/usr/lib/python2.7/site-packages/pki/system.py", line 44, in > > getSecurityDomainInfo > > info.name = response.json()['id'] > > KeyError: 'id' > > > I'll have to look into this. Will fix in another patch. This will be a > dogtag patch though. > > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 73390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Added-ipa-drm-install.patch Type: text/x-patch Size: 22704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Added-nolog-to-pkispawn-and-some-additional-fixes-fr.patch Type: text/x-patch Size: 13199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-various-pep-8-issues-and-comments-from-review.patch Type: text/x-patch Size: 31467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-1-Added-dogtag-plugin-for-DRM.patch Type: text/x-patch Size: 23333 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Allow-ipa-replica-install-to-be-used-for-installing-.patch Type: text/x-patch Size: 19638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-set-drm-to-not-install-by-default-with-ipa-server-in.patch Type: text/x-patch Size: 1082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Formatting-fixes-and-change-in-security-domain-api.patch Type: text/x-patch Size: 10208 bytes Desc: not available URL: From mkosek at redhat.com Wed May 28 06:22:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 08:22:26 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401214714.2598.17.camel@willson.li.ssimo.org> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> Message-ID: <538580A2.60508@redhat.com> On 05/27/2014 08:18 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >> On Tue, 27 May 2014, Simo Sorce wrote: >>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>> care of the situation. >>>>>> In that case the provisioning system created a staging entry >>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>> it created. >>>>> Too bad for the provisioning system, we are not going to allow users to >>>>> have a form that does not use uid in the RDN in IPA. >>>>> >>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>> we need is to not enforce uniqueness in staging. >>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>> It is not useful, the operator still needs to be able to create in >>>>> pre-active ... so it can still create what it wants. >>>> >>>> yes that is correct. >>>> Does it address the security concern, if the operator that is allowed to >>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>> the entry in 'active' ? >>> >>> Well it really depends on 'who' the operator is. >>> >>> We would like to be able to allow a 'junior admin/helpdesk person' to >>> just press a button to activate a user, but that shouldn't drive our >>> design if it makes other things clumsy or suboptimal. >>> >>> The less privileged operator problem can always be solved by a >>> middle-man script that has higher privileges. So we nee to give priority >>> to getting the workflow right in terms of the way it works. >>> >>> I think re-creating the user object gives us better chances at handling >>> the overall workflow and fixing up entries accordingly to the management >>> framework view of what a user needs to look like, so in the end I prefer >>> that route. >> I agree. It also opens us a way to handle import of any foreign schema >> person if staged object uses extensibleObject object class where we are >> in control of what exactly will get into the actual tree. > > Right it allows us to do things like filter out objectclass or > attributes the provisioning system adds but that the admin does not want > in the final entry. This is not something we may want to build into the > solution from day zero, but it gives us the option to build it more > easily, as a framework filter on the 'unstage' operation. > (We so need to be able to copy additional objectclasses and their > attributes from day 0 though). > Simo. Ok, thanks guys, I see an agreement. Thierry, we should now update all the information here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP (you can even link this thread in the archives) Martin From ftweedal at redhat.com Wed May 28 06:48:18 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 28 May 2014 16:48:18 +1000 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <1401227860.9297.9.camel@aleeredhat.laptop> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> <1399693089.26524.14.camel@aleeredhat.laptop> <1401227860.9297.9.camel@aleeredhat.laptop> Message-ID: <20140528064818.GE28407@dhcp-40-8.bne.redhat.com> On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote: > There have been a couple of changes in the Dogtag interface, that > require some changes in the IPA patches. Also, I had to add back a > function in order to rebase to the latest IPA code. > > Most are the patches are as before, attached to this email by default. > > The latest Dogtag 10.2 build with the relevant changes needed to work > with these patches is at: > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ > > Ade > ACK. ipa-server-install worked fine for me, and the formatting changes seem good. Patch 0003 did not apply cleanly on master (due to minor conflict in 71c6d2f:installutils.py); an updated patch 0003 is attached. -------------- next part -------------- >From d4bd77e498156a976a81bf6c166069087bcb4d8a Mon Sep 17 00:00:00 2001 From: Ade Lee Date: Tue, 15 Apr 2014 14:09:32 -0400 Subject: [PATCH] Added ipa-drm-install ipa-drm-install can be used (with no arguments) to add a DRM to an existing ipa instance that already contains a Dogtag CA. In a subsequent patch, I will add logic to this script to detect if a drm naming context exists, and if so, to look for a replica file for installing on a replica. --- freeipa.spec.in | 2 + install/po/Makefile.in | 1 + install/tools/Makefile.am | 1 + install/tools/ipa-dns-install | 1 + install/tools/ipa-drm-install | 196 ++++++++++++++++++++++++++++++++++++++ install/tools/ipa-upgradeconfig | 67 +------------ ipaserver/install/drminstance.py | 4 + ipaserver/install/dsinstance.py | 77 +++++++++++++++ ipaserver/install/installutils.py | 23 +++-- 9 files changed, 296 insertions(+), 76 deletions(-) create mode 100644 install/tools/ipa-drm-install diff --git a/freeipa.spec.in b/freeipa.spec.in index 7ed989ec33a423646a5a3925894b52b85b101ec9..98782477857830d184aa48fb3792a94bf223b749 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -145,6 +145,7 @@ Requires: selinux-policy >= 3.12.1-135 Requires(post): selinux-policy-base Requires: slapi-nis >= 0.47.7 Requires: pki-ca >= 10.1.1 +Requires: pki-kra >= 10.1.1 Requires: dogtag-pki-server-theme %if 0%{?rhel} Requires: subscription-manager @@ -646,6 +647,7 @@ fi %{_sbindir}/ipa-restore %{_sbindir}/ipa-ca-install %{_sbindir}/ipa-dns-install +%{_sbindir}/ipa-drm-install %{_sbindir}/ipa-server-install %{_sbindir}/ipa-replica-conncheck %{_sbindir}/ipa-replica-install diff --git a/install/po/Makefile.in b/install/po/Makefile.in index 6dca615c13acf8d40030da0318a1103f4ece1181..c8d7b6353e2b2b00f6e9e6f8cfe3bcc8f84ae73f 100644 --- a/install/po/Makefile.in +++ b/install/po/Makefile.in @@ -47,6 +47,7 @@ PY_EXPLICIT_FILES = \ install/tools/ipa-csreplica-manage \ install/tools/ipactl \ install/tools/ipa-dns-install \ + install/tools/ipa-drm-install \ install/tools/ipa-ldap-updater \ install/tools/ipa-managed-entries \ install/tools/ipa-nis-manage \ diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am index 2cf66c6dfc1c272bb423253902e7339e7d159567..7f8e4a5a0217327662b57921314fcb03f60dc46c 100644 --- a/install/tools/Makefile.am +++ b/install/tools/Makefile.am @@ -7,6 +7,7 @@ SUBDIRS = \ sbin_SCRIPTS = \ ipa-ca-install \ ipa-dns-install \ + ipa-drm-install \ ipa-server-install \ ipa-adtrust-install \ ipa-replica-conncheck \ diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install index 78acc2d9bce02203cc97346b8797ec3ae40a3044..4684416685c06b919f3750f7a6cb064286b3b76d 100755 --- a/install/tools/ipa-dns-install +++ b/install/tools/ipa-dns-install @@ -31,6 +31,7 @@ from ipapython import ipautil, sysrestore from ipalib import api, errors, util from ipapython.config import IPAOptionParser from ipapython.ipa_log_manager import standard_logging_setup, root_logger +from ipapython.ipautil import DN log_file_name = "/var/log/ipaserver-install.log" diff --git a/install/tools/ipa-drm-install b/install/tools/ipa-drm-install new file mode 100644 index 0000000000000000000000000000000000000000..7af39a3c749964d93a87bc4b58f1f41f8bc87269 --- /dev/null +++ b/install/tools/ipa-drm-install @@ -0,0 +1,196 @@ +#! /usr/bin/python2 -E +# Authors: Ade Lee +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . +# + + +import os +import sys +from ConfigParser import SafeConfigParser, NoOptionError + +from ipalib import api +from ipaserver.install import drminstance +from ipaserver.install import dsinstance +from ipaserver.install import installutils +from ipapython import version +from ipaserver.install.installutils import read_password +from ipapython import certmonger +from ipapython.ipa_log_manager import * +from ipapython import dogtag +from ipapython.config import IPAOptionParser +from ipapython import services as ipaservices + + +log_file_name = "/var/log/ipa-drm-install.log" + + +def uninstall(realm_name): + dogtag_constants = dogtag.configured_constants() + + drm_instance = drminstance.DRMInstance( + realm_name, dogtag_constants=dogtag_constants) + drm_instance.stop_tracking_certificates(dogtag_constants) + if drm_instance.is_installed(): + drm_instance.uninstall() + + dirs = [dogtag_constants.ALIAS_DIR] + ids = certmonger.check_state(dirs) + if ids: + root_logger.error( + "Some certificates may still be tracked by certmonger.\n" + "This will cause re-installation to fail.\n" + "Start the certmonger service and list the certificates being tracked\n" + "# getcert list\nThese may be untracked by executing\n" + "# getcert stop-tracking -i \n" + "for each id in: %s" + % ', '.join(ids)) + + +def parse_options(): + usage = "%prog [options]" + parser = IPAOptionParser(usage=usage, version=version.VERSION) + parser.add_option("-d", "--debug", dest="debug", action="store_true", + default=False, help="gather extra debugging information") + parser.add_option("-p", "--password", dest="password", sensitive=True, + help="Directory Manager (existing master) password") + parser.add_option("-U", "--unattended", dest="unattended", + action="store_true", default=False, + help="unattended installation never prompts the user") + parser.add_option("", "--uninstall", dest="uninstall", + action="store_true", default=False, + help="uninstall an existing installation. The uninstall can " + "be run with --unattended option") + + options, args = parser.parse_args() + safe_options = parser.get_safe_opts(options) + + return safe_options, options + + +def main(): + log_file = "/var/log/ipa-drm-install.log" + safe_options, options = parse_options() + + if os.geteuid() != 0: + sys.exit("\nYou must be root to run this script.\n") + + if options.uninstall: + log_file = "/var/log/ipa-drm-uninstall.log" + + standard_logging_setup(log_file, debug=options.debug) + + print "\nThe log file for this operation can be found in " + log_file_name + root_logger.debug('%s was invoked with options: %s' % + (sys.argv[0], safe_options)) + + if options.unattended and options.password is None: + sys.exit("Directory Manager password must be specified using -p" + " in unattended mode") + + dm_password = options.password or \ + read_password("Directory Manager", confirm=False) + if dm_password is None: + sys.exit("Directory Manager password required") + + p = SafeConfigParser() + p.read("/etc/ipa/default.conf") + + try: + host_name = p.get('global', 'host') + realm_name = p.get('global', 'realm') + domain_name = p.get('global', 'domain') + except NoOptionError as e: + print "\nA required parameter is missing from /etc/ipa/default.conf\n" + raise e + + try: + dogtag_version = int(p.get('global', 'dogtag_version')) + ra_plugin = p.get('global', 'ra_plugin') + enable_ra = p.get('global', 'enable_ra') + except NoOptionError as e: + print "\nA Dogtag CA must first be installed, or a required " \ + "parameter is missing from /etc/ipa/default.conf\n" + raise e + + try: + enable_drm = p.get('global', 'enable_drm') + except NoOptionError: + enable_drm = None + + subject = dsinstance.DsInstance().find_subject_base() + + if options.uninstall: + if enable_drm is None: + sys.exit("There is no DRM installed on this system") + uninstall(realm_name) + + if enable_drm is not None and enable_drm == 'True': + sys.exit("DRM is already installed.") + + if enable_ra is not None and enable_ra == "True" and \ + ra_plugin is not None and ra_plugin == "dogtag": + if dogtag_version is not None and dogtag_version >= 10: + # correct dogtag version of CA installed + pass + else: + sys.exit("Dogtag must be version 10.1 or above to install DRM") + else: + sys.exit("Dogtag CA is not installed. Please install the CA first") + + # Initialize the ipalib api + cfg = dict( + in_server=True, + debug=options.debug, + ) + api.bootstrap(**cfg) + api.finalize() + + print "==============================================================================" + print "This program will setup Dogtag DRM for the FreeIPA Server." + print "" + + drm = drminstance.DRMInstance(realm_name, + dogtag_constants=dogtag.install_constants) + + drm.configure_instance(host_name, domain_name, dm_password, + dm_password, subject_base=subject) + + drm.enable_client_auth_to_db(drm.dogtag_constants.DRM_CS_CFG_PATH) + + # Restart apache for new proxy config file + ipaservices.knownservices.httpd.restart(capture_output=True) + + try: + with open("/etc/ipa/default.conf", "a") as fd: + fd.write("drm_enabled=True") + except IOError, e: + print "Failed to update /etc/ipa/default.conf" + root_logger.error(str(e)) + sys.exit(1) + + +fail_message = ''' +Your system may be partly configured. +Run /usr/sbin/ipa-drm-install --uninstall to clean up. +''' + +if __name__ == '__main__': + with installutils.private_ccache(): + installutils.run_script(main, log_file_name=log_file_name, + operation_name='ipa-drm-add', + fail_message=fail_message) diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 5f751becb1ab8604667e4f0d7a2f10a754ff7201..b45b3179abb877f876a16ccea61b8f72872cb8c7 100644 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -40,9 +40,10 @@ from ipapython.config import IPAOptionParser from ipapython.ipa_log_manager import * from ipapython import certmonger from ipapython import dogtag -from ipaserver.install import installutils + from ipaserver.install import dsinstance from ipaserver.install import httpinstance +from ipaserver.install import installutils from ipaserver.install import memcacheinstance from ipaserver.install import bindinstance from ipaserver.install import service @@ -51,7 +52,6 @@ from ipaserver.install import certs from ipaserver.install import otpdinstance from ipaserver.install import sysupgrade - def parse_options(): parser = IPAOptionParser(version=version.VERSION) parser.add_option("-d", "--debug", dest="debug", action="store_true", @@ -824,66 +824,7 @@ def find_subject_base(): 3) Last resort, look in the certmap.conf itself 4) If all fails, log loudly and return None """ - root_logger.debug('Trying to find certificate subject base in sysupgrade') - subject_base = sysupgrade.get_upgrade_state('certmap.conf', 'subject_base') - - if subject_base: - root_logger.debug( - 'Found certificate subject base in sysupgrade: %s', - subject_base - ) - return subject_base - - root_logger.debug('Unable to find certificate subject base in sysupgrade') - root_logger.debug('Trying to find certificate subject base in DS') - - ds_is_running = services.knownservices.dirsrv.is_running() - if not ds_is_running: - try: - services.knownservices.dirsrv.start() - except ipautil.CalledProcessError as e: - root_logger.error('Cannot start DS to find certificate ' - 'subject base: %s', e) - else: - ds_is_running = True - - if ds_is_running: - try: - api.Backend.ldap2.connect(autobind=True) - except ipalib.errors.PublicError, e: - root_logger.error('Cannot connect to DS to find certificate ' - 'subject base: %s', e) - else: - ret = api.Command['config_show']() - api.Backend.ldap2.disconnect() - subject_base = str(ret['result']['ipacertificatesubjectbase'][0]) - root_logger.debug( - 'Found certificate subject base in DS: %s', - subject_base - ) - - if not subject_base: - root_logger.debug('Unable to find certificate subject base in DS') - root_logger.debug('Trying to find certificate subject base in ' - 'certmap.conf') - - certmap_dir = dsinstance.config_dirname( - dsinstance.realm_to_serverid(api.env.realm) - ) - try: - with open(os.path.join(certmap_dir, 'certmap.conf')) as f: - for line in f: - if line.startswith('certmap ipaca'): - subject_base = line.strip().split(',')[-1] - root_logger.debug( - 'Found certificate subject base in certmap.conf: ' - '%s', - subject_base - ) - - except IOError as e: - root_logger.error('Cannot open certmap.conf to find certificate ' - 'subject base: %s', e.strerror) + subject_base = dsinstance.DsInstance().find_subject_base() if subject_base: sysupgrade.set_upgrade_state( @@ -893,8 +834,6 @@ def find_subject_base(): ) return subject_base - root_logger.debug('Unable to find certificate subject base in ' - 'certmap.conf') root_logger.error('Unable to determine certificate subject base. ' 'certmap.conf will not be updated.') diff --git a/ipaserver/install/drminstance.py b/ipaserver/install/drminstance.py index 744b0973d7f4e0015279ce39e55bb85344237cf8..6eab9d8221d52351bdac4bfdf723c4a5474c9d9b 100644 --- a/ipaserver/install/drminstance.py +++ b/ipaserver/install/drminstance.py @@ -51,6 +51,10 @@ class DRMInstance(DogtagInstance): """ def __init__(self, realm, dogtag_constants=None): + """ + + :rtype : DRMInstance + """ if dogtag_constants is None: dogtag_constants = dogtag.configured_constants() diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 9256c12449b69e7752d421a3a3947d0feabfe840..5c20860fcb04d14ef6fadd41fcc54159cc78b740 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -39,6 +39,7 @@ import ldap from ipaserver.install import ldapupdate from ipaserver.install import replication from ipaserver.install import sysupgrade +from ipalib import api from ipalib import errors from ipalib.constants import CACERT from ipapython.dn import DN @@ -933,3 +934,79 @@ class DsInstance(service.Service): pass self.ldap_disconnect() + + def find_subject_base(self): + """ + Try to find the current value of certificate subject base. + 1) Look in sysupgrade first + 2) If no value is found there, look in DS (start DS if necessary) + 3) Last resort, look in the certmap.conf itself + 4) If all fails, log loudly and return None + """ + root_logger.debug( + 'Trying to find certificate subject base in sysupgrade') + subject_base = sysupgrade.get_upgrade_state( + 'certmap.conf', 'subject_base') + + if subject_base: + root_logger.debug( + 'Found certificate subject base in sysupgrade: %s', + subject_base) + return subject_base + + root_logger.debug( + 'Unable to find certificate subject base in sysupgrade') + root_logger.debug( + 'Trying to find certificate subject base in DS') + + ds_is_running = is_ds_running() + if not ds_is_running: + try: + self.start() + except ipautil.CalledProcessError as e: + root_logger.error('Cannot start DS to find certificate ' + 'subject base: %s', e) + else: + ds_is_running = True + + if ds_is_running: + try: + api.Backend.ldap2.connect(autobind=True) + except errors.PublicError, e: + root_logger.error('Cannot connect to DS to find certificate ' + 'subject base: %s', e) + else: + ret = api.Command['config_show']() + api.Backend.ldap2.disconnect() + subject_base = str( + ret['result']['ipacertificatesubjectbase'][0]) + root_logger.debug( + 'Found certificate subject base in DS: %s', subject_base) + + if not subject_base: + root_logger.debug('Unable to find certificate subject base in DS') + root_logger.debug('Trying to find certificate subject base in ' + 'certmap.conf') + + certmap_dir = config_dirname( + realm_to_serverid(api.env.realm) + ) + try: + with open(os.path.join(certmap_dir, 'certmap.conf')) as f: + for line in f: + if line.startswith('certmap ipaca'): + subject_base = line.strip().split(',')[-1] + root_logger.debug( + 'Found certificate subject base in certmap.conf: ' + '%s', subject_base) + + except IOError as e: + root_logger.error('Cannot open certmap.conf to find certificate ' + 'subject base: %s', e.strerror) + + if subject_base: + return subject_base + + root_logger.debug('Unable to find certificate subject base in ' + 'certmap.conf') + return None diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py index 32cf6bb707928bfc8c8286019593204370460bd3..c5a20a42acb9187b72fc456eae63d81a59da358c 100644 --- a/ipaserver/install/installutils.py +++ b/ipaserver/install/installutils.py @@ -40,7 +40,6 @@ from ipapython.ipa_log_manager import * from ipalib.util import validate_hostname from ipapython import config from ipalib import errors -from ipapython.dn import DN from ipaserver.install import certs, service from ipapython import services as ipaservices @@ -172,7 +171,7 @@ def verify_fqdn(host_name, no_host_dns=False, local_hostname=True): raise HostReverseLookupError("The host name %s does not match the reverse lookup %s" % (host_name, revname)) verified.add(address) -def record_in_hosts(ip, host_name=None, file="/etc/hosts"): +def record_in_hosts(ip, host_name=None, conf_file="/etc/hosts"): """ Search record in /etc/hosts - static table lookup for hostnames @@ -182,9 +181,9 @@ def record_in_hosts(ip, host_name=None, file="/etc/hosts"): :param ip: IP address :param host_name: Optional hostname to search - :param file: Optional path to the lookup table + :param conf_file: Optional path to the lookup table """ - hosts = open(file, 'r').readlines() + hosts = open(conf_file, 'r').readlines() for line in hosts: line = line.rstrip('\n') fields = line.partition('#')[0].split() @@ -204,13 +203,13 @@ def record_in_hosts(ip, host_name=None, file="/etc/hosts"): return None return (hosts_ip, names) except IndexError: - print "Warning: Erroneous line '%s' in %s" % (line, file) + print "Warning: Erroneous line '%s' in %s" % (line, conf_file) continue return None -def add_record_to_hosts(ip, host_name, file="/etc/hosts"): - hosts_fd = open(file, 'r+') +def add_record_to_hosts(ip, host_name, conf_file="/etc/hosts"): + hosts_fd = open(conf_file, 'r+') hosts_fd.seek(0, 2) hosts_fd.write(ip+'\t'+host_name+' '+host_name.split('.')[0]+'\n') hosts_fd.close() @@ -510,20 +509,20 @@ def expand_replica_info(filename, password): """ top_dir = tempfile.mkdtemp("ipa") tarfile = top_dir+"/files.tar" - dir = top_dir + "/realm_info" + dir_path = top_dir + "/realm_info" ipautil.decrypt_file(filename, tarfile, password, top_dir) ipautil.run(["tar", "xf", tarfile, "-C", top_dir]) os.remove(tarfile) - return top_dir, dir + return top_dir, dir_path -def read_replica_info(dir, rconfig): +def read_replica_info(dir_path, rconfig): """ Read the contents of a replica installation file. rconfig is a ReplicaConfig object """ - filename = dir + "/realm_info" + filename = dir_path + "/realm_info" fd = open(filename) config = SafeConfigParser() config.readfp(fd) @@ -779,7 +778,7 @@ def check_pkcs12(pkcs12_info, ca_file, hostname): raise ScriptError( '%s server certificates found in %s, expecting only one' % (len(server_certs), pkcs12_filename)) - [(server_cert_name, server_cert_trust)] = server_certs + [(server_cert_name, _server_cert_trust)] = server_certs # Check we have the whole cert chain & the CA is in it trust_chain = nssdb.get_trust_chain(server_cert_name) -- 1.9.3 From ftweedal at redhat.com Wed May 28 07:06:21 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 28 May 2014 17:06:21 +1000 Subject: [Freeipa-devel] running out of entropy during ipa-server-install Message-ID: <20140528070621.GF28407@dhcp-40-8.bne.redhat.com> Hi all, Today I hit the "WARNING: Your system is running out of entropy, you may experience long delays" message while testing Ade's ipa-server-install changes. I got a lot more entropy a lot faster by installing haveged(8), and I blogged about it here: http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/ Do you think it would be worthwhile to update the above warning message to additionally suggest installing haveged(8) or pointing to other help on remediating a low-entropy system? Cheers, Fraser From tbordaz at redhat.com Wed May 28 07:38:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 28 May 2014 09:38:39 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <538580A2.60508@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> Message-ID: <5385927F.5030302@redhat.com> On 05/28/2014 08:22 AM, Martin Kosek wrote: > On 05/27/2014 08:18 PM, Simo Sorce wrote: >> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>> On Tue, 27 May 2014, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>> care of the situation. >>>>>>> In that case the provisioning system created a staging entry >>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>> it created. >>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>> have a form that does not use uid in the RDN in IPA. >>>>>> >>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>> It is not useful, the operator still needs to be able to create in >>>>>> pre-active ... so it can still create what it wants. >>>>> yes that is correct. >>>>> Does it address the security concern, if the operator that is allowed to >>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>> the entry in 'active' ? >>>> Well it really depends on 'who' the operator is. >>>> >>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>> just press a button to activate a user, but that shouldn't drive our >>>> design if it makes other things clumsy or suboptimal. >>>> >>>> The less privileged operator problem can always be solved by a >>>> middle-man script that has higher privileges. So we nee to give priority >>>> to getting the workflow right in terms of the way it works. >>>> >>>> I think re-creating the user object gives us better chances at handling >>>> the overall workflow and fixing up entries accordingly to the management >>>> framework view of what a user needs to look like, so in the end I prefer >>>> that route. >>> I agree. It also opens us a way to handle import of any foreign schema >>> person if staged object uses extensibleObject object class where we are >>> in control of what exactly will get into the actual tree. >> Right it allows us to do things like filter out objectclass or >> attributes the provisioning system adds but that the admin does not want >> in the final entry. This is not something we may want to build into the >> solution from day zero, but it gives us the option to build it more >> easily, as a framework filter on the 'unstage' operation. >> (We so need to be able to copy additional objectclasses and their >> attributes from day 0 though). >> Simo. > Ok, thanks guys, I see an agreement. Thierry, we should now update all the > information here: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP > > (you can even link this thread in the archives) > > Martin Yes I will do that. Regarding workflow, it looks a priority that active entries are valid (regarding FreeIPA). Currently CLI offers: * ipa user-add (in active) * ipa user-add --stage (in stage). In order to prevent admin to add a corrupted entry in active and force any entry to go through the filter of objectclass/attribute, we could make 'ipa user-add' to create entry in staging and 'ipa user-add --active' to create entry in active. Even more, should we support to add entry directly in 'active' or rather only support 'user-add' to go only in staging ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed May 28 10:08:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 12:08:01 +0200 Subject: [Freeipa-devel] running out of entropy during ipa-server-install In-Reply-To: <20140528070621.GF28407@dhcp-40-8.bne.redhat.com> References: <20140528070621.GF28407@dhcp-40-8.bne.redhat.com> Message-ID: <5385B581.8090501@redhat.com> On 05/28/2014 09:06 AM, Fraser Tweedale wrote: > Hi all, > > Today I hit the "WARNING: Your system is running out of entropy, you > may experience long delays" message while testing Ade's > ipa-server-install changes. > > I got a lot more entropy a lot faster by installing haveged(8), and > I blogged about it here: > http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/ > > Do you think it would be worthwhile to update the above warning > message to additionally suggest installing haveged(8) or pointing to > other help on remediating a low-entropy system? > > Cheers, > > Fraser Hello, haveged is not the only solution. As you note there's also rngd; and with modern virtualization systems VMs can get entropy from the host. If we suggest a concrete solution we should be reasonably sure it's the best one. AFAK, for RHEL/CentOS haveged is only in EPEL, we probably don't want to suggest it there. -- Petr? P.S. I use this hack for my testing VMs: https://copr.fedoraproject.org/coprs/pviktori/breakmycryptod/ From thozza at redhat.com Wed May 28 11:26:00 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 28 May 2014 13:26:00 +0200 Subject: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading In-Reply-To: <53849A57.4040106@redhat.com> References: <538498FA.7070609@redhat.com> <53849A57.4040106@redhat.com> Message-ID: <5385C7C8.3060102@redhat.com> On 05/27/2014 03:59 PM, Petr Spacek wrote: > On 27.5.2014 15:54, Petr Spacek wrote: >> Fix race condition during zone loading. >> >> DNS zone has to be added to DNS view before dns_zone_load() is called. >> It is necessary to prevent dns_zone_load() from racing with >> dns_zone_setview(). >> >> This race condition sometimes prevents zone from being signed. >> Now the unsigned zone is visible until signing process is complete. This >> mimics BIND behavior for in-line signed zones. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > And here is the patch... > Hi. When I use bind-dyndb-ldap plugin with this patch, named does not start due to: rbt.c:1379: REQUIRE(name->buffer != ((void *)0)) failed, back trace (gdb) bt #0 0x00007f3963924c39 in raise () from /lib64/libc.so.6 #1 0x00007f3963926348 in abort () from /lib64/libc.so.6 #2 0x00007f3966979aee in assertion_failed () #3 0x00007f3964b6917a in isc_assertion_failed () from /lib64/libisc.so.95 #4 0x00007f39661ca9da in dns_rbt_fullnamefromnode () from /lib64/libdns.so.100 #5 0x00007f396011824b in rbt_iter_getnodename (iter=, nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:46 #6 0x00007f396011839b in rbt_iter_next (iterp=iterp at entry=0x7f39625f8b90, nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:144 #7 0x00007f3960112d32 in activate_zones (task=task at entry=0x7f39668f5790, inst=0x7f39668e4160) at ldap_helper.c:1164 #8 0x00007f396011a20d in barrier_decrement (task=0x7f39668f5790, event=0x7f396005b010) at syncrepl.c:138 #9 0x00007f3964b8b836 in run () from /lib64/libisc.so.95 #10 0x00007f396473ff33 in start_thread () from /lib64/libpthread.so.0 #11 0x00007f39639e3ded in clone () from /lib64/libc.so.6 It looks like you should use INIT_BUFFERED_NAME(name); used in the original code instead of dns_name_init(&name, NULL). The macro initializes the buffer in "name", which is missing in the new code. Regards, Tomas From mkosek at redhat.com Wed May 28 11:38:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 13:38:05 +0200 Subject: [Freeipa-devel] running out of entropy during ipa-server-install In-Reply-To: <5385B581.8090501@redhat.com> References: <20140528070621.GF28407@dhcp-40-8.bne.redhat.com> <5385B581.8090501@redhat.com> Message-ID: <5385CA9D.9090703@redhat.com> On 05/28/2014 12:08 PM, Petr Viktorin wrote: > On 05/28/2014 09:06 AM, Fraser Tweedale wrote: >> Hi all, >> >> Today I hit the "WARNING: Your system is running out of entropy, you >> may experience long delays" message while testing Ade's >> ipa-server-install changes. >> >> I got a lot more entropy a lot faster by installing haveged(8), and >> I blogged about it here: >> http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/ >> >> Do you think it would be worthwhile to update the above warning >> message to additionally suggest installing haveged(8) or pointing to >> other help on remediating a low-entropy system? >> >> Cheers, >> >> Fraser > > Hello, > haveged is not the only solution. As you note there's also rngd; and with > modern virtualization systems VMs can get entropy from the host. If we suggest > a concrete solution we should be reasonably sure it's the best one. > AFAK, for RHEL/CentOS haveged is only in EPEL, we probably don't want to > suggest it there. > I think the key point here is that FreeIPA announces that the entropy is low thus giving the administrator an option to do his homework on "how to increase entropy on my system" - for example by reading Fraser's blog :-) I also do not think that FreeIPA should give any more recommendations on top of that. Thanks, Martin From mkosek at redhat.com Wed May 28 11:44:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 13:44:00 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <1397655723.19767.395.camel@willson.li.ssimo.org> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> <1397652333.19767.377.camel@willson.li.ssimo.org> <534E7C56.8000708@redhat.com> <534E7DD0.90804@redhat.com> <1397655723.19767.395.camel@willson.li.ssimo.org> Message-ID: <5385CC00.1070503@redhat.com> On 04/16/2014 03:42 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 14:55 +0200, Martin Kosek wrote: >> On 04/16/2014 02:49 PM, Petr Viktorin wrote: >>> On 04/16/2014 02:45 PM, Simo Sorce wrote: >>>> On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: >>>>> On 04/16/2014 10:02 AM, Martin Kosek wrote: >>>>>> I was looking into ticket >>>>>> https://fedorahosted.org/freeipa/ticket/4054 >>>>>> and experimenting with ACIs allowing privileged users to manage only >>>>>> their own LDAP objects. >>>>>> >>>>>> As already proposed in the Bugzilla, I had success with following ACIs: >>>>>> >>>>>> ~~~~~~~~~~~~~~~~ >>>>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>>>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>>>>> add: aci >>>>>> aci: (targetattr = "userclass")(targetfilter = >>>>>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own >>>>>> hosts";allow (write) userattr = "creatorsName#USERDN";) >>>>>> >>>>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>>>>> >>>>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>>>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>>>>> add: aci >>>>>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl >>>>>> "permission:Modify own hosts";allow (delete) userattr = >>>>>> "creatorsName#USERDN";) >>>>>> >>>>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>>>>> ~~~~~~~~~~~~~~~~ >>>>>> >>>>>> When I then added a user fbar with permission "Add hosts", I was able to >>>>>> do exactly what proposed in the ticket: >>>>>> >>>>>> >>>>>> $ ipa host-add test.example.com --force >>>>>> ----------------------------- >>>>>> Added host "test.example.com" >>>>>> ----------------------------- >>>>>> Host name: test.example.com >>>>>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>>>>> Password: False >>>>>> Keytab: False >>>>>> Managed by: test.example.com >>>>>> >>>>>> $ ipa host-mod test.example.com --class foo >>>>>> -------------------------------- >>>>>> Modified host "test.example.com" >>>>>> -------------------------------- >>>>>> Host name: test.example.com >>>>>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>>>>> Class: foo >>>>>> Password: False >>>>>> Keytab: False >>>>>> Managed by: test.example.com >>>>>> >>>>>> $ ipa host-mod admin.example.com --class foo >>>>>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the >>>>>> 'userClass' attribute of entry >>>>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>>>>> >>>>>> >>>>>> $ ipa host-del admin.example.com >>>>>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to >>>>>> delete the entry >>>>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>>>>> >>>>>> >>>>>> $ ipa host-del test.example.com >>>>>> ------------------------------- >>>>>> Deleted host "test.example.com" >>>>>> ------------------------------- >>>>>> >>>>>> I think this could be pretty powerful also with other LDAP objects. >>>>>> Question is what can be done to allow that to our users. >>>>>> >>>>>> I do not think we should add these ACIs by default as not everybody >>>>>> would like them. But if we enhance our permission API to allow the >>>>>> userattr bind rule, admins could add these ACIs at their wish. >>>>>> >>>>>> IMO the API is not that difficult, something like this could work: >>>>>> >>>>>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname >>>>>> --bind-attr-type=USERDN >>>>>> >>>>>> --bind-attr could be more or less free form text to allow "creatorsname" >>>>>> or "parent[0].creatorsname" >>>>>> --bind-attr-type would be enum of values USERDN/GROUPDN >>>>>> >>>>>> This should cover most of the basic use cases. >>>>>> >>>>>> Thoughts? >>>>>> >>>>> >>>>> Makes sense. I'd do it around the time we move self-service to permissions. >>>>> >>>>> Simo, can you reserve two more OIDs for the attributes? >>>> >>>> What attributes ? userclass ? Can't we simply use a group/role ? >>> >>> The --bind-attr and --bind-attr-type values will need to be stored in the >>> permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. >> >> I would personally wait with reserving OID until we create a design of this >> feature as there are several approaches. We could for example need one more >> attribute, ipaPermBindAttrDepth we would use for control of the ACI effective >> depth (mutli valued, values 0-4). > > Agreed, there is no hurry until we have a design page. > > simo. I personally had a secret wish we could make this RFE happen in 4.0, but it is too late for that - thus moving the ticket to 4.1. Martin From mbasti at redhat.com Wed May 28 11:50:11 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 13:50:11 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <5382FC6B.8040402@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> Message-ID: <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote: > freeipa-server-foreman-smartproxy################################# > [ 40%] It works for me. I install 3.5, upgrade to 4.0 and it works -- Martin^2 Basti From mkosek at redhat.com Wed May 28 11:56:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 13:56:42 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> Message-ID: <5385CEFA.9030101@redhat.com> On 05/28/2014 01:50 PM, Martin Basti wrote: > On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote: >> freeipa-server-foreman-smartproxy################################# >> [ 40%] > > It works for me. > I install 3.5, upgrade to 4.0 and it works > Ok, thanks for testing - I might have improperly updated the patches. Just grepping through code, I am thinking the following part of bindinstance.py may still cause a crash: cnames = get_rr(domain_name, IPA_CA_RECORD, "CNAME") if not cnames: return root_logger.info('Converting IPA CA CNAME records to A/AAAA records') # create CNAME to FQDN mapping cname_fqdn = {} for cname in cnames: if cname.endswith('.'): fqdn = cname[:-1] else: You can easily test that with patched 4.0 by removing ipa-ca DNS A records, replacing with CNAMEs pointing to IPA FQDN and running ipa-upgradeconfig. My best bet is that it will crash badly. Martin From mbasti at redhat.com Wed May 28 12:03:25 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 14:03:25 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <5385CEFA.9030101@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> Message-ID: <1401278605.2263.3.camel@unused-4-145.brq.redhat.com> On Wed, 2014-05-28 at 13:56 +0200, Martin Kosek wrote: > On 05/28/2014 01:50 PM, Martin Basti wrote: > > On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote: > >> freeipa-server-foreman-smartproxy################################# > >> [ 40%] > > > > It works for me. > > I install 3.5, upgrade to 4.0 and it works > > > > Ok, thanks for testing - I might have improperly updated the patches. > > Just grepping through code, I am thinking the following part of bindinstance.py > may still cause a crash: > > cnames = get_rr(domain_name, IPA_CA_RECORD, "CNAME") > if not cnames: > return > > root_logger.info('Converting IPA CA CNAME records to A/AAAA records') > > # create CNAME to FQDN mapping > cname_fqdn = {} > for cname in cnames: > if cname.endswith('.'): > fqdn = cname[:-1] > else: > > > You can easily test that with patched 4.0 by removing ipa-ca DNS A records, > replacing with CNAMEs pointing to IPA FQDN and running ipa-upgradeconfig. > > My best bet is that it will crash badly. > > Martin I will take a look. Also here is a rebased patch, because API minor version was changed. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0032-4-dns_name_values-capability-added.patch Type: text/x-patch Size: 4513 bytes Desc: not available URL: From mbasti at redhat.com Wed May 28 12:31:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 14:31:15 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <5385CEFA.9030101@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> Message-ID: <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> On Wed, 2014-05-28 at 13:56 +0200, Martin Kosek wrote: > On 05/28/2014 01:50 PM, Martin Basti wrote: > > On Mon, 2014-05-26 at 10:33 +0200, Martin Kosek wrote: > >> freeipa-server-foreman-smartproxy################################# > >> [ 40%] > > > > It works for me. > > I install 3.5, upgrade to 4.0 and it works > > > > Ok, thanks for testing - I might have improperly updated the patches. > > Just grepping through code, I am thinking the following part of bindinstance.py > may still cause a crash: > > cnames = get_rr(domain_name, IPA_CA_RECORD, "CNAME") > if not cnames: > return > > root_logger.info('Converting IPA CA CNAME records to A/AAAA records') > > # create CNAME to FQDN mapping > cname_fqdn = {} > for cname in cnames: > if cname.endswith('.'): > fqdn = cname[:-1] > else: > > > You can easily test that with patched 4.0 by removing ipa-ca DNS A records, > replacing with CNAMEs pointing to IPA FQDN and running ipa-upgradeconfig. > > My best bet is that it will crash badly. > > Martin CNAME record is returned as string, so this is no issue (tested) -- Martin^2 Basti From mkosek at redhat.com Wed May 28 12:44:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 14:44:03 +0200 Subject: [Freeipa-devel] [PATCH] 0557 pwpolicy-mod: Fix crash when priority is changed In-Reply-To: <538476AC.5040500@redhat.com> References: <538476AC.5040500@redhat.com> Message-ID: <5385DA13.2010205@redhat.com> On 05/27/2014 01:27 PM, Petr Viktorin wrote: > See the ticket & commit message. > > https://fedorahosted.org/freeipa/ticket/4309 Yup, this fixed the crash. ACK! Martin From mkosek at redhat.com Wed May 28 12:45:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 14:45:10 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <53831C13.9020506@redhat.com> References: <535FE8D0.7030608@redhat.com> <1398795455.10424.108.camel@willson.li.ssimo.org> <5360068E.80805@redhat.com> <5360AD85.9010802@redhat.com> <53734A64.9080701@redhat.com> <53831C13.9020506@redhat.com> Message-ID: <5385DA56.1090207@redhat.com> On 05/26/2014 12:48 PM, Petr Viktorin wrote: > On 05/14/2014 12:50 PM, Petr Viktorin wrote: >> On 04/30/2014 10:00 AM, thierry bordaz wrote: >>> On 04/29/2014 10:07 PM, Martin Kosek wrote: >>>> On 04/29/2014 08:17 PM, Simo Sorce wrote: >>>>> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >>>>>> This adds the "idnsSecInlineSigning" attribute and related option. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3801 >>>>>> >>>>>> Simo, is adding a MAY attribute to an existing objectClass okay? >>>>>> >>>>> >>>>> Not unheard of, however in the past we discovered some schema >>>>> replication issues that may have an impact, let's make sure DS team >>>>> also >>>>> agrees this is not going to cause issue. >>>>> >>>>>> From a purely functional pov a MAY attribute will not break any stored >>>>> object, so it is fine. >>>>> >>>>> Simo. >>>> >>>> Adding Thierry to the CC list to evaluate the risks, he was already >>>> involved in fixing related issue in the DS for a similar Dogtag schema >>>> extension. >>> Hello, >>> >>> When an instance in the topology contains schema extensions like new >>> MAY attribute, this extension would be propagated to all instances >>> by replication (no need to copy/merge schema files). This was the >>> purpose of https://fedorahosted.org/389/ticket/47721. So it is fine >>> to add new MAY/MUST attribute or new attribute/objectclasses. >>> >>> During a replication session, a master will check what schema >>> definitions (objectclasses/attributes) of the replica extends its >>> own schema. If such definitions exist the supplier add/replace them >>> in its schema and its user99.ldif file. In your case if a replica >>> contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but >>> not the supplier then the supplier 'learns it' (during a replication >>> session it initiated) and so an entry containing that new attribute >>> can be updated on the supplier as well. >>> There is a similar mechanism, when a replica receives a schema that >>> contains new definitions, it 'learns' them. >>> >>> The fix for 47721 is introduced in 389-ds 1.3.2.17 and after. >>> It was tested with mixing 1.3.2.17 instance with legacy versions >>> (1.3.1, 1,3.0..), and the schema on both side converged to a common >>> one. This, whatever if the extensions are present on both side. >>> A limitation is that a legacy instance (not having the fix), must >>> have a replica agreements to/from an instance with the fix. >>> >>> regards >>> thierry >>> >> >> Thanks. This means the patch is good for review. >> I've just rebased it slightly. > > Another rebase in VERSION was necessary. > Still looking for a review. This is pretty obvious change, worked fine for me. ACK! Martin From ssorce at redhat.com Wed May 28 12:48:28 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 May 2014 08:48:28 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5385927F.5030302@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> Message-ID: <1401281308.2598.57.camel@willson.li.ssimo.org> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: > On 05/28/2014 08:22 AM, Martin Kosek wrote: > > On 05/27/2014 08:18 PM, Simo Sorce wrote: > >> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: > >>> On Tue, 27 May 2014, Simo Sorce wrote: > >>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: > >>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: > >>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: > >>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: > >>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and > >>>>>>>> pick that to generate the RDN of the user in the active tree. If there > >>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation > >>>>>>>> will just fail (due to non unique RDN) and the admin will have to take > >>>>>>>> care of the situation. > >>>>>>> In that case the provisioning system created a staging entry > >>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE > >>>>>>> It could be an issue for the provisioning system to retrieve the entry > >>>>>>> it created. > >>>>>> Too bad for the provisioning system, we are not going to allow users to > >>>>>> have a form that does not use uid in the RDN in IPA. > >>>>>> > >>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all > >>>>>>>> we need is to not enforce uniqueness in staging. > >>>>>>> This proposal was also to limit the operator privilege to do MODRDN from > >>>>>>> 'pre-active' to 'active', instead ADD on 'active'. > >>>>>> It is not useful, the operator still needs to be able to create in > >>>>>> pre-active ... so it can still create what it wants. > >>>>> yes that is correct. > >>>>> Does it address the security concern, if the operator that is allowed to > >>>>> add in 'staging'/'pre-active' is different from the one allowed to move > >>>>> the entry in 'active' ? > >>>> Well it really depends on 'who' the operator is. > >>>> > >>>> We would like to be able to allow a 'junior admin/helpdesk person' to > >>>> just press a button to activate a user, but that shouldn't drive our > >>>> design if it makes other things clumsy or suboptimal. > >>>> > >>>> The less privileged operator problem can always be solved by a > >>>> middle-man script that has higher privileges. So we nee to give priority > >>>> to getting the workflow right in terms of the way it works. > >>>> > >>>> I think re-creating the user object gives us better chances at handling > >>>> the overall workflow and fixing up entries accordingly to the management > >>>> framework view of what a user needs to look like, so in the end I prefer > >>>> that route. > >>> I agree. It also opens us a way to handle import of any foreign schema > >>> person if staged object uses extensibleObject object class where we are > >>> in control of what exactly will get into the actual tree. > >> Right it allows us to do things like filter out objectclass or > >> attributes the provisioning system adds but that the admin does not want > >> in the final entry. This is not something we may want to build into the > >> solution from day zero, but it gives us the option to build it more > >> easily, as a framework filter on the 'unstage' operation. > >> (We so need to be able to copy additional objectclasses and their > >> attributes from day 0 though). > >> Simo. > > Ok, thanks guys, I see an agreement. Thierry, we should now update all the > > information here: > > > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP > > > > (you can even link this thread in the archives) > > > > Martin > Yes I will do that. > > Regarding workflow, it looks a priority that active entries are valid > (regarding FreeIPA). > Currently CLI offers: > > * ipa user-add (in active) > * ipa user-add --stage (in stage). > > In order to prevent admin to add a corrupted entry in active and force > any entry to go through the filter of objectclass/attribute, we could > make 'ipa user-add' to create entry in staging and 'ipa user-add > --active' to create entry in active. Even more, should we support to add > entry directly in 'active' or rather only support 'user-add' to go only > in staging ? I do not see why this would ever be necessary, ipa user-add cannot create a "corrupt entry" by definition. I am actually not very happy with the "ipa user-add --stage" idea, the staging area is necessary for when you do not create a full 'ipa' user entry, but rather for when a provisioning system creates an "incomplete" entry. Simo. From rcritten at redhat.com Wed May 28 12:55:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 May 2014 08:55:22 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401281308.2598.57.camel@willson.li.ssimo.org> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> Message-ID: <5385DCBA.4000608@redhat.com> Simo Sorce wrote: > On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>> care of the situation. >>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>> it created. >>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>> >>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>> pre-active ... so it can still create what it wants. >>>>>>> yes that is correct. >>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>> the entry in 'active' ? >>>>>> Well it really depends on 'who' the operator is. >>>>>> >>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>> design if it makes other things clumsy or suboptimal. >>>>>> >>>>>> The less privileged operator problem can always be solved by a >>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>> to getting the workflow right in terms of the way it works. >>>>>> >>>>>> I think re-creating the user object gives us better chances at handling >>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>> that route. >>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>> person if staged object uses extensibleObject object class where we are >>>>> in control of what exactly will get into the actual tree. >>>> Right it allows us to do things like filter out objectclass or >>>> attributes the provisioning system adds but that the admin does not want >>>> in the final entry. This is not something we may want to build into the >>>> solution from day zero, but it gives us the option to build it more >>>> easily, as a framework filter on the 'unstage' operation. >>>> (We so need to be able to copy additional objectclasses and their >>>> attributes from day 0 though). >>>> Simo. >>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>> information here: >>> >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>> >>> (you can even link this thread in the archives) >>> >>> Martin >> Yes I will do that. >> >> Regarding workflow, it looks a priority that active entries are valid >> (regarding FreeIPA). >> Currently CLI offers: >> >> * ipa user-add (in active) >> * ipa user-add --stage (in stage). >> >> In order to prevent admin to add a corrupted entry in active and force >> any entry to go through the filter of objectclass/attribute, we could >> make 'ipa user-add' to create entry in staging and 'ipa user-add >> --active' to create entry in active. Even more, should we support to add >> entry directly in 'active' or rather only support 'user-add' to go only >> in staging ? > > I do not see why this would ever be necessary, ipa user-add cannot > create a "corrupt entry" by definition. > > I am actually not very happy with the "ipa user-add --stage" idea, the > staging area is necessary for when you do not create a full 'ipa' user > entry, but rather for when a provisioning system creates an "incomplete" > entry. I'm not sure what the use case for this is either, other than simplifying testing. If you have access to the IPA API then why bother staging a user? rob From tbordaz at redhat.com Wed May 28 13:06:10 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 28 May 2014 15:06:10 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5385DCBA.4000608@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385DCBA.4000608@redhat.com> Message-ID: <5385DF42.2050402@redhat.com> On 05/28/2014 02:55 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >>> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>>> care of the situation. >>>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>>> it created. >>>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>>> >>>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>>> pre-active ... so it can still create what it wants. >>>>>>>> yes that is correct. >>>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>>> the entry in 'active' ? >>>>>>> Well it really depends on 'who' the operator is. >>>>>>> >>>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>>> design if it makes other things clumsy or suboptimal. >>>>>>> >>>>>>> The less privileged operator problem can always be solved by a >>>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>>> to getting the workflow right in terms of the way it works. >>>>>>> >>>>>>> I think re-creating the user object gives us better chances at handling >>>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>>> that route. >>>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>>> person if staged object uses extensibleObject object class where we are >>>>>> in control of what exactly will get into the actual tree. >>>>> Right it allows us to do things like filter out objectclass or >>>>> attributes the provisioning system adds but that the admin does not want >>>>> in the final entry. This is not something we may want to build into the >>>>> solution from day zero, but it gives us the option to build it more >>>>> easily, as a framework filter on the 'unstage' operation. >>>>> (We so need to be able to copy additional objectclasses and their >>>>> attributes from day 0 though). >>>>> Simo. >>>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>>> information here: >>>> >>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>> >>>> (you can even link this thread in the archives) >>>> >>>> Martin >>> Yes I will do that. >>> >>> Regarding workflow, it looks a priority that active entries are valid >>> (regarding FreeIPA). >>> Currently CLI offers: >>> >>> * ipa user-add (in active) >>> * ipa user-add --stage (in stage). >>> >>> In order to prevent admin to add a corrupted entry in active and force >>> any entry to go through the filter of objectclass/attribute, we could >>> make 'ipa user-add' to create entry in staging and 'ipa user-add >>> --active' to create entry in active. Even more, should we support to add >>> entry directly in 'active' or rather only support 'user-add' to go only >>> in staging ? >> I do not see why this would ever be necessary, ipa user-add cannot >> create a "corrupt entry" by definition. >> >> I am actually not very happy with the "ipa user-add --stage" idea, the >> staging area is necessary for when you do not create a full 'ipa' user >> entry, but rather for when a provisioning system creates an "incomplete" >> entry. > I'm not sure what the use case for this is either, other than > simplifying testing. If you have access to the IPA API then why bother > staging a user? > > rob > I agree, FreeIPA CLI or API will create valid entry. Now a staging area can be used for storing entries waiting for an approval. For an example, a cron job scanning the stage container may send request to an approver. The approver having the ability to read the 'stage' entry will issue 'ipa user-unstage' or not. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed May 28 13:40:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 15:40:23 +0200 Subject: [Freeipa-devel] [PATCHES] 0558-0561 Read ACI fixes Message-ID: <5385E747.6050306@redhat.com> Hello, Some of IPA plugins assume that everyone has access to everything. Here are some fixes for that. Patch 0560 adds a new permission for the UPG Definition, which is required to add users correctly. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0558-krbtpolicy-plugin-Fix-internal-error-when-global-pol.patch Type: text/x-patch Size: 1327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0559-aci-plugin-Fix-internal-error-when-ACIs-are-not-read.patch Type: text/x-patch Size: 915 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0560-Add-managed-read-permission-for-the-UPG-Definition.patch Type: text/x-patch Size: 1861 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0561-ldap2.has_upg-Raise-an-error-if-the-UPG-definition-i.patch Type: text/x-patch Size: 3442 bytes Desc: not available URL: From pviktori at redhat.com Wed May 28 13:53:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 15:53:01 +0200 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <20140528064818.GE28407@dhcp-40-8.bne.redhat.com> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> <1399693089.26524.14.camel@aleeredhat.laptop> <1401227860.9297.9.camel@aleeredhat.laptop> <20140528064818.GE28407@dhcp-40-8.bne.redhat.com> Message-ID: <5385EA3D.8000505@redhat.com> On 05/28/2014 08:48 AM, Fraser Tweedale wrote: > On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote: >> There have been a couple of changes in the Dogtag interface, that >> require some changes in the IPA patches. Also, I had to add back a >> function in order to rebase to the latest IPA code. >> >> Most are the patches are as before, attached to this email by default. >> >> The latest Dogtag 10.2 build with the relevant changes needed to work >> with these patches is at: >> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ >> >> Ade >> > > ACK. > > ipa-server-install worked fine for me, and the formatting changes > seem good. Patch 0003 did not apply cleanly on master (due to minor > conflict in 71c6d2f:installutils.py); an updated patch 0003 is > attached. Hello, If you do a rebase, could you attach all the patches again? I don't have the Git objects that result from the original patch, so `git am` fails on the later patches: $ git am -3 *.patch Applying: Add a DRM to IPA Applying: Added ipa-drm-install Applying: Fix various pep 8 issues and comments from review Applying: Added nolog to pkispawn and some additional fixes from review. Applying: Added dogtag plugin for DRM Applying: set drm to not install by default with ipa-server-install Applying: Allow ipa-replica-install to be used for installing replicas error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b for 'install/tools/ipa-replica-install' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0007 Allow ipa-replica-install to be used for installing replicas The copy of the patch that failed is found in: /home/pviktori/freeipa/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -- Petr? From mkosek at redhat.com Wed May 28 13:56:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 15:56:47 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401281308.2598.57.camel@willson.li.ssimo.org> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> Message-ID: <5385EB1F.5030403@redhat.com> On 05/28/2014 02:48 PM, Simo Sorce wrote: > On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>> care of the situation. >>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>> it created. >>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>> >>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>> pre-active ... so it can still create what it wants. >>>>>>> yes that is correct. >>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>> the entry in 'active' ? >>>>>> Well it really depends on 'who' the operator is. >>>>>> >>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>> design if it makes other things clumsy or suboptimal. >>>>>> >>>>>> The less privileged operator problem can always be solved by a >>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>> to getting the workflow right in terms of the way it works. >>>>>> >>>>>> I think re-creating the user object gives us better chances at handling >>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>> that route. >>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>> person if staged object uses extensibleObject object class where we are >>>>> in control of what exactly will get into the actual tree. >>>> Right it allows us to do things like filter out objectclass or >>>> attributes the provisioning system adds but that the admin does not want >>>> in the final entry. This is not something we may want to build into the >>>> solution from day zero, but it gives us the option to build it more >>>> easily, as a framework filter on the 'unstage' operation. >>>> (We so need to be able to copy additional objectclasses and their >>>> attributes from day 0 though). >>>> Simo. >>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>> information here: >>> >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>> >>> (you can even link this thread in the archives) >>> >>> Martin >> Yes I will do that. >> >> Regarding workflow, it looks a priority that active entries are valid >> (regarding FreeIPA). >> Currently CLI offers: >> >> * ipa user-add (in active) >> * ipa user-add --stage (in stage). >> >> In order to prevent admin to add a corrupted entry in active and force >> any entry to go through the filter of objectclass/attribute, we could >> make 'ipa user-add' to create entry in staging and 'ipa user-add >> --active' to create entry in active. Even more, should we support to add >> entry directly in 'active' or rather only support 'user-add' to go only >> in staging ? > > I do not see why this would ever be necessary, ipa user-add cannot > create a "corrupt entry" by definition. > > I am actually not very happy with the "ipa user-add --stage" idea, the > staging area is necessary for when you do not create a full 'ipa' user > entry, but rather for when a provisioning system creates an "incomplete" > entry. > > Simo. /me wishes that the major concerns were spelled out during initial RFE review... Could this help a custom provisioning system that uses FreeIPA user-add JSON-RPC command instead of ldapadd? The record may still be incomplete in terms of company policy (e.g. missing manager) and about to be moved only when the user joins the company? Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the staging area? Martin From pviktori at redhat.com Wed May 28 13:59:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 15:59:02 +0200 Subject: [Freeipa-devel] [PATCH] 0557 pwpolicy-mod: Fix crash when priority is changed In-Reply-To: <5385DA13.2010205@redhat.com> References: <538476AC.5040500@redhat.com> <5385DA13.2010205@redhat.com> Message-ID: <5385EBA6.50005@redhat.com> On 05/28/2014 02:44 PM, Martin Kosek wrote: > On 05/27/2014 01:27 PM, Petr Viktorin wrote: >> See the ticket & commit message. >> >> https://fedorahosted.org/freeipa/ticket/4309 > > > Yup, this fixed the crash. ACK! > > Martin > Thanks, pushed to master: 8bbd52e347f3e6395d469528e1220fd9158e5609 -- Petr? From pviktori at redhat.com Wed May 28 13:59:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 15:59:17 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <5385DA56.1090207@redhat.com> References: <535FE8D0.7030608@redhat.com> <1398795455.10424.108.camel@willson.li.ssimo.org> <5360068E.80805@redhat.com> <5360AD85.9010802@redhat.com> <53734A64.9080701@redhat.com> <53831C13.9020506@redhat.com> <5385DA56.1090207@redhat.com> Message-ID: <5385EBB5.1030805@redhat.com> On 05/28/2014 02:45 PM, Martin Kosek wrote: > On 05/26/2014 12:48 PM, Petr Viktorin wrote: >> On 05/14/2014 12:50 PM, Petr Viktorin wrote: >>> On 04/30/2014 10:00 AM, thierry bordaz wrote: >>>> On 04/29/2014 10:07 PM, Martin Kosek wrote: >>>>> On 04/29/2014 08:17 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >>>>>>> This adds the "idnsSecInlineSigning" attribute and related option. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3801 >>>>>>> >>>>>>> Simo, is adding a MAY attribute to an existing objectClass okay? >>>>>>> >>>>>> >>>>>> Not unheard of, however in the past we discovered some schema >>>>>> replication issues that may have an impact, let's make sure DS team >>>>>> also >>>>>> agrees this is not going to cause issue. >>>>>> >>>>>>> From a purely functional pov a MAY attribute will not break any stored >>>>>> object, so it is fine. >>>>>> >>>>>> Simo. >>>>> >>>>> Adding Thierry to the CC list to evaluate the risks, he was already >>>>> involved in fixing related issue in the DS for a similar Dogtag schema >>>>> extension. >>>> Hello, >>>> >>>> When an instance in the topology contains schema extensions like new >>>> MAY attribute, this extension would be propagated to all instances >>>> by replication (no need to copy/merge schema files). This was the >>>> purpose of https://fedorahosted.org/389/ticket/47721. So it is fine >>>> to add new MAY/MUST attribute or new attribute/objectclasses. >>>> >>>> During a replication session, a master will check what schema >>>> definitions (objectclasses/attributes) of the replica extends its >>>> own schema. If such definitions exist the supplier add/replace them >>>> in its schema and its user99.ldif file. In your case if a replica >>>> contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but >>>> not the supplier then the supplier 'learns it' (during a replication >>>> session it initiated) and so an entry containing that new attribute >>>> can be updated on the supplier as well. >>>> There is a similar mechanism, when a replica receives a schema that >>>> contains new definitions, it 'learns' them. >>>> >>>> The fix for 47721 is introduced in 389-ds 1.3.2.17 and after. >>>> It was tested with mixing 1.3.2.17 instance with legacy versions >>>> (1.3.1, 1,3.0..), and the schema on both side converged to a common >>>> one. This, whatever if the extensions are present on both side. >>>> A limitation is that a legacy instance (not having the fix), must >>>> have a replica agreements to/from an instance with the fix. >>>> >>>> regards >>>> thierry >>>> >>> >>> Thanks. This means the patch is good for review. >>> I've just rebased it slightly. >> >> Another rebase in VERSION was necessary. >> Still looking for a review. > > This is pretty obvious change, worked fine for me. ACK! > > Martin > Thanks, pushed to master: 8b7daf675e77d7a5e2de6eadb26ca3b682c0d67f -- Petr? From pviktori at redhat.com Wed May 28 14:02:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 16:02:40 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user In-Reply-To: <1401203596.2598.0.camel@willson.li.ssimo.org> References: <537C41A3.2090103@redhat.com> <1400667242.7561.12.camel@willson.li.ssimo.org> <537E0799.2000408@redhat.com> <537F0E0E.3020204@redhat.com> <1400856659.7561.124.camel@willson.li.ssimo.org> <538244B7.8010200@redhat.com> <538311AE.4090502@redhat.com> <538312C5.8000807@redhat.com> <538313C2.7020007@redhat.com> <5384A795.5090704@redhat.com> <20140527150154.GY23849@redhat.com> <1401203596.2598.0.camel@willson.li.ssimo.org> Message-ID: <5385EC80.2070707@redhat.com> On 05/27/2014 05:13 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 18:01 +0300, Alexander Bokovoy wrote: >> On Tue, 27 May 2014, Petr Viktorin wrote: >>> On 05/26/2014 12:13 PM, Petr Viktorin wrote: >>> [...] >>>> >>>> Thanks for the thorough review! >>>> Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 >>> >>> >>> Okay guys, we have another issue: >>> user-add (and the migration plugin) needs access to cn=UPG >>> Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the >>> originfilter for '(objectclass=disable)'. >>> >>> Do we want to give read access to all users, or just user admins? >> I would say user admins. If something more substantial fails, we'll >> extend the access. >> > > ACK > For the record, the change is in my patch 0560. -- Petr? From mkosek at redhat.com Wed May 28 14:07:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 16:07:18 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5385DF42.2050402@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385DCBA.4000608@redhat.com> <5385DF42.2050402@redhat.com> Message-ID: <5385ED96.60905@redhat.com> On 05/28/2014 03:06 PM, thierry bordaz wrote: > On 05/28/2014 02:55 PM, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >>>> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>>>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, >>>>>>>>>>>> and >>>>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>>>> care of the situation. >>>>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>>>> it created. >>>>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>>>> >>>>>>>>>>>> Sounds like a lot of complexity for a problem we do not really >>>>>>>>>>>> have, all >>>>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN >>>>>>>>>>> from >>>>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>>>> pre-active ... so it can still create what it wants. >>>>>>>>> yes that is correct. >>>>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>>>> the entry in 'active' ? >>>>>>>> Well it really depends on 'who' the operator is. >>>>>>>> >>>>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>>>> design if it makes other things clumsy or suboptimal. >>>>>>>> >>>>>>>> The less privileged operator problem can always be solved by a >>>>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>>>> to getting the workflow right in terms of the way it works. >>>>>>>> >>>>>>>> I think re-creating the user object gives us better chances at handling >>>>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>>>> that route. >>>>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>>>> person if staged object uses extensibleObject object class where we are >>>>>>> in control of what exactly will get into the actual tree. >>>>>> Right it allows us to do things like filter out objectclass or >>>>>> attributes the provisioning system adds but that the admin does not want >>>>>> in the final entry. This is not something we may want to build into the >>>>>> solution from day zero, but it gives us the option to build it more >>>>>> easily, as a framework filter on the 'unstage' operation. >>>>>> (We so need to be able to copy additional objectclasses and their >>>>>> attributes from day 0 though). >>>>>> Simo. >>>>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>>>> information here: >>>>> >>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>>> >>>>> >>>>> (you can even link this thread in the archives) >>>>> >>>>> Martin >>>> Yes I will do that. >>>> >>>> Regarding workflow, it looks a priority that active entries are valid >>>> (regarding FreeIPA). >>>> Currently CLI offers: >>>> >>>> * ipa user-add (in active) >>>> * ipa user-add --stage (in stage). >>>> >>>> In order to prevent admin to add a corrupted entry in active and force >>>> any entry to go through the filter of objectclass/attribute, we could >>>> make 'ipa user-add' to create entry in staging and 'ipa user-add >>>> --active' to create entry in active. Even more, should we support to add >>>> entry directly in 'active' or rather only support 'user-add' to go only >>>> in staging ? >>> I do not see why this would ever be necessary, ipa user-add cannot >>> create a "corrupt entry" by definition. >>> >>> I am actually not very happy with the "ipa user-add --stage" idea, the >>> staging area is necessary for when you do not create a full 'ipa' user >>> entry, but rather for when a provisioning system creates an "incomplete" >>> entry. >> I'm not sure what the use case for this is either, other than >> simplifying testing. If you have access to the IPA API then why bother >> staging a user? >> >> rob >> > I agree, FreeIPA CLI or API will create valid entry. > > Now a staging area can be used for storing entries waiting for an approval. For > an example, a cron job scanning the stage container may send request to an > approver. The approver having the ability to read the 'stage' entry will issue > 'ipa user-unstage' or not. > > thanks > thierry Right. Company/app may for example have a registration page where users can fill their personal details. The page would only have privilege to add staged users. Unstaging would then be made after authorization step (mail verification, phone call, etc.). Martin From jcholast at redhat.com Wed May 28 14:20:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 28 May 2014 16:20:47 +0200 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5385EB1F.5030403@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385EB1F.5030403@redhat.com> Message-ID: <5385F0BF.8050106@redhat.com> On 28.5.2014 15:56, Martin Kosek wrote: > On 05/28/2014 02:48 PM, Simo Sorce wrote: >> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >>> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>>> care of the situation. >>>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>>> it created. >>>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>>> >>>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>>> pre-active ... so it can still create what it wants. >>>>>>>> yes that is correct. >>>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>>> the entry in 'active' ? >>>>>>> Well it really depends on 'who' the operator is. >>>>>>> >>>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>>> design if it makes other things clumsy or suboptimal. >>>>>>> >>>>>>> The less privileged operator problem can always be solved by a >>>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>>> to getting the workflow right in terms of the way it works. >>>>>>> >>>>>>> I think re-creating the user object gives us better chances at handling >>>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>>> that route. >>>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>>> person if staged object uses extensibleObject object class where we are >>>>>> in control of what exactly will get into the actual tree. >>>>> Right it allows us to do things like filter out objectclass or >>>>> attributes the provisioning system adds but that the admin does not want >>>>> in the final entry. This is not something we may want to build into the >>>>> solution from day zero, but it gives us the option to build it more >>>>> easily, as a framework filter on the 'unstage' operation. >>>>> (We so need to be able to copy additional objectclasses and their >>>>> attributes from day 0 though). >>>>> Simo. >>>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>>> information here: >>>> >>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>> >>>> (you can even link this thread in the archives) >>>> >>>> Martin >>> Yes I will do that. >>> >>> Regarding workflow, it looks a priority that active entries are valid >>> (regarding FreeIPA). >>> Currently CLI offers: >>> >>> * ipa user-add (in active) >>> * ipa user-add --stage (in stage). >>> >>> In order to prevent admin to add a corrupted entry in active and force >>> any entry to go through the filter of objectclass/attribute, we could >>> make 'ipa user-add' to create entry in staging and 'ipa user-add >>> --active' to create entry in active. Even more, should we support to add >>> entry directly in 'active' or rather only support 'user-add' to go only >>> in staging ? >> >> I do not see why this would ever be necessary, ipa user-add cannot >> create a "corrupt entry" by definition. >> >> I am actually not very happy with the "ipa user-add --stage" idea, the >> staging area is necessary for when you do not create a full 'ipa' user >> entry, but rather for when a provisioning system creates an "incomplete" >> entry. >> >> Simo. > > /me wishes that the major concerns were spelled out during initial RFE review... > > Could this help a custom provisioning system that uses FreeIPA user-add > JSON-RPC command instead of ldapadd? The record may still be incomplete in > terms of company policy (e.g. missing manager) and about to be moved only when > the user joins the company? > > Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the > staging area? > > Martin Like I said in the other thread, I think managing staged users does not belong in the user plugin, as they are different object classes. So IMO we should either avoid it, or do it in a new plugin. -- Jan Cholasta From pviktori at redhat.com Wed May 28 14:27:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 16:27:54 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <53849F31.2050508@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> Message-ID: <5385F26A.1010402@redhat.com> On 05/27/2014 04:20 PM, Martin Kosek wrote: > On 05/26/2014 04:44 PM, Petr Viktorin wrote: >> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>> Hello, >>> Here I start upgrading the existing default permissions to the new >>> Managed style. >>> >>> https://fedorahosted.org/freeipa/ticket/4346 >>> >>> The patches rely on my patch 0551 >>> (https://fedorahosted.org/freeipa/ticket/4349) >>> You may run into what seems to be a 389 bug. If you get a "Midair >>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>> >>> >>> >>> The operation is now described at >>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>> >>> >>> >>> If there user has modified an old default permission, a warning is >>> logged the replacement permission is not added/updated. The user needs >>> to evaluate the situation: either update the old permission to match the >>> original default, or remove the old permission, and then run >>> ipa-ldap-updater will create the new one. >>> Is bailing out the right thing to do if the old entry was modified? > > Forcing user to remove old permission and create new one seems as a too much > work to me. After the upgrade, we need to be sure that the managed permissions > is there. Note that this only happens if the user changed the permissions, so we need to be extra careful to respect their wishes. > What is the problem of having both 2 permissions in the DS? The old modified > permission and the new system managed one? As we are dealing with allow > permissions, having 2 of them should be harmless. The new one could be granting too much access, the admin might have wanted to restrict the defaults. >>> It could be possible to parse the permission, figure out the changes the >>> user made, and apply them to the new one, but that seems like too much >>> guesswork to me. > > Maybe we could do the same we do with managed permissions upgrades? Only allow > differences in the list of attributes? I am thinking that people could hotfix > missing attributes at permissions themselves (like adding description to > sudorule permission), this would lead to duplicate permissions later. > > What we could do when old ACI differs only in allowed attributes is to compare > it to defaults and set whitelist and blacklist attributes of the new managed > permission. Then we can safely delete the old ACI (with warning). > > If you think this is too much work, we can keep the old behavior and just add > duplicate ACI. Having duplicate permissions would be possible, after all they have a different name. However I'd expect that most people would still want to delete the old ones, rather than letting them hide among user-defined permissions. >>> On the other hand, my approach has a downside as well: if the >>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's >>> now no way to upgrade while allowing access but keeping that attribute >>> off-limits, short of writing deny a ACI by hand. How big a problem is >>> this? It might be worth it to create a special tool that upgrades a >>> single permission and allows setting the excluded/included attributes >>> explicitly. > > This problem would be removed with my approach proposed above. > >>> There are some interesting scenarios to think about with respect to >>> upgrades and user changes: >>> >>> * Upgrade to old version, e.g. >>> - have IPA 3.2 master, IPA 3.2 replica >>> - upgrade master to 4.0 (old permissions are updated) >>> - then upgrade replica to 3.3 (old permissions are added again!) >>> >>> This is AFAIK not supported but it does happen. >>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>> always add the old permissions, but with this patch, a subsequent >>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old >>> permissions again. > > Hm, I think this is the best option we have. We should warn about this behavior > in our release notes though. > >>> Tied to that is another scenario: >>> >>> * Re-create permissions with old names >>> - have IPA 4.0 master >>> - Create a permission named 'Modify Sudo rule' >>> - Upgrade to IPA 4.1 >>> >>> Here we need to make sure the new permission is *not* removed, because a >>> new 'Modify Sudo rule' permission is no longer special in any way. To >>> ensure this the updater only removes old-style permissions. > > Right, we can decide based on objectclasses - whether permissionsv2 OC is there > or not. > >>> >>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>> that an old permission named 'Modify Sudo rule' is added on the old >>> server. Any update to 4.0+ will remove that. >>> Old-style default permissions were sorta-kinda managed by IPA itself >>> anyway, so users should expect this. We should still point it out in the >>> docs though, since I expect some users to start messing with the >>> permissions before upgrading all of the infrastructure to 4.0. > > +1, I would just point out that behavior in the release notes. > >>> The second patch upgrades sudorule permissions, this server as an >>> example of how the will work. >>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >> >> The user read permissions patches had a conflict with these; attaching rebased >> version. > > Now the actual review > 552.2: worked fine for me. Some updates will probably be needed though, based > on the discussion above. > > 553.2: > > 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? Looks > like a noop to me, it was also never part of our add ACIs. Simo, I hazily remember discussing that we should only allow specific attributes on add, otherwise users can add entries with any extra objectclasses and attributes. Did we come to a conclusion? I might have confused targetattr with targetattrfilter in my notes; since I see targetarr is ineffective. > I tried to strip that down to just "description" and I was still able to add a > whole new SUDO rule. Ludwig, is that correct - does DS ignore (should it?) > targetattr part of add ACI? > > 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it ineffective. > Privileged user still cannot update all SUDO rule attributes. Duh. I've been staring at this too long. > Besides that, the ACIs were working fine. -- Petr? From ssorce at redhat.com Wed May 28 14:30:29 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 May 2014 10:30:29 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5385EB1F.5030403@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385EB1F.5030403@redhat.com> Message-ID: <1401287429.2598.66.camel@willson.li.ssimo.org> On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote: > On 05/28/2014 02:48 PM, Simo Sorce wrote: > > On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: > >> On 05/28/2014 08:22 AM, Martin Kosek wrote: > >>> On 05/27/2014 08:18 PM, Simo Sorce wrote: > >>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: > >>>>> On Tue, 27 May 2014, Simo Sorce wrote: > >>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: > >>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: > >>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: > >>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: > >>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and > >>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there > >>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation > >>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take > >>>>>>>>>> care of the situation. > >>>>>>>>> In that case the provisioning system created a staging entry > >>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE > >>>>>>>>> It could be an issue for the provisioning system to retrieve the entry > >>>>>>>>> it created. > >>>>>>>> Too bad for the provisioning system, we are not going to allow users to > >>>>>>>> have a form that does not use uid in the RDN in IPA. > >>>>>>>> > >>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all > >>>>>>>>>> we need is to not enforce uniqueness in staging. > >>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from > >>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. > >>>>>>>> It is not useful, the operator still needs to be able to create in > >>>>>>>> pre-active ... so it can still create what it wants. > >>>>>>> yes that is correct. > >>>>>>> Does it address the security concern, if the operator that is allowed to > >>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move > >>>>>>> the entry in 'active' ? > >>>>>> Well it really depends on 'who' the operator is. > >>>>>> > >>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to > >>>>>> just press a button to activate a user, but that shouldn't drive our > >>>>>> design if it makes other things clumsy or suboptimal. > >>>>>> > >>>>>> The less privileged operator problem can always be solved by a > >>>>>> middle-man script that has higher privileges. So we nee to give priority > >>>>>> to getting the workflow right in terms of the way it works. > >>>>>> > >>>>>> I think re-creating the user object gives us better chances at handling > >>>>>> the overall workflow and fixing up entries accordingly to the management > >>>>>> framework view of what a user needs to look like, so in the end I prefer > >>>>>> that route. > >>>>> I agree. It also opens us a way to handle import of any foreign schema > >>>>> person if staged object uses extensibleObject object class where we are > >>>>> in control of what exactly will get into the actual tree. > >>>> Right it allows us to do things like filter out objectclass or > >>>> attributes the provisioning system adds but that the admin does not want > >>>> in the final entry. This is not something we may want to build into the > >>>> solution from day zero, but it gives us the option to build it more > >>>> easily, as a framework filter on the 'unstage' operation. > >>>> (We so need to be able to copy additional objectclasses and their > >>>> attributes from day 0 though). > >>>> Simo. > >>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the > >>> information here: > >>> > >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP > >>> > >>> (you can even link this thread in the archives) > >>> > >>> Martin > >> Yes I will do that. > >> > >> Regarding workflow, it looks a priority that active entries are valid > >> (regarding FreeIPA). > >> Currently CLI offers: > >> > >> * ipa user-add (in active) > >> * ipa user-add --stage (in stage). > >> > >> In order to prevent admin to add a corrupted entry in active and force > >> any entry to go through the filter of objectclass/attribute, we could > >> make 'ipa user-add' to create entry in staging and 'ipa user-add > >> --active' to create entry in active. Even more, should we support to add > >> entry directly in 'active' or rather only support 'user-add' to go only > >> in staging ? > > > > I do not see why this would ever be necessary, ipa user-add cannot > > create a "corrupt entry" by definition. > > > > I am actually not very happy with the "ipa user-add --stage" idea, the > > staging area is necessary for when you do not create a full 'ipa' user > > entry, but rather for when a provisioning system creates an "incomplete" > > entry. > > > > Simo. > > /me wishes that the major concerns were spelled out during initial RFE review... > > Could this help a custom provisioning system that uses FreeIPA user-add > JSON-RPC command instead of ldapadd? The record may still be incomplete in > terms of company policy (e.g. missing manager) and about to be moved only when > the user joins the company? > > Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the > staging area? Note that I did not say we should not have an IPA command for that, but I dislike the idea of putting it in the user plugin and using that specific command expression. I would see something like ipa stage-user-add as a better way to go, in its own "stage" plugin. Simo. From pviktori at redhat.com Wed May 28 14:36:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 May 2014 16:36:55 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385F26A.1010402@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> Message-ID: <5385F487.908@redhat.com> On 05/28/2014 04:27 PM, Petr Viktorin wrote: > On 05/27/2014 04:20 PM, Martin Kosek wrote: >> On 05/26/2014 04:44 PM, Petr Viktorin wrote: >>> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>>> Hello, >>>> Here I start upgrading the existing default permissions to the new >>>> Managed style. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4346 >>>> >>>> The patches rely on my patch 0551 >>>> (https://fedorahosted.org/freeipa/ticket/4349) >>>> You may run into what seems to be a 389 bug. If you get a "Midair >>>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>>> >>>> >>>> >>>> The operation is now described at >>>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>>> >>>> >>>> >>>> >>>> If there user has modified an old default permission, a warning is >>>> logged the replacement permission is not added/updated. The user needs >>>> to evaluate the situation: either update the old permission to match >>>> the >>>> original default, or remove the old permission, and then run >>>> ipa-ldap-updater will create the new one. >>>> Is bailing out the right thing to do if the old entry was modified? >> >> Forcing user to remove old permission and create new one seems as a >> too much >> work to me. After the upgrade, we need to be sure that the managed >> permissions >> is there. > > Note that this only happens if the user changed the permissions, so we > need to be extra careful to respect their wishes. > >> What is the problem of having both 2 permissions in the DS? The old >> modified >> permission and the new system managed one? As we are dealing with allow >> permissions, having 2 of them should be harmless. > > The new one could be granting too much access, the admin might have > wanted to restrict the defaults. > > >>>> It could be possible to parse the permission, figure out the changes >>>> the >>>> user made, and apply them to the new one, but that seems like too much >>>> guesswork to me. >> >> Maybe we could do the same we do with managed permissions upgrades? >> Only allow >> differences in the list of attributes? I am thinking that people could >> hotfix >> missing attributes at permissions themselves (like adding description to >> sudorule permission), this would lead to duplicate permissions later. >> >> What we could do when old ACI differs only in allowed attributes is to >> compare >> it to defaults and set whitelist and blacklist attributes of the new >> managed >> permission. Then we can safely delete the old ACI (with warning). >> >> If you think this is too much work, we can keep the old behavior and >> just add >> duplicate ACI. > > Having duplicate permissions would be possible, after all they have a > different name. However I'd expect that most people would still want to > delete the old ones, rather than letting them hide among user-defined > permissions. > >>>> On the other hand, my approach has a downside as well: if the >>>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's >>>> now no way to upgrade while allowing access but keeping that attribute >>>> off-limits, short of writing deny a ACI by hand. How big a problem is >>>> this? It might be worth it to create a special tool that upgrades a >>>> single permission and allows setting the excluded/included attributes >>>> explicitly. >> >> This problem would be removed with my approach proposed above. >> >>>> There are some interesting scenarios to think about with respect to >>>> upgrades and user changes: >>>> >>>> * Upgrade to old version, e.g. >>>> - have IPA 3.2 master, IPA 3.2 replica >>>> - upgrade master to 4.0 (old permissions are updated) >>>> - then upgrade replica to 3.3 (old permissions are added again!) >>>> >>>> This is AFAIK not supported but it does happen. >>>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>>> always add the old permissions, but with this patch, a subsequent >>>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old >>>> permissions again. >> >> Hm, I think this is the best option we have. We should warn about this >> behavior >> in our release notes though. >> >>>> Tied to that is another scenario: >>>> >>>> * Re-create permissions with old names >>>> - have IPA 4.0 master >>>> - Create a permission named 'Modify Sudo rule' >>>> - Upgrade to IPA 4.1 >>>> >>>> Here we need to make sure the new permission is *not* removed, >>>> because a >>>> new 'Modify Sudo rule' permission is no longer special in any way. To >>>> ensure this the updater only removes old-style permissions. >> >> Right, we can decide based on objectclasses - whether permissionsv2 OC >> is there >> or not. >> >>>> >>>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>>> that an old permission named 'Modify Sudo rule' is added on the old >>>> server. Any update to 4.0+ will remove that. >>>> Old-style default permissions were sorta-kinda managed by IPA itself >>>> anyway, so users should expect this. We should still point it out in >>>> the >>>> docs though, since I expect some users to start messing with the >>>> permissions before upgrading all of the infrastructure to 4.0. >> >> +1, I would just point out that behavior in the release notes. >> >>>> The second patch upgrades sudorule permissions, this server as an >>>> example of how the will work. >>>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >>> >>> The user read permissions patches had a conflict with these; >>> attaching rebased >>> version. >> >> Now the actual review >> 552.2: worked fine for me. Some updates will probably be needed >> though, based >> on the discussion above. >> >> 553.2: >> >> 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? >> Looks >> like a noop to me, it was also never part of our add ACIs. > > Simo, I hazily remember discussing that we should only allow specific > attributes on add, otherwise users can add entries with any extra > objectclasses and attributes. Did we come to a conclusion? > I might have confused targetattr with targetattrfilter in my notes; > since I see targetarr is ineffective. OK, this was just me confused. As Ludwig told me, > for adding an entry you need add rights for the entry and write rights for each attribute, so in the add aci the targetattrs are irrelevant. so I'll remove them from the add ACI. >> I tried to strip that down to just "description" and I was still able >> to add a >> whole new SUDO rule. Ludwig, is that correct - does DS ignore (should >> it?) >> targetattr part of add ACI? >> >> 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it >> ineffective. >> Privileged user still cannot update all SUDO rule attributes. > > Duh. I've been staring at this too long. > >> Besides that, the ACIs were working fine. > -- Petr? From ssorce at redhat.com Wed May 28 14:50:03 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 May 2014 10:50:03 -0400 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385F26A.1010402@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> Message-ID: <1401288603.2598.70.camel@willson.li.ssimo.org> On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote: > Simo, I hazily remember discussing that we should only allow specific > attributes on add, otherwise users can add entries with any extra > objectclasses and attributes. Did we come to a conclusion? > I might have confused targetattr with targetattrfilter in my notes; > since I see targetarr is ineffective. > Yes we need to restrict at least the allowed objectclasses I think. Simo. From mkosek at redhat.com Wed May 28 14:56:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 16:56:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <1401288603.2598.70.camel@willson.li.ssimo.org> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <1401288603.2598.70.camel@willson.li.ssimo.org> Message-ID: <5385F911.4030407@redhat.com> On 05/28/2014 04:50 PM, Simo Sorce wrote: > On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote: >> Simo, I hazily remember discussing that we should only allow specific >> attributes on add, otherwise users can add entries with any extra >> objectclasses and attributes. Did we come to a conclusion? >> I might have confused targetattr with targetattrfilter in my notes; >> since I see targetarr is ineffective. >> > Yes we need to restrict at least the allowed objectclasses I think. > > Simo. > We do not have a support for targetattrfilter, I do not think this was ever tested. This part of ACI is also not very well documented, I think Petr found just one notice in the DS documentation about targetattrfilter. For 4.0, I would keep the add ACIs as they area (we do not have time for additional experiments anyway). If we feel the urge later, given the permissions are managed, it should be easy to change that. Martin From lkrispen at redhat.com Wed May 28 15:03:44 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 28 May 2014 17:03:44 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385F911.4030407@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <1401288603.2598.70.camel@willson.li.ssimo.org> <5385F911.4030407@redhat.com> Message-ID: <5385FAD0.40501@redhat.com> On 05/28/2014 04:56 PM, Martin Kosek wrote: > On 05/28/2014 04:50 PM, Simo Sorce wrote: >> On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote: >>> Simo, I hazily remember discussing that we should only allow specific >>> attributes on add, otherwise users can add entries with any extra >>> objectclasses and attributes. Did we come to a conclusion? >>> I might have confused targetattr with targetattrfilter in my notes; >>> since I see targetarr is ineffective. >>> >> Yes we need to restrict at least the allowed objectclasses I think. >> >> Simo. >> > We do not have a support for targetattrfilter, I do not think this was ever > tested. This part of ACI is also not very well documented, I think Petr found > just one notice in the DS documentation about targetattrfilter. It is in chapter 13.2.3.5 in https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets and it is for unknown reasons: targattrfilters > > For 4.0, I would keep the add ACIs as they area (we do not have time for > additional experiments anyway). If we feel the urge later, given the > permissions are managed, it should be easy to change that. > > Martin From mkosek at redhat.com Wed May 28 15:08:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 17:08:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385FAD0.40501@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <1401288603.2598.70.camel@willson.li.ssimo.org> <5385F911.4030407@redhat.com> <5385FAD0.40501@redhat.com> Message-ID: <5385FC04.6000304@redhat.com> On 05/28/2014 05:03 PM, Ludwig Krispenz wrote: > > On 05/28/2014 04:56 PM, Martin Kosek wrote: >> On 05/28/2014 04:50 PM, Simo Sorce wrote: >>> On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote: >>>> Simo, I hazily remember discussing that we should only allow specific >>>> attributes on add, otherwise users can add entries with any extra >>>> objectclasses and attributes. Did we come to a conclusion? >>>> I might have confused targetattr with targetattrfilter in my notes; >>>> since I see targetarr is ineffective. >>>> >>> Yes we need to restrict at least the allowed objectclasses I think. >>> >>> Simo. >>> >> We do not have a support for targetattrfilter, I do not think this was ever >> tested. This part of ACI is also not very well documented, I think Petr found >> just one notice in the DS documentation about targetattrfilter. > It is in chapter 13.2.3.5 in > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets > > and it is for unknown reasons: targattrfilters Right, this is what I (and Petr) was talking about. The doc contain just this single one line of information about targetattrfilters. Try googling that and you won't get much more. Just for completeness, posting one of the top findings: Bug 1032767 - Examples of the targetattrfilters ACI keyword need to be documented Martin From lkrispen at redhat.com Wed May 28 15:13:03 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 28 May 2014 17:13:03 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385FC04.6000304@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <1401288603.2598.70.camel@willson.li.ssimo.org> <5385F911.4030407@redhat.com> <5385FAD0.40501@redhat.com> <5385FC04.6000304@redhat.com> Message-ID: <5385FCFF.3050805@redhat.com> On 05/28/2014 05:08 PM, Martin Kosek wrote: > On 05/28/2014 05:03 PM, Ludwig Krispenz wrote: >> On 05/28/2014 04:56 PM, Martin Kosek wrote: >>> On 05/28/2014 04:50 PM, Simo Sorce wrote: >>>> On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote: >>>>> Simo, I hazily remember discussing that we should only allow specific >>>>> attributes on add, otherwise users can add entries with any extra >>>>> objectclasses and attributes. Did we come to a conclusion? >>>>> I might have confused targetattr with targetattrfilter in my notes; >>>>> since I see targetarr is ineffective. >>>>> >>>> Yes we need to restrict at least the allowed objectclasses I think. >>>> >>>> Simo. >>>> >>> We do not have a support for targetattrfilter, I do not think this was ever >>> tested. This part of ACI is also not very well documented, I think Petr found >>> just one notice in the DS documentation about targetattrfilter. >> It is in chapter 13.2.3.5 in >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets >> >> and it is for unknown reasons: targattrfilters > Right, this is what I (and Petr) was talking about. The doc contain just this > single one line of information about targetattrfilters. Well, it is not much, but more than one line :-) > > 13.3.2.5. Targeting Attribute Values Using LDAP Filters > > You can use access control to target specific attribute values. This > means that you can grant or deny permissions on an attribute if that > attribute's value meets the criteria defined in the ACI. An ACI that > grants or denies access based on an attribute's value is called a > value-based ACI. > For example, you might grant all users in your organization permission > to modify the /|nsroledn|/ attribute in their own entry. However, you > would also want to ensure that they do not give themselves certain key > roles, such as |Top Level Administrator|. LDAP filters are used to > check that the conditions on attribute values are satisfied. > To create a value-based ACI, you must use the |targattrfilters| > keyword with the following syntax: > (targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn,del=attr1:F1 > && /|attr2|/:/|F2|/ ... && /|attrn|/:/|Fn|/") > > * > |add| represents the operation of creating an attribute. > * > |del| represents the operation of deleting an attribute. > * > /attrx/ represents the target attributes. > * > /Fx/ represents filters that apply only to the associated attribute. > > When creating an entry, if a filter applies to an attribute in the new > entry, then each instance of that attribute must satisfy the filter. > When deleting an entry, if a filter applies to an attribute in the > entry, then each instance of that attribute must also satisfy the filter. > When modifying an entry, if the operation adds an attribute, then the > add filter that applies to that attribute must be satisfied; if the > operation deletes an attribute, then the delete filter that applies to > that attribute must be satisfied. If individual values of an attribute > already present in the entry are replaced, then both the add and > delete filters must be satisfied. > For example, consider the following attribute filter: > (targattrfilters="add=nsroledn:(!(nsroledn=cn=superAdmin)) && > telephoneNumber:(telephoneNumber=123*)") > This filter can be used to allow users to add any role (/|nsroledn|/ > attribute) to their own entry, except the |superAdmin| role. It also > allows users to add a telephone number with a 123 prefix. > > * > * > > Try googling that and > you won't get much more. > > Just for completeness, posting one of the top findings: > > Bug 1032767 - Examples of the targetattrfilters ACI keyword need to be documented > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 28 15:15:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 May 2014 17:15:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385FCFF.3050805@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <1401288603.2598.70.camel@willson.li.ssimo.org> <5385F911.4030407@redhat.com> <5385FAD0.40501@redhat.com> <5385FC04.6000304@redhat.com> <5385FCFF.3050805@redhat.com> Message-ID: <5385FD9F.2070605@redhat.com> On 05/28/2014 05:13 PM, Ludwig Krispenz wrote: > > On 05/28/2014 05:08 PM, Martin Kosek wrote: >> On 05/28/2014 05:03 PM, Ludwig Krispenz wrote: >>> On 05/28/2014 04:56 PM, Martin Kosek wrote: >>>> On 05/28/2014 04:50 PM, Simo Sorce wrote: >>>>> On Wed, 2014-05-28 at 16:27 +0200, Petr Viktorin wrote: >>>>>> Simo, I hazily remember discussing that we should only allow specific >>>>>> attributes on add, otherwise users can add entries with any extra >>>>>> objectclasses and attributes. Did we come to a conclusion? >>>>>> I might have confused targetattr with targetattrfilter in my notes; >>>>>> since I see targetarr is ineffective. >>>>>> >>>>> Yes we need to restrict at least the allowed objectclasses I think. >>>>> >>>>> Simo. >>>>> >>>> We do not have a support for targetattrfilter, I do not think this was ever >>>> tested. This part of ACI is also not very well documented, I think Petr found >>>> just one notice in the DS documentation about targetattrfilter. >>> It is in chapter 13.2.3.5 in >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Targets >>> >>> >>> and it is for unknown reasons: targattrfilters >> Right, this is what I (and Petr) was talking about. The doc contain just this >> single one line of information about targetattrfilters. > Well, it is not much, but more than one line :-) Ah, I see, that's much better. The problem was that the guide is referring to "targattrfilters" and not "targetattrfilters" - thus my CTRL+F searching method failed :-). I added a note to the referred Bugzilla. Martin From mbasti at redhat.com Wed May 28 16:48:09 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 18:48:09 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses Message-ID: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/3210 Patches attached. TODO: upgrade procedure http://www.freeipa.org/page/V4/Forward_zones#Updates_and_Upgrades WebUI ticket: https://fedorahosted.org/freeipa/ticket/4357 -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0052-Separate-master-and-forward-DNS-zones.patch Type: text/x-patch Size: 21546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0053-Prevent-commands-to-modify-different-type-of-a-zone.patch Type: text/x-patch Size: 11555 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0054-Create-BASE-zone-class.patch Type: text/x-patch Size: 39944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0055-Tests-DNS-forward-zones.patch Type: text/x-patch Size: 29038 bytes Desc: not available URL: From mbasti at redhat.com Wed May 28 17:04:26 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 19:04:26 +0200 Subject: [Freeipa-devel] [PATCH] 0056 Test DNS: wildcards in name Message-ID: <1401296666.2263.13.camel@unused-4-145.brq.redhat.com> Test for ticket https://fedorahosted.org/freeipa/ticket/3148 Patch attached. Required patches: mbasti 0029-0032, 0034-0040, 0047, 0041-0042, 0045-0046 -- Martin^2 Basti From mbasti at redhat.com Wed May 28 17:11:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 19:11:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> Message-ID: <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> On Wed, 2014-05-28 at 18:48 +0200, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/3210 > Patches attached. > > TODO: upgrade procedure > http://www.freeipa.org/page/V4/Forward_zones#Updates_and_Upgrades > > WebUI ticket: https://fedorahosted.org/freeipa/ticket/4357 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I forgot mention: * Required patches: mbasti 0029-0032, 0034-0040, 0047, 0041-0042, 0045-0046 * For testing you will need to update schema: Add line objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) MAY ( idnsForwarders $ idnsForwardPolicy ) ) into /etc/dirsrv/slapd-$REALM/schema/60ipadns.ldif and restart dirsrv -- Martin^2 Basti From mbasti at redhat.com Wed May 28 17:12:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 28 May 2014 19:12:05 +0200 Subject: [Freeipa-devel] [PATCH] 0056 Test DNS: wildcards in name In-Reply-To: <1401296666.2263.13.camel@unused-4-145.brq.redhat.com> References: <1401296666.2263.13.camel@unused-4-145.brq.redhat.com> Message-ID: <1401297125.2263.21.camel@unused-4-145.brq.redhat.com> On Wed, 2014-05-28 at 19:04 +0200, Martin Basti wrote: > Test for ticket https://fedorahosted.org/freeipa/ticket/3148 > Patch attached. > > Required patches: mbasti 0029-0032, 0034-0040, 0047, > 0041-0042, 0045-0046 Sorry, patch is attached here -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0056-Test-DNS-wildcard-in-RR-owner.patch Type: text/x-patch Size: 2858 bytes Desc: not available URL: From rcritten at redhat.com Wed May 28 17:18:28 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 May 2014 13:18:28 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <1401287429.2598.66.camel@willson.li.ssimo.org> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385EB1F.5030403@redhat.com> <1401287429.2598.66.camel@willson.li.ssimo.org> Message-ID: <53861A64.60200@redhat.com> Simo Sorce wrote: > On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote: >> On 05/28/2014 02:48 PM, Simo Sorce wrote: >>> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >>>> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>>>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>>>> care of the situation. >>>>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>>>> it created. >>>>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>>>> >>>>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>>>> pre-active ... so it can still create what it wants. >>>>>>>>> yes that is correct. >>>>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>>>> the entry in 'active' ? >>>>>>>> Well it really depends on 'who' the operator is. >>>>>>>> >>>>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>>>> design if it makes other things clumsy or suboptimal. >>>>>>>> >>>>>>>> The less privileged operator problem can always be solved by a >>>>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>>>> to getting the workflow right in terms of the way it works. >>>>>>>> >>>>>>>> I think re-creating the user object gives us better chances at handling >>>>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>>>> that route. >>>>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>>>> person if staged object uses extensibleObject object class where we are >>>>>>> in control of what exactly will get into the actual tree. >>>>>> Right it allows us to do things like filter out objectclass or >>>>>> attributes the provisioning system adds but that the admin does not want >>>>>> in the final entry. This is not something we may want to build into the >>>>>> solution from day zero, but it gives us the option to build it more >>>>>> easily, as a framework filter on the 'unstage' operation. >>>>>> (We so need to be able to copy additional objectclasses and their >>>>>> attributes from day 0 though). >>>>>> Simo. >>>>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>>>> information here: >>>>> >>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>>> >>>>> (you can even link this thread in the archives) >>>>> >>>>> Martin >>>> Yes I will do that. >>>> >>>> Regarding workflow, it looks a priority that active entries are valid >>>> (regarding FreeIPA). >>>> Currently CLI offers: >>>> >>>> * ipa user-add (in active) >>>> * ipa user-add --stage (in stage). >>>> >>>> In order to prevent admin to add a corrupted entry in active and force >>>> any entry to go through the filter of objectclass/attribute, we could >>>> make 'ipa user-add' to create entry in staging and 'ipa user-add >>>> --active' to create entry in active. Even more, should we support to add >>>> entry directly in 'active' or rather only support 'user-add' to go only >>>> in staging ? >>> >>> I do not see why this would ever be necessary, ipa user-add cannot >>> create a "corrupt entry" by definition. >>> >>> I am actually not very happy with the "ipa user-add --stage" idea, the >>> staging area is necessary for when you do not create a full 'ipa' user >>> entry, but rather for when a provisioning system creates an "incomplete" >>> entry. >>> >>> Simo. >> >> /me wishes that the major concerns were spelled out during initial RFE review... >> >> Could this help a custom provisioning system that uses FreeIPA user-add >> JSON-RPC command instead of ldapadd? The record may still be incomplete in >> terms of company policy (e.g. missing manager) and about to be moved only when >> the user joins the company? >> >> Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the >> staging area? > > Note that I did not say we should not have an IPA command for that, but > I dislike the idea of putting it in the user plugin and using that > specific command expression. > > I would see something like ipa stage-user-add as a better way > to go, in its own "stage" plugin. > +1 This fits better into the plugin model as well since the container, default objectclasses, etc will be different for these entries. rob From npmccallum at redhat.com Wed May 28 20:44:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 28 May 2014 16:44:25 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <53835641.7040001@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> <53835641.7040001@redhat.com> Message-ID: <1401309865.4631.5.camel@ipa.example.com> 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 = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; > >>>>> acl "Users can create and delete tokens"; allow (add, delete) userattr = > >>>>> "ipatokenOwner#SELFDN";) > >>>>> > >>>>> This is what they look like using managedBy (I have not tested this): > >>>>> > >>>>> 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"; allow (read, search, compare) > >>>>> userattr = "managedBy#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"; allow > >>>>> (read, search, compare) userattr = "managedBy#USERDN";) > >>>>> > >>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > >>>>> see HOTP details"; allow (read, search, compare) userattr = > >>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > >>>>> "managedBy#USERDN";) > >>>>> > >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>>> "description || ipatokenDisabled || ipatokenNotBefore || > >>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > >>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; > >>>>> allow (write) userattr = "managedBy#USERDN";) > >>>>> > >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >>>>> "Managers can delete tokens"; allow (delete) userattr = > >>>>> "managedBy#USERDN";) > >>>>> > >>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > >>>>> userattr = "managedBy#SELFDN";) > >>>>> > >>>>> In short: > >>>>> 1. Owner and manager get read, search and compare. > >>>>> 2. Manager gets write (to select attributes) and delete. > >>>>> 3. Users can create self-managed tokens for themselves only. > >>>>> > >>>>> The otptoken-add command should gain the following defaults: > >>>>> 1. The owner defaults to the user adding the token. > >>>>> 2. If owner == user adding token, managedBy defaults to owner. > >>>>> 3. Otherwise, managedBy defaults to None. > >>>>> > >>>>> This means that if neither owner nor managedBy are specified, the > >>>>> default is a self-owned, self-managed token. Likewise, if a different > >>>>> owner is specified, no manager is assumed. > >>>>> > >>>>> rcrit expresses worry that ipalib's ACI parser may not handle the above > >>>>> syntax. This will become clear during testing if we want this approach. > >>>>> > >>>>> Does this look sane? > >>>> > >>>> I am not entirely sure your ACI syntax is always right for the second > >>>> set. and perhaps we want to duplicate ACIs in some cases (once for owner > >>>> once for manager). > >>>> > >>>> I think the read ACIs do not need to list managedby ? Do we plan to have > >>>> a manager that is another regular user but not the owner nor an admin ? > >>>> > >>>> In any case I prefer the sytnax that uses managedby, as it has more > >>>> potential. > >>> > >>> Attached is a new version of the patch which implements the feature > >>> using managedBy instead of ipatokenProtected. One important thing needs > >>> to be said about this patch. I am not exposing managedBy in either the > >>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I > >>> expose this similar to owner or as a relationship? > >> > >> I would expose it, as a relationship. (Note that ipatokenowner should > >> ideally be represented as a relationship too, but the framework does not > >> support 1-to-many relationships ATM.) > > > > So since this is a 1-to-many relationship we shouldn't expose it? > > > > Or should I do it like owner is currently done? > > Do it like managedby is done in the host plugin (see > "attribute_members", "relationships", etc.) > > > > >> > >> Just curious, why are the ACIs divided like this: > >> > >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers > >> can read basic token info"; allow (read, search, compare) userattr = > >> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > >> "ipatokenOTPalgorithm || ipatokenOTPdigits || > >> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP > >> details"; allow (read, search, compare) userattr = > >> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > >> "Users/managers can see HOTP details"; allow (read, search, compare) > >> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >> > >> IMHO you could make them less complex by dividing them like this: > >> > >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || > >> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can > >> read token details"; allow (read, search, compare) userattr = > >> "ipatokenOwner#USERDN";) > >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || > >> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers > >> can read token details"; allow (read, search, compare) userattr = > >> "managedBy#USERDN";) > > > > The first set is organized by objectClass. The second by userattr. I > > have no strong opinion on this matter, though performance is probably a > > consideration. Do any DS guys want to chime in? > > I would still like to know someone else's opinion on this, but if > there's none, let's keep it your way. > > > > >> Would it make sense to keep --protected as a flag in otptoken-add as a > >> shortcut for "entry_attrs['managedby'] = None"? > > > > I can't think of a use case for this. The only use case I *can* think of > > is an admin creating a non-protected token for a user. > > OK. > > > > >> Would it make sense to default managedby to the current bind DN in > >> otptoken-add, even if it's not a user DN? (Do we want to allow running > >> otptoken-add by hosts/services/other non-users?) > > > > No idea. Dmitri? > > We can add this later if necessary. > > > > >> Is orphaning a token when a user is deleted only if it is not managed by > >> any other users the intended behavior? It just seems sort of strange to > >> me, since it changes the token from unprotected to protected. > > > > I don't think that is the behavior. We orphan the token if the owner is > > not listed as a manager. If the owner is listed as a manager, we delete > > the token. > > > > Put another way, protected tokens are orphaned and unprotected tokens > > are deleted. > > > > If I didn't implement that, please point out my bug. > > Sorry, my bad, your code is right. You can make it simpler, though: > > orphan = [x for x in token.get('managedby', []) if x == dn] > > (The "len() == 0" check is not necessary and using list comprehensions > makes the code more readable than using filter.) The attached version fixes all the above issues. Two issues that may remain: 1. There is no option to set managedBy during otptoken-add or otptoken-mod. This is probably okay. 2. I can't figure out how to get the framework to actually show managedBy in command output (like otptoken-show). This means you can add/remove relationships using otptoken-add-managedby and otptoken-remove-managedby, but you can't actually see the list of managers. What am I missing? Also, it would be helpful if someone with DS expertise could answer the question about the performance of the ACI structure options as listed above. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0049a.1-Add-support-managedBy-to-tokens.patch Type: text/x-patch Size: 17236 bytes Desc: not available URL: From pspacek at redhat.com Wed May 28 20:56:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 28 May 2014 22:56:40 +0200 Subject: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading In-Reply-To: <5385C7C8.3060102@redhat.com> References: <538498FA.7070609@redhat.com> <53849A57.4040106@redhat.com> <5385C7C8.3060102@redhat.com> Message-ID: <53864D88.6030400@redhat.com> On 28.5.2014 13:26, Tomas Hozza wrote: > On 05/27/2014 03:59 PM, Petr Spacek wrote: >> On 27.5.2014 15:54, Petr Spacek wrote: >>> Fix race condition during zone loading. >>> >>> DNS zone has to be added to DNS view before dns_zone_load() is called. >>> It is necessary to prevent dns_zone_load() from racing with >>> dns_zone_setview(). >>> >>> This race condition sometimes prevents zone from being signed. >>> Now the unsigned zone is visible until signing process is complete. This >>> mimics BIND behavior for in-line signed zones. >>> >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >> >> And here is the patch... >> > > Hi. > > When I use bind-dyndb-ldap plugin with this patch, named > does not start due to: > > rbt.c:1379: REQUIRE(name->buffer != ((void *)0)) failed, back trace > > (gdb) bt > #0 0x00007f3963924c39 in raise () from /lib64/libc.so.6 > #1 0x00007f3963926348 in abort () from /lib64/libc.so.6 > #2 0x00007f3966979aee in assertion_failed () > #3 0x00007f3964b6917a in isc_assertion_failed () from /lib64/libisc.so.95 > #4 0x00007f39661ca9da in dns_rbt_fullnamefromnode () from > /lib64/libdns.so.100 > #5 0x00007f396011824b in rbt_iter_getnodename (iter=, > nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:46 > #6 0x00007f396011839b in rbt_iter_next > (iterp=iterp at entry=0x7f39625f8b90, > nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:144 > #7 0x00007f3960112d32 in activate_zones > (task=task at entry=0x7f39668f5790, inst=0x7f39668e4160) at ldap_helper.c:1164 > #8 0x00007f396011a20d in barrier_decrement (task=0x7f39668f5790, > event=0x7f396005b010) at syncrepl.c:138 > #9 0x00007f3964b8b836 in run () from /lib64/libisc.so.95 > #10 0x00007f396473ff33 in start_thread () from /lib64/libpthread.so.0 > #11 0x00007f39639e3ded in clone () from /lib64/libc.so.6 > > > It looks like you should use INIT_BUFFERED_NAME(name); used in the > original code instead of dns_name_init(&name, NULL). The macro > initializes the buffer in "name", which is missing in the new code. Oh yes, it didn't happened on my machine because I have had only single zone defined in LDAP at the time of testing. Thank you for catching this! I'm attaching fixed patch. dns_name_reset() is good enough in this case. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0257-2-Fix-race-condition-during-zone-loading.patch Type: text/x-patch Size: 5192 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 28 23:23:00 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 29 May 2014 09:23:00 +1000 Subject: [Freeipa-devel] running out of entropy during ipa-server-install In-Reply-To: <5385CA9D.9090703@redhat.com> References: <20140528070621.GF28407@dhcp-40-8.bne.redhat.com> <5385B581.8090501@redhat.com> <5385CA9D.9090703@redhat.com> Message-ID: <20140528232300.GA804@dhcp-40-8.bne.redhat.com> On Wed, May 28, 2014 at 01:38:05PM +0200, Martin Kosek wrote: > On 05/28/2014 12:08 PM, Petr Viktorin wrote: > > On 05/28/2014 09:06 AM, Fraser Tweedale wrote: > >> Hi all, > >> > >> Today I hit the "WARNING: Your system is running out of entropy, you > >> may experience long delays" message while testing Ade's > >> ipa-server-install changes. > >> > >> I got a lot more entropy a lot faster by installing haveged(8), and > >> I blogged about it here: > >> http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/ > >> > >> Do you think it would be worthwhile to update the above warning > >> message to additionally suggest installing haveged(8) or pointing to > >> other help on remediating a low-entropy system? > >> > >> Cheers, > >> > >> Fraser > > > > Hello, > > haveged is not the only solution. As you note there's also rngd; and with > > modern virtualization systems VMs can get entropy from the host. If we suggest > > a concrete solution we should be reasonably sure it's the best one. > > AFAK, for RHEL/CentOS haveged is only in EPEL, we probably don't want to > > suggest it there. > > > > I think the key point here is that FreeIPA announces that the entropy is low > thus giving the administrator an option to do his homework on "how to increase > entropy on my system" - for example by reading Fraser's blog :-) > > I also do not think that FreeIPA should give any more recommendations on top of > that. > > Thanks, > Martin Fair enough; all good points. Thanks for the feedback. Fraser From ftweedal at redhat.com Thu May 29 01:20:36 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 29 May 2014 11:20:36 +1000 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <5385EA3D.8000505@redhat.com> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> <1399693089.26524.14.camel@aleeredhat.laptop> <1401227860.9297.9.camel@aleeredhat.laptop> <20140528064818.GE28407@dhcp-40-8.bne.redhat.com> <5385EA3D.8000505@redhat.com> Message-ID: <20140529012036.GB3128@dhcp-40-8.bne.redhat.com> On Wed, May 28, 2014 at 03:53:01PM +0200, Petr Viktorin wrote: > On 05/28/2014 08:48 AM, Fraser Tweedale wrote: > >On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote: > >>There have been a couple of changes in the Dogtag interface, that > >>require some changes in the IPA patches. Also, I had to add back a > >>function in order to rebase to the latest IPA code. > >> > >>Most are the patches are as before, attached to this email by default. > >> > >>The latest Dogtag 10.2 build with the relevant changes needed to work > >>with these patches is at: > >>http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ > >> > >>Ade > >> > > > >ACK. > > > >ipa-server-install worked fine for me, and the formatting changes > >seem good. Patch 0003 did not apply cleanly on master (due to minor > >conflict in 71c6d2f:installutils.py); an updated patch 0003 is > >attached. > > Hello, > If you do a rebase, could you attach all the patches again? > I don't have the Git objects that result from the original patch, so `git > am` fails on the later patches: > Cool, I didn't know about `git am`s 3-way merge capability. The resolution is trivial so I'll leave it at that. Still an ACK for patches 0002..0005 inclusive :) > $ git am -3 *.patch > Applying: Add a DRM to IPA > Applying: Added ipa-drm-install > Applying: Fix various pep 8 issues and comments from review > Applying: Added nolog to pkispawn and some additional fixes from review. > Applying: Added dogtag plugin for DRM > Applying: set drm to not install by default with ipa-server-install > Applying: Allow ipa-replica-install to be used for installing replicas > error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b for > 'install/tools/ipa-replica-install' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0007 Allow ipa-replica-install to be used for installing > replicas > The copy of the patch that failed is found in: > /home/pviktori/freeipa/.git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > -- > Petr? From dpal at redhat.com Thu May 29 02:09:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 22:09:21 -0400 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users In-Reply-To: <537E0AAA.5090100@redhat.com> References: <537E0AAA.5090100@redhat.com> Message-ID: <538696D1.1000002@redhat.com> On 05/22/2014 10:33 AM, thierry bordaz wrote: > Hello, > > In order to provision staged users (account inactivated) with > there initial values: > > /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 > ----------------- > Added user "tb20" > ----------------- > User login: tb20 > First name: tb20 > Last name: tb20 > Full name: tb20 tb20 > Display name: tb20 tb20 > Initials: tt > Home directory: /home/tb20 > GECOS: tb20 tb20 > Login shell: /bin/sh > Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM > Email address: tb20 at idm.lab.bos.redhat.com > UID: -1 > GID: -1 > Account disabled: true > Password: False > Kerberos keys available: False > > ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" > -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 > dn: uid=tb20,cn=staged > users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > dc=redhat,dc=com > displayName: tb20 tb20 > cn: tb20 tb20 > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipasshuser > objectClass: ipaSshGroupOfPubKeys > loginShell: /bin/sh > uidNumber: -1 > ipaUniqueID: autogenerate > gidNumber: -1 > gecos: tb20 tb20 > sn: tb20 > homeDirectory: /home/tb20 > uid: tb20 > mail: tb20 at idm.lab.bos.redhat.com > krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM > givenName: tb20 > initials: tt > > I needed to resctrict the scope of the following plugins: > > dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config > nsslapd-pluginarg1: > cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi > ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > dn: cn=Posix IDs,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > dn: cn=MemberOf Plugin,cn=plugins,cn=config > memberofentryscope: > cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > In fact I need them to not modify the added entry when it is added > under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". > Now is it possible to limit those plugins scope to the > 'cn=accounts' part of the tree ? I guess not. > If it is not possible, a solution is to make the scope > multi-valued attributes or to introduce a new config attribute > '*notInScope' also multi-valued. > A problem is the 'cn=ipaUniqueID uniqueness' that rely on the > 'attribute uniqueness' plugin with a argv[ ], not really > convenient to pass 2 multivalued attributes. > > If anyone is having others solutions it would help me a lot :-) > > thanks > thierry > > The easiest solution IMO is to not treat staging area as an account area, i.e instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, cn=staging, dc=... This way if in future we will have some staging for other objects (for whatever reason) we will create containers under common "staging" area. I would also argue that "deleted" should not be under accounts. > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu May 29 02:44:16 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 22:44:16 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5384BFD4.3020307@redhat.com> References: <5384578C.6090603@redhat.com> <53846093.4030302@redhat.com> <5384707C.60705@redhat.com> <1401192984.7561.176.camel@willson.li.ssimo.org> <538482D4.1040503@redhat.com> <1401193374.7561.178.camel@willson.li.ssimo.org> <538485C6.3020207@redhat.com> <538487BC.3070506@redhat.com> <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> Message-ID: <53869F00.4000109@redhat.com> On 05/27/2014 12:39 PM, thierry bordaz wrote: > On 05/27/2014 06:06 PM, Simo Sorce wrote: >> On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote: >>> On 05/27/2014 04:35 PM, Martin Kosek wrote: >>>> On 05/27/2014 04:27 PM, Simo Sorce wrote: >>>>> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: >>>>>> This topic was already discussed in the past, see following part of >>>>>> the design: >>>>>> >>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>>>> >>>>>> >>>>>> One of the biggest concern was that to allow operator unstage a >>>>>> user, >>>>>> he would >>>>>> need to have a delete ACI in staging container AND add ACI in the >>>>>> active users >>>>>> area - which would also allow him to create any user he wishes in >>>>>> the >>>>>> users area. >>>>>> >>>>>> This is the reason why we preferred to do and control it via MODRDN >>>>>> and the >>>>>> reason why Thierry implemented the new ACI for controlling MODRDN >>>>>> operation: >>>>>> >>>>>> https://fedorahosted.org/389/ticket/47553 >>>>>> >>>>> I know that's why we did it, but I had a hard look since then, and I >>>>> believe we cannot really use that method. >>>>> >>>>> The reason is simply that we do not control who adds the user >>>>> object and >>>>> our reason to do the staging is to make it simple for an external >>>>> provisioning system to create a basic user entry the way it knows how >>>>> to, with only the attributes the provisioning system cares about. >>>>> >>>>> But this means we have no guarantee of what objectclasses are >>>>> available >>>>> on the object, so we have no guarantees all the necessary structureal >>>>> objectclasses have been added in the staging object. >>>>> >>>>> We have to recreate the user object in order to be able to add all >>>>> the >>>>> right structural objectclasses as those can only be added at object >>>>> creation time in an LDAPv3 compliant LDAP server. >>> Both approach looks possible: >>> >>> * adding required structural OC+AT in the existing entry >>> * creating a new entry with all structural OC+AT and update the AT >>> values with what exists in the stage entry >>> >>> but I think the second one would be simpler to implement. >> My assessment too. >> >>> Here again uid uniqueness is a difficulty: if 'uid' exists in stage >>> entry we need to delete the stage entry before adding the active one. >>> There is a risk to loose the entry if the add fails. Also it is >>> important to apply DEL/ADD on the same replica so that DEL csn < ADD >>> csn. >> I think the solution is to not have the uid uniqueness plugin look into >> the staging tree. I think it is fair to put the burden of not creatoing >> conflicting uids in the provisioning system the drives creating the >> staged entries. >> >> If a staged entry has a conflicting uid then at unstaging time we will >> throw an error and the admin will have to fix the staged entry (either >> remove it and ask the provisioning people to re-provision, or modifying >> it). > > Ok great. >> >>>>> Recreating the object will also allow you to deal with the other case >>>>> you brought forward where the provisioning system used CN as the RDN, >>>>> but we want uid. >>> I am not sure: if some provisioning systems created the two entries >>> >>> # entry 1 >>> dn: ou=TestUser,cn=staged >>> users,cn=accounts,cn=provisioning,dc=example,dc=com >>> objectClass: top >>> objectClass: account >>> uid: xxx >>> ou: TestUser >>> >>> # entry 2 >>> dn: uid=TestUser,cn=staged >>> users,cn=accounts,cn=provisioning,dc=example,dc=com >>> objectClass: top >>> objectClass: posixAccount >>> cn: TestUser >>> uid: TestUser >>> ipaUniqueID: autogenerate >>> uidNumber: -1 >>> gidNumber: -1 >>> >>> >>> If we activate both entries. we will create a new entry with all the >>> required objectclass but at the end we will need to pick up a 'uid' >>> value. >>> Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' >>> but then it changes the RDN value or 'TestUser' (the former RDN >>> value) that is in collision with entry 2. >>> >>> I think it would simplify the problem if we enforce that staged >>> entries have 'uid' RDN. >> To be honest I do not see the problem. >> >> We just need to care about the 'uid' attribute in the staged entry, and >> pick that to generate the RDN of the user in the active tree. If there >> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >> will just fail (due to non unique RDN) and the admin will have to take >> care of the situation. > In that case the provisioning system created a staging entry > ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE > It could be an issue for the provisioning system to retrieve the entry > it created. > >> >>>>> I understand it gives operators a higher privilege, but I think we'll >>>>> have to think harder how to properly handle the issue. >>> A possibility is to create a "pre-active" status, between 'stage' and >>> 'active'. >>> The 'stage' container contains raw provisioned entries. 'pre-active' a >>> copy of the 'stage' entry with all the structural objectclasses. >>> >>> If 'pre-active' is out of the scope of uid uniqueness, we can add the >>> 'pre-active' entry before removing the 'stage' entry (and rollback in >>> case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' >>> -> 'active'. >> Sounds like a lot of complexity for a problem we do not really have, all >> we need is to not enforce uniqueness in staging. > > This proposal was also to limit the operator privilege to do MODRDN > from 'pre-active' to 'active', instead ADD on 'active'. Just a note: The modrdn privilege is needed for moving users from normal to deleted and from deleted to normal or to staging. This was its primary intent of the RFE. It was not for staging to normal as that use case can in fact be addressed by adding a normal entry and then deleting the staged entry. >> >> Simo. >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu May 29 02:50:02 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 22:50:02 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <53861A64.60200@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385EB1F.5030403@redhat.com> <1401287429.2598.66.camel@willson.li.ssimo.org> <53861A64.60200@redhat.com> Message-ID: <5386A05A.2090909@redhat.com> On 05/28/2014 01:18 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote: >>> On 05/28/2014 02:48 PM, Simo Sorce wrote: >>>> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >>>>> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>>>>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>>>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>>>>> We just need to care about the 'uid' attribute in the staged entry, and >>>>>>>>>>>>> pick that to generate the RDN of the user in the active tree. If there >>>>>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation >>>>>>>>>>>>> will just fail (due to non unique RDN) and the admin will have to take >>>>>>>>>>>>> care of the situation. >>>>>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>>>>> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE >>>>>>>>>>>> It could be an issue for the provisioning system to retrieve the entry >>>>>>>>>>>> it created. >>>>>>>>>>> Too bad for the provisioning system, we are not going to allow users to >>>>>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>>>>> >>>>>>>>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>>>>> It is not useful, the operator still needs to be able to create in >>>>>>>>>>> pre-active ... so it can still create what it wants. >>>>>>>>>> yes that is correct. >>>>>>>>>> Does it address the security concern, if the operator that is allowed to >>>>>>>>>> add in 'staging'/'pre-active' is different from the one allowed to move >>>>>>>>>> the entry in 'active' ? >>>>>>>>> Well it really depends on 'who' the operator is. >>>>>>>>> >>>>>>>>> We would like to be able to allow a 'junior admin/helpdesk person' to >>>>>>>>> just press a button to activate a user, but that shouldn't drive our >>>>>>>>> design if it makes other things clumsy or suboptimal. >>>>>>>>> >>>>>>>>> The less privileged operator problem can always be solved by a >>>>>>>>> middle-man script that has higher privileges. So we nee to give priority >>>>>>>>> to getting the workflow right in terms of the way it works. >>>>>>>>> >>>>>>>>> I think re-creating the user object gives us better chances at handling >>>>>>>>> the overall workflow and fixing up entries accordingly to the management >>>>>>>>> framework view of what a user needs to look like, so in the end I prefer >>>>>>>>> that route. >>>>>>>> I agree. It also opens us a way to handle import of any foreign schema >>>>>>>> person if staged object uses extensibleObject object class where we are >>>>>>>> in control of what exactly will get into the actual tree. >>>>>>> Right it allows us to do things like filter out objectclass or >>>>>>> attributes the provisioning system adds but that the admin does not want >>>>>>> in the final entry. This is not something we may want to build into the >>>>>>> solution from day zero, but it gives us the option to build it more >>>>>>> easily, as a framework filter on the 'unstage' operation. >>>>>>> (We so need to be able to copy additional objectclasses and their >>>>>>> attributes from day 0 though). >>>>>>> Simo. >>>>>> Ok, thanks guys, I see an agreement. Thierry, we should now update all the >>>>>> information here: >>>>>> >>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>>>> >>>>>> (you can even link this thread in the archives) >>>>>> >>>>>> Martin >>>>> Yes I will do that. >>>>> >>>>> Regarding workflow, it looks a priority that active entries are valid >>>>> (regarding FreeIPA). >>>>> Currently CLI offers: >>>>> >>>>> * ipa user-add (in active) >>>>> * ipa user-add --stage (in stage). >>>>> >>>>> In order to prevent admin to add a corrupted entry in active and force >>>>> any entry to go through the filter of objectclass/attribute, we could >>>>> make 'ipa user-add' to create entry in staging and 'ipa user-add >>>>> --active' to create entry in active. Even more, should we support to add >>>>> entry directly in 'active' or rather only support 'user-add' to go only >>>>> in staging ? >>>> I do not see why this would ever be necessary, ipa user-add cannot >>>> create a "corrupt entry" by definition. >>>> >>>> I am actually not very happy with the "ipa user-add --stage" idea, the >>>> staging area is necessary for when you do not create a full 'ipa' user >>>> entry, but rather for when a provisioning system creates an "incomplete" >>>> entry. >>>> >>>> Simo. >>> /me wishes that the major concerns were spelled out during initial RFE review... >>> >>> Could this help a custom provisioning system that uses FreeIPA user-add >>> JSON-RPC command instead of ldapadd? The record may still be incomplete in >>> terms of company policy (e.g. missing manager) and about to be moved only when >>> the user joins the company? >>> >>> Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the >>> staging area? >> Note that I did not say we should not have an IPA command for that, but >> I dislike the idea of putting it in the user plugin and using that >> specific command expression. >> >> I would see something like ipa stage-user-add as a better way >> to go, in its own "stage" plugin. >> > +1 > > This fits better into the plugin model as well since the container, > default objectclasses, etc will be different for these entries. > > rob +1 I was actually suggesting this too. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu May 29 02:53:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 22:53:28 -0400 Subject: [Freeipa-devel] Supported Staged entries In-Reply-To: <5386A05A.2090909@redhat.com> References: <1401196093.7561.185.camel@willson.li.ssimo.org> <53849142.8030709@redhat.com> <1401200878.7561.193.camel@willson.li.ssimo.org> <5384A2C0.1050500@redhat.com> <5384B569.6080806@redhat.com> <1401206771.2598.5.camel@willson.li.ssimo.org> <5384BFD4.3020307@redhat.com> <1401209769.2598.9.camel@willson.li.ssimo.org> <5384D26E.5000802@redhat.com> <1401214114.2598.15.camel@willson.li.ssimo.org> <20140527181445.GA10924@redhat.com> <1401214714.2598.17.camel@willson.li.ssimo.org> <538580A2.60508@redhat.com> <5385927F.5030302@redhat.com> <1401281308.2598.57.camel@willson.li.ssimo.org> <5385EB1F.5030403@redhat.com> <1401287429.2598.66.camel@willson.li.ssimo.org> <53861A64.60200@redhat.com> <5386A05A.2090909@redhat.com> Message-ID: <5386A128.1010706@redhat.com> On 05/28/2014 10:50 PM, Dmitri Pal wrote: > On 05/28/2014 01:18 PM, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote: >>>> On 05/28/2014 02:48 PM, Simo Sorce wrote: >>>>> On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: >>>>>> On 05/28/2014 08:22 AM, Martin Kosek wrote: >>>>>>> On 05/27/2014 08:18 PM, Simo Sorce wrote: >>>>>>>> On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >>>>>>>>> On Tue, 27 May 2014, Simo Sorce wrote: >>>>>>>>>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>>>>>>>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>>>>>>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>>>>>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>>>>>>>>> We just need to care about the 'uid' attribute in the >>>>>>>>>>>>>> staged entry, and >>>>>>>>>>>>>> pick that to generate the RDN of the user in the active >>>>>>>>>>>>>> tree. If there >>>>>>>>>>>>>> are conflicts the 'unstage' will fail cleanly, as the >>>>>>>>>>>>>> 'add' operation >>>>>>>>>>>>>> will just fail (due to non unique RDN) and the admin will >>>>>>>>>>>>>> have to take >>>>>>>>>>>>>> care of the situation. >>>>>>>>>>>>> In that case the provisioning system created a staging entry >>>>>>>>>>>>> ou=TestUser,$STAGING, it will get an active entry >>>>>>>>>>>>> uid=xxx,$ACTIVE >>>>>>>>>>>>> It could be an issue for the provisioning system to >>>>>>>>>>>>> retrieve the entry >>>>>>>>>>>>> it created. >>>>>>>>>>>> Too bad for the provisioning system, we are not going to >>>>>>>>>>>> allow users to >>>>>>>>>>>> have a form that does not use uid in the RDN in IPA. >>>>>>>>>>>> >>>>>>>>>>>>>> Sounds like a lot of complexity for a problem we do not >>>>>>>>>>>>>> really have, all >>>>>>>>>>>>>> we need is to not enforce uniqueness in staging. >>>>>>>>>>>>> This proposal was also to limit the operator privilege to >>>>>>>>>>>>> do MODRDN from >>>>>>>>>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>>>>>>>>> It is not useful, the operator still needs to be able to >>>>>>>>>>>> create in >>>>>>>>>>>> pre-active ... so it can still create what it wants. >>>>>>>>>>> yes that is correct. >>>>>>>>>>> Does it address the security concern, if the operator that >>>>>>>>>>> is allowed to >>>>>>>>>>> add in 'staging'/'pre-active' is different from the one >>>>>>>>>>> allowed to move >>>>>>>>>>> the entry in 'active' ? >>>>>>>>>> Well it really depends on 'who' the operator is. >>>>>>>>>> >>>>>>>>>> We would like to be able to allow a 'junior admin/helpdesk >>>>>>>>>> person' to >>>>>>>>>> just press a button to activate a user, but that shouldn't >>>>>>>>>> drive our >>>>>>>>>> design if it makes other things clumsy or suboptimal. >>>>>>>>>> >>>>>>>>>> The less privileged operator problem can always be solved by a >>>>>>>>>> middle-man script that has higher privileges. So we nee to >>>>>>>>>> give priority >>>>>>>>>> to getting the workflow right in terms of the way it works. >>>>>>>>>> >>>>>>>>>> I think re-creating the user object gives us better chances >>>>>>>>>> at handling >>>>>>>>>> the overall workflow and fixing up entries accordingly to the >>>>>>>>>> management >>>>>>>>>> framework view of what a user needs to look like, so in the >>>>>>>>>> end I prefer >>>>>>>>>> that route. >>>>>>>>> I agree. It also opens us a way to handle import of any >>>>>>>>> foreign schema >>>>>>>>> person if staged object uses extensibleObject object class >>>>>>>>> where we are >>>>>>>>> in control of what exactly will get into the actual tree. >>>>>>>> Right it allows us to do things like filter out objectclass or >>>>>>>> attributes the provisioning system adds but that the admin does >>>>>>>> not want >>>>>>>> in the final entry. This is not something we may want to build >>>>>>>> into the >>>>>>>> solution from day zero, but it gives us the option to build it >>>>>>>> more >>>>>>>> easily, as a framework filter on the 'unstage' operation. >>>>>>>> (We so need to be able to copy additional objectclasses and their >>>>>>>> attributes from day 0 though). >>>>>>>> Simo. >>>>>>> Ok, thanks guys, I see an agreement. Thierry, we should now >>>>>>> update all the >>>>>>> information here: >>>>>>> >>>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP >>>>>>> >>>>>>> >>>>>>> (you can even link this thread in the archives) >>>>>>> >>>>>>> Martin >>>>>> Yes I will do that. >>>>>> >>>>>> Regarding workflow, it looks a priority that active entries are >>>>>> valid >>>>>> (regarding FreeIPA). >>>>>> Currently CLI offers: >>>>>> >>>>>> * ipa user-add (in active) >>>>>> * ipa user-add --stage (in stage). >>>>>> >>>>>> In order to prevent admin to add a corrupted entry in active and >>>>>> force >>>>>> any entry to go through the filter of objectclass/attribute, we >>>>>> could >>>>>> make 'ipa user-add' to create entry in staging and 'ipa user-add >>>>>> --active' to create entry in active. Even more, should we support >>>>>> to add >>>>>> entry directly in 'active' or rather only support 'user-add' to >>>>>> go only >>>>>> in staging ? >>>>> I do not see why this would ever be necessary, ipa user-add cannot >>>>> create a "corrupt entry" by definition. >>>>> >>>>> I am actually not very happy with the "ipa user-add --stage" idea, >>>>> the >>>>> staging area is necessary for when you do not create a full 'ipa' >>>>> user >>>>> entry, but rather for when a provisioning system creates an >>>>> "incomplete" >>>>> entry. >>>>> >>>>> Simo. >>>> /me wishes that the major concerns were spelled out during initial >>>> RFE review... >>>> >>>> Could this help a custom provisioning system that uses FreeIPA >>>> user-add >>>> JSON-RPC command instead of ldapadd? The record may still be >>>> incomplete in >>>> terms of company policy (e.g. missing manager) and about to be >>>> moved only when >>>> the user joins the company? >>>> >>>> Or is this nonsense and we should avoid doing >>>> user-add/user-mod/user-del in the >>>> staging area? >>> Note that I did not say we should not have an IPA command for that, but >>> I dislike the idea of putting it in the user plugin and using that >>> specific command expression. >>> >>> I would see something like ipa stage-user-add as a better >>> way >>> to go, in its own "stage" plugin. >>> >> +1 >> >> This fits better into the plugin model as well since the container, >> default objectclasses, etc will be different for these entries. >> >> rob > > +1 I was actually suggesting this too. I also do not like the term "unstage". This is not intuitive. May be to create users (and other objects in future) from staging entry we should use 'ipa provision-user ...' command? > >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu May 29 03:15:27 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 23:15:27 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1401220340.2598.31.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> Message-ID: <5386A64F.7040206@redhat.com> On 05/27/2014 03:52 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: >> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: >>> Hi, >>> >>> I have started to write a design page for 'Migrating existing >>> environments to Trust' >>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >>> https://fedorahosted.org/freeipa/ticket/3979 . >>> >> while working on a new version of the page with more details on design >> and implementation I came across the following problem. On the IPA >> server there should be a way for SSSD to deliver unmodified data (no >> view applied) or views other than the one for the IPA server to >> processes which delivers user and group data to other clients. This are >> mainly the extdom and the compat plugin of dirsrv. >> >> The two currently use standard glibc calls like getpwnam_r() to get the >> needed data from SSSD. While they can read the view objects form the >> LDAP tree there is no way to read the original data for users from >> trusted domains because it is only in the cache of SSSD. >> >> I'm looking for a way to allow SSSD to deliver the data without changing >> the protocol used by the NSS responder. >> >> One way I can think of is to use a new socket like >> /var/lib/sss/pipes/nss_noview and create a small library for the extdom >> and compat plugin to use the new socket. With this the plugin have to >> apply the views on their own if needed. >> >> Another way would be a new command for the NSS responder with two >> arguments, the view name (or empty for unmodified data) and a blob which >> contains the data for the corresponding request like e.g. getpwnam_r() or >> getgrgid_r(). Here the plugins have to use some new calls but all view >> processing can happen in sssd and the plugins can deliver the data >> directly. >> >> A drawback in both cases is that the memcache cannot be used. >> >> If someone has suggestions for SSSD or other ways how to deliver user >> and group data to client with other views than the IPA server I'm all >> ears. > Ok this one is hard to deal with in a way that will satisfy every > possible user. > > I think what we need to aim is simplicity and predictability at the > expense of flexibility. > > What I mean is that freeipa servers should be allowed to only stick to > one view, the default view for external users. I do not understand what you mean by "one" view? Server should be able to have "all" views. "View" is an equivalent of the "zones". SSSD has to get raw data from the external domain and give it to IPA. IPA would have to merge the data coming from SSSD in server mode with some set of data associated with a subset of clients. I am not sure how it will be done (compat, cos or some other mechanism) but this is the requirement. So for clarity let me restate the use cases: a) I had my users in a NIS or LDAP with POSIX attributes there. I used to sync users from AD. I migrate from that to IPA but want to use trust for my users because AD is authoritative source and I do not want/can put POSIX into AD. b) I have several NIS domains that I need to consolidate. For whatever reasons I can't migrate to the unified POSIX namespace. I want an equivalent of the Centrify Zones when different clients get different uid/gid assignments for the same users. c) I used sync so my POSIX attributes are in IPA but now I want to switch to trust. d) I had a third party solution that had posix zoning and I want to replace it with the similar solution based on IPA. Views (plural) are a way to merge data and present it to a subset of clients. In this context it is not really clear what you mean by "one" view. > > And then the extdom plugin will be allowed to overlay a different view > for specific clients. > But the default view is the baseline, no special behavior. > If you need to 're'-override some attributes in specific views, so be > it. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu May 29 03:18:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 23:18:50 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <1400864498.7561.155.camel@willson.li.ssimo.org> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F031E.8070701@redhat.com> <537F6D85.6040103@redhat.com> <1400864498.7561.155.camel@willson.li.ssimo.org> Message-ID: <5386A71A.7040906@redhat.com> On 05/23/2014 01:01 PM, Simo Sorce wrote: > On Fri, 2014-05-23 at 17:47 +0200, thierry bordaz wrote: >> About membership. I think it could be risky to keep membership in >> 'delete' or 'stage'. Those entries are not valid user and should not >> belong to any active group. Should we keep membership attributes in >> those state or let the plugin recompute the valid values when the >> entry >> is back to active ? >> > Recompute. > When a user is deleted it loses the memberships, when it is reactivated > then new memberships need to be computed or explicitly added. > > Simo. > Yes. This was a part of the initial design. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Thu May 29 03:20:46 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 May 2014 23:20:46 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <5386A64F.7040206@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> Message-ID: <1401333646.3590.4.camel@willson.li.ssimo.org> On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: > On 05/27/2014 03:52 PM, Simo Sorce wrote: > > On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: > >> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > >>> Hi, > >>> > >>> I have started to write a design page for 'Migrating existing > >>> environments to Trust' > >>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > >>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > >>> https://fedorahosted.org/freeipa/ticket/3979 . > >>> > >> while working on a new version of the page with more details on design > >> and implementation I came across the following problem. On the IPA > >> server there should be a way for SSSD to deliver unmodified data (no > >> view applied) or views other than the one for the IPA server to > >> processes which delivers user and group data to other clients. This are > >> mainly the extdom and the compat plugin of dirsrv. > >> > >> The two currently use standard glibc calls like getpwnam_r() to get the > >> needed data from SSSD. While they can read the view objects form the > >> LDAP tree there is no way to read the original data for users from > >> trusted domains because it is only in the cache of SSSD. > >> > >> I'm looking for a way to allow SSSD to deliver the data without changing > >> the protocol used by the NSS responder. > >> > >> One way I can think of is to use a new socket like > >> /var/lib/sss/pipes/nss_noview and create a small library for the extdom > >> and compat plugin to use the new socket. With this the plugin have to > >> apply the views on their own if needed. > >> > >> Another way would be a new command for the NSS responder with two > >> arguments, the view name (or empty for unmodified data) and a blob which > >> contains the data for the corresponding request like e.g. getpwnam_r() or > >> getgrgid_r(). Here the plugins have to use some new calls but all view > >> processing can happen in sssd and the plugins can deliver the data > >> directly. > >> > >> A drawback in both cases is that the memcache cannot be used. > >> > >> If someone has suggestions for SSSD or other ways how to deliver user > >> and group data to client with other views than the IPA server I'm all > >> ears. > > Ok this one is hard to deal with in a way that will satisfy every > > possible user. > > > > I think what we need to aim is simplicity and predictability at the > > expense of flexibility. > > > > What I mean is that freeipa servers should be allowed to only stick to > > one view, the default view for external users. > > I do not understand what you mean by "one" view? The "one" view is the view exposed via the (default) compat tree. > Server should be able to have "all" views. > "View" is an equivalent of the "zones". > > SSSD has to get raw data from the external domain and give it to IPA. > IPA would have to merge the data coming from SSSD in server mode with > some set of data associated with a subset of clients. > I am not sure how it will be done (compat, cos or some other mechanism) > but this is the requirement. This would require multiple compat trees, one per view, it would be very expensive. > So for clarity let me restate the use cases: > > a) I had my users in a NIS or LDAP with POSIX attributes there. I used > to sync users from AD. I migrate from that to IPA but want to use trust > for my users because AD is authoritative source and I do not want/can > put POSIX into AD. > b) I have several NIS domains that I need to consolidate. For whatever > reasons I can't migrate to the unified POSIX namespace. I want an > equivalent of the Centrify Zones when different clients get different > uid/gid assignments for the same users. > c) I used sync so my POSIX attributes are in IPA but now I want to > switch to trust. > d) I had a third party solution that had posix zoning and I want to > replace it with the similar solution based on IPA. > > Views (plural) are a way to merge data and present it to a subset of > clients. In this context it is not really clear what you mean by "one" > view. In order to see views you'll need a modern SSSD client that knows how to apply them. Ie viewS are applied on the client side. The server shows only one view via LDAP. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu May 29 03:31:42 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 May 2014 23:31:42 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5382D607.5070407@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> Message-ID: <5386AA1E.3050505@redhat.com> On 05/26/2014 01:49 AM, Martin Kosek wrote: > On 05/23/2014 04:55 PM, Simo Sorce wrote: >> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>> This, I believe, has already been covered, but I'm concerned with the >>> (over)use of active/inactive in this discussion. >>> >>> I think use of "inactive" and "active" to describe users might be >>> confusing since there is already an account enable/disable command. >>> This >>> on top of unlock, are there now 3 possible boolean states a user can >>> be >>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>> deleted/active and staged/active? >>> >> Agree, we should only have "ipa user-unstage " and not call >> this operations with words like active/inactive. >> >> User's in the staging area are not inactive, they are *not* users yet in >> the first place. >> >> Simo. >> > > Ok. Let us consolidate the decisions, I think we are now running in > circles. Let me start from Petr3's API proposal which was a > functionally complete proposal and start from there: > > On 05/22/2014 10:47 AM, Petr Viktorin wrote: > > ... > > My proposal would be that the move commands use the verb for the > target and an > > option for the source, and add/mod use an option for the container: > > > > 1) adding a new user > > (to active) ipa user-add tuser ... > > (to stage) ipa user-add tuser --staged ... > > Ok. > > > (to deleted) ipa user-add tuser --deleted ... (*) > > Not needed. > > > 2) moving to main > > (from stage) ipa user-activate tuser (**) > > (from del) ipa user-activate tuser --deleted > > We need both, alternative is Simo's proposal: > > ipa user-unstage > ipa user-undelete > > I personally like unstage and undelete commands, I would go with those. Sorry for coming late to the party. I strongly do not like "unstage" This suggests that the user will be removed from staged but does not indicate that the full user will be created. As I suggested elsewhere provision-user or user-provision (or may be even user-add --from-stage) would be better. > > > > 3) moving to deleted > > (from active) ipa user-del tuser > > Ok. > > > (from stage) ipa user-del tuser --staged > > IMO staged deleted users should not be moved to deleted container, but > simply permanently deleted. As Simo noted, staged user are not real > users, just incomplete users. > > > 4) moving to stage > > (from active) ipa user-stage tuser This was suggested for completeness. I think we are cutting corners but I would not insist here. > > (from del) ipa user-stage tuser --deleted > > None of the commands are needed for the basic workflow. But this is a valid use case. I created a user, deleted it and want to rebuild it becuase something got corrupted in the original entry. I agree it is not a primary use case but then we should have a ticket to track this RFE for future. > > > 5) modifying > > (in active) ipa user-mod tuser ... > > Ok. > > > (in stage) ipa user-mod tuser --staged ... > > Simo did not like this command, I would personally add it. As long as > we have "ipa user-add --staged", we should also have an option to > delete and modify user in staged area. > > > (in del) ipa user-mod tuser --deleted ... > > Not needed. > > Is this acceptable for everyone? If yes, the next step would be for > Thierry to update the design page with new proposals. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From purpleidea at gmail.com Thu May 29 05:44:46 2014 From: purpleidea at gmail.com (James) Date: Thu, 29 May 2014 01:44:46 -0400 Subject: [Freeipa-devel] ipa-server-install error Message-ID: Hi, Can anyone decipher this log and help me understand what is broken and how to fix it? What is more peculiar is that I don't get the problem on an older version of CentOS 6.5, but on the latest up to date version it breaks. Note that I am using the latest versions of all the ipa-server packages and dependencies. The command I am using to install is: /usr/sbin/ipa-server-install --hostname='ipa.example.com' --domain='example.com' --realm='EXAMPLE.COM' --ds-password=`/bin/cat '/var/lib/puppet/tmp/ipa/dm.password' | /bin/cat | /bin/cat | /bin/cat` --admin-password=`/bin/cat '/var/lib/puppet/tmp/ipa/admin.password' | /bin/cat | /bin/cat | /bin/cat` --idstart=16777216 --no-ntp --unattended Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-install.log Type: text/x-log Size: 18505 bytes Desc: not available URL: From mkosek at redhat.com Thu May 29 06:17:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 May 2014 08:17:25 +0200 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users In-Reply-To: <538696D1.1000002@redhat.com> References: <537E0AAA.5090100@redhat.com> <538696D1.1000002@redhat.com> Message-ID: <5386D0F5.5040706@redhat.com> On 05/29/2014 04:09 AM, Dmitri Pal wrote: > On 05/22/2014 10:33 AM, thierry bordaz wrote: >> Hello, >> >> In order to provision staged users (account inactivated) with >> there initial values: >> >> /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 >> ----------------- >> Added user "tb20" >> ----------------- >> User login: tb20 >> First name: tb20 >> Last name: tb20 >> Full name: tb20 tb20 >> Display name: tb20 tb20 >> Initials: tt >> Home directory: /home/tb20 >> GECOS: tb20 tb20 >> Login shell: /bin/sh >> Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM >> Email address: tb20 at idm.lab.bos.redhat.com >> UID: -1 >> GID: -1 >> Account disabled: true >> Password: False >> Kerberos keys available: False >> >> ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" >> -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 >> dn: uid=tb20,cn=staged >> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >> dc=redhat,dc=com >> displayName: tb20 tb20 >> cn: tb20 tb20 >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: ipasshuser >> objectClass: ipaSshGroupOfPubKeys >> loginShell: /bin/sh >> uidNumber: -1 >> ipaUniqueID: autogenerate >> gidNumber: -1 >> gecos: tb20 tb20 >> sn: tb20 >> homeDirectory: /home/tb20 >> uid: tb20 >> mail: tb20 at idm.lab.bos.redhat.com >> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >> givenName: tb20 >> initials: tt >> >> I needed to resctrict the scope of the following plugins: >> >> dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config >> nsslapd-pluginarg1: >> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> >> dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi >> ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> >> dn: cn=Posix IDs,cn=Distributed Numeric Assignment >> Plugin,cn=plugins,cn=config >> dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> >> dn: cn=MemberOf Plugin,cn=plugins,cn=config >> memberofentryscope: >> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> >> In fact I need them to not modify the added entry when it is added >> under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". >> Now is it possible to limit those plugins scope to the >> 'cn=accounts' part of the tree ? I guess not. >> If it is not possible, a solution is to make the scope >> multi-valued attributes or to introduce a new config attribute >> '*notInScope' also multi-valued. >> A problem is the 'cn=ipaUniqueID uniqueness' that rely on the >> 'attribute uniqueness' plugin with a argv[ ], not really >> convenient to pass 2 multivalued attributes. >> >> If anyone is having others solutions it would help me a lot :-) >> >> thanks >> thierry >> >> > > The easiest solution IMO is to not treat staging area as an account area, i.e > instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, > cn=staging, dc=... Actually, this almost exactly the DN I wrote in the RFE: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status Proposed containers are: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX > This way if in future we will have some staging for other objects (for whatever > reason) we will create containers under common "staging" area. > I would also argue that "deleted" should not be under accounts. Agreed. This will also make the plugin configuration (tree exclusion) easier. Martin From mkosek at redhat.com Thu May 29 07:43:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 May 2014 09:43:24 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5386AA1E.3050505@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> Message-ID: <5386E51C.4020704@redhat.com> On 05/29/2014 05:31 AM, Dmitri Pal wrote: > On 05/26/2014 01:49 AM, Martin Kosek wrote: >> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>> This, I believe, has already been covered, but I'm concerned with the >>>> (over)use of active/inactive in this discussion. >>>> >>>> I think use of "inactive" and "active" to describe users might be >>>> confusing since there is already an account enable/disable command. >>>> This >>>> on top of unlock, are there now 3 possible boolean states a user can >>>> be >>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>> deleted/active and staged/active? >>>> >>> Agree, we should only have "ipa user-unstage " and not call >>> this operations with words like active/inactive. >>> >>> User's in the staging area are not inactive, they are *not* users yet in >>> the first place. >>> >>> Simo. >>> >> >> Ok. Let us consolidate the decisions, I think we are now running in circles. >> Let me start from Petr3's API proposal which was a functionally complete >> proposal and start from there: >> >> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >> > ... >> > My proposal would be that the move commands use the verb for the target and an >> > option for the source, and add/mod use an option for the container: >> > >> > 1) adding a new user >> > (to active) ipa user-add tuser ... >> > (to stage) ipa user-add tuser --staged ... >> >> Ok. >> >> > (to deleted) ipa user-add tuser --deleted ... (*) >> >> Not needed. >> >> > 2) moving to main >> > (from stage) ipa user-activate tuser (**) >> > (from del) ipa user-activate tuser --deleted >> >> We need both, alternative is Simo's proposal: >> >> ipa user-unstage >> ipa user-undelete >> >> I personally like unstage and undelete commands, I would go with those. > > Sorry for coming late to the party. > I strongly do not like "unstage" > This suggests that the user will be removed from staged but does not indicate > that the full user will be created. > As I suggested elsewhere provision-user or user-provision (or may be even > user-add --from-stage) would be better. As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation could get messy and would not create the right API. Using a separate call would be cleaner. As we see, choosing the right action term has proven very difficult - everyone has strong opinion on the command name :-) I already saw user-activate and user-unstage to be trashed so I am thinking what we are left with. I am still fan of user-unstage, user-provision is not telling me much more than user-unstage. >> > 3) moving to deleted >> > (from active) ipa user-del tuser >> >> Ok. >> >> > (from stage) ipa user-del tuser --staged >> >> IMO staged deleted users should not be moved to deleted container, but simply >> permanently deleted. As Simo noted, staged user are not real users, just >> incomplete users. >> >> > 4) moving to stage >> > (from active) ipa user-stage tuser > > > This was suggested for completeness. > I think we are cutting corners but I would not insist here. > >> > (from del) ipa user-stage tuser --deleted >> >> None of the commands are needed for the basic workflow. > > But this is a valid use case. I created a user, deleted it and want to rebuild > it becuase something got corrupted in the original entry. I agree it is not a > primary use case but then we should have a ticket to track this RFE for future. This was not about cutting corners, this was about what operation makes sense and what we should support. Stage was defined as a tree with incomplete user, thus this proposal - Simo was not very OK with this workflow. >> >> > 5) modifying >> > (in active) ipa user-mod tuser ... >> >> Ok. >> >> > (in stage) ipa user-mod tuser --staged ... >> >> Simo did not like this command, I would personally add it. As long as we have >> "ipa user-add --staged", we should also have an option to delete and modify >> user in staged area. >> >> > (in del) ipa user-mod tuser --deleted ... >> >> Not needed. >> >> Is this acceptable for everyone? If yes, the next step would be for Thierry >> to update the design page with new proposals. >> >> Martin Let me try to consolidate again the proposals and changes for the workflow&API we have so far: 1) Manipulating staged users - staged users must have UID RDN - UID uniqueness plugin should not be enforcing in staging area - we do not want it in user plugin as it requires different parameters and objectclasses - API: ipa stage-user-add ipa stage-user-mod ipa stage-user-find ipa stage-user-del 2) Activating staged user - activation will not do MODRDN, it will create a new user in active container and then delete the old one (to create right structural objectclass set) - for now, we need to allow operator delete any user in staged and add any user in active tree - API ipa stage-user-activate - other options mentioned in the past were user-unstage and user-activate 3) Manipulating deleted users - deletion and undeletion will do MODRDN and will use the ACI that Thierry implemented - API ipa user-del ipa user-undel OR ipa user-undelete - Dmitri mentioned that he would like to see the move from deleted to staged. I would do it via flag: ipa user-undel --to-stage Does that look better now? Thanks, Martin From mkosek at redhat.com Thu May 29 08:03:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 May 2014 10:03:34 +0200 Subject: [Freeipa-devel] [PATCHES] 0558-0561 Read ACI fixes In-Reply-To: <5385E747.6050306@redhat.com> References: <5385E747.6050306@redhat.com> Message-ID: <5386E9D6.2060309@redhat.com> On 05/28/2014 03:40 PM, Petr Viktorin wrote: > Hello, > Some of IPA plugins assume that everyone has access to everything. Here are > some fixes for that. > > Patch 0560 adds a new permission for the UPG Definition, which is required to > add users correctly. 558: Crash is now removed, though I am thinking that the output may be confusing for users as there is no output: # ipa krbtpolicy-show # echo $? 0 I need to use --all to see anything: # ipa krbtpolicy-show --all dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test cn: MKOSEK-FEDORA20.TEST objectclass: krbrealmcontainer, top, krbticketpolicyaux Would it make sense to raise ACIError if user cannot any Kerberos policy attributes? 559: ACK 560: ACK 561: functionally works fine, tested with migrate-ds. When looking at the code, would it make sense to replace this section: + disable_attr = '(objectclass=disable)' + org_filter = upg_entries[0].single_value['originfilter'] + return not re.search(r'%s' % disable_attr, org_filter) with + origin_filter = upg_entries[0].single_value['originfilter'] + return '(objectclass=disable)' not in origin_filter I am not sure why RE is used in this case at all. Martin From pviktori at redhat.com Thu May 29 08:06:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 29 May 2014 10:06:50 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5386E51C.4020704@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> Message-ID: <5386EA9A.8020407@redhat.com> On 05/29/2014 09:43 AM, Martin Kosek wrote: > On 05/29/2014 05:31 AM, Dmitri Pal wrote: >> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>> This, I believe, has already been covered, but I'm concerned with the >>>>> (over)use of active/inactive in this discussion. >>>>> >>>>> I think use of "inactive" and "active" to describe users might be >>>>> confusing since there is already an account enable/disable command. >>>>> This >>>>> on top of unlock, are there now 3 possible boolean states a user can >>>>> be >>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>> deleted/active and staged/active? >>>>> >>>> Agree, we should only have "ipa user-unstage " and not call >>>> this operations with words like active/inactive. >>>> >>>> User's in the staging area are not inactive, they are *not* users yet in >>>> the first place. >>>> >>>> Simo. >>>> >>> >>> Ok. Let us consolidate the decisions, I think we are now running in circles. >>> Let me start from Petr3's API proposal which was a functionally complete >>> proposal and start from there: >>> >>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>> ... >>>> My proposal would be that the move commands use the verb for the target and an >>>> option for the source, and add/mod use an option for the container: >>>> >>>> 1) adding a new user >>>> (to active) ipa user-add tuser ... >>>> (to stage) ipa user-add tuser --staged ... >>> >>> Ok. >>> >>>> (to deleted) ipa user-add tuser --deleted ... (*) >>> >>> Not needed. >>> >>>> 2) moving to main >>>> (from stage) ipa user-activate tuser (**) >>>> (from del) ipa user-activate tuser --deleted >>> >>> We need both, alternative is Simo's proposal: >>> >>> ipa user-unstage >>> ipa user-undelete >>> >>> I personally like unstage and undelete commands, I would go with those. >> >> Sorry for coming late to the party. >> I strongly do not like "unstage" >> This suggests that the user will be removed from staged but does not indicate >> that the full user will be created. >> As I suggested elsewhere provision-user or user-provision (or may be even >> user-add --from-stage) would be better. > > As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation > could get messy and would not create the right API. Using a separate call would > be cleaner. As we see, choosing the right action term has proven very difficult > - everyone has strong opinion on the command name :-) > > I already saw user-activate and user-unstage to be trashed so I am thinking > what we are left with. I am still fan of user-unstage, user-provision is not > telling me much more than user-unstage. > >>>> 3) moving to deleted >>>> (from active) ipa user-del tuser >>> >>> Ok. >>> >>>> (from stage) ipa user-del tuser --staged >>> >>> IMO staged deleted users should not be moved to deleted container, but simply >>> permanently deleted. As Simo noted, staged user are not real users, just >>> incomplete users. >>> >>>> 4) moving to stage >>>> (from active) ipa user-stage tuser >> >> >> This was suggested for completeness. >> I think we are cutting corners but I would not insist here. >> >>>> (from del) ipa user-stage tuser --deleted >>> >>> None of the commands are needed for the basic workflow. >> >> But this is a valid use case. I created a user, deleted it and want to rebuild >> it becuase something got corrupted in the original entry. I agree it is not a >> primary use case but then we should have a ticket to track this RFE for future. > > This was not about cutting corners, this was about what operation makes sense > and what we should support. Stage was defined as a tree with incomplete user, > thus this proposal - Simo was not very OK with this workflow. > >>> >>>> 5) modifying >>>> (in active) ipa user-mod tuser ... >>> >>> Ok. >>> >>>> (in stage) ipa user-mod tuser --staged ... >>> >>> Simo did not like this command, I would personally add it. As long as we have >>> "ipa user-add --staged", we should also have an option to delete and modify >>> user in staged area. >>> >>>> (in del) ipa user-mod tuser --deleted ... >>> >>> Not needed. >>> >>> Is this acceptable for everyone? If yes, the next step would be for Thierry >>> to update the design page with new proposals. >>> >>> Martin > > Let me try to consolidate again the proposals and changes for the workflow&API > we have so far: > > 1) Manipulating staged users > - staged users must have UID RDN > - UID uniqueness plugin should not be enforcing in staging area > - we do not want it in user plugin as it requires different parameters and > objectclasses > - API: > ipa stage-user-add > ipa stage-user-mod > ipa stage-user-find > ipa stage-user-del You left out "show". But note that the framework won't allow dashes in the object name, so this would have to be "stage-add", "stageuser-add", "userstage-add", or something like that. (This is because of the way commands are mapped to objects implicitly by name, which I don't think was the best decision, but it is what we have. It may not be very hard to change, though.) > 2) Activating staged user > - activation will not do MODRDN, it will create a new user in active container > and then delete the old one (to create right structural objectclass set) > - for now, we need to allow operator delete any user in staged and add any user > in active tree > - API > ipa stage-user-activate > - other options mentioned in the past were user-unstage and user-activate > > 3) Manipulating deleted users > - deletion and undeletion will do MODRDN and will use the ACI that Thierry > implemented > - API > ipa user-del > ipa user-undel OR ipa user-undelete > - Dmitri mentioned that he would like to see the move from deleted to staged. I > would do it via flag: > ipa user-undel --to-stage > > Does that look better now? Thanks, > Martin > -- Petr? From jcholast at redhat.com Thu May 29 08:15:51 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 29 May 2014 10:15:51 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5386E51C.4020704@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> Message-ID: <5386ECB7.1060408@redhat.com> On 29.5.2014 09:43, Martin Kosek wrote: > On 05/29/2014 05:31 AM, Dmitri Pal wrote: >> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>> This, I believe, has already been covered, but I'm concerned with the >>>>> (over)use of active/inactive in this discussion. >>>>> >>>>> I think use of "inactive" and "active" to describe users might be >>>>> confusing since there is already an account enable/disable command. >>>>> This >>>>> on top of unlock, are there now 3 possible boolean states a user can >>>>> be >>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>> deleted/active and staged/active? >>>>> >>>> Agree, we should only have "ipa user-unstage " and not call >>>> this operations with words like active/inactive. >>>> >>>> User's in the staging area are not inactive, they are *not* users yet in >>>> the first place. >>>> >>>> Simo. >>>> >>> >>> Ok. Let us consolidate the decisions, I think we are now running in circles. >>> Let me start from Petr3's API proposal which was a functionally complete >>> proposal and start from there: >>> >>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>> ... >>>> My proposal would be that the move commands use the verb for the target and an >>>> option for the source, and add/mod use an option for the container: >>>> >>>> 1) adding a new user >>>> (to active) ipa user-add tuser ... >>>> (to stage) ipa user-add tuser --staged ... >>> >>> Ok. >>> >>>> (to deleted) ipa user-add tuser --deleted ... (*) >>> >>> Not needed. >>> >>>> 2) moving to main >>>> (from stage) ipa user-activate tuser (**) >>>> (from del) ipa user-activate tuser --deleted >>> >>> We need both, alternative is Simo's proposal: >>> >>> ipa user-unstage >>> ipa user-undelete >>> >>> I personally like unstage and undelete commands, I would go with those. >> >> Sorry for coming late to the party. >> I strongly do not like "unstage" >> This suggests that the user will be removed from staged but does not indicate >> that the full user will be created. >> As I suggested elsewhere provision-user or user-provision (or may be even >> user-add --from-stage) would be better. > > As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation > could get messy and would not create the right API. Using a separate call would > be cleaner. As we see, choosing the right action term has proven very difficult > - everyone has strong opinion on the command name :-) > > I already saw user-activate and user-unstage to be trashed so I am thinking > what we are left with. I am still fan of user-unstage, user-provision is not > telling me much more than user-unstage. > >>>> 3) moving to deleted >>>> (from active) ipa user-del tuser >>> >>> Ok. >>> >>>> (from stage) ipa user-del tuser --staged >>> >>> IMO staged deleted users should not be moved to deleted container, but simply >>> permanently deleted. As Simo noted, staged user are not real users, just >>> incomplete users. >>> >>>> 4) moving to stage >>>> (from active) ipa user-stage tuser >> >> >> This was suggested for completeness. >> I think we are cutting corners but I would not insist here. >> >>>> (from del) ipa user-stage tuser --deleted >>> >>> None of the commands are needed for the basic workflow. >> >> But this is a valid use case. I created a user, deleted it and want to rebuild >> it becuase something got corrupted in the original entry. I agree it is not a >> primary use case but then we should have a ticket to track this RFE for future. > > This was not about cutting corners, this was about what operation makes sense > and what we should support. Stage was defined as a tree with incomplete user, > thus this proposal - Simo was not very OK with this workflow. > >>> >>>> 5) modifying >>>> (in active) ipa user-mod tuser ... >>> >>> Ok. >>> >>>> (in stage) ipa user-mod tuser --staged ... >>> >>> Simo did not like this command, I would personally add it. As long as we have >>> "ipa user-add --staged", we should also have an option to delete and modify >>> user in staged area. >>> >>>> (in del) ipa user-mod tuser --deleted ... >>> >>> Not needed. >>> >>> Is this acceptable for everyone? If yes, the next step would be for Thierry >>> to update the design page with new proposals. >>> >>> Martin > > Let me try to consolidate again the proposals and changes for the workflow&API > we have so far: > > 1) Manipulating staged users > - staged users must have UID RDN > - UID uniqueness plugin should not be enforcing in staging area > - we do not want it in user plugin as it requires different parameters and > objectclasses > - API: > ipa stage-user-add > ipa stage-user-mod > ipa stage-user-find > ipa stage-user-del I think this has to be stageduser-add, etc., since the framework does not allow object names with multiple words. > > 2) Activating staged user > - activation will not do MODRDN, it will create a new user in active container > and then delete the old one (to create right structural objectclass set) > - for now, we need to allow operator delete any user in staged and add any user > in active tree > - API > ipa stage-user-activate > - other options mentioned in the past were user-unstage and user-activate > > 3) Manipulating deleted users > - deletion and undeletion will do MODRDN and will use the ACI that Thierry > implemented > - API > ipa user-del > ipa user-undel OR ipa user-undelete > - Dmitri mentioned that he would like to see the move from deleted to staged. I > would do it via flag: > ipa user-undel --to-stage I would prefer if anything related to staged users was confined to the stage-user/stageduser plugin. So maybe something like this: ipa stage-user-add --from-deleted=username > > > Does that look better now? Thanks, > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Jan Cholasta From mkosek at redhat.com Thu May 29 08:14:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 May 2014 10:14:06 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5386EA9A.8020407@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <5386EA9A.8020407@redhat.com> Message-ID: <5386EC4E.9080506@redhat.com> On 05/29/2014 10:06 AM, Petr Viktorin wrote: > On 05/29/2014 09:43 AM, Martin Kosek wrote: ... >> 1) Manipulating staged users >> - staged users must have UID RDN >> - UID uniqueness plugin should not be enforcing in staging area >> - we do not want it in user plugin as it requires different parameters and >> objectclasses >> - API: >> ipa stage-user-add >> ipa stage-user-mod >> ipa stage-user-find >> ipa stage-user-del > > You left out "show". Right - that too. > > But note that the framework won't allow dashes in the object name, so this > would have to be "stage-add", "stageuser-add", "userstage-add", or something > like that. > (This is because of the way commands are mapped to objects implicitly by name, > which I don't think was the best decision, but it is what we have. It may not > be very hard to change, though.) Hmm, correct. There are 2 ways - follow the pattern we have in automember and be OK we have one LDAPObject for all stage commands and override what we need in LDAPCommands, or update to separate LDAPObjects as you proposed: ipa stageduser-add ipa stageduser-mod ipa stageduser-find ipa stageduser-del ipa stageduser-show Martin From pviktori at redhat.com Thu May 29 09:04:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 29 May 2014 11:04:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0558-0561 Read ACI fixes In-Reply-To: <5386E9D6.2060309@redhat.com> References: <5385E747.6050306@redhat.com> <5386E9D6.2060309@redhat.com> Message-ID: <5386F834.1010004@redhat.com> On 05/29/2014 10:03 AM, Martin Kosek wrote: > On 05/28/2014 03:40 PM, Petr Viktorin wrote: >> Hello, >> Some of IPA plugins assume that everyone has access to everything. Here are >> some fixes for that. >> >> Patch 0560 adds a new permission for the UPG Definition, which is required to >> add users correctly. > > 558: > > Crash is now removed, though I am thinking that the output may be confusing for > users as there is no output: > > # ipa krbtpolicy-show > # echo $? > 0 > > I need to use --all to see anything: > > # ipa krbtpolicy-show --all > dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test > cn: MKOSEK-FEDORA20.TEST > objectclass: krbrealmcontainer, top, krbticketpolicyaux > > Would it make sense to raise ACIError if user cannot any Kerberos policy > attributes? Hm, actually there's a bigger problem -- if the user policy is not readable, the command will actually lie. I think we'll need to check attributelevelrights here to see if the attributes are really unset or just unreadable. And I'll go through all the other commands more carefully, to see if distinction between "not readable" and "not existing" makes significant difference. I withdraw the patch for now. > 559: ACK > 560: ACK > 561: > > functionally works fine, tested with migrate-ds. When looking at the code, > would it make sense to replace this section: > > + disable_attr = '(objectclass=disable)' > + org_filter = upg_entries[0].single_value['originfilter'] > + return not re.search(r'%s' % disable_attr, org_filter) > > with > > + origin_filter = upg_entries[0].single_value['originfilter'] > + return '(objectclass=disable)' not in origin_filter > > I am not sure why RE is used in this case at all. Good point, thanks. Update attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0559-aci-plugin-Fix-internal-error-when-ACIs-are-not-read.patch Type: text/x-patch Size: 915 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0560-Add-managed-read-permission-for-the-UPG-Definition.patch Type: text/x-patch Size: 1861 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0561-ldap2.has_upg-Raise-an-error-if-the-UPG-definition-i.patch Type: text/x-patch Size: 3539 bytes Desc: not available URL: From sbose at redhat.com Thu May 29 11:48:09 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 29 May 2014 13:48:09 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2 Message-ID: <20140529114809.GJ30381@localhost.localdomain> Hi, I have updated http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust with the results of various discussions with Simo and Alexander (thank you). For your convenience you can find the text below as well. I'm working on some figures which hopefully can help to understand the user-view even better. Comments and suggestions are welcome. bye, Sumit = Overview = This page illustrates how existing solutions which make AD users available to Linux hosts can be migrated to FreeIPA with Trusts. This includes migrations from the FreeIPA WinSync feature or environments where the AD users where correlated to NIS users. The common problem here is that some if not all attributes needed by a POSIX user or group must be overwritten or supplied by the IPA server. The link to the related AD object is preferably the SID but if it is not available on both sides the name of the object must be used. AD will keep the responsibility for authentication and provide the AD group-memberships of the object. = Use Cases = * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] * Migration/Consolidation of domains currently managed by other * solutions, e.g. NIS ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) = Design = In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. # Instead of just offering a single override option the introduction of # views are suggested. # The views will be stored in containers below # cn=views,cn=accounts,$SUFFIX with containers for users and groups. The # objectclasses will look similar to posixAccount and posixGroup # objectclasses but with only optional (MAY) attributes. Questions: On the SSSD side we try to avoid changes. The AD users and group are looked up via the extdom plugin which applies all needed views for the client. To manage the views a new set CLI tools/Web UI pages should be added. Depending if we would like to allow to override IPA users as well or only users from trusted domains the tools might get their own name space, ipa view-*, or can be added below the trust name space, ipa trust-view-*. These tools will create and delete the views and assign them to hosts and hostgroups. Additionally viewuser-* and viewgroup-* commands must be created to add users and groups to the views and specify their override values. It has to be noted that changes of a view will only be visible on the client after the related cached object is expired. = Implementation = As said we try to avoid changes on the client side so the older clients using the extdom plugin can benefit from the views. On the server side we have to modify SSSD running in IPA server mode, the extdom plugin and the slapi-nis plugin for the compat tree. == SSSD (IPA server mode) == The main purpose of the IPA server mode of SSSD is to look up the users and groups from the trusted domains so that they are available for standard POSIX calls like getpwnam(). Before writing the data from AD to the cache SSSD will check if there is a default view for the AD object. For this it will search the container of the default view with the SID of the AD object as a key. If a default view was found the given overrides are applied and the result is written into the cache of SSSD. The following should be noted here: * all IPA servers and replicas are hardcoded to the default view, it is * not possible to assign a different view to them * for overridden values the original data will not be available (we * might want to store them with a 'orig' prefix in the SSSD cache, but * currently there is no use for this data in the IPA domain) * it makes no sense to assign the default view to any host or * hostgroups, because it is apllied by design to the whole IPA domain * all other views are applied on top of the default view: ** if the default view e.g. overrides the uidNumber attribute from AD the original value from AD is _not_ available to any other view ** if an override value is changed in the default view and not overridden by e.g. view xyz the change in the default view will be visible on call clients assigned to the xyz view as well. == extdom plugin == The original purpose of the extdom plugin was to SIDs of AD objects to POSIX UIDs and GIDs. There are plans to enhance the plugin [https://fedorahosted.org/freeipa/ticket/4031 https://fedorahosted.org/freeipa/ticket/4031] but since some of them might relate to user-views the user-views related changes should be done first. As a consequence currently only UID and GID can be overridden, not home-directory or shell. But changing the IDs is the main purpose of the views anyways. Before sending the data back to the client the extdom plugin must check if it has to apply a different view then the default view for the client. Since the SSSD client use SASL binds with the the host keytab to access the IPA LDAP server the client DN is available as SLAPI_CONN_DN in the Slapi_PBlock struct. With the DN the host object of the client can be looked up to get the hostgroups the client is a member of. With the DNs of the client and the hostgroups the view objects can be searched for a match. If there is a view the extdom plugin must look up the SID of the object the client requested and search the container of the view with the SID as a key. If there is a view for the object it will be applied and the result is returned to the client. In case of an error during this operations or if more than one view was found the data from SSSD were only the default view is applied will be returned to the client. If the extdom plugin finds that a client is assigned to multiple views it should be reported in the log at a high level. Adding checks in the CLI or WebUI does not make sense because every change to a host group would require such a check. == slapi-nis plugin/compat tree == The compat tree offers a simplified LDAP tree with user and group data for legacy clients. No data for this tree is stored on disk but it is always created on the fly. It has to be noted that legacy clients might be one of the major users of the user-views because chances are that they were attached to the legacy systems with legacy ID management which should be replaced by IPA. In contrast to the extdom plugin it is not possible to determine the client based on the DN because connection might be anonymous. The Slapi_PBlock contains the IP address of the client in SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA tree requires a reverse-DNS lookup which might be unreliable. If the reverse-DNS lookup was successful the slapi-nos plugin can follow the same steps as the extdom plugin to lookup up and apply the view. As a alternative slapi-nis can provide one tree for each view. The first approach has the advantage that everything can be manages on the server and no change on the legacy clients is needed, even if the are assigned to a different view, but requires reverse-DNS and has more search overhead. With the second approach every legacy system which should get a specific view different from the default view has to be pointed to the new tree. Using both in parallel is possible but might not be worth the additional effort. =Feature Management = == UI == === View management === A page to list all view and a page to change the attributes of the view object are needed (see CLI section below for details). === Management of the overrides === I'm currently not sure if a user/group oriented approach or a view based one is the better choice. In the first case there will be a new tab on the user and group page where views can be selected and overrides can be specified. In the second case the view page (see above) will have tabs for users and groups in the view. Maybe both approaches can be combined. == CLI == === View management === Views must be added, displayed, modified and deleted. Imo the object for the default view does not need any changes and should not be deleted, so the tool can reject any attempt to change the default view. Besides the name the only attributes for the view object are the assignments to hosts and hostgroups. Maybe there might be use-cases for host-categories as well, but the ALL category is already covered by the default view. Maybe we can add the category already to the schema to avoid updates in future but not expose it through the cli tools. === Management of the overrides === It must be possible to add, display, modify and delete an override object for any trusted user or group in any view. Since user and groups have different attributes there should be a command family for user and another one for groups. It should be possible to identify the trusted object by its fully qualified name or by its SID. I think the find and show operations should take the fully qualified name or SID as an argument and should display the overrides found in any view if not a specific view is given by an option. = Major configuration options and enablement = I think it is better to enable views manually than to have them by default because they have special use-cases and will generate overhead in the general case. If this feature is only needed for users from trusted domains it can be activated during ipa-adtrust-install. If it should be used for local users in the long run as well there should be a special operation to activate it and to create the container for views and the default view container. The existence of the view container cn=views,cn=accounts,$SUFFIX can be uses as an indicator if views are enabled or not. = Replication = Views must be replicated. = Updates and Upgrades = Since views and not enabled by default only the new schema entries must ba added during updates. = Dependencies = Currently no new package or library dependencies are expected. = External Impact = Enhancements for SSSD's IPA server mode a re needed. = Backup and Restore = All data needed for user-views are in the replicated LDAP tree and should be backuped with the other data in the tree. = Test Plan = Test scenarios that will be transformed to test cases for FreeIPA Continuous Integration during implementation or review phase. = RFE Author = [[User:Sbose|Sumit Bose]] From ssorce at redhat.com Thu May 29 12:39:13 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 08:39:13 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5386E51C.4020704@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> Message-ID: <1401367153.3590.8.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: > On 05/29/2014 05:31 AM, Dmitri Pal wrote: > > On 05/26/2014 01:49 AM, Martin Kosek wrote: > >> On 05/23/2014 04:55 PM, Simo Sorce wrote: > >>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: > >>>> This, I believe, has already been covered, but I'm concerned with the > >>>> (over)use of active/inactive in this discussion. > >>>> > >>>> I think use of "inactive" and "active" to describe users might be > >>>> confusing since there is already an account enable/disable command. > >>>> This > >>>> on top of unlock, are there now 3 possible boolean states a user can > >>>> be > >>>> in? locked/unlocked, enabled/disabled, active/inactive, plus > >>>> deleted/active and staged/active? > >>>> > >>> Agree, we should only have "ipa user-unstage " and not call > >>> this operations with words like active/inactive. > >>> > >>> User's in the staging area are not inactive, they are *not* users yet in > >>> the first place. > >>> > >>> Simo. > >>> > >> > >> Ok. Let us consolidate the decisions, I think we are now running in circles. > >> Let me start from Petr3's API proposal which was a functionally complete > >> proposal and start from there: > >> > >> On 05/22/2014 10:47 AM, Petr Viktorin wrote: > >> > ... > >> > My proposal would be that the move commands use the verb for the target and an > >> > option for the source, and add/mod use an option for the container: > >> > > >> > 1) adding a new user > >> > (to active) ipa user-add tuser ... > >> > (to stage) ipa user-add tuser --staged ... > >> > >> Ok. > >> > >> > (to deleted) ipa user-add tuser --deleted ... (*) > >> > >> Not needed. > >> > >> > 2) moving to main > >> > (from stage) ipa user-activate tuser (**) > >> > (from del) ipa user-activate tuser --deleted > >> > >> We need both, alternative is Simo's proposal: > >> > >> ipa user-unstage > >> ipa user-undelete > >> > >> I personally like unstage and undelete commands, I would go with those. > > > > Sorry for coming late to the party. > > I strongly do not like "unstage" > > This suggests that the user will be removed from staged but does not indicate > > that the full user will be created. > > As I suggested elsewhere provision-user or user-provision (or may be even > > user-add --from-stage) would be better. > > As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation > could get messy and would not create the right API. Using a separate call would > be cleaner. As we see, choosing the right action term has proven very difficult > - everyone has strong opinion on the command name :-) > > I already saw user-activate and user-unstage to be trashed so I am thinking > what we are left with. I am still fan of user-unstage, user-provision is not > telling me much more than user-unstage. > > >> > 3) moving to deleted > >> > (from active) ipa user-del tuser > >> > >> Ok. > >> > >> > (from stage) ipa user-del tuser --staged > >> > >> IMO staged deleted users should not be moved to deleted container, but simply > >> permanently deleted. As Simo noted, staged user are not real users, just > >> incomplete users. > >> > >> > 4) moving to stage > >> > (from active) ipa user-stage tuser > > > > > > This was suggested for completeness. > > I think we are cutting corners but I would not insist here. > > > >> > (from del) ipa user-stage tuser --deleted > >> > >> None of the commands are needed for the basic workflow. > > > > But this is a valid use case. I created a user, deleted it and want to rebuild > > it becuase something got corrupted in the original entry. I agree it is not a > > primary use case but then we should have a ticket to track this RFE for future. > > This was not about cutting corners, this was about what operation makes sense > and what we should support. Stage was defined as a tree with incomplete user, > thus this proposal - Simo was not very OK with this workflow. > > >> > >> > 5) modifying > >> > (in active) ipa user-mod tuser ... > >> > >> Ok. > >> > >> > (in stage) ipa user-mod tuser --staged ... > >> > >> Simo did not like this command, I would personally add it. As long as we have > >> "ipa user-add --staged", we should also have an option to delete and modify > >> user in staged area. > >> > >> > (in del) ipa user-mod tuser --deleted ... > >> > >> Not needed. > >> > >> Is this acceptable for everyone? If yes, the next step would be for Thierry > >> to update the design page with new proposals. > >> > >> Martin > > Let me try to consolidate again the proposals and changes for the workflow&API > we have so far: > > 1) Manipulating staged users > - staged users must have UID RDN > - UID uniqueness plugin should not be enforcing in staging area > - we do not want it in user plugin as it requires different parameters and > objectclasses > - API: > ipa stage-user-add > ipa stage-user-mod > ipa stage-user-find > ipa stage-user-del > > 2) Activating staged user > - activation will not do MODRDN, it will create a new user in active container > and then delete the old one (to create right structural objectclass set) > - for now, we need to allow operator delete any user in staged and add any user > in active tree > - API > ipa stage-user-activate > - other options mentioned in the past were user-unstage and user-activate > > 3) Manipulating deleted users > - deletion and undeletion will do MODRDN and will use the ACI that Thierry > implemented > - API > ipa user-del > ipa user-undel OR ipa user-undelete > - Dmitri mentioned that he would like to see the move from deleted to staged. I > would do it via flag: > ipa user-undel --to-stage > > > Does that look better now? Thanks, Yes, although I do not see the need for --to-stage honestly. Simo. From ssorce at redhat.com Thu May 29 12:40:35 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 08:40:35 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <5386EA9A.8020407@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <5386EA9A.8020407@redhat.com> Message-ID: <1401367235.3590.9.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 10:06 +0200, Petr Viktorin wrote: > > Let me try to consolidate again the proposals and changes for the workflow&API > > we have so far: > > > > 1) Manipulating staged users > > - staged users must have UID RDN > > - UID uniqueness plugin should not be enforcing in staging area > > - we do not want it in user plugin as it requires different parameters and > > objectclasses > > - API: > > ipa stage-user-add > > ipa stage-user-mod > > ipa stage-user-find > > ipa stage-user-del > > You left out "show". > > But note that the framework won't allow dashes in the object name, so > this would have to be "stage-add", "stageuser-add", "userstage-add", or > something like that. > (This is because of the way commands are mapped to objects implicitly by > name, which I don't think was the best decision, but it is what we have. > It may not be very hard to change, though.) ipa stage-useradd ipa stage-usermod ipa stage-userdel ipa stage-userfind ipa stage-usershow From mkosek at redhat.com Thu May 29 13:35:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 May 2014 15:35:31 +0200 Subject: [Freeipa-devel] [PATCHES] 0558-0561 Read ACI fixes In-Reply-To: <5386F834.1010004@redhat.com> References: <5385E747.6050306@redhat.com> <5386E9D6.2060309@redhat.com> <5386F834.1010004@redhat.com> Message-ID: <538737A3.2030801@redhat.com> On 05/29/2014 11:04 AM, Petr Viktorin wrote: > On 05/29/2014 10:03 AM, Martin Kosek wrote: >> On 05/28/2014 03:40 PM, Petr Viktorin wrote: >>> Hello, >>> Some of IPA plugins assume that everyone has access to everything. Here are >>> some fixes for that. >>> >>> Patch 0560 adds a new permission for the UPG Definition, which is required to >>> add users correctly. >> >> 558: >> >> Crash is now removed, though I am thinking that the output may be confusing for >> users as there is no output: >> >> # ipa krbtpolicy-show >> # echo $? >> 0 >> >> I need to use --all to see anything: >> >> # ipa krbtpolicy-show --all >> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >> cn: MKOSEK-FEDORA20.TEST >> objectclass: krbrealmcontainer, top, krbticketpolicyaux >> >> Would it make sense to raise ACIError if user cannot any Kerberos policy >> attributes? > > Hm, actually there's a bigger problem -- if the user policy is not readable, > the command will actually lie. > I think we'll need to check attributelevelrights here to see if the attributes > are really unset or just unreadable. And I'll go through all the other commands > more carefully, to see if distinction between "not readable" and "not existing" > makes significant difference. > > I withdraw the patch for now. > >> 559: ACK >> 560: ACK >> 561: >> >> functionally works fine, tested with migrate-ds. When looking at the code, >> would it make sense to replace this section: >> >> + disable_attr = '(objectclass=disable)' >> + org_filter = upg_entries[0].single_value['originfilter'] >> + return not re.search(r'%s' % disable_attr, org_filter) >> >> with >> >> + origin_filter = upg_entries[0].single_value['originfilter'] >> + return '(objectclass=disable)' not in origin_filter >> >> I am not sure why RE is used in this case at all. > > Good point, thanks. Update attached. > > Thanks, works fine. ACK for all these 3 patches. Martin From pviktori at redhat.com Thu May 29 14:22:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 29 May 2014 16:22:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0558-0561 Read ACI fixes In-Reply-To: <538737A3.2030801@redhat.com> References: <5385E747.6050306@redhat.com> <5386E9D6.2060309@redhat.com> <5386F834.1010004@redhat.com> <538737A3.2030801@redhat.com> Message-ID: <538742BB.6090908@redhat.com> On 05/29/2014 03:35 PM, Martin Kosek wrote: > On 05/29/2014 11:04 AM, Petr Viktorin wrote: >> On 05/29/2014 10:03 AM, Martin Kosek wrote: >>> On 05/28/2014 03:40 PM, Petr Viktorin wrote: >>>> Hello, >>>> Some of IPA plugins assume that everyone has access to everything. Here are >>>> some fixes for that. >>>> >>>> Patch 0560 adds a new permission for the UPG Definition, which is required to >>>> add users correctly. >>> >>> 558: >>> >>> Crash is now removed, though I am thinking that the output may be confusing for >>> users as there is no output: >>> >>> # ipa krbtpolicy-show >>> # echo $? >>> 0 >>> >>> I need to use --all to see anything: >>> >>> # ipa krbtpolicy-show --all >>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>> cn: MKOSEK-FEDORA20.TEST >>> objectclass: krbrealmcontainer, top, krbticketpolicyaux >>> >>> Would it make sense to raise ACIError if user cannot any Kerberos policy >>> attributes? >> >> Hm, actually there's a bigger problem -- if the user policy is not readable, >> the command will actually lie. >> I think we'll need to check attributelevelrights here to see if the attributes >> are really unset or just unreadable. And I'll go through all the other commands >> more carefully, to see if distinction between "not readable" and "not existing" >> makes significant difference. >> >> I withdraw the patch for now. >> >>> 559: ACK >>> 560: ACK >>> 561: >>> >>> functionally works fine, tested with migrate-ds. When looking at the code, >>> would it make sense to replace this section: >>> >>> + disable_attr = '(objectclass=disable)' >>> + org_filter = upg_entries[0].single_value['originfilter'] >>> + return not re.search(r'%s' % disable_attr, org_filter) >>> >>> with >>> >>> + origin_filter = upg_entries[0].single_value['originfilter'] >>> + return '(objectclass=disable)' not in origin_filter >>> >>> I am not sure why RE is used in this case at all. >> >> Good point, thanks. Update attached. >> >> > > Thanks, works fine. ACK for all these 3 patches. > > Martin > Thanks, pushed to master: 4f89decc9a6020cbacbfa4406f32ce5465d49a72 -- Petr? From pvoborni at redhat.com Thu May 29 15:03:38 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 May 2014 17:03:38 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <538358FA.6070304@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> Message-ID: <53874C4A.3020402@redhat.com> On 26.5.2014 17:08, Petr Vobornik wrote: > On 19.5.2014 14:58, Petr Vobornik wrote: >> 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 action dropdown >> 639 webui-ci: assert_action_list_action >> 638 webui: use dark color for facet titles without pkey >> 637 webui: association adder dialog - change find label to filter >> 636 webui: certificate search - select search attribute only when defined >> 635 webui: change control buttons to normal buttons >> 634 webui: add search box placeholder text >> 633 webui: adjust header controls alignment >> 628 webui: remove old css for standalone pages >> 627 webui-ci: select search table item - chrome issue >> 626 webui: use BS alerts in validation_summary_widget >> 625 webui: adjust login page to PatternFly >> 624 webui: preload automember default group select list >> 623 webui: restyle automember default group >> 622 webui: do not show empty table footer >> 621 webui: improve pagination >> 620 webui: activity indicators >> 619 webui: adjust association adder dialog to PatternFly >> 618 webui: patternFly dialog >> 617 webui: move user reset password action to action dropdown >> 616 webui: move certificate actions to action dropdown >> 615 webui: add confirmation to action dropdown actions >> 614 webui: remove select action >> 613 webui: add space between action buttons's icon and text >> 612 webui: add action dropdown >> 611 webui: remove action list widget >> 610 webui: use h1 in facet title instead of h3 >> 609 webui: change breadcrumb to PatternFly >> 608 webui: allow multiple base section layouts >> 607 webui: display undo and multivalued delete buttons in input-group >> 606 webui: adjust styles to PatternFly >> 605 webui: change navigation from RCUE to PatternFly >> 604 webui: remove column sizing in tables, use PF styles >> 603 webui: change absolutely positioned layout to fluid >> 602 webui: remove unused images >> 601 webui: remove unused collapsible feature from section >> 600 webui: remove unused icons >> 599 webui: remove remnants of jquery-ui >> 598 webui: apply PatternFly theme on migration pages >> 597 webui: styles for alert icons >> 596 webui: apply PatternFly theme on config pages >> 595 webui: apply PatternFly login theme on reset_password.html >> 594 webui: add PaternFly css >> 593 webui: remove login.html >> 592 webui: remove logout.html > > The branch was rebased and commit > > 644 webui: move radius proxy action panel commands to header actions > > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/commit/?h=patternfly&id=a0591297adaec404ad1142651d2f6ce1a61e6164 > > > was added. I've improved UX of alerts. Now dialogs, page header and login screen use the same logic for rendering alerts with icons [1]. It required to implement widget.alert_helper. It was squashed into patch #626 webui: use BS alerts in validation_summary_widget. Two new patches for dialogs and header alerts: 653 webui: use propert alerts in header notification area 652 webui: proper alerts in dialogs the branch was updated. [1] https://www.patternfly.org/widgets/#forms -- Petr Vobornik From pvoborni at redhat.com Thu May 29 15:15:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 May 2014 17:15:21 +0200 Subject: [Freeipa-devel] [PATCH] 645 webui: display only dialogs which belong to current facet In-Reply-To: <53846DB7.40403@redhat.com> References: <53846DB7.40403@redhat.com> Message-ID: <53874F09.6040307@redhat.com> On 27.5.2014 12:49, Petr Vobornik wrote: > Dialog instances no longer directly call IPA.opened_dialog methods. It's > handled through events (decoupled from dialog's POV). IPA.open_dialogs > with assistance of ApplicationController makes sure that there is only > one dialog opened at the same time. > > It also makes sure to hide all dialogs, which are not global dialogs and > did not originate from current facet, when switching facets. > > https://fedorahosted.org/freeipa/ticket/4348 > Attaching rebased version (on top of latest PatternFly patch set). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0645-1-webui-display-only-dialogs-which-belong-to-current-f.patch Type: text/x-patch Size: 8743 bytes Desc: not available URL: From rcritten at redhat.com Thu May 29 15:15:58 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 May 2014 11:15:58 -0400 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <5385EA3D.8000505@redhat.com> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> <1399693089.26524.14.camel@aleeredhat.laptop> <1401227860.9297.9.camel@aleeredhat.laptop> <20140528064818.GE28407@dhcp-40-8.bne.redhat.com> <5385EA3D.8000505@redhat.com> Message-ID: <53874F2E.1040001@redhat.com> Petr Viktorin wrote: > On 05/28/2014 08:48 AM, Fraser Tweedale wrote: >> On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote: >>> There have been a couple of changes in the Dogtag interface, that >>> require some changes in the IPA patches. Also, I had to add back a >>> function in order to rebase to the latest IPA code. >>> >>> Most are the patches are as before, attached to this email by default. >>> >>> The latest Dogtag 10.2 build with the relevant changes needed to work >>> with these patches is at: >>> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ >>> >>> Ade >>> >> >> ACK. >> >> ipa-server-install worked fine for me, and the formatting changes >> seem good. Patch 0003 did not apply cleanly on master (due to minor >> conflict in 71c6d2f:installutils.py); an updated patch 0003 is >> attached. > > Hello, > If you do a rebase, could you attach all the patches again? > I don't have the Git objects that result from the original patch, so > `git am` fails on the later patches: > > $ git am -3 *.patch > Applying: Add a DRM to IPA > Applying: Added ipa-drm-install > Applying: Fix various pep 8 issues and comments from review > Applying: Added nolog to pkispawn and some additional fixes from review. > Applying: Added dogtag plugin for DRM > Applying: set drm to not install by default with ipa-server-install > Applying: Allow ipa-replica-install to be used for installing replicas > error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b > for 'install/tools/ipa-replica-install' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0007 Allow ipa-replica-install to be used for installing > replicas > The copy of the patch that failed is found in: > /home/pviktori/freeipa/.git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > I needed to rebase patche 9 as well as it contained a duplicate function, check_entropy. No need to rebase it again yet as we have to wait to push these until after a future branch anyway. Speaking of patch 9, it appears to be all formatting and spelling fixes, not all related to the DRM. Patch 4 does similar work. If we're going to commit these all separately anyway, is it worthwhile to combine these two? Something (or someone) is mighty picky about thru vs through too :-) The DRM patches should all have a ticket referenced. At a minimum the first one (0002 in this case). I think 0007 can be rebased into an existing patch unless we want to record in history that the default stance changed. Found a place that needs a change. The script install/restart_scripts/renew_ca_cert handles fixing the trust on the audit cert after renewal. This needs to update the DRM audit cert trust as well. Be aware that Honza is making significant changes to this area. Otherwise looks ok to me. I'm not super-firm on squashing some of the patches, I just don't know what historical benefit might be gained from keeping them separate. rob From pviktori at redhat.com Thu May 29 15:37:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 29 May 2014 17:37:34 +0200 Subject: [Freeipa-devel] [PATCHES] 0562-0563 ix internal error when global policy is not readable Message-ID: <5387543E.3010002@redhat.com> When investigating this issue I became very annoyed by the star import hiding where names come from, so I did some cleanup first. In krbtpolicy, an ACIError is now raised if: - the user doesn't have permission to read any one of the ticket policy attributes on the requested entry (checked using attribute-level rights) - any ticket policy attribute from the default policy is not available (either not readable, or not there at all) (only checked if these are accessed, i.e. when the user entry doesn't override all of the defaults, or when requesting the global policy) That means if the user is not available at all, you get a NotFound, but if global policy is not found it's assumed that it's just unreadable. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0562-krbtpolicy-plugin-Code-cleanup.patch Type: text/x-patch Size: 3203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0563-krbtpolicy-plugin-Fix-internal-error-when-global-pol.patch Type: text/x-patch Size: 3239 bytes Desc: not available URL: From dpal at redhat.com Thu May 29 15:39:09 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 29 May 2014 11:39:09 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1401333646.3590.4.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> Message-ID: <5387549D.4050705@redhat.com> On 05/28/2014 11:20 PM, Simo Sorce wrote: > On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: >> On 05/27/2014 03:52 PM, Simo Sorce wrote: >>> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: >>>> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: >>>>> Hi, >>>>> >>>>> I have started to write a design page for 'Migrating existing >>>>> environments to Trust' >>>>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >>>>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >>>>> https://fedorahosted.org/freeipa/ticket/3979 . >>>>> >>>> while working on a new version of the page with more details on design >>>> and implementation I came across the following problem. On the IPA >>>> server there should be a way for SSSD to deliver unmodified data (no >>>> view applied) or views other than the one for the IPA server to >>>> processes which delivers user and group data to other clients. This are >>>> mainly the extdom and the compat plugin of dirsrv. >>>> >>>> The two currently use standard glibc calls like getpwnam_r() to get the >>>> needed data from SSSD. While they can read the view objects form the >>>> LDAP tree there is no way to read the original data for users from >>>> trusted domains because it is only in the cache of SSSD. >>>> >>>> I'm looking for a way to allow SSSD to deliver the data without changing >>>> the protocol used by the NSS responder. >>>> >>>> One way I can think of is to use a new socket like >>>> /var/lib/sss/pipes/nss_noview and create a small library for the extdom >>>> and compat plugin to use the new socket. With this the plugin have to >>>> apply the views on their own if needed. >>>> >>>> Another way would be a new command for the NSS responder with two >>>> arguments, the view name (or empty for unmodified data) and a blob which >>>> contains the data for the corresponding request like e.g. getpwnam_r() or >>>> getgrgid_r(). Here the plugins have to use some new calls but all view >>>> processing can happen in sssd and the plugins can deliver the data >>>> directly. >>>> >>>> A drawback in both cases is that the memcache cannot be used. >>>> >>>> If someone has suggestions for SSSD or other ways how to deliver user >>>> and group data to client with other views than the IPA server I'm all >>>> ears. >>> Ok this one is hard to deal with in a way that will satisfy every >>> possible user. >>> >>> I think what we need to aim is simplicity and predictability at the >>> expense of flexibility. >>> >>> What I mean is that freeipa servers should be allowed to only stick to >>> one view, the default view for external users. >> I do not understand what you mean by "one" view? > The "one" view is the view exposed via the (default) compat tree. > >> Server should be able to have "all" views. >> "View" is an equivalent of the "zones". >> >> SSSD has to get raw data from the external domain and give it to IPA. >> IPA would have to merge the data coming from SSSD in server mode with >> some set of data associated with a subset of clients. >> I am not sure how it will be done (compat, cos or some other mechanism) >> but this is the requirement. > This would require multiple compat trees, one per view, it would be very > expensive. > >> So for clarity let me restate the use cases: >> >> a) I had my users in a NIS or LDAP with POSIX attributes there. I used >> to sync users from AD. I migrate from that to IPA but want to use trust >> for my users because AD is authoritative source and I do not want/can >> put POSIX into AD. >> b) I have several NIS domains that I need to consolidate. For whatever >> reasons I can't migrate to the unified POSIX namespace. I want an >> equivalent of the Centrify Zones when different clients get different >> uid/gid assignments for the same users. >> c) I used sync so my POSIX attributes are in IPA but now I want to >> switch to trust. >> d) I had a third party solution that had posix zoning and I want to >> replace it with the similar solution based on IPA. >> >> Views (plural) are a way to merge data and present it to a subset of >> clients. In this context it is not really clear what you mean by "one" >> view. > In order to see views you'll need a modern SSSD client that knows how to > apply them. Ie viewS are applied on the client side. The server shows > only one view via LDAP. > > Simo. > OK, I agree with multiple views being expensive and merging things on the client but how you define which one is the "default" on the server? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Thu May 29 15:41:57 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 11:41:57 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <5387549D.4050705@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> <5387549D.4050705@redhat.com> Message-ID: <1401378117.3590.13.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote: > On 05/28/2014 11:20 PM, Simo Sorce wrote: > > On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: > >> On 05/27/2014 03:52 PM, Simo Sorce wrote: > >>> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: > >>>> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > >>>>> Hi, > >>>>> > >>>>> I have started to write a design page for 'Migrating existing > >>>>> environments to Trust' > >>>>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > >>>>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > >>>>> https://fedorahosted.org/freeipa/ticket/3979 . > >>>>> > >>>> while working on a new version of the page with more details on design > >>>> and implementation I came across the following problem. On the IPA > >>>> server there should be a way for SSSD to deliver unmodified data (no > >>>> view applied) or views other than the one for the IPA server to > >>>> processes which delivers user and group data to other clients. This are > >>>> mainly the extdom and the compat plugin of dirsrv. > >>>> > >>>> The two currently use standard glibc calls like getpwnam_r() to get the > >>>> needed data from SSSD. While they can read the view objects form the > >>>> LDAP tree there is no way to read the original data for users from > >>>> trusted domains because it is only in the cache of SSSD. > >>>> > >>>> I'm looking for a way to allow SSSD to deliver the data without changing > >>>> the protocol used by the NSS responder. > >>>> > >>>> One way I can think of is to use a new socket like > >>>> /var/lib/sss/pipes/nss_noview and create a small library for the extdom > >>>> and compat plugin to use the new socket. With this the plugin have to > >>>> apply the views on their own if needed. > >>>> > >>>> Another way would be a new command for the NSS responder with two > >>>> arguments, the view name (or empty for unmodified data) and a blob which > >>>> contains the data for the corresponding request like e.g. getpwnam_r() or > >>>> getgrgid_r(). Here the plugins have to use some new calls but all view > >>>> processing can happen in sssd and the plugins can deliver the data > >>>> directly. > >>>> > >>>> A drawback in both cases is that the memcache cannot be used. > >>>> > >>>> If someone has suggestions for SSSD or other ways how to deliver user > >>>> and group data to client with other views than the IPA server I'm all > >>>> ears. > >>> Ok this one is hard to deal with in a way that will satisfy every > >>> possible user. > >>> > >>> I think what we need to aim is simplicity and predictability at the > >>> expense of flexibility. > >>> > >>> What I mean is that freeipa servers should be allowed to only stick to > >>> one view, the default view for external users. > >> I do not understand what you mean by "one" view? > > The "one" view is the view exposed via the (default) compat tree. > > > >> Server should be able to have "all" views. > >> "View" is an equivalent of the "zones". > >> > >> SSSD has to get raw data from the external domain and give it to IPA. > >> IPA would have to merge the data coming from SSSD in server mode with > >> some set of data associated with a subset of clients. > >> I am not sure how it will be done (compat, cos or some other mechanism) > >> but this is the requirement. > > This would require multiple compat trees, one per view, it would be very > > expensive. > > > >> So for clarity let me restate the use cases: > >> > >> a) I had my users in a NIS or LDAP with POSIX attributes there. I used > >> to sync users from AD. I migrate from that to IPA but want to use trust > >> for my users because AD is authoritative source and I do not want/can > >> put POSIX into AD. > >> b) I have several NIS domains that I need to consolidate. For whatever > >> reasons I can't migrate to the unified POSIX namespace. I want an > >> equivalent of the Centrify Zones when different clients get different > >> uid/gid assignments for the same users. > >> c) I used sync so my POSIX attributes are in IPA but now I want to > >> switch to trust. > >> d) I had a third party solution that had posix zoning and I want to > >> replace it with the similar solution based on IPA. > >> > >> Views (plural) are a way to merge data and present it to a subset of > >> clients. In this context it is not really clear what you mean by "one" > >> view. > > In order to see views you'll need a modern SSSD client that knows how to > > apply them. Ie viewS are applied on the client side. The server shows > > only one view via LDAP. > > > > Simo. > > > OK, I agree with multiple views being expensive and merging things on > the client but how you define which one is the "default" on the server? We'll have one called "default" ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu May 29 16:30:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 29 May 2014 12:30:51 -0400 Subject: [Freeipa-devel] Handling of multiple krbPrincipalNames and of krbCanonicalNames In-Reply-To: <20131007195348.GA20708@redhat.com> References: <20131007195348.GA20708@redhat.com> Message-ID: <1401381051.2449.0.camel@ipa.example.com> On Mon, 2013-10-07 at 15:53 -0400, Nalin Dahyabhai wrote: > Comparing master's ipa-kdb's handling of krbPrincipalName and > krbCanonicalName attributes with that of the upstream kldap driver, > there are a few differences which I'm thinking are bugs. > > * If an entry has multiple krbPrincipalName values, the name which > was used to look it up is required to match only the last value of the > attribute that we read, not any of them. > > * If an entry has a krbCanonicalName value, and the name which we used > to look it up doesn't match it, if database aliases are allowed, we > return an error instead of using it to populate the returned entry. > > I'm attaching patches for both of these, though the second still doesn't > quite match the behavior of kldap.so, in that we don't preserve the > requested name if it differs from the canonical name only in case. I > don't know that it matters, but I'm mentioning here just in case. 0001: ACK 0002: I don't think that matters. If it does, the fix is easy. ACK Nathaniel From dpal at redhat.com Thu May 29 16:35:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 29 May 2014 12:35:23 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1401378117.3590.13.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> <5387549D.4050705@redhat.com> <1401378117.3590.13.camel@willson.li.ssimo.org> Message-ID: <538761CB.1070701@redhat.com> On 05/29/2014 11:41 AM, Simo Sorce wrote: > On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote: >> On 05/28/2014 11:20 PM, Simo Sorce wrote: >>> On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: >>>> On 05/27/2014 03:52 PM, Simo Sorce wrote: >>>>> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: >>>>>> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have started to write a design page for 'Migrating existing >>>>>>> environments to Trust' >>>>>>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >>>>>>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >>>>>>> https://fedorahosted.org/freeipa/ticket/3979 . >>>>>>> >>>>>> while working on a new version of the page with more details on design >>>>>> and implementation I came across the following problem. On the IPA >>>>>> server there should be a way for SSSD to deliver unmodified data (no >>>>>> view applied) or views other than the one for the IPA server to >>>>>> processes which delivers user and group data to other clients. This are >>>>>> mainly the extdom and the compat plugin of dirsrv. >>>>>> >>>>>> The two currently use standard glibc calls like getpwnam_r() to get the >>>>>> needed data from SSSD. While they can read the view objects form the >>>>>> LDAP tree there is no way to read the original data for users from >>>>>> trusted domains because it is only in the cache of SSSD. >>>>>> >>>>>> I'm looking for a way to allow SSSD to deliver the data without changing >>>>>> the protocol used by the NSS responder. >>>>>> >>>>>> One way I can think of is to use a new socket like >>>>>> /var/lib/sss/pipes/nss_noview and create a small library for the extdom >>>>>> and compat plugin to use the new socket. With this the plugin have to >>>>>> apply the views on their own if needed. >>>>>> >>>>>> Another way would be a new command for the NSS responder with two >>>>>> arguments, the view name (or empty for unmodified data) and a blob which >>>>>> contains the data for the corresponding request like e.g. getpwnam_r() or >>>>>> getgrgid_r(). Here the plugins have to use some new calls but all view >>>>>> processing can happen in sssd and the plugins can deliver the data >>>>>> directly. >>>>>> >>>>>> A drawback in both cases is that the memcache cannot be used. >>>>>> >>>>>> If someone has suggestions for SSSD or other ways how to deliver user >>>>>> and group data to client with other views than the IPA server I'm all >>>>>> ears. >>>>> Ok this one is hard to deal with in a way that will satisfy every >>>>> possible user. >>>>> >>>>> I think what we need to aim is simplicity and predictability at the >>>>> expense of flexibility. >>>>> >>>>> What I mean is that freeipa servers should be allowed to only stick to >>>>> one view, the default view for external users. >>>> I do not understand what you mean by "one" view? >>> The "one" view is the view exposed via the (default) compat tree. >>> >>>> Server should be able to have "all" views. >>>> "View" is an equivalent of the "zones". >>>> >>>> SSSD has to get raw data from the external domain and give it to IPA. >>>> IPA would have to merge the data coming from SSSD in server mode with >>>> some set of data associated with a subset of clients. >>>> I am not sure how it will be done (compat, cos or some other mechanism) >>>> but this is the requirement. >>> This would require multiple compat trees, one per view, it would be very >>> expensive. >>> >>>> So for clarity let me restate the use cases: >>>> >>>> a) I had my users in a NIS or LDAP with POSIX attributes there. I used >>>> to sync users from AD. I migrate from that to IPA but want to use trust >>>> for my users because AD is authoritative source and I do not want/can >>>> put POSIX into AD. >>>> b) I have several NIS domains that I need to consolidate. For whatever >>>> reasons I can't migrate to the unified POSIX namespace. I want an >>>> equivalent of the Centrify Zones when different clients get different >>>> uid/gid assignments for the same users. >>>> c) I used sync so my POSIX attributes are in IPA but now I want to >>>> switch to trust. >>>> d) I had a third party solution that had posix zoning and I want to >>>> replace it with the similar solution based on IPA. >>>> >>>> Views (plural) are a way to merge data and present it to a subset of >>>> clients. In this context it is not really clear what you mean by "one" >>>> view. >>> In order to see views you'll need a modern SSSD client that knows how to >>> apply them. Ie viewS are applied on the client side. The server shows >>> only one view via LDAP. >>> >>> Simo. >>> >> OK, I agree with multiple views being expensive and merging things on >> the client but how you define which one is the "default" on the server? > We'll have one called "default" ? > > Simo. > > I do not care about the name i care about the content. Imagine that there can be several different views. Which one is the default one? How it is picked? Id there a way to change from one view to another? Also this means that all legacy clients would have just one view because there will be a single compat all of them can be pointed to. May be if we can switch views on different replicas we would be able to create zones such that different replicas are used to serve different groups of legacy clients. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From npmccallum at redhat.com Thu May 29 16:40:41 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 29 May 2014 12:40:41 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1379938349.17271.32.camel@willson.li.ssimo.org> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <523FE712.80108@redhat.com> <1379938349.17271.32.camel@willson.li.ssimo.org> Message-ID: <1401381641.2449.4.camel@ipa.example.com> On Mon, 2013-09-23 at 08:12 -0400, Simo Sorce wrote: > On Mon, 2013-09-23 at 09:00 +0200, Petr Spacek wrote: > > On 20.9.2013 21:35, Simo Sorce wrote: > > > This patch set is an initial implementation of ticket #3859 > > > > > > It seem to be working fine in my initial testing but I have not yet > > > tested all cases. > > > > > > However I wonted to throw it on the list to get some initial feedback > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > default behavior. > > > > > > In particular, the current patch set would require us to make > > > host/service keytabs readable by the requesting party (whoever that is, > > > admin or host itself) in order to allow it to get back the actual > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > still all is needed to allow someone to change it. > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > particular I think we should allow either permission indipendently, and > > > it should be something an admin can change. However I do not like > > > allowing normal writes or reads to these attributes, mostly because w/o > > > access to the master key nobody can really make sense of actually > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > can be successfully decrypted. > > > > > > So I was wondering if we might want to prevent both reading and writing > > > via LDAP (except via extended operations) and instead use another method > > > to determine access patterns. > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > always falling back to the old one (if a password has been provided) ? > > > > > > Simo. > > > > I was always curious why we don't use normal kadmin protocol? :-) > > Kadmin won't respect LDAP based ACIs, it always operate as "root" > against LDAP, and has it's own simple ACL file. We want to be able to > easily manage and delegate access to keytab creation. > > We might try to change the kadmin code to impersonate the user but I > think it would be invasive, I never seriously looked into it though. Wouldn't such an approach have inherently better security properties (and potentially gain other operations for free)? The current patch set is also invasive (at least in terms of its size). If the kadmin approach is a similar sized or smaller change, I'd probably prefer that. There seems to be some indentation shuffling in the patches. I *think* this is because the old code has incorrect indentation. Nathaniel From pspacek at redhat.com Thu May 29 16:50:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 May 2014 18:50:50 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140529114809.GJ30381@localhost.localdomain> References: <20140529114809.GJ30381@localhost.localdomain> Message-ID: <5387656A.2080605@redhat.com> On 29.5.2014 13:48, Sumit Bose wrote: > == slapi-nis plugin/compat tree == > The compat tree offers a simplified LDAP tree with user and group data > for legacy clients. No data for this tree is stored on disk but it is > always created on the fly. It has to be noted that legacy clients might > be one of the major users of the user-views because chances are that > they were attached to the legacy systems with legacy ID management which > should be replaced by IPA. > > In contrast to the extdom plugin it is not possible to determine the > client based on the DN because connection might be anonymous. The > Slapi_PBlock contains the IP address of the client in > SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > tree requires a reverse-DNS lookup which might be unreliable. If the > reverse-DNS lookup was successful the slapi-nos plugin can follow the > same steps as the extdom plugin to lookup up and apply the view. Do we really want to base security decisions on reverse DNS resolution? That will be insecure. Attacker could tamper with reverse DNS to change UID/GID mapping ... Maybe we can store IP->view mapping in the LDAP database. That should be reliable if we assume that only TCP is used for connection to LDAP database. > As a alternative slapi-nis can provide one tree for each view. > > The first approach has the advantage that everything can be manages on > the server and no change on the legacy clients is needed, even if the > are assigned to a different view, but requires reverse-DNS and has more > search overhead. With the second approach every legacy system which > should get a specific view different from the default view has to be > pointed to the new tree. Using both in parallel is possible but might > not be worth the additional effort. -- Petr^2 Spacek From pspacek at redhat.com Thu May 29 16:57:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 May 2014 18:57:54 +0200 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1401381641.2449.4.camel@ipa.example.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <523FE712.80108@redhat.com> <1379938349.17271.32.camel@willson.li.ssimo.org> <1401381641.2449.4.camel@ipa.example.com> Message-ID: <53876712.5030208@redhat.com> On 29.5.2014 18:40, Nathaniel McCallum wrote: > On Mon, 2013-09-23 at 08:12 -0400, Simo Sorce wrote: >> On Mon, 2013-09-23 at 09:00 +0200, Petr Spacek wrote: >>> On 20.9.2013 21:35, Simo Sorce wrote: >>>> This patch set is an initial implementation of ticket #3859 >>>> >>>> It seem to be working fine in my initial testing but I have not yet >>>> tested all cases. >>>> >>>> However I wonted to throw it on the list to get some initial feedback >>>> about the choices I made wrt access control and ipa-getkeytab flags and >>>> default behavior. >>>> >>>> In particular, the current patch set would require us to make >>>> host/service keytabs readable by the requesting party (whoever that is, >>>> admin or host itself) in order to allow it to get back the actual >>>> keytab. I am not sure this is ideal. Also write access to the keytab is >>>> still all is needed to allow someone to change it. >>>> >>>> Neither is ideal, but it was simpler as a first implementation. In >>>> particular I think we should allow either permission indipendently, and >>>> it should be something an admin can change. However I do not like >>>> allowing normal writes or reads to these attributes, mostly because w/o >>>> access to the master key nobody can really make sense of actually >>>> reading out the contents of KrbPrincipalKey or could write a blob that >>>> can be successfully decrypted. >>>> >>>> So I was wondering if we might want to prevent both reading and writing >>>> via LDAP (except via extended operations) and instead use another method >>>> to determine access patterns. >>>> >>>> As for ipa-getkeytab is everyone ok with tryin the new method first and >>>> always falling back to the old one (if a password has been provided) ? >>>> >>>> Simo. >>> >>> I was always curious why we don't use normal kadmin protocol? :-) >> >> Kadmin won't respect LDAP based ACIs, it always operate as "root" >> against LDAP, This leads to question: Why? Wouldn't be approach with S4U sufficient? >> and has it's own simple ACL file. We want to be able to >> easily manage and delegate access to keytab creation. >> >> We might try to change the kadmin code to impersonate the user but I >> think it would be invasive, I never seriously looked into it though. IMHO we have two options: A) Operate as root & use LDAP proxy control. -- Determine DN of an object representing principal used by user. -- Use LDAP proxy control with given DN. B) Use S4U and connect to LDAP with user's credentials. > Wouldn't such an approach have inherently better security properties > (and potentially gain other operations for free)? The current patch set > is also invasive (at least in terms of its size). If the kadmin approach > is a similar sized or smaller change, I'd probably prefer that. I agree with Nathaniel. -- Petr^2 Spacek From rcritten at redhat.com Thu May 29 17:13:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 May 2014 13:13:56 -0400 Subject: [Freeipa-devel] [PATCHES] 0562-0563 ix internal error when global policy is not readable In-Reply-To: <5387543E.3010002@redhat.com> References: <5387543E.3010002@redhat.com> Message-ID: <53876AD4.6000108@redhat.com> Petr Viktorin wrote: > When investigating this issue I became very annoyed by the star import > hiding where names come from, so I did some cleanup first. > > > In krbtpolicy, an ACIError is now raised if: > - the user doesn't have permission to read any one of the ticket policy > attributes on the requested entry > (checked using attribute-level rights) > - any ticket policy attribute from the default policy is not available > (either not readable, or not there at all) > (only checked if these are accessed, i.e. when the user entry doesn't > override all of the defaults, or when requesting the global policy) > > That means if the user is not available at all, you get a NotFound, but > if global policy is not found it's assumed that it's just unreadable. That seems reasonable to me. I also noticed a typo, ddoesn't In the lower-level code, ldap2.py, we have some help can_[read|write|etc] for managing rights. Would doing something similar in baseldap be better than embedding the logic into each plugins? So instead of this: if rights is None: rights = baseldap.get_effective_rights( ldap, dn, self.obj.default_attributes) if 'r' not in rights.get(attrname.lower(), ''): raise errors.ACIError( info=_('Ticket policy for %s could not be read') % keys[-1]) You'd have this: if not baseldap.can_read(ldap, dn, attrname): raise errors.ACIError( info=_('Ticket policy for %s could not be read') % keys[-1]) This may end up fetching the rights multiple times depending on how many things need to be read, so perhaps passing that in if you have it already. rob From simo at redhat.com Thu May 29 17:31:04 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 13:31:04 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <5387656A.2080605@redhat.com> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> Message-ID: <1401384664.3590.19.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: > On 29.5.2014 13:48, Sumit Bose wrote: > > == slapi-nis plugin/compat tree == > > The compat tree offers a simplified LDAP tree with user and group data > > for legacy clients. No data for this tree is stored on disk but it is > > always created on the fly. It has to be noted that legacy clients might > > be one of the major users of the user-views because chances are that > > they were attached to the legacy systems with legacy ID management which > > should be replaced by IPA. > > > > In contrast to the extdom plugin it is not possible to determine the > > client based on the DN because connection might be anonymous. The > > Slapi_PBlock contains the IP address of the client in > > SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > > tree requires a reverse-DNS lookup which might be unreliable. If the > > reverse-DNS lookup was successful the slapi-nos plugin can follow the > > same steps as the extdom plugin to lookup up and apply the view. > > Do we really want to base security decisions on reverse DNS resolution? No we do not want to play these games. > That > will be insecure. Attacker could tamper with reverse DNS to change UID/GID > mapping ... Maybe we can store IP->view mapping in the LDAP database. That > should be reliable if we assume that only TCP is used for connection to LDAP > database. It is not just about it being insecure, it is about it being wrong. As soon as you have a bunch of clients behind a NAT this pans goes belly up. > > As a alternative slapi-nis can provide one tree for each view. This is the only alternative, if we decide to pursue it. Simo. -- Simo Sorce * Red Hat, Inc * New York From nalin at redhat.com Thu May 29 17:44:27 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 29 May 2014 13:44:27 -0400 Subject: [Freeipa-devel] CA certificate renewal, shared store trust settings Message-ID: <20140529174427.GC12741@redhat.com> I'm working on adding to certmonger the ability to read the IPA root certificate from the server and store it locally, and I'm looking at the V4 shared certificate store feature [1] with an eye toward also pulling down and processing those certificates. Before I head down that path, I've got a few questions about the schema that the page describes for storing trust information. Is the ipaKeyTrust attribute meant to be a part of the ipaKeyPolicy object class? Looking at the ipaKeyTrust attribute, the description suggests that it's a directoryString that should contain one of 'unknown', 'trusted', or 'distrusted' as its value. The syntax doesn't guarantee that, and that ambiguity makes me a little nervous. Any chance of tweaking the schema to remove that possibility? The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' and 'distrusted', appears to map pretty directly to the sort of information that OpenSSL stores in trusted certificates [2], but going through the man pages for x509(1) and verify(1), I don't see anything that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's that value intended to signify, and how would consumers of the certificates be expected to treat certificates from entries with that ipaKeyTrust value? Are there examples of what the ipaKeyUsage attribute should contain? Is there a recommended method for mapping from this representation to the form that we'd pass to certutil(1)'s '-t' option when storing the certificates in NSS databases, or is the intent that it be translated into NSS-specific PKCS#11 attributes set on those certificates? Thanks, Nalin [1] http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store [2] http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#openssl-trusted From dpal at redhat.com Thu May 29 18:08:42 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 29 May 2014 14:08:42 -0400 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users In-Reply-To: <5386D0F5.5040706@redhat.com> References: <537E0AAA.5090100@redhat.com> <538696D1.1000002@redhat.com> <5386D0F5.5040706@redhat.com> Message-ID: <538777AA.7080904@redhat.com> On 05/29/2014 02:17 AM, Martin Kosek wrote: > On 05/29/2014 04:09 AM, Dmitri Pal wrote: >> On 05/22/2014 10:33 AM, thierry bordaz wrote: >>> Hello, >>> >>> In order to provision staged users (account inactivated) with >>> there initial values: >>> >>> /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 >>> ----------------- >>> Added user "tb20" >>> ----------------- >>> User login: tb20 >>> First name: tb20 >>> Last name: tb20 >>> Full name: tb20 tb20 >>> Display name: tb20 tb20 >>> Initials: tt >>> Home directory: /home/tb20 >>> GECOS: tb20 tb20 >>> Login shell: /bin/sh >>> Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM >>> Email address: tb20 at idm.lab.bos.redhat.com >>> UID: -1 >>> GID: -1 >>> Account disabled: true >>> Password: False >>> Kerberos keys available: False >>> >>> ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" >>> -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 >>> dn: uid=tb20,cn=staged >>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>> dc=redhat,dc=com >>> displayName: tb20 tb20 >>> cn: tb20 tb20 >>> objectClass: top >>> objectClass: person >>> objectClass: organizationalperson >>> objectClass: inetorgperson >>> objectClass: inetuser >>> objectClass: posixaccount >>> objectClass: krbprincipalaux >>> objectClass: krbticketpolicyaux >>> objectClass: ipaobject >>> objectClass: ipasshuser >>> objectClass: ipaSshGroupOfPubKeys >>> loginShell: /bin/sh >>> uidNumber: -1 >>> ipaUniqueID: autogenerate >>> gidNumber: -1 >>> gecos: tb20 tb20 >>> sn: tb20 >>> homeDirectory: /home/tb20 >>> uid: tb20 >>> mail: tb20 at idm.lab.bos.redhat.com >>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>> givenName: tb20 >>> initials: tt >>> >>> I needed to resctrict the scope of the following plugins: >>> >>> dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config >>> nsslapd-pluginarg1: >>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi >>> ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> dn: cn=Posix IDs,cn=Distributed Numeric Assignment >>> Plugin,cn=plugins,cn=config >>> dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> dn: cn=MemberOf Plugin,cn=plugins,cn=config >>> memberofentryscope: >>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> In fact I need them to not modify the added entry when it is added >>> under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". >>> Now is it possible to limit those plugins scope to the >>> 'cn=accounts' part of the tree ? I guess not. >>> If it is not possible, a solution is to make the scope >>> multi-valued attributes or to introduce a new config attribute >>> '*notInScope' also multi-valued. >>> A problem is the 'cn=ipaUniqueID uniqueness' that rely on the >>> 'attribute uniqueness' plugin with a argv[ ], not really >>> convenient to pass 2 multivalued attributes. >>> >>> If anyone is having others solutions it would help me a lot :-) >>> >>> thanks >>> thierry >>> >>> >> The easiest solution IMO is to not treat staging area as an account area, i.e >> instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, >> cn=staging, dc=... > Actually, this almost exactly the DN I wrote in the RFE: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status > > Proposed containers are: > > cn=staged users,cn=accounts,cn=provisioning,$SUFFIX > cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX > >> This way if in future we will have some staging for other objects (for whatever >> reason) we will create containers under common "staging" area. >> I would also argue that "deleted" should not be under accounts. > Agreed. This will also make the plugin configuration (tree exclusion) easier. > > Martin > I do not think so. My proposal is not to have staging under cn=accounts because most of the plugins enforce uniqueness and other consistency like DNA in the cn=account sub tree. Moving it out would move the staging out of the scope of the plugins and plugin configuration would not need to change. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Thu May 29 18:13:33 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 14:13:33 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <538761CB.1070701@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> <5387549D.4050705@redhat.com> <1401378117.3590.13.camel@willson.li.ssimo.org> <538761CB.1070701@redhat.com> Message-ID: <1401387213.3590.21.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote: > On 05/29/2014 11:41 AM, Simo Sorce wrote: > > On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote: > >> On 05/28/2014 11:20 PM, Simo Sorce wrote: > >>> On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: > >>>> On 05/27/2014 03:52 PM, Simo Sorce wrote: > >>>>> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: > >>>>>> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I have started to write a design page for 'Migrating existing > >>>>>>> environments to Trust' > >>>>>>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > >>>>>>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > >>>>>>> https://fedorahosted.org/freeipa/ticket/3979 . > >>>>>>> > >>>>>> while working on a new version of the page with more details on design > >>>>>> and implementation I came across the following problem. On the IPA > >>>>>> server there should be a way for SSSD to deliver unmodified data (no > >>>>>> view applied) or views other than the one for the IPA server to > >>>>>> processes which delivers user and group data to other clients. This are > >>>>>> mainly the extdom and the compat plugin of dirsrv. > >>>>>> > >>>>>> The two currently use standard glibc calls like getpwnam_r() to get the > >>>>>> needed data from SSSD. While they can read the view objects form the > >>>>>> LDAP tree there is no way to read the original data for users from > >>>>>> trusted domains because it is only in the cache of SSSD. > >>>>>> > >>>>>> I'm looking for a way to allow SSSD to deliver the data without changing > >>>>>> the protocol used by the NSS responder. > >>>>>> > >>>>>> One way I can think of is to use a new socket like > >>>>>> /var/lib/sss/pipes/nss_noview and create a small library for the extdom > >>>>>> and compat plugin to use the new socket. With this the plugin have to > >>>>>> apply the views on their own if needed. > >>>>>> > >>>>>> Another way would be a new command for the NSS responder with two > >>>>>> arguments, the view name (or empty for unmodified data) and a blob which > >>>>>> contains the data for the corresponding request like e.g. getpwnam_r() or > >>>>>> getgrgid_r(). Here the plugins have to use some new calls but all view > >>>>>> processing can happen in sssd and the plugins can deliver the data > >>>>>> directly. > >>>>>> > >>>>>> A drawback in both cases is that the memcache cannot be used. > >>>>>> > >>>>>> If someone has suggestions for SSSD or other ways how to deliver user > >>>>>> and group data to client with other views than the IPA server I'm all > >>>>>> ears. > >>>>> Ok this one is hard to deal with in a way that will satisfy every > >>>>> possible user. > >>>>> > >>>>> I think what we need to aim is simplicity and predictability at the > >>>>> expense of flexibility. > >>>>> > >>>>> What I mean is that freeipa servers should be allowed to only stick to > >>>>> one view, the default view for external users. > >>>> I do not understand what you mean by "one" view? > >>> The "one" view is the view exposed via the (default) compat tree. > >>> > >>>> Server should be able to have "all" views. > >>>> "View" is an equivalent of the "zones". > >>>> > >>>> SSSD has to get raw data from the external domain and give it to IPA. > >>>> IPA would have to merge the data coming from SSSD in server mode with > >>>> some set of data associated with a subset of clients. > >>>> I am not sure how it will be done (compat, cos or some other mechanism) > >>>> but this is the requirement. > >>> This would require multiple compat trees, one per view, it would be very > >>> expensive. > >>> > >>>> So for clarity let me restate the use cases: > >>>> > >>>> a) I had my users in a NIS or LDAP with POSIX attributes there. I used > >>>> to sync users from AD. I migrate from that to IPA but want to use trust > >>>> for my users because AD is authoritative source and I do not want/can > >>>> put POSIX into AD. > >>>> b) I have several NIS domains that I need to consolidate. For whatever > >>>> reasons I can't migrate to the unified POSIX namespace. I want an > >>>> equivalent of the Centrify Zones when different clients get different > >>>> uid/gid assignments for the same users. > >>>> c) I used sync so my POSIX attributes are in IPA but now I want to > >>>> switch to trust. > >>>> d) I had a third party solution that had posix zoning and I want to > >>>> replace it with the similar solution based on IPA. > >>>> > >>>> Views (plural) are a way to merge data and present it to a subset of > >>>> clients. In this context it is not really clear what you mean by "one" > >>>> view. > >>> In order to see views you'll need a modern SSSD client that knows how to > >>> apply them. Ie viewS are applied on the client side. The server shows > >>> only one view via LDAP. > >>> > >>> Simo. > >>> > >> OK, I agree with multiple views being expensive and merging things on > >> the client but how you define which one is the "default" on the server? > > We'll have one called "default" ? > > > > Simo. > > > > > I do not care about the name i care about the content. Imagine that > there can be several different views. Which one is the default one? How > it is picked? Id there a way to change from one view to another? Also > this means that all legacy clients would have just one view because > there will be a single compat all of them can be pointed to. May be if > we can switch views on different replicas we would be able to create > zones such that different replicas are used to serve different groups of > legacy clients. No we can't switch the default view for external users via LDAP on different replicas, as that would cause clients to have conflicting data. If we need different views via LDAP we will have to explicitly enable additional compat views. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu May 29 18:14:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 29 May 2014 14:14:10 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <1401367153.3590.8.camel@willson.li.ssimo.org> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> Message-ID: <538778F2.6000504@redhat.com> On 05/29/2014 08:39 AM, Simo Sorce wrote: > On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>> This, I believe, has already been covered, but I'm concerned with the >>>>>> (over)use of active/inactive in this discussion. >>>>>> >>>>>> I think use of "inactive" and "active" to describe users might be >>>>>> confusing since there is already an account enable/disable command. >>>>>> This >>>>>> on top of unlock, are there now 3 possible boolean states a user can >>>>>> be >>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>> deleted/active and staged/active? >>>>>> >>>>> Agree, we should only have "ipa user-unstage " and not call >>>>> this operations with words like active/inactive. >>>>> >>>>> User's in the staging area are not inactive, they are *not* users yet in >>>>> the first place. >>>>> >>>>> Simo. >>>>> >>>> Ok. Let us consolidate the decisions, I think we are now running in circles. >>>> Let me start from Petr3's API proposal which was a functionally complete >>>> proposal and start from there: >>>> >>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>> ... >>>>> My proposal would be that the move commands use the verb for the target and an >>>>> option for the source, and add/mod use an option for the container: >>>>> >>>>> 1) adding a new user >>>>> (to active) ipa user-add tuser ... >>>>> (to stage) ipa user-add tuser --staged ... >>>> Ok. >>>> >>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>> Not needed. >>>> >>>>> 2) moving to main >>>>> (from stage) ipa user-activate tuser (**) >>>>> (from del) ipa user-activate tuser --deleted >>>> We need both, alternative is Simo's proposal: >>>> >>>> ipa user-unstage >>>> ipa user-undelete >>>> >>>> I personally like unstage and undelete commands, I would go with those. >>> Sorry for coming late to the party. >>> I strongly do not like "unstage" >>> This suggests that the user will be removed from staged but does not indicate >>> that the full user will be created. >>> As I suggested elsewhere provision-user or user-provision (or may be even >>> user-add --from-stage) would be better. >> As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation >> could get messy and would not create the right API. Using a separate call would >> be cleaner. As we see, choosing the right action term has proven very difficult >> - everyone has strong opinion on the command name :-) >> >> I already saw user-activate and user-unstage to be trashed so I am thinking >> what we are left with. I am still fan of user-unstage, user-provision is not >> telling me much more than user-unstage. >> >>>>> 3) moving to deleted >>>>> (from active) ipa user-del tuser >>>> Ok. >>>> >>>>> (from stage) ipa user-del tuser --staged >>>> IMO staged deleted users should not be moved to deleted container, but simply >>>> permanently deleted. As Simo noted, staged user are not real users, just >>>> incomplete users. >>>> >>>>> 4) moving to stage >>>>> (from active) ipa user-stage tuser >>> >>> This was suggested for completeness. >>> I think we are cutting corners but I would not insist here. >>> >>>>> (from del) ipa user-stage tuser --deleted >>>> None of the commands are needed for the basic workflow. >>> But this is a valid use case. I created a user, deleted it and want to rebuild >>> it becuase something got corrupted in the original entry. I agree it is not a >>> primary use case but then we should have a ticket to track this RFE for future. >> This was not about cutting corners, this was about what operation makes sense >> and what we should support. Stage was defined as a tree with incomplete user, >> thus this proposal - Simo was not very OK with this workflow. >> >>>>> 5) modifying >>>>> (in active) ipa user-mod tuser ... >>>> Ok. >>>> >>>>> (in stage) ipa user-mod tuser --staged ... >>>> Simo did not like this command, I would personally add it. As long as we have >>>> "ipa user-add --staged", we should also have an option to delete and modify >>>> user in staged area. >>>> >>>>> (in del) ipa user-mod tuser --deleted ... >>>> Not needed. >>>> >>>> Is this acceptable for everyone? If yes, the next step would be for Thierry >>>> to update the design page with new proposals. >>>> >>>> Martin >> Let me try to consolidate again the proposals and changes for the workflow&API >> we have so far: >> >> 1) Manipulating staged users >> - staged users must have UID RDN >> - UID uniqueness plugin should not be enforcing in staging area >> - we do not want it in user plugin as it requires different parameters and >> objectclasses >> - API: >> ipa stage-user-add >> ipa stage-user-mod >> ipa stage-user-find >> ipa stage-user-del >> >> 2) Activating staged user >> - activation will not do MODRDN, it will create a new user in active container >> and then delete the old one (to create right structural objectclass set) >> - for now, we need to allow operator delete any user in staged and add any user >> in active tree >> - API >> ipa stage-user-activate >> - other options mentioned in the past were user-unstage and user-activate >> >> 3) Manipulating deleted users >> - deletion and undeletion will do MODRDN and will use the ACI that Thierry >> implemented >> - API >> ipa user-del >> ipa user-undel OR ipa user-undelete >> - Dmitri mentioned that he would like to see the move from deleted to staged. I >> would do it via flag: >> ipa user-undel --to-stage >> >> >> Does that look better now? Thanks, > Yes, although I do not see the need for --to-stage honestly. I agree we can just leave it as a future ticket. Rest looks OK. > > Simo. > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Thu May 29 18:15:59 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 14:15:59 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <53876712.5030208@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <523FE712.80108@redhat.com> <1379938349.17271.32.camel@willson.li.ssimo.org> <1401381641.2449.4.camel@ipa.example.com> <53876712.5030208@redhat.com> Message-ID: <1401387359.3590.22.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 18:57 +0200, Petr Spacek wrote: > On 29.5.2014 18:40, Nathaniel McCallum wrote: > > On Mon, 2013-09-23 at 08:12 -0400, Simo Sorce wrote: > >> On Mon, 2013-09-23 at 09:00 +0200, Petr Spacek wrote: > >>> On 20.9.2013 21:35, Simo Sorce wrote: > >>>> This patch set is an initial implementation of ticket #3859 > >>>> > >>>> It seem to be working fine in my initial testing but I have not yet > >>>> tested all cases. > >>>> > >>>> However I wonted to throw it on the list to get some initial feedback > >>>> about the choices I made wrt access control and ipa-getkeytab flags and > >>>> default behavior. > >>>> > >>>> In particular, the current patch set would require us to make > >>>> host/service keytabs readable by the requesting party (whoever that is, > >>>> admin or host itself) in order to allow it to get back the actual > >>>> keytab. I am not sure this is ideal. Also write access to the keytab is > >>>> still all is needed to allow someone to change it. > >>>> > >>>> Neither is ideal, but it was simpler as a first implementation. In > >>>> particular I think we should allow either permission indipendently, and > >>>> it should be something an admin can change. However I do not like > >>>> allowing normal writes or reads to these attributes, mostly because w/o > >>>> access to the master key nobody can really make sense of actually > >>>> reading out the contents of KrbPrincipalKey or could write a blob that > >>>> can be successfully decrypted. > >>>> > >>>> So I was wondering if we might want to prevent both reading and writing > >>>> via LDAP (except via extended operations) and instead use another method > >>>> to determine access patterns. > >>>> > >>>> As for ipa-getkeytab is everyone ok with tryin the new method first and > >>>> always falling back to the old one (if a password has been provided) ? > >>>> > >>>> Simo. > >>> > >>> I was always curious why we don't use normal kadmin protocol? :-) > >> > >> Kadmin won't respect LDAP based ACIs, it always operate as "root" > >> against LDAP, > This leads to question: Why? Wouldn't be approach with S4U sufficient? > > >> and has it's own simple ACL file. We want to be able to > >> easily manage and delegate access to keytab creation. > >> > >> We might try to change the kadmin code to impersonate the user but I > >> think it would be invasive, I never seriously looked into it though. > > IMHO we have two options: > A) Operate as root & use LDAP proxy control. > -- Determine DN of an object representing principal used by user. > -- Use LDAP proxy control with given DN. > > B) Use S4U and connect to LDAP with user's credentials. > > > Wouldn't such an approach have inherently better security properties > > (and potentially gain other operations for free)? The current patch set > > is also invasive (at least in terms of its size). If the kadmin approach > > is a similar sized or smaller change, I'd probably prefer that. > > I agree with Nathaniel. We have discussed this with MIT already, it is an important change to kadmin and will not be available even in 1.13, so that is not an option for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 29 18:24:34 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 May 2014 14:24:34 -0400 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users In-Reply-To: <538777AA.7080904@redhat.com> References: <537E0AAA.5090100@redhat.com> <538696D1.1000002@redhat.com> <5386D0F5.5040706@redhat.com> <538777AA.7080904@redhat.com> Message-ID: <1401387874.3590.26.camel@willson.li.ssimo.org> On Thu, 2014-05-29 at 14:08 -0400, Dmitri Pal wrote: > On 05/29/2014 02:17 AM, Martin Kosek wrote: > > On 05/29/2014 04:09 AM, Dmitri Pal wrote: > >> On 05/22/2014 10:33 AM, thierry bordaz wrote: > >>> Hello, > >>> > >>> In order to provision staged users (account inactivated) with > >>> there initial values: > >>> > >>> /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 > >>> ----------------- > >>> Added user "tb20" > >>> ----------------- > >>> User login: tb20 > >>> First name: tb20 > >>> Last name: tb20 > >>> Full name: tb20 tb20 > >>> Display name: tb20 tb20 > >>> Initials: tt > >>> Home directory: /home/tb20 > >>> GECOS: tb20 tb20 > >>> Login shell: /bin/sh > >>> Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM > >>> Email address: tb20 at idm.lab.bos.redhat.com > >>> UID: -1 > >>> GID: -1 > >>> Account disabled: true > >>> Password: False > >>> Kerberos keys available: False > >>> > >>> ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" > >>> -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 > >>> dn: uid=tb20,cn=staged > >>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, > >>> dc=redhat,dc=com > >>> displayName: tb20 tb20 > >>> cn: tb20 tb20 > >>> objectClass: top > >>> objectClass: person > >>> objectClass: organizationalperson > >>> objectClass: inetorgperson > >>> objectClass: inetuser > >>> objectClass: posixaccount > >>> objectClass: krbprincipalaux > >>> objectClass: krbticketpolicyaux > >>> objectClass: ipaobject > >>> objectClass: ipasshuser > >>> objectClass: ipaSshGroupOfPubKeys > >>> loginShell: /bin/sh > >>> uidNumber: -1 > >>> ipaUniqueID: autogenerate > >>> gidNumber: -1 > >>> gecos: tb20 tb20 > >>> sn: tb20 > >>> homeDirectory: /home/tb20 > >>> uid: tb20 > >>> mail: tb20 at idm.lab.bos.redhat.com > >>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM > >>> givenName: tb20 > >>> initials: tt > >>> > >>> I needed to resctrict the scope of the following plugins: > >>> > >>> dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config > >>> nsslapd-pluginarg1: > >>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >>> > >>> dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi > >>> ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >>> > >>> dn: cn=Posix IDs,cn=Distributed Numeric Assignment > >>> Plugin,cn=plugins,cn=config > >>> dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >>> > >>> dn: cn=MemberOf Plugin,cn=plugins,cn=config > >>> memberofentryscope: > >>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > >>> > >>> In fact I need them to not modify the added entry when it is added > >>> under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". > >>> Now is it possible to limit those plugins scope to the > >>> 'cn=accounts' part of the tree ? I guess not. > >>> If it is not possible, a solution is to make the scope > >>> multi-valued attributes or to introduce a new config attribute > >>> '*notInScope' also multi-valued. > >>> A problem is the 'cn=ipaUniqueID uniqueness' that rely on the > >>> 'attribute uniqueness' plugin with a argv[ ], not really > >>> convenient to pass 2 multivalued attributes. > >>> > >>> If anyone is having others solutions it would help me a lot :-) > >>> > >>> thanks > >>> thierry > >>> > >>> > >> The easiest solution IMO is to not treat staging area as an account area, i.e > >> instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, > >> cn=staging, dc=... > > Actually, this almost exactly the DN I wrote in the RFE: > > > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status > > > > Proposed containers are: > > > > cn=staged users,cn=accounts,cn=provisioning,$SUFFIX > > cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX > > > >> This way if in future we will have some staging for other objects (for whatever > >> reason) we will create containers under common "staging" area. > >> I would also argue that "deleted" should not be under accounts. > > Agreed. This will also make the plugin configuration (tree exclusion) easier. > > > > Martin > > > I do not think so. My proposal is not to have staging under cn=accounts > because most of the plugins enforce uniqueness and other consistency > like DNA in the cn=account sub tree. Moving it out would move the > staging out of the scope of the plugins and plugin configuration would > not need to change. Dmitri, I think you need to pay attention to the whole suffix :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From redhatrises at gmail.com Thu May 29 23:11:30 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 May 2014 17:11:30 -0600 Subject: [Freeipa-devel] [PATCH 0020] ipa recursively adds old backups Message-ID: Hello, This is a patch for https://fedorahosted.org/freeipa/ticket/4331 It's a one liner that just adds an exclude to the tar command to ignore the /var/lib/ipa/backup folder. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0020-ipa-recursively-adds-old-backups.patch Type: text/x-patch Size: 896 bytes Desc: not available URL: From dpal at redhat.com Fri May 30 04:03:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 00:03:25 -0400 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users In-Reply-To: <1401387874.3590.26.camel@willson.li.ssimo.org> References: <537E0AAA.5090100@redhat.com> <538696D1.1000002@redhat.com> <5386D0F5.5040706@redhat.com> <538777AA.7080904@redhat.com> <1401387874.3590.26.camel@willson.li.ssimo.org> Message-ID: <5388030D.9040405@redhat.com> On 05/29/2014 02:24 PM, Simo Sorce wrote: > On Thu, 2014-05-29 at 14:08 -0400, Dmitri Pal wrote: >> On 05/29/2014 02:17 AM, Martin Kosek wrote: >>> On 05/29/2014 04:09 AM, Dmitri Pal wrote: >>>> On 05/22/2014 10:33 AM, thierry bordaz wrote: >>>>> Hello, >>>>> >>>>> In order to provision staged users (account inactivated) with >>>>> there initial values: >>>>> >>>>> /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 >>>>> ----------------- >>>>> Added user "tb20" >>>>> ----------------- >>>>> User login: tb20 >>>>> First name: tb20 >>>>> Last name: tb20 >>>>> Full name: tb20 tb20 >>>>> Display name: tb20 tb20 >>>>> Initials: tt >>>>> Home directory: /home/tb20 >>>>> GECOS: tb20 tb20 >>>>> Login shell: /bin/sh >>>>> Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>> Email address: tb20 at idm.lab.bos.redhat.com >>>>> UID: -1 >>>>> GID: -1 >>>>> Account disabled: true >>>>> Password: False >>>>> Kerberos keys available: False >>>>> >>>>> ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" >>>>> -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 >>>>> dn: uid=tb20,cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>>>> dc=redhat,dc=com >>>>> displayName: tb20 tb20 >>>>> cn: tb20 tb20 >>>>> objectClass: top >>>>> objectClass: person >>>>> objectClass: organizationalperson >>>>> objectClass: inetorgperson >>>>> objectClass: inetuser >>>>> objectClass: posixaccount >>>>> objectClass: krbprincipalaux >>>>> objectClass: krbticketpolicyaux >>>>> objectClass: ipaobject >>>>> objectClass: ipasshuser >>>>> objectClass: ipaSshGroupOfPubKeys >>>>> loginShell: /bin/sh >>>>> uidNumber: -1 >>>>> ipaUniqueID: autogenerate >>>>> gidNumber: -1 >>>>> gecos: tb20 tb20 >>>>> sn: tb20 >>>>> homeDirectory: /home/tb20 >>>>> uid: tb20 >>>>> mail: tb20 at idm.lab.bos.redhat.com >>>>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>>>> givenName: tb20 >>>>> initials: tt >>>>> >>>>> I needed to resctrict the scope of the following plugins: >>>>> >>>>> dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config >>>>> nsslapd-pluginarg1: >>>>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>> >>>>> dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi >>>>> ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>> >>>>> dn: cn=Posix IDs,cn=Distributed Numeric Assignment >>>>> Plugin,cn=plugins,cn=config >>>>> dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>> >>>>> dn: cn=MemberOf Plugin,cn=plugins,cn=config >>>>> memberofentryscope: >>>>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>> >>>>> In fact I need them to not modify the added entry when it is added >>>>> under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". >>>>> Now is it possible to limit those plugins scope to the >>>>> 'cn=accounts' part of the tree ? I guess not. >>>>> If it is not possible, a solution is to make the scope >>>>> multi-valued attributes or to introduce a new config attribute >>>>> '*notInScope' also multi-valued. >>>>> A problem is the 'cn=ipaUniqueID uniqueness' that rely on the >>>>> 'attribute uniqueness' plugin with a argv[ ], not really >>>>> convenient to pass 2 multivalued attributes. >>>>> >>>>> If anyone is having others solutions it would help me a lot :-) >>>>> >>>>> thanks >>>>> thierry >>>>> >>>>> >>>> The easiest solution IMO is to not treat staging area as an account area, i.e >>>> instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, >>>> cn=staging, dc=... >>> Actually, this almost exactly the DN I wrote in the RFE: >>> >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status >>> >>> Proposed containers are: >>> >>> cn=staged users,cn=accounts,cn=provisioning,$SUFFIX >>> cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX >>> >>>> This way if in future we will have some staging for other objects (for whatever >>>> reason) we will create containers under common "staging" area. >>>> I would also argue that "deleted" should not be under accounts. >>> Agreed. This will also make the plugin configuration (tree exclusion) easier. >>> >>> Martin >>> >> I do not think so. My proposal is not to have staging under cn=accounts >> because most of the plugins enforce uniqueness and other consistency >> like DNA in the cn=account sub tree. Moving it out would move the >> staging out of the scope of the plugins and plugin configuration would >> not need to change. > Dmitri, I think you need to pay attention to the whole suffix :-) > > Simo. > @#$%^. Mia Culpa. Missed the cn=provisioning part. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri May 30 04:09:13 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 00:09:13 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1401387213.3590.21.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> <5387549D.4050705@redhat.com> <1401378117.3590.13.camel@willson.li.ssimo.org> <538761CB.1070701@redhat.com> <1401387213.3590.21.camel@willson.li.ssimo.org> Message-ID: <53880469.7040305@redhat.com> On 05/29/2014 02:13 PM, Simo Sorce wrote: > On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote: >> On 05/29/2014 11:41 AM, Simo Sorce wrote: >>> On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote: >>>> On 05/28/2014 11:20 PM, Simo Sorce wrote: >>>>> On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: >>>>>> On 05/27/2014 03:52 PM, Simo Sorce wrote: >>>>>>> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: >>>>>>>> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have started to write a design page for 'Migrating existing >>>>>>>>> environments to Trust' >>>>>>>>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >>>>>>>>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3979 . >>>>>>>>> >>>>>>>> while working on a new version of the page with more details on design >>>>>>>> and implementation I came across the following problem. On the IPA >>>>>>>> server there should be a way for SSSD to deliver unmodified data (no >>>>>>>> view applied) or views other than the one for the IPA server to >>>>>>>> processes which delivers user and group data to other clients. This are >>>>>>>> mainly the extdom and the compat plugin of dirsrv. >>>>>>>> >>>>>>>> The two currently use standard glibc calls like getpwnam_r() to get the >>>>>>>> needed data from SSSD. While they can read the view objects form the >>>>>>>> LDAP tree there is no way to read the original data for users from >>>>>>>> trusted domains because it is only in the cache of SSSD. >>>>>>>> >>>>>>>> I'm looking for a way to allow SSSD to deliver the data without changing >>>>>>>> the protocol used by the NSS responder. >>>>>>>> >>>>>>>> One way I can think of is to use a new socket like >>>>>>>> /var/lib/sss/pipes/nss_noview and create a small library for the extdom >>>>>>>> and compat plugin to use the new socket. With this the plugin have to >>>>>>>> apply the views on their own if needed. >>>>>>>> >>>>>>>> Another way would be a new command for the NSS responder with two >>>>>>>> arguments, the view name (or empty for unmodified data) and a blob which >>>>>>>> contains the data for the corresponding request like e.g. getpwnam_r() or >>>>>>>> getgrgid_r(). Here the plugins have to use some new calls but all view >>>>>>>> processing can happen in sssd and the plugins can deliver the data >>>>>>>> directly. >>>>>>>> >>>>>>>> A drawback in both cases is that the memcache cannot be used. >>>>>>>> >>>>>>>> If someone has suggestions for SSSD or other ways how to deliver user >>>>>>>> and group data to client with other views than the IPA server I'm all >>>>>>>> ears. >>>>>>> Ok this one is hard to deal with in a way that will satisfy every >>>>>>> possible user. >>>>>>> >>>>>>> I think what we need to aim is simplicity and predictability at the >>>>>>> expense of flexibility. >>>>>>> >>>>>>> What I mean is that freeipa servers should be allowed to only stick to >>>>>>> one view, the default view for external users. >>>>>> I do not understand what you mean by "one" view? >>>>> The "one" view is the view exposed via the (default) compat tree. >>>>> >>>>>> Server should be able to have "all" views. >>>>>> "View" is an equivalent of the "zones". >>>>>> >>>>>> SSSD has to get raw data from the external domain and give it to IPA. >>>>>> IPA would have to merge the data coming from SSSD in server mode with >>>>>> some set of data associated with a subset of clients. >>>>>> I am not sure how it will be done (compat, cos or some other mechanism) >>>>>> but this is the requirement. >>>>> This would require multiple compat trees, one per view, it would be very >>>>> expensive. >>>>> >>>>>> So for clarity let me restate the use cases: >>>>>> >>>>>> a) I had my users in a NIS or LDAP with POSIX attributes there. I used >>>>>> to sync users from AD. I migrate from that to IPA but want to use trust >>>>>> for my users because AD is authoritative source and I do not want/can >>>>>> put POSIX into AD. >>>>>> b) I have several NIS domains that I need to consolidate. For whatever >>>>>> reasons I can't migrate to the unified POSIX namespace. I want an >>>>>> equivalent of the Centrify Zones when different clients get different >>>>>> uid/gid assignments for the same users. >>>>>> c) I used sync so my POSIX attributes are in IPA but now I want to >>>>>> switch to trust. >>>>>> d) I had a third party solution that had posix zoning and I want to >>>>>> replace it with the similar solution based on IPA. >>>>>> >>>>>> Views (plural) are a way to merge data and present it to a subset of >>>>>> clients. In this context it is not really clear what you mean by "one" >>>>>> view. >>>>> In order to see views you'll need a modern SSSD client that knows how to >>>>> apply them. Ie viewS are applied on the client side. The server shows >>>>> only one view via LDAP. >>>>> >>>>> Simo. >>>>> >>>> OK, I agree with multiple views being expensive and merging things on >>>> the client but how you define which one is the "default" on the server? >>> We'll have one called "default" ? >>> >>> Simo. >>> >>> >> I do not care about the name i care about the content. Imagine that >> there can be several different views. Which one is the default one? How >> it is picked? Id there a way to change from one view to another? Also >> this means that all legacy clients would have just one view because >> there will be a single compat all of them can be pointed to. May be if >> we can switch views on different replicas we would be able to create >> zones such that different replicas are used to serve different groups of >> legacy clients. > No we can't switch the default view for external users via LDAP on > different replicas, as that would cause clients to have conflicting > data. > > If we need different views via LDAP we will have to explicitly enable > additional compat views. > > Simo. > May be we can enhance the compat view to use sub types for posix attributes that denote a view. Then use mapping of client IP/Hostname to a view using some kind of relation object. DS can already consider IP of the client so may be we can extend it to use IP to pick the right sub-type value from a MV attribute. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri May 30 04:14:33 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 00:14:33 -0400 Subject: [Freeipa-devel] ipa-server-install error In-Reply-To: References: Message-ID: <538805A9.40304@redhat.com> On 05/29/2014 01:44 AM, James wrote: > /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" Looks like and AVC that lead to restart failure of the PKI instance that in turn led to failure to configure CA. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri May 30 04:23:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 00:23:53 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <1401384664.3590.19.camel@willson.li.ssimo.org> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> Message-ID: <538807D9.6080905@redhat.com> On 05/29/2014 01:31 PM, Simo Sorce wrote: > On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >> On 29.5.2014 13:48, Sumit Bose wrote: >>> == slapi-nis plugin/compat tree == >>> The compat tree offers a simplified LDAP tree with user and group data >>> for legacy clients. No data for this tree is stored on disk but it is >>> always created on the fly. It has to be noted that legacy clients might >>> be one of the major users of the user-views because chances are that >>> they were attached to the legacy systems with legacy ID management which >>> should be replaced by IPA. >>> >>> In contrast to the extdom plugin it is not possible to determine the >>> client based on the DN because connection might be anonymous. The >>> Slapi_PBlock contains the IP address of the client in >>> SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >>> tree requires a reverse-DNS lookup which might be unreliable. If the >>> reverse-DNS lookup was successful the slapi-nos plugin can follow the >>> same steps as the extdom plugin to lookup up and apply the view. >> Do we really want to base security decisions on reverse DNS resolution? > No we do not want to play these games. > >> That >> will be insecure. Attacker could tamper with reverse DNS to change UID/GID >> mapping ... Maybe we can store IP->view mapping in the LDAP database. That >> should be reliable if we assume that only TCP is used for connection to LDAP >> database. > It is not just about it being insecure, it is about it being wrong. > As soon as you have a bunch of clients behind a NAT this pans goes belly > up. > >>> As a alternative slapi-nis can provide one tree for each view. > This is the only alternative, if we decide to pursue it. > > Simo. > Can we at least do something like CoS and use the base compat tree and overwrite just uid/gid on the fly instead of using the whole another view? That would reduce the size of the additional views significantly and would save cycles used for keeping each view in sync with underlying DB. In this case there will be still one view and dynamic overwrite in the search results. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Fri May 30 04:54:22 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 30 May 2014 00:54:22 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <53880469.7040305@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> <5387549D.4050705@redhat.com> <1401378117.3590.13.camel@willson.li.ssimo.org> <538761CB.1070701@redhat.com> <1401387213.3590.21.camel@willson.li.ssimo.org> <53880469.7040305@redhat.com> Message-ID: <1401425662.3590.28.camel@willson.li.ssimo.org> On Fri, 2014-05-30 at 00:09 -0400, Dmitri Pal wrote: > On 05/29/2014 02:13 PM, Simo Sorce wrote: > > On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote: > >> On 05/29/2014 11:41 AM, Simo Sorce wrote: > >>> On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote: > >>>> On 05/28/2014 11:20 PM, Simo Sorce wrote: > >>>>> On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: > >>>>>> On 05/27/2014 03:52 PM, Simo Sorce wrote: > >>>>>>> On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: > >>>>>>>> On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have started to write a design page for 'Migrating existing > >>>>>>>>> environments to Trust' > >>>>>>>>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > >>>>>>>>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3979 . > >>>>>>>>> > >>>>>>>> while working on a new version of the page with more details on design > >>>>>>>> and implementation I came across the following problem. On the IPA > >>>>>>>> server there should be a way for SSSD to deliver unmodified data (no > >>>>>>>> view applied) or views other than the one for the IPA server to > >>>>>>>> processes which delivers user and group data to other clients. This are > >>>>>>>> mainly the extdom and the compat plugin of dirsrv. > >>>>>>>> > >>>>>>>> The two currently use standard glibc calls like getpwnam_r() to get the > >>>>>>>> needed data from SSSD. While they can read the view objects form the > >>>>>>>> LDAP tree there is no way to read the original data for users from > >>>>>>>> trusted domains because it is only in the cache of SSSD. > >>>>>>>> > >>>>>>>> I'm looking for a way to allow SSSD to deliver the data without changing > >>>>>>>> the protocol used by the NSS responder. > >>>>>>>> > >>>>>>>> One way I can think of is to use a new socket like > >>>>>>>> /var/lib/sss/pipes/nss_noview and create a small library for the extdom > >>>>>>>> and compat plugin to use the new socket. With this the plugin have to > >>>>>>>> apply the views on their own if needed. > >>>>>>>> > >>>>>>>> Another way would be a new command for the NSS responder with two > >>>>>>>> arguments, the view name (or empty for unmodified data) and a blob which > >>>>>>>> contains the data for the corresponding request like e.g. getpwnam_r() or > >>>>>>>> getgrgid_r(). Here the plugins have to use some new calls but all view > >>>>>>>> processing can happen in sssd and the plugins can deliver the data > >>>>>>>> directly. > >>>>>>>> > >>>>>>>> A drawback in both cases is that the memcache cannot be used. > >>>>>>>> > >>>>>>>> If someone has suggestions for SSSD or other ways how to deliver user > >>>>>>>> and group data to client with other views than the IPA server I'm all > >>>>>>>> ears. > >>>>>>> Ok this one is hard to deal with in a way that will satisfy every > >>>>>>> possible user. > >>>>>>> > >>>>>>> I think what we need to aim is simplicity and predictability at the > >>>>>>> expense of flexibility. > >>>>>>> > >>>>>>> What I mean is that freeipa servers should be allowed to only stick to > >>>>>>> one view, the default view for external users. > >>>>>> I do not understand what you mean by "one" view? > >>>>> The "one" view is the view exposed via the (default) compat tree. > >>>>> > >>>>>> Server should be able to have "all" views. > >>>>>> "View" is an equivalent of the "zones". > >>>>>> > >>>>>> SSSD has to get raw data from the external domain and give it to IPA. > >>>>>> IPA would have to merge the data coming from SSSD in server mode with > >>>>>> some set of data associated with a subset of clients. > >>>>>> I am not sure how it will be done (compat, cos or some other mechanism) > >>>>>> but this is the requirement. > >>>>> This would require multiple compat trees, one per view, it would be very > >>>>> expensive. > >>>>> > >>>>>> So for clarity let me restate the use cases: > >>>>>> > >>>>>> a) I had my users in a NIS or LDAP with POSIX attributes there. I used > >>>>>> to sync users from AD. I migrate from that to IPA but want to use trust > >>>>>> for my users because AD is authoritative source and I do not want/can > >>>>>> put POSIX into AD. > >>>>>> b) I have several NIS domains that I need to consolidate. For whatever > >>>>>> reasons I can't migrate to the unified POSIX namespace. I want an > >>>>>> equivalent of the Centrify Zones when different clients get different > >>>>>> uid/gid assignments for the same users. > >>>>>> c) I used sync so my POSIX attributes are in IPA but now I want to > >>>>>> switch to trust. > >>>>>> d) I had a third party solution that had posix zoning and I want to > >>>>>> replace it with the similar solution based on IPA. > >>>>>> > >>>>>> Views (plural) are a way to merge data and present it to a subset of > >>>>>> clients. In this context it is not really clear what you mean by "one" > >>>>>> view. > >>>>> In order to see views you'll need a modern SSSD client that knows how to > >>>>> apply them. Ie viewS are applied on the client side. The server shows > >>>>> only one view via LDAP. > >>>>> > >>>>> Simo. > >>>>> > >>>> OK, I agree with multiple views being expensive and merging things on > >>>> the client but how you define which one is the "default" on the server? > >>> We'll have one called "default" ? > >>> > >>> Simo. > >>> > >>> > >> I do not care about the name i care about the content. Imagine that > >> there can be several different views. Which one is the default one? How > >> it is picked? Id there a way to change from one view to another? Also > >> this means that all legacy clients would have just one view because > >> there will be a single compat all of them can be pointed to. May be if > >> we can switch views on different replicas we would be able to create > >> zones such that different replicas are used to serve different groups of > >> legacy clients. > > No we can't switch the default view for external users via LDAP on > > different replicas, as that would cause clients to have conflicting > > data. > > > > If we need different views via LDAP we will have to explicitly enable > > additional compat views. > > > > Simo. > > > > May be we can enhance the compat view to use sub types for posix > attributes that denote a view. > Then use mapping of client IP/Hostname to a view using some kind of > relation object. > DS can already consider IP of the client so may be we can extend it to > use IP to pick the right sub-type value from a MV attribute. Using the IP of a client in general is unreliable, we cannot base a change of behavior on that information. It would be a nightmare to debug. NAT, mobile clients, etc... will all cause any policy based on IP addresses to be unusable in various situations. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri May 30 06:00:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 May 2014 08:00:10 +0200 Subject: [Freeipa-devel] ipa-server-install error In-Reply-To: <538805A9.40304@redhat.com> References: <538805A9.40304@redhat.com> Message-ID: <53881E6A.3040609@redhat.com> On 05/30/2014 06:14 AM, Dmitri Pal wrote: > On 05/29/2014 01:44 AM, James wrote: >> /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: >> Invalid argument" > Looks like and AVC that lead to restart failure of the PKI instance that in > turn led to failure to configure CA. I asked Ade Lee and got this response: On 05/29/2014 04:44 PM, Ade Lee wrote: > The problem is here: > > /usr/bin/runcon: invalid context: > unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" > > We've seen this before. Sometimes pki-selinux fails to load its policy > for some reason. The best thing to do is to force re-install > pki-selinux (and check for any errors in the /var/log/messages file). > > Ade From mkosek at redhat.com Fri May 30 06:17:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 May 2014 08:17:42 +0200 Subject: [Freeipa-devel] [PATCH 0020] ipa recursively adds old backups In-Reply-To: References: Message-ID: <53882286.1030902@redhat.com> On 05/30/2014 01:11 AM, Gabe Alford wrote: > Hello, > > This is a patch for https://fedorahosted.org/freeipa/ticket/4331 > It's a one liner that just adds an exclude to the tar command to ignore the > /var/lib/ipa/backup folder. > > Thanks, > > Gabe Thanks! Patches for backup and restore feature are very welcome. ACK, works fine. Pushed to master: 9f2c4705d7e2fa83be95f005a78f83a399acfa72 Martin From mkosek at redhat.com Fri May 30 06:37:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 May 2014 08:37:12 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <538778F2.6000504@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> Message-ID: <53882718.1040907@redhat.com> On 05/29/2014 08:14 PM, Dmitri Pal wrote: > On 05/29/2014 08:39 AM, Simo Sorce wrote: >> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>> This, I believe, has already been covered, but I'm concerned with the >>>>>>> (over)use of active/inactive in this discussion. >>>>>>> >>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>> confusing since there is already an account enable/disable command. >>>>>>> This >>>>>>> on top of unlock, are there now 3 possible boolean states a user can >>>>>>> be >>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>> deleted/active and staged/active? >>>>>>> >>>>>> Agree, we should only have "ipa user-unstage " and not call >>>>>> this operations with words like active/inactive. >>>>>> >>>>>> User's in the staging area are not inactive, they are *not* users yet in >>>>>> the first place. >>>>>> >>>>>> Simo. >>>>>> >>>>> Ok. Let us consolidate the decisions, I think we are now running in circles. >>>>> Let me start from Petr3's API proposal which was a functionally complete >>>>> proposal and start from there: >>>>> >>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>> ... >>>>>> My proposal would be that the move commands use the verb for the target >>>>>> and an >>>>>> option for the source, and add/mod use an option for the container: >>>>>> >>>>>> 1) adding a new user >>>>>> (to active) ipa user-add tuser ... >>>>>> (to stage) ipa user-add tuser --staged ... >>>>> Ok. >>>>> >>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>> Not needed. >>>>> >>>>>> 2) moving to main >>>>>> (from stage) ipa user-activate tuser (**) >>>>>> (from del) ipa user-activate tuser --deleted >>>>> We need both, alternative is Simo's proposal: >>>>> >>>>> ipa user-unstage >>>>> ipa user-undelete >>>>> >>>>> I personally like unstage and undelete commands, I would go with those. >>>> Sorry for coming late to the party. >>>> I strongly do not like "unstage" >>>> This suggests that the user will be removed from staged but does not indicate >>>> that the full user will be created. >>>> As I suggested elsewhere provision-user or user-provision (or may be even >>>> user-add --from-stage) would be better. >>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation >>> could get messy and would not create the right API. Using a separate call would >>> be cleaner. As we see, choosing the right action term has proven very difficult >>> - everyone has strong opinion on the command name :-) >>> >>> I already saw user-activate and user-unstage to be trashed so I am thinking >>> what we are left with. I am still fan of user-unstage, user-provision is not >>> telling me much more than user-unstage. >>> >>>>>> 3) moving to deleted >>>>>> (from active) ipa user-del tuser >>>>> Ok. >>>>> >>>>>> (from stage) ipa user-del tuser --staged >>>>> IMO staged deleted users should not be moved to deleted container, but simply >>>>> permanently deleted. As Simo noted, staged user are not real users, just >>>>> incomplete users. >>>>> >>>>>> 4) moving to stage >>>>>> (from active) ipa user-stage tuser >>>> >>>> This was suggested for completeness. >>>> I think we are cutting corners but I would not insist here. >>>> >>>>>> (from del) ipa user-stage tuser --deleted >>>>> None of the commands are needed for the basic workflow. >>>> But this is a valid use case. I created a user, deleted it and want to rebuild >>>> it becuase something got corrupted in the original entry. I agree it is not a >>>> primary use case but then we should have a ticket to track this RFE for >>>> future. >>> This was not about cutting corners, this was about what operation makes sense >>> and what we should support. Stage was defined as a tree with incomplete user, >>> thus this proposal - Simo was not very OK with this workflow. >>> >>>>>> 5) modifying >>>>>> (in active) ipa user-mod tuser ... >>>>> Ok. >>>>> >>>>>> (in stage) ipa user-mod tuser --staged ... >>>>> Simo did not like this command, I would personally add it. As long as we have >>>>> "ipa user-add --staged", we should also have an option to delete and modify >>>>> user in staged area. >>>>> >>>>>> (in del) ipa user-mod tuser --deleted ... >>>>> Not needed. >>>>> >>>>> Is this acceptable for everyone? If yes, the next step would be for Thierry >>>>> to update the design page with new proposals. >>>>> >>>>> Martin >>> Let me try to consolidate again the proposals and changes for the workflow&API >>> we have so far: >>> >>> 1) Manipulating staged users >>> - staged users must have UID RDN >>> - UID uniqueness plugin should not be enforcing in staging area >>> - we do not want it in user plugin as it requires different parameters and >>> objectclasses >>> - API: >>> ipa stage-user-add >>> ipa stage-user-mod >>> ipa stage-user-find >>> ipa stage-user-del >>> >>> 2) Activating staged user >>> - activation will not do MODRDN, it will create a new user in active container >>> and then delete the old one (to create right structural objectclass set) >>> - for now, we need to allow operator delete any user in staged and add any user >>> in active tree >>> - API >>> ipa stage-user-activate >>> - other options mentioned in the past were user-unstage and user-activate >>> >>> 3) Manipulating deleted users >>> - deletion and undeletion will do MODRDN and will use the ACI that Thierry >>> implemented >>> - API >>> ipa user-del >>> ipa user-undel OR ipa user-undelete >>> - Dmitri mentioned that he would like to see the move from deleted to staged. I >>> would do it via flag: >>> ipa user-undel --to-stage >>> >>> >>> Does that look better now? Thanks, >> Yes, although I do not see the need for --to-stage honestly. > I agree we can just leave it as a future ticket. I think Simo's thoughts were different - he did not opposed to this part because it is too much work (it shouldn't be), but because he did not want that part of the workflow. Given the simplicity of this part, I see 2 options: 1) Do it and do it together with other API is it just one MODRDN command 2) Decide we do not want to do it, i.e. do not file any RFE > Rest looks OK. It should be fine, just one command could done differently to confine it better as per Honza's idea: ipa stageduser-add --from-deleted username Thierry, you know what to do :-) Martin From sbose at redhat.com Fri May 30 07:04:11 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 30 May 2014 09:04:11 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <1401384664.3590.19.camel@willson.li.ssimo.org> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> Message-ID: <20140530070411.GK30381@localhost.localdomain> On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: > On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: > > On 29.5.2014 13:48, Sumit Bose wrote: > > > == slapi-nis plugin/compat tree == > > > The compat tree offers a simplified LDAP tree with user and group data > > > for legacy clients. No data for this tree is stored on disk but it is > > > always created on the fly. It has to be noted that legacy clients might > > > be one of the major users of the user-views because chances are that > > > they were attached to the legacy systems with legacy ID management which > > > should be replaced by IPA. > > > > > > In contrast to the extdom plugin it is not possible to determine the > > > client based on the DN because connection might be anonymous. The > > > Slapi_PBlock contains the IP address of the client in > > > SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > > > tree requires a reverse-DNS lookup which might be unreliable. If the > > > reverse-DNS lookup was successful the slapi-nos plugin can follow the > > > same steps as the extdom plugin to lookup up and apply the view. > > > > Do we really want to base security decisions on reverse DNS resolution? > > No we do not want to play these games. > > > That > > will be insecure. Attacker could tamper with reverse DNS to change UID/GID > > mapping ... Maybe we can store IP->view mapping in the LDAP database. That > > should be reliable if we assume that only TCP is used for connection to LDAP > > database. > > It is not just about it being insecure, it is about it being wrong. > As soon as you have a bunch of clients behind a NAT this pans goes belly > up. I do not like this one either. I just wanted to list to options I could think of because I think supporting user-views on legacy clients is one of the major use-cases for this feature. bye, Sumit > > > > As a alternative slapi-nis can provide one tree for each view. > > This is the only alternative, if we decide to pursue it. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Fri May 30 07:09:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 30 May 2014 09:09:46 +0200 Subject: [Freeipa-devel] CA certificate renewal, shared store trust settings In-Reply-To: <20140529174427.GC12741@redhat.com> References: <20140529174427.GC12741@redhat.com> Message-ID: <53882EBA.4030007@redhat.com> Hi, On 29.5.2014 19:44, Nalin Dahyabhai wrote: > I'm working on adding to certmonger the ability to read the IPA root > certificate from the server and store it locally, and I'm looking at the > V4 shared certificate store feature [1] with an eye toward also pulling > down and processing those certificates. Before I head down that path, > I've got a few questions about the schema that the page describes for > storing trust information. So, you want to fetch the certificates directly from LDAP? Shouldn't they rather be fetched using IPA API (in ipa-submit) or Dogtag API (in dogtag-ipa-renew-agent-submit)? In the past few months that I worked on the CA certificate renewal feature the shared certificate store design has evolved into something more about certificate trust policy rather than simple storage of CA certificates. My plan is to integrate it with p11-kit in the forthcoming months to provide the policy to IPA clients. SSSD is going to be used as the component between IPA and p11-kit. A PKCS#11 module will be provided for (not only) that. (This is what is going to be about.) I can imagine you might as well talk to the module to fetch the CA certificates. Are there any plans to support PKCS#11 as a storage backend in certmonger? > > Is the ipaKeyTrust attribute meant to be a part of the ipaKeyPolicy > object class? Yes. > > Looking at the ipaKeyTrust attribute, the description suggests that it's > a directoryString that should contain one of 'unknown', 'trusted', or > 'distrusted' as its value. The syntax doesn't guarantee that, and that > ambiguity makes me a little nervous. Any chance of tweaking the schema > to remove that possibility? This does not make me nervous at all. Take a look at other similar attributes in IPA, they all use directory string syntax. I'm open to suggestions, though. > > The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' > and 'distrusted', appears to map pretty directly to the sort of > information that OpenSSL stores in trusted certificates [2], but going > through the man pages for x509(1) and verify(1), I don't see anything > that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's > that value intended to signify, and how would consumers of the > certificates be expected to treat certificates from entries with that > ipaKeyTrust value? Actually it is designed to map to p11-kit-style trust policy (), which is a superset of OpenSSL's. The "unknown" value means the trust is not explicitly given and that if there is other source of trust information for the key/certificate, it should be used. In p11-kit terms, it is for certificates which are neither in the anchors nor the blacklist set. In NSS terms, it's for certificates without any of the C, T, P or p trust flags. > > Are there examples of what the ipaKeyUsage attribute should contain? It's the purpose bit names from the key usage certificate extension () or "none". > > Is there a recommended method for mapping from this representation to > the form that we'd pass to certutil(1)'s '-t' option when storing the > certificates in NSS databases, or is the intent that it be translated > into NSS-specific PKCS#11 attributes set on those certificates? Well, it can be both. But as I said above, I'm not sure if reading from LDAP directly is the best thing to do in this case. > > Thanks, > > Nalin > > [1] http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store > [2] http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#openssl-trusted > (Yes, I will update the design page.) Honza -- Jan Cholasta From sbose at redhat.com Fri May 30 07:20:09 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 30 May 2014 09:20:09 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <538807D9.6080905@redhat.com> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <538807D9.6080905@redhat.com> Message-ID: <20140530072009.GL30381@localhost.localdomain> On Fri, May 30, 2014 at 12:23:53AM -0400, Dmitri Pal wrote: > On 05/29/2014 01:31 PM, Simo Sorce wrote: > >On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: > >>On 29.5.2014 13:48, Sumit Bose wrote: > >>>== slapi-nis plugin/compat tree == > >>>The compat tree offers a simplified LDAP tree with user and group data > >>>for legacy clients. No data for this tree is stored on disk but it is > >>>always created on the fly. It has to be noted that legacy clients might > >>>be one of the major users of the user-views because chances are that > >>>they were attached to the legacy systems with legacy ID management which > >>>should be replaced by IPA. > >>> > >>>In contrast to the extdom plugin it is not possible to determine the > >>>client based on the DN because connection might be anonymous. The > >>>Slapi_PBlock contains the IP address of the client in > >>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > >>>tree requires a reverse-DNS lookup which might be unreliable. If the > >>>reverse-DNS lookup was successful the slapi-nos plugin can follow the > >>>same steps as the extdom plugin to lookup up and apply the view. > >>Do we really want to base security decisions on reverse DNS resolution? > >No we do not want to play these games. > > > >>That > >>will be insecure. Attacker could tamper with reverse DNS to change UID/GID > >>mapping ... Maybe we can store IP->view mapping in the LDAP database. That > >>should be reliable if we assume that only TCP is used for connection to LDAP > >>database. > >It is not just about it being insecure, it is about it being wrong. > >As soon as you have a bunch of clients behind a NAT this pans goes belly > >up. > > > >>>As a alternative slapi-nis can provide one tree for each view. > >This is the only alternative, if we decide to pursue it. > > > >Simo. > > > Can we at least do something like CoS and use the base compat tree and > overwrite just uid/gid on the fly instead of using the whole another view? > That would reduce the size of the additional views significantly and would > save cycles used for keeping each view in sync with underlying DB. In this > case there will be still one view and dynamic overwrite in the search > results. If we do not want to support all configured views what about making it configurable which view are delivered in separate trees by slapi-nis? - I do not know much about the slap-nis internal, but I could image that the memory requirement for a two layer cache (one global for the data from SSSD (default view) and one for each view with the override data) might be an issue. It would be nice if Alexander or Nalin can explain some of the current bottlenecks in slap-nis to see were it will get worse when supporting user-views in multiple trees? Maybe running a separate 389ds instance for the user-views might be an alternative here as well? Alexanders work for the Global Catalog might come handy here because it sets up and configures a separate instance which reads data from the main one. bye, Sumit > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From purpleidea at gmail.com Fri May 30 07:44:36 2014 From: purpleidea at gmail.com (James) Date: Fri, 30 May 2014 03:44:36 -0400 Subject: [Freeipa-devel] ipa-server-install error In-Reply-To: <53881E6A.3040609@redhat.com> References: <538805A9.40304@redhat.com> <53881E6A.3040609@redhat.com> Message-ID: On Fri, May 30, 2014 at 2:00 AM, Martin Kosek wrote: > On 05/30/2014 06:14 AM, Dmitri Pal wrote: >> On 05/29/2014 01:44 AM, James wrote: >>> /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: >>> Invalid argument" >> Looks like and AVC that lead to restart failure of the PKI instance that in >> turn led to failure to configure CA. > > I asked Ade Lee and got this response: > > On 05/29/2014 04:44 PM, Ade Lee wrote: >> The problem is here: >> >> /usr/bin/runcon: invalid context: >> unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" >> >> We've seen this before. Sometimes pki-selinux fails to load its policy >> for some reason. The best thing to do is to force re-install >> pki-selinux (and check for any errors in the /var/log/messages file). >> >> Ade > Thanks for looking into this... I'm able to reproduce this currently 100% of the time. Unfortunately this breaks automated installs. Is it a bug that needs filling somewhere, or is it something wrong with my machines? I'm seeing it with the most recent incarnation of the vagrant-libvirt base images I'm building. It's particularly pernicious because when this occurs (100% of the time), the machine seems to be in a partially installed state. Thanks, James From pviktori at redhat.com Fri May 30 07:50:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 May 2014 09:50:27 +0200 Subject: [Freeipa-devel] Handling of multiple krbPrincipalNames and of krbCanonicalNames In-Reply-To: <1401381051.2449.0.camel@ipa.example.com> References: <20131007195348.GA20708@redhat.com> <1401381051.2449.0.camel@ipa.example.com> Message-ID: <53883843.1090206@redhat.com> On 05/29/2014 06:30 PM, Nathaniel McCallum wrote: > On Mon, 2013-10-07 at 15:53 -0400, Nalin Dahyabhai wrote: >> Comparing master's ipa-kdb's handling of krbPrincipalName and >> krbCanonicalName attributes with that of the upstream kldap driver, >> there are a few differences which I'm thinking are bugs. >> >> * If an entry has multiple krbPrincipalName values, the name which >> was used to look it up is required to match only the last value of the >> attribute that we read, not any of them. >> >> * If an entry has a krbCanonicalName value, and the name which we used >> to look it up doesn't match it, if database aliases are allowed, we >> return an error instead of using it to populate the returned entry. >> >> I'm attaching patches for both of these, though the second still doesn't >> quite match the behavior of kldap.so, in that we don't preserve the >> requested name if it differs from the canonical name only in case. I >> don't know that it matters, but I'm mentioning here just in case. > > 0001: ACK > > 0002: I don't think that matters. If it does, the fix is easy. ACK > > Nathaniel Added link to ticket and pushed to master: 16092c39073e6512e897dc671fd22b2b583ea5b5 -- Petr? From mkosek at redhat.com Fri May 30 07:51:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 May 2014 09:51:58 +0200 Subject: [Freeipa-devel] ipa-server-install error In-Reply-To: References: <538805A9.40304@redhat.com> <53881E6A.3040609@redhat.com> Message-ID: <5388389E.80209@redhat.com> On 05/30/2014 09:44 AM, James wrote: > On Fri, May 30, 2014 at 2:00 AM, Martin Kosek wrote: >> On 05/30/2014 06:14 AM, Dmitri Pal wrote: >>> On 05/29/2014 01:44 AM, James wrote: >>>> /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: >>>> Invalid argument" >>> Looks like and AVC that lead to restart failure of the PKI instance that in >>> turn led to failure to configure CA. >> >> I asked Ade Lee and got this response: >> >> On 05/29/2014 04:44 PM, Ade Lee wrote: >>> The problem is here: >>> >>> /usr/bin/runcon: invalid context: >>> unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" >>> >>> We've seen this before. Sometimes pki-selinux fails to load its policy >>> for some reason. The best thing to do is to force re-install >>> pki-selinux (and check for any errors in the /var/log/messages file). >>> >>> Ade >> > > Thanks for looking into this... I'm able to reproduce this currently > 100% of the time. Unfortunately this breaks automated installs. Is it > a bug that needs filling somewhere, or is it something wrong with my > machines? I'm seeing it with the most recent incarnation of the > vagrant-libvirt base images I'm building. > > It's particularly pernicious because when this occurs (100% of the > time), the machine seems to be in a partially installed state. > > Thanks, > James Good question - CCing PKI developers. Martin From abokovoy at redhat.com Fri May 30 08:24:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 May 2014 11:24:34 +0300 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140530072009.GL30381@localhost.localdomain> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <538807D9.6080905@redhat.com> <20140530072009.GL30381@localhost.localdomain> Message-ID: <20140530082434.GB23849@redhat.com> On Fri, 30 May 2014, Sumit Bose wrote: >On Fri, May 30, 2014 at 12:23:53AM -0400, Dmitri Pal wrote: >> On 05/29/2014 01:31 PM, Simo Sorce wrote: >> >On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >> >>On 29.5.2014 13:48, Sumit Bose wrote: >> >>>== slapi-nis plugin/compat tree == >> >>>The compat tree offers a simplified LDAP tree with user and group data >> >>>for legacy clients. No data for this tree is stored on disk but it is >> >>>always created on the fly. It has to be noted that legacy clients might >> >>>be one of the major users of the user-views because chances are that >> >>>they were attached to the legacy systems with legacy ID management which >> >>>should be replaced by IPA. >> >>> >> >>>In contrast to the extdom plugin it is not possible to determine the >> >>>client based on the DN because connection might be anonymous. The >> >>>Slapi_PBlock contains the IP address of the client in >> >>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >> >>>tree requires a reverse-DNS lookup which might be unreliable. If the >> >>>reverse-DNS lookup was successful the slapi-nos plugin can follow the >> >>>same steps as the extdom plugin to lookup up and apply the view. >> >>Do we really want to base security decisions on reverse DNS resolution? >> >No we do not want to play these games. >> > >> >>That >> >>will be insecure. Attacker could tamper with reverse DNS to change UID/GID >> >>mapping ... Maybe we can store IP->view mapping in the LDAP database. That >> >>should be reliable if we assume that only TCP is used for connection to LDAP >> >>database. >> >It is not just about it being insecure, it is about it being wrong. >> >As soon as you have a bunch of clients behind a NAT this pans goes belly >> >up. >> > >> >>>As a alternative slapi-nis can provide one tree for each view. >> >This is the only alternative, if we decide to pursue it. >> > >> >Simo. >> > >> Can we at least do something like CoS and use the base compat tree and >> overwrite just uid/gid on the fly instead of using the whole another view? >> That would reduce the size of the additional views significantly and would >> save cycles used for keeping each view in sync with underlying DB. In this >> case there will be still one view and dynamic overwrite in the search >> results. > >If we do not want to support all configured views what about making it >configurable which view are delivered in separate trees by slapi-nis? >- >I do not know much about the slap-nis internal, but I could image that >the memory requirement for a two layer cache (one global for the data >from SSSD (default view) and one for each view with the override data) >might be an issue. It would be nice if Alexander or Nalin can explain >some of the current bottlenecks in slap-nis to see were it will get >worse when supporting user-views in multiple trees? Pretty bad. slapi-nis only serves the entries that were not found with the normal search path. This implies there is always cost of a search over the main tree. If a base DN is too generic, slapi-nis will happily return everything what is cached and fits the filter. Now, we cannot rely on a client connection properties to segregate the connections to different cached sub-trees. Reverse DNS is bad, IP address handling is unreliable. The only way to differentiate would be to have different base DN supplied by each client, maybe in the form of multi-valued RDN (cn=compat+view=viewname,$SUFFIX). However, that would add complication to slapi-nis map cache as data is evaluated once and then inserted into the map cache while in this case a different view would mean need to re-evaluate part of the entry or partially modify returned object on the fly. Technically the latter is possible. Suppose on the first hit to slapi-nis for a uid=foo we would insert its entry into the map cache where each uidNumber/gidNumber has view name appended: uidNumber: 12344556 gidNumber: 12344556 uidNumber_legacy_client1: 110000 gidNumber_legacy_client1: 110001 uidNumber_legacy_client2: 210000 gidNumber_legacy_client2: 210001 uidNumber_legacy_client3: 310000 gidNumber_legacy_client3: 310001 And then have a filter for the resulting object fetched from the map cache prior to pushing it out to the client. The main trouble here is that we have to post process the data in map cache and also the fact that we'll have more triggers to invalidate cached objects, including the ones coming from nss requests which officially have no DN in the main tree to get a trigger for them. >Maybe running a separate 389ds instance for the user-views might be an >alternative here as well? Alexanders work for the Global Catalog might >come handy here because it sets up and configures a separate instance >which reads data from the main one. I don't think it makes problem any easier as we really have to solve the issue of addressing client connection differences first. Whether the data is served by a separate instance or not is irrelevant here. -- / Alexander Bokovoy From abokovoy at redhat.com Fri May 30 08:30:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 May 2014 11:30:19 +0300 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <53880469.7040305@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <20140527140141.GA30381@localhost.localdomain> <1401220340.2598.31.camel@willson.li.ssimo.org> <5386A64F.7040206@redhat.com> <1401333646.3590.4.camel@willson.li.ssimo.org> <5387549D.4050705@redhat.com> <1401378117.3590.13.camel@willson.li.ssimo.org> <538761CB.1070701@redhat.com> <1401387213.3590.21.camel@willson.li.ssimo.org> <53880469.7040305@redhat.com> Message-ID: <20140530083019.GC23849@redhat.com> On Fri, 30 May 2014, Dmitri Pal wrote: >On 05/29/2014 02:13 PM, Simo Sorce wrote: >>On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote: >>>On 05/29/2014 11:41 AM, Simo Sorce wrote: >>>>On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote: >>>>>On 05/28/2014 11:20 PM, Simo Sorce wrote: >>>>>>On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote: >>>>>>>On 05/27/2014 03:52 PM, Simo Sorce wrote: >>>>>>>>On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: >>>>>>>>>On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: >>>>>>>>>>Hi, >>>>>>>>>> >>>>>>>>>>I have started to write a design page for 'Migrating existing >>>>>>>>>>environments to Trust' >>>>>>>>>>http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >>>>>>>>>>It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >>>>>>>>>>https://fedorahosted.org/freeipa/ticket/3979 . >>>>>>>>>> >>>>>>>>>while working on a new version of the page with more details on design >>>>>>>>>and implementation I came across the following problem. On the IPA >>>>>>>>>server there should be a way for SSSD to deliver unmodified data (no >>>>>>>>>view applied) or views other than the one for the IPA server to >>>>>>>>>processes which delivers user and group data to other clients. This are >>>>>>>>>mainly the extdom and the compat plugin of dirsrv. >>>>>>>>> >>>>>>>>>The two currently use standard glibc calls like getpwnam_r() to get the >>>>>>>>>needed data from SSSD. While they can read the view objects form the >>>>>>>>>LDAP tree there is no way to read the original data for users from >>>>>>>>>trusted domains because it is only in the cache of SSSD. >>>>>>>>> >>>>>>>>>I'm looking for a way to allow SSSD to deliver the data without changing >>>>>>>>>the protocol used by the NSS responder. >>>>>>>>> >>>>>>>>>One way I can think of is to use a new socket like >>>>>>>>>/var/lib/sss/pipes/nss_noview and create a small library for the extdom >>>>>>>>>and compat plugin to use the new socket. With this the plugin have to >>>>>>>>>apply the views on their own if needed. >>>>>>>>> >>>>>>>>>Another way would be a new command for the NSS responder with two >>>>>>>>>arguments, the view name (or empty for unmodified data) and a blob which >>>>>>>>>contains the data for the corresponding request like e.g. getpwnam_r() or >>>>>>>>>getgrgid_r(). Here the plugins have to use some new calls but all view >>>>>>>>>processing can happen in sssd and the plugins can deliver the data >>>>>>>>>directly. >>>>>>>>> >>>>>>>>>A drawback in both cases is that the memcache cannot be used. >>>>>>>>> >>>>>>>>>If someone has suggestions for SSSD or other ways how to deliver user >>>>>>>>>and group data to client with other views than the IPA server I'm all >>>>>>>>>ears. >>>>>>>>Ok this one is hard to deal with in a way that will satisfy every >>>>>>>>possible user. >>>>>>>> >>>>>>>>I think what we need to aim is simplicity and predictability at the >>>>>>>>expense of flexibility. >>>>>>>> >>>>>>>>What I mean is that freeipa servers should be allowed to only stick to >>>>>>>>one view, the default view for external users. >>>>>>>I do not understand what you mean by "one" view? >>>>>>The "one" view is the view exposed via the (default) compat tree. >>>>>> >>>>>>>Server should be able to have "all" views. >>>>>>>"View" is an equivalent of the "zones". >>>>>>> >>>>>>>SSSD has to get raw data from the external domain and give it to IPA. >>>>>>>IPA would have to merge the data coming from SSSD in server mode with >>>>>>>some set of data associated with a subset of clients. >>>>>>>I am not sure how it will be done (compat, cos or some other mechanism) >>>>>>>but this is the requirement. >>>>>>This would require multiple compat trees, one per view, it would be very >>>>>>expensive. >>>>>> >>>>>>>So for clarity let me restate the use cases: >>>>>>> >>>>>>>a) I had my users in a NIS or LDAP with POSIX attributes there. I used >>>>>>>to sync users from AD. I migrate from that to IPA but want to use trust >>>>>>>for my users because AD is authoritative source and I do not want/can >>>>>>>put POSIX into AD. >>>>>>>b) I have several NIS domains that I need to consolidate. For whatever >>>>>>>reasons I can't migrate to the unified POSIX namespace. I want an >>>>>>>equivalent of the Centrify Zones when different clients get different >>>>>>>uid/gid assignments for the same users. >>>>>>>c) I used sync so my POSIX attributes are in IPA but now I want to >>>>>>>switch to trust. >>>>>>>d) I had a third party solution that had posix zoning and I want to >>>>>>>replace it with the similar solution based on IPA. >>>>>>> >>>>>>>Views (plural) are a way to merge data and present it to a subset of >>>>>>>clients. In this context it is not really clear what you mean by "one" >>>>>>>view. >>>>>>In order to see views you'll need a modern SSSD client that knows how to >>>>>>apply them. Ie viewS are applied on the client side. The server shows >>>>>>only one view via LDAP. >>>>>> >>>>>>Simo. >>>>>> >>>>>OK, I agree with multiple views being expensive and merging things on >>>>>the client but how you define which one is the "default" on the server? >>>>We'll have one called "default" ? >>>> >>>>Simo. >>>> >>>> >>>I do not care about the name i care about the content. Imagine that >>>there can be several different views. Which one is the default one? How >>>it is picked? Id there a way to change from one view to another? Also >>>this means that all legacy clients would have just one view because >>>there will be a single compat all of them can be pointed to. May be if >>>we can switch views on different replicas we would be able to create >>>zones such that different replicas are used to serve different groups of >>>legacy clients. >>No we can't switch the default view for external users via LDAP on >>different replicas, as that would cause clients to have conflicting >>data. >> >>If we need different views via LDAP we will have to explicitly enable >>additional compat views. >> >>Simo. >> > >May be we can enhance the compat view to use sub types for posix >attributes that denote a view. >Then use mapping of client IP/Hostname to a view using some kind of >relation object. >DS can already consider IP of the client so may be we can extend it to >use IP to pick the right sub-type value from a MV attribute. Please leave the hope to base any differentiation on the connection properties. They are unreliable, especially for the mobile and NATed clients. The only thing we can use for legacy clients is to have differentiated base DN. Using multi-valued RDN like cn=compat+view=viewname should give us enough clue. Given that view has to be setup by the admin manually anyway, asking them to amend the client's configuration to use multi-valued RDN seems to be a reasonable compromise. We can also take the view name into account when generating advices by the ipa-advise tool as it could simple pull down whole set of views, place mapping of hostname to view name in the generated script, and then can use hostname on the machine to properly give base DN configuration. -- / Alexander Bokovoy From pviktori at redhat.com Fri May 30 09:02:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 May 2014 11:02:09 +0200 Subject: [Freeipa-devel] [PATCHES] 0562-0563 ix internal error when global policy is not readable In-Reply-To: <53876AD4.6000108@redhat.com> References: <5387543E.3010002@redhat.com> <53876AD4.6000108@redhat.com> Message-ID: <53884911.3010209@redhat.com> On 05/29/2014 07:13 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> When investigating this issue I became very annoyed by the star import >> hiding where names come from, so I did some cleanup first. >> >> >> In krbtpolicy, an ACIError is now raised if: >> - the user doesn't have permission to read any one of the ticket policy >> attributes on the requested entry >> (checked using attribute-level rights) >> - any ticket policy attribute from the default policy is not available >> (either not readable, or not there at all) >> (only checked if these are accessed, i.e. when the user entry doesn't >> override all of the defaults, or when requesting the global policy) >> >> That means if the user is not available at all, you get a NotFound, but >> if global policy is not found it's assumed that it's just unreadable. > > That seems reasonable to me. > > I also noticed a typo, ddoesn't Fixed, thanks. > In the lower-level code, ldap2.py, we have some help > can_[read|write|etc] for managing rights. Would doing something similar > in baseldap be better than embedding the logic into each plugins? > > So instead of this: > > if rights is None: > rights = baseldap.get_effective_rights( > ldap, dn, self.obj.default_attributes) > if 'r' not in rights.get(attrname.lower(), ''): > raise errors.ACIError( > info=_('Ticket policy for %s could not be > read') % > keys[-1]) > > You'd have this: > > if not baseldap.can_read(ldap, dn, attrname): > raise errors.ACIError( > info=_('Ticket policy for %s could not be > read') % > keys[-1]) The second is definitely better. > This may end up fetching the rights multiple times depending on how many > things need to be read, so perhaps passing that in if you have it already. This however means doing the get_effective_rights call anyway to get all the needed attrs, at which point most of the readability benefits are gone. Actually I'd like to add some good attrlevelrights handling right into ipaldap. Let's do this correctly rather than add a quick fix to the helpers just so we can use them. Issue here: https://fedorahosted.org/freeipa/ticket/4362 -- Petr? From pviktori at redhat.com Fri May 30 09:03:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 May 2014 11:03:23 +0200 Subject: [Freeipa-devel] [PATCHES] 0562-0563 Fix internal error when global policy is not readable In-Reply-To: <53884911.3010209@redhat.com> References: <5387543E.3010002@redhat.com> <53876AD4.6000108@redhat.com> <53884911.3010209@redhat.com> Message-ID: <5388495B.3010008@redhat.com> On 05/30/2014 11:02 AM, Petr Viktorin wrote: > On 05/29/2014 07:13 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> When investigating this issue I became very annoyed by the star import >>> hiding where names come from, so I did some cleanup first. >>> >>> >>> In krbtpolicy, an ACIError is now raised if: >>> - the user doesn't have permission to read any one of the ticket policy >>> attributes on the requested entry >>> (checked using attribute-level rights) >>> - any ticket policy attribute from the default policy is not available >>> (either not readable, or not there at all) >>> (only checked if these are accessed, i.e. when the user entry doesn't >>> override all of the defaults, or when requesting the global policy) >>> >>> That means if the user is not available at all, you get a NotFound, but >>> if global policy is not found it's assumed that it's just unreadable. >> >> That seems reasonable to me. >> >> I also noticed a typo, ddoesn't > > Fixed, thanks. > >> In the lower-level code, ldap2.py, we have some help >> can_[read|write|etc] for managing rights. Would doing something similar >> in baseldap be better than embedding the logic into each plugins? >> >> So instead of this: >> >> if rights is None: >> rights = baseldap.get_effective_rights( >> ldap, dn, self.obj.default_attributes) >> if 'r' not in rights.get(attrname.lower(), ''): >> raise errors.ACIError( >> info=_('Ticket policy for %s could not be >> read') % >> keys[-1]) >> >> You'd have this: >> >> if not baseldap.can_read(ldap, dn, attrname): >> raise errors.ACIError( >> info=_('Ticket policy for %s could not be >> read') % >> keys[-1]) > > The second is definitely better. > >> This may end up fetching the rights multiple times depending on how many >> things need to be read, so perhaps passing that in if you have it >> already. > > This however means doing the get_effective_rights call anyway to get all > the needed attrs, at which point most of the readability benefits are gone. > > Actually I'd like to add some good attrlevelrights handling right into > ipaldap. Let's do this correctly rather than add a quick fix to the > helpers just so we can use them. > Issue here: https://fedorahosted.org/freeipa/ticket/4362 Once more, with patches -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0562.2-krbtpolicy-plugin-Code-cleanup.patch Type: text/x-patch Size: 3203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0563.2-krbtpolicy-plugin-Fix-internal-error-when-global-pol.patch Type: text/x-patch Size: 3216 bytes Desc: not available URL: From jpazdziora at redhat.com Fri May 30 09:18:54 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 30 May 2014 11:18:54 +0200 Subject: [Freeipa-devel] ipa-server-install error In-Reply-To: <53881E6A.3040609@redhat.com> References: <538805A9.40304@redhat.com> <53881E6A.3040609@redhat.com> Message-ID: <20140530091854.GX1482@redhat.com> On Fri, May 30, 2014 at 08:00:10AM +0200, Martin Kosek wrote: > On 05/30/2014 06:14 AM, Dmitri Pal wrote: > > On 05/29/2014 01:44 AM, James wrote: > >> /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: > >> Invalid argument" > > Looks like and AVC that lead to restart failure of the PKI instance that in > > turn led to failure to configure CA. > > I asked Ade Lee and got this response: > > On 05/29/2014 04:44 PM, Ade Lee wrote: > > The problem is here: > > > > /usr/bin/runcon: invalid context: > > unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument" > > > > We've seen this before. Sometimes pki-selinux fails to load its policy > > for some reason. The best thing to do is to force re-install Did you try to use %posttrans instead of %post? https://bugzilla.redhat.com/show_bug.cgi?id=505066 -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Fri May 30 12:08:59 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 May 2014 14:08:59 +0200 Subject: [Freeipa-devel] [PATCH] 0057 Fix indentation Message-ID: <1401451739.2306.1.camel@unused-4-145.brq.redhat.com> Patch fixes indentation in one function in ipalib/util.py -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0057-Fix-indentation.patch Type: text/x-patch Size: 2911 bytes Desc: not available URL: From mbasti at redhat.com Fri May 30 12:15:06 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 May 2014 14:15:06 +0200 Subject: [Freeipa-devel] [PATCH] 0058 Test DNS: dnsrecord-* zone.test. zone.test. should work Message-ID: <1401452106.2306.5.camel@unused-4-145.brq.redhat.com> Test only, issue was fixed in https://fedorahosted.org/freeipa/ticket/3169 Required patches: mbasti 0029-0032, 0034-0040, 0047, 0041-0042, 0045-0046 Patch attached. Ticket: https://fedorahosted.org/freeipa/ticket/4232 -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0058-Test-DNS-dnsrecord-zone.test.-zone.test.-should-work.patch Type: text/x-patch Size: 2391 bytes Desc: not available URL: From pviktori at redhat.com Fri May 30 13:00:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 May 2014 15:00:59 +0200 Subject: [Freeipa-devel] [PATCH] 0564 Add read permissions for automember tasks Message-ID: <5388810B.3010103@redhat.com> I've noticed tests failing because the admin has no access to automember tasks. This is because automember task admins don't have read access to the tasks, and when the code doesn't find the task it assumes the task is already done. This adds the read permission both to the admins group, and to those with the 'Automember Task Administrator' privilege. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0564-Add-read-permissions-for-automember-tasks.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: From dpal at redhat.com Fri May 30 13:13:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 09:13:18 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140530070411.GK30381@localhost.localdomain> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> Message-ID: <538883EE.3090207@redhat.com> On 05/30/2014 03:04 AM, Sumit Bose wrote: > On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: >> On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >>> On 29.5.2014 13:48, Sumit Bose wrote: >>>> == slapi-nis plugin/compat tree == >>>> The compat tree offers a simplified LDAP tree with user and group data >>>> for legacy clients. No data for this tree is stored on disk but it is >>>> always created on the fly. It has to be noted that legacy clients might >>>> be one of the major users of the user-views because chances are that >>>> they were attached to the legacy systems with legacy ID management which >>>> should be replaced by IPA. >>>> >>>> In contrast to the extdom plugin it is not possible to determine the >>>> client based on the DN because connection might be anonymous. The >>>> Slapi_PBlock contains the IP address of the client in >>>> SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >>>> tree requires a reverse-DNS lookup which might be unreliable. If the >>>> reverse-DNS lookup was successful the slapi-nos plugin can follow the >>>> same steps as the extdom plugin to lookup up and apply the view. >>> Do we really want to base security decisions on reverse DNS resolution? >> No we do not want to play these games. >> >>> That >>> will be insecure. Attacker could tamper with reverse DNS to change UID/GID >>> mapping ... Maybe we can store IP->view mapping in the LDAP database. That >>> should be reliable if we assume that only TCP is used for connection to LDAP >>> database. >> It is not just about it being insecure, it is about it being wrong. >> As soon as you have a bunch of clients behind a NAT this pans goes belly >> up. > I do not like this one either. I just wanted to list to options I could > think of because I think supporting user-views on legacy clients is one > of the major use-cases for this feature. > > bye, > Sumit > >>>> As a alternative slapi-nis can provide one tree for each view. >> This is the only alternative, if we decide to pursue it. >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please correct me as I might be confused. We have the compat tree now for legacy clients. It is also used by latest SSSD clients to do special lookups, right? The data in this tree comes from the SSSD on the server running in server mode. I wonder if we can say: here are replicas A, B, C that have vanilla "default view", here are replicas K, L, M where the data is overwritten with a special view (i.e. UID/GID fro ma special area) and then we have replicas X,Y,Z that have a different overlay view. It will be assumed that replicas A,B,C, serve clients in one "zone", new and legacy, while K, L, M serve another zone and X, Y, Z serve the other one. Would that work? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri May 30 13:20:18 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 09:20:18 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <53882718.1040907@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> Message-ID: <53888592.9000204@redhat.com> On 05/30/2014 02:37 AM, Martin Kosek wrote: > On 05/29/2014 08:14 PM, Dmitri Pal wrote: >> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>> This, I believe, has already been covered, but I'm concerned with the >>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>> >>>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>>> confusing since there is already an account enable/disable command. >>>>>>>> This >>>>>>>> on top of unlock, are there now 3 possible boolean states a user can >>>>>>>> be >>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>> deleted/active and staged/active? >>>>>>>> >>>>>>> Agree, we should only have "ipa user-unstage " and not call >>>>>>> this operations with words like active/inactive. >>>>>>> >>>>>>> User's in the staging area are not inactive, they are *not* users yet in >>>>>>> the first place. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> Ok. Let us consolidate the decisions, I think we are now running in circles. >>>>>> Let me start from Petr3's API proposal which was a functionally complete >>>>>> proposal and start from there: >>>>>> >>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>> ... >>>>>>> My proposal would be that the move commands use the verb for the target >>>>>>> and an >>>>>>> option for the source, and add/mod use an option for the container: >>>>>>> >>>>>>> 1) adding a new user >>>>>>> (to active) ipa user-add tuser ... >>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>> Ok. >>>>>> >>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>> Not needed. >>>>>> >>>>>>> 2) moving to main >>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>> (from del) ipa user-activate tuser --deleted >>>>>> We need both, alternative is Simo's proposal: >>>>>> >>>>>> ipa user-unstage >>>>>> ipa user-undelete >>>>>> >>>>>> I personally like unstage and undelete commands, I would go with those. >>>>> Sorry for coming late to the party. >>>>> I strongly do not like "unstage" >>>>> This suggests that the user will be removed from staged but does not indicate >>>>> that the full user will be created. >>>>> As I suggested elsewhere provision-user or user-provision (or may be even >>>>> user-add --from-stage) would be better. >>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation >>>> could get messy and would not create the right API. Using a separate call would >>>> be cleaner. As we see, choosing the right action term has proven very difficult >>>> - everyone has strong opinion on the command name :-) >>>> >>>> I already saw user-activate and user-unstage to be trashed so I am thinking >>>> what we are left with. I am still fan of user-unstage, user-provision is not >>>> telling me much more than user-unstage. >>>> >>>>>>> 3) moving to deleted >>>>>>> (from active) ipa user-del tuser >>>>>> Ok. >>>>>> >>>>>>> (from stage) ipa user-del tuser --staged >>>>>> IMO staged deleted users should not be moved to deleted container, but simply >>>>>> permanently deleted. As Simo noted, staged user are not real users, just >>>>>> incomplete users. >>>>>> >>>>>>> 4) moving to stage >>>>>>> (from active) ipa user-stage tuser >>>>> This was suggested for completeness. >>>>> I think we are cutting corners but I would not insist here. >>>>> >>>>>>> (from del) ipa user-stage tuser --deleted >>>>>> None of the commands are needed for the basic workflow. >>>>> But this is a valid use case. I created a user, deleted it and want to rebuild >>>>> it becuase something got corrupted in the original entry. I agree it is not a >>>>> primary use case but then we should have a ticket to track this RFE for >>>>> future. >>>> This was not about cutting corners, this was about what operation makes sense >>>> and what we should support. Stage was defined as a tree with incomplete user, >>>> thus this proposal - Simo was not very OK with this workflow. >>>> >>>>>>> 5) modifying >>>>>>> (in active) ipa user-mod tuser ... >>>>>> Ok. >>>>>> >>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>> Simo did not like this command, I would personally add it. As long as we have >>>>>> "ipa user-add --staged", we should also have an option to delete and modify >>>>>> user in staged area. >>>>>> >>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>> Not needed. >>>>>> >>>>>> Is this acceptable for everyone? If yes, the next step would be for Thierry >>>>>> to update the design page with new proposals. >>>>>> >>>>>> Martin >>>> Let me try to consolidate again the proposals and changes for the workflow&API >>>> we have so far: >>>> >>>> 1) Manipulating staged users >>>> - staged users must have UID RDN >>>> - UID uniqueness plugin should not be enforcing in staging area >>>> - we do not want it in user plugin as it requires different parameters and >>>> objectclasses >>>> - API: >>>> ipa stage-user-add >>>> ipa stage-user-mod >>>> ipa stage-user-find >>>> ipa stage-user-del >>>> >>>> 2) Activating staged user >>>> - activation will not do MODRDN, it will create a new user in active container >>>> and then delete the old one (to create right structural objectclass set) >>>> - for now, we need to allow operator delete any user in staged and add any user >>>> in active tree >>>> - API >>>> ipa stage-user-activate >>>> - other options mentioned in the past were user-unstage and user-activate >>>> >>>> 3) Manipulating deleted users >>>> - deletion and undeletion will do MODRDN and will use the ACI that Thierry >>>> implemented >>>> - API >>>> ipa user-del >>>> ipa user-undel OR ipa user-undelete >>>> - Dmitri mentioned that he would like to see the move from deleted to staged. I >>>> would do it via flag: >>>> ipa user-undel --to-stage >>>> >>>> >>>> Does that look better now? Thanks, >>> Yes, although I do not see the need for --to-stage honestly. >> I agree we can just leave it as a future ticket. > I think Simo's thoughts were different - he did not opposed to this part > because it is too much work (it shouldn't be), but because he did not want that > part of the workflow. Given the simplicity of this part, I see 2 options: > 1) Do it and do it together with other API is it just one MODRDN command > 2) Decide we do not want to do it, i.e. do not file any RFE > >> Rest looks OK. > It should be fine, just one command could done differently to confine it better > as per Honza's idea: > > ipa stageduser-add --from-deleted username ack > > Thierry, you know what to do :-) > > Martin -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From pviktori at redhat.com Fri May 30 13:24:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 May 2014 15:24:00 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <53882718.1040907@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> Message-ID: <53888670.4090605@redhat.com> On 05/30/2014 08:37 AM, Martin Kosek wrote: > On 05/29/2014 08:14 PM, Dmitri Pal wrote: >> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>> This, I believe, has already been covered, but I'm concerned with the >>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>> >>>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>>> confusing since there is already an account enable/disable command. >>>>>>>> This >>>>>>>> on top of unlock, are there now 3 possible boolean states a user can >>>>>>>> be >>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>> deleted/active and staged/active? >>>>>>>> >>>>>>> Agree, we should only have "ipa user-unstage " and not call >>>>>>> this operations with words like active/inactive. >>>>>>> >>>>>>> User's in the staging area are not inactive, they are *not* users yet in >>>>>>> the first place. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> Ok. Let us consolidate the decisions, I think we are now running in circles. >>>>>> Let me start from Petr3's API proposal which was a functionally complete >>>>>> proposal and start from there: >>>>>> >>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>> ... >>>>>>> My proposal would be that the move commands use the verb for the target >>>>>>> and an >>>>>>> option for the source, and add/mod use an option for the container: >>>>>>> >>>>>>> 1) adding a new user >>>>>>> (to active) ipa user-add tuser ... >>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>> Ok. >>>>>> >>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>> Not needed. >>>>>> >>>>>>> 2) moving to main >>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>> (from del) ipa user-activate tuser --deleted >>>>>> We need both, alternative is Simo's proposal: >>>>>> >>>>>> ipa user-unstage >>>>>> ipa user-undelete >>>>>> >>>>>> I personally like unstage and undelete commands, I would go with those. >>>>> Sorry for coming late to the party. >>>>> I strongly do not like "unstage" >>>>> This suggests that the user will be removed from staged but does not indicate >>>>> that the full user will be created. >>>>> As I suggested elsewhere provision-user or user-provision (or may be even >>>>> user-add --from-stage) would be better. >>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation >>>> could get messy and would not create the right API. Using a separate call would >>>> be cleaner. As we see, choosing the right action term has proven very difficult >>>> - everyone has strong opinion on the command name :-) >>>> >>>> I already saw user-activate and user-unstage to be trashed so I am thinking >>>> what we are left with. I am still fan of user-unstage, user-provision is not >>>> telling me much more than user-unstage. >>>> >>>>>>> 3) moving to deleted >>>>>>> (from active) ipa user-del tuser >>>>>> Ok. >>>>>> >>>>>>> (from stage) ipa user-del tuser --staged >>>>>> IMO staged deleted users should not be moved to deleted container, but simply >>>>>> permanently deleted. As Simo noted, staged user are not real users, just >>>>>> incomplete users. >>>>>> >>>>>>> 4) moving to stage >>>>>>> (from active) ipa user-stage tuser >>>>> >>>>> This was suggested for completeness. >>>>> I think we are cutting corners but I would not insist here. >>>>> >>>>>>> (from del) ipa user-stage tuser --deleted >>>>>> None of the commands are needed for the basic workflow. >>>>> But this is a valid use case. I created a user, deleted it and want to rebuild >>>>> it becuase something got corrupted in the original entry. I agree it is not a >>>>> primary use case but then we should have a ticket to track this RFE for >>>>> future. >>>> This was not about cutting corners, this was about what operation makes sense >>>> and what we should support. Stage was defined as a tree with incomplete user, >>>> thus this proposal - Simo was not very OK with this workflow. >>>> >>>>>>> 5) modifying >>>>>>> (in active) ipa user-mod tuser ... >>>>>> Ok. >>>>>> >>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>> Simo did not like this command, I would personally add it. As long as we have >>>>>> "ipa user-add --staged", we should also have an option to delete and modify >>>>>> user in staged area. >>>>>> >>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>> Not needed. >>>>>> >>>>>> Is this acceptable for everyone? If yes, the next step would be for Thierry >>>>>> to update the design page with new proposals. >>>>>> >>>>>> Martin >>>> Let me try to consolidate again the proposals and changes for the workflow&API >>>> we have so far: >>>> >>>> 1) Manipulating staged users >>>> - staged users must have UID RDN >>>> - UID uniqueness plugin should not be enforcing in staging area >>>> - we do not want it in user plugin as it requires different parameters and >>>> objectclasses >>>> - API: >>>> ipa stage-user-add >>>> ipa stage-user-mod >>>> ipa stage-user-find >>>> ipa stage-user-del >>>> >>>> 2) Activating staged user >>>> - activation will not do MODRDN, it will create a new user in active container >>>> and then delete the old one (to create right structural objectclass set) >>>> - for now, we need to allow operator delete any user in staged and add any user >>>> in active tree >>>> - API >>>> ipa stage-user-activate >>>> - other options mentioned in the past were user-unstage and user-activate >>>> >>>> 3) Manipulating deleted users >>>> - deletion and undeletion will do MODRDN and will use the ACI that Thierry >>>> implemented >>>> - API >>>> ipa user-del >>>> ipa user-undel OR ipa user-undelete >>>> - Dmitri mentioned that he would like to see the move from deleted to staged. I >>>> would do it via flag: >>>> ipa user-undel --to-stage >>>> >>>> >>>> Does that look better now? Thanks, >>> Yes, although I do not see the need for --to-stage honestly. >> I agree we can just leave it as a future ticket. > > I think Simo's thoughts were different - he did not opposed to this part > because it is too much work (it shouldn't be), but because he did not want that > part of the workflow. Given the simplicity of this part, I see 2 options: > 1) Do it and do it together with other API is it just one MODRDN command > 2) Decide we do not want to do it, i.e. do not file any RFE > >> Rest looks OK. > > It should be fine, just one command could done differently to confine it better > as per Honza's idea: > > ipa stageduser-add --from-deleted username Do we want that to take all of stageduser-add's options? Should we use somrthing like stageduser-undel instead? > > Thierry, you know what to do :-) > > Martin > -- Petr? From dpal at redhat.com Fri May 30 13:28:46 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 May 2014 09:28:46 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <53888670.4090605@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> <53888670.4090605@redhat.com> Message-ID: <5388878E.6000908@redhat.com> On 05/30/2014 09:24 AM, Petr Viktorin wrote: > On 05/30/2014 08:37 AM, Martin Kosek wrote: >> On 05/29/2014 08:14 PM, Dmitri Pal wrote: >>> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>>> This, I believe, has already been covered, but I'm concerned >>>>>>>>> with the >>>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>>> >>>>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>>>> confusing since there is already an account enable/disable >>>>>>>>> command. >>>>>>>>> This >>>>>>>>> on top of unlock, are there now 3 possible boolean states a >>>>>>>>> user can >>>>>>>>> be >>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>>> deleted/active and staged/active? >>>>>>>>> >>>>>>>> Agree, we should only have "ipa user-unstage " and >>>>>>>> not call >>>>>>>> this operations with words like active/inactive. >>>>>>>> >>>>>>>> User's in the staging area are not inactive, they are *not* >>>>>>>> users yet in >>>>>>>> the first place. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> Ok. Let us consolidate the decisions, I think we are now running >>>>>>> in circles. >>>>>>> Let me start from Petr3's API proposal which was a functionally >>>>>>> complete >>>>>>> proposal and start from there: >>>>>>> >>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>>> ... >>>>>>>> My proposal would be that the move commands use the verb for >>>>>>>> the target >>>>>>>> and an >>>>>>>> option for the source, and add/mod use an option for the >>>>>>>> container: >>>>>>>> >>>>>>>> 1) adding a new user >>>>>>>> (to active) ipa user-add tuser ... >>>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>>> Ok. >>>>>>> >>>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>>> Not needed. >>>>>>> >>>>>>>> 2) moving to main >>>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>>> (from del) ipa user-activate tuser --deleted >>>>>>> We need both, alternative is Simo's proposal: >>>>>>> >>>>>>> ipa user-unstage >>>>>>> ipa user-undelete >>>>>>> >>>>>>> I personally like unstage and undelete commands, I would go with >>>>>>> those. >>>>>> Sorry for coming late to the party. >>>>>> I strongly do not like "unstage" >>>>>> This suggests that the user will be removed from staged but does >>>>>> not indicate >>>>>> that the full user will be created. >>>>>> As I suggested elsewhere provision-user or user-provision (or may >>>>>> be even >>>>>> user-add --from-stage) would be better. >>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating >>>>> unstaging operation >>>>> could get messy and would not create the right API. Using a >>>>> separate call would >>>>> be cleaner. As we see, choosing the right action term has proven >>>>> very difficult >>>>> - everyone has strong opinion on the command name :-) >>>>> >>>>> I already saw user-activate and user-unstage to be trashed so I am >>>>> thinking >>>>> what we are left with. I am still fan of user-unstage, >>>>> user-provision is not >>>>> telling me much more than user-unstage. >>>>> >>>>>>>> 3) moving to deleted >>>>>>>> (from active) ipa user-del tuser >>>>>>> Ok. >>>>>>> >>>>>>>> (from stage) ipa user-del tuser --staged >>>>>>> IMO staged deleted users should not be moved to deleted >>>>>>> container, but simply >>>>>>> permanently deleted. As Simo noted, staged user are not real >>>>>>> users, just >>>>>>> incomplete users. >>>>>>> >>>>>>>> 4) moving to stage >>>>>>>> (from active) ipa user-stage tuser >>>>>> >>>>>> This was suggested for completeness. >>>>>> I think we are cutting corners but I would not insist here. >>>>>> >>>>>>>> (from del) ipa user-stage tuser --deleted >>>>>>> None of the commands are needed for the basic workflow. >>>>>> But this is a valid use case. I created a user, deleted it and >>>>>> want to rebuild >>>>>> it becuase something got corrupted in the original entry. I agree >>>>>> it is not a >>>>>> primary use case but then we should have a ticket to track this >>>>>> RFE for >>>>>> future. >>>>> This was not about cutting corners, this was about what operation >>>>> makes sense >>>>> and what we should support. Stage was defined as a tree with >>>>> incomplete user, >>>>> thus this proposal - Simo was not very OK with this workflow. >>>>> >>>>>>>> 5) modifying >>>>>>>> (in active) ipa user-mod tuser ... >>>>>>> Ok. >>>>>>> >>>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>>> Simo did not like this command, I would personally add it. As >>>>>>> long as we have >>>>>>> "ipa user-add --staged", we should also have an option to delete >>>>>>> and modify >>>>>>> user in staged area. >>>>>>> >>>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>>> Not needed. >>>>>>> >>>>>>> Is this acceptable for everyone? If yes, the next step would be >>>>>>> for Thierry >>>>>>> to update the design page with new proposals. >>>>>>> >>>>>>> Martin >>>>> Let me try to consolidate again the proposals and changes for the >>>>> workflow&API >>>>> we have so far: >>>>> >>>>> 1) Manipulating staged users >>>>> - staged users must have UID RDN >>>>> - UID uniqueness plugin should not be enforcing in staging area >>>>> - we do not want it in user plugin as it requires different >>>>> parameters and >>>>> objectclasses >>>>> - API: >>>>> ipa stage-user-add >>>>> ipa stage-user-mod >>>>> ipa stage-user-find >>>>> ipa stage-user-del >>>>> >>>>> 2) Activating staged user >>>>> - activation will not do MODRDN, it will create a new user in >>>>> active container >>>>> and then delete the old one (to create right structural >>>>> objectclass set) >>>>> - for now, we need to allow operator delete any user in staged and >>>>> add any user >>>>> in active tree >>>>> - API >>>>> ipa stage-user-activate >>>>> - other options mentioned in the past were user-unstage and >>>>> user-activate >>>>> >>>>> 3) Manipulating deleted users >>>>> - deletion and undeletion will do MODRDN and will use the ACI that >>>>> Thierry >>>>> implemented >>>>> - API >>>>> ipa user-del >>>>> ipa user-undel OR ipa user-undelete >>>>> - Dmitri mentioned that he would like to see the move from deleted >>>>> to staged. I >>>>> would do it via flag: >>>>> ipa user-undel --to-stage >>>>> >>>>> >>>>> Does that look better now? Thanks, >>>> Yes, although I do not see the need for --to-stage honestly. >>> I agree we can just leave it as a future ticket. >> >> I think Simo's thoughts were different - he did not opposed to this part >> because it is too much work (it shouldn't be), but because he did not >> want that >> part of the workflow. Given the simplicity of this part, I see 2 >> options: >> 1) Do it and do it together with other API is it just one MODRDN command >> 2) Decide we do not want to do it, i.e. do not file any RFE >> >>> Rest looks OK. >> >> It should be fine, just one command could done differently to confine >> it better >> as per Honza's idea: >> >> ipa stageduser-add --from-deleted username > > Do we want that to take all of stageduser-add's options? > Should we use somrthing like stageduser-undel instead? either way works for me. > >> >> Thierry, you know what to do :-) >> >> Martin >> > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jcholast at redhat.com Fri May 30 13:32:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 30 May 2014 15:32:09 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <53888670.4090605@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> <53888670.4090605@redhat.com> Message-ID: <53888859.2060202@redhat.com> On 30.5.2014 15:24, Petr Viktorin wrote: > On 05/30/2014 08:37 AM, Martin Kosek wrote: >> On 05/29/2014 08:14 PM, Dmitri Pal wrote: >>> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>>> This, I believe, has already been covered, but I'm concerned >>>>>>>>> with the >>>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>>> >>>>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>>>> confusing since there is already an account enable/disable >>>>>>>>> command. >>>>>>>>> This >>>>>>>>> on top of unlock, are there now 3 possible boolean states a >>>>>>>>> user can >>>>>>>>> be >>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>>> deleted/active and staged/active? >>>>>>>>> >>>>>>>> Agree, we should only have "ipa user-unstage " and not >>>>>>>> call >>>>>>>> this operations with words like active/inactive. >>>>>>>> >>>>>>>> User's in the staging area are not inactive, they are *not* >>>>>>>> users yet in >>>>>>>> the first place. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> Ok. Let us consolidate the decisions, I think we are now running >>>>>>> in circles. >>>>>>> Let me start from Petr3's API proposal which was a functionally >>>>>>> complete >>>>>>> proposal and start from there: >>>>>>> >>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>>> ... >>>>>>>> My proposal would be that the move commands use the verb for the >>>>>>>> target >>>>>>>> and an >>>>>>>> option for the source, and add/mod use an option for the container: >>>>>>>> >>>>>>>> 1) adding a new user >>>>>>>> (to active) ipa user-add tuser ... >>>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>>> Ok. >>>>>>> >>>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>>> Not needed. >>>>>>> >>>>>>>> 2) moving to main >>>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>>> (from del) ipa user-activate tuser --deleted >>>>>>> We need both, alternative is Simo's proposal: >>>>>>> >>>>>>> ipa user-unstage >>>>>>> ipa user-undelete >>>>>>> >>>>>>> I personally like unstage and undelete commands, I would go with >>>>>>> those. >>>>>> Sorry for coming late to the party. >>>>>> I strongly do not like "unstage" >>>>>> This suggests that the user will be removed from staged but does >>>>>> not indicate >>>>>> that the full user will be created. >>>>>> As I suggested elsewhere provision-user or user-provision (or may >>>>>> be even >>>>>> user-add --from-stage) would be better. >>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating >>>>> unstaging operation >>>>> could get messy and would not create the right API. Using a >>>>> separate call would >>>>> be cleaner. As we see, choosing the right action term has proven >>>>> very difficult >>>>> - everyone has strong opinion on the command name :-) >>>>> >>>>> I already saw user-activate and user-unstage to be trashed so I am >>>>> thinking >>>>> what we are left with. I am still fan of user-unstage, >>>>> user-provision is not >>>>> telling me much more than user-unstage. >>>>> >>>>>>>> 3) moving to deleted >>>>>>>> (from active) ipa user-del tuser >>>>>>> Ok. >>>>>>> >>>>>>>> (from stage) ipa user-del tuser --staged >>>>>>> IMO staged deleted users should not be moved to deleted >>>>>>> container, but simply >>>>>>> permanently deleted. As Simo noted, staged user are not real >>>>>>> users, just >>>>>>> incomplete users. >>>>>>> >>>>>>>> 4) moving to stage >>>>>>>> (from active) ipa user-stage tuser >>>>>> >>>>>> This was suggested for completeness. >>>>>> I think we are cutting corners but I would not insist here. >>>>>> >>>>>>>> (from del) ipa user-stage tuser --deleted >>>>>>> None of the commands are needed for the basic workflow. >>>>>> But this is a valid use case. I created a user, deleted it and >>>>>> want to rebuild >>>>>> it becuase something got corrupted in the original entry. I agree >>>>>> it is not a >>>>>> primary use case but then we should have a ticket to track this >>>>>> RFE for >>>>>> future. >>>>> This was not about cutting corners, this was about what operation >>>>> makes sense >>>>> and what we should support. Stage was defined as a tree with >>>>> incomplete user, >>>>> thus this proposal - Simo was not very OK with this workflow. >>>>> >>>>>>>> 5) modifying >>>>>>>> (in active) ipa user-mod tuser ... >>>>>>> Ok. >>>>>>> >>>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>>> Simo did not like this command, I would personally add it. As >>>>>>> long as we have >>>>>>> "ipa user-add --staged", we should also have an option to delete >>>>>>> and modify >>>>>>> user in staged area. >>>>>>> >>>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>>> Not needed. >>>>>>> >>>>>>> Is this acceptable for everyone? If yes, the next step would be >>>>>>> for Thierry >>>>>>> to update the design page with new proposals. >>>>>>> >>>>>>> Martin >>>>> Let me try to consolidate again the proposals and changes for the >>>>> workflow&API >>>>> we have so far: >>>>> >>>>> 1) Manipulating staged users >>>>> - staged users must have UID RDN >>>>> - UID uniqueness plugin should not be enforcing in staging area >>>>> - we do not want it in user plugin as it requires different >>>>> parameters and >>>>> objectclasses >>>>> - API: >>>>> ipa stage-user-add >>>>> ipa stage-user-mod >>>>> ipa stage-user-find >>>>> ipa stage-user-del >>>>> >>>>> 2) Activating staged user >>>>> - activation will not do MODRDN, it will create a new user in >>>>> active container >>>>> and then delete the old one (to create right structural objectclass >>>>> set) >>>>> - for now, we need to allow operator delete any user in staged and >>>>> add any user >>>>> in active tree >>>>> - API >>>>> ipa stage-user-activate >>>>> - other options mentioned in the past were user-unstage and >>>>> user-activate >>>>> >>>>> 3) Manipulating deleted users >>>>> - deletion and undeletion will do MODRDN and will use the ACI that >>>>> Thierry >>>>> implemented >>>>> - API >>>>> ipa user-del >>>>> ipa user-undel OR ipa user-undelete >>>>> - Dmitri mentioned that he would like to see the move from deleted >>>>> to staged. I >>>>> would do it via flag: >>>>> ipa user-undel --to-stage >>>>> >>>>> >>>>> Does that look better now? Thanks, >>>> Yes, although I do not see the need for --to-stage honestly. >>> I agree we can just leave it as a future ticket. >> >> I think Simo's thoughts were different - he did not opposed to this part >> because it is too much work (it shouldn't be), but because he did not >> want that >> part of the workflow. Given the simplicity of this part, I see 2 options: >> 1) Do it and do it together with other API is it just one MODRDN command >> 2) Decide we do not want to do it, i.e. do not file any RFE >> >>> Rest looks OK. >> >> It should be fine, just one command could done differently to confine >> it better >> as per Honza's idea: >> >> ipa stageduser-add --from-deleted username > > Do we want that to take all of stageduser-add's options? > Should we use somrthing like stageduser-undel instead? stageduser-undel suggests it's opposite of stageduser-del, which it is not. An alternative would be something like stageduser-add-from-deleted, but that's really long, hence my proposal to use stageduser-add. > >> >> Thierry, you know what to do :-) >> >> Martin >> > > -- Jan Cholasta From rcritten at redhat.com Fri May 30 13:33:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 May 2014 09:33:30 -0400 Subject: [Freeipa-devel] [PATCHES] 0562-0563 Fix internal error when global policy is not readable In-Reply-To: <5388495B.3010008@redhat.com> References: <5387543E.3010002@redhat.com> <53876AD4.6000108@redhat.com> <53884911.3010209@redhat.com> <5388495B.3010008@redhat.com> Message-ID: <538888AA.60709@redhat.com> Petr Viktorin wrote: > On 05/30/2014 11:02 AM, Petr Viktorin wrote: >> On 05/29/2014 07:13 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> When investigating this issue I became very annoyed by the star import >>>> hiding where names come from, so I did some cleanup first. >>>> >>>> >>>> In krbtpolicy, an ACIError is now raised if: >>>> - the user doesn't have permission to read any one of the ticket policy >>>> attributes on the requested entry >>>> (checked using attribute-level rights) >>>> - any ticket policy attribute from the default policy is not available >>>> (either not readable, or not there at all) >>>> (only checked if these are accessed, i.e. when the user entry >>>> doesn't >>>> override all of the defaults, or when requesting the global policy) >>>> >>>> That means if the user is not available at all, you get a NotFound, but >>>> if global policy is not found it's assumed that it's just unreadable. >>> >>> That seems reasonable to me. >>> >>> I also noticed a typo, ddoesn't >> >> Fixed, thanks. >> >>> In the lower-level code, ldap2.py, we have some help >>> can_[read|write|etc] for managing rights. Would doing something similar >>> in baseldap be better than embedding the logic into each plugins? >>> >>> So instead of this: >>> >>> if rights is None: >>> rights = baseldap.get_effective_rights( >>> ldap, dn, self.obj.default_attributes) >>> if 'r' not in rights.get(attrname.lower(), ''): >>> raise errors.ACIError( >>> info=_('Ticket policy for %s could not be >>> read') % >>> keys[-1]) >>> >>> You'd have this: >>> >>> if not baseldap.can_read(ldap, dn, attrname): >>> raise errors.ACIError( >>> info=_('Ticket policy for %s could not be >>> read') % >>> keys[-1]) >> >> The second is definitely better. >> >>> This may end up fetching the rights multiple times depending on how many >>> things need to be read, so perhaps passing that in if you have it >>> already. >> >> This however means doing the get_effective_rights call anyway to get all >> the needed attrs, at which point most of the readability benefits are >> gone. >> >> Actually I'd like to add some good attrlevelrights handling right into >> ipaldap. Let's do this correctly rather than add a quick fix to the >> helpers just so we can use them. >> Issue here: https://fedorahosted.org/freeipa/ticket/4362 Sure, I'm ok with waiting and doing it right. > Once more, with patches ACK x2 rob From rcritten at redhat.com Fri May 30 13:34:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 May 2014 09:34:52 -0400 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <53888670.4090605@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> <53888670.4090605@redhat.com> Message-ID: <538888FC.7000900@redhat.com> Petr Viktorin wrote: > On 05/30/2014 08:37 AM, Martin Kosek wrote: >> On 05/29/2014 08:14 PM, Dmitri Pal wrote: >>> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>>> This, I believe, has already been covered, but I'm concerned >>>>>>>>> with the >>>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>>> >>>>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>>>> confusing since there is already an account enable/disable >>>>>>>>> command. >>>>>>>>> This >>>>>>>>> on top of unlock, are there now 3 possible boolean states a >>>>>>>>> user can >>>>>>>>> be >>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>>> deleted/active and staged/active? >>>>>>>>> >>>>>>>> Agree, we should only have "ipa user-unstage " and not >>>>>>>> call >>>>>>>> this operations with words like active/inactive. >>>>>>>> >>>>>>>> User's in the staging area are not inactive, they are *not* >>>>>>>> users yet in >>>>>>>> the first place. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> Ok. Let us consolidate the decisions, I think we are now running >>>>>>> in circles. >>>>>>> Let me start from Petr3's API proposal which was a functionally >>>>>>> complete >>>>>>> proposal and start from there: >>>>>>> >>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>>> ... >>>>>>>> My proposal would be that the move commands use the verb for the >>>>>>>> target >>>>>>>> and an >>>>>>>> option for the source, and add/mod use an option for the container: >>>>>>>> >>>>>>>> 1) adding a new user >>>>>>>> (to active) ipa user-add tuser ... >>>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>>> Ok. >>>>>>> >>>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>>> Not needed. >>>>>>> >>>>>>>> 2) moving to main >>>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>>> (from del) ipa user-activate tuser --deleted >>>>>>> We need both, alternative is Simo's proposal: >>>>>>> >>>>>>> ipa user-unstage >>>>>>> ipa user-undelete >>>>>>> >>>>>>> I personally like unstage and undelete commands, I would go with >>>>>>> those. >>>>>> Sorry for coming late to the party. >>>>>> I strongly do not like "unstage" >>>>>> This suggests that the user will be removed from staged but does >>>>>> not indicate >>>>>> that the full user will be created. >>>>>> As I suggested elsewhere provision-user or user-provision (or may >>>>>> be even >>>>>> user-add --from-stage) would be better. >>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating >>>>> unstaging operation >>>>> could get messy and would not create the right API. Using a >>>>> separate call would >>>>> be cleaner. As we see, choosing the right action term has proven >>>>> very difficult >>>>> - everyone has strong opinion on the command name :-) >>>>> >>>>> I already saw user-activate and user-unstage to be trashed so I am >>>>> thinking >>>>> what we are left with. I am still fan of user-unstage, >>>>> user-provision is not >>>>> telling me much more than user-unstage. >>>>> >>>>>>>> 3) moving to deleted >>>>>>>> (from active) ipa user-del tuser >>>>>>> Ok. >>>>>>> >>>>>>>> (from stage) ipa user-del tuser --staged >>>>>>> IMO staged deleted users should not be moved to deleted >>>>>>> container, but simply >>>>>>> permanently deleted. As Simo noted, staged user are not real >>>>>>> users, just >>>>>>> incomplete users. >>>>>>> >>>>>>>> 4) moving to stage >>>>>>>> (from active) ipa user-stage tuser >>>>>> >>>>>> This was suggested for completeness. >>>>>> I think we are cutting corners but I would not insist here. >>>>>> >>>>>>>> (from del) ipa user-stage tuser --deleted >>>>>>> None of the commands are needed for the basic workflow. >>>>>> But this is a valid use case. I created a user, deleted it and >>>>>> want to rebuild >>>>>> it becuase something got corrupted in the original entry. I agree >>>>>> it is not a >>>>>> primary use case but then we should have a ticket to track this >>>>>> RFE for >>>>>> future. >>>>> This was not about cutting corners, this was about what operation >>>>> makes sense >>>>> and what we should support. Stage was defined as a tree with >>>>> incomplete user, >>>>> thus this proposal - Simo was not very OK with this workflow. >>>>> >>>>>>>> 5) modifying >>>>>>>> (in active) ipa user-mod tuser ... >>>>>>> Ok. >>>>>>> >>>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>>> Simo did not like this command, I would personally add it. As >>>>>>> long as we have >>>>>>> "ipa user-add --staged", we should also have an option to delete >>>>>>> and modify >>>>>>> user in staged area. >>>>>>> >>>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>>> Not needed. >>>>>>> >>>>>>> Is this acceptable for everyone? If yes, the next step would be >>>>>>> for Thierry >>>>>>> to update the design page with new proposals. >>>>>>> >>>>>>> Martin >>>>> Let me try to consolidate again the proposals and changes for the >>>>> workflow&API >>>>> we have so far: >>>>> >>>>> 1) Manipulating staged users >>>>> - staged users must have UID RDN >>>>> - UID uniqueness plugin should not be enforcing in staging area >>>>> - we do not want it in user plugin as it requires different >>>>> parameters and >>>>> objectclasses >>>>> - API: >>>>> ipa stage-user-add >>>>> ipa stage-user-mod >>>>> ipa stage-user-find >>>>> ipa stage-user-del >>>>> >>>>> 2) Activating staged user >>>>> - activation will not do MODRDN, it will create a new user in >>>>> active container >>>>> and then delete the old one (to create right structural objectclass >>>>> set) >>>>> - for now, we need to allow operator delete any user in staged and >>>>> add any user >>>>> in active tree >>>>> - API >>>>> ipa stage-user-activate >>>>> - other options mentioned in the past were user-unstage and >>>>> user-activate >>>>> >>>>> 3) Manipulating deleted users >>>>> - deletion and undeletion will do MODRDN and will use the ACI that >>>>> Thierry >>>>> implemented >>>>> - API >>>>> ipa user-del >>>>> ipa user-undel OR ipa user-undelete >>>>> - Dmitri mentioned that he would like to see the move from deleted >>>>> to staged. I >>>>> would do it via flag: >>>>> ipa user-undel --to-stage >>>>> >>>>> >>>>> Does that look better now? Thanks, >>>> Yes, although I do not see the need for --to-stage honestly. >>> I agree we can just leave it as a future ticket. >> >> I think Simo's thoughts were different - he did not opposed to this part >> because it is too much work (it shouldn't be), but because he did not >> want that >> part of the workflow. Given the simplicity of this part, I see 2 options: >> 1) Do it and do it together with other API is it just one MODRDN command >> 2) Decide we do not want to do it, i.e. do not file any RFE >> >>> Rest looks OK. >> >> It should be fine, just one command could done differently to confine >> it better >> as per Honza's idea: >> >> ipa stageduser-add --from-deleted username > > Do we want that to take all of stageduser-add's options? > Should we use somrthing like stageduser-undel instead? I concur, though it should probably be stageduser-mod --undelete to keep with the CRUD model. rob From sbose at redhat.com Fri May 30 13:47:49 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 30 May 2014 15:47:49 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <538883EE.3090207@redhat.com> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> <538883EE.3090207@redhat.com> Message-ID: <20140530134748.GO30381@localhost.localdomain> On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote: > On 05/30/2014 03:04 AM, Sumit Bose wrote: > >On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: > >>On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: > >>>On 29.5.2014 13:48, Sumit Bose wrote: > >>>>== slapi-nis plugin/compat tree == > >>>>The compat tree offers a simplified LDAP tree with user and group data > >>>>for legacy clients. No data for this tree is stored on disk but it is > >>>>always created on the fly. It has to be noted that legacy clients might > >>>>be one of the major users of the user-views because chances are that > >>>>they were attached to the legacy systems with legacy ID management which > >>>>should be replaced by IPA. > >>>> > >>>>In contrast to the extdom plugin it is not possible to determine the > >>>>client based on the DN because connection might be anonymous. The > >>>>Slapi_PBlock contains the IP address of the client in > >>>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > >>>>tree requires a reverse-DNS lookup which might be unreliable. If the > >>>>reverse-DNS lookup was successful the slapi-nos plugin can follow the > >>>>same steps as the extdom plugin to lookup up and apply the view. > >>>Do we really want to base security decisions on reverse DNS resolution? > >>No we do not want to play these games. > >> > >>>That > >>>will be insecure. Attacker could tamper with reverse DNS to change UID/GID > >>>mapping ... Maybe we can store IP->view mapping in the LDAP database. That > >>>should be reliable if we assume that only TCP is used for connection to LDAP > >>>database. > >>It is not just about it being insecure, it is about it being wrong. > >>As soon as you have a bunch of clients behind a NAT this pans goes belly > >>up. > >I do not like this one either. I just wanted to list to options I could > >think of because I think supporting user-views on legacy clients is one > >of the major use-cases for this feature. > > > >bye, > >Sumit > > > >>>>As a alternative slapi-nis can provide one tree for each view. > >>This is the only alternative, if we decide to pursue it. > >> > >>Simo. > >> > >>-- > >>Simo Sorce * Red Hat, Inc * New York > >> > >>_______________________________________________ > >>Freeipa-devel mailing list > >>Freeipa-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/freeipa-devel > >_______________________________________________ > >Freeipa-devel mailing list > >Freeipa-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-devel > > Please correct me as I might be confused. > We have the compat tree now for legacy clients. It is also used by latest > SSSD clients to do special lookups, right? no, we discussed this with Alexander some time ago and he asked not to use the compat tree from SSSD but the extdom plugin because of the given limitations of the slapi-nis plugin. > The data in this tree comes from the SSSD on the server running in server > mode. > I wonder if we can say: here are replicas A, B, C that have vanilla "default > view", here are replicas K, L, M where the data is overwritten with a > special view (i.e. UID/GID fro ma special area) and then we have replicas > X,Y,Z that have a different overlay view. > It will be assumed that replicas A,B,C, serve clients in one "zone", new and > legacy, while K, L, M serve another zone and X, Y, Z serve the other one. > Would that work? Besides that it is very confusing it would be possible as long as the overrides from the special views are done by slapi-nis because SSSD on servers and replicas will always and only deliver the default view. bye, Sumit > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Fri May 30 13:51:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 May 2014 15:51:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0562-0563 Fix internal error when global policy is not readable In-Reply-To: <538888AA.60709@redhat.com> References: <5387543E.3010002@redhat.com> <53876AD4.6000108@redhat.com> <53884911.3010209@redhat.com> <5388495B.3010008@redhat.com> <538888AA.60709@redhat.com> Message-ID: <53888CF2.2040705@redhat.com> On 05/30/2014 03:33 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 05/30/2014 11:02 AM, Petr Viktorin wrote: >>> On 05/29/2014 07:13 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> When investigating this issue I became very annoyed by the star import >>>>> hiding where names come from, so I did some cleanup first. >>>>> >>>>> >>>>> In krbtpolicy, an ACIError is now raised if: >>>>> - the user doesn't have permission to read any one of the ticket policy >>>>> attributes on the requested entry >>>>> (checked using attribute-level rights) >>>>> - any ticket policy attribute from the default policy is not available >>>>> (either not readable, or not there at all) >>>>> (only checked if these are accessed, i.e. when the user entry >>>>> doesn't >>>>> override all of the defaults, or when requesting the global policy) >>>>> >>>>> That means if the user is not available at all, you get a NotFound, but >>>>> if global policy is not found it's assumed that it's just unreadable. >>>> >>>> That seems reasonable to me. >>>> >>>> I also noticed a typo, ddoesn't >>> >>> Fixed, thanks. >>> >>>> In the lower-level code, ldap2.py, we have some help >>>> can_[read|write|etc] for managing rights. Would doing something similar >>>> in baseldap be better than embedding the logic into each plugins? >>>> >>>> So instead of this: >>>> >>>> if rights is None: >>>> rights = baseldap.get_effective_rights( >>>> ldap, dn, self.obj.default_attributes) >>>> if 'r' not in rights.get(attrname.lower(), ''): >>>> raise errors.ACIError( >>>> info=_('Ticket policy for %s could not be >>>> read') % >>>> keys[-1]) >>>> >>>> You'd have this: >>>> >>>> if not baseldap.can_read(ldap, dn, attrname): >>>> raise errors.ACIError( >>>> info=_('Ticket policy for %s could not be >>>> read') % >>>> keys[-1]) >>> >>> The second is definitely better. >>> >>>> This may end up fetching the rights multiple times depending on how many >>>> things need to be read, so perhaps passing that in if you have it >>>> already. >>> >>> This however means doing the get_effective_rights call anyway to get all >>> the needed attrs, at which point most of the readability benefits are >>> gone. >>> >>> Actually I'd like to add some good attrlevelrights handling right into >>> ipaldap. Let's do this correctly rather than add a quick fix to the >>> helpers just so we can use them. >>> Issue here: https://fedorahosted.org/freeipa/ticket/4362 > > Sure, I'm ok with waiting and doing it right. > >> Once more, with patches > > ACK x2 Thanks! Pushed to master: 63a2147ac2bca82c710a6ffd025d4dbd8f1b3449 -- Petr? From nalin at redhat.com Fri May 30 14:11:21 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 30 May 2014 10:11:21 -0400 Subject: [Freeipa-devel] CA certificate renewal, shared store trust settings In-Reply-To: <53882EBA.4030007@redhat.com> References: <20140529174427.GC12741@redhat.com> <53882EBA.4030007@redhat.com> Message-ID: <20140530141121.GA16884@redhat.com> On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote: > On 29.5.2014 19:44, Nalin Dahyabhai wrote: > >I'm working on adding to certmonger the ability to read the IPA root > >certificate from the server and store it locally, and I'm looking at the > >V4 shared certificate store feature [1] with an eye toward also pulling > >down and processing those certificates. Before I head down that path, > >I've got a few questions about the schema that the page describes for > >storing trust information. > > So, you want to fetch the certificates directly from LDAP? Shouldn't > they rather be fetched using IPA API (in ipa-submit) or Dogtag API > (in dogtag-ipa-renew-agent-submit)? Yes, that's something the daemon is farming out to the enrollment helpers. As a start, though, I'm only looking at teaching ipa-submit to fetch this information. The IPA interfaces run over HTTPS, so I thought that having ipa-submit search LDAP using GSSAPI would avoid complications that could arise if the CA certificate had become invalid before we went to fetch things. The request for the "read the root certificate" functionality is to have something that works against servers running IPA on EL6, so the ability to fetch the v3 root information is dictated by needing to work against what we're already storing and offering there. Accessing the additional information that's coming in v4 could be done differently, but I'd also lean toward looking at the directory directly. The design page mentions asking SSSD for it, which I guess would work. > In the past few months that I worked on the CA certificate renewal > feature the shared certificate store design has evolved into > something more about certificate trust policy rather than simple > storage of CA certificates. My plan is to integrate it with p11-kit > in the forthcoming months to provide the policy to IPA clients. SSSD > is going to be used as the component between IPA and p11-kit. A > PKCS#11 module will be provided for (not only) that. (This is what > is going > to be about.) > > I can imagine you might as well talk to the module to fetch the CA > certificates. Are there any plans to support PKCS#11 as a storage > backend in certmonger? Only notionally, as it it's only ever been one of those "would be cool, but we don't need it in the short-term" things. I also wasn't looking forward to dealing with cases where a removable token isn't inserted right when we intend to access it, but if we need to make that work, then okay. > This does not make me nervous at all. Take a look at other similar > attributes in IPA, they all use directory string syntax. I'm open to > suggestions, though. The first thing that comes to mind is an enumerated syntax like the one for booleans, but I understand that enforcing that would require help from the server itself. The docs tell me that syntax plugins are a thing we can supply, but that might be more than we want to bite off. > >The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' > >and 'distrusted', appears to map pretty directly to the sort of > >information that OpenSSL stores in trusted certificates [2], but going > >through the man pages for x509(1) and verify(1), I don't see anything > >that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's > >that value intended to signify, and how would consumers of the > >certificates be expected to treat certificates from entries with that > >ipaKeyTrust value? > > Actually it is designed to map to p11-kit-style trust policy (), > which is a superset of OpenSSL's. What's the planned schedule for teaching NSS and OpenSSL to consume trust information supplied in this format? > The "unknown" value means the trust is not explicitly given and that > if there is other source of trust information for the > key/certificate, it should be used. In p11-kit terms, it is for > certificates which are neither in the anchors nor the blacklist set. > In NSS terms, it's for certificates without any of the C, T, P or p > trust flags. Okay, that makes sense -- they're around for building chains, but not much else. > >Are there examples of what the ipaKeyUsage attribute should contain? > > It's the purpose bit names from the key usage certificate extension > () or "none". So, enumerated values represented as directory strings? > >Is there a recommended method for mapping from this representation to > >the form that we'd pass to certutil(1)'s '-t' option when storing the > >certificates in NSS databases, or is the intent that it be translated > >into NSS-specific PKCS#11 attributes set on those certificates? > > Well, it can be both. But as I said above, I'm not sure if reading > from LDAP directly is the best thing to do in this case. [shrug] If that's where it's being stored, something's going to have to fetch it from there. Until the SSSD and IPA interfaces are fleshed out, LDAP's the only option. But I understand we're not there yet. I'm starting to think that attempting to future-proof by learning to fetch and store the v4 information isn't a good idea at this time, and sticking to just fetching the data we store in v3 is the better option. Cheers, Nalin From simo at redhat.com Sat May 31 01:27:23 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 30 May 2014 21:27:23 -0400 Subject: [Freeipa-devel] Patch for #1539 Message-ID: <1401499643.3590.39.camel@willson.li.ssimo.org> 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. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Check-for-password-expiration-in-pre-bind.patch Type: text/x-patch Size: 3430 bytes Desc: not available URL: