Well, it depends how the information gets into the Gluu Server. There are a few different interception scripts that might enable you to push information back to AD. But first you need to say exactly where this write to the Gluu database is originating.

@Michael.Schwartz - Thanks for the quick reply. In regards to where this write to Gluu DB is originating, it's currently configured to run a Cache Refresh against Active Directory. So flow is; Active Directory --> Gluu Cache Refresh --> Gluu DB. Since the federated user data is writing into Gluu DB, does that help answer your question at all? Thanks

No... because if AD is the source of the info... why do you need to write back to AD? And why not use the Cache Refresh interception script if it's tied to that event?

@Michael.Schwartz - Understood and the intent was to try and leverage Gluu as an all-in-one IAM platform. Use case is to essentially allow access admins to log into and leverage only Gluu, when creating/updating/de-provisioning users into AD as well as other connected applications, etc. Otherwise, was a little confused per the indication on this page however; https://www.gluu.org/features/identity-management/, because it seems like you can push/pull from Gluu server into AD. But if that's not the case and I misunderstood, then makes more sense now and thanks again for your speedy response. Thanks

Gluu Server offers custom scripts of type "Update user" which should be triggered when user entry is changed in Gluu Server. So it should be possible to write a script that uses LDAP interface of AD to push the changes you do to users in Gluu Server there each time (not sure if it's called on user's removal, worth testing). Combined with Cache Refresh (with addition of another custom scripts that runs during each CR batch) you can also import changes done at AD into Gluu Server. That's just from the top of my head, I'm not aware if somebody actually tried such approach in production. Otherwise, normally it's only one way transfer - from some existing internal LDAP server into Gluu Server. I know that users who needed more advanced management capabilities were writing their own apps which handled it, using SCIM REST API to access Gluu Server's user data.

@Aliaksandr.Samuseu - Thanks for your response. Are there any out-of-the-box type configs/features I can leverage then, without having to write additional scripts? Or perhaps documenation somewhere that depicts how this push/update user process is done back to AD?

No, we don't offer a ready-to-use feature like that. Normally, user data is imported into Gluu Server from external sources, not the opposite. Basically, Gluu Server just aggregates and caches this data internally, to be able to provide seamless SSO experience. To achieve what you want you would need to do some scripting, and still the final solution may be susceptible to data loss and data going out of sync, as the scripts are usually just run once, being hooked to specific event. If anything fails and script either exits or throws exception, whatever changes it failed to push to your AD server are lost (unless you somehow safeguard against it). That turns into architecture discussion, instead of being a specific question about officially supported features at that point, which I think we don't normally engage in under Community Support. May be @Michael.Schwartz still has something to add, or suggest how to handle this ticket.

@Aliaksandr.Samuseu - Thanks for your response and information. I'll look into the possibility leveraging some scripts to meet our use case. Thanks again for your help and if you ever happen to locate any documentation regarding this, please do let me know.