Alexander, > >Yes, the group was created within the IPA domain via the cli, and this > >error is only manifest in the client log. However, the GID of the > >group (10001) is supplied via the AD trust using the POSIX range. > That isn't going to work at all. > > For IPA groups POSIX IDs should be in IPA LDAP. You cannot have a > non-POSIX group in IPA and POSIX ID supplied from AD LDAP.
Alright. So, do you recommend deleting the trust and re-creating it without "--range-type=ipa-ad-trust-posix"? What I don't completely follow is that why would the servers not manifest this behaviour despite having the same trust settings? Thanks, John DeSantis Il giorno lun 29 apr 2019 alle ore 14:12 Alexander Bokovoy <aboko...@redhat.com> ha scritto: > > On ma, 29 huhti 2019, John Desantis via FreeIPA-users wrote: > >Sumit, > > > >Thanks for your reply. > > > >> According to the logs you send there is an error during the first > >> lookup when lookup up the group adglobalposixgroup: > >> Is this really a group from the IPA domain? If yes and the SID is really > >> missing (you can check with 'ipa group-show --all adglobalposixgroup) you > >> might > >> need the re-run the sidgen task to assign a SID.] has no SID, please check > >> the ipaNTSecurityIdentifier attribute on the server-side. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_save_step] (0x0040): > >> ipa_s2n_save_objects failed. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_next] (0x0040): > >> ipa_s2n_get_list_save_step failed. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_done] (0x0040): s2n > >> get_fqlist request failed. > >> > >> Is this really a group from the IPA domain? If yes and the SID is really > >> missing (you can check with 'ipa group-show --all adglobalposixgroup) you > >> might > >> need the re-run the sidgen task to assign a SID. > > > >Yes, the group was created within the IPA domain via the cli, and this > >error is only manifest in the client log. However, the GID of the > >group (10001) is supplied via the AD trust using the POSIX range. > That isn't going to work at all. > > For IPA groups POSIX IDs should be in IPA LDAP. You cannot have a > non-POSIX group in IPA and POSIX ID supplied from AD LDAP. > > > >Just to rule out any interference, I went ahead and removed the group. > >Once I did that, I was no longer able to resolve any AD user on the > >client in question (the IPA servers still had no issue). And, when I > >re-added the group using its specified GID of 10001, I was able to > >again resolve the users (with latency) on the client. > > > >However, since this is a new lead, here is what I found in the slapd logs: > > > >errors:[03/Apr/2019:11:23:22.941060612 -0400] - ERR - > >find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot > >convert Posix ID [10001] into an unused SID. > >errors:[03/Apr/2019:11:23:23.015868654 -0400] - ERR - > >ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID > >to new entry. > >errors:[04/Apr/2019:14:41:01.760929261 -0400] - ERR - > >find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 514]: > >Inconsistent objectclasses and attributes, nothing to do. > >errors:[05/Apr/2019:11:43:24.912535009 -0400] - ERR - > >find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot > >convert Posix ID [1839611] into an unused SID. > >errors:[05/Apr/2019:11:43:24.931834879 -0400] - ERR - > >ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID > >to new entry. > >errors:[29/Apr/2019:12:22:00.486070625 -0400] - ERR - > >ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 128]: Missing target > >entry. > >errors:[29/Apr/2019:12:22:05.005693122 -0400] - ERR - > >find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot > >convert Posix ID [10001] into an unused SID. > >errors:[29/Apr/2019:12:22:05.025295150 -0400] - ERR - > >ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID > >to new entry. > > > >These time stamps all correlate when I created the group, changed an > >override on the user, or deleted the group. > > > >I looked at the URL's > >https://www.redhat.com/archives/freeipa-users/2017-February/msg00114.html > >and https://bugzilla.redhat.com/show_bug.cgi?id=1305533, but none of > >the suggestions functioned; I tried adding an extra ID range to > >potentially cover the GID in question (since it was supplied from AD), > >but there was no effect. I also cannot delete it now since it's > >associated with the trusted domain (I'm sure it's innocuous though). > > > >> Can you send the sssd.conf from the IPA server and client used to generate > >> the > >> debug logs (or the current version) as well? > > > >Please find them attached. Currently, they both do function with the > >IPA server sssd.conf returning results immediately, while the client > >requires the population of the negative cache prior to returning a > >result. > > > >Thanks for your help so far! > > > >John DeSantis > > > > > >Il giorno lun 29 apr 2019 alle ore 05:37 Sumit Bose via FreeIPA-users > ><freeipa-users@lists.fedorahosted.org> ha scritto: > >> > >> On Thu, Apr 25, 2019 at 01:05:52PM -0400, John Desantis via FreeIPA-users > >> wrote: > >> > Hello all, > >> > > >> > So, for anyone following this thread, I've been able to make some > >> > progress but not enough to consider the configuration production > >> > ready. > >> > > >> > After watching sssd logs ([domain] debug_level = 10, [sssd] > >> > debug_level = 10, and [nss] debug_level = 10) on both the client and > >> > server, I am able to reduce by ~50% the time required and failures of > >> > user look-ups via `getent passwd` and `id` by configuring the [nss] > >> > option 'entry_negative_timeout = 1'. > >> > >> Hi, > >> > >> this option controls how long a "failed" lookup will be cached, The > >> default is 15s which means that in your case when the first lookup fails > >> SSSD will reply to every request for the same user during the next 15s > >> with "User does not exists" and will not try to get fresh data from the > >> IPA server. Making this value shorter allows you trigger a new request > >> to the IPA server earlier and hopefully also have a proper result > >> earlier. But it might also cause more unneeded request to the IPA server > >> for users or groups which really do not exist. So I would not recommend > >> to lower this value. > >> > >> According to the logs you send there is an error during the first > >> lookup when lookup up the group adglobalposixgroup: > >> > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_save_objects] (0x0020): Cannot find > >> SID of object. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_save_objects] (0x0020): Object > >> [adglobalposixgr...@ipa.domain.com] has no SID, please check the > >> ipaNTSecurityIdentifier attribute on the server-side. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_save_step] (0x0040): > >> ipa_s2n_save_objects failed. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_next] (0x0040): > >> ipa_s2n_get_list_save_step failed. > >> /var/log/sssd/sssd_ipa.domain.com.log:(Mon Apr 22 10:58:36 2019) > >> [sssd[be[ipa.domain.com]]] [ipa_s2n_get_list_done] (0x0040): s2n > >> get_fqlist request failed. > >> > >> Is this really a group from the IPA domain? If yes and the SID is really > >> missing (you can check with 'ipa group-show --all adglobalposixgroup) you > >> might > >> need the re-run the sidgen task to assign a SID. > >> > >> Can you send the sssd.conf from the IPA server and client used to generate > >> the > >> debug logs (or the current version) as well? > >> > >> bye, > >> Sumit > >> > >> > > >> > No matter what other options are configured on the client via sssd, > >> > the first look-up always fails. The server logs do not indicate that > >> > the client checked the server's sssd cache on the first look-up. Only > >> > after a negative entry has been introduced and then purged will a > >> > "true" client look-up receive a result. I cannot understand why this > >> > does not happen on the IPA servers with a default sssd configuration, > >> > but happens continually on a client's generated sssd configuration via > >> > the IPA installer. Even after removing the additional trusted domains > >> > and their ID ranges, the behaviour remains. > >> > > >> > In order to rule out the hardware on the client and an older sssd > >> > version (1.15.2), I installed on new hardware and with the latest sssd > >> > version offered via our satellite server (1.16.2), and the behavior > >> > was the same. > >> > > >> > Why is the first user lookup-up on the native IPA client failing to > >> > retrieve the entry that is properly cached on the IPA server? > >> > > >> > Thanks, > >> > John DeSantis > >> > > >> > > >> > Il giorno mer 24 apr 2019 alle ore 08:42 John Desantis > >> > <desan...@mail.usf.edu> ha scritto: > >> > > > >> > > Hello all, > >> > > > >> > > Doh! I realized that I hadn't actually attached the logs; so much > >> > > for trouble-shooting! > >> > > > >> > > Thanks, > >> > > John DeSantis > >> > > > >> > > Il giorno lun 22 apr 2019 alle ore 13:07 John Desantis > >> > > <desan...@mail.usf.edu> ha scritto: > >> > > > > >> > > > Hello all, > >> > > > > >> > > > I've pretty much exhausted my searching in order to find a solution > >> > > > to > >> > > > a problem I've been working on for about a week now, and now I find > >> > > > myself grasping at straws. > >> > > > > >> > > > Basically, AD trust user lookups on IPA clients fail several times in > >> > > > a row before finally returning results (after 8-20 seconds). > >> > > > However, > >> > > > this does not happen on the IPA servers - even after clearing caches. > >> > > > Furthermore, querying the same list of users against a non IPA Linux > >> > > > client that connects directly to our AD domain using nslcd has no > >> > > > issues querying the same list of users. > >> > > > > >> > > > From what I understand regarding the anatomy of the FreeIPA - AD > >> > > > Trust > >> > > > relationship, the FreeIPA servers' sssd caches are queried first by > >> > > > FreeIPA clients and if there is no result, then the FreeIPA server > >> > > > queries the AD domain controllers, receives results, caches them, and > >> > > > then provides the results to the FreeIPA client. > >> > > > > >> > > > I've tried adjusting the sssd.conf file on both the server and the > >> > > > client, without any expected results: > >> > > > > >> > > > ignore_group_members = True > >> > > > ldap_purge_cache_timeout = (various values) > >> > > > memcache_timeout = (various values) > >> > > > cache_first = (various values) > >> > > > ldap_opt_timeout = (various values) > >> > > > ldap_search_timeout = (various values) > >> > > > > >> > > > The trust was established using the range type of > >> > > > "ipa-ad-trust-posix" > >> > > > since each user has a unique Posix UID and a shared unique Posix GID > >> > > > (no AD groups are returned). > >> > > > > >> > > > I've attached logs (dirsrv and sssd) from the IPA server I directly > >> > > > specified via the client sssd.conf and logs from the client itself. > >> > > > > >> > > > Any pointers and/or suggestions would be extremely helpful! > >> > > > > >> > > > Thank you, > >> > > > John DeSantis > >> > _______________________________________________ > >> > 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 > > >[domain/ipa.domain.com] > > > >debug_level = 10 > >krb5_store_password_if_offline = True > >ipa_domain = ipa.domain.com > >id_provider = ipa > >auth_provider = ipa > >access_provider = ipa > >ipa_hostname = client.ipa.domain.com > >chpass_provider = ipa > >#ipa_server = _srv_, ipaserver1.ipa.domain.com > >ipa_server = ipaserver2.ipa.domain.com > >ldap_tls_cacert = /etc/ipa/ca.crt > >krb5_auth_timeout = 3600 > > > >#ignore_group_members = True > >#ldap_purge_cache_timeout = 0 > >#ldap_use_tokengroups = false > >#ldap_search_timeout = 30 > >#ldap_network_timeout = 30 > >#ldap_group_nesting_level = 0 > >#ldap_opt_timeout = 30 > >#ldap_referrals = false > >#ipa_subdomains_search_base > >cn=ad.domain.com,cn=ad,cn=trusts,dc=ipa,dc=domain,dc=com > >#subdomain_inherit = > >ldap_purge_cache_timeout,ignore_group_members,ldap_use_tokengroups,ldap_group_nesting_level > >#reconnection_retries = 12 > >#get_domains_timeout = 120 > > > >[sssd] > >config_file_version = 2 > >debug_level = 10 > >services = nss, sudo, pam, ssh > >domains = ipa.domain.com > >#domain_resolution_order = ad.domain.com,ipa.domain.com > >full_name_format = %1$s > > > >[nss] > >debug_level = 10 > >entry_negative_timeout = 1 > >override_homedir = /home/%l/%u > >filter_groups = adglobalposixgr...@ad.domain.com > > > >[pam] > >pam_id_timeout = 3600 > > > > > >[sudo] > > > >[autofs] > > > >[ssh] > > > >[pac] > > > >[ifp] > > > >[secrets] > > > > >[domain/ipa.domain.com] > > > >debug_level = 10 > >krb5_store_password_if_offline = True > >ipa_domain = ipa.domain.com > >id_provider = ipa > >auth_provider = ipa > >access_provider = ipa > >ipa_hostname = ipaserver2.ipa.domain.com > >chpass_provider = ipa > >ipa_server = ipaserver2.ipa.domain.com > >ipa_server_mode = True > >ldap_tls_cacert = /etc/ipa/ca.crt > >#entry_cache_timeout = 30 > >#ldap_enumeration_refresh_timeout = 30 > >#ignore_group_members = True > >#ldap_purge_cache_timeout = 0 > >#ldap_use_tokengroups = False > >#ldap_group_nesting_level = 0 > >#subdomain_inherit = > >ignore_group_members,ldap_purge_cache_timeout,ldap_use_tokengroups,ldap_group_nesting_level > > > >[sssd] > >debug_level = 10 > >services = nss, sudo, pam, ssh > >domains = ipa.domain.com > >#domain_resolution_order = ad.domain.com,ipa.domain.com > >full_name_format = %1$s > > > > > >[nss] > >debug_level = 10 > >override_homedir = /home/%l/%u > >#entry_negative_timeout = 1 > >#filter_groups = *@ad.domain.com > > > > > >[pam] > >pam_id_timeout = 3600 > > > >[sudo] > > > >[autofs] > > > >[ssh] > > > >[pac] > > > >[ifp] > > > >[secrets] > > > >[session_recording] > > > > >_______________________________________________ > >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
