Hi all,

We’re trying to roll out a multi-tenant Kerberos realm service here at ViaSat.  
We have a root realm (something like VIASAT.COM) that has principals for all 
the users, and then a series of sub-realms (A.VIASAT.COM, B.VIASAT.COM, etc) 
that have one-way trust relationships with the root.  For regular service use, 
this is working fine.  Users in VIASAT.COM can properly authenticate to a 
service in B.VIASAT.COM, for example.

We are running a single multi-realm KDC process, along with a kadmind process 
per realm, on a single host, backed by an LDAP database.  The KDC is running on 
default ports, but each kadmind is running on a dedicated pre-defined port.  
The procs looks something like

/usr/sbin/kadmind -P /var/run/krb5-admin-VIASAT.COM.pid -r VIASAT.COM
/usr/sbin/kadmind -P /var/run/krb5-admin-A.VIASAT.COM.pid -r A.VIASAT.COM
/usr/sbin/kadmind -P /var/run/krb5-admin-B.VIASAT.COM.pid -r B.VIASAT.COM
/usr/sbin/krb5kdc -P /var/run/krb5kdc.pid -r VIASAT.COM -r A.VIASAT.COM -r 
B.VIASAT.COM

The problem is with our admin principals.  I can’t seem to get our KDC to hand 
me the service ticket that I want.  Each time I run a `kinit -S 
kadmin/ad...@b.viasat.com -c ccache skemper/ad...@viasat.com` I get back a 
service of kadmin/ad...@viasat.com, the root realm.

From what I can tell, when I issue that command, the request that’s getting 
sent over the wire is only encoding the service name (“kadmin/admin”), rather 
than the entire principal of the service I want.  Since serving multiple realms 
out of a single KDC is supported, I would expect a way to tell said KDC which 
realm I want a given service ticket from.  Maybe I’m missing something?


Thanks,
Stephan Kemper
ViaSat, Inc.


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

Reply via email to