[isapros] Re: Publishing Longhorn TS Gateway with ISA Server 2006
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 5 Jan 2007 21:31:00 -0800
Stefaan, you're a real troublemaker - keep it up.
The correlation between OL and TSG is the RPC component, but I guess you
already know that.
It is also the failure point for your TFA efforts and it will likely
remain so.
"Without strong two-factor authentication..." is going to cause you to
drink (more?) heavily. You will not see TFA for RPC/HTTP-based
application in the near (or far?) future. The ability to render the
page and post the auth data and related cookie data back to the
authenticator is a complex mess. It's unreasonable for you to expect
any non-browser such as an RPC/HTTP client (whether OL or TSG) to have
any FBA capabilities.
I agree that a lack of Basic auth for the RDPv6 client is odd,
especially given the support for SSL-based RDP traffic.
Getting the Office and TSG teams (or any two unrelated product teams) to
"match efforts" takes a huge customer noise. You'll have to start a
stronger "grass-roots" movement if you want this to make any headway.
For instance; two years ago I filed a bug with the RPC team because they
failed to handle the case where the RPC/HTTP transport hits a documented
limitation in WinHTTP as described in
http://msdn2.microsoft.com/en-us/library/aa383157.aspx. Basically,
WinHTTP can only use one array member, regardless of the number of
servers in that array. "Documented limitation" == no obligation to
change it.
The short form of this issue is that if:
1. RPC/HTTP client (OL or TSG)
a. uses a multi-server array
b. obtains the array server list via wpad
2. the first server in the list fails to respond
..the connection to the remote destination will never be made
The long form is:
1. OL client makes MAPI to RPC configured for RPC/HTTP
2. RPC/HTTP translates the RPC data to HTTP and passes it to WinHTTP
3. WinHTTP acquires WPAD script with # servers listed
4. WinHTTP attempts to connect to <Server1>
5. <Server1> fails to respond (we don't care why)
6. WinHTTP acquires WPAD script from next server in list (cycle back to
first if end-of-list)
7. repeat 4-6 until user gets disgusted
Because OL RPC/HTTP service providers *always* require SSL connections,
the only way to sort this out is to use WinHTTP tracing; but this
assumes that the troubleshooter knows:
1. OL RPC/HTTP uses WinHTTP
2. WinHTTP has plain-text tracing
3. How to enable WinHTTP tracing
4. how to interpret WinHTTP tracing
..like I said; a real beatch to sort out.
I pointed out that due to the deep dependency between OL, RPC and
WinHTTP, the connection failures are nearly impossible for Jo(sephin)e
User to sort out. Yes; this will affect TSG clients too, if they have
to use an array where the first array member in the wpad script (not
necessarily the first array member) fails to respond.
..it only gets funnerer from here...
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Stefaan Pouseele
Sent: Friday, January 05, 2007 4:08 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Publishing Longhorn TS Gateway with ISA Server 2006
Hi,
I'm currently testing out the publishing of a Longhorn TS Gateway with
the ISA Server 2006. As you probably know the protocol used is "RPC over
HTTPS"
just like the Outlook Anywhere client. MSKB
http://support.microsoft.com/kb/884506 is referenced to get it working.
However, that MSKB suggest the use of Forms based authentication and
that means for the MSRPC agent a fall-back to Basic authentication.
Now, if you look carefully to the RDP V6 client, it tells you that for
password authentication only NTLM is supported. If I change the Web
listener to Integrated authentication than it works flawless. Even
better, I can select Windows as Authentication provider and use Kerberos
constraint delegation as Delegation method. That works all without
problems as long as NTLM is used between the RDP client and the ISA
Server.
The final goal is to require strong two-factor authentication (i.e.
Vasco or Safeword token) against the ISA Server. In contrast to Outlook
Anywhere, the RDP V6 client enables the use of two separate sets of
credentials, one to authenticate against the TS Gateway (or the ISA
Server) and one to authenticate against the real destination. However,
due to the fact that the RDP V6 client doesn't support Basic
authentication, we can't use Radius or Radius OTP as Authentication
provider in ISA Server (
http://blogs.isaserver.org/pouseele/2006/12/26/playing-with-radius-authe
ntic
ation-and-isa-server-2006/ ).
Is there any information available how we can enable the RDP V6 client
to use Basic authentication instead of NTLM?
Without strong two-factor authentication I can't accept "RPC over HTTPS"
as an equivalent of an SSL-VPN solution.
BTW --- with Outlook Anywhere we don't have two separate sets of
credentials but do have Basic authentication, and with the RDP V6 client
we do have two separate sets of credentials but don't have Basic
authentication. Why can't both teams work together and create a solution
that enables the use of two separate sets of credentials *and* Basic
authentication (it can't be that hard!)? It's a real shame! :-(((
Thanks,
All mail to and from this domain is GFI-scanned.
Other related posts:
