Alexander,
Thank you for your support!
John DeSantis
Il giorno gio 2 mag 2019 alle ore 16:30 Alexander Bokovoy
<abokovoy(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.fedorahosted.org
> >> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> >_______________________________________________
> >FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> >To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland