Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure
Jeffrey Altman
jaltman at secure-endpoints.com
Thu Aug 16 13:06:22 EDT 2007
Newman, Edward (GTI) wrote:
> The issue here is that the client doesn't know the correct realm for the
> service ticket it only knows the machine FQDN. It would therefore need
> to go the KDC of the realm it belongs to and ask for a service ticket
> for the service FQDN and the client realm.
That is exactly what the referral mechanism is for. The client doesn't
know the realm because
it has no locally configured data from which to make the decision so it
asks its local realm's
KDC to determine the realm based upon the data that it has available to it.
> The KDC, which may support
> trusts to multiple other realms,
If the KDC does not share keys with other realms it cannot perform a
referral as the client
would not be able to authenticate to the referred realm.
> needs some way to map FQDN and/or
> service principal to a specific realm and return this back to the
> client.
This is done by configuring data on the KDC using either the
[domain_realms] section
of the krb5.conf file, lookups in a local or external database, etc.
> Sounds almost like there is a need for another administrative
> protocol to allow trusting realms to share/cache their service
> principals so that the referral directs to the correct trusted realm.
Active Directory and its GC support LDAP for queries. Any KDC that
shares keys with
a Windows Domain can perform lookups against AD to determine if the service
principal name that is requested is present.
I believe it is also possible for organizations that wish to license the
Microsoft propriety
data synchronization protocols to do so.
I'm not sure that it is necessary for there to be yet another database
exchange protocol
defined for sharing inter-realm data. From a practical perspective, the
MIT database
replication protocol, kprop, doesn't even support multi-master yet let
alone something
else. The beauty of the pluggable database back-end support in MIT
Kerberos is that
the OEMs that create enterprise solutions can take the MIT code and
integrate it with
a database back-end that does support multi-master synchronization of
local realm or
global realm data or even performs queries to remote databases on the fly.
Anyone can implement LDAP in front of their directory service /
database. Microsoft,
Novell, etc. have all done it. So there does in fact exist a protocol
for queries and there
are a number of LDAP Content Synchronization products out there.
Where there can
be benefit from standardization is of the "schema" of the data that is
stored and used
to resolve these "where is xxxx located?" queries.
> This would be unnecessary when the KDC shares a common repository (as is
> the case with AD and a GC) but not with cross-forest trusts.
>
There is certainly a mechanism that Microsoft uses for synchronizing
data Global Catalog
data between multiple AD forests.
I'm not sure that the IETF needs to develop one that is specific to the
Kerberos protocol.
The question of zero configuration of clients has been around for a very
long time. We
absolutely need to solve it for Kerberos to become a universal
solution. I am assuming it will
be one of the highest priorities for the Consortium and it will require
the participation of
all of the major implementations.
Jeffrey Altman
Secure Endpoints Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20070816/e9eb580c/attachment.bin
More information about the Kerberos
mailing list