Re: Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure
- From: Danny Mayer <mayer@xxxxxxxxxxx>
- Date: Wed, 15 Aug 2007 23:18:26 -0400
Newman, Edward (GTI) wrote:
What are the preferred mechanisms to manage DNS domain to Kerberos Realm
mappings in large implementations?
I want to avoid having to redistribute a krb5.conf to every client each
time this changes so was wondering how others have solved this problem.
How often do you think this changes and what is wrong with the SRV
records that Kerberos currently uses?
Need some solution that supports a combination of the following
platforms:
- Active Directory 2003
- MIT Libraries
- Sun Java JDK
- Quest Vintela
+ other proprietary implementations
Looking online suggests the following:
1) DNS TXT records
- DNS TXT records used to link a DNS domain to Realm via
_Kerberos.<Domain-name>
- Apparently vulnerable to MITM attacks (is this an issue in closed
environments?)
MITM attacks mostly happen that way.
- Appears to be support by MIT & Heimdal but not by Java JDK Kerberosproprietary, and if you are not an intended recipient, please notify the
libraries or various commercial products
- Still an IETF draft (draft ietf cat krb dns locate 02 txt)
2) Kerberos Server referrals
- KDC returns referrals to client when request made to local environment
- supported by Windows AD 2003 & MIT (limited documentation on how
mappings managed for referral process)
- Still an IETF draft (draft ietf krb wg kerberos referrals 09 txt)
3) Standard krb5.conf/ini [domain_realm] mappings
- appears to be best supported by various products
- pain to deploy in large environments
Thoughts? Suggestions? Is this on the Kerberos-wg plan?
--------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or
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.
--------------------------------------------------------
No, I don't consent to any of this and by replying I don't automatically
give my consent, nor will I go and look at that URL. This is a public
mailing list so I can't even tell whether or not I'm even the intended
recipient. What I do with a message that you send me is my business and
you have no right to dictate what I do with it.
Danny
.
- Prev by Date: Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure
- Next by Date: RE: Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure
- Previous by thread: Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure
- Next by thread: RE: Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure
- Index(es):
Relevant Pages
|
Loading
