freeipa

#7765 AD user cannot ssh login to the client server
Closed: invalid Opened by akadoya.

Closed: invalid
Reopen Issue

Issue

users in active directory (cross-forest trust is configured) cannot authenticate the ipa client servers over ssh.
FreeIPA domain : idm.domain.com
AD domain : domain.com
client machines' domain : prod.domain.com (domain.com's child domain and I can see this domain as trusted domains from ipa server)
DNS and users are all controlled by AD side.

Steps to Reproduce

  1. Install a ipa-client by ipa-client-install --mkhomedir --hostname=client1.prod.domain.com --server ipa-server.idm.domain.com --domain idm.domain.com
    2.ssh aduser\@domain.com@localhost

Actual behavior

cannot authenticate

Expected behavior

can login by using a user x password in trusted domain

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

ipa-server-4.5.4-10.el7.centos.4.4.x86_64
ipa-client-4.5.4-10.el7.centos.4.4.x86_64
389-ds-base-1.3.7.5-28.el7_5.x86_64
pki-ca-10.5.1-15.el7_5.noarch
krb5-server-1.15.1-19.el7.x86_64


ipa-client-4.5.4-10.el7.centos.4.4.x86_64

Additional info:

I can login with ad user to the IPA server itself.
kinit works both for client and servers so I am pretty sure I am using the right password.

sssd_pam.log has the error like below.
(Tue Nov 13 01:22:32 2018) [sssd[pam]] [cache_req_search_dp] (0x0400): CR #0: Looking up [user@domain.com] in data provider
(Tue Nov 13 01:22:32 2018) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5626a71824c0:3:user@domain.com@domain.com]
(Tue Nov 13 01:22:32 2018) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [domain.com][0x3][BE_REQ_INITGROUPS][name=user@domain.com:-]
(Tue Nov 13 01:22:32 2018) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x5626a858c2b0
(Tue Nov 13 01:22:32 2018) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5626a71824c0:3:user@domain.com@domain.com]
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x5626a858c2b0
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x5626a858b170
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching.
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [cache_req_common_dp_recv] (0x0040): CR #0: Data Provider Error: 3, 5, Failed to get reply from Data Provider
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [cache_req_common_dp_recv] (0x0400): CR #0: Due to an error we will return cached data
(Tue Nov 13 01:22:33 2018) [sssd[pam]] [cache_req_search_cache] (0x0400): CR #0: Looking up [user@domain.com] in cache

sssd.conf
[domain/idm.domain.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = idm.domain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = client.prod.domain.com
chpass_provider = ipa
ipa_server = ipa-server.idm.domain.com
debug_level = 10
[sssd]
services = nss, sudo, pam, ssh

domains = idm.domain.com
[nss]
homedir_substring = /home

[pam]
debug_level = 10

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[secrets]

[session_recording]

Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domai
n_Identity_Authentication_and_Policy_Guide/config-files-logs.html
Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting

Most probably the client cannot looks the AD user from the IPA server properly. The SSSD domain log on the client should have more details.

Which range type are you using? You can find out by calling

ipa idrange-find

and look for the AD domains. A typical reason if you use ipa-ad-trust-posix is that not all AD groups the user is a member of have GIDs assigned. To check this, please call 'id aduser@domain.com' on the IPA server and check if every group has a name and a GID.

HTH

bye,
Sumit

HI Sumit,

Thank you for the advise, I do see the domains from idrange-find as below.

3 ranges matched

Range name: DOMAIN.COM_id_range
First Posix ID of the range: 1751600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-2771039769-2678555624-23535128=
33
Range type: Active Directory domain range

Range name: IDM.DOMAIN.COM_id_range
First Posix ID of the range: 841200000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range type: local domain range

Range name: DOMAIN.BUY.COM_id_range
First Posix ID of the range: 1252600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-1165448894-1289096760-36842007=
38
Range type: Active Directory domain range

Number of entries returned 3

Also, I see all the groups have GID assigned on the client.
However I do have a lot of groups assigned to a user... my own account
belong to like 404 groups. (all group ID is assigned in the range of
1751600000)

I also can retrieve the account info by getend passwd command as well.
Appreciate if you could advise me on other things to check.

Best,
Aoi

On Tue, Nov 13, 2018 at 12:43 AM Sumit Bose pagure@pagure.io wrote:

sbose added a new comment to an issue you are following:
``
Most probably the client cannot looks the AD user from the IPA server pro=
perly. The SSSD domain log on the client should have more details.

Which range type are you using? You can find out by calling

ipa idrange-find

and look for the AD domains. A typical reason if you use ipa-ad-trust-pos=
ix is that not all AD groups the user is a member of have GIDs assigned. To=
check this, please call 'id aduser@domain.com' on the IPA server and check=
if every group has a name and a GID.

HTH

bye,
Sumit
``

To reply, visit the link below or just reply to this email
https://pagure.io/freeipa/issue/7765

The ranges look good. The domain logs from the SSSD client are needed to get a better understanding what is failing. Since you have many groups it might be a timeout which should be increased. But the domain logs with debug_level=10 will have more detailed information.

Thank you very much, that was it, I found a timeout error.

(Wed Nov 14 21:02:52 2018) [sssd[be[idm.domain.com]]]
[ipa_s2n_get_acct_info_send] (0x0400): Sending request_type:
[REQ_FULL_WITH_MEMBERS] for trust user [user.name] to IPA server
(Wed Nov 14 21:02:52 2018) [sssd[be[idm.domain.com]]]
[ipa_s2n_exop_send] (0x0400): Executing extended operation
(Wed Nov 14 21:02:52 2018) [sssd[be[idm.domain.com]]]
[ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid =3D 5
(Wed Nov 14 21:02:52 2018) [sssd[be[idm.domain.com]]] [sdap_op_add]
(0x2000): New operation 5 timeout 6
(Wed Nov 14 21:02:52 2018) [sssd[be[idm.domain.com]]]
[sdap_id_op_connect_done] (0x4000): caching successful connection
after 1 notifies
(Wed Nov 14 21:02:52 2018) [sssd[be[idm.domain.com]]]
[be_run_unconditional_online_cb] (0x4000): List of unconditional
online callbacks is empty, nothing to do.
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_op_timeout] (0x1000): Issuing timeout for 5
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_op_destructor] (0x1000): Abandoning operation 5
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_id_op_done] (0x0200): communication error on cached connection,
moving to next server
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_id_op_done] (0x4000): too many communication failures, giving
up...
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_id_op_done] (0x4000): releasing operation connection
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_id_release_conn_data] (0x4000): releasing unused connection
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[sdap_handle_release] (0x2000): Trace: sh[0x558c892f0a30],
connected[1], ops[(nil)], ldap[0x558c892ef6a0], destructor_lock[0],
release_memory[0]
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[remove_connection_callback] (0x4000): Successfully removed connection
callback.
(Wed Nov 14 21:02:58 2018) [sssd[be[idm.domain.com]]]
[ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed:
[110]: Connection timed out.

I added a longer timeout value and now people are able to login!
Thanks a lot,
Aoi
On Tue, Nov 13, 2018 at 11:19 PM Sumit Bose pagure@pagure.io wrote:

sbose added a new comment to an issue you are following:
The ranges look good. The domain logs from the SSSD client are needed to = get a better understanding what is failing. Since you have many groups it m= ight be a timeout which should be increased. But the domain logs with debug= _level=3D10 will have more detailed information.

To reply, visit the link below or just reply to this email
https://pagure.io/freeipa/issue/7765

Thank you for the feedback, I'll close this ticket.

Metadata Update from @sbose:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.