Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Questions Regarding User Tokens

15 views
Skip to first unread message

John Joshua Gutierrez

unread,
Dec 7, 2023, 6:42:37 PM12/7/23
to kerb...@mit.edu
Hi Kerberos Team,

My name is John Gutierrez and I work with Deep Apple Therapeutics. We have
a small cluster running Kerberos and would like guidance on a couple of
issues. We have been experiencing difficulty with user authentication and
keeping tickets alive to run processes for more than 7 days without getting
kicked out. We are not experts of Kerberos and we probably have very poor
configuration. Here are our questions:

- How do we extend ticket lifetime to 14 days?
- We have tried to set the ticket lifetime to 14 days in krb5.conf
[realm] but it caps out to one day
- How do we extend renewable ticket lifetime to 30 days?
- We set the variable to 30 days but it only caps out to 14 days.
- Kinit would sometimes give us an expiration date from the past
- Kinit needs to be done on every single node you want to use. If, no
kinit then no access to NFS home directory.

We currently work around the issue of token expiration by using a script
that kinits with one day of lifetime and 14 days of renewal and doing a
cronjob every 12 hours to renew the token on every node in our tiny
cluster. Please advise.

Best,
John

Ken Hornstein

unread,
Dec 7, 2023, 7:43:57 PM12/7/23
to John Joshua Gutierrez, kerb...@mit.edu
> - How do we extend ticket lifetime to 14 days?
> - We have tried to set the ticket lifetime to 14 days in krb5.conf
> [realm] but it caps out to one day

First, assuming you're talking about the "ticket_lifetime" parameter,
that actually goes in the [libdefaults] stanza. You can also specify the
lifetime parameter on the command line to kinit using the "-l" option
and that might be the most useful to start out during testing.

Where you're probably running into issues is that the ticket lifetime
is the MINIMUM of: the requested lifetime (via the -l option or the
ticket_lifetime parameter), the maximum lifetime set on the client
principal, and the maximum lifetime set on the service principal. So
you need to modify the maximum lifetime on all of your clients AND
all of your services. You can do this with the "modprinc -maxlife"
command inside of kadmin. To even test this out with one user you'd
need to change that user's maximum lifetime AND the lifetime of the TGS
principal (krbtgt/REALM@REALM).

> - How do we extend renewable ticket lifetime to 30 days?
> - We set the variable to 30 days but it only caps out to 14 days.

See above, the same rules apply (with the exception that you're use
the "-maxrenewlife" option to modprinc).

> - Kinit would sometimes give us an expiration date from the past

That maybe sounds like a clock synchronization problem? If you could
give us details there, might be helpful.

> - Kinit needs to be done on every single node you want to use. If, no
> kinit then no access to NFS home directory.

Normally this is done at login time automatically, and when you log into
a remote system Kerberos tickets are forwarded.

If you are using a batch processing system then that is trickier; there
are some tricks there, but none of them are great if you don't have
a Kerberos aware queueing system.

--Ken

Ken Hornstein

unread,
Dec 7, 2023, 8:59:28 PM12/7/23
to John Joshua Gutierrez, kerb...@mit.edu
>1. For the kinit -l and -r, I will get started on changing everything to be
>the same thing. When I finish, I will email back to you if I was successful
>and if not I will send screenshots of the configs.

Note that while I am glad to help, I can't guarantee that I'll be
available for unlimited general help.

>2. For the time problem, I just finished syncing all the machines to one
>local NTP Server. I am using chronyd and we are running Rocky Linux 8.
>Hopefully that fixes that problem.

I'm a little surprised that it worked at all since synchronized clocks
are a requirement of Kerberos, but moving on ...

>3. Yes, we unfortunately are using a scheduler and its SLURM. Would this
>question now go to SLURM Developers or still to Kerberos or both?

That's more of a SLURM question, but out of curiousity I Googled "slurm
kerberos" and it seems like there's a solution there using a software
package called "Auks" which is a central ticket manager that you can
forward TGTs to and it can dole them out to a SLURM job at the right
time. Which is kind of interesting! Caution: it looks to be a bit
complicated, but that is unavoidable. Here's an overview:

https://slurm.schedmd.com/slurm_ug_2012/auks-tutorial.pdf

Auks is here:

https://github.com/cea-hpc/auks

--Ken

John Joshua Gutierrez

unread,
Dec 8, 2023, 1:15:45 AM12/8/23
to Ken Hornstein, kerb...@mit.edu
Hi Ken,

Thank you so much for the fast reply! I will try my best to get through the
tips you've given me and hopefully I fix something.

1. For the kinit -l and -r, I will get started on changing everything to be
the same thing. When I finish, I will email back to you if I was successful
and if not I will send screenshots of the configs.

2. For the time problem, I just finished syncing all the machines to one
local NTP Server. I am using chronyd and we are running Rocky Linux 8.
Hopefully that fixes that problem.

3. Yes, we unfortunately are using a scheduler and its SLURM. Would this
question now go to SLURM Developers or still to Kerberos or both?

Best,
John
0 new messages