Итак, здесь я снова имею дело, вероятно, с вопросом номер один о поддержке IIS, SPN. Я не новичок, когда дело доходит до этого, поскольку за последние несколько лет я испытал на себе все трудности, связанные с получением внешних интерфейсов SSRS для делегирования для серверных компонентов SQL и SSAS в различных средах.
Но теперь Microsoft повысила ставку, представив обновленный интерфейс IIS7 и Windows 2008 с режимом ядра, и я тут же вернулся к работе и бьюсь головой о стол.
В прошлом я успешно использовал инструмент DelegConfig Брайана Бута, чтобы быстро разобраться в проблемах, но в моем текущем случае я получаю результаты, которым я не уверен, которым я доверяю, и сомневаюсь в том, что инструмент точно отображает проблемы или просто зря трачу время на несуществующие проблемы.
Так что, может быть, пришло время получить второе (третье и четвертое) мнение.
На высоком уровне у меня есть веб-сервер, который будет запускать приложения, которые должны действовать как делегаты для доступа к внутренним экземплярам SQL и SSAS. На первый взгляд звучит достаточно просто.
Хорошая новость в том, что серверные инстансы уже настроены и работают. Это именованные экземпляры, работающие на учетных записях служб домена, с соответствующими именами участников-служб уже на месте.
Внешний вид сервера выглядит так:
Операционная система: Windows Server 2008 R2 Enterprise IIS: 7.5.7600.16385
Учетная запись машины
Использование заголовков хоста
Пул приложений
На веб-сайте [CONET] размещено ~ 50 «приложений» и ~ 20 «виртуальных каталогов». Для этого упражнения есть одно (1) интересное приложение, назовем его «MyApplication». Приложение DelegConfig пока также живет на этом веб-сайте.
На верхнем уровне [CONET] включены «Анонимная аутентификация» и «Аутентификация Windows {kernelModeAuthentication = true}».
На уровне MyApplication включена проверка подлинности Windows {kernelModeAuthentication = true}. То же самое и с DelegConfig.
Насколько я понимаю, для учетной записи компьютера домена сервера [CO \ COLOVWEB $] требуется следующее:
ServicePrincipalName:
msDS-AllowedToDelegateTo:
Насколько я понимаю, следующее, хотя и не требуется в данном случае, также уместно:
ServicePrincipalName:
И все должно работать, да?
Что ж, это не так. В зависимости от точного синтаксиса, который я использую для имени хоста внешнего интерфейса, DelegConfig жалуется на:
The domain or workstation membership of NETWORK SERVICE (http://conet$) could not be determined.
ИЛИ
Service account NETWORK SERVICE (COLOVWEB$) is not a domain account.
Я знаю, что борюсь с проблемой делегирования Kerberos, но не уверен, помогает ли DelegConfig или мешает. Ответы на любой оцененный.
РЕДАКТИРОВАТЬ - 20130403
Приложение ConnectString было проверено и показано ниже:
Data Source=colosql3\MyInstance;Catalog=OurCatalog;Integrated Security=SSPI;SSPI=negotiate;Impersonation Level=Delegate;SspropInitAppName=MyApplication
Имя входа, попадающее на сервер OLAP, все еще CO \ COLOVWEB $, а не учетная запись пользователя.
Я запускаю elmah на сервере в корневом вебе, чтобы получить хороший снимок сеанса пользователя:
AUTH_TYPE negotiate
AUTH_USER CO\user
HTTP_AUTHORIZATION Negotiate YIIKMwYGKwYBBQ....
Итак, клиентский браузер явно отправляет соответствующий запрос.
Наконец, это оказалось проблемой с приложением. Устаревшие приложения ASP по умолчанию будут использовать олицетворение. Однако ASP.NET по умолчанию отключает олицетворение. Недостаточно установить олицетворение в источнике данных ASP.NET, также необходимо, чтобы разработчик явно включил олицетворение. Это можно сделать через web.config
<identity impersonate="true" />
хотя им можно управлять на нескольких различных уровнях внутри сайта, поэтому разработчикам важно оценить требования безопасности и внести изменения в соответствующем месте.
Например, когда олицетворение было включено на уровне сайта, SSAS-соединение начало работать ... и почти все остальное сломалось, потому что большинство других вещей было написано так, чтобы не использовать олицетворение, поэтому вы можете легко закончить конкуренцию в вашей модели безопасности ... и это не помогло Microsoft продвинуть IE9 накануне вечером, что сломало кучу вещей, которые, очевидно, были связаны с этим изменением, пока кто-то не понял это.