Alexander, Apologies for the delay in responding. Our A.D. admins have been quite busy.
> Can you remove it from IPA and add > > ipa idoverridegroup-add 'Default Trust View' adglobalposixgroup@ad.domain > --gid 10001 > > after you added adglobalposixgroup in AD? Alright, this was done and the caches were cleared (client and server). I was able to add the override as listed above, but at first it seemed to have made the issue worse than before, because the same set of testing was failing more often than not. At some point, all lookups were failing. But, after removing "ldap_id_mapping" from sssd.conf on the client (which I had added for testing, grasping at straws) I was able to resolve users again. After looking at the logs on the server side, I saw additional entries that I hadn't seen before - the list of users in question were also being resolved against the adglobalposixgroup@ad.domain. However, the client side still reported multiple failures per user, _except_ for those that had already been added as external members to a testing group. This was the culprit, at least in my case. Once I added the external users to a local group (unrelated to adglobalposixgroup@ad.domain) and reset the caches (server and client, just to rule out cached entries), I was able to resolve the users all on the first try! There was a slight delay (a few seconds), but that's it. From all of the documentation that I have read, not once am I able to recall that external users needed to be added first for "immediate" results from a user look-up on a client. The client log entries no longer manifest the "Cannot find SID of object." message as before. So, it does appear that the addition of the group on the A.D. side corrected that. I don't know if the idoverride for the group really did anything or not, but I will test further with clean caches on both IPA servers and the client. The sequence of steps that I performed which produced positive results were the following: 1.) Created external group labelled "adglobalposixgroup_external". 2.) Create IPA group labelled "adglobalposixgroup" with gid 10001. 3.) Added "adglobalposixgroup_external" to "adglobalposixgroup". 4.) Added list of users as external members to "adglobalposixgroup_external". 5.) Reset caches as described above. I'll continue to perform some additional testing and client tuning, but for anyone else that is following this thread I hope this information is useful. Thanks, John DeSantis Il giorno lun 29 apr 2019 alle ore 15:37 Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.org> ha scritto: > > On ma, 29 huhti 2019, John Desantis wrote: > >Alexander, > > > >Thanks for your continued support. > > > >> I'm not saying about that at all. > >> > >> Can you show output of > >> > >> ipa group-show --all --raw adglobalposixgroup > > > >Sure thing! > > > >PROD:15:13:34-root@ipaserver1:~ > ># ipa group-show --all --raw adglobalposixgroup > > dn: cn=adglobalposixgroup,cn=groups,cn=accounts,dc=ipa,dc=domain,dc=com > > cn: adglobalposixgroup > > gidnumber: 10001 > > ipaUniqueID: 5f5745b4-6a9f-11e9-8213-d4ae52a0e39d > > objectClass: top > > objectClass: groupofnames > > objectClass: nestedgroup > > objectClass: ipausergroup > > objectClass: ipaobject > > objectClass: posixgroup > > > >> From your explanation adglobalposixgroup is not a normal group in IPA. > >> Otherwise, sidgen plugin wouldn't have those issues. This is what I'm > >> pointing out -- having a split-brain situation is not expected and not > >> supported by SSSD in this way. "This way" - how we understood your > >> situation from your description above. > > > >To clarify, the "adglobalposixgroup" has a GID that is supplied via > >AD, it's configured as the GID 10001. > > > >When the trust was initially created, I was able to `getent passwd` > >and `id` users, but I received an error message stating that "10001 > >could not be found". That's the reason that I created it in IPA. > Understood. > > My understanding that the group should exist in AD. It doesn't need to > be POSIX there. You can add POSIX attributes for it in the 'Default > Trust View' as a group override, but the group itself has to exist in > AD. > > Can you remove it from IPA and add > > ipa idoverridegroup-add 'Default Trust View' adglobalposixgroup@ad.domain > --gid 10001 > > after you added adglobalposixgroup in AD? > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
