Not that I can see: Permission name: System: Read Group Compat Tree Granted rights: read, compare, search Effective attributes: cn, createtimestamp, entryusn, gidnumber, memberuid, modifytimestamp, objectclass Default attributes: objectclass, memberuid, gidnumber, cn Bind rule type: anonymous Subtree: dc=my,dc=domain,dc=com Target DN: cn=groups,cn=compat,dc=my,dc=domain,dc=com Permission flags: V2, MANAGED, SYSTEM
Jeff On Tue, May 9, 2023 at 10:14 AM Florence Blanc-Renaud <[email protected]> wrote: > Hi, > > on a standard installation, the compat tree groups should be readable by > anyone thanks to the permissions "System: Read Group Compat Tree". > # ipa permission-show "System: Read Group Compat Tree" > Permission name: System: Read Group Compat Tree > Granted rights: read, search, compare > Effective attributes: cn, createtimestamp, entryusn, gidnumber, > memberuid, modifytimestamp, objectclass > Default attributes: memberuid, gidnumber, objectclass, cn > Bind rule type: anonymous > Subtree: dc=ipa,dc=test > Target DN: cn=groups,cn=compat,dc=ipa,dc=test > Permission flags: SYSTEM, V2, MANAGED > > Was this permission modified on your system? > > flo > > On Tue, May 9, 2023 at 2:57 PM Jeff Goddard <[email protected]> wrote: > >> >> Flo, >> >> Thank you for giving me a pointer. It helped me better design a test >> scenario where I now can get success but I'm still looking to improve >> things. Our lookup configuration uses a system account. If I make the >> changes you suggest, I still see errors/no populated user groups. However >> if I switch the lookup user DN in the config to a "regular" user DN and >> have the groups lookups configured to use the compat tree, I now populate >> groups as expected. Does this mean I have an access permissions issue with >> my service account? Do you have any suggestions on how I can get the >> service account to work again? >> >> Non-working lookup DN config snippets: >> bindDn="uid=$system_account,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com" >> bindPassword="$password" >> >> Working lookup DN config snippets: >> bindDn="uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com" >> bindPassword="$password" >> >> In both cases above this is used as the group DN: >> roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com >> >> Your assistance is greatly appreciated, >> >> Jeff >> >> >> >> >> >> On Tue, May 9, 2023 at 3:32 AM Florence Blanc-Renaud <[email protected]> >> wrote: >> >>> Hi, >>> I am not familiar with rundeck but from the provided configuration, the >>> application is using the *memberUid* attribute. IPA stores its groups >>> with the member attribute, not memberUid, unless you are using the compat >>> tree. The compat tree is stored below cn=compat,$BASEDN and provides a >>> virtual view following RFC 2307 instead of RFC 2307bis. For instance: >>> *IPA group entry* >>> $ ldapsearch -LLL -o ldif-wrap=no -D cn=directory\ manager -w $PASSWORD >>> -b cn=mygroup,cn=groups,*cn=accounts*,dc=ipa,dc=test >>> dn: cn=mygroup,cn=groups,cn=accounts,dc=ipa,dc=test >>> cn: mygroup >>> objectClass: top >>> objectClass: nestedgroup >>> objectClass: ipausergroup >>> objectClass: ipaobject >>> objectClass: groupofnames >>> objectClass: posixgroup >>> objectClass: ipantgroupattrs >>> ipaUniqueID: ff523b2a-ee38-11ed-8374-fa163eaf69aa >>> gidNumber: 205400095 >>> ipaNTSecurityIdentifier: S-1-5-21-1166032515-3431855665-2561613534-1095 >>> *member: uid=idmuser,cn=users,cn=accounts,dc=ipa,dc=test* >>> >>> *IPA Group entry in the compat tree* >>> $ ldapsearch -LLL -o ldif-wrap=no -D cn=directory\ manager -w $PASSWORD >>> -b cn=mygroup,cn=groups,*cn=compat*,dc=ipa,dc=test >>> dn: cn=mygroup,cn=groups,cn=compat,dc=ipa,dc=test >>> objectClass: posixGroup >>> objectClass: ipaOverrideTarget >>> objectClass: ipaexternalgroup >>> objectClass: top >>> gidNumber: 205400095 >>> *memberUid: idmuser* >>> ipaAnchorUUID:: >>> OklQQTppcGEudGVzdDpmZjUyM2IyYS1lZTM4LTExZWQtODM3NC1mYTE2M2VhZjY5YWE= >>> cn: mygroup >>> >>> There were some changes in the compat tree with slapi-nis-0.60.0-1 that >>> may explain the different behavior. You can try to use the compat tree for >>> the groups (replace >>> *roleBaseDn="cn=groups,cn=accounts,dc=my,dc=domain,dc=com"* with >>> *roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com"*) to make sure >>> the right schema is used. >>> >>> flo >>> >>> On Mon, May 8, 2023 at 3:06 PM Jeff Goddard via FreeIPA-users < >>> [email protected]> wrote: >>> >>>> Hello and thank you for providing such a useful product. >>>> >>>> >>>> We recently used yum to update our freeipa infrastructure and >>>> everything went off without a hitch with the exception of one of our >>>> integrated apps which now cannot determine group membership. We know the >>>> lookup is successful as the user can login but we use group-based ACLs >>>> from freeipa and when the groups are not populated, the users cannot access >>>> the rundeck jobs. Nothing on rundeck was changed, the only actions taken >>>> were "yum update" and "yum upgrade" on the freeipa servers. I've reviewed >>>> the configurations and done some troubleshooting but can't find an answer >>>> so I'm reaching out in hopes someone can give me a clue. >>>> >>>> Environment details: >>>> >>>> Server: CentOS Linux release 7.9.2009 (Core) >>>> Freeipa version: 4.6.8-5.el7.centos.12 >>>> Problematic app: Rundeck >>>> >>>> Update logs are attached as is the application ladp lookup config and >>>> application login error. Any help is greatly appreciated. >>>> >>>> Jeff >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> FreeIPA-users mailing list -- [email protected] >>>> To unsubscribe send an email to >>>> [email protected] >>>> Fedora Code of Conduct: >>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List Archives: >>>> https://lists.fedorahosted.org/archives/list/[email protected] >>>> Do not reply to spam, report it: >>>> https://pagure.io/fedora-infrastructure/new_issue >>>> >>> >> >> >>
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
