Re: [Freeipa-devel] python-kdcproxy 0.3
On 2015-06-25 06:04, Martin Kosek wrote: We need to make sure it is at least in https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/builds/ https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/builds/ I started the COPR builds based on the F22 SRPMs. Thanks Martin! You can easily build a F21 RPM with a small modification. You can either disable the %check block and remove the tox call from the spec file. Or you could include my patch. The code is fine. It is really just a small incompatibility in the test code. Apropos tests let's talk about CI for python-kdcproxy, when you are back in Brno. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Self-service Password Reset
On Thu, 2015-06-25 at 15:19 -0400, Drew Erny wrote: On 06/25/2015 03:13 PM, Drew Erny wrote: On 06/25/2015 03:07 PM, Simo Sorce wrote: On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote: Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Well clearly it is a security nightmare :-D Anyway point 6, it is better to not send any password via email. I see 2/3 options here. 1) Just show the user the new password and a link to go and reset it. 2) Just redirect the user to the Self-Service Password change page and pre-fill the old password fields with the newly minted password. 3) Provide a password change with hidden old-password fields straight on the self-service portal. I think when I was running this past my peers, they mentioned these concerns, and I must've forgotten to update the draft. While 2 would be somewhjat nice it is probably difficult because of CSRF protections in FreeIPA, and besides if you already have the password you might as well just use it immediately and save the redirect. So I would prefer 3. I prefer 3 as well; I'll amend the draft right now. Simo. Sorry, I jumped the gun on replying to this email and forgot to sanity check it. Option 3 won't work, because when anybody who is not the user resets the user's password (including admins, IIRC), the user is prompted to reset their password upon first login. So, if the user sets a new password straight on the self-service portal, they'll have to change it immediately anyway, because the self-service portal will be the user resetting the password, not the actual user. This is not how it works. Follow these steps: 1. check that the user used a link with the proper unique reset code in the path on in the query arguments, and validate the link is not expired. 2. immediately remove the reset token from the db. 3. generate a random password 4. use the service keytab to authenticate and reset the user password to the generated random password. 5. present the user with a form to enter his new password (a hidden filed will contain the random password as old password). 6. perform a password reset where the old password is the one you generated in (2) and used in (3) and the new password is the one the user gave you. You will basically go through 2 password changes (one administrative, and one normal), but it's ok. Make sure to be able to retain the password until the password change is successful, as the user may fail to change the password if the new one does not meet policy requirements, so you'll have to display errors and be able to retry. Option 1, just displaying the password to the user, is probably actually best. This way, they copy the password, paste it into the FreeIPA webui login form, and then get kicked into the FreeIPA webui password reset workflow, instead of setting a new password just to have to change it. We can show the password with a big message that says, USE THIS PASSWORD IMMEDIATELY. IT WILL NOT BE AVAILABLE AGAIN. It's more error prone and does not give you any better outcome. Simo, -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Topology: Central node removal in star topology
On Thu, 2015-06-25 at 09:53 +0200, Petr Vobornik wrote: On 06/25/2015 08:52 AM, Ludwig Krispenz wrote: On 06/24/2015 09:01 PM, Simo Sorce wrote: On Wed, 2015-06-24 at 11:25 +0200, Ludwig Krispenz wrote: Oleg, the topology plugin relies on existing connection between servers which remain in a topolgy. If you remove a central node in your topology you are asking for trouble. With Petr's patch it warns you that your topology will be disconnected, and if you insist we cannot guarantee anything. should we completely prohibit this ? No, but a --force should be needed. Without a --force option we should not allow to remove a replica completely from another one. I don't know, I think you could also enforce an uninstall of vm175 with probably the same result. what you mean be calculating the remaining topology and send it to the remaining servers does not work, it would require to send a removal of a segment, which would be rejected. You would have to connect to each replica that has a replication agreement with vm175 and remove the segment from that replica. But it wouldn't really help much as once a replica is isolated from the central one, it will not see the other operations going on in other replicas. Once we have a topology resolver we will be able to warn that removing a specific replica will cause a split brain and make very loud warnings we have this already, see the output of Oleg's example: ipa-replica-manage del vm-175.idm.lab.eng.brq.redhat.com Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be disconnected: Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Continue to delete? [no]: yes it tells you that the topology gets disconnected and which connections will be missing, the continue yes/no is the --force, the question was, should we allow a force in this situation ? What it does is: 1. Checks current topology, prints errors with introduction msg: Current topology is disconnected: + errors 2. Checks topology after node removal, prints errors with msg: Topology after removal of %s will be disconnected: + errors 3. if there were errors in #1 or #2, it does: if not force and not ipautil.user_input(Continue to delete?, False): sys.exit(Aborted) To make it more loud we can introduce msg in #2 with: WARNING: or something even more louder The question Continue to delete? could be * removed, and therefore --force will be always required for such case * be still regarded as 'force' but the question could be changed e.g. to: Continue to delete and disconnect the topology? I do not like questions very much, they are usually annoying to scripting and such. I would not ask questions, and simply deny the operation if --force is not present, and allow it if it is present. More interesting would be if we can heal this later by adding new segments. Indeed, reconnecting all the severed replicas should cause all the removals (segments or servers) to be replicated among servers and should bring back the topology view in a consistent state. But not until all servers are reconnected and replication has started again. This healing can also be required without forcing removal by an admin. If you have a start topology and your central node goes down and is not recoverable Yes, I think the most likely case (bar testing) for ever using --force remove is that a server imploded and died, and just need replacing. Being able to recover from such a situation by simply reconnecting replicas until the split brain is healed is paramount. I would go as far as saying that perhaps we should provide a simple heal-topology command in a *future* version that will pick one replica and reconnect all the missing branches in a stellar topology. The only problem in doing that is that the tool my have a misleading idea of the status of the topology given that when replication is severed not all topology changes may be reflected to all servers. So different servers may have a different view of the current topology based on when they got disconnected and the replication flow was interrupted. So a good tool would have to reconnect all branches it sees, then wait a little to see if the reconnected replicas send in topology changes and re-iterate if further changes caused the topology to still be in split brain. Another tool could
Re: [Freeipa-devel] [PATCHES 0252-0253] DNSSEC: allow to move DNSSEC key master to another IPA server
On 17.6.2015 13:37, Martin Basti wrote: On 17/06/15 13:26, Petr Spacek wrote: On 16.6.2015 15:40, Martin Basti wrote: On 05/06/15 12:54, Petr Spacek wrote: On 20.5.2015 18:00, Martin Basti wrote: This patch allows to disable DNSSEC key master on IPA server, or replace current DNSSEC key master with another IPA server. Only for master branch. https://fedorahosted.org/freeipa/ticket/4657 Patches attached. NACK. This happens on DNSSEC key master: $ ipa-dns-install --disable-dnssec-master Do you want to disable current DNSSEC key master? [no]: yes Unexpected error - see /var/log/ipaserver-install.log for details: TypeError: sequence item 0: expected string, DNSName found 2015-06-05T10:52:35Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 733, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 128, in main dns_installer.disable_dnssec_master(options.unattended) File /usr/lib/python2.7/site-packages/ipaserver/install/dns.py, line 112, in disable_dnssec_master , .join(dnssec_zones)) 2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, exception: TypeError: sequence item 0: expected string, DNSName found Updated patches attached. Due new installers, more changes were required. Sorry, NACK, I'm not able to apply this patch set to current master (69607250b9762a6c9b657dd31653b03d54a7b411). Rebased patches attached. NACK. 0) ipa-dns-install --replace-dnssec-master always puts file into /root/ipa-kasp.db. It would be better to put it into local working directory or /var/lib/ipa (as with replica files). 1) I installed DNSSEC key master role on the vm-134 but DNSSEC services were not stopped by ipactl stop: [root@vm-134 review]# ipactl stop Stopping ipa-otpd Service Stopping httpd Service Stopping ipa_memcached Service Stopping kadmin Service Stopping krb5kdc Service Stopping Directory Service ipa: INFO: The ipactl command was successful [root@vm-134 review]# ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-otpd Service Starting ipa-ods-exporter Service Starting ods-enforcerd Service Starting ipa-dnskeysyncd Service Subsequent ipactl stop worked fine, only the first one is affected. 2a) vm-134 was the original master. I ran this: [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com ... and then attempted to install master to vm-059: [root@vm-059 review]# ipa-dns-install --dnssec-master This command was accepted despite of missing --kasp-db option and wrong replica name. It should error out and tell the user to run the command with --kasp-db option. Even better, we could get rid of explicit replica name specification in --replace-dnssec-master option and allow to run installation with --kasp-db on any replica as long as the kasp.db file is provided. 2b) Attempt to move DNSSEC key master from vm-134 to vm-090 *without* specifying --kasp-db option was accepted. [root@vm-090 review]# ipa-dns-install --dnssec-master As in case (2a), it should print what user is supposed to do. I propose following text: Current DNSSEC key master vm-134.abc.idm.lab.eng.brq.redhat.com is being moved to different server. You need to copy kasp.db file from vm-134.abc.idm.lab.eng.brq.redhat.com and run following command to complete the transition: # ipa-dns-install --dnssec-master --kasp-db=/path/to/the/copied/kasp.db 3) [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com does not remove ISMASTER option from file /etc/sysconfig/ipa-dnskeysyncd . 4) [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com it is possible to run [root@vm-134 review]# ipa-dns-install --dnssec-master again without --kasp-db and it is accepted. Moreover, in this case ipaConfigString NEW_DNSSEC_MASTER is not properly removed from cn=DNSKeySync,cn=vm-090.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example. 5) Sequence of commands [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com [root@vm-090 review]# ipa-replica-manage del vm-134.abc.idm.lab.eng.brq.redhat.com allows me to run [root@vm-090 review]# ipa-dns-install --dnssec-master without --kasp-db option, it does not throw an error, and the information that some other master existed somewhere is lost. It would be probably better to replace this and to use some global attribute in cn=dns so similar problems do not happen. 6) The migration itself seems to work, KASP DB seems to work properly, however it is necessary to run 'ods-ksmutil zonelist' command *before* all the daemons on the new master are (re)started. This needs do be done to re-generate file /etc/opendnssec/zonelist.xml from the new
Re: [Freeipa-devel] [RFC] Self-service Password Reset
On Thu, 25 Jun 2015, Simo Sorce wrote: On Thu, 2015-06-25 at 15:19 -0400, Drew Erny wrote: On 06/25/2015 03:13 PM, Drew Erny wrote: On 06/25/2015 03:07 PM, Simo Sorce wrote: On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote: Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Well clearly it is a security nightmare :-D Anyway point 6, it is better to not send any password via email. I see 2/3 options here. 1) Just show the user the new password and a link to go and reset it. 2) Just redirect the user to the Self-Service Password change page and pre-fill the old password fields with the newly minted password. 3) Provide a password change with hidden old-password fields straight on the self-service portal. I think when I was running this past my peers, they mentioned these concerns, and I must've forgotten to update the draft. While 2 would be somewhjat nice it is probably difficult because of CSRF protections in FreeIPA, and besides if you already have the password you might as well just use it immediately and save the redirect. So I would prefer 3. I prefer 3 as well; I'll amend the draft right now. Simo. Sorry, I jumped the gun on replying to this email and forgot to sanity check it. Option 3 won't work, because when anybody who is not the user resets the user's password (including admins, IIRC), the user is prompted to reset their password upon first login. So, if the user sets a new password straight on the self-service portal, they'll have to change it immediately anyway, because the self-service portal will be the user resetting the password, not the actual user. This is not how it works. Follow these steps: 1. check that the user used a link with the proper unique reset code in the path on in the query arguments, and validate the link is not expired. 2. immediately remove the reset token from the db. 3. generate a random password 4. use the service keytab to authenticate and reset the user password to the generated random password. 5. present the user with a form to enter his new password (a hidden filed will contain the random password as old password). 6. perform a password reset where the old password is the one you generated in (2) and used in (3) and the new password is the one the user gave you. You will basically go through 2 password changes (one administrative, and one normal), but it's ok. This is what I suggested multiple times in past, see for example, http://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html However, this requires that you have password policy which allows subsequent password changes in a short time period. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Self-service Password Reset
On Thu, 2015-06-25 at 23:43 +0300, Alexander Bokovoy wrote: On Thu, 25 Jun 2015, Simo Sorce wrote: On Thu, 2015-06-25 at 15:19 -0400, Drew Erny wrote: On 06/25/2015 03:13 PM, Drew Erny wrote: On 06/25/2015 03:07 PM, Simo Sorce wrote: On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote: Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Well clearly it is a security nightmare :-D Anyway point 6, it is better to not send any password via email. I see 2/3 options here. 1) Just show the user the new password and a link to go and reset it. 2) Just redirect the user to the Self-Service Password change page and pre-fill the old password fields with the newly minted password. 3) Provide a password change with hidden old-password fields straight on the self-service portal. I think when I was running this past my peers, they mentioned these concerns, and I must've forgotten to update the draft. While 2 would be somewhjat nice it is probably difficult because of CSRF protections in FreeIPA, and besides if you already have the password you might as well just use it immediately and save the redirect. So I would prefer 3. I prefer 3 as well; I'll amend the draft right now. Simo. Sorry, I jumped the gun on replying to this email and forgot to sanity check it. Option 3 won't work, because when anybody who is not the user resets the user's password (including admins, IIRC), the user is prompted to reset their password upon first login. So, if the user sets a new password straight on the self-service portal, they'll have to change it immediately anyway, because the self-service portal will be the user resetting the password, not the actual user. This is not how it works. Follow these steps: 1. check that the user used a link with the proper unique reset code in the path on in the query arguments, and validate the link is not expired. 2. immediately remove the reset token from the db. 3. generate a random password 4. use the service keytab to authenticate and reset the user password to the generated random password. 5. present the user with a form to enter his new password (a hidden filed will contain the random password as old password). 6. perform a password reset where the old password is the one you generated in (2) and used in (3) and the new password is the one the user gave you. You will basically go through 2 password changes (one administrative, and one normal), but it's ok. This is what I suggested multiple times in past, see for example, http://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html However, this requires that you have password policy which allows subsequent password changes in a short time period. The administrative reset should not cause the password change blackout period. If it does it is something we should consider fixing/changing. Note that if that's the case, a manual approach will be no better as the user won't be able to immediately change the password as well. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Password vault
On 6/25/2015 12:35 AM, Jan Cholasta wrote:
I think it would be better to use a new attribute type which inherits
from ipaPublicKey (ipaVaultPublicKey?) rather than ipaPublicKey
directly
for assymetric vault public keys, so that assymetric public key and
escrow public key are on the same level and you can still use
ipaPublicKey to refer to either one:
ipaPublicKey
ipaVaultPublicKey
ipaEscrowPublicKey
OK. To be consistent the parameters need to be renamed too:
--vault-public-key and --vault-public-key-file.
It doesn't need to, there is no requirement for CLI names to always
match attribute names. (Also I don't insist on the name
ipaVaultPublicKey, feel free to change it if you want.)
It's unchanged for now. In a previous discussion it was advised to reuse
the existing attribute type whenever possible.
Well, in this discussion, it is not. Escrow public key should also reuse
ipaPublicKey, but it can't if you use it for vault public key. By using
ipaPublicKey subtypes you can distinguish between the two uses and still
use ipaPublicKey to refer to either of them.
So what's changed? This is what you said when I posted the same patch
six months ago:
In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute
types to store salt and public key for vault. Are there existing
attribute types that I can use instead? I see there's an ipaPublicKey,
should I use that and maybe add ipaSalt/ipaEncSalt? Thanks.
yes, please re-use existing attributes where possible.
Honza
Could you show me how to use ipaPublicKey to refer to ipaVaultPublicKey
and ipaEscrowPublicKey? Under what situation would that be useful?
a) When the non-split vault_{archive,retrieve} was called from a
server API with client-only options, it crashed. This is the broken API
I was talking about.
This is because in the current framework any API called on the server
side will be a server API, so you are not supposed to call it with
client options in the first place. Because of that limitation, the only
way to use client options is to use a separate API on the client side to
call the original API on the server side. The point is, client options
belong to client API, and server options belong to server API. In
vault_add the public key file name belongs to client API because it's
used to load a file on the client side. You should not add public key
file name option to the server API just because it can safely be ignored.
I don't disagree, but file name options do not belong to the general
client API either, as they are strictly CLI-specific.
To my understanding the current framework doesn't have a separate CLI
class, so you don't have a choice but to put CLI-specific options in the
client API class too. However, you do have a choice not to combine
client API class and server API class because otherwise that will put
CLI-specific options in the server API class too.
2. Since the vault_archive_internal inherits from Update, it accepts
all non
primary-key attributes automatically. This is incorrect since we
don't want to
update these parameters during archival. Can this behavior be
overridden?
Inherit from PKQuery instead (don't forget to add has_output =
output.standard_entry).
Previously you didn't want to use LDAPQuery because of semantics
reasons. Is PKQuery fine semantically?
It's not. Currently there is a set of commands which operate on the LDAP
part of vault and another set of commands which operate on the KRA part
of vault and we don't want the commands in one set to see attributes
related to the other part of vault. If you insist on keeping both parts
in a single object, you have to resort to hackery like using PKQuery,
hence my suggestion to split the data part off to a separate object to
avoid this.
This because the framework was based on simplistic assumptions which
create unnecessary restrictions, for example:
* client API is just a proxy to server API (i.e. client and server
cannot do different things)
They can do different things the same way vault_archive/vault_retrieve
does that, the commands just can't be called the same (which is not
necessarily a bad thing).
Of course different APIs can do different things, like vault_add calling
vault_archive, or vault_archive calling vault_archive_internal. The
point is right now the client portion of an API (i.e. the forward()
method) cannot do anything other than forwarding the request to the
server, so the API has to be split into different APIs:
* vault_archive
* vault_archive_internal
It would be nice to have formal separation between client and server
APIs so it's clear they are different but still related without
resorting to ugly names:
* client.vault_archive
* server.vault_archive
* CLI options will be identical to client and server API options (i.e.
no CLI-only, client-only, or server-only options)
Actually, you can create CLI-only options (add include='cli' to the
param's kwargs).
I need to
Re: [Freeipa-devel] IPA Python API
If I add the lines if not api.Backend.rpcclient.isconnected(): api.Backend.rpcclient.connect() before I call the api, the code works. Problem (pretty much) solved. On 06/23/2015 04:36 PM, Drew Erny wrote: Resurrecting this thread, because the problem is getting me again. If I go through the python interpreter and import the code that calls the ipalib, and then manually call it myself the way the webserver does, the code works. If the same code is run in the course of the web server process, I get the error: Traceback (most recent call last): File /home/derny/freeipa/env/lib/python2.7/site-packages/cherrypy/_cprequest.py, line 670, in respond response.body = self.handler() File /home/derny/freeipa/env/lib/python2.7/site-packages/cherrypy/lib/encoding.py, line 217, in __call__ self.body = self.oldhandler(*args, **kwargs) File /home/derny/freeipa/env/lib/python2.7/site-packages/cherrypy/_cpdispatch.py, line 61, in __call__ return self.callable(*self.args, **self.kwargs) File freeipa_community_portal/app.py, line 39, in POST errors = user.save() File freeipa_community_portal/model/user.py, line 33, in save self._call_api() File freeipa_community_portal/model/user.py, line 45, in _call_api mail=self.email File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 755, in run return self.forward(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File /usr/lib/python2.7/site-packages/ipalib/rpc.py, line 880, in forward command = getattr(self.conn, name) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'CP Server Thread-6' The error shows up whether the server is run from within the python interpreter or by itself. I kinit and have a TGT from the IPA server. The client machine is registered with the IPA server. When I run the commands by hand, an HTTP ticket can be seen in the klist. When I run the webserver, no HTTP ticket is ever recieved, so the code is failing on the client side before it even gets to the server. Which is obviously not what should be happening. It's the same error I got when I was using Flask, and now I'm using cherrypy and it's still broken. Could this have something to do with the web server being a multithreaded environment? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Self-service Password Reset
On 06/25/2015 03:07 PM, Simo Sorce wrote: On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote: Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Well clearly it is a security nightmare :-D Anyway point 6, it is better to not send any password via email. I see 2/3 options here. 1) Just show the user the new password and a link to go and reset it. 2) Just redirect the user to the Self-Service Password change page and pre-fill the old password fields with the newly minted password. 3) Provide a password change with hidden old-password fields straight on the self-service portal. I think when I was running this past my peers, they mentioned these concerns, and I must've forgotten to update the draft. While 2 would be somewhjat nice it is probably difficult because of CSRF protections in FreeIPA, and besides if you already have the password you might as well just use it immediately and save the redirect. So I would prefer 3. I prefer 3 as well; I'll amend the draft right now. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Self-service Password Reset
On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote: Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Well clearly it is a security nightmare :-D Anyway point 6, it is better to not send any password via email. I see 2/3 options here. 1) Just show the user the new password and a link to go and reset it. 2) Just redirect the user to the Self-Service Password change page and pre-fill the old password fields with the newly minted password. 3) Provide a password change with hidden old-password fields straight on the self-service portal. While 2 would be somewhjat nice it is probably difficult because of CSRF protections in FreeIPA, and besides if you already have the password you might as well just use it immediately and save the redirect. So I would prefer 3. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Self-service Password Reset
On 06/25/2015 03:13 PM, Drew Erny wrote: On 06/25/2015 03:07 PM, Simo Sorce wrote: On Thu, 2015-06-25 at 14:40 -0400, Drew Erny wrote: Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Well clearly it is a security nightmare :-D Anyway point 6, it is better to not send any password via email. I see 2/3 options here. 1) Just show the user the new password and a link to go and reset it. 2) Just redirect the user to the Self-Service Password change page and pre-fill the old password fields with the newly minted password. 3) Provide a password change with hidden old-password fields straight on the self-service portal. I think when I was running this past my peers, they mentioned these concerns, and I must've forgotten to update the draft. While 2 would be somewhjat nice it is probably difficult because of CSRF protections in FreeIPA, and besides if you already have the password you might as well just use it immediately and save the redirect. So I would prefer 3. I prefer 3 as well; I'll amend the draft right now. Simo. Sorry, I jumped the gun on replying to this email and forgot to sanity check it. Option 3 won't work, because when anybody who is not the user resets the user's password (including admins, IIRC), the user is prompted to reset their password upon first login. So, if the user sets a new password straight on the self-service portal, they'll have to change it immediately anyway, because the self-service portal will be the user resetting the password, not the actual user. Option 1, just displaying the password to the user, is probably actually best. This way, they copy the password, paste it into the FreeIPA webui login form, and then get kicked into the FreeIPA webui password reset workflow, instead of setting a new password just to have to change it. We can show the password with a big message that says, USE THIS PASSWORD IMMEDIATELY. IT WILL NOT BE AVAILABLE AGAIN. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [RFC] Self-service Password Reset
Hi, All, FreeIPA's most requested feature just got a proposal. Check it out at http://www.freeipa.org/page/V4/Self_Service_Password_Reset I eagerly await your explanations of why this is a terrible idea. Thanks, Drew Erny -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Topology: Central node removal in star topology
On 25.6.2015 09:53, Petr Vobornik wrote: On 06/25/2015 08:52 AM, Ludwig Krispenz wrote: On 06/24/2015 09:01 PM, Simo Sorce wrote: On Wed, 2015-06-24 at 11:25 +0200, Ludwig Krispenz wrote: Oleg, the topology plugin relies on existing connection between servers which remain in a topolgy. If you remove a central node in your topology you are asking for trouble. With Petr's patch it warns you that your topology will be disconnected, and if you insist we cannot guarantee anything. should we completely prohibit this ? No, but a --force should be needed. Without a --force option we should not allow to remove a replica completely from another one. I don't know, I think you could also enforce an uninstall of vm175 with probably the same result. what you mean be calculating the remaining topology and send it to the remaining servers does not work, it would require to send a removal of a segment, which would be rejected. You would have to connect to each replica that has a replication agreement with vm175 and remove the segment from that replica. But it wouldn't really help much as once a replica is isolated from the central one, it will not see the other operations going on in other replicas. Once we have a topology resolver we will be able to warn that removing a specific replica will cause a split brain and make very loud warnings we have this already, see the output of Oleg's example: ipa-replica-manage del vm-175.idm.lab.eng.brq.redhat.com Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be disconnected: Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Continue to delete? [no]: yes it tells you that the topology gets disconnected and which connections will be missing, the continue yes/no is the --force, the question was, should we allow a force in this situation ? What it does is: 1. Checks current topology, prints errors with introduction msg: Current topology is disconnected: + errors 2. Checks topology after node removal, prints errors with msg: Topology after removal of %s will be disconnected: + errors 3. if there were errors in #1 or #2, it does: if not force and not ipautil.user_input(Continue to delete?, False): sys.exit(Aborted) To make it more loud we can introduce msg in #2 with: WARNING: or something even more louder The question Continue to delete? could be * removed, and therefore --force will be always required for such case * be still regarded as 'force' but the question could be changed e.g. to: Continue to delete and disconnect the topology? Nitpick: I'm not a native English speaker but Current topology is disconnected does not sound clear and scary enough to me. At very least, the line should start with WARNING: to follow the same patter as all other warnings. Also it would be nice to add something descriptive like 'Changes in will not be replicated to all servers and data WILL become inconsistent.' Or possibly 'GATE TO HELL IS WIDE OPEN'? :-) Of course all this needs to be rephrased to proper English ... Petr^2 Spacek More interesting would be if we can heal this later by adding new segments. Indeed, reconnecting all the severed replicas should cause all the removals (segments or servers) to be replicated among servers and should bring back the topology view in a consistent state. But not until all servers are reconnected and replication has started again. This healing can also be required without forcing removal by an admin. If you have a start topology and your central node goes down and is not recoverable Simo. Ludwig On 06/24/2015 11:04 AM, Oleg Fayans wrote: Hi everybody, Current implementation of topology plugin (including patch 878 from Petr) allows the deletion of the central node in the star topology. I had the following topology: snip -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Topology: Central node removal in star topology
On 06/24/2015 09:01 PM, Simo Sorce wrote: On Wed, 2015-06-24 at 11:25 +0200, Ludwig Krispenz wrote: Oleg, the topology plugin relies on existing connection between servers which remain in a topolgy. If you remove a central node in your topology you are asking for trouble. With Petr's patch it warns you that your topology will be disconnected, and if you insist we cannot guarantee anything. should we completely prohibit this ? No, but a --force should be needed. Without a --force option we should not allow to remove a replica completely from another one. I don't know, I think you could also enforce an uninstall of vm175 with probably the same result. what you mean be calculating the remaining topology and send it to the remaining servers does not work, it would require to send a removal of a segment, which would be rejected. You would have to connect to each replica that has a replication agreement with vm175 and remove the segment from that replica. But it wouldn't really help much as once a replica is isolated from the central one, it will not see the other operations going on in other replicas. Once we have a topology resolver we will be able to warn that removing a specific replica will cause a split brain and make very loud warnings we have this already, see the output of Oleg's example: ipa-replica-manage del vm-175.idm.lab.eng.brq.redhat.com Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be disconnected: Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Continue to delete? [no]: yes it tells you that the topology gets disconnected and which connections will be missing, the continue yes/no is the --force, the question was, should we allow a force in this situation ? More interesting would be if we can heal this later by adding new segments. Indeed, reconnecting all the severed replicas should cause all the removals (segments or servers) to be replicated among servers and should bring back the topology view in a consistent state. But not until all servers are reconnected and replication has started again. This healing can also be required without forcing removal by an admin. If you have a start topology and your central node goes down and is not recoverable Simo. Ludwig On 06/24/2015 11:04 AM, Oleg Fayans wrote: Hi everybody, Current implementation of topology plugin (including patch 878 from Petr) allows the deletion of the central node in the star topology. I had the following topology: vm056 vm036 \ / | vm175 | / \ | vm127 vm244 I was able to remove node vm175 from node vm244: [17:54:48]ofayans@vm-244:~]$ ipa-replica-manage del vm-175.idm.lab.eng.brq.redhat.com Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be disconnected: Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Continue to delete? [no]: yes Waiting for removal of replication agreements unexpected error: limits exceeded for this query I would expect this operation to delete 4 replication agreements on all nodes: vm056 - vm175 vm127 - vm175 vm244 - vm175 vm036 - vm175 However an arbitrary set of replication agreements was deleted on each node leading to total infrastructure inconsistency: === vm056**thought the topology was as follows: vm056 vm036 / | vm175 | / \ | vm127 vm244 [10:28:55]ofayans@vm-056:~]$ ipa topologysegment-find realm -- 4 segments matched -- Segment name: 036-to-244 Left node: vm-036.idm.lab.eng.brq.redhat.com Right node: vm-244.idm.lab.eng.brq.redhat.com Connectivity: both Segment name: vm-036.idm.lab.eng.brq.redhat.com-to-vm-175.idm.lab.eng.brq.redhat.com Left node: vm-036.idm.lab.eng.brq.redhat.com Right node:
Re: [Freeipa-devel] Topology: Central node removal in star topology
On 06/25/2015 08:52 AM, Ludwig Krispenz wrote: On 06/24/2015 09:01 PM, Simo Sorce wrote: On Wed, 2015-06-24 at 11:25 +0200, Ludwig Krispenz wrote: Oleg, the topology plugin relies on existing connection between servers which remain in a topolgy. If you remove a central node in your topology you are asking for trouble. With Petr's patch it warns you that your topology will be disconnected, and if you insist we cannot guarantee anything. should we completely prohibit this ? No, but a --force should be needed. Without a --force option we should not allow to remove a replica completely from another one. I don't know, I think you could also enforce an uninstall of vm175 with probably the same result. what you mean be calculating the remaining topology and send it to the remaining servers does not work, it would require to send a removal of a segment, which would be rejected. You would have to connect to each replica that has a replication agreement with vm175 and remove the segment from that replica. But it wouldn't really help much as once a replica is isolated from the central one, it will not see the other operations going on in other replicas. Once we have a topology resolver we will be able to warn that removing a specific replica will cause a split brain and make very loud warnings we have this already, see the output of Oleg's example: ipa-replica-manage del vm-175.idm.lab.eng.brq.redhat.com Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be disconnected: Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com Continue to delete? [no]: yes it tells you that the topology gets disconnected and which connections will be missing, the continue yes/no is the --force, the question was, should we allow a force in this situation ? What it does is: 1. Checks current topology, prints errors with introduction msg: Current topology is disconnected: + errors 2. Checks topology after node removal, prints errors with msg: Topology after removal of %s will be disconnected: + errors 3. if there were errors in #1 or #2, it does: if not force and not ipautil.user_input(Continue to delete?, False): sys.exit(Aborted) To make it more loud we can introduce msg in #2 with: WARNING: or something even more louder The question Continue to delete? could be * removed, and therefore --force will be always required for such case * be still regarded as 'force' but the question could be changed e.g. to: Continue to delete and disconnect the topology? More interesting would be if we can heal this later by adding new segments. Indeed, reconnecting all the severed replicas should cause all the removals (segments or servers) to be replicated among servers and should bring back the topology view in a consistent state. But not until all servers are reconnected and replication has started again. This healing can also be required without forcing removal by an admin. If you have a start topology and your central node goes down and is not recoverable Simo. Ludwig On 06/24/2015 11:04 AM, Oleg Fayans wrote: Hi everybody, Current implementation of topology plugin (including patch 878 from Petr) allows the deletion of the central node in the star topology. I had the following topology: snip -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0020..0022 pki-related upgrade fixes
On 19/06/15 09:28, Fraser Tweedale wrote: The attached patches fix upgrade issues when pki is also updated from pre 10.2.4. pki dependency is bumped to 10.2.5 - the official builds should be done Friday (US time) but it is available from my copr[1]. If someone wants to add to official freeipa COPR in meantime the SRPM is here[2]. [1] https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ [2] https://ftweedal.fedorapeople.org/pki-core-10.2.5-0.2.fc21.src.rpm Thanks, Fraser Thank you. 1) I cannot apply patches. 2) IMO patch 0020 was fixed with my patch 266 3) This print should not be there + +print cs_cfg +for profile_id in profile_ids: 4) This is unused variable, it is defined later + cs_cfg = None 5) Can you add there log.error or log.debug instead of pass please? +# enable the profile +try: +profile_api.enable_profile(profile_id) +except errors.RemoteRetrieveError: +pass I will test it later. -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
