[Freeipa-users] Re: Strategy to renew TGT - any thoughts?

[Eric Ashley via FreeIPA-users]

Hi Francis,

I think with a minor change of logic this issue is rather simple with a 
bit of scripting and some user training. Rather than getting a new 
ticket after the old one expires, look for a ticket that expires within 
X minutes where your other renewal criteria are still met. While that 
original ticket is active, issue a 'kinit -R' for the user principal. 
Obviously if your ticket is approaching the end of it's renewable life, 
you have your original problem again which is where the user training 
comes into play. To address that I'd ensure that a) the renewal lifetime 
is long enough to run your longest running long job plus one day (or 3 
if some long jobs are started on a Friday with no operators available 
for the weekend) and b) you have users who execute these kinds of jobs 
get a new ticket the next work day even if, but especially if, a job is 
still running). That should cover almost all cases. If you can tell the 
difference between one of these long jobs and regular interactive 
activity, you can notify the use (or just flat execute kinit for them) 
since there are at the computer to answer any prompts for renewal.


After adjusting the renewal lifetimes for user tickets, I'd create a 
script that does this renewal then executes all the remaining user 
parameters. In the script if the 'kinit -R' fails execute a regular 
kinit for the principal in use. Train your uses to always start their 
jobs with this script rather an directly invoking the jobs and they'll 
always be running the job in an environment where they have enough time 
to execute the job under a valid ticket that the user has just renewed 
or they'll be back to the computer before the current one expires to get 
a new one of the job run takes days. That should handle all the cases 
except one like the user starting a long job and leaving for long 
holiday. If you still use a system script to renew almost expired 
tickets with jobs running, you would even handle that case.


To everyone else, thanks for all the great effort on FreeIPA. It has 
been a fantastic addition to my little network.


Best regards,

Eric



OpenPGP_0x6D7B90C58CAE3115.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


publickey - 
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

> On 25 Apr 2022, at 15:14, Alexander Bokovoy via FreeIPA-users 
>  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-initiation
> 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-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 ___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Alexander Bokovoy via FreeIPA-users]

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-initiation
describes a general solution.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

Thanks a lot, Charles. I gave a look into it, really neat!

Best,

---
Francis Augusto Medeiros-Logeay
Oslo, Norway

On 2022-04-24 14:51, Charles Hedrick via FreeIPA-users wrote:

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


-

From: Francis Augusto Medeiros-Logeay 
Sent: Sunday, April 24, 2022 8:35 AM
To: FreeIPA users list 
Cc: Charles Hedrick 
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 


Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy 
; Francis Augusto Medeiros-Logeay 

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-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ [1]
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines [2]
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org 
[3]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure [4]

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Strategy to renew TGT - any thoughts?

[Charles Hedrick via FreeIPA-users]

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

From: Francis Augusto Medeiros-Logeay 
Sent: Sunday, April 24, 2022 8:35 AM
To: FreeIPA users list 
Cc: Charles Hedrick 
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 

Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; 
Francis Augusto Medeiros-Logeay 
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-le...@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<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send 

[Freeipa-users] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

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 


Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy 
; Francis Augusto Medeiros-Logeay 

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-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ [1]
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
[2]
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org 
[3]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure [4]

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@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



Links:
--
[1] https://docs.fedoraproject.org/en-US/project/code

[Freeipa-users] Re: Strategy to renew TGT - any thoughts?

[Charles Hedrick via FreeIPA-users]

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 

Sent: Friday, April 8, 2022 2:19 PM
To: FreeIPA users list 
Cc: Sam Morris ; Alexander Bokovoy ; 
Francis Augusto Medeiros-Logeay 
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-le...@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-le...@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] Re: Strategy to renew TGT - any thoughts?

[Jim Kinney via FreeIPA-users]

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  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-le...@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

-- 
Computers amplify human error
Super computers are really cool___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

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-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

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  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?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Alexander Bokovoy via FreeIPA-users]

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  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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

--
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  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?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Sam Morris via FreeIPA-users]

> 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  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 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

---
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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Francis Augusto Medeiros-Logeay via FreeIPA-users]

---
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
someipau...@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-le...@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-le...@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] Re: Strategy to renew TGT - any thoughts?

[Kees Bakker via FreeIPA-users]

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
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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] Re: Strategy to renew TGT - any thoughts?

[Ronald Wimmer via FreeIPA-users]

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 someipau...@somedomain.com 
-P -k ./someipauser.keytab

export KRB5_CLIENT_KTNAME /some/path/to/someipauser.keytab

Cheers,
Ronald
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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