Настройка сквозной авторизации internet explorer
Имеется корпоративный портал на sharepoint, к которому можно подключиться, используя встроенную проверку подлинности windows. Авторизация сквозная, т.е. логин и пароль вводить не требуется. На большинстве компьютеров эта схема работает. Т.е. пользователь открывает internet explorer 11, попадает на портал и может спокойно на нем работать.
Необходимые настройки для корректной работы авторизации раздаются групповыми политиками на пользовательские компьютеры. Сайт заведомо находится в интрасети, сквозная авторизация включена в ie и т.д.
Однако, есть компьютеры, на которых при входе на портал запрашивается логин и пароль. Причем введенные данные не принимаются, по-прежнему будет оставаться форма с просьбой ввода логина и пароля..
Итак, что было замечено:
1. Если зайти под другой учеткой на данном компьютере, то проблема сохраняется. При этом на другом компьютере под данной учетной записью авторизация работает нормально.
2. Сброс настроек ie и последующий gpupdate /force ни к чему не приводят.
3. Удаление антивируса ни к чему не приводит.
4. Делал sfc /scannow из режима восстановления, причем winsxs подсовывал из чистого образа. Результат: ошибок не обнаружено.
5. Через avz пробовал сбрасывать сетевые настройки, не помогло.
6. Полное удаление internet explorer, а также чистка папок C:\Windows\SoftwareDistribution\Download и C:\Windows\winsxs (winsxs через утилиту очистки диска разумеется) не помогает.
Что помогло:
1. В windows 8.1 можно загрузиться с флешки в режиме восстановления с сохранением пользовательских данных. После этой процедуры авторизация начинает работать. Но в windows 7 такой возможности нет.
2. Если зайти в безопасном режиме с поддержкой сетевых драйверов, то портал откроется без требования ввода пароля. И более того, после этого он начнет открываться в обычном режиме. Но открываться будет только под той учеткой, под которой открывали в безопасном режиме. Остальные учетки по-прежнему работать не будут. И самое печальное, что через какое-то время опять все ломается.
Прошу помочь разобраться. В компании ~200 компьютеров, проблема всплыла на 7-10.
22.01.2018
itpro
Active Directory, Разное
Комментариев пока нет
В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.
Чтобы браузер мог авторизоваться на веб-сервере, нужно, чтобы были выполнены следующие условия:
-
Поддержка Kerberos должны быть включена на стороне веб-сервера (пример настройки Kerberos авторизации на сайте IIS)
Настройка Kerberos аутентификации в Mozilla Firefox
По умолчанию поддержка Kerberos в Firefox отключена, чтобы включить ее, откройте окно конфигурации браузера (в адресной строке перейдите на адрес about:config). Затем в следующих параметрах укажите адреса веб-серверов, для которых должна использоваться Kerberos аутентификация.
- network.negotiate-auth.trusted-uris
- network.automatic-ntlm-auth.trusted-uris
Для удобства, можно отключить обязательное указание FQDN адреса в адресной строке Mozilla Firefox, включив параметр network.negotiate-auth.allow-non-fqdn
Проверить, что ваш браузер работает через аутентифицировался на сервере с помощью Kerberos можно с помощью Fiddler или команды klist tickets.
11.09.2019
itpro
Windows Server 2012 R2
комментария 22
Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.
На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).
Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.
Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.
Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).
Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.
Проверить настройки SPN у учетной записи можно так:
setspn /l iis_service
Совет. Kerberos не будет работать корректно при наличии дублирующих SPN у разных записей домена. С помощью следующей команды, убедитесь, что дубликатов SPN в домене нет: setspn –x
Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.
Выберите Application Pool сайта (в нашем примере это DefaultAppPool).
Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.
Измените его с ApplicationPoolIdentity на contoso\iis_service.
Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.
В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication
Измените useAppPoolCredentials на True.
Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.
Перезапустим IIS командой:
Аналогичную настройку нужно выполнить на всех серверах веб-фермы.
Примечание. В моем примере, на IE11 сразу авторизоваться не получилось. Пришлось добавить адрес в доверенные и в настройках Trusted Zones Sites выставить значение параметра User Authentication -> Logon на Automatic logon with current user name and password
Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.
На днях получили некоторые требования от одной из Web платформ по настройке IE для ее корректной работы. Требования не сложные, но важные для корректного отображения страниц:
— Включить Режим совместимости для портала (или для этого сайта);
— И добавить сайт в доверенные узлы.
Вроде и все требования.
Так как подразумевается, что с платформой будет работать много пользователей (от 250), решили прикрутить настройки через GPO, руками не особо улыбается это каждому.
Контроллеры домена развернуты Win2008R2, пользовательские станции Win8.1 с IE11.
На первый взгляд ничего сложного, открываем GPO
Далее Конфигурация пользователя
Добавляем нужные нам сайты
Все это сохраняем.
Теперь необходимо добавить этот же сайт в Надежные сайты IE
Ставим цифру 2 так как нас интересует зона надежных сайтов. Все сохраняем.
Далее gpupdate /force
И вроде бы все не плохо, но тут появляется «кулак дружбы», гадки включения в окне режима совместимости становятся не активными (это говорит нам, что политика не отрабатывает), а вот указанный сайт туда никак не добавляет, то есть окно просто пустое. В доверенных узлах сайт благополучно появляется. Еще более интересно, то что результирующая политика показывает, что вроде как сайт добавлен, но по факту на рабочих станциях его нет.
Три дня и три ночи скакал Иван Царевич, пока скакалку не отобрали (не добавляется сайт в список в режиме совместимости и все тут). Всем департаментом стали думать и гадать пробуя различные варианты.
Некоторая полезная информация по теме здесь:
но пока так и не нашли для себя рабочего решения. Есть версия, что это не работает только в IE11, но в нашем случае это не так, не работает и на более ранних версиях IE. Попросили коллег сделать все тоже самое на контроллерах, поднятых на Windows 2012 (думали может что не так у нас), но у них это тоже не заработало.
Если кто сталкивался с проблемой и уже ее решил, прошу написать в комментариях.
На днях поступила интересная мысль: Сделать сквозную авторизацию IE. Это необходимо для того, чтоб доменные пользователи не набирали пароли при входе на внутренние веб порталы, авторизуясь под своей доменной учеткой, под ней же сразу проваливаешься на портал.
Для того чтоб это работало необходимо следующее:
-В IE должна присутствовать галка: Разрешить встроенную проверку Windows (она стоит по умолчанию);
-Сайты должны быть добавлены в раздел Местная интрасеть, но если комп в домене, то по умолчанию все поля не активны.
Задача оказалась не такой простой, как казалось изначально.
Для не доменных машинок процесс достаточно прост:
Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:
Даже если бы и была возможность, то руками прописывать сайты никак не улыбается, поэтому, как обычно, делаем это через GPO:
Открываем редактор локальной (gpedit.msc) либо доменной (gpmc.msc) политики.
Переходим в раздел Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность.
Включаем политику Список назначений зоны безопасности для веб-сайтов. В настройках политики нужно указать список доверенных серверов в формате:
- Имя сервера (в виде file://server_name, \\server_name, server_name или IP)
- Номер зоны (1 – Для местной интрасети)
В моем случае правим отдельную политику IE Default (ранее она уже была создана для других манипуляций IE):
На компе gpupdate /force
Теперь в IE появляются следующие настройки:
Можно проверить ветку реестра:
HKEY_CURRENT_USER\Software\Microsoft\ Windows\CurrentVersion\ Internet Settings\ZoneMap\Domains.
Теперь авторизация проходит без пароля. Это радует. Но работает пока только в IE. В Chrome у меня не сработало, но потом все вроде подхватилось и под Chrome.
Но если все же не заработало, то можно прикрутить в GPO шаблон под Chrome:
Сейчас эти галки возможно убрать руками просто зайдя в настройки IE:
Чтоб такой возможности у пользователей не было, можно включить все три вот этих политики:
В остальном все, что необходимо, заработало без проблем.
P.S. VmWare по умолчанию, к сожалению, сквозную аутентификацию не отработала.
Настройка Kerberos аутентификации в Internet Explorer
Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.
Напомним, что с января 2016 года, единственная официально поддерживаемая версия Internet Explorer – это IE11.
Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:
Добавить сайты в эту зону можно с помощью групповой политики: Computer Configuration ->Administrative Templates ->Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment. Для каждого веб-сайта нужно добавить запись со значением 1. Пример смотри в статье об отключении предупреждения системы безопасности для загруженных из интернета файлов
Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).
Важно. Убедитесь, что веб сайты, для которых включена поддержка Kerberos аутентификации приустают только в зоне Местная интрасеть. Для сайтов, включенных в зону Надежные сайты (Trusted sites), токен Kerberos не отправляется на соответствующий веб-сервер.
Включаем Kerberos аутентификацию в Google Chrome
Чтобы SSO работала в Google Chrome, нужно настроить Internet Explorer вышеописанным способом (Chrome использует данные настройки IE). Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” --auth-server-whitelist="*.winitpro.ru" --auth-negotiate-delegate-whitelist="*.winitpro.ru"
Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLM\SOFTWARE\Policies\Google\Chrome).
Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).
Читайте также: