Windows Server Referral Problem

[Richard E. Silverman]

>>>>> "EN" == Newman, Edward (GTI) <edward_newman at ml.com> writes:

    EN> Markus I have a request out to Microsoft to get more information
    EN> on this.  Microsoft apparently are not following the draft IETF
    EN> standard as yet but have something similar (pre-draft spec)
    EN> implemented in 2000/2003. 09 spec shows differences in Appendix.

    EN> I would check both DNS and AD:

    EN> - For DNS check that server2.example.com has a correct forward and
    EN> reverse. Possible that reverse maps back to another name and thus
    EN> wrong SPN being requested from AD - Check AD has the right SPN
    EN> registered in domain. I also assume this is one forest and you
    EN> left appropriate delay for new server to replicate.

    EN> It is not clear (to me...) how Windows does cross-forest but
    EN> within forest it can look up SPN through Global Catalog and return
    EN> referral to correct domain.

For cross-forest, Windows has "top-level name translations" (TLN's).  A
TLN is a mapping from a domain name suffix to a realm.  When Windows
consults the GC to satisfy a ticket request, if it doesn't find the
principal, it first matches the principal hostname against the defined
TLN's, and returns a referral to the specified realm if there's a match.
For instance, to define a TLN in the realm WINDOWS mapping hostnames
*.unix.foo.com to a realm UNIX, use these Windows commands on a domain
controller:

netdom trust WINDOWS /domain:UNIX /foresttransitive:yes
netdom trust WINDOWS /domain:UNIX /addtln:unix.foo.com

I use this to solve the problem of Windows clients accessing Unix-based
kerberized services which reside in a Unix-based realm, via cross-realm
trust.  The problem is that Windows always assumes any server is in its
own realm, and generates a ticket request for Unix-based principal in the
Windows realm.  This trick provides the needed referral.

    EN> Edward

    EN> I have a problem with server referrals in my Windows environment.
    EN> I have two Unix webservers server1.example.com and
    EN> server2.example.com with SPNs HTTP/server1.example.com and
    EN> HTTP/server2.example.com respectively. Both

    EN> SPNs are setup under a Windows 2003 SP2 domain test.example.com.
    EN> test.example.com has a two way trust to example.com (2003 SP2
    EN> domain) which has a two way trust to prod.example.com (2003 SP2
    EN> domain).

    EN>                     EXAMPLE.COM / \ / \ TEST.EXAMPLE.COM
    EN> PROD.EXAMPLE.COM


    EN> The problem I have that a user from prod.example.com can access
    EN> server1 and authenticate, but can not authanticate to server2. The
    EN> reason is that the client gets an error "unknown principal" from
    EN> prod.example.com when requesting a TGS for
    EN> HTTP/server2.example.com whereas for HTTP/server1.example.com the
    EN> client gets a TGS referrals reply to example.com and from there to
    EN> test.example.com.

    EN> What determines on the domain controller prod.example.com to reply
    EN> with a referral to a TGS Req ?

    EN> BTW I only assume the replys are referrals as the TGS Req does not
    EN> have the canonicalisation option set and the TGS Rep doesn't have
    EN> pa-data as described in
    EN> draft-ietf-krb-wg-kerberos-referrals-09.txt. Does Windows follow
    EN> that draft ?

    EN> Thank you Markus


    EN> Edward

    EN> ___________________________________ Edward Newman GTI A&E Identity
    EN> & Naming Services Merrill Lynch, 9th Fl, 222 Broadway, New York,
    EN> NY 10007, USA Phone : +1-212-670-1546 Cell: +1-917-975-2356
    EN> --------------------------------------------------------

    EN> This message w/attachments (message) may be privileged,
    EN> confidential or proprietary, and if you are not an intended
    EN> recipient, please notify the sender, do not use or share it and
    EN> delete it. Unless specifically indicated, this message is not an
    EN> offer to sell or a solicitation of any investment products or
    EN> other financial product or service, an official confirmation of
    EN> any transaction, or an official statement of Merrill
    EN> Lynch. Subject to applicable law, Merrill Lynch may monitor,
    EN> review and retain e-communications (EC) traveling through its
    EN> networks/systems. The laws of the country of each sender/recipient
    EN> may impact the handling of EC, and EC may be archived, supervised
    EN> and produced in countries other than the country in which you are
    EN> located. This message cannot be guaranteed to be secure or
    EN> error-free. This message is subject to terms available at the
    EN> following link: http://www.ml.com/e-communications_terms/. By
    EN> messaging with Merrill Lynch you consent to the foregoing.
    EN> --------------------------------------------------------

-- 
  Richard Silverman
  res at qoxp.net