Bug 974947 - Kerberos credential delegation does not works for IPA.
Kerberos credential delegation does not works for IPA.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Kosek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-17 04:34 EDT by Kaleem
Modified: 2014-02-05 16:50 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 16:50:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kaleem 2013-06-17 04:34:30 EDT
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@TESTRELM.COM: 
[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@f18-ipa-master.testrelm.com klist
Ticket cache: DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt
Default principal: admin@TESTRELM.COM

Valid starting       Expires              Service principal
06/17/2013 13:53:08  06/18/2013 13:53:05  krbtgt/TESTRELM.COM@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@f18-ipa-master.testrelm.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@f18-ipa-master.testrelm.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@TESTRELM.COM
  Email address: httpuser1@testrelm.com
  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@f18-ipa-master.testrelm.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 ~]#
Comment 1 Martin Kosek 2013-06-18 07:11:17 EDT
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@EXAMPLE.COM: 

# ssh fbar@vm-119.example.com "echo 'Secret123' | kinit"
Password for fbar@EXAMPLE.COM: 

# ssh fbar@vm-119.example.com "klist"
klist: No credentials cache found (ticket cache DIR::/run/user/1494000003/krb5cc/tkt)

# ssh fbar@vm-119.example.com "ls /run/user/1494000003/krb5cc/tkt"
ls: cannot access /run/user/1494000003/krb5cc/tkt: No such file or directory

# ssh fbar@vm-119.example.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.
Comment 2 Jakub Hrozek 2013-06-18 08:21:07 EDT
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.
Comment 3 Martin Kosek 2013-06-19 03:17:20 EDT
Ok, thanks. Then I moving this back to krb5 as it was previously.
Comment 4 Nalin Dahyabhai 2013-06-20 13:07:13 EDT
(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@TESTRELM.COM: 
> [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@f18-ipa-master.testrelm.com klist
> Ticket cache: DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt
> Default principal: admin@TESTRELM.COM
> 
> Valid starting       Expires              Service principal
> 06/17/2013 13:53:08  06/18/2013 13:53:05  krbtgt/TESTRELM.COM@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@f18-ipa-master.testrelm.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@f18-ipa-master.testrelm.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@TESTRELM.COM
>   Email address: httpuser1@testrelm.com
>   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@f18-ipa-master.testrelm.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?
Comment 5 Nalin Dahyabhai 2013-06-20 13:10:49 EDT
(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).
Comment 6 Kaleem 2013-06-21 05:08:35 EDT
(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@TESTRELM.COM: 
> > [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@f18-ipa-master.testrelm.com klist
> > Ticket cache: DIR::/tmp/krb5cc_1628800000_57IOryBB49/tkt
> > Default principal: admin@TESTRELM.COM
> > 
> > Valid starting       Expires              Service principal
> > 06/17/2013 13:53:08  06/18/2013 13:53:05  krbtgt/TESTRELM.COM@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@TESTRELM.COM             FILE:/tmp/krb5cc_0
[root@f18-ipa-client1 ~]#

[root@f18-ipa-client1 ~]# klist -A
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@TESTRELM.COM
Valid starting       Expires              Service principal
06/21/2013 14:13:45  06/22/2013 14:13:43  krbtgt/TESTRELM.COM@TESTRELM.COM
[root@f18-ipa-client1 ~]#

[root@f18-ipa-client1 ~]# klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@TESTRELM.COM
Valid starting       Expires              Service principal
06/21/2013 14:13:45  06/22/2013 14:13:43  krbtgt/TESTRELM.COM@TESTRELM.COM
[root@f18-ipa-client1 ~]#

[root@f18-ipa-client1 ~]# ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes -o StrictHostKeyChecking=no admin@f18-ipa-master.testrelm.com klist
Ticket cache: DIR::/tmp/krb5cc_990600000_m0k4zAM4DG/tkt
Default principal: admin@TESTRELM.COM
Valid starting       Expires              Service principal
06/21/2013 14:14:14  06/22/2013 14:13:43  krbtgt/TESTRELM.COM@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@f18-ipa-master.testrelm.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@f18-ipa-master.testrelm.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@TESTRELM.COM
> >   Email address: httpuser1@testrelm.com
> >   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@f18-ipa-master.testrelm.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@f18-ipa-master.testrelm.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@TESTRELM.COM             FILE:/tmp/krb5cc_0
[root@f18-ipa-client1 ~]# klist -A
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@TESTRELM.COM

Valid starting       Expires              Service principal
06/21/2013 14:13:45  06/22/2013 14:13:43  krbtgt/TESTRELM.COM@TESTRELM.COM
06/21/2013 14:14:14  06/22/2013 14:13:43  host/f18-ipa-master.testrelm.com@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@TESTRELM.COM
Valid starting       Expires              Service principal
06/21/2013 14:13:45  06/22/2013 14:13:43  krbtgt/TESTRELM.COM@TESTRELM.COM
06/21/2013 14:14:14  06/22/2013 14:13:43  host/f18-ipa-master.testrelm.com@TESTRELM.COM
[root@f18-ipa-client1 ~]# ssh admin@f18-ipa-master.testrelm.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@f18-ipa-master.testrelm.com
admin@f18-ipa-master.testrelm.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@TESTRELM.COM
Valid starting       Expires              Service principal
06/21/2013 14:31:29  06/22/2013 14:31:29  krbtgt/TESTRELM.COM@TESTRELM.COM
[admin@f18-ipa-master ~]$

[admin@f18-ipa-master ~]$ touch abc.txt
touch: cannot touch ‘abc.txt’: Permission denied
[admin@f18-ipa-master ~]$
Comment 7 Nalin Dahyabhai 2013-06-25 18:09:40 EDT
(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@TESTRELM.COM             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@TESTRELM.COM
> Valid starting       Expires              Service principal
> 06/21/2013 14:13:45  06/22/2013 14:13:43  krbtgt/TESTRELM.COM@TESTRELM.COM
> 06/21/2013 14:14:14  06/22/2013 14:13:43 
> host/f18-ipa-master.testrelm.com@TESTRELM.COM
> [root@f18-ipa-client1 ~]# ssh admin@f18-ipa-master.testrelm.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@f18-ipa-master.testrelm.com
> admin@f18-ipa-master.testrelm.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@TESTRELM.COM
> Valid starting       Expires              Service principal
> 06/21/2013 14:31:29  06/22/2013 14:31:29  krbtgt/TESTRELM.COM@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?
Comment 8 Kaleem 2013-07-01 11:48:26 EDT
(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@TESTRELM.COM             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@f18-ipa-master.testrelm.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@TESTRELM.COM

Valid starting       Expires              Service principal
07/01/2013 21:14:12  07/02/2013 21:10:25  krbtgt/TESTRELM.COM@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@f18-ipa-master.testrelm.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 ~]$
Comment 9 Fedora End Of Life 2013-12-21 09:02:18 EST
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.
Comment 10 Fedora End Of Life 2014-02-05 16:50:54 EST
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.

Note You need to log in before you can comment on or make changes to this bug.