All,
A final head's up for users that land on this thread.
I was able to reduce all outstanding latency after realizing via debug
logs that I had inadvertently created a "loop" of sorts via HBAC
rules.
The "loop" was caused by an HBAC rule which included both the POSIX
group and its externally mapped group, e.g. "posixgroup" and
"posixgroup_external". By having removed the "posixgroup_external"
group via `ipa hbacrule-remove-user RULE --group=posixgroup_external`
(thereby only leaving "posixgroup"), all noticeable latencies
disappeared.
The clue was in the sssd_nss logs: "Received [n] groups in group list
from IPA Server". Each user had the group in question duplicated,
despite belonging to several other POSIX to externally mapped groups -
which weren't duplicated.
HTH,
John DeSantis
Il giorno ven 24 mag 2019 alle ore 14:58 John Desantis
<desantis(a)mail.usf.edu> ha scritto:
>
> 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