3

I've setup a 2 node NLB cluster and used the following to share IIS configs between them.

http://blogs.technet.com/b/meamcs/archive/2012/05/30/configuring-iis-7-5-shared-configuration.aspx

The IIS configs and content is located on a network share via a UNC path. This works - updating IIS settings on one node, is visible in another node and my website works on the individual nodes and the cluster as whole.

I'm able to setup an FTP site and successfully connect with my Windows login. However, I want to use IIS Manager Authentication as defined in:

http://www.iis.net/learn/publish/using-the-ftp-service/configure-ftp-with-iis-manager-authentication-in-iis-7

I've tried using "Network Service" with the FTP COM object as well as a dedicated user account that exists on all three hosts, but every time I try to login with an IIS user I get something like the following:

IISWMSVC_AUTHENTICATION_UNABLE_TO_READ_CONFIG

An unexpected error occurred while retrieving the authentication information.

Exception:System.Runtime.InteropServices.COMException (0x8007052E): Filename: Error:

at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath) at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath) at Microsoft.Web.Management.Server.ConfigurationAuthenticationProvider.GetSection(ServerManager serverManager)

Process:dllhost User=NT AUTHORITY\NETWORK SERVICE

Can anyone point me in the right direction here?

William Jens
  • 191
  • 8
  • You're absolutely sure you've given permissions to c:\windows\system32\inetsrv\config\* to the appropriate user? If so, try using ProcMon to see exactly what's happening. Does it work with the shared config turned off? – phoebus Oct 28 '13 at 21:56

1 Answers1

3

We've been battling this EXACT SAME issue for over the last week and have found a workaround.

It seems that the custom IISManager Authentication Provider has some additional (undocumented) permission requirements when IIS is in Shared Configuration mode (it works fine with local config).

Event Log: Application

Type: Error

Source: Microsoft-Windows-IIS-IISManager

Category:

Event: 1106

Message:

IISWMSVC_AUTHENTICATION_UNABLE_TO_READ_CONFIG

An unexpected error occurred while retrieving the authentication information.

Exception:System.Runtime.InteropServices.COMException (0x8007052E): Filename: Error:

at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath) at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath) at Microsoft.Web.Management.Server.ConfigurationAuthenticationProvider.GetSection(ServerManager serverManager)

Process:dllhost Process:dllhost User=NT AUTHORITY\NETWORK SERVICE

I can confirm that we receive this EVEN AFTER we applied 'Network Service' permissions all over the place (i.e. the following commands that have been referred to already):

ICACLS "%SystemDrive%\Windows\System32\inetsrv\config" /Grant "Network Service":R /T
ICACLS "%SystemDrive%\Windows\System32\inetsrv\config\administration.config" /Grant "Network Service":R
ICACLS "%SystemDrive%\Windows\System32\inetsrv\config\redirection.config" /Grant "Network Service":R

In addition to the above folders, we added the 'Network Service' account [Full Permissions] to:

  1. the shared configuration folder (and files below).
  2. the target FTP folder itself.

None of the above affects the issue.

The problem is that this error message is different to the normal one, as in this case the details for 'Filename:' and 'Error:' are both blank (usually the xxx.config filename is listed if the permissions are missing). So this is something else...

We also ran Process Monitor and couldn't see any Access Denied messages in there either. My thought is this is possibly a cached error from when the IIS User Management process first starts and tries (and fails) to read the config. We've noticed some odd caching behaviour when we have found ways to make it work (see below).

The breakthrough came when we Changed the FTP Extensibility Process Identity to '{Domain}\Administrator', and after rebooting the machine it worked!

Note: IISReset doesn't work - which is what leads me to believe that there are a few things being (resiliently) cached here.

As a further test we:

  1. created a new plain domain user account (called '{Domain}\FTPService').
  2. switched the FTP Process Identity to this new account.
  3. applied the appropriate permissions to the config folders.
  4. Rebooted.

We then get the same error message again (with the blank username / error).

Finally, when we made the new 'FTPService' user a member of 'Domain Admins' and rebooted (again, some caching preventing the immediate fix) it works.

We have also tried this in Windows 2008 / IIS7 (with the FTP7.5 addon), Windows 2008 R2 / IIS 7.5, Windows 2012 / IIS8 and Windows 2012 R2 / IIS8.5 and it is the same problem (and resolution) in each.

So it seems that there is some bug or 'undocumented' permission that is required to make this work with Shared Configuration and the Network Service account (without giving the FTP Extensibility Process Administrative rights) that's been there since the advent of FTP 7.5.

Although this is a workaround, it would be great to find out what extra permissions are required to make this work with Network Service or a non Domain Admin user account.

  • BTW. we also tried **[ETW Trace Logs](http://blogs.iis.net/robert_mcmurray/archive/2012/08/28/troubleshooting-custom-ftp-providers-with-etw.aspx)**, and all we could see was a **FailCallProvider** entry with the *error code*: **'0x8007052E'** and *description*: **'Filename: Error:'**. However, LogParser 2.2 didn't want to work on Server 2012 R2, so we had to use **[Tracerpt](http://technet.microsoft.com/en-us/library/cc732700%28WS.10%29.aspx)** to read the logs, with the **-o -lr** switches, and I'm not 100% confident it supplied all the info. – Simon Gregory Dec 11 '13 at 16:52