<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_-6699124709016566315h5"><br><div><br></div></div></div><div>I'm surprised any AD administrator let Keystone write to it. I've always hear the inverse that AD admins never would allow keystone to write to it, therefore it was never used for Projects or Assignments. Users were likewise read-only when AD was involved.</div><div><br></div><div>I have seen normal LDAP setups work with Keystone and used in both read/write mode (but even still the write-allowed was the extreme minority).</div></div></div></div></blockquote><div><br></div></span><div>Yes agreed. AD administrators are generally pretty protective of write access. And especially so of some Linux-based open source project writing into their Windows kingdom. We got over our lack of being able to store assignment in LDAP, mainly because the blocker was not Keystone, it was corporate policy.</div><div><br></div></div></div></div></blockquote><div>Neither the admins allow to write to the AD (even though it is not quite true and there were at least 2 projects where writing to AD was allowed (specific groups) and they were Very big customers) nor I mentioned that.</div><div>What was happening all the time is read-only AD with project and assignments Stored in the AD. Which means whenever you need the project and the user has to have access to it - the admin creates the group in AD and adds users to the according groups. It looked not Very transparent (because the roles were stored in the separate group and the assignments were not very clear), but admins could live with that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>As for everything else that's been discussed, I think database replication is easier, and when you're not replicating tokens, there's just not that much traffic across the WAN. It's been very stable for us, especially since we started using Fernet tokens. </div><div> </div></div></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Andrey Grebennikov<div>Principal Deployment Engineer</div><div>Mirantis Inc, Austin TX</div></div></div></div></div>
</div></div>