All,
Just a head's up for users that land on this thread.
Make sure that you do not create any groups whose names are actual AD
usernames, i.e. "amber12" and "amber12". If you do, client look-ups
will stall and fail.
As a result of this find, we'll make sure to add a prefix/suffix to
the group name moving forward!
Thanks,
John DeSantis
Il giorno ven 3 mag 2019 alle ore 08:51 John Desantis
<desantis(a)mail.usf.edu> ha scritto:
>
> 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