Разрешить встроенную проверку подлинности windows gpo

В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.

Чтобы браузер мог авторизоваться на веб-сервере, нужно, чтобы были выполнены следующие условия:

• Поддержка Kerberos должны быть включена на стороне веб-сервера (пример настройки Kerberos авторизации на сайте IIS)
• Наличие у пользователя прав доступа к серверу
• Пользователь должен быть аутентифицирован на своем компьютере в Active Directory с помощью Kerberos (должен иметь TGT — Kerberos Ticket Granting Ticket).

К примеру, мы хотим разрешить клиентам Kerberos авторизацию через браузер на всех веб серверах домена winitpro.ru (нужно использовать именно DNS или FQDN, а не IP адрес веб сервера)

Настройка Kerberos аутентификации в Internet Explorer

Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.

Напомним, что с января 2016 года, единственная официально поддерживаемая версия Internet Explorer – это IE 11.

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

• https://*.winitpro.ru
• http://*.winitpro.ru

Добавить сайты в эту зону можно с помощью групповой политики: 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, его нужно запустить с параметрами:

--auth-server-whitelist="*.winitpro.ru"
--auth-negotiate-delegate-whitelist="*.winitpro.ru"

Например,

"C:Program Files (x86)GoogleChromeApplicationchrome.exe” --auth-server-whitelist="*.winitpro.ru" --auth-negotiate-delegate-whitelist="*.winitpro.ru"

Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLMSOFTWAREPoliciesGoogleChrome).

Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).

Настройка 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.

На днях поступила интересная мысль: Сделать сквозную авторизацию IE. Это необходимо для того, чтоб доменные пользователи не набирали пароли при входе на внутренние веб порталы, авторизуясь под своей доменной учеткой, под ней же сразу проваливаешься на портал.

Для того чтоб это работало необходимо следующее:

-В IE должна присутствовать галка: Разрешить встроенную проверку Windows (она стоит по умолчанию);

-Сайты должны быть добавлены в раздел Местная интрасеть, но если комп в домене, то по умолчанию все поля не активны.

Задача оказалась не такой простой, как казалось изначально.

Для не доменных машинок процесс достаточно прост:

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

https://*.comp.loc

Даже если бы и была возможность, то руками прописывать сайты никак не улыбается, поэтому, как обычно, делаем это через 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_USERSoftwareMicrosoft WindowsCurrentVersion Internet SettingsZoneMapDomains.

http://192.168.10.15:8080/HomePage.do?SkipNV2Filter=true

Теперь авторизация проходит без пароля. Это радует. Но работает пока только в IE. В Chrome у меня не сработало, но потом все вроде подхватилось и под Chrome.

Но если все же не заработало, то можно прикрутить в GPO шаблон под Chrome:

http://winitpro.ru/index.php/2014/06/06/nastrojka-google-chrome-gruppovymi-politikami/

Сейчас эти галки возможно убрать руками просто зайдя в настройки IE:

Чтоб такой возможности у пользователей не было, можно включить все три вот этих политики:

В остальном все, что необходимо, заработало без проблем.

P.S. VmWare по умолчанию, к сожалению, сквозную аутентификацию не отработала.

Пришлось переставить плагин.

После его переустановки  все благополучно подхватилось.

Всем хорошей работы!!!

04.06.2019 —

Posted by |
scripts&GPO

В этом разделе объясняется, как настроить встроенную проверку
подлинности Windows для
Microsoft Office Outlook Web Access в
Microsoft Exchange Server 2007. Встроенная
проверка подлинности Windows позволяет серверу проверять
подлинность пользователей, подключающихся к сети без запроса имени
пользователя и пароля, а также без передачи незашифрованных
сведений по сети.

Примечание.

Встроенная проверка подлинности Windows может быт задана только для виртуальных каталогов Exchange 2007 на сервере Exchange 2007, на котором установлена только роль сервера клиентского доступа. Встроенная проверка подлинности Windows может быть задана для любого виртуального каталога Outlook Web Access на сервере Exchange 2007, на котором установлены роли сервера клиентского доступа и сервера почтовых ящиков.

Предварительная подготовка

Процедура

Дополнительные сведения

В чем разница между группами Everyone и Authenticated Users?

В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (ACL) представляет, в том числе встроенные в ОС Windows.

Существует множество встроенных учетных записей с малопонятными именами и неопределенными описаниями, что может привести к путанице в понимании разницы между ними. Очень частый вопрос: «В чем разница между группами Everyone и Authenticated Users?»

Самое важное

Группа Authenticated Users охватывает всех пользователей, вошедших в систему, используя учетную запись и пароль. Группа Everyone охватывает всех пользователей, вошедших в систему с учетной записью и паролем, а также встроенные, незащищённые паролем учетные записи, такие как Guest и LOCAL_SERVICE.

Если описанное выше показалась вам упрощённым, то дальше чуть больше деталей.

Группа Authenticated Users включает в себя всех пользователей, чья подлинность была подтверждена при входе в систему, в них входят как локальные учетные записи, так и учетные записи доверенных доменов.

Группа же Everyone включает всех членов группы Authenticated Users, а также гостевую учетную запись Guest и некоторые другие встроенные учетные записи, такие как likeSERVICE, LOCAL_SERVICE, NETWORK_SERVICE и др. Гостевая учётная запись Guest по умолчанию отключена, однако если она активна, то она дает возможность попасть в систему без ввода пароля.

Вопреки распространенному мнению, любой, кто вошел в систему анонимно, т.е. не прошедшие процедуру подтверждения подлинности, не будут включены в группу Everyone. Это имело место ранее, но изменено начиная с Windows 2003 и Windows XP (SP2).

Когда дело доходит до распределения разрешений, существует один важный вопрос, на который мы должны быть в состоянии ответить: какие конкретные люди имеют доступ к данному ресурсу?

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

Решение есть. Когда ваш CEO спросит: «Кто имеет доступ к «Зарплатная ведомость.doc»?» вы сможете быстро, уверенно и абсолютно точно дать ответ, вместо предположений после недельных расследований.

Источник

О групповых политиках и невнимательности

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

Напомню, что по умолчанию права на политику имеет группа Authenticated Users (Прошедшие проверку). При использовании фильтра безопасности мы удаляем эту группу и добавляем только тех, для кого эта политика должна отработать.

Функция стандартная, много раз опробованная. Но на сей раз что то пошло не так 🙁

Политика была назначена на правильную область, в фильтре безопасности находились правильные пользователи, но политика упорно не хотела отрабатывать. Не было никаких ошибок и предупреждений, а gpresult и RSOP просто показывали отсутствие политики в списке примененных к пользователю. Как будто ее не было совсем.

Проверив все что можно и что нельзя, я решил удалить политику и создать ее заново. И вот тут, при настройке фильтра безопасности, я обратил внимание на сообщение, появляющееся при удалении группы Authenticated Users.

Как следует из сообщения, для того, чтобы пользовательская политика смогла успешно отработать на компьютере, у компьютера должно быть право чтения на эту политику. А в группу Authenticated Users входят не только пользователи, но и компьютеры, и при ее удалении компьютер не сможет получить доступ к политике и применить ее.

Это связано с обновлением безопасности MS16-072 от 14 июня 2016 года. Обновление изменяет контекст безопасности, с помощью которого извлекаются политики пользователя. До установки обновления политики извлекаются в контексте безопасности пользователя, после — в контексте компьютера. Это делает невозможным несанкционированное повышение привилегий в том случае, если злоумышленник перехватил трафик между пользовательским компьютером и контроллером домена.

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

Самый простой вариант, это добавить в фильтр группу Domain Computers, что собственно я и сделал. После этого политика успешно применилась.

Какие из этой истории можно сделать выводы? Во первых, при назначении политики на пользователя и использовании фильтров безопасности добавляйте в список группу Domain Computers. Ну и во вторых, не ленитесь читать системные сообщения, в них может быть важная информация. Которая сэкономит вам кучу времени 🙂

Источник

Authenticated users в русской windows

Вопрос

Как ее можно добавить? Где она находиться?

Ответы

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

Все ответы

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

меняете ваш домен на название кд (самый верхний пункт в списке)

таки вроде менять не совсем обязательно, ну смотреть надо какой из серваков резолвит имя(вполне может быть ситуация с разноязычными DC)

проще попробовать по русски и по буржуйски

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

Возле названия группы есть маленькая красненькая стрелочка направлена вверх. Это не значит что группа отключена?

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

Возле названия группы есть маленькая красненькая стрелочка направлена вверх. Это не значит что группа отключена?

The opinion expressed by me is not an official position of Microsoft

Источник

Authenticated users в русской windows

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами научились отключать защитник Windows 8.1, у каждого была своя причина произвести данное действие. Сегодня я хочу вас научить очень полезной вещи, без которой системный администратор управляющий групповой политикой не сможет активно и гибко ее применять. И речь пойдет про применение фильтров на разных этапах применения групповой политики к компьютерам и пользователям.

Для чего нужен механизм фильтрации GPO

Какую бы вы сложную иерархию Active Directory не создавали у вас рано или поздно появится ситуация, что вам нужно для двух и более объектов находящихся в одном OU иметь разные настройки, а для кого-то вообще запретить применение определенной групповой политики, но перемещать объект нельзя, так как в текущей иерархии он получает все настройки по корпоративному стандарту, и усложнять структуру не представляется возможным.

Лично я стараюсь не создавать лишних организационных подразделений, так как, чем проще система, тем проще ею управлять. У вас может быть вообще одна OU и все навалено в ней, но это вам не мешает грамотно применять политики к конкретным объектам, благодаря фильтрации на разных этапах GPO.

Виды фильтрации групповых политик

Фильтр безопасности GPO

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

то вы можете их добавить в данный фильтр, после чего нужно удалить группу «Прошедшие проверку (authentication user)«, так как в нее входят все пользователи и компьютеры домена. Давайте это попробуем. Открываем оснастку «Управление групповой политикой». В прошлый раз я создавал политику «Настройка MaxTokenSize» в задачи которой входило изменение размера токена kerberos. Предположим, что я хочу применить ее только в локальной доменной группе MaxTokenSize. Для этого я нажимаю кнопку «Добавить» в области «Фильтры безопасности«, находим ее и нажимаем «Ok».

Теперь нам необходимо удалить группу по умолчанию «Прошедшие проверку«, напоминаю, что в нее входят все компьютеры и пользователи домена.

В итоге мы видим в фильтрах безопасности одну нашу группу. Пробуем зайти на компьютер, где она должна отработать.

В начале 2016 года я столкнулся с тем, что моя политика не отработала, хотя все фильтры безопасности были настроены правильно. Открыв вывод команды gpresult/ r, я обнаружил статус (Unknown reason).

Начав разбираться, все пришло к тому, что новые обновления Microsoft (KB3159398, KB3163017, KB3163018) закрывал одну нехорошую вещь, которая длилась с 2000 года. Проблема заключалась в том, что злоумышленник мог применять атаку «Человек посередине (Man in the Middle)», тем самым делать подмену ответа от контроллера домена на целевом компьютере, это выливалось в то, что он подделывал политику безопасности, которая давала ему права локального администратора для скомпрометированной учетной записи.

Microsoft долго билась с этой проблемой и пришла к решению поменять порядок считывания политики, теперь это могут делать только компьютеры домена. Раньше политики пользователя считывал пользователь, политики компьютера, компьютер. Установив KB3163622 теперь для считывания GPO используется только компьютер и если он не входит в фильтр безопасности политики, то она не применится (Подробнее можете посмотреть вот тут https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016).

Исходя из данной ситуации, чтобы политики успешно применялись Microsoft предложило добавлять одну из групп безопасности в ACL политики «Прошедшие проверку» или «Все компьютеры». Переходим к ACL.

Фильтрация GPO через ACL (Запрет GPO)

И так фильтрацию в фильтре мы сделали, чтобы политика применилась нам необходимо выбрать политику и перейти на вкладку «Делегирование». Тут нам необходимо добавить одну из двух групп «Прошедшие проверку (Authenticated Users)» или «Все компьютеры (Domain Computers)«. Я добавляю первую. Нажимаем кнопку «Добавить» и находим нашу группу.

Уровень прав оставляем «Чтение», этого будет достаточно.

Пробуем проверить применение нашей политики. В качестве испытуемого у меня идет виртуальная машина с Windows 10. После загрузки, я открываю командную строку и смотрю применение политики, для этого пишем команду:

В итоге я вижу, что среди примененных объектов групповой политики, моя «Настройка MaxTokenSize» в списке присутствует.

Если бы пользователь не был членом группы, которая фигурирует с фильтре безопасности, то мы видели бы вот такую картину, что следующие политики GPO не были применены, так как они отфильтрованы по причине отказано (Безопасность). Как видим нет прав на чтение.

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

Добавляем группу для которой хотим запретить применение политики, у меня это Forbidden MaxTokenSize.

Далее даем права «Чтение».

Далее нажимаем кнопку «Дополнительно«, у вас откроется окно параметром безопасности. Тут вы выбираете нужную вам группу, для которой вы хотите запретить применение групповой политики и ставите галку «Запретить«. В таком случае данная группа будет получать при попытке считать GPO «Отказано (безопасность)».

Фильтрация GPO по WMI

Еще одним действенным методом фильтровать получателей групповой политики, это использование WMI фильтров. Мы с вами их уже применяли, когда нужно было применить политику только к ноутбукам.

Простой пример вы создали политику и хотели бы ее применить скажем только на компьютеры у кого установлена операционная система Windows 7. Для нашей задачи нам необходимо создать WMI фильтр, для этого перейдем в «Фильтры WMI«, где выбираем соответствующий пункт.

Задаем имя WMI фильтра, после чего нажимаем кнопку «Добавить». Откроется окно для составления запроса. Конструкция для Windows 7 будет такая:

Номера для Win32_OperatingSystem

Тип продукта отвечает за назначение компьютера и может иметь 3 значения:

Вот вам пример вывода в PowerShell команды показывающей версию операционной системы:

Сохраняем наш WMI запрос.

Если хотите перед внедрение проверить будет ли применена групповая политика к нужному объекту, то можете провести тестирование в WMI Filter Validation Utility. Если все настроено корректно, но политика не применяется, почитайте по ссылке возможные варианты. Далее берем вашу политику и применяем к ней WMI.

Теперь если компьютер не соответствует критериям WMI фильтра, то вы увидите в gpresult /r /scope:computer вот такую запись (Отказано фильтр WMI)

Фильтрация через состояние GPO

Еще на вкладке «Сведения» есть такая настройка, как состояние GPO. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:

Источник

Проверка подлинности пользователей с помощью проверки подлинности Windows (C#)

Узнайте, как использовать аутентификацию Windows в контексте приложения MVC. Вы узнаете, как включить аутентификацию Windows в файле веб-конфигурации приложения и как настроить аутентификацию с помощью IIS. Наконец, вы узнаете, как использовать атрибут «Authorize» для ограничения доступа к действиям контроллера для определенных пользователей или групп Windows.

Цель этого руководства состоит в том, чтобы объяснить, как вы можете воспользоваться функциями безопасности, встроенными в информационные службы Интернета, чтобы защитить пароли в ваших приложениях MVC. Вы узнаете, как разрешить вызов действия контроллера только определенным пользователям Windows или пользователям, всданным в определенные группы Windows.

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

Включение аутентификации Windows

При создании нового приложения mVC ASP.NET проверка подлинности Windows по умолчанию не включена. Проверки подлинности форм — это тип проверки подлинности по умолчанию, включенный для приложений MVC. Необходимо включить аутентификацию Windows, изменив веб-конфигурацию приложения MVC (web.config). Найдите проверки подлинности и измените его, чтобы использовать Windows вместо формы аутентификации следующим образом:

Когда вы включите аутентификацию Windows, ваш веб-сервер становится ответственным за аутентификацию пользователей. Как правило, существует два различных типа веб-серверов, которые используются при создании и развертывании ASP.NET mVC-приложений.

Во-первых, при разработке приложения MVC используется веб-сервер ASP.NET разработки, включенный в Visual Studio. По умолчанию веб-сервер ASP.NET разработки выполняет все страницы в контексте текущей учетной записи Windows (независимо от учетной записи, которую вы использовали для входа в Windows).

Веб-сервер ASP.NET разработки также поддерживает аутентификацию NTLM. Вы можете включить проверку подлинности NTLM, нажав правой кнопкой назовем название вашего проекта в окне Solution Explorer и выбрав свойства. Затем выберите веб-вкладку и проверьте флажок NTLM (см. рисунок 1).

Для производственного веб-приложения, с другой стороны, вы используете IIS в качестве веб-сервера. IIS поддерживает несколько типов аутентификации, включая:

Более подробный обзор этих различных типов аутентификации см. https://msdn.microsoft.com/library/aa292114(VS.71).aspx

Для включения определенного типа аутентификации можно использовать менеджер информационных служб Интернета. Имейте в виду, что все типы аутентификации не доступны в случае каждой операционной системы. Кроме того, если вы используете IIS 7.0 с Windows Vista, вам необходимо включить различные типы проверки подлинности Windows, прежде чем они появятся в менеджере информационных служб Интернета. Панель открытого управления, программы, программы и функции, включите или выключите функции Windowsи расширьте узлы информационных служб Интернета (см. рисунок 2).

Используя информационные службы Интернета, можно включить или отключить различные типы аутентификации. Например, на рисунке 3 показано отключение анонимной аутентификации и включение интегрированной проверки подлинности Windows (NTLM) при использовании IIS 7.0.

Авторизация пользователей и групп Windows

После включения аутентификации Windows можно использовать атрибут «Авторизовать» для управления доступом к контроллерам или действиям контроллера. Этот атрибут может быть применен ко всему контроллеру MVC или определенному действию контроллера.

Например, контроллер Home в листинге 1 предоставляет три действия под названием Index (), CompanySecrets() и StephenSecrets(). Любой человек может вызвать действие Индекса () Однако только члены локальной группы менеджеров Windows могут ссылаться на действия CompanySecrets() Наконец, только пользователь домена Windows по имени Стивен (в домене Редмонд) может вызвать действие StephenSecrets ()

Из-за управления учетными записями пользователей Windows (UAC), при работе с Windows Vista или Windows Server 2008, местная группа администраторов будет вести себя иначе, чем другие группы. Атрибут «Авторизовать» не распознает правильно члена локальной группы администраторов, если вы не измените настройки UAC вашего компьютера.

То, что происходит при попытке вызвать действие контроллера, не будучи правильными разрешениями, зависит от типа включенной аутентификации. По умолчанию при использовании ASP.NET сервера разработки вы просто получаете пустую страницу. Страница подается с 401 Не авторизованным статусом ответа HTTP.

Если, с другой стороны, вы используете IIS с отключенной аутентификацией Anonymous и включенной базовой аутентификацией, то вы продолжаете получать запрос на диалог входа каждый раз, когда вы запрашиваете защищенную страницу (см. рисунок 4).

Источник

Введение

Для настройки функций доменной авторизации и SSO для входа в систему централизованного управления необходимо выполнить ряд действий:

• Настроить веб-сервер (ngnix или apache) на поддержку аутентификации HTTP Negotiate.
• Выполнить соответствующие настройки на стороне домена: создать SPN, ServiceUser.
• Сгенерировать keytab-файл.
• Выполнить настройку используемого браузера.

Для получения дополнительной информации по процессу аутентификации Kerberos, типам шифрования, конфигурации Kerberos, настройке оповещателей и т.д. см. документ Аутентификация Kerberos.

Настройка веб-сервера

Для настройки AD-аутентификации для apache рекомендуем ознакомиться с подробными материалами в сети Интернет ([1], [2]).

Далее приводится подробное описание процесса подготовки и настройки веб-сервера ngnix и всей системы в целом.

В базовой поставке nginx функционал AD-аутентификации отсутствует. Для добавления данного функционала рекомендуется использовать модуль SPNEGO. Таким образом, для начала необходимо собрать nginx с нужным нам модулем. Для этого выполните следующее:

1. Выполните установку nginx.

2. Скачайте последнюю версию исходников веб-сервера с официального сайта.

   wget http://nginx.org/download/nginx-1.17.1.tar.gz

3. Распакуйте папку с исходниками веб-сервера и поместите туда исходники модуля spnego-http-auth-nginx-module следующим образом:

   tar xvzf nginx-1.17.1.tar.gz
   cd nginx-1.17.1
   git clone https://github.com/stnoonan/spnego-http-auth-nginx-module

4.  Выполните команду просмотра текущей версии ngnix. На экране появится список опций сборки ngnix из базовой поставки:

   # nginx -V
   nginx version: nginx/1.12.2
   built by gcc 4.9.2 (Debian 4.9.2-10+deb8u1) 
   built with OpenSSL 1.1.0g  2 Nov 2017
   TLS SNI support enabled
   configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock 
   --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx  --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-debug --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed'

5. Скопируйте приведенный список опций во временный текстовый файл и добавьте новую опцию:

   --add-module=spnego-http-auth-nginx-module

6. Выполните сборку веб-сервера с нужными параметрами (скопированными из текстового файла):

   ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf 
   --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
   --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp 
   --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
   --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx 
   --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module 
   --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module 
   --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module 
   --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic 
   --with-threads --with-stream --with-stream_ssl_module --add-module=spnego-http-auth-nginx-module --with-http_slice_module 
   --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-debug --with-cc-opt='-g -O2 
   -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions 
   -Wl,-z,relro -Wl,--as-needed'

   Обратите внимание, что утилиты для сборки должны быть установлены в системе, а nginx должен быть остановлен.

   По завершении процедуры мы получим рабочий самосборный nginx с нужным модулем. Проверить это можно также — nginx -V и посмотреть в параметрах наличие модуля.
         

7. Запустите веб-сервер ngnix.

Создание SPN

SPN (Service Principal Name) — уникальный идентификатор экземпляра сервиса. SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью сервиса (service logon account). Это позволяет клиентским приложением аутентифицироваться в роли сервиса даже не зная имени пользователя.
До того как аутентификация Kerberos сможет использовать SPN для аутентификации сервиса, SPN должен быть привязан к учетной записи, которая будет использоваться для входа. SPN может быть привязан только к одной учетной записи. Если учетная запись, привязанная к SPN, изменяется, то необходимо заново выполнить привязку.
Когда клиент хочет воспользоваться сервисом, он находит экземпляр сервиса и составляет SPN для этого экземпляра, далее использует этот SPN для аутентификации.

DC Windows

Для начала необходимо создать на контроллере домена (DC) пользователя, к которому впоследствии мы привяжем SPN.

Например создадим пользователя squid:

Далее необходимо запретить пользователю смену пароля и не ограничивать срок действия пароля. Последнее важно, так как иначе при истечении срока действия пароля придется не только менять пароль, но и заново генерировать keytab-файлы привязанные к этому пользователю:

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

Создадим SPN для прокси-сервера squid HTTP/sqserver.domg.testg и привяжем его к пользователю squid.

Для этого в командной строке на контроллере домена выполним следующую команду:

C:>setspn -A HTTP/sqserver.domg.testg squid
Регистрация ServicePrincipalNames для CN=squid,CN=Users,DC=domg,DC=testg
        HTTP/sqserver.domg.testg
Обновленный объект

Проверить привязанные SPN у пользователя можно командой:

C:>setspn -L squid
Зарегистрирован ServicePrincipalNames для CN=squid3,CN=Users,DC=domg,DC=testg:
        HTTP/sqserver.domg.testg

DC FreeIPA

Для добавления SPN зайдите в web-интерфейс сервера FreeIPA->Identity->Services→Add:

В открывшемся окне необходимо выбрать имя сервиса и имя хоста, к которому будет привязан сервис:

Чтобы добавить SPN с коротким именем хоста (например это необходимо для samba), выполните команду:

ipa service-add cifs/samba --force

Генерирование keytab-файла

Создать keytab-файл можно разными способами.

Рассмотрим некоторые из них.

На контроллере домена Windows 2008 R2

Необходимо выполнить следующую команду:

C:>ktpass -princ HTTP/sqserver.domg.testg@DOMG.TESTG -mapuser squid -pass Pa$$word -ptype KRB5_NT_PRINCIPAL -out C:squid.keytab
Targeting domain controller: dcd.domg.testg
Using legacy password setting method
Successfully mapped HTTP/sqserver.domg.testg to squid.
Key created.
Output keytab to C:squid.keytab:
Keytab version: 0x502
keysize 70 HTTP/sqserver.domg.testg@DOMG.TESTG ptype 1 (KRB5_NT_PRINCIPAL) vno 6
 etype 0x17 (RC4-HMAC) keylength 16 (0x1a4b1757588cab6298e29e91c06df58d)

Рассмотрим параметры команды подробнее:

• -princ — имя принципала содержащее SPN и Kerberos-область (realm)
• -mapuser — пользователь к которому привязывается SPN
• -pass — пароль пользователя
• -ptype — указывает тип принципала (рекомендуется KRB5_NT_PRINCIPAL)
• -out — путь и имя генерируемого файла
  

На машине с Debian

С помощью ktutil

Этот способ работает если SPN предварительно были созданы и привязаны.

Установим необходимый пакет:

apt-get install krb5-kadmin

Запустим ktutil и создадим keytab-файл:

ktutil
ktutil:  addent -password -p HTTP/sqserver.domg.testg@DOMG.TESTG -k 6 -e RC4-HMAC
Password for HTTP/sqserver.domg.testg@DOMG.TESTG: 
ktutil:  wkt squid.keytab
ktutil:  q

С помощью Samba

Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация.
При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена.
Приведите файл настроек /etc/samba/smb.conf к следующему виду:

realm = DOMG.TESTG
workgroup = DOMG
server string = Samba server on %h (v. %v)
security = ads
dedicated keytab file = /etc/krb5.keytab
kerberos method = dedicated keytab

Введите машину в домен:

net -v ads join DOMG.TESTG -UAdministrator
Using short domain name -- DOMG
Joined 'DOSERVER' to dns domain 'domg.testg'

 Проверить ввод в домен можно командой:

net ads testjoin
Join is OK

После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.

Создадим keytab-файл для компьютера:

net ads keytab create -UAdministrator

Добавим в keytab-файл принципала сервиса «HTTP»:

net ads keytab add HTTP -U Administrator
Processing principals to add...

Далее можно поменять права на keytab и отредактировать его утилитой kutil.

С помощью Samba DC

При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.

Создадим пользователя, с которым будем связывать создаваемые SPN:

samba-tool user create <someuser>
samba-tool user setexpiry <someuser> --noexpiry

Привяжем к нему SPN (возможно несколько раз для разных сервисов):

samba-tool spn add <service-name>/test.example.com <someuser>

Создадим keytab:

samba-tool domain exportkeytab /tmp/keytab --principal=<service-name>/test.example.com

Данную процедуру необходимо выполнить несколько раз для всех spn, которые требуется поместить в keytab.

Проверка:

klist -ke /tmp/keytab
  Keytab name: FILE:/etc/http.keytab
  KVNO Principal
  ---- --------------------------------------------------------------------------
     1 host/test.address.com@INTRANET.COM (des-cbc-crc) 
     1 host/test.address.com@INTRANET.COM (des-cbc-md5) 
     1 host/test.address.com@INTRANET.COM (arcfour-hmac) 
     1 HTTP/test.address.com@INTRANET.COM (des-cbc-crc) 
     1 HTTP/test.address.com@INTRANET.COM (des-cbc-md5) 
     1 HTTP/test.address.com@INTRANET.COM (arcfour-hmac)

С помощью FreeIPA Client

Для этого способа необходимо ввести машину в домен FreeIPA.

Для генерации keytab-файла используется команда:

ipa-getkeytab -s dc.ipa.server.ru -p HTTP/httpserver.ipa.server.ru -k /etc/http.keytab

Здесь:

• dc.ipa.server.ru — FreeIPA сервер
• HTTP/httpserver.ipa.server.ru — SPN
• /etc/http.keytab — местоположение создаваемого keytab-файла

Проверка keytab-файла

Для проверки keytab-файла необходима настроенная Kerberos-аутентификация.

Это можно проверить командой:

kinit Administrator@DOMG.TESTG

Она должна запрашивать пароль и получать билет:

klist
Ticket cache: KEYRING:persistent:0:0
Default principal: Administrator@DOMG.TESTG
Valid starting       Expires              Service principal
14.03.2017 16:45:58  15.03.2017 02:45:58  krbtgt/DOMG.TESTG@DOMG.TESTG
	renew until 21.03.2017 16:44:36

Попробуем зарегистрироваться с помощью keytab-файла:

kinit -V -k HTTP/sqserver.domg.testg -t /home/test/squid.keytab 
Using existing cache: persistent:0:krb_ccache_95Lkl2t
Using principal: HTTP/sqserver.domg.testg@DOMG.TESTG
Using keytab: /home/test/squid.keytab
Authenticated to Kerberos v5

Проверить версию ключей на сервере можно, предварительно получив билет, с помощью команды:

kvno HTTP/sqserver.domg.testg
HTTP/sqserver.domg.testg@DOMG.TESTG: kvno = 6

Проверить версию kvno и список ключей в keytab-файле можно с помощью команды:

klist -ket /home/test/squid.keytab
Keytab name: FILE:/home/test/squid.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   6 01.01.1970 03:00:00 HTTP/sqserver.domg.testg@DOMG.TESTG (arcfour-hmac)

После всех проверок желательно удалить полученные билеты командой:

Подготовка и настройка клиентского браузера

В данном разделе рассматривается процесс настройки аутентификации Kerberos для разных браузеров, чтобы обеспечить прозрачную и безопасную аутентификацию на веб-серверах без необходимости повторного ввода пароля пользователя в корпоративной сети. Большинство современных браузеров (IE, Chrome, Firefox) поддерживают Kerberos, однако для его работы необходимо выполнить несколько дополнительных настроек.

Рассмотрим пример разрешения клиентам Kerberos проходить аутентификацию с использованием браузера на любых веб-серверах домена applite.ru (в данном случае вместо IP-адреса веб-сервера следует всегда использовать имя DNS или полное доменное имя).

Настройка Kerberos-аутентификации в Internet Explorer

Перейдите в Свойства браузера -> Безопасность -> Местная интрасеть и нажмите Сайты -> Дополнительно. Добавьте следующие записи в зону:

• https://*.applite.ru
• http://*.applite.ru

Затем перейдите на вкладку Дополнительно и в разделе Безопасность убедитесь, что установлен флажок «Разрешить встроенную проверку подлинности Windows».

Настройка Kerberos-аутентификации в Google Chrome

Чтобы функция SSO работала в Google Chrome, настройте Internet Explorer, используя метод, описанный выше (Chrome использует настройку IE). Кроме того, следует отметить, что все новые версии Chrome автоматически обнаруживают поддержку Kerberos на сайте. Если вы используете одну из более ранних версий Chrome (Chromium), запустите ее со следующими параметрами, чтобы проверка подлинности Kerberos на ваших веб-серверах работала правильно:

--auth-server-whitelist="*.applite.ru"
--auth-negotiate-delegate-whitelist="*.applite.ru"

Например:

"C:Program Files (x86)GoogleChromeApplicationchrome.exe” --auth-server-whitelist="*.applite.ru" --auth-negotiate-delegate-whitelist="*.applite.ru"

Вы также можете настроить эти параметры с помощью GPO для Chrome (политика AuthServerWhitelist) или параметра реестра AuthNegotiateDelegateWhitelist, расположенного в разделе реестра HKLMSOFTWAREPoliciesGoogleChrome.

Чтобы изменения вступили в силу, перезапустите браузер и сбросьте билеты Kerberos с помощью команды очистки klist purge.

Настройка Kerberos-аутентификации в Firefox

По умолчанию поддержка Kerberos в Firefox отключена. Чтобы включить поддержку аутентификации, откройте окно настройки браузера (введите about:config в адресной строке). Затем в следующих параметрах укажите адреса веб-серверов, для которых вы собираетесь использовать аутентификацию Kerberos.

1. network.negotiate-auth.trusted-uris
2. network.automatic-ntlm-auth.trusted-uris

Чтобы проверить, что браузер прошел проверку подлинности Kerberos на сервере, воспользуйтесь отладчиком Fiddler или командой klist tickets.

4 ответа