Hi,
yesterday I noticed a strange issue on a Centos 7 client running ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again after GNOME failed to load (/home on kerberized NFS4). Closer inspection showed that she had no permission to access her home directory, so GNOME was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory, as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked immediately.
Questions: - What could be the reason for this behaviour? The box was freshly booted and I don't see what might have been wrong with the first ticket. - Where should I look (which logs, etc.) to investigate this further?
Regards, Ray
On Tue, Nov 21, 2017 at 08:36:16AM +0100, Ray via FreeIPA-users wrote:
Hi,
yesterday I noticed a strange issue on a Centos 7 client running ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again after GNOME failed to load (/home on kerberized NFS4). Closer inspection showed that she had no permission to access her home directory, so GNOME was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory, as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked immediately.
Questions:
- What could be the reason for this behaviour? The box was freshly booted
and I don't see what might have been wrong with the first ticket.
- Where should I look (which logs, etc.) to investigate this further?
Does the faulty user account come from the IPA domain or a trusted AD domain?
Am 2017-11-21 11:26, schrieb Jakub Hrozek via FreeIPA-users:
On Tue, Nov 21, 2017 at 08:36:16AM +0100, Ray via FreeIPA-users wrote:
Hi,
yesterday I noticed a strange issue on a Centos 7 client running ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again after GNOME failed to load (/home on kerberized NFS4). Closer inspection showed that she had no permission to access her home directory, so GNOME was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory, as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked immediately.
Questions:
- What could be the reason for this behaviour? The box was freshly
booted and I don't see what might have been wrong with the first ticket.
- Where should I look (which logs, etc.) to investigate this
further?
Does the faulty user account come from the IPA domain or a trusted AD domain?
I'm running FreeIPA 4.5 with four repicas on CentOS 7. No AD around anywhere.
Server version: ipa-server-4.5.0-21.el7.centos.2.2.x86_64
Another weird thing is that I was able to log in without issues on the same client when my daughter couldn't. My account comes from the same group of FreeIPA Servers/replicas.
Best, Ray
On Tue, Nov 21, 2017 at 11:45:36AM +0100, Ray via FreeIPA-users wrote:
Am 2017-11-21 11:26, schrieb Jakub Hrozek via FreeIPA-users:
On Tue, Nov 21, 2017 at 08:36:16AM +0100, Ray via FreeIPA-users wrote:
Hi,
yesterday I noticed a strange issue on a Centos 7 client running ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again after GNOME failed to load (/home on kerberized NFS4). Closer inspection showed that she had no permission to access her home directory, so GNOME was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory, as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked immediately.
Questions:
- What could be the reason for this behaviour? The box was freshly
booted and I don't see what might have been wrong with the first ticket.
- Where should I look (which logs, etc.) to investigate this
further?
Does the faulty user account come from the IPA domain or a trusted AD domain?
I'm running FreeIPA 4.5 with four repicas on CentOS 7. No AD around anywhere.
Server version: ipa-server-4.5.0-21.el7.centos.2.2.x86_64
Another weird thing is that I was able to log in without issues on the same client when my daughter couldn't. My account comes from the same group of FreeIPA Servers/replicas.
Hm, I was asking because there used to be some issues with readin unixHomeDirectory from AD Global Catalog, which manifested as randomly removing the home directory value..but that's not the case for you I guess..
Is the issue reproducable? Does "getent passwd $username" show "/" as the homedir?
Am 2017-11-21 11:51, schrieb Jakub Hrozek via FreeIPA-users:
On Tue, Nov 21, 2017 at 11:45:36AM +0100, Ray via FreeIPA-users wrote:
Am 2017-11-21 11:26, schrieb Jakub Hrozek via FreeIPA-users:
On Tue, Nov 21, 2017 at 08:36:16AM +0100, Ray via FreeIPA-users wrote:
Hi,
yesterday I noticed a strange issue on a Centos 7 client running ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again after GNOME failed to load (/home on kerberized NFS4). Closer inspection showed that she had no permission to access her home directory, so GNOME was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory, as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked immediately.
Questions:
- What could be the reason for this behaviour? The box was freshly
booted and I don't see what might have been wrong with the first ticket.
- Where should I look (which logs, etc.) to investigate this
further?
Does the faulty user account come from the IPA domain or a trusted AD domain?
I'm running FreeIPA 4.5 with four repicas on CentOS 7. No AD around anywhere.
Server version: ipa-server-4.5.0-21.el7.centos.2.2.x86_64
Another weird thing is that I was able to log in without issues on the same client when my daughter couldn't. My account comes from the same group of FreeIPA Servers/replicas.
Hm, I was asking because there used to be some issues with readin unixHomeDirectory from AD Global Catalog, which manifested as randomly removing the home directory value..but that's not the case for you I guess..
Is the issue reproducable? Does "getent passwd $username" show "/" as the homedir?
The "/" as homedir is easily explained: when then homedir is no exitsting, users get "/" as their home directory. In my daughter's case, the ticket she initially got was not fit to grant NFS access to her access home directory, this is why she ended up in "/".
The actual question for me is: how come there was an issue with the ticket in the first place? After fetching a new ticket with kinit, everything worked as expected, i.e., the ticket she received during login was invalid.
Could this indicate issues with the IPA replication?
Best, Ray
On Tue, Nov 21, 2017 at 12:39:00PM +0100, Ray via FreeIPA-users wrote:
Am 2017-11-21 11:51, schrieb Jakub Hrozek via FreeIPA-users:
On Tue, Nov 21, 2017 at 11:45:36AM +0100, Ray via FreeIPA-users wrote:
Am 2017-11-21 11:26, schrieb Jakub Hrozek via FreeIPA-users:
On Tue, Nov 21, 2017 at 08:36:16AM +0100, Ray via FreeIPA-users wrote:
Hi,
yesterday I noticed a strange issue on a Centos 7 client running ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again after GNOME failed to load (/home on kerberized NFS4). Closer inspection showed that she had no permission to access her home directory, so GNOME was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory, as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked immediately.
Questions:
- What could be the reason for this behaviour? The box was freshly
booted and I don't see what might have been wrong with the first ticket.
- Where should I look (which logs, etc.) to investigate this
further?
Does the faulty user account come from the IPA domain or a trusted AD domain?
I'm running FreeIPA 4.5 with four repicas on CentOS 7. No AD around anywhere.
Server version: ipa-server-4.5.0-21.el7.centos.2.2.x86_64
Another weird thing is that I was able to log in without issues on the same client when my daughter couldn't. My account comes from the same group of FreeIPA Servers/replicas.
Hm, I was asking because there used to be some issues with readin unixHomeDirectory from AD Global Catalog, which manifested as randomly removing the home directory value..but that's not the case for you I guess..
Is the issue reproducable? Does "getent passwd $username" show "/" as the homedir?
The "/" as homedir is easily explained: when then homedir is no exitsting, users get "/" as their home directory.
You mean not existing (or accessible I guess in this case) on the filesystem level, as in, getent passwd $username would show the real username, but you can't cd there?
Then yes, I agree. Sorry, I was focusing on the narrow case where the nsswitch wouldn't report the correct homedir in the first place..
In my daughter's case, the ticket she initially got was not fit to grant NFS access to her access home directory, this is why she ended up in "/".
The actual question for me is: how come there was an issue with the ticket in the first place? After fetching a new ticket with kinit, everything worked as expected, i.e., the ticket she received during login was invalid.
What exactly do you mean by 'ticket was not fit'? What was the klist output when she logged in? Was the ticket by chance expired or even from the start of the UNIX epoch?
freeipa-users@lists.fedorahosted.org
-
Jakub Hrozek -
Ray