|
jfrench -> Visual SourceSafe 2005 publishing woes (14.Aug.2007 11:00:49 AM)
|
Hello,
I am trying to publish my company's Visual SourceSafe 2005 server using it's remote access feature. The remote access feature works via a web service which can be set up to use SSL. Obviously I want to use SSL so that my data isn't be shot all over the net in plain text. :) Having managed to publish Sharepoint, Exchange OWA, and Exchange Activesync / RPC over HTTP all with the help of Tom Shinder's articles I figured I'd be able to publish a simple webservice with SSL with very little headache. I was wrong!
Steps I've taken:
Setup the webservice app in IIS and requested a cert for the public domain name (vss.company.com). In "Authentication and Access Control" I unchecked everything but Basic authentication.
Exported the cert and installed it it in the Machine Account of the ISA using MMC Certificates snap-in
Created a listener for the external IP using the cert installed on the ISA (vss.company.com) and set up for Http Authentication with only Basic checked and Windows AD as the Validation method.
Created a publishing rule using my new listner. In the "To:" tab I have specified vss.company.com as the published site and 192.168.1.250 as the internal ip to connect to. I have checked the box for "Forward the original host header..." and "Requests appear to come from the original client." On the "Traffic" tab I have checked Rquire 128-bit encryption. On the "Public Name" tab i have specified vss.company.com. On the "Paths" tab i have set "/*" for internal and external. "Authentication Delegation" tab I have selected Basic authentication. Bridging is set up for SSL only on port 443.
So everything appeared to be set correctly so I gave it a spin. The service is accessed from a plug in in Visual Studio. When I try to access the service from behind my ISA using the Visual Studio plug in I get the basic authenticaion box. I enter my user name and password and everything works just fine. So I tried to do the exact same thing from outside my network and instead of getting prompted to authenticate, I get an error that says:
The SourceSafe Web Service cannot be accessed at the specified address.
Address: https://vss.company.com/SourceSafe/VssService.asmx
The server returned the following error: A connection with the server could not be established (0x80072EFD)
The plug-in advanced settings for SourceSafe Internet require SSL connections. Please, verify that your server can be accessed using secure connections or change your plug-in advanced settings.
So I fired up IE7 and entered https://vss.company.com/SourceSafe/VssService.asmx in the address bar. I have the root cert installed on my machine as a Trusted Root Cert authority so I didn't get any certificate errors, it just automatically trusted the cert. I got the Basic Authentication box where I entered my username and password. It authenticated me and gave me a Server Error page from the web service. (According to the VSS 2005 documentation this is the expected behavior when accessing the web service from a browser instead of the plug in).
So, it would appear that the ISA publishing rule is set up correctly since I get prompted to authenticate and then after successful authentication at the ISA server by credentials are passed to the published server and I get the expected behavior. So why doesn't it work from the plug-in? I have quadruple checked all my settings. I am using vss.company.com to access the service from the plug in, but I don't get prompted to authenticate.
I did some logging in ISA and found that when I connect via IE I get Initiated Connection with result ERROR_SUCCESS followed by Closed Connection with result GRACEFUL_SHUTDOWN then I get Denied Connection for Rule Visual Source Safe (the name of my VSS publishing rule) as expected since it requires authentication. However when I try to connect via the Visual Studio plug-in I get Initiated Connection with result ERROR_SUCCESS follow by Closed Connection with result GRACEFUL_SHUTDOWN but it never hits the Visual Source Safe publishing rule.
I have used fiddler to monitor the requests and the only difference appears to be that the client is identified as User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2) when using IE and User-Agent: VCSoapClient when using the plug-in. Does ISA server respond/react differently depending on the user agent?
Any ideas or advice?
Thanks,
Jeff French
|
|
|
|