From: Jakub Hrozek jhrozek@redhat.com
Are you sure sssd is not logging you offline?
sssctl domain-status can tell you the status of the domains..
Yes, I sure. I tried to login in ipa server and client. I could with old password, but coludn't with new.
sssctl domain-status start-line.local Online status: Online
Active servers: AD Global Catalog: ad.start-line.local AD Domain Controller: ad2.start-line.local IPA: dc.fs.lan
Discovered AD Global Catalog servers: - ad.start-line.local - ad2.start-line.local
Discovered AD Domain Controller servers: - ad2.start-line.local - ad.start-line.local
Discovered IPA servers: - dc.fs.lan
On su, 22 heinä 2018, Николай Савельев via FreeIPA-users wrote:
From: Jakub Hrozek jhrozek@redhat.com
Are you sure sssd is not logging you offline?
sssctl domain-status can tell you the status of the domains..
Yes, I sure. I tried to login in ipa server and client. I could with old password, but coludn't with new.
When you are using trust to AD *all* authentication of AD users is performed by AD DCs. IPA masters are not involved at all. So you need to look at AD side for that.
22.07.2018, 12:56, "Alexander Bokovoy" abokovoy@redhat.com:
When you are using trust to AD *all* authentication of AD users is performed by AD DCs. IPA masters are not involved at all. So you need to look at AD side for that.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
Sorry, I don't undestend wat's going on. I can login ad computers with new password. And i also can login on one ipa client - a new member of ipa domen. But whan I try login by ssh on old ipa members and ipa controllers, i see:
Password: Password: Passwors: start-line\savelev@192.168.2.21's password:
I enter password 4 times, and after that i can login.
When i root, I can doing su aduser@ad_domain. And then I can kinit and get kerberos ticket.
But if I another user, I must tape password after su ad_user@ad_domain and get error
Password: su: Authentication failure
because su wanted password just one time.
On su, 22 heinä 2018, Николай Савельев wrote:
22.07.2018, 12:56, "Alexander Bokovoy" abokovoy@redhat.com:
When you are using trust to AD *all* authentication of AD users is performed by AD DCs. IPA masters are not involved at all. So you need to look at AD side for that.
Sorry, I don't undestend wat's going on. I can login ad computers with new password. And i also can login on one ipa client - a new member of ipa domen. But whan I try login by ssh on old ipa members and ipa controllers, i see:
Password: Password: Passwors: start-line\savelev@192.168.2.21's password: I enter password 4 times, and after that i can login.
enable 'debug_level = 9' in domain and pam sections in sssd.conf, restart sssd, try again and show logs.
When i root, I can doing su aduser@ad_domain.
This is *not* authenticating anything. Root is allowed to su to anyone without authentication.
And then I can kinit and get kerberos ticket.
But if I another user, I must tape password after su ad_user@ad_domain and get error
Password: su: Authentication failure
because su wanted password just one time.
Again, show sssd logs. I suspect it is something with communicating to your AD DCs because SSSD doesn't use anything else to authenticate.
22.07.2018, 14:16, "Alexander Bokovoy" abokovoy@redhat.com:
Again, show sssd logs. I suspect it is something with communicating to your AD DCs because SSSD doesn't use anything else to authenticate.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
Here you are
On su, 22 heinä 2018, Николай Савельев wrote:
22.07.2018, 14:16, "Alexander Bokovoy" abokovoy@redhat.com:
Again, show sssd logs. I suspect it is something with communicating to your AD DCs because SSSD doesn't use anything else to authenticate.
Here you are
So, SSSD is not able to communicate with AD DCs and puts the domain offline. You can see in /var/log/sssd/krb5_child.log and ldap_child.log for details on why thing fail.
(Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain lookup failed, will try to reset sudomain.. (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of subdom start-line.local from forest start-line.local is: one-way inbound: local +domain trusts the remote domain (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for start-line.local (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab for FS$@START-LINE.LOCAL from dc.fs.lan into /var/lib/sss/keytabs/start-line.local.keytab5Q7g1i +using ccache /var/lib/sss/db/ccache_FS.LAN (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [9290] (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [child_handler_setup] (0x2000): Signal handler set up for pid [9290] (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x55acec715d90], connected[1], ops[(nil)], ldap[0x55acec7069b0] (Sun Jul 22 15:54:19 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list Keytab successfully retrieved and stored in: /var/lib/sss/keytabs/start-line.local.keytab5Q7g1i (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [child_sig_handler] (0x1000): Waiting for child [9290]. (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [child_sig_handler] (0x0100): child [9290] finished successfully. (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_getkeytab_recv] (0x2000): ipa-getkeytab status 0 (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_server_trust_1way_kt_done] (0x0400): Keytab successfully retrieved to /var/lib/sss/keytabs/start-line.local.keytab5Q7g1i (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_check_keytab] (0x4000): keytab /var/lib/sss/keytabs/start-line.local.keytab5Q7g1i already exists (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_server_trust_1way_kt_done] (0x2000): Keytab renamed to /var/lib/sss/keytabs/start-line.local.keytab (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_server_trust_1way_kt_done] (0x0400): Keytab /var/lib/sss/keytabs/start-line.local.keytab5Q7g1i contains the expected principals (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_server_trust_1way_kt_done] (0x0400): Established trust context for start-line.local (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/keytabs/start-line.local.keytab5Q7g1i] (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/keytabs/start-line.local.keytab5Q7g1i] (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_srv_ad_acct_retried] (0x0400): Sudomain re-set, will retry lookup (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [be_fo_reset_svc] (0x1000): Resetting all servers in service start-line.local (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [be_fo_reset_svc] (0x0080): Cannot retrieve service [start-line.local] (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [sss_domain_get_state] (0x1000): Domain fs.lan is Active (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [sss_domain_get_state] (0x1000): Domain start-line.local is Inactive (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [sss_domain_get_state] (0x1000): Domain start-line.local is Inactive (Sun Jul 22 15:54:20 2018) [sssd[be[fs.lan]]] [be_mark_dom_offline] (0x1000): Marking subdomain start-line.local offline
Here
22.07.2018, 16:32, "Alexander Bokovoy" abokovoy@redhat.com:
On su, 22 heinä 2018, Николай Савельев wrote:
22.07.2018, 14:16, "Alexander Bokovoy" abokovoy@redhat.com:
Again, show sssd logs. I suspect it is something with communicating to your AD DCs because SSSD doesn't use anything else to authenticate.
Here you are
So, SSSD is not able to communicate with AD DCs and puts the domain offline. You can see in /var/log/sssd/krb5_child.log and ldap_child.log for details on why thing fail.
There are two errors I see in the logs. First, the ldap_child.log ends with: (Sun Jul 22 16:07:37 2018) [[sssd[ldap_child[9680]]]] [sss_child_krb5_trace_cb] (0x4000): [9680] 1532250457.238992: Initiating TCP connection to stream 192.168.2.10:88
and nothing after that so I wonder if the child was subsequently killed due to a timeout after it tried to authenticate to the DC. But we don’t have the full logs so I’m just guessing.
The other issue I see is in krb5_child.log, first there is this: (Sun Jul 22 15:54:36 2018) [[sssd[krb5_child[9331]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328174] during pre-auth. but this is “just” preauth failed, then the authentication goes on about 6 seconds later: (Sun Jul 22 15:54:42 2018) [[sssd[krb5_child[9337]]]] [unpack_buffer] (0x0100): cmd [241] uid [1837401456] gid [1837401456] validate [true] enterprise principal [false] offline [true] UPN [savelev@START-LINE.LOCAL]
but the interesting part here is “offline [true]” which indicates some connectivity issues. And btw the delay of 6 seconds matches the default timeouts.
It would be nice to see the complete logs, though.
On 22 Jul 2018, at 11:48, Николай Савельев via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Here
22.07.2018, 16:32, "Alexander Bokovoy" abokovoy@redhat.com:
On su, 22 heinä 2018, Николай Савельев wrote:
22.07.2018, 14:16, "Alexander Bokovoy" abokovoy@redhat.com:
Again, show sssd logs. I suspect it is something with communicating to your AD DCs because SSSD doesn't use anything else to authenticate.
Here you are
So, SSSD is not able to communicate with AD DCs and puts the domain offline. You can see in /var/log/sssd/krb5_child.log and ldap_child.log for details on why thing fail.
-- С уважением, Николай. <krb5_child.log><ldap_child.log>_______________________________________________ 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.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Here logs after attempt autentication via ssh.
Also config files,
23.07.2018, 14:49, "Jakub Hrozek" jhrozek@redhat.com:
OK, maybe it’s this: (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_print_server] (0x2000): Searching 192.168.2.105:389 (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-1948593278-483253815-2868158363-1029))][cn=Default Trust View,cn=v iews,cn=accounts,dc=fs,dc=lan]. (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 21 (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_op_add] (0x2000): New operation 21 timeout 6 (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x56065d6cd580], connected[1], ops[0x56065d71df60], ldap[0x56065d6c4a10] (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_result] (0x2000): Trace: sh[0x56065d6cd580], connected[1], ops[0x56065d71df60], ldap[0x56065d6c4a10] (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_op_destructor] (0x2000): Operation 21 finished (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-1948593278-483253815-2868158363-1029))]. (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_initgr_get_overrides_step] (0x1000): Processing group 2/4 (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_initgr_get_overrides_step] (0x0040): The group name=domainusers@fs.lan,cn=groups,cn=fs.lan,cn=sysdb has no UUID attribute objectSIDString, error!
—> here
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides failed [22]. (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [be_mark_dom_offline] (0x1000): Marking subdomain start-line.local offline (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x56065d7255a0
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x56065d6f6dd0
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Running timer event 0x56065d7255a0 "ltdb_callback"
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Destroying timer event 0x56065d6f6dd0 "ltdb_timeout"
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ldb] (0x4000): Ending timer event 0x56065d7255a0 "ltdb_callback"
(Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [be_mark_subdom_offline] (0x1000): Marking subdomain start-line.local as inactive (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [22]: Недопустимый аргумент. (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [22]: Недопустимый аргумент. (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [dp_reply_std_set] (0x0080): DP Error is OK on failed request? (Tue Jul 24 23:53:31 2018) [sssd[be[fs.lan]]] [dp_req_done] (0x0400): DP Request [Initgroups #4]: Request handler finished [0]: Победа
So this group doesn’t have a SID (note that the objectSIDString is what SSSD saves into the database, not the actual LDAP attribute. On the IPA side, all groups a trusted object is a member of must have the attribute ipaNTSecurityIdentifier. Does the group domainusers have one? You can check with “ipa group-show —all —raw domainusers”.
btw when you established the trust, the ipa-adtrust-install command should have given you the option to generate SIDs for IPA objects. I don’t know exactly how to generate the SIDs post-install, maybe one of the IPA developers would help me out. Looking at the —help output of ipa-adtrust-install there is an option —add-sids..
On 24 Jul 2018, at 19:33, Николай Савельев via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Here logs after attempt autentication via ssh.
Also config files,
23.07.2018, 14:49, "Jakub Hrozek" jhrozek@redhat.com:
-- С уважением, Николай. <conf.tgz><sssd.tgz>_______________________________________________ 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.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
freeipa-users@lists.fedorahosted.org