Bug 974947
| Summary: | Kerberos credential delegation does not works for IPA. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kaleem <ksiddiqu> |
| Component: | krb5 | Assignee: | Martin Kosek <mkosek> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | dpal, extras-orphan, jhrozek, ksiddiqu, nalin, nathaniel, ssorce |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-02-05 21:50:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I do not think this is an IPA problem. I think it lies in client libraries. The directory where the credentials are supposed to be simply does not exist. This is an output with following packages being installed on vm-119.example.com: freeipa-server-3.2.1-1.fc19.x86_64 krb5-libs-1.11.3-1.fc19.x86_64 # kinit fbar Password for fbar: # ssh fbar.com "echo 'Secret123' | kinit" Password for fbar: # ssh fbar.com "klist" klist: No credentials cache found (ticket cache DIR::/run/user/1494000003/krb5cc/tkt) # ssh fbar.com "ls /run/user/1494000003/krb5cc/tkt" ls: cannot access /run/user/1494000003/krb5cc/tkt: No such file or directory # ssh fbar.com "ls /run/user/1494000003/" total 0 drwx------. 2 fbar fbar 40 Jun 18 19:08 . drwxr-xr-x. 5 root root 100 Jun 18 19:08 .. I am thinking that this issue may be related to Bug 961235. Jakub, is this an SSSD bug? If not, I would just put it back to krb5. If you can reproduce the problem with bare kinit then it's completely unrelated to SSSD. SSSD would create the directory when the user logs in via SSSD, but kinit goes straight to KDC. Ok, thanks. Then I moving this back to krb5 as it was previously. (In reply to Kaleem from comment #0) > Description of problem: > Kerberos credential delegation does not seems to work for IPA. > > Version-Release number of selected component (if applicable): > [root@f18-ipa-master ~]# rpm -q krb5-server freeipa-server > krb5-server-1.11.2-5.fc18.x86_64 > freeipa-server-3.2.99-0.20130613T1542Zgit851b091.fc18.x86_64 > [root@f18-ipa-master ~]# > > How reproducible: > Always > > Steps to Reproduce: > 1. Get admin kerberos credentials on client > [root@f18-ipa-client1 ~]# kinit admin > Password for admin: > [root@f18-ipa-client1 ~]# > > 2. Do klist on IPA server using delegation > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > admin.com klist > Ticket cache: DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt > Default principal: admin > > Valid starting Expires Service principal > 06/17/2013 13:53:08 06/18/2013 13:53:05 krbtgt/TESTRELM.COM > [root@f18-ipa-client1 ~]# What's the value of $KRB5CCNAME in this shell? You'd get this output from klist for either DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt or DIR:/tmp/krb5cc_1628800000_57IOryBB49. The output of "klist -l" or "klist -A" would also help us tell which of those is the case here. > 3. Run "kinit admin" on master from using delegation of kerberos credentials > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > admin.com "echo Secret123|kinit admin" > kinit: Can't create new subsidiary cache because default cache is not a > directory collection while generating new ccache > [root@f18-ipa-client1 ~]# This suggests DIR::, and if you're hitting this we may need to revisit how sshd is setting up caches with delegated credentials. > Additional info: > 1. Following is another example with different error message. > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > admin.com echo xxxxxxxx | ipa user-add > --first=httpuser1 --last=httpuser1 --password httpuser1 > ---------------------- > Added user "httpuser1" > ---------------------- > User login: httpuser1 > First name: httpuser1 > Last name: httpuser1 > Full name: httpuser1 httpuser1 > Display name: httpuser1 httpuser1 > Initials: hh > Home directory: /home/httpuser1 > GECOS field: httpuser1 httpuser1 > Login shell: /bin/sh > Kerberos principal: httpuser1 > Email address: httpuser1 > UID: 1628800001 > GID: 1628800001 > Password: True > Member of groups: ipausers > Kerberos keys available: True Which of the prompts were you supplying an answer to there? It's not the simplest thing to decipher. > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > admin.com ipa service-add > HTTP/f18-ipa-client1.testrelm.com > ipa: ERROR: Cannot open log file u'/home/admin/.ipa/log/cli.log': [Errno 13] > Permission denied: u'/home/admin/.ipa/log/cli.log' > ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may > provide more information', 851968)/('No Kerberos credentials available', > -1765328243) > [root@f18-ipa-client1 ~]# What credential cache was the command attempting to read and use? What was $KRB5CCNAME set to, and what was in that location? Between the two runs, did those change? Why did this hit a permission error? Is the admin user not allowed to write to their home directory? (In reply to Martin Kosek from comment #1) > I do not think this is an IPA problem. I think it lies in client libraries. > The directory where the credentials are supposed to be simply does not exist. > > This is an output with following packages being installed on > vm-119.example.com: > freeipa-server-3.2.1-1.fc19.x86_64 > krb5-libs-1.11.3-1.fc19.x86_64 krb5 1.11 from F19 and krb5 1.10 from F18 differ in at least a couple of ways: * If the location of a DIR: ccache name doesn't exist but its parent does, 1.11 will create it when you try to access the ccache, while 1.10 did not. * We configure F19's packages to look in a different location (DIR:/run/user/$UID/krb5cc) for the ccache than we did in F18 (the default default of FILE:/tmp/krb5cc_$UID). (In reply to Nalin Dahyabhai from comment #4) > (In reply to Kaleem from comment #0) > > Description of problem: > > Kerberos credential delegation does not seems to work for IPA. > > > > Version-Release number of selected component (if applicable): > > [root@f18-ipa-master ~]# rpm -q krb5-server freeipa-server > > krb5-server-1.11.2-5.fc18.x86_64 > > freeipa-server-3.2.99-0.20130613T1542Zgit851b091.fc18.x86_64 > > [root@f18-ipa-master ~]# > > > > How reproducible: > > Always > > > > Steps to Reproduce: > > 1. Get admin kerberos credentials on client > > [root@f18-ipa-client1 ~]# kinit admin > > Password for admin: > > [root@f18-ipa-client1 ~]# > > > > 2. Do klist on IPA server using delegation > > > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > > admin.com klist > > Ticket cache: DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt > > Default principal: admin > > > > Valid starting Expires Service principal > > 06/17/2013 13:53:08 06/18/2013 13:53:05 krbtgt/TESTRELM.COM > > [root@f18-ipa-client1 ~]# > > What's the value of $KRB5CCNAME in this shell? You'd get this output from > klist for either DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt or > DIR:/tmp/krb5cc_1628800000_57IOryBB49. The output of "klist -l" or "klist > -A" would also help us tell which of those is the case here. Its pointing to FILE:/tmp/krb5cc_0 [root@f18-ipa-client1 ~]# klist -l Principal name Cache name -------------- ---------- admin FILE:/tmp/krb5cc_0 [root@f18-ipa-client1 ~]# [root@f18-ipa-client1 ~]# klist -A Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin Valid starting Expires Service principal 06/21/2013 14:13:45 06/22/2013 14:13:43 krbtgt/TESTRELM.COM [root@f18-ipa-client1 ~]# [root@f18-ipa-client1 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin Valid starting Expires Service principal 06/21/2013 14:13:45 06/22/2013 14:13:43 krbtgt/TESTRELM.COM [root@f18-ipa-client1 ~]# [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com klist Ticket cache: DIR::/tmp/krb5cc_990600000_m0k4zAM4DG/tkt Default principal: admin Valid starting Expires Service principal 06/21/2013 14:14:14 06/22/2013 14:13:43 krbtgt/TESTRELM.COM [root@f18-ipa-client1 ~]# > > > 3. Run "kinit admin" on master from using delegation of kerberos credentials > > > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > > admin.com "echo Secret123|kinit admin" > > kinit: Can't create new subsidiary cache because default cache is not a > > directory collection while generating new ccache > > [root@f18-ipa-client1 ~]# > > This suggests DIR::, and if you're hitting this we may need to revisit how > sshd is setting up caches with delegated credentials. > > > Additional info: > > 1. Following is another example with different error message. > > > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > > admin.com echo xxxxxxxx | ipa user-add > > --first=httpuser1 --last=httpuser1 --password httpuser1 > > ---------------------- > > Added user "httpuser1" > > ---------------------- > > User login: httpuser1 > > First name: httpuser1 > > Last name: httpuser1 > > Full name: httpuser1 httpuser1 > > Display name: httpuser1 httpuser1 > > Initials: hh > > Home directory: /home/httpuser1 > > GECOS field: httpuser1 httpuser1 > > Login shell: /bin/sh > > Kerberos principal: httpuser1 > > Email address: httpuser1 > > UID: 1628800001 > > GID: 1628800001 > > Password: True > > Member of groups: ipausers > > Kerberos keys available: True > > Which of the prompts were you supplying an answer to there? It's not the > simplest thing to decipher. for --password parameter > > > [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o > > GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no > > admin.com ipa service-add > > HTTP/f18-ipa-client1.testrelm.com > > ipa: ERROR: Cannot open log file u'/home/admin/.ipa/log/cli.log': [Errno 13] > > Permission denied: u'/home/admin/.ipa/log/cli.log' > > ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may > > provide more information', 851968)/('No Kerberos credentials available', > > -1765328243) > > [root@f18-ipa-client1 ~]# > > What credential cache was the command attempting to read and use? What was > $KRB5CCNAME set to, and what was in that location? Between the two runs, > did those change? Why did this hit a permission error? Is the admin user > not allowed to write to their home directory? Same credential cache was being used and it did not change between the runs. [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com ipa service-add HTTP/f18-ipa-client1.testrelm.com ipa: ERROR: Cannot open log file u'/home/admin/.ipa/log/cli.log': [Errno 13] Permission denied: u'/home/admin/.ipa/log/cli.log' ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('No Kerberos credentials available', -1765328243) [root@f18-ipa-client1 ~]# klist -l Principal name Cache name -------------- ---------- admin FILE:/tmp/krb5cc_0 [root@f18-ipa-client1 ~]# klist -A Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin Valid starting Expires Service principal 06/21/2013 14:13:45 06/22/2013 14:13:43 krbtgt/TESTRELM.COM 06/21/2013 14:14:14 06/22/2013 14:13:43 host/f18-ipa-master.testrelm.com [root@f18-ipa-client1 ~]# For admin user's permission, i observed following (1)ssh to Master using gssapi authentication [root@f18-ipa-client1 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin Valid starting Expires Service principal 06/21/2013 14:13:45 06/22/2013 14:13:43 krbtgt/TESTRELM.COM 06/21/2013 14:14:14 06/22/2013 14:13:43 host/f18-ipa-master.testrelm.com [root@f18-ipa-client1 ~]# ssh admin.com Last login: Fri Jun 21 14:29:17 2013 from 10.65.207.109 [admin@f18-ipa-master ~]$ [admin@f18-ipa-master ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_990600000) [admin@f18-ipa-master ~]$ [admin@f18-ipa-master ~]$ touch abc.txt touch: cannot touch ‘abc.txt’: Permission denied [admin@f18-ipa-master ~]$ (2)ssh to Master using passwrod authenticaion [root@f18-ipa-client1 ~]# ssh admin.com admin.com's password: Last login: Fri Jun 21 14:29:25 2013 from 10.65.207.109 [admin@f18-ipa-master ~]$ [admin@f18-ipa-master ~]$ klist Ticket cache: DIR::/run/user/990600000/krb5cc/tktIROIdk Default principal: admin Valid starting Expires Service principal 06/21/2013 14:31:29 06/22/2013 14:31:29 krbtgt/TESTRELM.COM [admin@f18-ipa-master ~]$ [admin@f18-ipa-master ~]$ touch abc.txt touch: cannot touch ‘abc.txt’: Permission denied [admin@f18-ipa-master ~]$ (In reply to Kaleem from comment #6) > (In reply to Nalin Dahyabhai from comment #4) > > What's the value of $KRB5CCNAME in this shell? You'd get this output from > > klist for either DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt or > > DIR:/tmp/krb5cc_1628800000_57IOryBB49. The output of "klist -l" or "klist > > -A" would also help us tell which of those is the case here. > > Its pointing to FILE:/tmp/krb5cc_0 > > [root@f18-ipa-client1 ~]# klist -l > Principal name Cache name > -------------- ---------- > admin FILE:/tmp/krb5cc_0 And on the SSH server, where you're seeing problem behavior? > For admin user's permission, i observed following > > (1)ssh to Master using gssapi authentication > > [root@f18-ipa-client1 ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin > Valid starting Expires Service principal > 06/21/2013 14:13:45 06/22/2013 14:13:43 krbtgt/TESTRELM.COM > 06/21/2013 14:14:14 06/22/2013 14:13:43 > host/f18-ipa-master.testrelm.com > [root@f18-ipa-client1 ~]# ssh admin.com > Last login: Fri Jun 21 14:29:17 2013 from 10.65.207.109 > [admin@f18-ipa-master ~]$ > > [admin@f18-ipa-master ~]$ klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_990600000) > [admin@f18-ipa-master ~]$ > > [admin@f18-ipa-master ~]$ touch abc.txt > touch: cannot touch ‘abc.txt’: Permission denied > [admin@f18-ipa-master ~]$ > > (2)ssh to Master using passwrod authenticaion > > [root@f18-ipa-client1 ~]# ssh admin.com > admin.com's password: > Last login: Fri Jun 21 14:29:25 2013 from 10.65.207.109 > [admin@f18-ipa-master ~]$ > > [admin@f18-ipa-master ~]$ klist > Ticket cache: DIR::/run/user/990600000/krb5cc/tktIROIdk > Default principal: admin > Valid starting Expires Service principal > 06/21/2013 14:31:29 06/22/2013 14:31:29 krbtgt/TESTRELM.COM > [admin@f18-ipa-master ~]$ > > [admin@f18-ipa-master ~]$ touch abc.txt > touch: cannot touch ‘abc.txt’: Permission denied > [admin@f18-ipa-master ~]$ What's causing this error? Who owns the directory? Is it local, or mounted remotely? If remotely, is there anything in the logs on either the filesystem client or server that indicates a cause? Is there anything in the system's audit log? (In reply to Nalin Dahyabhai from comment #7) > (In reply to Kaleem from comment #6) > > (In reply to Nalin Dahyabhai from comment #4) > > > What's the value of $KRB5CCNAME in this shell? You'd get this output from > > > klist for either DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt or > > > DIR:/tmp/krb5cc_1628800000_57IOryBB49. The output of "klist -l" or "klist > > > -A" would also help us tell which of those is the case here. > > > > Its pointing to FILE:/tmp/krb5cc_0 > > > > [root@f18-ipa-client1 ~]# klist -l > > Principal name Cache name > > -------------- ---------- > > admin FILE:/tmp/krb5cc_0 > > And on the SSH server, where you're seeing problem behavior? [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com Last login: Mon Jul 1 21:12:31 2013 from 10.65.207.109 [admin@f18-ipa-master ~]$ [admin@f18-ipa-master ~]$ klist Ticket cache: DIR::/tmp/krb5cc_1084800000_omONuvdPai/tkt Default principal: admin Valid starting Expires Service principal 07/01/2013 21:14:12 07/02/2013 21:10:25 krbtgt/TESTRELM.COM [admin@f18-ipa-master ~]$ [root@f18-ipa-master ~]# ls -la /tmp/krb5cc_1084800000_omONuvdPai/tkt -rw-------. 1 admin admins 539 Jul 1 21:14 /tmp/krb5cc_1084800000_omONuvdPai/tkt [root@f18-ipa-master ~]# > > > > > [admin@f18-ipa-master ~]$ touch abc.txt > > touch: cannot touch ‘abc.txt’: Permission denied > > [admin@f18-ipa-master ~]$ > > What's causing this error? Who owns the directory? Is it local, or mounted > remotely? If remotely, is there anything in the logs on either the > filesystem client or server that indicates a cause? Is there anything in > the system's audit log? This error is no more there. I un-installed IPA server, removed /home/admin, installed IPA server again. [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com Creating home directory for admin. Last login: Mon Jul 1 20:52:38 2013 from 10.65.207.109 [admin@f18-ipa-master ~]$ touch abc.txt [admin@f18-ipa-master ~]$ cat abc.txt [admin@f18-ipa-master ~]$ ls abc.txt [admin@f18-ipa-master ~]$ This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Kerberos credential delegation does not seems to work for IPA. Version-Release number of selected component (if applicable): [root@f18-ipa-master ~]# rpm -q krb5-server freeipa-server krb5-server-1.11.2-5.fc18.x86_64 freeipa-server-3.2.99-0.20130613T1542Zgit851b091.fc18.x86_64 [root@f18-ipa-master ~]# How reproducible: Always Steps to Reproduce: 1. Get admin kerberos credentials on client [root@f18-ipa-client1 ~]# kinit admin Password for admin: [root@f18-ipa-client1 ~]# 2. Do klist on IPA server using delegation [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com klist Ticket cache: DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt Default principal: admin Valid starting Expires Service principal 06/17/2013 13:53:08 06/18/2013 13:53:05 krbtgt/TESTRELM.COM [root@f18-ipa-client1 ~]# 3. Run "kinit admin" on master from using delegation of kerberos credentials [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com "echo Secret123|kinit admin" kinit: Can't create new subsidiary cache because default cache is not a directory collection while generating new ccache [root@f18-ipa-client1 ~]# Actual results: Command ran in step (3) above is failing using GSSAPIDelegateCredentials option Expected results: Command ran in step (3) above should have been successful using GSSAPIDelegateCredentials option Additional info: 1. Following is another example with different error message. [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com echo xxxxxxxx | ipa user-add --first=httpuser1 --last=httpuser1 --password httpuser1 ---------------------- Added user "httpuser1" ---------------------- User login: httpuser1 First name: httpuser1 Last name: httpuser1 Full name: httpuser1 httpuser1 Display name: httpuser1 httpuser1 Initials: hh Home directory: /home/httpuser1 GECOS field: httpuser1 httpuser1 Login shell: /bin/sh Kerberos principal: httpuser1 Email address: httpuser1 UID: 1628800001 GID: 1628800001 Password: True Member of groups: ipausers Kerberos keys available: True [root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin.com ipa service-add HTTP/f18-ipa-client1.testrelm.com ipa: ERROR: Cannot open log file u'/home/admin/.ipa/log/cli.log': [Errno 13] Permission denied: u'/home/admin/.ipa/log/cli.log' ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('No Kerberos credentials available', -1765328243) [root@f18-ipa-client1 ~]#