Микширование форм с помощью проверки подлинности Windows

У меня есть (ASP.NET 3.5) приложение интрасети, которое было разработано для использования проверки подлинности форм (наряду с системой членства aspnet по умолчанию). Я также храню дополнительную информацию о пользователях в другой таблице, которая делится своим основным ключом с таблицей aspnet_users.

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

Я прочитал руководства, которые доступны - все они два года назад или более, и предположим, что вы можете активировать проверку подлинности Windows на отдельной странице входа, которая позволяет вам извлекать имя учетной записи домена. Из того, что я могу сказать, это невозможно в IIS7 (общий метод проверки подлинности применяется ко всем страницам и не может быть выборочно деактивирован, и оба метода проверки подлинности не могут применяться на одной странице).

Есть ли способ заставить IIS пройти через имя учетной записи домена Windows запрашивающего пользователя? Мне не нужна правильная аутентификация AD, просто имя домена.

Ответ 1

Собственно, вы можете это сделать. Бит опоздал на @dr_draik, но это произошло из-за результата Google для меня, поэтому я решил поделиться знаниями.

Если вы находитесь в классическом режиме - активируйте как Windows, так и Forms auth. Вы получите предупреждение о невозможности выполнить оба действия одновременно, но вы можете игнорировать его. Затем вы можете создавать различные свойства, такие как Код:

HttpContext.Current.Request.ServerVariables["LOGON_USER"]

и сложите имя пользователя оттуда.

Если вы находитесь в интегрированном режиме - 4021905 IIS7 Аутентификация на основе переадресации на основе входа и входа не может использоваться одновременно, приводит к IIS 7.0 Двухуровневая аутентификация с аутентификацией форм и аутентификацией Windows, которая является модулем, позволяющим выборочно изменять auth для разных страниц.

Ответ 2

Вы всегда можете настроить 2 отдельных приложения в IIS7. Можно было бы включить проверку подлинности Windows. Другое будет основным приложением с проверкой подлинности форм. Если пользователь отправился в приложение проверки подлинности Windows, страница могла бы получить свои учетные данные и передать его в приложение проверки подлинности форм.

Ответ 3

_{(Больше для полноты информации)}

Я спросил у него вопрос о безопасности .Net на конференции некоторое время назад. Его реакция заключалась в том, что это технически возможно, но он никогда не видел этого (и сообщить ему, если я сделал это, и это сработало!).

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

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

Ответ 4

Есть много статей о смешивании аутентификации, устанавливая config для использования форм, позволяющих анонимный доступ к приложению. Во-вторых, необходимо создать страницу для интегрированного auth с настройками IIS, чтобы запретить анонимность и использовать функцию Intgrated Authentication. Там вы можете сделать волшебный трюк, проверив переменную "Logon_User" коллекции наборов запросов ServerVariables. И, наконец, для интегрированной аутентификации, чтобы тихо войти в пользователь, у нее должно быть короткое имя. Поэтому, если ваш экземпляр аутентификации в формах открыт для доступа в Интернет через FQDN, должно быть какое-то перенаправление на короткую страницу хоста. Я думаю, что можно достичь только одним приложением в IIS с двумя виртуальными каталогами.

Ответ 5

Это может быть потенциальным решением для вашей проблемы: http://msdn.microsoft.com/en-us/library/ms972958.aspx

Ответ 6

У меня есть кое-что, что вы можете попробовать - не уверен, что это сработает.

В прошлом мы использовали Request.ServerVariables [ "LOGON_USER" ], но для этого, чтобы вернуть непустое значение, вам необходимо отключить анонимный доступ.

Смотрите эту статью: http://support.microsoft.com/default.aspx/kb/306359

Это предполагает сохранение анонимного доступа на стороне IIS и проверку подлинности форм, но отказ анонимного пользователя в следующем:

<authorization> <deny users = "?" />  <allow users ="*" />  </authorization>

Не уверен, что это сработает, но стоит попробовать.

-Krip

Ответ 7

К сожалению, то, что вы пытаетесь сделать, не поддерживается. Чтобы ASP.NET знал имя пользователя Windows, вы должны использовать проверку подлинности Windows.

Вы можете настроить другой сайт/виртуальный каталог, который просто перенаправил данные имени пользователя на другую страницу. Но что произойдет, если пользователи, не прошедшие проверку подлинности Windows, попытаются войти?

Ответ 8

Я нашел решение без специальных надстроек. Это было сложно, и они задействовали элементы из всех страниц, упомянутых здесь. Я опубликовал об этом: http://low-bandwidth.blogspot.com.au/2014/11/iis7-mixed-windows-and-forms.html

В сущности, должны быть включены формы, окна и анонимная аутентификация. Экран входа должен быть основан на форме и содержать кнопку для запуска входа в систему Windows, которая выдает запрос ответа HTTP 401, который при успешном создании формы входа на основе формы.

Проблемы довольно сложны, и почта подробно рассматривает принципы и решение.