Как настроить FTP с пользователями диспетчера IIS в среде NLB с общими конфигурациями IIS?

Я установил двухузловой NLB-кластер и использовал следующее для обмена конфигурациями IIS между ними.

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

Конфигурации и контент IIS находятся в общей сетевой папке по пути UNC. Это работает - обновление настроек IIS на одном узле отображается на другом узле, а мой веб-сайт работает на отдельных узлах и кластере в целом.

Я могу настроить FTP-сайт и успешно подключиться, используя мой логин Windows. Однако я хочу использовать проверку подлинности диспетчера IIS, как определено в:

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

Я пробовал использовать «Сетевую службу» с COM-объектом FTP, а также с выделенной учетной записью пользователя, которая существует на всех трех хостах, но каждый раз, когда я пытаюсь войти в систему с пользователем IIS, я получаю что-то вроде следующего:

IISWMSVC_AUTHENTICATION_UNABLE_TO_READ_CONFIG

При получении информации для аутентификации произошла непредвиденная ошибка.

Исключение: System.Runtime.InteropServices.COMException (0x8007052E): имя файла: ошибка:

в Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection (String bstrSectionName, String bstrSectionPath) в Microsoft.Web.Administration.Configuration.GetSectionInternal (раздел ConfigurationSection, String sectionPath, String locationeruthentiguration .Configuration.Management GetSection (ServerManager serverManager)

Процесс: dllhost User = NT AUTHORITY \ NETWORK SERVICE

Может ли кто-нибудь указать мне здесь правильное направление?

Мы боролись с этой ТОЧНОЙ проблемой в течение прошлой недели и нашли обходной путь.

Кажется, что пользовательский провайдер аутентификации IISManager имеет некоторые дополнительные (недокументированные) требования к разрешениям, когда IIS находится в режиме общей конфигурации (он отлично работает с локальной конфигурацией).

Журнал событий: приложение

Тип: Ошибка

Источник: Microsoft-Windows-IIS-IISManager

Категория:

Событие: 1106

Сообщение:

IISWMSVC_AUTHENTICATION_UNABLE_TO_READ_CONFIG

При получении информации для аутентификации произошла непредвиденная ошибка.

Исключение: System.Runtime.InteropServices.COMException (0x8007052E): имя файла: ошибка:

в Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection (String bstrSectionName, String bstrSectionPath) в Microsoft.Web.Administration.Configuration.GetSectionInternal (раздел ConfigurationSection, String sectionPath, String locationeruthentiguration. GetSection (ServerManager serverManager)

Процесс: dllhost Процесс: dllhost Пользователь = NT AUTHORITY \ NETWORK SERVICE

Я могу подтвердить, что мы получить это ДАЖЕ ПОСЛЕ мы повсеместно применяли разрешения «Сетевой сервис» (т.е. следующие команды, которые уже упоминались):

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

В дополнение к указанным выше папкам мы добавили учетную запись «Сетевая служба» [Полные разрешения] для:

общая папка конфигурации (и файлы ниже).
сама целевая папка FTP.

Ничего из вышеперечисленного не влияет на проблему.

Проблема в том, что это сообщение об ошибке отличается от нормальный один, как в этом случае детали для "Имя файла:" и "Ошибка:" оба пустые (обычно xxx.config имя файла указано, если разрешения отсутствуют). Так это что-то еще ...

Мы также запустили Process Monitor и не увидели никаких сообщений об отказе в доступе. Я думаю, что это, возможно, кешированная ошибка, связанная с первым запуском процесса управления пользователями IIS, который пытается (и не может) прочитать конфигурацию. Мы заметили странное поведение кэширования, когда нашли способы заставить его работать (увидеть ниже).

Прорыв произошел, когда мы Изменен идентификатор процесса расширения FTP к '{Домен} \ Администратор', и после перезагрузки машина заработала!

Примечание: IISReset не работает - поэтому я полагаю, что здесь (устойчиво) кэшируются некоторые вещи.

В качестве дальнейшего теста мы:

создал новую учетную запись пользователя обычного домена (названную '{Домен} \ FTPService').
переключил удостоверение процесса FTP на эту новую учетную запись.
применил соответствующие разрешения к папкам конфигурации.
Перезагрузился.

Затем мы снова получаем то же сообщение об ошибке (с пустым именем пользователя / ошибкой).

Наконец, когда мы сделали нового пользователя «FTPService» членом «Администраторы домена» и перезагрузили (опять же, некоторое кеширование препятствует немедленному исправлению) оно работает.

Мы также пробовали это в Windows 2008 / IIS7 (с надстройкой FTP7.5), Windows 2008 R2 / IIS 7.5, Windows 2012 / IIS8 и Windows 2012 R2 / IIS8.5, и это одна и та же проблема (и решение) в каждом .

Таким образом, похоже, что для работы с общей конфигурацией и учетной записью сетевой службы требуется некоторая ошибка или «недокументированное» разрешение (без предоставления прав администратора процесса расширения FTP), которое существует с момента появления FTP 7.5.

Хотя это обходной путь, было бы здорово узнать, какие дополнительные разрешения требуются для работы с сетевой службой или учетной записью пользователя, не являющегося администратором домена.