1:56 p.m.
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
2:04 p.m.
New subject: IPA Client SSH under AD cross-forest trust not working
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?
2:48 p.m.
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(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...
2:59 p.m.
New subject: IPA Client SSH under AD cross-forest trust not working
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...
>
>
4:33 p.m.
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(a)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(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...
1831
days inactive
1831
days old
freeipa-users@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
D -
Jakub Hrozek