Hide Forgot
Description of problem: login through GDM does not create kerberos tkt On 5.10 client Version-Release number of selected component (if applicable): ipa-server-3.3.3-5.el7.x86_64 ipa-client-2.1.3-7.el5 pam-0.99.6.2-12.el5 gdm-2.16.0-59.el5_9.1 How reproducible: Always Steps to Reproduce: 1.create an ipa user on master 2.log in via GDM on 5.10 client 3.klist on 5.10 client Actual results: no tkt got created Expected results: krb tkt got created Additional info: I also found that kinit as non admin user, the tkt cache file remains /tmp/krb5cc_0 instead of /tmp/krb5cc_$uid [root@c510 ~]# echo Secret123|kinit admin;klist Password for admin: Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin Valid starting Expires Service principal 11/26/13 12:54:03 11/27/13 12:54:03 krbtgt/TESTRELM.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@c510 ~]# echo xdong123|kinit one;klist Password for one: Ticket cache: FILE:/tmp/krb5cc_0 Default principal: one Valid starting Expires Service principal 11/26/13 12:54:18 11/27/13 12:54:18 krbtgt/TESTRELM.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached
What install options did you pass to the client? Are there any errors in the system logs? The ccache used is expected. The ccache filename has no relationship to the user you kinit to. What version of sssd is installed?
client install options: ipa-client-install --domain=testrelm.com --server=ibm-x3650m4-01-vm-02.testrelm.com --realm=TESTRELM.COM -p admin -w Secret123 --mkhomedir -U I didn't see anything unusual in /var/log/ipaclient-install.log and /var/log/secure client installed with sssd-1.5.1-70.el5
Have you looked at the SSSD logs on the system? Set the debug level and see if it goes through the SSSD and why there is no ticket. Also do you use the same user "admin" to login into GDM and then from the command promt?
I see ccache's of the form that gdm creates that seems to equate with the last successful logins: -rw------- 1 admin admins 529 Nov 26 17:28 /tmp/krb5cc_1235200000_jdUqKI -rw------- 1 one one 523 Nov 26 11:48 /tmp/krb5cc_1235200001_xhEJtV -rw------- 1 two two 523 Nov 26 17:27 /tmp/krb5cc_1235200003_eVYRoV
I think that we need the SSSD logs to be able to proceed further. xdong, did you restart SSSD after you set the debug in respective sections in sssd.conf? If yes, can you please attach your sssd.conf so that Jakub can check if everything is set correctly?
Created attachment 829727 [details] sssd.conf
The config file looks good to me. Does logging in with any other PAM aware service (ssh for example) produce a ccache that can be displayed with klist?
yes. [xdong@xdong ~]$ ssh one.57.7 one.57.7's password: Last login: Wed Nov 27 08:27:15 2013 from 10.10.61.141 -sh-3.2$ klist Ticket cache: FILE:/tmp/krb5cc_1235200001_j4znYq Default principal: one Valid starting Expires Service principal 11/27/13 08:27:58 11/28/13 08:27:58 krbtgt/TESTRELM.COM Kerberos 4 ticket cache: /tmp/tkt1235200001 klist: You have no tickets cached
That's strange, the mechanism for publishing the KRB5CCNAME is the same for pam_sss, we just putenv() the KRB5CCNAME environment variable. Can you check the PAM stack of GDM, is it the same as for SSH? Are there any error messages in /var/log/secure ?
[root@c510 ~]# cat /etc/pam.d/gdm #%PAM-1.0 auth required pam_env.so auth required pam_permit.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so session optional pam_console.so [root@c510 ~]# cat /etc/pam.d/gdm-autologin #%PAM-1.0 auth required pam_env.so auth required pam_permit.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so session optional pam_console.so [root@c510 ~]# cat /etc/pam.d/sshd #%PAM-1.0 auth include system-auth account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so no errors in /var/log/secure
so KRB5CCNAME is not created after GDM login.If KRB5CCNAME is set ,then GDM login creates the tkt. [xdong@xdong ~]$ ssh one.57.7 one.57.7's password: Last login: Wed Nov 27 08:27:59 2013 from 10.10.61.141 -sh-3.2$ klist Ticket cache: FILE:/tmp/krb5cc_1235200001_VAZpq4 Default principal: one Valid starting Expires Service principal 11/27/13 11:00:37 11/28/13 11:00:37 krbtgt/TESTRELM.COM Kerberos 4 ticket cache: /tmp/tkt1235200001 klist: You have no tickets cached -sh-3.2$ echo $KRB5CCNAME FILE:/tmp/krb5cc_1235200001_VAZpq4 -sh-3.2$ kdestroy ---GDM login--- -sh-3.2$ klist Ticket cache: FILE:/tmp/krb5cc_1235200001_VAZpq4 Default principal: one Valid starting Expires Service principal 11/27/13 11:01:58 11/28/13 11:01:58 krbtgt/TESTRELM.COM renew until 11/28/13 11:01:59 Kerberos 4 ticket cache: /tmp/tkt1235200001 klist: You have no tickets cached -sh-3.2$ echo $KRB5CCNAME FILE:/tmp/krb5cc_1235200001_VAZpq4 -sh-3.2$ unset KRB5CCNAME -sh-3.2$ echo $KRB5CCNAME -sh-3.2$ kdestroy kdestroy: No credentials cache found while destroying cache ---GDM login--- -sh-3.2$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1235200001) Kerberos 4 ticket cache: /tmp/tkt1235200001 klist: You have no tickets cached [xdong@xdong ~]$ ssh root.57.7 root.57.7's password: Last login: Wed Nov 27 08:28:45 2013 from 10.10.61.141 [root@c510 ~]# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@c510 ~]# echo $KRB5CCNAME [root@c510 ~]# export KRB5CCNAME=FILE:/tmp/krb5cc_1235200001_VAZpq4 [root@c510 ~]# echo $KRB5CCNAME FILE:/tmp/krb5cc_1235200001_VAZpq4 ---GDM login--- [root@c510 ~]# klist Ticket cache: FILE:/tmp/krb5cc_1235200001_VAZpq4 Default principal: one Valid starting Expires Service principal 11/27/13 11:18:09 11/28/13 11:18:09 krbtgt/TESTRELM.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached
Is there only /etc/pam.d/gdm-autologin? When you log in with gdm, how do the last couple of lines in /var/log/secure look like? Are there any AVC denials perhaps?
[root@c510 one]# ls /etc/pam.d/gdm* /etc/pam.d/gdm /etc/pam.d/gdm-autologin /etc/pam.d/gdmsetup [root@c510 one]# cat /etc/pam.d/gdmsetup #%PAM-1.0 auth include config-util account include config-util session include config-util no avc denial found in /var/log/secure Nov 27 11:18:01 c510 gdm[2515]: pam_unix(gdm:session): session closed for user one Nov 27 11:18:08 c510 gdm[2515]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=one Nov 27 11:18:09 c510 gdm[2515]: pam_sss(gdm:auth): authentication success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=one Nov 27 11:18:10 c510 gdm[2515]: pam_unix(gdm:session): session opened for user one by (uid=0) Nov 27 11:25:49 c510 sshd[8594]: Received disconnect from 10.10.61.141: 11: disconnected by user
log in via GDM on 5.10 client worked for me and I got a kerberos ticket. [root@vm-235 ~]# rpm -q ipa-client sssd gnome-desktop kernel gdm pam ipa-client-2.1.3-7.el5 sssd-1.5.1-70.el5 gnome-desktop-2.16.0-1.fc6 kernel-2.6.18-348.el5 gdm-2.16.0-59.el5_9.1 pam-0.99.6.2-12.el5 ---GDM login-- [root@vm-235 ~]# uname -a Linux vm-235.idm.lab.eng.brq.redhat.com 2.6.18-371.el5 #1 SMP Thu Sep 5 21:21:44 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux I was also able to ssh to another machine using krb5 ticket. clientmachine$ klist Ticket cache: FILE:/tmp/krb5cc_325600000_eVFYMp Default principal: admin.ENG.BRQ.REDHAT.COM Valid starting Expires Service principal 11/27/13 18:22:01 11/28/13 18:22:01 krbtgt/IDM.LAB.ENG.BRQ.REDHAT.COM.ENG.BRQ.REDHAT.COM Kerberos 4 ticket cache: /tmp/tkt325600000 klist: You have no tickets cached clientmachine$ ssh admin@vm-077 Last login: Wed Nov 27 18:21:28 2013 from vm-235.idm.lab.eng.brq.redhat.com bash-4.2$ logout Connection to vm-077 closed. clientmachine$ kdestroy clientmachine$ ssh admin@vm-077 admin@vm-077's password:
Thanks Lukas for testing. It seems to me that there may be a configuration issue in xdong's environment. I think we really need to get the SSSD logs to see what's going on. Either way, this is more a potential SSSD issue than IPA client issue. Moving to sssd component.
Can you reproduce this bug on another machine? Can you provide access to this machine?
yes ,it's the second 5.10 client I'm testing on .Met same issue. master ssh root.41.15 pw: redhat client ssh root.57.7 pw: redhat ---first GDM login failed because previous ccache file not deleted--- (Mon Dec 2 11:04:30 2013) [sssd[be[testrelm.com]]] [check_if_ccache_file_is_used] (1): Cache file [/tmp/krb5cc_1235200001_VAZpq4] exists, but is owned by [0] instead of [1235200010]. (Mon Dec 2 11:04:30 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (1): check_if_ccache_file_is_used failed. (Mon Dec 2 11:04:30 2013) [sssd[be[testrelm.com]]] [ipa_auth_handler_done] (1): krb5_auth_recv request failed. [root@c510 home]# ls /tmp/krb5cc_* /tmp/krb5cc_1235200000_LszXgI /tmp/krb5cc_1235200001_VAZpq4 /tmp/krb5cc_1235200001_xhEJtV /tmp/krb5cc_1235200003_eVYRoV /tmp/krb5cc_1235200004_qWzHG0 /tmp/krb5cc_1235200009_OEnqEE [root@c510 home]# rm -f /tmp/krb5cc_* ---second GDM login success, ccache file was created ,but krb tkt not created--- [root@c510 home]# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (4): No ccache file for user [one] found. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (9): Ccache_file is [not set] and is not active and TGT is not valid. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [get_server_status] (7): Status of server 'ibm-x3650m4-01-vm-02.testrelm.com' is 'working' (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [get_port_status] (7): Port status of port 0 for server 'ibm-x3650m4-01-vm-02.testrelm.com' is 'working' (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [get_server_status] (7): Status of server 'ibm-x3650m4-01-vm-02.testrelm.com' is 'working' (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [be_resolve_server_done] (7): Saving the first resolved server (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [be_resolve_server_done] (4): Found address for server ibm-x3650m4-01-vm-02.testrelm.com: [10.16.41.15] TTL 7200 (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_find_ccache_step] (9): Recreating ccache file. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [child_handler_setup] (8): Setting up signal handler up for pid [3644] (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [child_handler_setup] (8): Signal handler set up for pid [3644] (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [write_pipe_handler] (6): All data has been sent! (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [read_pipe_handler] (6): EOF received, client finished (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_child_done] (9): child response [0][3][46]. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_child_done] (9): child response [0][-1073741823][32]. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_child_done] (7): TGT times are [1386000536][1386000536][1386086936][0]. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_child_done] (9): child response [0][7][58]. (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [fo_set_port_status] (4): Marking port 0 of server 'ibm-x3650m4-01-vm-02.testrelm.com' as 'working' (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [set_server_common_status] (4): Marking server 'ibm-x3650m4-01-vm-02.testrelm.com' as 'working' (Mon Dec 2 11:08:56 2013) [sssd[be[testrelm.com]]] [krb5_mod_ccname] (9): Save ccname [FILE:/tmp/krb5cc_1235200010_upCaW2] for user [one]. [root@c510 home]# ls /tmp/krb5cc_* /tmp/krb5cc_1235200010_upCaW2
User "one" was able to authenticate using service sshd and gdb on Wed Nov 27 and also got a krb5 ticket. I am not sure why it is different on Mon Dec 2. I can only say that krb5 cache has wrong permissions. (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [check_if_ccache_file_is_used] (1): Cache file [/tmp/krb5cc_1235200001_VAZpq4] exists, but is owned by [0] instead of [1235200007]. Here is related part of logfile sssd_testrelm.com.log: ------------------------------------------------------ (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [be_pam_handler] (4): Got request with the following data (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): domain: testrelm.com (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): user: one (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): service: sshd (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [check_if_ccache_file_is_used] (5): User [1235200001] is not active (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [check_for_valid_tgt] (1): krb5_cc_retrieve_cred failed. (Wed Nov 27 08:27:57 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (9): Ccache_file is [FILE:/tmp/krb5cc_1235200001_UTLFdg] and is not active and TGT is not valid. (Wed Nov 27 08:27:58 2013) [sssd[be[testrelm.com]]] [krb5_mod_ccname] (9): Save ccname [FILE:/tmp/krb5cc_1235200001_j4znYq] for user [one]. (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [be_pam_handler] (4): Got request with the following data (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): domain: testrelm.com (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): user: one (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): service: sshd (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [check_for_valid_tgt] (7): TGT end time [1385645278]. (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [check_for_valid_tgt] (3): TGT is valid. (Wed Nov 27 11:00:36 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (9): Ccache_file is [FILE:/tmp/krb5cc_1235200001_j4znYq] and is not active and TGT is valid. (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [be_pam_handler] (4): Got request with the following data (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): domain: testrelm.com (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): user: one (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): service: gdm (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [check_if_ccache_file_is_used] (9): User [1235200001] is still active, reusing ccache file [/tmp/krb5cc_1235200001_VAZpq4]. (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [check_for_valid_tgt] (1): krb5_cc_retrieve_cred failed. (Wed Nov 27 11:01:58 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (9): Ccache_file is [FILE:/tmp/krb5cc_1235200001_VAZpq4] and is active and TGT is not valid. (Wed Nov 27 11:01:59 2013) [sssd[be[testrelm.com]]] [krb5_mod_ccname] (9): Save ccname [FILE:/tmp/krb5cc_1235200001_VAZpq4] for user [one]. (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [be_pam_handler] (4): Got request with the following data (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): domain: testrelm.com (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): user: one (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): service: gdm (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [check_if_ccache_file_is_used] (9): User [1235200001] is still active, reusing ccache file [/tmp/krb5cc_1235200001_VAZpq4]. (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [check_for_valid_tgt] (7): TGT end time [1385654518]. (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [check_for_valid_tgt] (3): TGT is valid. (Wed Nov 27 11:04:03 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (9): Ccache_file is [FILE:/tmp/krb5cc_1235200001_VAZpq4] and is active and TGT is valid. (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [be_pam_handler] (4): Got request with the following data (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): domain: testrelm.com (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): user: one (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [pam_print_data] (4): service: gdm (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [check_if_ccache_file_is_used] (1): Cache file [/tmp/krb5cc_1235200001_VAZpq4] exists, but is owned by [0] instead of [1235200007]. (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [krb5_auth_send] (1): check_if_ccache_file_is_used failed. (Mon Dec 2 09:43:56 2013) [sssd[be[testrelm.com]]] [ipa_auth_handler_done] (1): krb5_auth_recv request failed./1235200007 q
I am not able to reproduce it on my RHEL5 machine with gdm. We must know steps how to reproduce it. (Exact steps how to get to the state that user's krb5 ticket has wrong permissions)
The ccache is created by the krb5_child process which should drop privileges to the user, sounds like it didn't this time. But I agree we need better steps to reproduce.
After checking with Nalin I found out that I check the krb5 tkt in a wrong way. I ssh to the client machine and do klist in the shell window,in which $KRB5CCNAME is not set.I did GDM login and check in there directly ,klist show up the tkt. Closing as not a bug.Sorry and thanks!!