2:39 p.m.
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,
--
Francis Augusto Medeiros-Logeay
Oslo, Norway
5:03 a.m.
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(a)SOMEDOMAIN.COM
-P -k ./someipauser.keytab
export KRB5_CLIENT_KTNAME /some/path/to/someipauser.keytab
Cheers,
Ronald
6:30 a.m.
---
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(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
3:22 a.m.
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).
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
3:41 a.m.
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?
3:42 a.m.
--
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?
3:57 a.m.
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1:19 p.m.
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
2:35 p.m.
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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Computers amplify human error
Super computers are really cool
1:59 p.m.
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(a)lists.fedorahosted.org>
Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Sam Morris <sam(a)robots.org.uk>; Alexander Bokovoy <abokovoy(a)redhat.com>;
Francis Augusto Medeiros-Logeay <r_f(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
4:49 a.m.
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
7:49 a.m.
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
8:14 a.m.
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-cli...
describes a general solution.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
11:52 a.m.
On 25 Apr 2022, at 15:14, Alexander Bokovoy via FreeIPA-users
<freeipa-users(a)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-cli...
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-impersonati...
<https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonati...
? 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
8:26 a.m.
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.
--
Kees
8:38 a.m.
---
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
733
days inactive
752
days old
freeipa-users@lists.fedorahosted.org
15 comments
8 participants
participants (8)
-
Alexander Bokovoy -
Charles Hedrick -
Francis Augusto Medeiros-Logeay -
Francis Augusto Medeiros-Logeay -
Jim Kinney -
Kees Bakker -
Ronald Wimmer -
Sam Morris