On Fri, Jul 24, 2015 at 12:02 PM, Adam Young <ayo...@redhat.com> wrote:
> On 07/24/2015 12:00 AM, Julian Edwards wrote: > >> Hello, >> >> I am relatively new to Openstack and Keystone so please forgive me any >> crazy misunderstandings here. >> >> One of the problems with the existing LDAP Identity driver that I see >> is that for group management it needs write access to the LDAP server, >> or requires an LDAP admin to set up groups separately. >> >> Neither of these are palatable to some larger users with corporate >> LDAP directories, so I'm interested in discussing a solution that >> would get acceptance from core devs. >> >> My initial thoughts are to create a new driver that would store groups >> and their user memberships in the local keystone database, while >> continuing to rely on LDAP for user authentication. The advantages of >> this would be that the standard UI tools could continue to work for >> group manipulation. This is somewhat parallel with ephemeral >> federated user group mappings, but that's all done in the json blob >> which is a bit horrible. (I'd like to see that working with a decent >> UI some time, perhaps it is solved in the same way) >> > > This has come up numerous times, as I am sure you are now aware by reading > the rest of the thread. > > A couple points; I've been aware of the hybrid driver for several years. > I feel it is a security mistake to copy the users from the system of record > (LDAP) into a cache (Keystone) and then tro only trust the values in the > cache; if I delete or disable a user in LDAP, that should be the state > used, not the cached value. > > Disabled and deleted user cannot bind to the LDAP server.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev