[Freeipa-users] How to change kerberos key lifetime?

[William Muriithi]

Hello

We are currently mostly using RHEL 6 on the clients but IPA is on RHEL
7.3. I am using Kerberos to authenticate NFS mount and its working
fine. However, there is a lot of users who are complaining that its
causing too much problems. They are all related to key expiry


I have looked at how to rectify this and noticed that the only
solution with RHEL 6 is to increase the time the key is valid.
However, it hasn't worked, the key lifetime remains a day and maximum
lifetime of 7 days.

These are the changes I have made so far:

Changed the policy on IPA:

[***@lithium ~]# ipa krbtpolicy-show
Max life: 15552000
Max renew: 25552000
[***@lithium ~]#


Changed kerberos configuration:

[libdefaults]
default_realm = ENG.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 4320h
forwardable = yes
udp_preference_limit = 0


Changed sssd configurations:

[domain/eng.example.com]

krb5_renewable_lifetime = 180d
krb5_renew_interval = 3600
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = eng.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = platinum.eng.example.com
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, lithium.eng.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
autofs_provider = ipa
ipa_automount_location = default
[sssd]
services = nss, sudo, pam, autofs, ssh

domains = eng.example.com
[nss]
homedir_substring = /home

None have lead to any difference as seem below. What would I be missing?

Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N
Default principal: ***@ENG.EXAMPLE.COM

Valid starting Expires Service principal
02/15/17 13:17:11 02/22/17 13:17:11 krbtgt/***@ENG.EXAMPLE.COM
renew until 03/01/17 13:17:11

Regards,
William

[David Kupka]

Post by William Muriithi
Hello
We are currently mostly using RHEL 6 on the clients but IPA is on RHEL
7.3. I am using Kerberos to authenticate NFS mount and its working
fine. However, there is a lot of users who are complaining that its
causing too much problems. They are all related to key expiry
I have looked at how to rectify this and noticed that the only
solution with RHEL 6 is to increase the time the key is valid.
However, it hasn't worked, the key lifetime remains a day and maximum
lifetime of 7 days.
Max life: 15552000
Max renew: 25552000
[libdefaults]
default_realm = ENG.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 4320h
forwardable = yes
udp_preference_limit = 0
[domain/eng.example.com]
krb5_renewable_lifetime = 180d
krb5_renew_interval = 3600
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = eng.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = platinum.eng.example.com
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, lithium.eng.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
autofs_provider = ipa
ipa_automount_location = default
[sssd]
services = nss, sudo, pam, autofs, ssh
domains = eng.example.com
[nss]
homedir_substring = /home
None have lead to any difference as seem below. What would I be missing?
Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N
Valid starting Expires Service principal
renew until 03/01/17 13:17:11
Regards,
William
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Hello William,
first you're mantioning "key expiry" but if I understand corectly you're
interested in "ticket lifetime".

As mentioned here [1] the ticket lifetime is the minimum of 4 values:
1) maxlife for the user principal
2) maxlife for the service [principal]
3) max_life in the kdc.conf
4) requested lifetime in the ticket request

You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in
[libdefaults] in /etc/krb5.conf on client).

To increase 2) you need to change maxlife for krbtgt service. There're two ways
this ca be done:
a) modifying krbMaxTicketLife attribute in
krbPrincipalName=krbtgt/***@EXAMPLE.ORG,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org
b) using kadmin.local:
# kadmin.local
Authenticating as principal admin/***@EXAMPLE.ORG
: modprinc -maxlife 10day krbtgt/EXAMPLE.ORG
Principal "krbtgt/***@EXAMPLE.ORG" modified.
: exit

To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf
and restart krb5kdc service.

But generally I don't think it's a good idea to have such long tickets. Would
it make sense in your use case to deploy SSSD on user systems to handle
Kerberos tickets for them?

[1] http://mailman.mit.edu/pipermail/kerberos/2009-February/014520.html

[William Muriithi]

Morning David,

Thank you very much for your help.

first you're mentioning "key expiry" but if I understand correctly you're
interested in "ticket lifetime".

Yes, want to increase ticket lifetime.

1) maxlife for the user principal
2) maxlife for the service [principal]
3) max_life in the kdc.conf
4) requested lifetime in the ticket request
You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in
[libdefaults] in /etc/krb5.conf on client).
To increase 2) you need to change maxlife for krbtgt service. There're two ways
a) modifying krbMaxTicketLife attribute in
# kadmin.local
: modprinc -maxlife 10day krbtgt/EXAMPLE.ORG
: exit

Will try 2 b and see how it goes

To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf
and restart krb5kdc service.

okay, wasn't actually aware of this. Will look at it

But generally I don't think it's a good idea to have such long tickets. Would
it make sense in your use case to deploy SSSD on user systems to handle
Kerberos tickets for them?

I am actually using SSSD on all the systems, even the desktops. I
agree the changes above aren't ideal and would prefer to get SSSD
working well. Where would like to avoid this error showing around
every 12 hours.

antimony: Could not chdir to home directory /home/william: Key has expired


Regards,
William

[David Kupka]

Post by William Muriithi
Morning David,
Thank you very much for your help.

first you're mentioning "key expiry" but if I understand correctly you're
interested in "ticket lifetime".

Yes, want to increase ticket lifetime.

1) maxlife for the user principal
2) maxlife for the service [principal]
3) max_life in the kdc.conf
4) requested lifetime in the ticket request
You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in
[libdefaults] in /etc/krb5.conf on client).
To increase 2) you need to change maxlife for krbtgt service. There're two ways
a) modifying krbMaxTicketLife attribute in
# kadmin.local
: modprinc -maxlife 10day krbtgt/EXAMPLE.ORG
: exit

Will try 2 b and see how it goes

To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf
and restart krb5kdc service.

okay, wasn't actually aware of this. Will look at it

But generally I don't think it's a good idea to have such long tickets. Would
it make sense in your use case to deploy SSSD on user systems to handle
Kerberos tickets for them?

I am actually using SSSD on all the systems, even the desktops. I
agree the changes above aren't ideal and would prefer to get SSSD
working well. Where would like to avoid this error showing around
every 12 hours.
antimony: Could not chdir to home directory /home/william: Key has expired
Regards,
William

Hello William!

The fact that your desktops are using SSSD changes the situation dramatically.

SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in.
And can be configured to renew the ticket for the user until the ticket renew
life time expires.

Given this you can keep ticket life time reasonable short (~1 day) set ticket
renewable life time to longer period (~2 weeks) and maintain reasonable
security level without negative impact on user's daily work.

Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options
in sssd-krb5 man page.

[William Muriithi]

David

Post by David Kupka
The fact that your desktops are using SSSD changes the situation dramatically.
SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in.
And can be configured to renew the ticket for the user until the ticket renew
life time expires.
Given this you can keep ticket life time reasonable short (~1 day) set ticket
renewable life time to longer period (~2 weeks) and maintain reasonable
security level without negative impact on user's daily work.
Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options
in sssd-krb5 man page.

Thanks a lot. I did actually end up using this. Will wait for a
couple of days and see if anybody if the situation is better and
update you.

Curious though, why isn't renewal interval setup by default? Is there
a negative consequence of having SSSD renewing tickets by default? I
can't think of any and hence a bit lost on explaining the default
setup

Post by David Kupka
--

Regards,
William

[David Kupka]

Post by William Muriithi
David

Post by David Kupka
The fact that your desktops are using SSSD changes the situation dramatically.
SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in.
And can be configured to renew the ticket for the user until the ticket renew
life time expires.
Given this you can keep ticket life time reasonable short (~1 day) set ticket
renewable life time to longer period (~2 weeks) and maintain reasonable
security level without negative impact on user's daily work.
Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options
in sssd-krb5 man page.

Thanks a lot. I did actually end up using this. Will wait for a
couple of days and see if anybody if the situation is better and
update you.
Curious though, why isn't renewal interval setup by default? Is there
a negative consequence of having SSSD renewing tickets by default? I
can't think of any and hence a bit lost on explaining the default
setup

Post by David Kupka
--

Regards,
William

Honestly, I don't know why krb5_renew_interval isn't set by default.

My wild guess would be that in typical SSSD deployment user logs-in in the
begining of work day, SSSD gets ticket that last for a day for him and he
logs-out in the end of the workday (after 8~10 hours). So there's no need to
refresh it.

But feel free to open a ticket for SSSD [1] and describe you use case. I don't
know SSSD that well and maybe there's no reason against setting it by default.

[1] https://fedorahosted.org/sssd/newticket

[Lukas Slebodnik]

Post by William Muriithi

Post by David Kupka
The fact that your desktops are using SSSD changes the situation dramatically.
SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in.
And can be configured to renew the ticket for the user until the ticket renew
life time expires.
Given this you can keep ticket life time reasonable short (~1 day) set ticket
renewable life time to longer period (~2 weeks) and maintain reasonable
security level without negative impact on user's daily work.
Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options
in sssd-krb5 man page.

Thanks a lot. I did actually end up using this. Will wait for a
couple of days and see if anybody if the situation is better and
update you.
Curious though, why isn't renewal interval setup by default? Is there
a negative consequence of having SSSD renewing tickets by default? I
can't think of any and hence a bit lost on explaining the default
setup

Desktop/laptop user usually does not need automatic renewal.
They authenticate/login/unlock screen quite often and for each
action sssd authenticate against IPA server which automatically get/renew
krb5 ticket. Unless machine is offline.

LS

[William Muriithi]

Hello David/Lukas

Thank you for your assistance so far. I still have the problem and not
even sure what to look at next. We are still seeing key expiry error
from NFS even after the proposed changes.

[***@silicon ~]$ ssh iron
Last login: Wed Mar 1 19:26:56 2017 from silicon.eng.example.com
Could not chdir to home directory /home/william: Key has expired
[***@iron /]$

[***@silicon ~]$ ssh manganese
Last login: Wed Mar 1 19:26:57 2017 from silicon.eng.example.com
Could not chdir to home directory /home/william: Permission denied
[***@manganese /]$


[***@silicon ~]$ ssh iron
Last login: Wed Mar 1 19:58:36 2017 from manganese.eng.example.com
DISPLAY is manganese:2
[***@iron ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_800


These are the changes that I currently have on my sssd.conf

[domain/eng.example.com]

krb5_realm = ENG.EXAMPLE.COM
krb5_server = hydrogen.eng.example.com
auth_provider = krb5
krb5_renewable_lifetime = 50d
krb5_renew_interval = 3600
cache_credentials = True
krb5_store_password_if_offline = True

According to this article, this change would ensure that the system
auto renew the keys for the next 50 days. Why would this key expiry
still show up?

http://people.redhat.com/steved/Summits/Summit13/Summit_Handout13.pdf

One side question, that is the difference between "auth_provider =
krb5" and "auth_provider = ipa"? In another word, what is expected
different between the two as far as IPA usage is concerned and what
would make one choose one over the other?


Regards,
William

Post by Lukas Slebodnik

Post by William Muriithi

Post by David Kupka
The fact that your desktops are using SSSD changes the situation dramatically.
SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in.
And can be configured to renew the ticket for the user until the ticket renew
life time expires.
Given this you can keep ticket life time reasonable short (~1 day) set ticket
renewable life time to longer period (~2 weeks) and maintain reasonable
security level without negative impact on user's daily work.
Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options
in sssd-krb5 man page.

Thanks a lot. I did actually end up using this. Will wait for a
couple of days and see if anybody if the situation is better and
update you.
Curious though, why isn't renewal interval setup by default? Is there
a negative consequence of having SSSD renewing tickets by default? I
can't think of any and hence a bit lost on explaining the default
setup

Desktop/laptop user usually does not need automatic renewal.
They authenticate/login/unlock screen quite often and for each
action sssd authenticate against IPA server which automatically get/renew
krb5 ticket. Unless machine is offline.
LS