Я работаю над старым веб-приложением, которое изначально не создавало, но сейчас поддерживаю. Это классическое приложение ASP со смешанными ASPX-страницами.
Сайт настроен для аутентификации и делегирования Kerberos, и он корректно работает с другими блоками (например, я могу выполнить SQL-запрос к внутреннему серверу со страницы ASP на сайте, и он подключается с помощью внешнего интерфейса учетные данные клиента правильно). Таким образом, имена SPN регистрируются, права делегирования настраиваются в AD и т. Д.
Теперь часть, с которой у меня возникают проблемы, - это страница ASPX, которая вызывает удаленный WMI-вызов для проверки состояния веб-сайта IIS с использованием пространства имен \ root \ WebAdministration WMI. Страница ASPX сама вызывается посредством XHR, который находится в клиентском коде другой страницы ASP. При вызове ASPX выполняет вызов WMI, а затем Response.Write возвращает необходимые данные, которые исходная страница ASP затем использует для заполнения страницы, которую видит пользователь. Проблема в том, что я не могу получить окно IIS для правильного делегирования учетных данных пользователя на сервер, с которым он вызывает WMI.
Это все работает правильно (включая ограниченное делегирование), но только если я включаю переход по протоколу. Если я установил делегирование в боксе среднего уровня (IIS) для использования только аутентификации Kerberos, оно завершится неудачно (я получаю анонимную попытку входа в систему во внутреннем блоке).
Теперь я сделал множество захватов пакетов как на клиентском компьютере, так и на окне IIS, чтобы точно увидеть, что здесь происходит, и я вижу несколько вещей:
- Внешний клиент правильно получает свой билет Kerberos и представляет его в поле IIS для проверки подлинности.
- Окно IIS принимает билет Kerberos от клиента.
- Однако поле IIS не , использующее билет, полученный от клиента, в качестве «билета доказательства», который он должен представить KDC, чтобы получить билет службы для доступа к серверной части. сервис от имени интерфейсного пользователя. Вместо этого в окне IIS используется вызов S4U2Self для KDC, чтобы получить для себя билет от имени пользователя переднего плана, а затем использовать этот билет в последующем вызове S4U2Proxy, чтобы попытаться получить билет для серверной части. , Вот в чем проблема.
- Вышеуказанное поведение объясняет, почему это работает, когда включен переход по протоколу, и не работает, когда это не так.
Я не могу сообразить себе всю жизнь, почему в окне IIS ощущается необходимость приобрести для себя TGS, чтобы использовать его в качестве «билета доказательств» для получения билета для доступа к серверной части, вместо простого использования билет, представленный клиентом. Из того, что я могу сказать, нет ничего недопустимого в билете клиента, и клиент прекрасно устанавливает соединение с веб-сервером, прошедшее проверку подлинности Kerberos, поэтому здесь не нужно переключать протокол. Я мог бы включить его, если это действительно необходимо, но я просто хочу знать, почему это необходимо (если есть веская причина, и это по замыслу, так тому и быть).
Пул приложений IIS работает как идентификатор встроенного пула приложений, и, таким образом, параметры делегирования настраиваются для учетной записи компьютера IIS в AD. SPN регистрируются для сайта под учетной записью компьютера IIS, а для фоновых служб - для этих учетных записей службы и / или компьютера, а список «позволенный_телегисто» настраивается для учетной записи компьютера IIS, что позволяет ограниченное делегирование необходимым службам. Конкретное имя участника-службы, которому мы пытаемся делегировать кредиты в этом сценарии, - это RPCSS / [машина] для вызова WMI. С помощью перехвата пакета я проверил, что SPN в запросе совпадает с SPN в списке A2D2 точно (конечно, если это не так, то он не будет работать при включенном переключении протокола в любом случае).
Что касается фактического кода подключения WMI, я пробовал несколько способов. Один был что-то вроде этого:
ConnectionOptions co = new ConnectionOptions();
// I did try ImpersonationLevel set to both Impersonate and Delegate, but I don't think I need
// Delegate here because I'm not delegating from the remote WMI machine to a different box; instead,
// I'm delegating from the IIS box to the remote WMI machine.
co.Impersonation = ImpersonationLevel.Impersonate;
co.Authentication = AuthenticationLevel.PacketPrivacy;
co.EnablePrivileges = true;
// Tried this for the Authority line because I noticed in the packet captures that the principal
// specified here becomes the SPN that is used in the S4U2Proxy request.
co.Authority = "kerberos:RPCSS/machine.domain.com";
ManagementScope ms = new ManagementScope(@"\\machine.domain.com\root\WebAdministration", co);
Тогда я тоже попробовал это:
ConnectionOptions co = new ConnectionOptions();
co.Impersonation = ImpersonationLevel.Impersonate;
co.Authentication = AuthenticationLevel.PacketPrivacy;
co.EnablePrivileges = true;
// I also tried this for the Authority line based on various other code examples for similar
// issues, but this resulted in an incorrect SPN being used in the request.
co.Authority = @"kerberos:DOMAIN\machine";
ManagementScope ms = new ManagementScope(@"\\machine.domain.com\root\WebAdministration", co);
Я также попробовал то же самое, что и выше, но без строки авторизации, и в запросе использовался правильный SPN, но он все еще не работал.
Наконец, я тоже попробовал это, вообще без объекта ConnectionOptions, надеясь, что он просто передаст кредиты по умолчанию:
ManagementScope ms = new ManagementScope(@"\\machine.domain.com\root\WebAdministration");
Буду очень признателен за помощь в том, как я могу заставить это работать без включения перехода по протоколу, или информацию о том, почему эта настройка потребует перехода по протоколу, будет очень признателен!