On Wed, Feb 17, 2021 at 10:58:54AM -0500, Robert Kudyba via FreeIPA-users wrote:
> >
> > that's odd, can you check with ps if nscd is running?
>
>
> It is not.
>
>
> > Does /var/run/nscd/socket exists?
> >
>
> Yes it does, I then deleted it.
>
>
> > > (2021-02-16 15:06:30): [be[ourdomain.edu]] [setup_tls_config] (0x0020):
> > > Unknown value for tls_reqcert 'never (or allow'.
> >
> > Can you check your sssd.conf if the 'tls_reqcert' option is set to
> > 'never (or allow'? I guess you wanted to set it to 'never'.
> >
>
> Nice catch. Bad copy/paste for me as I tried to enable more verbose debug
> logs. Now sssd at least starts.
>
> So new users created in IPA/LDAP can now ssh -k and su correctly. The debug
> ssh server logs look like this:
> Feb 17 09:44:47 ourdomainsshd[1016078]: debug1: userauth-request for user
> tuser service ssh-connection method keyboard-interactive [preauth]
> Feb 17 09:44:47 ourdomainsshd[1016078]: debug1: attempt 3 failures 1
> [preauth]
> Feb 17 09:44:47 ourdomainsshd[1016078]: debug1: keyboard-interactive devs
> [preauth]
> Feb 17 09:44:47 ourdomainsshd[1016078]: debug1: auth2_challenge: user=tuser
> devs= [preauth]
> Feb 17 09:44:47 ourdomainsshd[1016078]: debug1: kbdint_alloc: devices 'pam'
> [preauth]
> Feb 17 09:44:47 ourdomainsshd[1016078]: debug1: auth2_challenge_start:
> trying authentication method 'pam' [preauth]
> Feb 17 09:44:48 ourdomainsshd[1016078]: Postponed keyboard-interactive for
> tuser from x.x.x.x port 48614 ssh2 [preauth]
> Feb 17 09:44:52 ourdomainsshd[1016085]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.xuser=tuser
> Feb 17 09:44:52 ourdomainsshd[1016085]: pam_sss(sshd:auth): received for
> user tuser: 12 (Authentication token is no longer valid; new one required)
> Feb 17 09:44:52 ourdomainsshd[1016085]: debug1: do_pam_account: called
> Feb 17 09:44:52 ourdomainsshd[1016085]: pam_sss(sshd:account): User info
> message: Password expired. Change your password now.
> Feb 17 09:44:52 ourdomainsshd[1016085]: pam_unix(sshd:chauthtok): user
> "tuser" does not exist in /etc/passwd
> Feb 17 09:44:52 ourdomainsshd[1016078]: Postponed keyboard-interactive/pam
> for tuser from x.x.x.x port 48614 ssh2 [preauth]
>
> ssh -vvv has this:
> debug2: pubkey_prepare: done
> debug3: send packet: type 5
> debug3: receive packet: type 7
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,
> [email protected]
> ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> [email protected],
> [email protected]>
> debug3: receive packet: type 6
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug3: send packet: type 50
> debug3: receive packet: type 51
> debug1: Authentications that can continue:
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> debug3: start over, passed a different list
> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> debug3: preferred password
> debug3: authmethod_lookup password
> debug3: remaining preferred:
> debug3: authmethod_is_enabled password
> debug1: Next authentication method: password
>
> As for an imported NIS user, only the NIS password continues to allow
> logins. I also stopped ypserv and ypbind to see if there was any difference
> and there is not.
>
> Here are the ssh server logs for the NIS password that succeeds:
> Feb 17 09:34:56 ourdomain sshd [1015632]: debug1: userauth-request for user
> ouruser service ssh-connection method password [preauth]
> Feb 17 09:34:56 ourdomain sshd [1015632]: debug1: attempt 2 failures 1
> [preauth]
> Feb 17 09:34:56 ourdomain sshd [1015632]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x
> user=ouruser
> Feb 17 09:34:56 ourdomain sshd [1015632]: pam_sss(sshd:auth): received for
> user ouruser: 9 (Authentication service cannot retrieve authentication info)
> Feb 17 09:34:58 ourdomain sshd [1015632]: debug1: PAM: password
> authentication failed for ouruser: Authentication failure
> Feb 17 09:34:58 ourdomain sshd [1015632]: Failed password for ouruser from
> x.x.x.x port 48578 ssh2
> Feb 17 09:35:07 ourdomain sshd [1015632]: debug1: userauth-request for user
> ouruser service ssh-connection method password [preauth]
> Feb 17 09:35:07 ourdomain sshd [1015632]: debug1: attempt 3 failures 2
> [preauth]
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1:* PAM: password
> authentication accepted for ouruser*
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: do_pam_account: called
> Feb 17 09:35:08 ourdomain sshd [1015632]: Accepted password for ouruser
> from x.x.x.x port 48578 ssh2
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: monitor_child_preauth:
> ouruser has been authenticated by privileged process
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: monitor_read_log: child
> log fd closed
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: audit_event: unhandled
> event 2
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: temporarily_use_uid:
> 5920/200 (e=0/0)
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1:* ssh_gssapi_storecreds:
> Not a GSSAPI mechanism*
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: restore_uid: 0/0
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: SELinux support disabled
> Feb 17 09:35:08 ourdomain sshd [1015632]: debug1: PAM: establishing
> credentials
> Feb 17 09:35:08 ourdomain systemd[1015655]: pam_unix(systemd-user:session):
> session opened for user ouruser (uid=5920) by (uid=0)
> Feb 17 09:36:38 ourdomain sshd [1015632]: pam_unix(sshd:session): session
> opened for user ouruser (uid=5920) by (uid=0)
> Feb 17 09:36:39 ourdomain sshd [1015632]: User child is on pid 1015696
> Feb 17 09:36:39 ourdomain sshd [1015696]: debug1: PAM: establishing
> credentials
>
> What sticks out to me is what I bolded, that PAM password auth works and
> that this is NOT a GSSAPI mechanism. Am I missing a step?
>
> Here are the related logs from sssd_ourdomain.edu.log:
> (2021-02-17 10:45:25): [be[ourdomain.edu]*] [dp_get_account_info_send]
> (0x0200): Got request for
> [0x1][BE_REQ_USER][name=pam_usertype_non_existent:@ourdomain.edu
> <[email protected]>]*
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [dp_attach_req] (0x0400): DP
> Request [Account #70]: New request. Flags [0x0001].
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [dp_attach_req] (0x0400): Number
> of active DP request: 1
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_search_user_next_base]
> (0x0400): Searching for users with base [cn=accounts,dc=ourdomain,dc=edu]
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_get_generic_ext_step]
> (0x0400): calling ldap_search_ext with
> [(&(uid=pam_usertype_non_existent:)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=ourdomain,dc=edu].
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_get_generic_op_finished]
> (0x0400): Search result: Success(0), no errmsg set
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_search_user_process]
> (0x0400): *Search for users, returned 0 results*.
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_search_user_next_base]
> (0x0400): Searching for users with base [cn=trusts,dc=ourdomain,dc=edu]
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_get_generic_ext_step]
> (0x0400): calling ldap_search_ext with
> [(&(&(uid=pam_usertype_non_existent:)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))(objectClass=ipaIDObject))][cn=trusts,dc=ourdomain,dc=edu].
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_get_generic_op_finished]
> (0x0400): Search result: Success(0), no errmsg set
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sdap_search_user_process]
> (0x0400): *Search for users, returned 0 results*.
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sysdb_search_by_name] (0x0400):
> No such entry
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sysdb_delete_user] (0x0400):
> Error: 2 (No such file or directory)
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sysdb_search_by_name] (0x0400):
> No such entry
> (2021-02-17 10:45:25): [be[ourdomain.edu]]
> [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending
> request
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [dp_req_done] (0x0400): DP
> Request [Account #70]: Request handler finished [0]: Success
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [_dp_req_recv] (0x0400): DP
> Request [Account #70]: Receiving request data.
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [dp_req_destructor] (0x0400): DP
> Request [Account #70]: Request removed.
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [dp_req_destructor] (0x0400):
> Number of active DP request: 0
> (2021-02-17 10:45:25): [be[ourdomain.edu]] [sbus_issue_request_done]
> (0x0400): sssd.dataprovider.getAccountInfo: Success
>
> So the log "*name=pam_usertype_non_existent*:" seems rather pertinent. I
> see from another thread
> https://freeipa-users.redhat.narkive.com/GYwxOWHr/understanding-the-migration-mode,
> I also used --setattr userpassword={crypt}yourencryptedpass.
>
> ipa user-show returns "Kerberos keys available: False" on the migrated NIS
> users. I tested changing passwords of users via the GUI and then ipa
> user-show returns "Kerberos keys available: True"
Hi,
have you enabled the migration mode with
ipa config-mod --enable-migration=True
With this authentication with SSSD should fall back to LDAP
authentication if the Kerberos keys are not available and this would
trigger a creation of the Kerberos keys for the user trying to log in.
bye,
Sumit
>
> Anything stick out here?
> _______________________________________________
> FreeIPA-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[email protected]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
