[Freeipa-users] AD trust relationship is established, but IPA cannot see AD users

[Alexander Bokovoy]

On Tue, 03 Mar 2015, Guertin, David S. wrote:
>> Do these logs come from a client or the IPA server? Are you able to look up
>> the user on the IPA server at least?
>
>These come from the IPA server. So no, I can't even look up the user on the server.
>
>> Can you paste (sanitized) logs from the sssd_be process as well? They would
>> be located at /var/log/sssd/sssd_middlebury.edu.log
>
>Here's the relevant section. It's actually in var/log/sssd/sssd_csns.middlebury.edu.log. Here, csns.middlebury.edu is the IPA subdomain of our middlebury.edu AD domain.
>
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0xcbdfd0
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): Dispatching.
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=guertin-s]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_req_set_domain] (0x0400): Changing request domain from [csns.middlebury.edu] to [middlebury.edu]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 26
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[0xce01f0], ldap[0xcc9a00]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null)
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[(nil)], ldap[0xcc9a00]
>(Tue Mar  3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
Can you show us your sssd.conf? When SSSD runs on IPA master it should
not use extdom (ipa_s2n_exop_send and friends) at all.

>
> > If the logs are from the client and the back end logs would say something
>> about extended operation failing, then we need to take a look at the sssd
>> logs on the server as well.
>
>So, yes, it looks like ldap_extended_operation failed, and something is
>going on with our AD server. This actually triggers a realization on my
>part: I've been testing this with one of our AD domain controllers, but
>we have three others that I'm not testing it with. I suspect now that
>IPA is trying to talk to one of the other DCs that does not have a
>trust relationship established. Eventually I want to set up a trust
>relationship on all the DCs, but to test for now, is there a way to
>force IPA to use a particular domain controller?
>
>David Guertin
>
>-- 
>Manage your subscription for the Freeipa-users mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-users
>Go To http://freeipa.org for more info on the project

-- 
/ Alexander Bokovoy