Hi,
We have a few machines that joined a FreeIPA instance. We use NFSv4 + kerberos to mount home directories.
However, if the user do not log on to the machine for more than 7 days, and he leaves a job executing and that writes to some file on his home directory, the cpu usage of the machine goes up to the sky and the machine gets almost unusable.
Is there a good strategy to fetch new TGT's when near expiration? I know some users generate a key tab (or fetch them using ipa-getkeytab) to automate a kinit, but I wonder if we could come with a system-wide solution that doesn't lead to storing key tabs around.
Any tips for that?
Best,
On 06.04.22 21:39, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
We have a few machines that joined a FreeIPA instance. We use NFSv4 + kerberos to mount home directories.
However, if the user do not log on to the machine for more than 7 days, and he leaves a job executing and that writes to some file on his home directory, the cpu usage of the machine goes up to the sky and the machine gets almost unusable.
Is there a good strategy to fetch new TGT's when near expiration? I know some users generate a key tab (or fetch them using ipa-getkeytab) to automate a kinit, but I wonder if we could come with a system-wide solution that doesn't lead to storing key tabs around.
Any tips for that?
One way could be
ipa-getkeytab -s ipaserver.somedomain.com -p someipauser@SOMEDOMAIN.COM -P -k ./someipauser.keytab export KRB5_CLIENT_KTNAME /some/path/to/someipauser.keytab
Cheers, Ronald
--- Francis Augusto Medeiros-Logeay Oslo, Norway
On 2022-04-07 12:03, Ronald Wimmer via FreeIPA-users wrote:
On 06.04.22 21:39, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
We have a few machines that joined a FreeIPA instance. We use NFSv4 + kerberos to mount home directories.
However, if the user do not log on to the machine for more than 7 days, and he leaves a job executing and that writes to some file on his home directory, the cpu usage of the machine goes up to the sky and the machine gets almost unusable.
Is there a good strategy to fetch new TGT's when near expiration? I know some users generate a key tab (or fetch them using ipa-getkeytab) to automate a kinit, but I wonder if we could come with a system-wide solution that doesn't lead to storing key tabs around.
Any tips for that?
One way could be
ipa-getkeytab -s ipaserver.somedomain.com -p someipauser@SOMEDOMAIN.COM -P -k ./someipauser.keytab export KRB5_CLIENT_KTNAME /some/path/to/someipauser.keytab
Thanks Ronald. So as long as a keytab is generated and the variable is setup, so will FreeIPA automatically use it to fetch a new TGT when the older one expires after 7 days?
Best,
Francis
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
So as long as a keytab is generated and the variable is setup, so will FreeIPA automatically use it to fetch a new TGT when the older one
expires after 7 days?
You need something to automate the process of obtaining a ticket-granting-ticket every so often.
Check out kstart https://www.eyrie.org/~eagle/software/kstart/ for this purpose. The user needs to run their job via k5start, and k5start takes on the job of obtaining and renewing a TGT while the job is running.
If you can't use kstart, something else will have to keep running 'kinit -k -i' every so often. I suggest the '-i' argument because it uses a standard well-known keytab location; you only have to drop your keytab at that location & make sure the user can read it, and kinit is clever enough to figure out the principal name itself. The location is documented in the kerberos(7) man page - look for KRB5_CLIENT_KTNAME (or just run 'kinit -k -i' and it will spit out the location it's looking for in the error message).
On 2022-04-08 10:22, Sam Morris via FreeIPA-users wrote:
You need something to automate the process of obtaining a ticket-granting-ticket every so often.
Check out kstart https://www.eyrie.org/~eagle/software/kstart/ for this purpose. The user needs to run their job via k5start, and k5start takes on the job of obtaining and renewing a TGT while the job is running.
If you can't use kstart, something else will have to keep running 'kinit -k -i' every so often. I suggest the '-i' argument because it uses a standard well-known keytab location; you only have to drop your keytab at that location & make sure the user can read it, and kinit is clever enough to figure out the principal name itself. The location is documented in the kerberos(7) man page - look for KRB5_CLIENT_KTNAME (or just run 'kinit -k -i' and it will spit out the location it's looking for in the error message).
Thanks Sam,
I've looked k5start before, and, correct me if I am wrong, but the difference between using a `kinit -k -i | -t keytab` and k5start is that the later takes care of the daemonization aspect, right? As I see it, both need a keytab to work. The issue for me here is that it is a bit undesirable to leave a keytab around. What I like about FreeIPA is that you can fetch the keytab from a cached credential, so that it you could fetch it, use k5start or kinit -kt, and then erase it.
I guess there's no way to renew those tickets without a keytab, right?
On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
-- Francis Augusto Medeiros-Logeay Oslo, Norway
On 2022-04-08 10:22, Sam Morris via FreeIPA-users wrote:
You need something to automate the process of obtaining a ticket-granting-ticket every so often.
Check out kstart https://www.eyrie.org/~eagle/software/kstart/ for this purpose. The user needs to run their job via k5start, and k5start takes on the job of obtaining and renewing a TGT while the job is running.
If you can't use kstart, something else will have to keep running 'kinit -k -i' every so often. I suggest the '-i' argument because it uses a standard well-known keytab location; you only have to drop your keytab at that location & make sure the user can read it, and kinit is clever enough to figure out the principal name itself. The location is documented in the kerberos(7) man page - look for KRB5_CLIENT_KTNAME (or just run 'kinit -k -i' and it will spit out the location it's looking for in the error message).
Thanks Sam,
I've looked k5start before, and, correct me if I am wrong, but the difference between using a `kinit -k -i | -t keytab` and k5start is that the later takes care of the daemonization aspect, right? As I see it, both need a keytab to work. The issue for me here is that it is a bit undesirable to leave a keytab around. What I like about FreeIPA is that you can fetch the keytab from a cached credential, so that it you could fetch it, use k5start or kinit -kt, and then erase it.
I guess there's no way to renew those tickets without a keytab, right?
Nope -- unless you store that password somewhere and run a systemd timer, effectively.
If you store your user credentials into a keytab and just set KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used to replace k5start.
Alternatively, gssproxy could be used for that. It already knows how to handle NFS, for example, so it would work just fine. But it also expects to have a keytab in a proper place.
On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
I've looked k5start before, and, correct me if I am wrong, but the difference between using a `kinit -k -i | -t keytab` and k5start is that the later takes care of the daemonization aspect, right? As I see it, both need a keytab to work. The issue for me here is that it is a bit undesirable to leave a keytab around. What I like about FreeIPA is that you can fetch the keytab from a cached credential, so that it you could fetch it, use k5start or kinit -kt, and then erase it.
I guess there's no way to renew those tickets without a keytab, right?
Nope -- unless you store that password somewhere and run a systemd timer, effectively.
If you store your user credentials into a keytab and just set KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used to replace k5start.
Alternatively, gssproxy could be used for that. It already knows how to handle NFS, for example, so it would work just fine. But it also expects to have a keytab in a proper place.
Thanks a lot, Alexander.
I am clueless now on how to solve this. We experienced that, on machines where the user uses nfsv4+kerberos to mount their home directory, what happens is that if the user has some job that writes to some file on his home directory, the machine goes bananas if the ticket expires (ie, if the user goes on vacation and doesn't log in). This is already a problem for a machine with one user, imagine when the machine has dozens of users. This happened with a RHEL 8.5, and I see no remedy for this, other than:
- storing a user keytab somewhere in his home folder, and use a mechanism (k5start, crond, etc) to fetch new TGT's, but seems to be a potential security risk; - having some cron job that checks for expired credentials and kills all processes of that user to avoid a problem with the machine.
Would you have any idea of something out of these lines?
Best,
Francis
Had a prior employer that solved this with non-human accounts to run automatic process that humans could sudu-su to become and make operational changes. Sysadmin setup keytabs for those process accounts. Jobs ran. People took time off. Security was solid. The accounts with keytabs could not login. Cron and systemd timers ran jobs.
On April 8, 2022 2:19:26 PM EDT, Francis Augusto Medeiros-Logeay via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via
FreeIPA-users
wrote:
I've looked k5start before, and, correct me if I am wrong, but the difference between using a `kinit -k -i | -t keytab` and k5start is that the later takes care of the daemonization aspect, right? As I
see
it, both need a keytab to work. The issue for me here is that it is
a
bit undesirable to leave a keytab around. What I like about FreeIPA
is
that you can fetch the keytab from a cached credential, so that it
you
could fetch it, use k5start or kinit -kt, and then erase it.
I guess there's no way to renew those tickets without a keytab,
right?
Nope -- unless you store that password somewhere and run a systemd timer, effectively.
If you store your user credentials into a keytab and just set KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used
to replace k5start.
Alternatively, gssproxy could be used for that. It already knows how
to
handle NFS, for example, so it would work just fine. But it also expects to have a keytab in a proper place.
Thanks a lot, Alexander.
I am clueless now on how to solve this. We experienced that, on machines where the user uses nfsv4+kerberos to mount their home directory, what happens is that if the user has some job that writes to some file on his home directory, the machine goes bananas if the ticket expires (ie, if the user goes on vacation and doesn't log in). This is already a problem for a machine with one user, imagine when the machine has dozens of users. This happened with a RHEL 8.5, and I see no remedy for this, other than:
- storing a user keytab somewhere in his home folder, and use a
mechanism (k5start, crond, etc) to fetch new TGT's, but seems to be a potential security risk;
- having some cron job that checks for expired credentials and kills
all processes of that user to avoid a problem with the machine.
Would you have any idea of something out of these lines?
Best,
Francis _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
We have a script that renews all tickets that are still in use, and kills those that are not. The original version of this is a bit complex, but I now have a bash script in testing that seems reasonable.
I agree that keytables are a bit of a risk. They work on any host, and root can steal them. Here's what we do instead: For cron jobs, a user registers that they want to run cron jobs on a specific host. There's a pam module that will get a TGT for them when a cron job starts. It talks to a daemon on the kdc that verifies that they authorized it to issue tickets for that host and returns a ticket. The tickets are locked to that IP address and are not forwardble (since we are only using them from NFS).
None of this code is specific to Rutgers, but the script requires less infrastructure than the cron support. I have concerns about what we're doing for cron. I suspect the right solution is to use constrained delegation for NFS. I think that can be done with gssproxy.
________________________________ From: Francis Augusto Medeiros-Logeay via FreeIPA-users freeipa-users@lists.fedorahosted.org Sent: Friday, April 8, 2022 2:19 PM To: FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: Sam Morris sam@robots.org.uk; Alexander Bokovoy abokovoy@redhat.com; Francis Augusto Medeiros-Logeay r_f@med-lo.eu Subject: [Freeipa-users] Re: Strategy to renew TGT - any thoughts?
On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
I've looked k5start before, and, correct me if I am wrong, but the difference between using a `kinit -k -i | -t keytab` and k5start is that the later takes care of the daemonization aspect, right? As I see it, both need a keytab to work. The issue for me here is that it is a bit undesirable to leave a keytab around. What I like about FreeIPA is that you can fetch the keytab from a cached credential, so that it you could fetch it, use k5start or kinit -kt, and then erase it.
I guess there's no way to renew those tickets without a keytab, right?
Nope -- unless you store that password somewhere and run a systemd timer, effectively.
If you store your user credentials into a keytab and just set KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used to replace k5start.
Alternatively, gssproxy could be used for that. It already knows how to handle NFS, for example, so it would work just fine. But it also expects to have a keytab in a proper place.
Thanks a lot, Alexander.
I am clueless now on how to solve this. We experienced that, on machines where the user uses nfsv4+kerberos to mount their home directory, what happens is that if the user has some job that writes to some file on his home directory, the machine goes bananas if the ticket expires (ie, if the user goes on vacation and doesn't log in). This is already a problem for a machine with one user, imagine when the machine has dozens of users. This happened with a RHEL 8.5, and I see no remedy for this, other than:
- storing a user keytab somewhere in his home folder, and use a mechanism (k5start, crond, etc) to fetch new TGT's, but seems to be a potential security risk; - having some cron job that checks for expired credentials and kills all processes of that user to avoid a problem with the machine.
Would you have any idea of something out of these lines?
Best,
Francis _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
On pe, 08 huhti 2022, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
If you store your user credentials into a keytab and just set KRB5_CLIENT_KTNAME, this will work too. A systemd timer could be used to replace k5start.
Alternatively, gssproxy could be used for that. It already knows how to handle NFS, for example, so it would work just fine. But it also expects to have a keytab in a proper place.
I started to see GSSPROXY, and it seems like a good alternative, as we could use a keytab that give limited access to resources, and not the user's keytab. Would a service keytab work here, or should I rather create a specific user just for the purpose of mounting NFS, for example?
Best, Francis
On 2022-04-25 11:49, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
I started to see GSSPROXY, and it seems like a good alternative, as we could use a keytab that give limited access to resources, and not the user's keytab. Would a service keytab work here, or should I rather create a specific user just for the purpose of mounting NFS, for example?
I actually tested it, but it seems I had a misunderstanding. Gssproxy helps me to be able to mount my NFSv4 shares, but the problem is that the user can't access them without a ticket, so I am back to square one, which is, how to get a ticket for the user, non-interactively, after his ticket has expired, so that running jobs won't create havoc when the user looses access to his (mounted) share.
Best, Francis
On ma, 25 huhti 2022, Francis Augusto Medeiros-Logeay wrote:
On 2022-04-25 11:49, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
On 2022-04-08 10:57, Alexander Bokovoy via FreeIPA-users wrote:
I started to see GSSPROXY, and it seems like a good alternative, as we could use a keytab that give limited access to resources, and not the user's keytab. Would a service keytab work here, or should I rather create a specific user just for the purpose of mounting NFS, for example?
I actually tested it, but it seems I had a misunderstanding. Gssproxy helps me to be able to mount my NFSv4 shares, but the problem is that the user can't access them without a ticket, so I am back to square one, which is, how to get a ticket for the user, non-interactively, after his ticket has expired, so that running jobs won't create havoc when the user looses access to his (mounted) share.
You need to instruct gssproxy to use a client keytab that contains user's keys.
You have to use user's keys in that keytab because you need to make sure UID of the user has the same mapping between what the client runs and what NFS server uses. For users it is done more or less automatically. For services it is not because Kerberos services in IPA do not have POSIX identities.
https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#keytab-based-client... describes a general solution.
On 25 Apr 2022, at 15:14, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
You need to instruct gssproxy to use a client keytab that contains user's keys.
You have to use user's keys in that keytab because you need to make sure UID of the user has the same mapping between what the client runs and what NFS server uses. For users it is done more or less automatically. For services it is not because Kerberos services in IPA do not have POSIX identities.
https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#keytab-based-client... describes a general solution.
Thanks a lot for pointing this. But what about this https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-via-constrained-delegation ? Do I get it correctly that with user delegation so the user keytab or a valid user credential isn’t necessary?
Will the user be able to access a mounted share without a ticket when user delegation is used?
Best, Francis
On 06-04-2022 21:39, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
We have a few machines that joined a FreeIPA instance. We use NFSv4 + kerberos to mount home directories.
However, if the user do not log on to the machine for more than 7 days, and he leaves a job executing and that writes to some file on his home directory, the cpu usage of the machine goes up to the sky and the machine gets almost unusable.
Is there a good strategy to fetch new TGT's when near expiration? I know some users generate a key tab (or fetch them using ipa-getkeytab) to automate a kinit, but I wonder if we could come with a system-wide solution that doesn't lead to storing key tabs around.
Any tips for that?
Have you looked at SSSD's krb5_renew_interval and krb5_renewable_lifetime? On my PC I changed it to:
/etc/sssd/sssd.conf [domain/example.com] ... krb5_renewable_lifetime = 60d krb5_renew_interval = 6h
I don't really need it anymore because I'm now locking my PC when I go home :-). And when I get back I have to enter my password, after which there is a new TGT.
--- Francis Augusto Medeiros-Logeay Oslo, Norway
On 2022-04-07 15:26, Kees Bakker via FreeIPA-users wrote:
Have you looked at SSSD's krb5_renew_interval and krb5_renewable_lifetime? On my PC I changed it to:
/etc/sssd/sssd.conf [domain/example.com] ... krb5_renewable_lifetime = 60d krb5_renew_interval = 6h
I don't really need it anymore because I'm now locking my PC when I go home :-). And when I get back I have to enter my password, after which there is a new TGT.
Thanks Kees. That doesn't cut it, as it doesn't really get a new TGT besides the lifetime that is set by the server. If that is 7d, so setting it higher on the client won't help. Besides the renewal_interval only works for tickets inside the renewable_lifetime.
Best, Francis
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Charles Hedrick -
Francis Augusto Medeiros-Logeay -
Francis Augusto Medeiros-Logeay -
Jim Kinney -
Kees Bakker -
Ronald Wimmer -
Sam Morris