ticket renew lifetime limited by Windows KDC policy
Di Pe
We use kerberized nfs for our home directories on desktops and
computational servers. Users login via pam_krb5 and tickets are
refreshed via a cron job that checks if users are still logged on and
executes a kinit -R /tmp/ticketcache if they are to refresh the
ticket. If they are logged off their ticket cache is deleted. If the
ticket expires users are instantly cut off their home directory and
almost all processes freeze. Sometimes a reboot is required.
Some users stay logged onto a system for longer than 30 days. To
minimize the likelihood of this "freeze" to happen we increased
renew_lifetime from 7d to 90d in the local krb5.conf. Unfortunately
the renew lifetime is enforced by our Windows 2k3 KDC
(http://technet.microsoft.com/en-us/library/cc738269%28WS.10%29.aspx)
. We are debating if we should increase the ActiveDirectory policy
from 7d to 120d for all users.
What is the specific risk of increasing the renew lifetime? to 30days,
90days, 120days? For Windows and Unix systems?
Please take into account that our cron job is deleting all tickets of
users that are currently not logged on every hour. Also we need to use
weak crypto because our NetApp requires it.
What would be a better Kerberos setup? pam_winbind instead of
pam_krb5? Other tools that can refresh/replace the TGT instead of
renewing it? These tools would have to store the user's password in
memory, wouldn't they?
Thanks much for your help
dipe
Russ Allbery
> We use kerberized nfs for our home directories on desktops and
> computational servers. Users login via pam_krb5 and tickets are
> refreshed via a cron job that checks if users are still logged on and
> executes a kinit -R /tmp/ticketcache if they are to refresh the
> ticket. If they are logged off their ticket cache is deleted. If the
> ticket expires users are instantly cut off their home directory and
> almost all processes freeze. Sometimes a reboot is required. Some users
> stay logged onto a system for longer than 30 days. To minimize the
> likelihood of this "freeze" to happen we increased renew_lifetime from
> 7d to 90d in the local krb5.conf. Unfortunately the renew lifetime is
> enforced by our Windows 2k3 KDC
> (http://technet.microsoft.com/en-us/library/cc738269%28WS.10%29.aspx)
> . We are debating if we should increase the ActiveDirectory policy from
> 7d to 120d for all users.
> What is the specific risk of increasing the renew lifetime? to 30days,
> 90days, 120days? For Windows and Unix systems?
The risk is that anyone who steals that ticket cache can then continue to
act as that user for the full length of the renewal period. At least with
the KDCs I'm familiar with, this remains true even if the user changes
their password, although I don't know if that's also true of Active
Directory. It brings the ticket cache closer and closer to a password in
terms of the security implications of it being stolen.
Have you considered using some other mechanism to ensure that users
reauthenticate periodically? For instance, if you're using bash, you
could configure it to run kinit (or, possibly better, k5start -H) every
once in a while by (ab)using the prompt setting.
> What would be a better Kerberos setup? pam_winbind instead of pam_krb5?
> Other tools that can refresh/replace the TGT instead of renewing it?
> These tools would have to store the user's password in memory, wouldn't
> they?
Yes. You either need to allow tickets to be renewable for longer or you
have to get the user to enter their password occasionally. There aren't
any other alternatives, really.
Note, however, that if you use the newest version of the GSSAPI patch for
ssh, any users who are logged on via ssh with a new client will have their
tickets automatically reforwarded to all the systems to which they're
logged on and hence refreshed on those systems. If you have relatively
sophisticated users, this is a very nice feature.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Di Pe
some more comments/questions below
On Wed, Sep 1, 2010 at 2:12 PM, Russ Allbery <r...@stanford.edu> wrote:
> Di Pe <dip...@gmail.com> writes:
>
> Have you considered using some other mechanism to ensure that users
> reauthenticate periodically? For instance, if you're using bash, you
> could configure it to run kinit (or, possibly better, k5start -H) every
> once in a while by (ab)using the prompt setting.
>
This seems to be a good idea. I used
export PROMPT_COMMAND="k5start -H 500"
and it does what it's supposed to do.
One issue tough: k5start seems to look at ticket_lifetime instead of
renew_liefetime. ticket_lifetime is enforced to 10 hours by active
directory. If I don't use a cron job to renew the ticket users would
have to enter their credentials every few hours or so which is not
good if they run jobs over night.
If I use a cron job to renew the ticket I would not be prompted for
7days but if renew_lifetime ran out on a saturday I would only have
another few hours to refresh the ticket.
Another problem we notice on our terminal server is that user sessions
are completely locking up when a ticket expires on a nfs mounted home
directory. It would be good if we had a cron job that forces a logout
for users where the ticket is about to expire in 60 minutes or less.
Is there a way to check for a happy ticket in a shell script without
getting a prompt if the ticket is not happy?
dipe
>> What would be a better Kerberos setup? pam_winbind instead of pam_krb5?
>> Other tools that can refresh/replace the TGT instead of renewing it?
>> These tools would have to store the user's password in memory, wouldn't
>> they?
>
> Yes. You either need to allow tickets to be renewable for longer or you
> have to get the user to enter their password occasionally. There aren't
> any other alternatives, really.
>
> Note, however, that if you use the newest version of the GSSAPI patch for
> ssh, any users who are logged on via ssh with a new client will have their
> tickets automatically reforwarded to all the systems to which they're
> logged on and hence refreshed on those systems. If you have relatively
> sophisticated users, this is a very nice feature.
We have started using this feature and it will be a great replacement
for ssh keys because sys admins cannot enforce a password policy with
SSH keys.
Russ Allbery
> This seems to be a good idea. I used
> export PROMPT_COMMAND="k5start -H 500"
> and it does what it's supposed to do.
> One issue tough: k5start seems to look at ticket_lifetime instead of
> renew_liefetime. ticket_lifetime is enforced to 10 hours by active
> directory. If I don't use a cron job to renew the ticket users would
> have to enter their credentials every few hours or so which is not
> good if they run jobs over night.
Yeah, you ideally want k5start to renew the ticket if it can, and if not,
prompt. That's something that k5start -H should probably just do by
default. It doesn't do that right now and it will require some coding.
I'll add it to the to-do list.
> Another problem we notice on our terminal server is that user sessions
> are completely locking up when a ticket expires on a nfs mounted home
> directory. It would be good if we had a cron job that forces a logout
> for users where the ticket is about to expire in 60 minutes or less. Is
> there a way to check for a happy ticket in a shell script without
> getting a prompt if the ticket is not happy?
Also a good idea. There isn't at the moment.
Di Pe
I am currently using the workflow in the cronjob script below. It
would be nice if some of that could be implemented in k5start
Dipe
##########
#! /bin/sh
# This script renews kerberos tickets for all logged on users
# that have not yet expired and removes tickets that have expired.
# It also allows a user to refresh her ticket in time by not
# auto renewing tickets that have between 8 and 1 hour to live
# durning the last 4 days of the renew_lifetime. Thus, the user
# is not prompted for a password for 3 days after logon if the
# ticket renew lifetime is 7 days (MS AD default policy)
# The user should set this env variable (6 hours):
# export PROMPT_COMMAND="k5start -H 360"
#
# Finally the scripts logs out users for who renew_lifetime is
# less than 1 hour. (FORCELOGOUT is set to "no" by default) and
# sends a warning email to all users for who renew_lifetime is less than
# 2 hours (SENDWARNING is set to "no" by default)
#
# Test cases, there are more test cases in the code below.
# kinit -l 10m -r 3d
# (ticket_lifetime = 10 minutes, renew_lifetime = 3 days)
#
# Please put this script in /etc/cron.hourly and edit /etc/krb5.conf :
##[libdefaults]
## ticket_lifetime = 10h
## renew_lifetime = 7d
SENDWARNING="no"
FORCELOGOUT="no"
MAILHOST="mx"
DOMAIN=`hostname -d`
CURRUSERS=`users | sed 's/ /\n/g' | sort -u`
for TCACHE in $( ls -1 /tmp/krb5cc* 2> /dev/null ); do
OWNER=$( ls -l $TCACHE | awk '{print $3}' )
GROUP=$( ls -l $TCACHE | awk '{print $4}' )
NOW=$( date +%s )
EXPIRE_TIME=$( date -d "$( klist -c $TCACHE | grep krbtgt | awk
'{print $3, $4}' )" +%s )
RENEW_TIME=$( date -d "$( klist -c $TCACHE | grep "renew until" |
awk '{print $3, $4}' )" +%s )
echo owner:$OWNER tcache:$TCACHE expire:$EXPIRE_TIME
renew:$RENEW_TIME current:$NOW
# If the ticket has already expired, might as well delete it
# testcase: kinit -l 10s
if [ $NOW -ge $EXPIRE_TIME ]; then
kdestroy -c $TCACHE &> /dev/null:
echo "Removed expired ticket cache $TCACHE for user $OWNER"
# log user out if we are within one hour or less of max
renew_lifetime, prevent lockup
# testcase: kinit -l 1h -r 1h
elif [ $( expr $RENEW_TIME - $NOW ) -le 3600 ]; then
echo "time to log user out!"
if [[ $FORCELOGOUT == "yes" ]]; then
kill -15 $(ps -U $OWNER -o "pid=")
echo "send notice to user!"
emailbody=`mktemp`
mail -s "You have been logged out from '`hostname`' and
all your jobs have been ended." -r root@`hostname -f` \
-S "smtp=$MAILHOST.$DOMAIN" $OWNER@$DOMAIN < $emailbody
rm $emailbody
fi
# notify user if we are between 3 and 4 hours of max
renew_lifetime to prevent forced logout
# testcase: kinit -l 1h -r 4h
elif [ $( expr $RENEW_TIME - $NOW ) -le 14400 ]; then
if [ $( expr $RENEW_TIME - $NOW ) -gt 10800 ]; then
echo "send warning to user!"
if [[ $SENDWARNING == "yes" ]]; then
emailbody=`mktemp`
echo "$OWNER, please make sure to login to
'`hostname`' to update your credentials." >> $emailbody
echo "If you can't login within 3 hours you will be
logged out and your running jobs will be ended." >> $emailbody
mail -s "Please login to '`hostname`' within the next
3 hours." -r root@`hostname -f` \
-S "smtp=$MAILHOST.$DOMAIN" $OWNER@$DOMAIN < $emailbody
rm $emailbody
fi
fi
else
# standard refresh loop, tickets are not in immediate danger to expire
for user in $CURRUSERS; do
if [[ $user == $OWNER ]]; then
echo "user $OWNER is logged on, check renewal!"
# renew ticket if it will expire in one hour or less
# testcase: kinit -l 1h -r 1d
if [ $( expr $EXPIRE_TIME - $NOW ) -le 3600 ]; then
kinit -R -c $TCACHE
chown $OWNER:$GROUP $TCACHE
echo "auto renewed - 1h!"
# renew ticket if it will expire in 8 hours or less
# testcase: kinit -l 8h -r 97h
elif [ $( expr $EXPIRE_TIME - $NOW ) -le 28800 ]; then
# ....and if there is at least 96 hours left for renewal
if [ $( expr $RENEW_TIME - $NOW ) -ge 345600 ]; then
kinit -R -c $TCACHE
chown $OWNER:$GROUP $TCACHE
echo "auto renewed - <96h left"
else
#testcase: kinit -l 8h -r 96h
echo "time for ticket refresh via k5start or
systray app"
fi
fi
fi
done
fi
done