Hi, if you are comfortable with 389-ds access log, you can check which search rundeck is performing and try to reproduce manually. I would start with the working one: in /var/log/dirsrv/slapd-MY-DOMAIN-DOM/access, look for a line showing the operations done with the working user uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com (look for a line containing *BIND dn="uid=$userID"*, for instance:
# grep 'BIND dn="uid=testuser' /var/log/dirsrv/slapd-IPA-TEST/access [09/May/2023:14:02:19.721498412 +0000] *conn=58634* op=0 BIND dn="uid=test user,cn=users,cn=accounts,dc=ipa,dc=test" method=128 version=3 Note the *conn* number and try to find all the operations performed with this connection: # grep conn=58634 /var/log/dirsrv/slapd-IPA-TEST/access [09/May/2023:14:02:19.702570402 +0000] conn=58634 fd=162 slot=162 SSL connection from 10.0.144.249 to 10.0.144.249 [09/May/2023:14:02:19.709587570 +0000] conn=58634 TLS1.3 128-bit AES-GCM [09/May/2023:14:02:19.721498412 +0000] conn=58634 op=0 BIND dn="uid=testuser,cn=users,cn=accounts,dc=ipa,dc=test" method=128 version=3 [09/May/2023:14:02:19.742183857 +0000] conn=58634 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.015180938 optime=0.020691034 etime=0.035869230 dn="uid=testuser,cn=users,cn=accounts,dc=ipa,dc=test" *[09/May/2023:14:02:19.742532170 +0000] conn=58634 op=1 SRCH base="cn=groups,cn=compat,dc=ipa,dc=test" scope=2 filter="(objectClass=posixgroup)" attrs="memberUid"* [09/May/2023:14:02:19.757048401 +0000] conn=58634 op=1 RESULT err=0 tag=101 *nentries=26* wtime=0.000154146 optime=0.014517504 etime=0.014669869 [09/May/2023:14:02:19.757131659 +0000] conn=58634 op=2 UNBIND [09/May/2023:14:02:19.763351173 +0000] conn=58634 op=2 fd=162 closed error - U1 In my example I can see that there was a SEARCH with base *cn=groups,cn=compat,dc=ipa,dc=test*, scope=2 (meaning sub) and filter (objectClass=posixgroup), that asked for the attribute memberuid and found 26 entries. Once you identify the exact operations it should be easier to understand which ACIs apply and prevent from finding the groups. HTH, flo On Tue, May 9, 2023 at 4:21 PM Jeff Goddard <[email protected]> wrote: > 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
