<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"><div><div class="h5"><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><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>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>