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

[Jeffrey Altman]

Newman, Edward (GTI) wrote:
> One additional comment on example below - having more than one realm
> within one DNS domain is likely to cause a lot of pain as you will not
> be able to use SRV records for KDC identification. 
SRV records are used for location of the KDCs in a realm.  Unless you
have two realms
with the same name (which won't interoperate) this will not be a problem. 

    Realm A.EXAMPLE.COM
       a-kdc-1.example.com
       a-kdc-2.example.com
    Realm B.EXAMPLE.COM
       b-kdc-1.example.com
       b-kdc-2.example.com

SRV records are then created with the following names to represent those
KDCs.

       _kerberos._udp.A.EXAMPLE.COM
       _kerberos._tcp.A.EXAMPLE.COM
       _kerberos._udp.B.EXAMPLE.COM
       _kerberos._tcp.B.EXAMPLE.COM

This SRV records are independent of the domain name of the KDCs.

If you meant TXT records instead of SRV records, they can be set on a
per host basis.

Jeffrey Altman

>
> Jeffrey Altman wrote:
>
> The reason this is an issue is if your organization's domain is foo.com
> and you have both a MIT realm and an AD realm where the hosts in the two
> realms both belonging to the foo.com domain.   In this situation the
> organization must list each individual host that provides a service in
> the krb5.conf domain_realm section.  As you add or remove hosts, you
> must update the krb5.conf files.  This is exactly the reason why KDC
> referrals are so important for scalability.
>
> ___________________________________
> Edward Newman
> GTI A&E Identity & Naming Services
> Merrill Lynch, 9th Fl, 222 Broadway, New York, NY 10007, USA
> Phone : +1-212-670-1546  Cell: +1-917-975-2356
> --------------------------------------------------------
>
> This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
> --------------------------------------------------------

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