Re: Windows Server Referral Problem
- From: "Richard E. Silverman" <res@xxxxxxxx>
- Date: 03 Sep 2007 17:33:59 -0400
"EN" == Newman, Edward (GTI) <edward_newman@xxxxxx> 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@xxxxxxxx
.
- References:
- Re: Windows Server Referral Problem
- From: Newman, Edward (GTI)
- Re: Windows Server Referral Problem
- Prev by Date: Re: regarding clock skew difference between client and KDC
- Next by Date: Re: Kerberos 5 certified under NIST 140-2.
- Previous by thread: Re: Windows Server Referral Problem
- Next by thread: Re: Kerberos 5 certified under NIST 140-2.
- Index(es):
Relevant Pages
|
