Multi-tenancy in MIT KDC

[Jeremy Hunt]

A kerberos 'realm' is a logical network. by convention it is set up to 
be the same as the DNS domain, but its name is set up as uppercase 
e.g.:

DNS domain: a.b.c
Kerberos realm: A.B.C

hostname fqdn: client1.a.b.c.d
Kerberos name: CLIENT1.A.B.C

If you wanted to break up the domain into subsets, then you could have 
an extra branch in the DNS domain. Let's say you wanted a Geographic 
breakup, then with this scheme and the same base domain you could add 
a location branch something like:

DNS domain: a.b.c
Kerberos realm A.B.C

DNS sub-domain location1.a.b.c
Kerberos sub-realm LOCATION1.A.B.C

hostname fqdn: client2.location1.a.b.c
Kerberos name: CLIENT2.LOCATION1.A.B.C

If you wanted to have some other association, and subsubdomains you 
could set up their DNS and kerberos like this:


DNS domain: a.b.c
Kerberos realm A.B.C

DNS sub-domain tenant1.a.b.c            (using your 'higher' 'tenant' 
concept)
Kerberos sub-realm TENANT1.A.B.C

Then locations of tenants are subdomains of the tenants:
DNS sub-sub-domain location2.tenant1.a.b.c            (using your 
'higher' 'tenant' concept)
Kerberos sub-sub-realm LOCATION2.TENANT1.A.B.C

hostname fqdn: client3.location2.tenant1.a.b.c
Kerberos name: CLIENT3.LOCATION2.TENANT1.A.B.C

If you want to set up some other logical network hierarchy you can. 
The choice is yours.

To answer your specific question, if you don't want to use DNS like 
names I think it is technically possible, this way of naming realms is 
only a convention. But why would you do this? The domain concept is 
pretty easy to implement and fits in with the way networks in TCP/IP 
are partitioned. It has the added bonus that basic things like routing 
and network filtering follow logically.

Or are you talking about linking networks and systems that are not 
related in any way except your tenancy concept ? If these networks and 
hosts are administered by different network administrators then you 
may find yourself falling foul of things like routing and network 
filtering. That is your clients and servers may not be able to use the 
kerberos protocol because the kerberos packets they depend on are not 
able to get through.

What I am saying is that  the network planning has to encapsulate you 
tenancy concept in the first place, or be made to encapsulate it. 
Which is going beyond a kerberos question.

And Kerberos doesn't support network partitioning, you plan the TCP/IP 
networks and how they are partitioned. Then you use Kerberos within 
that network, it has to be able to be used in the network.
> --- Original message ---
> Subject: RE: Multi-tenancy in MIT KDC
> From: Firouzeh Jalilian <fjalilian at vmware.com>
> To: Tim Mooney <Tim.Mooney at ndsu.edu>, kerberos at mit.edu 
> <kerberos at mit.edu>
> Date: Saturday, 30/05/2015 11:12 AM
>
> What is the definition of "realm" in MIT KDC?  Is it just different 
> domains?
>
> By definition of "tenant" I am referring to a categorization above the 
> "domains".  For example a tenant could have multiple domains, and when 
> a a user logs in there has to be an indicator of the "tenant" it 
> belongs to besides its the domain. As the domain may not be sufficient 
> to find the tenant the user belongs to.
>
> Is that something that is supported?
>
> Firouzeh
> ________________________________________
> From: kerberos-bounces at mit.edu <kerberos-bounces at mit.edu> on behalf of 
> Tim Mooney <Tim.Mooney at ndsu.edu>
> Sent: Friday, May 29, 2015 4:00 PM
> To: kerberos at mit.edu
> Subject: Re: Multi-tenancy in MIT KDC
>
> In regard to: Multi-tenancy in MIT KDC, Firouzeh Jalilian said (at 
> 10:24pm...:
>
>>
>> I would like to know if there is any support currently for 
>> multi-tenancy
>> in MIT KDC?
>
> What do you mean by multi-tenancy?  Do you mean one krb5kdc process
> serving multiple distinct realms?  If so, then yes, that's possible.
> We've served 11 different realms from one krb5kdc process.
>
> You have to run separate kadmind processes, each on a separate port,
> because those can't serve multiple realms.  On your secondary kdcs,
> you also need to run a separate kpropd per realm, each on its own
> port.
>
> We've done it for years and it works, but if we were starting over,
> these days I'm not certain I would choose the same path.  Depending on
> your realms, it might be better to use separate VMs or containers,
> depending on what you're comfortable with.
>
> Tim
> --
> Tim Mooney                                             
> Tim.Mooney at ndsu.edu
> Enterprise Computing & Infrastructure                  701-231-1076 
> (Voice)
> Room 242-J6, Quentin Burdick Building                  701-231-8541 
> (Fax)
> North Dakota State University, Fargo, ND 58105-5164
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.mit.edu_mailman_listinfo_kerberos&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=0wthfOXikoIWE5NfoxCN7_R8HXNMORzBYVlqWqEvHTA&m=cF...
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos