[28278] in Kerberos
Re: Standard mechanisms to manage domain->realm mappings
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Thu Aug 16 11:31:08 2007
Message-ID: <46C46DFF.6090307@secure-endpoints.com>
Date: Thu, 16 Aug 2007 11:32:15 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: edward_newman@ml.com
In-Reply-To: <E5F741E838FC2043A0B843E481818138051ADEF5@MLNYC730MB.amrs.win.ml.com>
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Cc: kerberos@mit.edu
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============0170097836=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============0170097836==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms020604020500000704070801"
This is a cryptographically signed message in MIME format.
--------------ms020604020500000704070801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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@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.
--------------ms020604020500000704070801
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX
DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c
bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF
PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184
9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d
1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1
AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk
0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr
5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU
3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl
DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL
AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM
94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV
lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t
ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3
UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA4MTYxNTMyMTVaMCMGCSqGSIb3DQEJBDEWBBRROMZu
gjP9C2F0j1D7ExOahVt1BTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ
KoZIhvcNAQEBBQAEggEAYpXp1ne5IZKjQMI5p9NRSc+9zihMVIbSat5gXHOvKSLz4yln4/ko
ZFGG7bZCh+S2M5RqaQLGHI9xMPJNcb8sHvnK+dETn7dUfgURnGWjLQEppmt38Xcqw14bmn4z
I67jARILupF/xvEbTEy//TCrv5lVD46Pyg5X+Wv0z5ro8CiqrWOAWNFMBZJ+ouI3lUhDu56V
nNIubnHfHtRgVoQdW1HHO5V12UMxLoiSHOhSeY2dfsFZsIswOr4mJv35Jq93UkVG+IeCrnku
EecW2/5AKmqcNUC3rihroAp712Q63iDeHe8WhER1FKzIcbDTjRCNCo6jo3gW+61NgAo3rzR5
fQAAAAAAAA==
--------------ms020604020500000704070801--
--===============0170097836==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============0170097836==--
