Получение учетных данных windows / domain в asp.net при разрешении анонимного доступа в IIS

Question

В нашем центре обработки данных запущено веб-приложение asp.NET, в которое мы хотим, чтобы клиент входил в систему с помощью единого входа. Это было бы очень легко, если бы мы могли использовать интегрированную безопасность IIS. Однако мы не можем этого сделать. У нас нет доверия к контроллеру домена заказчика. И мы хотим, чтобы сайт был доступен для общего интернета. Только когда люди подключаются из клиентской сети, они должны автоматически войти в систему.

У нас есть список учетных записей домена и способ запроса DC через LDAP в коде asp.net. Когда в IIS разрешен анонимный доступ, IIS никогда не запрашивает учетные данные в браузере. И поэтому наше приложение никогда не получает учетные данные пользователей.

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

Обновление:

Я попытался отправить 401: неавторизованный, www-authenticate: NTLM заголовки самостоятельно. Далее, как говорит мне Фидлер, IIS получает полный контроль и обрабатывает всю цепочку запросов. Как я понимаю из различных источников, IIS берет имя пользователя и отправляет запрос обратно в браузер. Браузер возвращается с зашифрованным ответом, и IIS подключается к контроллеру домена для аутентификации пользователя с помощью этого ответа.

Однако в моем сценарии IIS находится в другом домене Windows, чем клиенты, и не имеет возможности аутентифицировать пользователей. По этой причине создание отдельного сайта с включенной аутентификацией Windows также не будет работать.

На данный момент у меня есть варианты, которые я изучаю:

1. Создание доверительного отношения между нашим хостинговым доменом и клиентским доменом (наш ИТ-отдел этим не очень доволен)
2. Использование прокси-сервера NTML для пересылки запросов проверки подлинности IIS на контроллер домена клиентов (у нас есть доступное VPN-подключение для подключения через LDAP)

Answer 1

То, что вы просите, называется аутентификацией в смешанном режиме. Недавно я использовал механизм с двумя точками входа от Paul Glavich , и он отлично работает. Я думаю, это самое элегантное решение этой проблемы.

Answer 2

Это решение касается проверки подлинности на основе форм, но в нем подробно описывается проблема 401.

Решение было просто прикрепить обработчик приложений Событие EndRequest, поставив следующие в Global.asax:

protected void Application_EndRequest(object sender, EventArgs e) {
    if (Context.Items["Send401"] != null)
    {
         Response.StatusCode = 401;
         Response.StatusDescription = "Unauthorized";
    } }

Затем, чтобы вызвать этот код, все что вам нужно сделать, это поставить

Context.Items["Send401"] = true;

Edit:
Я использовал этот метод с включенным Anonymous и Integrated, чтобы получить учетные данные домена пользователя. Я не уверен, сработает ли это в вашей ситуации, но я подумал, что стоил того.

Answer 3

Не уверен, что вы легко сможете заставить это работать. В отличие от базового, когда вызов 401 происходит внутри полосы запроса пользователя - например, в заголовках появляются титры, рукопожатия NTLM выполняются на отдельном порте - затем принудительно вводятся в контекст потока неуправляемым кодом.

Вы пытались отделить модуль ASP.NET NTLM в VS2008 (или отражатель), чтобы посмотреть, что он делает для получения кредитов?

Не совсем ответ - извините ...