On Mon, Apr 29, 2019 at 07:48:30PM +0000, D wrote: > Ah ok, I see the nss lookup fails on the client now.
What nss lookup exactly? > > On the ipa master during failed client login, the only nss log entry says my > ad user matched the ad domain. Did you crank up the debug logs? Chances are some entries are returned from the memory cache, you might want to run sss_cache -E on the master before the test. > > When I log in to the master with ad creds (which works), I see all of the ad > groups properly resolving in the logs (at least the ones with proper > gidNumber attributes). The cache on the ipa master contains an entry for the > ad user with proper membership as well. > > At this stage, is it failing to lookup the ad user against AD or against ipa? > I can see that during successful ad logins on the master, it looks first at > ipa but understands that it must then look at ad. The client fetches the NSS information through the IPA master. > > FWIW the ipa masters have the AD ldaps cert installed but the clients do not. > Not sure if that's related. > > Thanks, > D > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, April 29, 2019 3:04 PM, Jakub Hrozek via FreeIPA-users > <freeipa-users@lists.fedorahosted.org> wrote: > > > On Mon, Apr 29, 2019 at 06:56:33PM +0000, D via FreeIPA-users wrote: > > > > > Hello, > > > Apologies for the earlier premature post :) > > > This list helped me solve a number of issues getting a proof-of-concept > > > ipa-ad cross-forest trust working. I believe there is one final issue, > > > hopefully one of the experts here can have a look at the logs and let me > > > know if anything sticks out. > > > I am able to SSH into the ipa master using my AD creds, but have not yet > > > been able to ssh into a given ipa client using AD creds. > > > Here's some details: > > > > > > 1. domain.acme.com is the AD domain, ipa.domain.acme.com is the ipa > > > domain. All ipa clients belong to ipa.domain.acme.com, and they reside in > > > a DNS zone controlled by the ipa server. > > > 2. It's using the posix id range scheme. > > > 3. All configs are fairly stock, and everything set up quite happily > > > using srvs for autodiscovery. There are sites configured, which appear to > > > be working. > > > 4. The ipa clients make no effort to contact the ad servers for KDC or > > > PAC. I have a feeling it doesn't get that far. > > > 5. IPA users can ssh into the ipa clients just fine, ad users cannot. > > > > > > Thank you for your time, > > > D > > > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sbus_dispatch] (0x4000): dbus conn: 0x55b6a51cc380 > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sbus_dispatch] (0x4000): Dispatching. > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sbus_message_handler] (0x2000): Received SBUS method > > > org.freedesktop.sssd.dataprovider.getAccountInfo on path > > > /org/freedesktop/sssd/dataprovider > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [dp_get_account_info_handler] (0x0200): Got request for > > > [0x1][BE_REQ_USER][name=myu...@domain.acme.com] > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [dp_attach_req] (0x0400): DP Request [Account #31]: New request. Flags > > > [0x0001]. > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [dp_attach_req] (0x0400): Number of active DP request: 1 > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_id_op_connect_step] (0x4000): reusing cached connection > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_id_op_connect_step] (0x4000): reusing cached connection > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in > > > view [Default Trust View] with filter > > > [(&(objectClass=ipaUserOverride)(uid=myuser))]. > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_print_server] (0x2000): Searching 172.18.181.132:389 > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > [(&(objectClass=ipaUserOverride)(uid=myuser))][cn=Default Trust > > > View,cn=views,cn=accounts,dc=ipa,dc=domain,dc=acme,dc=com]. > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9 > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] [sdap_op_add] > > > (0x2000): New operation 9 timeout 30 > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_process_result] (0x2000): Trace: sh[0x55b6a51e5060], connected[1], > > > ops[0x55b6a51d8680], ldap[0x55b6a51cb9c0] > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > > errmsg set > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_op_destructor] (0x2000): Operation 9 finished > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [ipa_get_ad_override_done] (0x4000): No override found with filter > > > [(&(objectClass=ipaUserOverride)(uid=myuser))]. > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_id_op_destroy] (0x4000): releasing operation connection > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sss_domain_get_state] (0x1000): Domain ipa.domain.acme.com is Active > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sss_domain_get_state] (0x1000): Domain domain.acme.com is Active > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [sdap_id_op_connect_step] (0x4000): reusing cached connection > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [ipa_s2n_get_acct_info_send] (0x0400): Sending request_type: > > > [REQ_FULL_WITH_MEMBERS] for trust user [myuser] to IPA server > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [ipa_s2n_exop_send] (0x0400): Executing extended operation > > > (Mon Apr 29 18:14:17 2019) [sssd[be[ipa.domain.acme.com]]] > > > [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 10 > > > > The client was not able to resolve the user from the server. Can you > > resolve the user /and all their groups/ on the server? If you tail > > sssd_nss on the server at the same time, are there some lookups that > > fail? > > > > 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
