Maximum size of a Unix MIT Kerberos database backend

[Garnett-2]

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)
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Ken Raeburn]

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 / raeburn@... / no longer at MIT Kerberos Consortium

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

[John Washington-3]

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.greneche@...> [2009-11-08 22:40]:

> 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)
> ________________________________________________
> Kerberos mailing list           Kerberos@...
> https://mailman.mit.edu/mailman/listinfo/kerberos

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


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

[Ken Raeburn]

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 / raeburn@... / no longer at MIT Kerberos Consortium

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

[Garnett-2]

On 10 nov, 22:21, Ken Raeburn <raeb...@...> 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...@... / no longer at MIT Kerberos Consortium

Thanks to all for your responses ! I'm more confident in using
Kerberos ;-)
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Nicolas Williams]

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
--
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos