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 <[email protected]> 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 > <[email protected]> ha scritto: > > > > Alexander, > > > > Thank you for your support! > > > > John DeSantis > > > > Il giorno gio 2 mag 2019 alle ore 16:30 Alexander Bokovoy > > <[email protected]> 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' > > > >> [email protected] --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 > > > >[email protected]. 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 > > > >[email protected]) 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 <[email protected]> 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' > > > >> [email protected] --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 -- [email protected] > > > >> To unsubscribe send an email to > > > >> [email protected] > > > >> 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/[email protected] > > > >_______________________________________________ > > > >FreeIPA-users mailing list -- [email protected] > > > >To unsubscribe send an email to > > > >[email protected] > > > >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/[email protected] > > > > > > -- > > > / Alexander Bokovoy > > > Sr. Principal Software Engineer > > > Security / Identity Management Engineering > > > Red Hat Limited, Finland _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
