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.