Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure

[Jeffrey Altman]

Newman, Edward (GTI) wrote:
> Jeffrey,
>
> Is there any documentation (apart from IETF draft) that describes the
> admin procedures to maintain this (MIT and hopefully MS AD...)?
The IETF draft is a protocol specification.  It is not an implementation
specification.
Microsoft Windows Server 2000 and 2003 implementation is not the IETF
draft.  The IETF
draft started from the Microsoft implementation and is attempting to
fill in many of the
edge cases that must be addressed in an environment that is not purely
Active Directory.

Microsoft Active Directory uses its Global Catalog to publish service
names across all of
the Windows Domains.  When a request is made to AD if the service is not
present in
the local domain, a Global Catalog search is performed and then the
result is used to
form a referral.

MIT and Heimdal have varying degrees of referrals support implemented.  
There are no complete implementations of the IETF referrals draft.

>
> My understanding from draft is the following:
>
> - Two realms exist REALM1.CORP.ORG and REALM2.CORP.ORG
> - A server abc.us.corp.org exists in REALM2
> - A client making a request for host/abc.us.corp.org to REALM1 KDC
> (using REALM1 as realm) should get a referral to REALM2 through Kerberos
> - Client will then follow current process to get a cross-realm ticket
> and then contact KDC in REALM2 for service ticket.
>
> Questions appear to be:
>
> - How does REALM1 know that service is in REALM2 (especially if you have
> REALM3, 4, etc)
Either by rule or database lookup.  For example, a request for
host/foo.b.example.com at A-REALM
can be mapped to a referral B-REALM via a domain_realm mapping or rule
application. 
Or it can be determined via a database lookup as Microsoft does in its
global catalog.
> - Does referral support returning multiple alternate realms? Does client
> perform traversal of all supplied realms?
There is no support for referrals to multiple realms.  The client is
requesting a service ticket
for a single entity.  The assumption is that there is a single instance
of that entity.  If it is not
in the current realm, the KDC can instruct the client which realm to ask
and provide a cross-realm
TGT to use when contacting the alternate realm.

If you have an application that has service instances in multiple realms
and you wish to provide
fail over to multiple locations, you must use either DNS SRV or LDAP
queries to determine
the service names so that you can determine which service ticket name(s)
should be obtained
via the KDC.

> - Which technologies supports this capability today?
Different degrees of referrals support are provided by AD, Heimdal, and MIT.
>
> Concern would be that every KDC needing to maintain mappings of hostname
> to realm for every trusted realm (did someone mention LDAP backend...).
Better every KDC than every client.   The reality is that someone needs
to maintain the
mapping database. 
>
> Kerberos docs still show dns_lookup_realm and TXT support. Is this going
> to supported long term or will you be moving to server referral as
> preferred mechanism within MIT implementation? 
dns_lookup_realm via TXT record is used at a variety of sites.  It is
disabled by default
but if you want to have a zero-configuration deployment today and can
accept the
associated risk it does provide a high degree of usability.
> Don't see mention of
> server referrals in 4.1 section of krb5-1.6.2 admin guide.
>
> I am sure you are aware this is critical for large deployments where
> managing host to realm mappings becomes complex.
>
Absolutely.  This is one of the issues that the MIT Kerberos Consortium
has been formed to address. 
        http://www.kerberos.org/
I encourage organizations that want to see global standards-based
cross-platform solutions
for large deployments to support MIT's efforts by joining the
Consortium.  The Consortium's
staff will play an active role in standards development and reference
implementation. 
Through its membership it will help foster universal adoption and
deployment of the standards-
based solutions.

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/864eb48b/attachment.bin