Hi, thanks for confirming, and glad you got it working! flo On Wed, May 10, 2023 at 4:46 PM Jeff Goddard <[email protected]> wrote:
> Flo, > > I must have made multiple edits before posting last about still > seeing issues. HAving parsed the rundeck config file again, and setting the > appropriate values as suggested, I'm now getting the group membership > information included in the lookups while still using my service account. > > Thank you very much for you time and assistance, > > Jeff > > On Tue, May 9, 2023 at 10:38 AM Florence Blanc-Renaud <[email protected]> > wrote: > >> 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=testuser,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
