Alexander, Thank you for your support!
John DeSantis Il giorno gio 2 mag 2019 alle ore 16:30 Alexander Bokovoy <aboko...@redhat.com> ha scritto: > > On Thu, 02 May 2019, John Desantis via FreeIPA-users wrote: > >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. > This is (apart from 5 which is obviously something that is specific to > each environment) the right sequence for a typical configuration for > trusted domain users. It is not necessarily primary group that should be > created in IPA -- one can do an ID override for AD group with a GID you > need -- but the fact that AD user's primary group should exist in AD and > some POSIX group in IPA would be used for this external user membership > is the key. > > > > >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 > > -- > / 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
