<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 24, 2015 at 12:02 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/24/2015 12:00 AM, Julian Edwards wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I am relatively new to Openstack and Keystone so please forgive me any<br>
crazy misunderstandings here.<br>
<br>
One of the problems with the existing LDAP Identity driver that I see<br>
is that for group management it needs write access to the LDAP server,<br>
or requires an LDAP admin to set up groups separately.<br>
<br>
Neither of these are palatable to some larger users with corporate<br>
LDAP directories, so I'm interested in discussing a solution that<br>
would get acceptance from core devs.<br>
<br>
My initial thoughts are to create a new driver that would store groups<br>
and their user memberships in the local keystone database, while<br>
continuing to rely on LDAP for user authentication. The advantages of<br>
this would be that the standard UI tools could continue to work for<br>
group manipulation.  This is somewhat parallel with ephemeral<br>
federated user group mappings, but that's all done in the json blob<br>
which is a bit horrible. (I'd like to see that working with a decent<br>
UI some time, perhaps it is solved in the same way)<br>
</blockquote>
<br></span>
This has come up numerous times, as I am sure you are now aware by reading the rest of the thread.<br>
<br>
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.<br><br></blockquote><div><br></div><div>Disabled and deleted user cannot bind to the LDAP server.</div></div><br></div></div>