Hmm, well, yes, it did: (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18121]]]] [unpack_buffer] (0x0100): cmd [249] uid [1349938498] gid [1349938498] validate [true] enterprise principal [false] offline [false] UPN [[email protected]] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18121]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/[email protected]] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18122]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18121]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18121]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18121]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [unpack_buffer] (0x0100): cmd [241] uid [1349938498] gid [1349938498] validate [true] enterprise principal [false] offline [false] UPN [[email protected]] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1349938498] old_ccname: [KEYRING:persistent:1349938498] keytab: [/etc/krb5.keytab] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/[email protected]] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328378][Client '[email protected]' not found in Kerberos database] (Thu Aug 4 13:46:58 2016) [[sssd[krb5_child[18124]]]] [map_krb5_error] (0x0020): 1303: [-1765328378][Client '[email protected]' not found in Kerberos database]
and this is actually correct, because the UPN would be [email protected]. I found this: https://access.redhat.com/solutions/323373 However, setting ldap_user_principal in the domain part to something non-existing doesn't seem to work. ----- On Aug 4, 2016, at 1:22 PM, Jakub Hrozek [email protected] wrote: > On Thu, Aug 04, 2016 at 12:57:40PM +0200, Troels Hansen wrote: >> Hi, we have set up IPA in a AD trust and is about 90% done, but still have >> one >> problem using SSH login. >> >> Kerberos works: >> # kdestroy >> # kinit [email protected] >> Password for [email protected]: >> # klist >> Ticket cache: KEYRING:persistent:0:0 >> Default principal: [email protected] >> >> Valid starting Expires Service principal >> 08/04/2016 12:46:17 08/04/2016 22:46:17 krbtgt/[email protected] >> renew until 08/05/2016 12:46:09 >> >> >> I can see the user: >> >> # getent passwd [email protected] >> [email protected]:*:1349938498:1349938498:DREXTRHA:/home/net.dr.dk/drextrha: >> >> However, can't log in using SSH: >> >> login as: [email protected] >> [email protected]@ipa02tst.linux.dr.dk's password: >> Access denied >> >> >> When I look at the log files it looks correct, untill we receive a " >> be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success >> (System error)] " error, which I can't quite resolve or even verify if thats >> what's causing the problem. >> >> >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [krb5_auth_store_creds] >> (0x0010): unsupported PAM command [249]. >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [krb5_auth_store_creds] >> (0x0010): password not available, offline auth may not work. >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [be_pam_handler_callback] >> (0x0100): Backend returned: (0, 0, <NULL>) [Success (Success)] >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [be_pam_handler_callback] >> (0x0100): Sending result [0][net.dr.dk] >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [be_pam_handler_callback] >> (0x0100): Sent result [0][net.dr.dk] >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [be_pam_handler] (0x0100): >> Got >> request with the following data >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> command: PAM_AUTHENTICATE >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> domain: net.dr.dk >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> user: [email protected] >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> service: sshd >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> tty: ssh >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> ruser: >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> rhost: t01042.net.dr.dk >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> authtok type: 1 >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> newauthtok type: 0 >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> priv: 1 >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> cli_pid: 17348 >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [pam_print_data] (0x0100): >> logon name: not set >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [fo_resolve_service_send] >> (0x0100): Trying to resolve service 'IPA' >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [child_sig_handler] >> (0x0100): >> child [17356] finished successfully. >> (Thu Aug 4 12:51:10 2016) [sssd[be[linux.dr.dk]]] [be_pam_handler_callback] >> (0x0100): Backend returned: (0, 4, <NULL>) [Success (System error)] > > Please take a look into krb5_child.log, it should have more hints on why > the authentication failed. > > (This is documented at > https://fedorahosted.org/sssd/wiki/Troubleshooting, section > "Troubleshooting general authentication problems") > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
