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

Maximum size of a Unix MIT Kerberos database backend

0 views
Skip to first unread message

garnett

unread,
Nov 8, 2009, 9:20:56 AM11/8/09
to
Hi all,

In our University I wish to centralize authentication in a Linux MIT
KDC. This operation will spawn a KDC with about 30 000 principals. Is
it a problem for Kerberos MIT implementation ? We will run the 1.6
version bundled with Debian Lenny.

Is there a need for tricks to handle such a database ?

Thanks for your piceces of advice.

Nico (http://blog.garnett.fr)

Ken Raeburn

unread,
Nov 9, 2009, 1:21:47 AM11/9/09
to garnett, kerb...@mit.edu
On Nov 8, 2009, at 09:20, garnett wrote:
> In our University I wish to centralize authentication in a Linux MIT
> KDC. This operation will spawn a KDC with about 30 000 principals. Is
> it a problem for Kerberos MIT implementation ? We will run the 1.6
> version bundled with Debian Lenny.
>
> Is there a need for tricks to handle such a database ?

No, there shouldn't be. You may want a slave KDC or two for
redundancy in case of hardware problems -- with that many entries it's
probably going to be a critical service for a lot of people -- but in
terms of disk space and cpu load, just about any desktop or server
system you can buy off the shelf these days should be able to handle
it easily.

Ken


--
Ken Raeburn / rae...@mit.edu / no longer at MIT Kerberos Consortium

John Washington

unread,
Nov 10, 2009, 12:14:40 PM11/10/09
to garnett, kerb...@mit.edu
Our backend was last counted at over 200,000 principals and the only noticeable
impact (at this time) is that propagation time is around two minutes.

* garnett <nicolas....@gmail.com> [2009-11-08 22:40]:

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
John Washington Network Security Officer,
University of Illinois Urbana-Champaign

signature.asc

Ken Raeburn

unread,
Nov 10, 2009, 4:21:07 PM11/10/09
to John Washington, garnett, kerb...@mit.edu
On Nov 10, 2009, at 12:14, John Washington wrote:
> Our backend was last counted at over 200,000 principals and the only
> noticeable
> impact (at this time) is that propagation time is around two minutes.

Have you looked into the new (Sun-contributed) incremental propagation
code in 1.7?

garnett

unread,
Nov 10, 2009, 4:32:50 PM11/10/09
to
On 10 nov, 22:21, Ken Raeburn <raeb...@MIT.EDU> wrote:
> On Nov 10, 2009, at 12:14, John Washington wrote:
>
> > Our backend was last counted at over 200,000 principals and the only  
> > noticeable
> > impact (at this time) is that propagation time is around two minutes.
>
> Have you looked into the new (Sun-contributed) incremental propagation  
> code in 1.7?
>
> Ken
>
> --
> Ken Raeburn / raeb...@mit.edu / no longer at MIT Kerberos Consortium

Thanks to all for your responses ! I'm more confident in using
Kerberos ;-)

Nicolas Williams

unread,
Nov 10, 2009, 4:34:00 PM11/10/09
to John Washington, garnett, kerb...@mit.edu
On Tue, Nov 10, 2009 at 11:14:40AM -0600, John Washington wrote:
> Our backend was last counted at over 200,000 principals and the only noticeable
> impact (at this time) is that propagation time is around two minutes.

My previous experience was with ~100K principals, and indeed, it scales
fine. I suspect it scales just fine to much larger sizes.

Things to keep in mind:

- The MIT krb5 KDC (and so the Solaris one) is single-threaded, and
demand for KDC exchanges matters more than number of principals in
KDB, but you're likely to have multi-code/multi-thread-CPU hardware,
so you may want to create a VM/zone/jail per-core or per-hardware
thread and run the KDC in as many as you need to scale to demand.

You'll probably want to measure how many KDC exchanges you can get
per-HW thread and decide how many KDCs you need based on expected
demand. Estimating demand requires knowledge of what kerberized
services you will have.

In any case, if you will deploy incrementally, then you can add KDCs
as you deploy.

- Incremental propagation helps; I recommend it.

Nico
--

0 new messages