Hi, Matt. The only thing that comes to mind is to try to enforce this logic from a custom Cache Refresh script. I.e., to code in such way that after user entry is created, it's also added to the admins group. I can't say for sure at the moment whether it's possible (it may be that CR scripts end their execution before user is created, just passing the responsibility to add formed user object to the main code etc), and we also don't usually provide support for custom scripts' development to community users. Unless you consider paying for a support plan, or develop the script yourself, there is hardly a way to achieve what you need.

right now we are evaluating gluu. I believe it is the front runner for our IDM needs but we need to set it up correctly and get our organization completely supported to know this is where our future lies. Can you point me to any documentation about custom cache refresh scripts?

>Can you point me to any documentation about custom cache refresh scripts? There is [brief doc](https://gluu.org/docs/ce/3.1.1/authn-guide/customauthn/) describing general outlining of authentication custom scripts, which is good to get familiarized with the core idea of it. CR's custom script works essentially in the same way, it's also sort of a hook into the usual execution flow, though API interfaces available for different script types may differ, and objects passed to them by default will differ most surely. You also can check the example custom CR script which comes pre-packaged with your Gluu instance (just make sure you don't enable it if you have CR enabled and configured, as it has potential to meddle with your user entries too much, unless you are sure you understand what it can do). Aside from that, there is not that much. The whole codebase for web UI (CR is part of it) can be accessed [here](https://github.com/GluuFederation/oxTrust) so you can study for yourself composition of each object and what other methods are exposed by different functional /system classes. If I'll manage to free some time this week, I'll try to have a look into what currently CR script may achieve, but can't promise any ETA here.. Developing a custom script is considered an advanced topic and it's expected you have staff who can handle it unless you have a support contract which covers our involvement in such tasks.

Thank you. your answer was somewhat helpful. I found the cache refresh script under Manage Scripts. I edited to default ALL users to the same organization (see below). I also removed all the munging. My cache refresh has run several times since then but each time, I check the user in the local user search in gluu and it seems that the users are not being updated. Additionally, I don't see my script ever running in any logs (I'm assuming it would be in /opt/gluu/jetty/identity/logs/oxtrust_cache_refresh_python.log?). Is this because the user is already in ldap and nothing changed on the source? I tried deleting a user and waiting to see the user recreated on next refresh. It has run twice and I have not seen my user recreated. Is there a way to clear the user cache and forcing a full refresh? Also I noticed while waiting my 5 minutes it seems the refresh doesn't actually run on my interval. At this point, it has ben 19 minutes and still waiting on may latest refresh which is supposed to be on a 5 minute interval. ``` # Update user entry before persist it # user is org.gluu.oxtrust.model.GluuCustomPerson # configurationAttributes is java.util.Map<String, SimpleCustomProperty> # # myoung - updated to add tenant def updateUser(self, user, configurationAttributes): print "Cache refresh. UpdateUser method" attributes = user.getCustomAttributes() # Add new attribute preferredLanguage attrPrefferedLanguage = GluuCustomAttribute("preferredLanguage", "en-us") attributes.add(attrPrefferedLanguage) # Add new attribute userPassword #attrUserPassword = GluuCustomAttribute("userPassword", "test") #attributes.add(attrUserPassword) attrUserTenant = GluuCustomAttribute("Organization", "Company1") attributes.add(attrUserPassword) print "checking memberOf" # Update givenName attribute #for attribute in attributes: # attrName = attribute.getName() # if (("givenname" == StringHelper.toLowerCase(attrName)) and StringHelper.isNotEmpty(attribute.getValue())): # attribute.setValue(StringHelper.removeMultipleSpaces(attribute.getValue()) + " (updated)") return True ```

Hi, Matt. FYI: I've done some studies of current code, and it looks like it what you need can be achieved. It won't be as simple as "add any user from backend's admins to Gluu's Managers", of course, more like "parse the list of provided attributes, find the membership attribute, check whether there is certain pattern in its value, and if it's there add this user to Managers group". But it should work. Though, as mentioned, developing custom scripts is not covered by Community support. >I edited to default ALL users to the same organization (see below). I also removed all the munging. My cache refresh has run several times since then but each time, I check the user in the local user search in gluu and it seems that the users are not being updated There are some peculiarities with CR. If cached entries for those users had been already created by CR before you enabled your script (like, you first enabled CR, then added script after some time), they won't be updated until they will be changed in backend next time. CR uses checksums of sets of attributes it receives at each pulling from backend to figure out whether it needs to further act on this user. If there are no changes it skips that user. A good way to trigger complete update is to flush contents of its working directory (please check its main tab in web UI for the actual path to it) >Is there a way to clear the user cache and forcing a full refresh? The method described above will only clean CR's current snapshot data, thus from its perspective all users in backend will suddenly become changed and it will try to update all their cached entries in internal LDAP. If you need to completely flush it, removing all cached entries, there is no obvious way to do it currently. A couple workarounds for it: 1. Temporarily change baseDN CR uses at your backend to some DN with zero users under it. From CR's perspective it will look like all users were deleted in backend, and it will proceed with removing them from local cache. Then you can point it back to previous baseDN 2. Remove the cached entries manually. The process is somewhat obscure. May be we should actually put it in a separate doc, thanks for asking. >Additionally, I don't see my script ever running in any logs (I'm assuming it would be in /opt/gluu/jetty/identity/logs/oxtrust_cache_refresh_python.log? It's `oxtrust_script.log`, all outputs should be there. >Also I noticed while waiting my 5 minutes it seems the refresh doesn't actually run on my interval. At this point, it has ben 19 minutes and still waiting on may latest refresh which is supposed to be on a 5 minute interval. Not sure what could cause it. Are you checking its progress in `oxtrust_cache_refresh.log`, correct?

What conditions need to be met (what groups or custom attributes) would be required to allow an authenticated user to be recognized as an admin?

Hi, Matt. >What conditions need to be met (what groups or custom attributes) would be required to allow an authenticated user to be recognized as an admin? It must be a valid user entry (not conflicting with schema and having all required attributes) and it must be a member of "Gluu Manager Group".