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(a)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(a)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(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
>
>