Forgeops AM Group Delegation


I have a running version of ForgeOps that I created groups / assigned users (admins) then delegated those groups in AM console to allow for administration. But, for some reason (did not change anything) AM is not picking up the group memberships now. When i look at identities in the AM console, I can see the groups / users, but when I look at a user am not seeing the groups assigned to that user. I can look at the group and shows the list of members (via fr-idm-uuid) but for some reason is not showign the user as a member when logging in. Anyone seen this issue? In the past, I had to restart idrepo / cts and resolved but did that and still not showing.


I may be misunderstanding the issue, but it sounds like you are stating that the configurations for delegated administration of AM are not being picked up via ForgeOps. You’ve created a group or groups and assigned those groups as delegated admins in AM and saved off your configs, but when you re-deploy AM those users are not actually admins in AM. Is that correct? Or is it just that AM is not recognizing the users as being members of the groups?

If it’s the former, last I checked the delegated administration configuration is not something managed via Amster which would explain why a re-deploy doesn’t pick up the changes. If it is the latter, that is something a little different but I bet we can troubleshoot it.

If you can let me know which interpretation of the scenario is correct I think we can move forward from there.

The second part is what is happening. When I go look at a user, I do not see the group membership, but when I look at a group I see the membership. This was working until not too long ago and has happened in the past and just had to reset / clear sessions in CTS but cannot get it to pick up the group membership again this time (also, I did upgrade to 7.4 latest recently so not sure if that changed / impacted things).


If you look at the user and don’t see the group but you look at the group and do see it, the issue is possibly with AM not being configured to read the attribute on the user object that denotes the group membership.
I’m assuming that when you look at the user via an LDAP browser the group memberships look correct - is that accurate? If so, double check the Identity Store configuration and confirm that you have the correct attribute name in the LDAP User Attributes list. If that attribute name is not listed, AM won’t request it during a read and that would explain the lack of groups being shown. If the group does not show up on the user object using an LDAP browser (after fetching operational attributes) the issue could possibly be with the sync between IDM and your identity store.

1 Like

Yeah, the user / group configuration is there (and matches another environment I have) so think that is correct, was wondering if there is an entry-cache in DS that is not firing / got corrupted and needs to be cleared.

Have you taken a look at the DS logs during the read operation to confirm that the request includes the expected attribute? The full list of queried attributes should be included in the log entry. After you confirm that you should be able to replicate the query yourself using the same account and filter to see if the results are what you’d expect.

Just to confirm - you are not seeing any group memberships for the users when you view them in AM, correct? And you can see that the user is a member of the group when you view the user in DS, correct? It’s not that I don’t trust the IDM UI for that piece of the investigation, but it is a step removed from the source.

Yeah, looked in the ds logs and not seeing any errors, also not really seeing the queries coming in for the user on login.

Yes, when I look at the user in AM I am not seeing group membership. But, when I look at the group I see the member fr-idm-uuid list for the users.


Hi @nick.hunt,

Can you check this is what you see in the id Repo:

  • Check the Group is created in DS with the proper setting. In my idRepo:

dn: cn=Group1,ou=groups,ou=identities
objectClass: top
objectClass: groupOfURLs
objectClass: fr-idm-managed-group
cn: Group1
description: Group1
fr-idm-managed-group-json: {“name”:“Group1”}
memberURL: ldap:///ou=people,ou=identities??sub?fr-idm-effectiveGroup:caseIgnoreJsonQueryMatch:=_refResourceId eq “Group1”

  • Check the user is assigned the group

dn: fr-idm-uuid=199471fe-d8a6-4ed8-a9a5-ff74ff73ed0a,ou=people,ou=identities
fr-idm-effectiveGroup: {“_refResourceCollection”:“managed/group”,“_refResourceId”:“Group1”,“_ref”:“managed/group/Group1”}
isMemberOf: cn=Group1,ou=groups,ou=identities

Which forgeops version are you using, and which sequence are you using to create user, group, and assign the group?


1 Like

Hey @patrick_diligent I confirmed that the group has the info and the user has the mapping for the fr-idm-effectiveGroup (see below). But, what I do not see / is not returning is the isMemberOf for the membership.

User Attribute
fr-idm-effectiveGroup: {"_refResourceCollection":"managed/group","_refResour ceId":"AMAdmins","_ref":"managed/group/AMAdmins"}

Group attributes
dn: cn=AMAdmins,ou=groups,ou=identities objectClass: fr-idm-managed-group objectClass: groupOfURLs objectClass: top cn: AMAdmins description: This is for delegated administration in AM fr-idm-managed-group-json: {"name":"AMAdmins"} memberURL: ldap:///ou=people,ou=identities??sub?fr-idm-effectiveGroup:caseIg noreJsonQueryMatch:=_refResourceId eq "AMAdmins"

I’m now using 7.4 of forgeops but was using 7.3 and had the same issue.


Hi @nick.hunt,

I use both 7.4 and 7.5, that issue does not show up for me (MacOs/minikube). Regarding the presence of ‘isMemberOf’, are you requesting operational attributes? they’re not returned by default.
If it’s still not showing, then you might consider there’s some issue with the DS backend, perhaps, so try to destroy the volume and start over with a clean sheet?


Yeah, I requested it via ldapBrowser and is returning empty. Was wondering if there is an entry cache or something I can clear since seems to happen periodically. Yeah, I am running 7.3 / 7.4 / 7.5 in different clusters and the other ones (same setup) work as expected so not sure what is causing this one to not pick it up.

Also, can’t really clear the ds data / start fresh since I have a lot of data in this instance (is my main dev) so don’t want to lose the clients / info if I can avoid it.

Ok, definitely confirmed is the isMemberOf attribute in DS. Just did a search of another instance and isMemberOf is returned like it should. So, now need to figure out why isMemberOf is not running. Checked in dsconfig and is all there, might need to do some restarts again…

Restarts did not help, checked groups, references, etc. and all look to be what should be. Any other suggestions on what to rebuild / clear in DS (other than all the data)?

Ok, so to close the loop on this, I deleted the group / recreated it with the same name and is now showing in the isMemberOf (and AM picked it back up since is name based on privileges). So, not sure what caused it, but was a cache / entry somewhere that was hung and recreating it fixed the issue.

1 Like

I believe that might have to do with the DN cache, which relies on persistent searches - as far as I remember, persistent searches do not trigger on operational attribute changes - so not sure how the whole thing is implemented… Next time, if this happens again, try to change any non operational attribute and see wether AM gets correctly updated.

1 Like