Приложение ASP.NET для аутентификации к Active Directory или SQL через аутентификацию Windows или Аутентификацию Форм
просто возьмите этот пример и измените loadBalancingRules, чтобы использовать 8080 вместо 80. Таким образом, вы будете использовать один порт для всех vms. Вам также необходимо изменить порт пробника.
Правила NAT (которые вы смотрите) - это нечто иное. Вы не можете балансировать нагрузку по нат правилам, поэтому разные порты используются для разных vms.
3 ответа
Это - способ, которым я обработал аналогичную ситуацию на основе этой информации:
- Настроенный приложение для использования аутентификации Форм.
- Установите LoginUrl на страницу по имени WinLogin.aspx.
- В WinLogin.aspx используйте Запрос. ServerVariables["LOGON_USER"] для получения имени пользователя затем называет FormsAuthentication. RedirectFromLoginPage (authorizedUserName, ложь) для входа их в. Я предполагаю, что можно вручную проверить Active Directory как эту точку также.
- Создайте страницу HTML, которая перенаправляет к странице по имени Login.aspx
- Login.aspx является Вашим стандартным входом в систему имени пользователя/пароля.
- В IIS Включите Интегрированную Аутентификацию и Анонимный на всем сайте, но запретите анонимного доступа к WinLogin.aspx.
- В IIS, устанавливает Ваша 401 ошибка на страницу, созданную на шаге 3.
То, что в основном происходит, - то, что, когда unauthenicated пользователь поражает сайт, они перенаправляются к WinLogin.aspx. С тех пор анонимный выключен, интегрированная защита осуществляет проверку. Если это передает, Ваш пользовательский код в WinLogin может работать. Если проверка интегрированной защиты перестала работать, 401 ошибка происходит. Ваша пользовательская 401 страница перенаправляет к Login.aspx, где пользователь может войти в систему с помощью их имени пользователя и пароля с поставщиком SQL.
Насколько я знаю, веб-приложения настроены для использования или аутентификации Windows или Аутентификации Форм, но не обоих. Поэтому я не полагаю, что возможно автоматически аутентифицировать внутренних пользователей, требуя, чтобы другие ввели имя пользователя / пароль.
Вы могли пройти проверку подлинности к Active Directory или пользовательскому хранилищу SQL через аутентификацию Форм при помощи пользовательского поставщика. Однако AD пользователи должны были бы все еще ввести свое имя пользователя и пароль. Хотя я никогда не комбинировал эти два метода, я использовал аутентификацию Форм для аутентификации против обоих источников в какой-то момент.
После этих слов я думаю, что можно хотеть рассмотреть сокращение "гибкости" системы. Если у Вас есть внешний сервер направления и внутренний сервер направления, Вы могли бы просто изменить конфигурацию поставщика на каждой копии приложения для хождения вразрез с другим источником. Затем Вы могли настроить внутренний для использования Windows (автоматическая) аутентификация и внешняя для использования аутентификации Форм.
По моему скромному мнению, я полагаю, что внутренние пользователи не должны использовать внешний сервер для доступа к приложению. Если они, им нужно сохранить учетную запись пользователя в SQL, полностью разделенном от их AD учетной записи. В основном, когда кто-то получает доступ к приложению внешне, они действуют как внешний пользователь, независимо от их физическое местоположение.
Ну, возможно использовать ActiveDirectoryMembershipProvider и SqlMembershipProvider, но это требует, чтобы Вы разработали свою страницу входа в систему с Вашим собственным кодом вместо Управления входом в систему.
Об аутентификации соединения (Windows и Формы), насколько я знаю только, помогает IIS 7, и убрать. См. это сообщение для получения дополнительной информации