Can't connect to VaultShadowFolder Service

Jakana · Post by **Jakana** » Wed Nov 17, 2004 1:45 pm

I have Vault 2.0.6 running on Small Business Server 2003. The VaultService is working great, but I am having major problems getting shadow folders to work.

From the Admin Tool, every time I click "Configure Shadow Folders" I get an error dialog box that says "The request failed with HTTP status 401: Unauthorized".

Trying the URL "http://<server>/VaultShadowFolder/" in a browser I get the same thing "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials."

I have verified that the IIS Virtual directory VaultShadowFolder exists and has anonymous access enabled. I tried deleting and re-creating the virtual directory (I had read in another post that sometimes this virtual directory can become corrupt). Anyway, still giving the same error.

The only other thing that I can think of that might be relevant is that I followed the instrucitons in a KB article for preparing shadow folders to network/UNC folders -- I modified the VaultService web.config file to impersonate a domain account. To eliminate the possibility that the domain account didn't have appropriate permissions, I temporarily added the domain account to the Administrators group.

I also read that changing the Vault "admin" password outside of the Vault Admin Tool does not update the password in the shadow folder service. Suspecting that someone may have changed the admin password outside of the Vault Admin Tool, I opened the Admin Tool and tried to update the "admin" password. However, when I set a new password I get the following message: "The Admin password HAS BEEN CHANGED. However, an attempt to update the Shadow Folder Service has failed. If you use Vault's Shadow Folders, please investigate this error. Otherwise, you may safely ignore this error message. The request failed with HTTP status 401 : Unauthorized."

It would appear that I'm not authorized to connect to the Shadow Folder Service (*sarcastic grin*).

I looked at the web.config file in the VaultShadowFolder directory, and see the admin username/password in there. However, I didn't recognize the password and figured it was probably encrypted so I didn't mess with it.

Oh, and a quick look at the vault log file didn't seem to reveal any new information.

OK, I've run out of ideas! Any suggestions?

Post by **jclausius** » Wed Nov 17, 2004 2:05 pm

Jakana:

Does SBS 2003 run IIS 6? If so, take a look at the Shadow Folder's Virtual directory. It should be running under an application pool.

On some installations, we've achieved success, by :

1) Creating a new application pool ( specifically for Shadow Folder ).
2) Setting the Identity property to the .Net domain account.
3) Assigning the new app pool in the Shadow Folder's virtual directory.
4) Removing identity impersonation in VaultShadowFolder's web.config.

Is there anything in your VaultShadowFolder's web.config regarding authentication / authorization?

What about a web.config located in your wwwroot - does a web.config file exist there?

Guest · Post by **Guest** » Wed Nov 17, 2004 3:00 pm

jclausius wrote:Jakana:

Does SBS 2003 run IIS 6? If so, take a look at the Shadow Folder's Virtual directory. It should be running under an application pool.

On some installations, we've achieved success, by :

1) Creating a new application pool ( specifically for Shadow Folder ).
2) Setting the Identity property to the .Net domain account.
3) Assigning the new app pool in the Shadow Folder's virtual directory.
4) Removing identity impersonation in VaultShadowFolder's web.config.

Is there anything in your VaultShadowFolder's web.config regarding authentication / authorization?

What about a web.config located in your wwwroot - does a web.config file exist there?

SBS 2003 does run IIS 6, and before reading your reply the VaultShadowFolder virtual directory was set to run the the default app pool.

I followed your instructions, except that I wasn't sure what account to use when you said "setting the Identity property to the .Net domain account." I wasn't sure if you meant a Predefined account (Network Service, Local System, etc.) or if you meant a domain account that I setup for the purpose of controlling the App Pool. I tried a few different accounts but none of them worked, so I set it back to the default "Network Service" predefined account.

I have one web.config file in the "VaultService" directory, and another in the "VaultService/VaultShadowFolder" directory. There isn't a web.config file in the wwwroot.

I've attached both web.config files to this reply for reference. For now I've commented out identity impersonation in both files. However, I am ultimately trying to create shadow folders on a network/unc path, and I think I'll need to enable impersonation for this to work.

Post by **jclausius** » Wed Nov 17, 2004 3:36 pm

Sorry about any confusion.

In the newly created app pool's properties, there is a tab marked Identity. Use this to enter the name of the Custom .Net Domain Account you created ( the account you created with all of the special .Net policy settings / NTFS security settings etc ). The value here will be used in lieu of the settings in web.config.

When complete, on the Vault server, BROWSE to http://localhost/vaultshadowfolder/vaul ... rvice.asmx.

Do you still get an unauthorized error or do you get the Shadow Folder Service description page?

Guest · Post by **Guest** » Wed Nov 17, 2004 4:13 pm

No need to apologize -- I appreciate the help!

OK, now I'm getting a different error. When I open the browser to the shadow folder service I get a "503 : Service Unavailable" error. I see that the new VaultShadowFolder App Pool has stopped with "unspecified error." I looked in the Event Log for more info and see an error from W3SVC: EventID 1059, "A failure was encountered while launching the process serving application pool VaultShadowFolder. The application pool has been disabled." I couldn't find any additional info on this error in the MS Knowledge Base.

I re-started the application pool and then opened the Vault Admin Tool and went to "Configure Shadow Folders". I then got an error dialog box that says, "The request failed with HTTP status 503: Service Unavailable." (same HTTP error as the browser)

This is really starting to get frustrating. I've verfied all the folder permissions and domain security policies were set as described in the KB post (http://support.sourcegear.com/viewtopic ... dow+folder). Even when the domain user account is given full Administrative rights on the domain, I get the same error.

I still have the identity impersonation commented out in both web.config files.

Post by **jclausius** » Wed Nov 17, 2004 5:22 pm

It still looks like the Custom Domain Account is still missing enough permissions to run an ASP.Net process.

I'll do some digging to see if I can find a link on setting up identities within App Pools for Custom Domain Accounts.

In the mean time, can you see affect setting the Vault Shadow App Pool to use NETWORK SERVICE as the identity, and assigning identity impersonation in Shadow Folder's web.config has on the entire process? Can you browse to the Shadow Folder Service?

Jakana · Post by **Jakana** » Wed Nov 17, 2004 5:29 pm

Nope -- when I set the App Pool back to "Network Service" and then set identity impersonation in the web.config file (the VaultShadowFolder web.config) it gives me the 401.1 - Not Authorized error again.

Post by **jclausius** » Wed Nov 17, 2004 8:43 pm

I'm still looking for configuring a Custom .Net account for Win 2003 server.

Another question... Have you checked the Directory security configured for VaultShadowFolder, VaultService, Web Site, all the way up the server chain. Is it possible something on one of those sites has Disabled Anonymous access for the security option?

One other thing to double check is the NTFS permissions on the physical directories of Vault and the VaultShadowFolder sub folder. Each should have the Custom .Net account.

Post by **jclausius** » Wed Nov 17, 2004 8:59 pm

Some other things I noticed:

In Shadow Folder's web.config, lets try uncommenting the authorization section:

Code: Select all

<authorization>
   <!-- Allow all users -->
   <allow users="*" />
</authorization>

Additionally, double check the identity impersonation is uncommented

Code: Select all

<identity impersonate="true" userName="MYDOMAIN\USER_ACCOUNT_NAME" password="PWD_HERE"/>

I'm still digging around for possible 401.1 errors.

Post by **jclausius** » Wed Nov 17, 2004 9:22 pm

Jakana:

The only thing I can find related to 401.1 is that the IIS Virtual Directory is not allowing anonymous access. Is there perhaps anything in the Event Viewer now ( related to running under the App Pool as NETWORK SERVICE with identity impersonation enabled )?

Perhaps the change I suggested to Shaow Folder's web.config may help, or you found something else interferring with the Directory Security on the Shadow Folder Virtual Director which was disabling the option to "Enable anonymous access".

I don't know your exact configuration, so its hard saying what else may be the problem. I did run across these possibilities. Do any of them help?

Is Basic Authentication enabled in any of the IIS folders? See "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials" error message if the Basic authentication Default Domain property is set to a backward slash character (\) in IIS - http://support.microsoft.com/kb/827991

One other possibility - "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials" error message when you try to access a Web site that is part of an IIS 6.0 application pool" - http://support.microsoft.com/?id=871179

Jakana · Post by **Jakana** » Thu Nov 18, 2004 4:48 pm

OK, after messing around with this most of the afternoon (and nearly pulling all my hair out) I finally got things working.

Without diving into the details on all the stuff that I did that didn't work, I was carefully re-reading the MSDN Library article that describes how to use a domain/local account for running .NET (http://msdn.microsoft.com/library/defau ... etHT01.asp). Note: This is the original source that was modified and used to create the SourceGear Vault FAQ Thread "Configuring Shadow Folders for UNC Paths". Anyway, this paragraph from the MSDN article caught my attention:

If you enable impersonation, your application accesses resources using the original caller's security context, or the anonymous Internet user account (by default IUSR_MACHINE), if IIS is configured for anonymous authentication. In this event, resources must have ACLs based on the original caller identity (or IUSR_MACHINE).

So, all this time I was focusing on the security settings and file permissions for the custom domain account I set up (DOMAIN\sgvault), but it turned out that the IUSER_MACHINE account was the one that needed to be granted resource access.

To quickly test this theory without diving into setting permissions on the various folders for the IUSR_MACHINE account, I modified the "Directory Security" settings in IIS 6 for the Vault virtual directories to use the new domain account I setup for anonymous access, and not IUSR_MACHINE. Once I made this change, everything started working.

I'm debating whether or not to leave the DOMAIN\sgvault account as the user used for anonymous access to the two Vault virtual directories, but I would like to know what specific security settings and/or file permissions are required by the IUSR_MACHINE account vs. the DOMAIN\sgvault user under the identity impersonation scenario. I'm also worried that using the DOMAIN\sgvault account for anonymous access to the Vault services, with the permissions I've granted to get things working, will pose a security risk. At the very least I'm going to scale back the permissions on that account to the minimun needed for things to work.

BTW, I moved both Vault virtual directories back into the DefaultAppPool which is using the "NETWORK SERVICE" Identity, and everything is still working fine. I can also successfully use UNC network paths for Shadow Folders now -- so I guess I'm all set. Now I just need to tune security/permissions for DOMAIN\sgvault (and possibly IUSR_MACHINE if I go back to using it for anonymous access) to keep things working without creating any unnecessary security risks.

Thanks for hangin' in there with me jclausius!

Post by **jclausius** » Thu Nov 18, 2004 4:59 pm

No problem.

So, adding IUSR_MACHINE to the NTFS settings solved your problem? Its weird that our test environment didn't encounter that problem.

One thing to ask, did your DOMAIN\user account belong to any groups? I believe by default we added the DOMAIN\user account to the Domain Users group. I also believe the NTFS settings contained permissions for that group.

I'll check things out, and make any necessary adjustments to the FAQ. Thanks for the feedback.

Jeff

Guest · Post by **Guest** » Fri Nov 19, 2004 7:59 am

To answer your question, my DOMAIN\sgvault account is a member of the "Domain Users" group. I setup the account as a member of this group originally (it says to do so in the FAQ as well). While troubleshooting, I tried adding DOMAIN\sgvault to other groups, including Administrators. However, in the end I removed all groups except the Domain Users group, and everything is still working fine.

I didn't actually add IUSR_MACHINE to the same NTFS settings as the DOMAIN account -- I changed the account used by IIS for anonymous access to use DOMAIN\sgvault instead of IUSR_MACHINE (inside the IIS virtual directory settings > "Directory Security" > Edit Authentication and Access Control > modified username/password used for anonymous access). I only changed this setting for the Vault virtual directories -- not globally inside IIS. Technically, it accomplished the same thing as changing the IUSR_MACHINE account NTFS permissions, except that the DOMAIN\sgvault probably has too many security permissions and shouldn't be used in this way.

What I haven't done yet, and plan on doing at some point, it looking at the specific differences in the IUSR_MACHINE and DOMAIN\sgvault accounts - both NTFS permissions on the relevant folders *and* the security rights of IUSR_MACHINE to "log in as service", etc. (which were granted to DOMAIN\sgvault per the FAQ). I want to understand whether the HTTP 401 errors were due to NTFS permissions (and if so, specifically which folders/rights), and/or if the 401 errors were happening due to the security settings of IUSR_MACHINE (not able to log in as service, etc). Once I go through that exercise, I'll post back what I find out.

Post by **jclausius** » Fri Nov 19, 2004 9:09 am

Great. We'll compare that against one of our configurations here, and see how they match up.

Thanks again.

slafave · Post by **slafave** » Mon Nov 29, 2004 10:08 am

Was this ever resolved? I am receiveing the exact same errors trying to get shadow folder service to work. I have followed the KB articles you have on setting up the service in Windows 2003, but still throws the exact errors described in this thread. I do not want to enable the anonymous access as described in the thread if follow up was not done by anyone to see if this opened up a security hole.

Thx!