Ah ok, I see the nss lookup fails on the client now.

On the ipa master during failed client login, the only nss log entry says my ad user matched the ad domain.

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.

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=myuser@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-leave@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.fedorahoste...

That clears up a lot. The client was failing on the NSS part as no results for the ad user were returned from the ipa master.

While cleaning cache and sss_debuglevel 10 on the master each time, testing indicates that a different ad ldap lookup is being done from the master during failed client auths vs during successful master auths.

The first AD search by master during failed client login is this:

(Mon Apr 29 21:28:28 2019) [sssd[be[ipa.domain.acme.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=123123123)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))][dc=domain,dc=acme,dc=com].

Meanwhile, when i ssh as ad user into the ipa master, it tries this first:

(Mon Apr 29 21:25:09 2019) [sssd[be[ipa.domain.acme.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=myuser)(objectclass=user)(&(uidNumber=*)(!(uidNumber=0))))][dc=domain,dc=acme,dc=com].

Any idea why it's searching incorrectly like that in the first test? I could be misunderstanding but if objectClass was user instead that would have been valid.

Thanks, D

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, April 29, 2019 3:59 PM, Jakub Hrozek jhrozek@redhat.com wrote:

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=myuser@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-leave@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.fedorahoste...