Skip Menu |
 

From: "Дилян Палаузов" <dilyan.palauzov@aegee.org>
To: "krb5-bugs" <krb5-bugs@mit.edu>
Date: Mon, 07 Sep 2020 12:50:57 +0300
Subject: krb5kdc: the 32 realms limit
Download (untitled) / with headers
text/plain 1.1KiB
Hello,

https://web.mit.edu/kerberos/krb5-1.18/doc/admin/admin_commands/krb5kdc.html says:

OPTIONS

The -r realm option specifies the realm for which the server should
provide service. This option may be specified multiple times to serve
multiple realms. If no -r option is given, the default realm (as
specified in krb5.conf) will be served.

EXAMPLE
The KDC may service requests for multiple realms (maximum 32 realms).
The realms are listed on the command line. Per-realm options that can
be specified on the command line pertain for each realm that follows it
and are superseded by subsequent definitions of the same option.

---------------------------

• If krb5.conf defines 62 realms, can I run two instances of krb5kdc,
each with 31 -r parameters, to cover all realms? The answer shall be
evident from the documentation.

• Please extend krb5kdc, so that a single instance can handle unlimited
amount of realms

• Please add means to krb5kdc to serve all configured realms in
kdc.conf, without the need to create -r for each realm

• In the meantime, move in the documentation above the 32-limitation
from the Example section to the Options section.

Greetings
Dilyan
For your use case, would it be better to have a separate KDB for each realm (implying separate storage, propagation, and backup), or have one KDB to which realms could be added and removed?

To answer one of your questions, if you ran two separate krb5kdc processes each with 31 -r options to get around the current 32-realm limitation, they would have to serve different ports.
Subject: Re: [krbdev.mit.edu #8945] krb5kdc: the 32 realms limit
From: "Дилян Палаузов" <dilyan.palauzov@aegee.org>
Date: Tue, 08 Sep 2020 21:56:57 +0300
To: rt@krbdev.mit.edu
Hello,

In my use case, all things shall go in a single Kerberos DataBase
(KDB), all under LDAP(kldap). Say it this way: I want to have many
users, and each user gets a separate domain. REALM=DOMAIN. So there
are many realms with very few users in each.

Greetings
Dilyan

On Tue, 2020-09-08 at 13:20 -0400, Greg Hudson via RT wrote:
Show quoted text
> For your use case, would it be better to have a separate KDB for each
> realm
> (implying separate storage, propagation, and backup), or have one KDB
> to which
> realms could be added and removed?
>
> To answer one of your questions, if you ran two separate krb5kdc
> processes each
> with 31 -r options to get around the current 32-realm limitation,
> they would
> have to serve different ports.
>
>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8945] krb5kdc: the 32 realms limit
Date: Thu, 17 Sep 2020 09:14:14 +0300
From: "Дилян Палаузов" <dilyan.palauzov@aegee.org>
Download (untitled) / with headers
text/plain 1.1KiB
Hello,

I withdraw the request.

As it turned out, in order to be able change the password for a
separate realm, a separate kadmind process has to run. So for many
realms hosted on few hosts, many kadmind processes have to run on the
hosts for the rare event of changing a password. This is overkill.

Greetings
Дилян

В 21:56 +0300 на 08.09.2020 (вт), Дилян Палаузов написа:
Show quoted text
> Hello,
>
> In my use case, all things shall go in a single Kerberos DataBase
> (KDB), all under LDAP(kldap). Say it this way: I want to have many
> users, and each user gets a separate domain. REALM=DOMAIN. So there
> are many realms with very few users in each.
>
> Greetings
> Dilyan
>
> On Tue, 2020-09-08 at 13:20 -0400, Greg Hudson via RT wrote:
> > For your use case, would it be better to have a separate KDB for
> > each
> > realm
> > (implying separate storage, propagation, and backup), or have one
> > KDB
> > to which
> > realms could be added and removed?
> >
> > To answer one of your questions, if you ran two separate krb5kdc
> > processes each
> > with 31 -r options to get around the current 32-realm limitation,
> > they would
> > have to serve different ports.
> >
> >