See clhedrick/kerberos in github. The README identifies the various things there.

From: Francis Augusto Medeiros-Logeay <r_f@med-lo.eu>
Sent: Sunday, April 24, 2022 8:35 AM
To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Cc: Charles Hedrick <hedrick@rutgers.edu>
Subject: Re: [Freeipa-users] Re: Strategy to renew TGT - any thoughts?

Hey Charles,

Thanks a lot for what you just described - it gives me a lot to think about.

If you have th etime, could you describe how the pam module is called from the cron job, and how the TGT is fetched for the users? I mean, if it is a cron job, how the tgt is fetched without passwords? And how does the kdc issues the ticket?

This info would help me a lot!

Best,

Francis

---

Francis Augusto Medeiros-Logeay
Oslo, Norway

On 2022-04-22 20:59, Charles Hedrick via FreeIPA-users wrote:

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.fedorahosted.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

_______________________________________________
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.fedorahosted.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure