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.
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.
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.
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.
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.