[prev in list] [next in list] [prev in thread] [next in thread] 

List:       krb5-bugs
Subject:    Re: [krbdev.mit.edu #8945] krb5kdc: the 32 realms limit
From:       "=?UTF-8?B?w5DClMOQwrjDkMK7w5HCj8OQwr0gw5DCn8OQwrDDkMK7w5DCsMORwoPDkMK3?= =?UTF-
Date:       2020-09-17 9:00:09
Message-ID: rt-4.4.4-46387-1600333209-1963.8945-5-0 () mit ! edu
[Download RAW message or body]


<URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8945 >

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 (вт), Дилян Палаузов написа:
> 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.
> > 
> > 


_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs

[prev in list] [next in list] [prev in thread] [next in thread]