Russ and Co.:
Going back to the original post. The scenario described is one in
which there are two user principal names which differ only by the
REALM
Administrator@NATIVE.WIN2003.COM (realm A)
Administrator@WIN2000.WIN2003.COM (realm B)
and there is no cross-realm authentication configured.
Let's assume we are attempting to authenticate from a machine in realm A
to a machine in realm B. Let's see how this would play out if fully i
Windows is going to query the realm A KDC to try to obtain a service
ticket for the machine in realm B. The realm A KDC does not have a
cross-realm authentication configured but it can still provide a
referral by using its knowledge of other domain controllers collected
in the Netbios name service and/or via DNS.
DNS contains two records. The first is a TXT which provides for a
mapping from the hostname to the realm name.
_kerberos.win2000.win2003.com TXT "WIN2000.WIN2003.COM"
This is used to search for the realm name of a fully qualified domain
name by systematically removing components from the left hand side one
at a time until a match is found.
The second is a SRV record which specifies where the KDCs are for a
given realm.
_kerberos._tcp.win2000.win20003.com SRV 0 0 88 dc1.win2000.win2003.com
With these records in place the realm A KDC can provide a referral to
the client instructing it to contact the realm B KDC for the desired
principal.
At this point the client knows it does not have a cross-realm TGT for
the new realm and will have to attempt to authenticate directly by
acquiring a new TGT for realm B.
Not that I believe Microsoft actually implemented the following steps
but they could. The client wants to communicate with realm B, therefore
it sends a TGS_REQ message for "Administrator@WIN2000.WIN2003.COM" and
attempts to decrypt the response using the password which was cached
when the logon session was established. Assuming the decryption was
successful, a subsequent request would be made for the service ticket
for CIFS/hostname.win2000.win2003.com@WIN2000.WIN2003.COM and the
cifs authentication would proceed without human intervention.
Now I believe that if you want Kerberos to be used for connections
outside of your local forest that you must include the foreign domain
in your "Local Trust Zone" within the Internet Options control panel.
At least this is true if you are using IE to connect to a Kerberos
secured web page. If the foreign domain is listed in the Local Trusts
then Kerberos will be used instead of NTLM to authenticate after the
user is prompted for a username and password.
It has been noted that NTLM will always be used as a fallback when
a host is contacted by IP address. This is because Kerberos provides
name based authentication and there is no secure means at the moment
for converting from an IP address to a fully qualified domain name
for use in constructing a service principal name.
Jeffrey Altman
-----
NTBugtraq Editor's Note:
Want to reply to the person who sent this message? This list is configured such
that just hitting reply is going to result in the message coming to the list,
not to the individual who sent the message. This was done to help reduce the
number of Out of Office messages posters received. So if you want to send a
reply just to the poster, you'll have to copy their email address out of the
message and place it in your TO: field.
-----
