SourceSafe Internet Plugin and IIS on W2K Server

SourceSafe Internet Plugin and IIS on W2K Server

• RonSQL

  You already have VSS installed on your IIS server. All is left is

  1. create new VSS database,
  2. set the same file access rights as your original database,
  3. create share with the same level of access for your users
  4. enable this new database for remote access using VSS Admin
  5. verify this new database is accessible from your client computer via HTTP

  
  

• Donat Michal

  Hi Alin,
  Thanks for the very quick response. I read the linked web page to understand what you were driving at. I opened the ASPNET account properties and sure enough its "Account is trusted for delegation" option was not selected. I selected it and tried again. I got exactly the same error. Unfortunately there does not seem to be any logging anywhere to give me a better clue as to what might be going on. There also does not seem to be another VSS tool/client I can run that uses the internet facility that I might run and get better error messages back than provided by the Visual Studio plugin. Any other ideas would be appreciated.
  Maypo
  
  

• Brock

  Roman,
  Thanks for the suggestion - I did not try this initially as we have a full-blown VSS setup already running on the file server (not the web server). I would prefer to get this working without that step - but may be forced to do that and take "baby steps".
  Maypo
  
  

• mizatch

  Hi Maypo,

  I am not familiar with DC and enabling delegation on Win2k, but if I understand correctly http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnnetsec/html/SecNetHT05.asp

  the steps 5-8 are Win2k3 specific (which supports constrained delegation).

  According with that article, on Win2k checking "Trust computer for delegation" in General tab enables the delegation for processes running under SYSTEM account.

  On Win2k the VSS service runs under using the aspnet_wp.exe process, using the ASPNET Windows account, so I think you need to enable delegation trust for the "ASPNET" account like below:

  To confirm that the server process account is trusted for delegation if the server process runs under a Windows user account

  1. Within the Users folder of Active Directory Users and Computers, right-click the user account that is used to run the server process that will impersonate the client, and then click Properties.
  2. Click the Account tab.
  3. Within the Account options list, click Account is trusted for delegation.

  Please let us know if this fixes the problem (if yes, we need to update the MSDN page for VSS)

  Thanks,

  Alin

  
  

• Nicola Zanardi

  VS will attempt to connect using SSL first even if SSL is not required on the client.

  You could do one of the following things:

  1. Start using SSL (use server name SSL certificate is created for in the VSS database connection string on the client)
  2. Block SSL on this web service (remove default SSL port from the web server)
  3. Create new web service for VSS Web service

  
  

• ciberskiper

  Alin,
  The same user doing my testing is able to access the VSS database directly using Visual Studio and a network share. That would seem to indicate that his permissions should be fine I will check that however and also restart the server.
  Maypo
  
  

• greekgeek

  Were you able to access a database that is located on the web server

  I’d start with database local to the web server and when this is working moved on to the remote database. Of course I’d also double checked permissions on the share and the files on the remote server making sure this account has read/write access to both share and the files.

  
  

• jmk

  It's not the ASPNET account that needs R/W permissions on the remote share, it's the Windows user's account used to authenticate with the server that needs share permissions.

  I'd also try though is to stop and restart IIS (and maybe reboot the server), because I don't know if delegation settings change are applied to already running aspnet_wp.exe processes.

  Alin

  
  

• devnet247

  Alin,
  Bouncing the server did "improve" things in that we get further along and now have a new error message:
  "The SourceSafe Web Service cannot be accessed because the server name specified in the following address does not match the machine name for which the SSL certificate was issued."
  
  This is strange since we are specifically NOT doing SSL for SourceSafe. I configured the server to not use SSL and the client is configured the same. Trying to reduce variables.
  Any thoughts
  Maypo
  
  
• SourceSafe Internet Plugin and IIS on W2K Server