On 06/09/2014 10:03 AM, Nathaniel McCallum wrote:
On Mon, 2014-06-09 at 09:01 -0400, Simo Sorce wrote:
From: "Martin Kosek" <mko...@redhat.com>
Given all sort of issues we get, I am thinking we should just revert it
unless
there is a quick fix available.
Instead of reverting I am thinking we may want to make this optional by adding 
a configuration parameter that defaults to False for now. Once we can manage 
better the password change we can turn it on by deault, in the meanwhile admins 
can choose by themselves the lesser evil.

Thoughts?
I'm not a fan of introducing a new configuration parameter for a
temporary workaround.

My preference is to revert it and have a small project for the next
release which handles all the "non-authenticated" corner cases. This
would include:
* Expired passwords
* Password changes
* Token syncing
* Unauthenticated RPCs (rpcserver.py rework)
* others?

I think there is some value to be gained by thinking about these
problems as a whole and devising a set of consistent mechanisms for
them.

Nathaniel

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
+1

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to