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