Вот сценарий, который мы переживаем, и почему мы пытаемся его решить:
Мы - консалтинговая компания, которая поддерживает конкретное стороннее программное обеспечение для ряда клиентов. Приложение написано на ASP.NET и работает на IIS и SQL Server. В этом примере организация ABC размещает приложение на серверах в своем домене. Это приложение в значительной степени расширяемо и настраивается, поэтому каждый из наших клиентов часто имеет репозиторий настроек, и у них может быть один или несколько поставщиков, которые поддерживают эти настройки.
Если организация просит нас или другого поставщика изменить существующую настройку, обычно требуется установка локального экземпляра приложения на наших машинах, чтобы сделать разработку более эффективной (особенно отладку). Обычно мы стараемся избегать размещения локальной копии их базы данных, и вместо этого мы подключаемся к VPN организации с наших локальных компьютеров, чтобы наш локальный экземпляр IIS мог подключиться к их SQL-серверу разработки в их сети, а затем мы настраиваем набор SQL учетные данные для строк подключения вместо использования стандартной встроенной безопасности.
Проблема в том, что некоторым организациям неудобно использовать учетные данные SQL для аутентификации даже на SQL-серверах разработки. Я понимаю, что есть веские основания для разрешения SQL-кредитов на SQL-сервере разработки, если этот сценарий нуждается в поддержке, но я пытаюсь выяснить, есть ли вообще какой-либо другой вариант. Собственные инженеры организации могут настроить свои локальные идентификаторы пула приложений IIS для использования учетных данных домена для доступа к серверам SQL с использованием встроенной безопасности. Однако внешние поставщики (например, мы) не присоединены к своим доменам, а домены не являются доверенными, поэтому я не могу использовать учетные данные домена, предоставленные организацией ABC, в качестве удостоверения пула приложений.
Кто-нибудь знает о возможном способе запуска приложения IIS на машине из домена XYZ с использованием встроенной безопасности для аутентификации на SQL-сервере, работающем в домене ABC, без доверия доменам или настройки делегирования Kerberos?
Я рассматривал возможность использования различных встроенных учетных записей в качестве идентификатора пула приложений и попытки предоставить им доступ на сервере SQL, но мы не хотим предоставлять доступ на сервере SQL для всех возможных комбинаций DOMAIN \ MachineName $ которые могут подключаться к нему от всех разных поставщиков. Может быть, если бы в имени пула приложений было соблюдено соглашение об именах и мы использовали ApplicationPoolIdentity, тогда мы могли бы предоставить доступ на SQL-сервере только одной «виртуальной» учетной записи? (Я не пробовал этого и планирую сделать это, когда позволит время).
Это невозможно без участия в их домене или, по крайней мере, без доверия.
Ваш сервер не понимает, что это за другой домен, и не имеет никаких учетных данных, которые позволяют вам пройти аутентификацию (или обнаружить) его домен. Windows обычно не позволяет запускать процесс от имени пользователя из центра (домена), которому он не доверяет, поэтому вы не можете установить удостоверение пула приложений, потому что рабочий процесс будет пытаться запускаться от имени этого пользователя.