[14550] in Kerberos
Re: addprinc -maxlife maxtixlife (?!)
daemon@ATHENA.MIT.EDU (Booker C. Bense)
Fri Jun 8 10:54:58 2001
Date: Fri, 8 Jun 2001 07:48:15 -0700 (PDT)
From: "Booker C. Bense" <bbense@networking.stanford.edu>
To: Turbo Fredriksson <turbo@bayour.com>
cc: <kerberos@MIT.EDU>
In-Reply-To: <87pucfgxv3.fsf@papadoc.bayour.com>
Message-ID: <Pine.GSO.4.33.0106080731500.8321-100000@shred.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 8 Jun 2001, Turbo Fredriksson wrote:
> >>>>> "Wyllys" == Wyllys Ingersoll <Wyllys.Ingersoll@eng.sun.com> writes:
>
> Now, another question, of a more philosophical nature.
>
> I have here a OpenLDAP server which should do some replication to another
> OpenLDAP server (the slave running on another port @ localhost). To make
> sure that authentication is done correctly, i have a 'replicator' principal,
> with a keytab (/etc/krb5.keytab.slurpd). Getting a ticket automaticly before
> starting slurpd, is done by issuing the command:
>
> export KRB5CCNAME=FILE:/var/run/slapd.krbenv
> kinit -k -t /etc/krb5.keytab.slurpd replicator@BAYOUR.COM
>
> Since the replicator should be running 24Hours/7Days a week (preferably
> NEVER being shutdown, but .. :). So the question is, the 'replicator'
> principal, how long should I let the ticket live (-maxlife) and how
> long should I allow it to be renewable (-maxrenewlife)? And how often
> should I renew the ticket from a cronscript?
>
> Currently the ticket lives for 9 hours, and I have the following line
> in my /etc/crontab file.
>
> KRB5CCNAME=FILE:/var/run/slapd.krbenv
> 0 */9 * * * root test -e /var/run/slapd.krbenv && kinit -k -t /etc/krb5.keytab.slurpd replicator@BAYOUR.COM
>
> But is there a better way to do it?
>
- I don't know if it's better but what I've done is to write a
program[1] that periodically checks for a valid ticket and renews the
tgt from the keytab if it's due to expire within X minutes. It's setup
to either run from cron or as a background job. The only advantage to
this approach is that you get faster recovery if something trashes the
tgt file[2].
- Messing around with the life of the tgt only makes sense if you
think the tgt file is somehow less secure than the keytab. Personally,
I would check more often than 9hrs and make the tgt active for much
longer than 9hrs.
- Booker C. Bense
[1]- Right now it's in K4, but I'm porting it to K5 as we speak and
will be putting it into production next week.
[2]- Doesn't happen very often, but when everyone's email depends on
having that tgt file available you get paranoid.
