Конфиденциальность
Первоначально реализованный в Kerberos и SAML, единый вход не давал пользователям никакого выбора в отношении предоставления их личной информации каждому новому ресурсу, который посетил пользователь. Это работало достаточно хорошо в рамках одного предприятия, например Массачусетского технологического института, где был изобретен Kerberos, или крупных корпораций, где все ресурсы были внутренними сайтами. Однако по мере распространения федеративных служб, таких как службы федерации Active Directory , личная информация пользователя отправлялась на аффилированные сайты, не находящиеся под контролем предприятия, которое собирало данные от пользователя. Поскольку правила конфиденциальности теперь ужесточаются с таким законодательством, как GDPR , новые методы, такие как OpenID Connect , начали становиться более привлекательными; например, MIT, создатель Kerberos, теперь поддерживает OpenID Connect .
Адрес электронной почты
Теоретически единый вход может работать без раскрытия идентифицирующей информации, такой как адреса электронной почты, проверяющей стороне (потребителю учетных данных), но многие поставщики учетных данных не позволяют пользователям настраивать, какая информация передается потребителю учетных данных. С 2019 года для входа в Google и Facebook не требуется, чтобы пользователи делились адресами электронной почты с потребителем учетных данных. « Вход через Apple », представленный в iOS 13, позволяет пользователю запрашивать уникальный адрес электронной почты для ретрансляции каждый раз, когда пользователь подписывается на новую службу, что снижает вероятность привязки учетной записи потребителем учетных данных.
Настройка сквозной аутентификации по смарт-карте
- на ПК пользователя запустите утилиту командной строки CMD с правами администратора;
- в командной строке указать путь к файлу установщика Citrix Receiver 4.0 и дополнительно указать параметры для включения SSO: /includeSSON AM_SMARTCARDPINENTRY=CSP; Пример: C:\Distr\CitrixReceiver.exe /includeSSON AM_SMARTCARDPINENTRY=CSP
- дождитесь окончания установки ПО Citrix Receiver 4.0 и перезагрузите ПК пользователя;
- после перезагрузки ПК пользователя проверьте, что в исполняемых процессах (Task Manager/Processes) присутсвует процесс ssonsrv.exe;
- выполните настройку политик аутентификации для ПО Citrix XenDesktop, которые будут применяться на серверы Citrix и устройства пользователей, как описано в разделе 3.3.
http://support.citrix.com/proddocs/topic/receiver-windows-40/receiver-windows-smart-card-cfg.htmlTo enable single sign-on for smart card authentication, To use CSP PIN prompts
3. Настройка политик аутентификации для ПО Citrix XenDesktop
- в шаблоны групповых политик службы каталога Active Directory импортируйте шаблон политик Citrix ADM Template (Add Template в оснастке управления групповыми политиками); Шаблон политик можно найти в папке установки клиента ПО Citrix Receiver: C:\Program Files (x86)\Citrix\ICA Client\Configuration\icaclient.adm.
- создайте политику (или отредактируйте имеющуюся) и включите сквозную аутентификацию по смарт-картам;
- откройте раздел Computer Configuration -> Policies -> Administrative templates -> Classic -> Citrix Components -> Citrix receiver -> User Authentica-tion;
- выберите настройку Smart Card Authentication и включите параметры «Allow smart card authentication» и «Use pass-through authentication for PIN». Выберите настройку Local User Name and Password и включите параметры «Enable pass-through authentication» и «Allow pass-through authentication for all ICA connections» (рис. 54, рис. 55).
http://support.citrix.com/proddocs/topic/ica-settings/ica-settings-wrapper.htmlРис. 54 — Настройка групповых политик AD для SSOРис. 55 — Настройка групповых политик службы каталога AD для SSO
4. Настройка ПО Citrix StoreFront 2.1 для включения сквозной аутентификации по смарт-картам
Вниманиеpropagate your configuration changes to the server group
- выполните первоначальную настройку ПО Citrix StoreFront 2.1, согласно разделу —Настройка Citrix StoreFront;
- в разделе Add/Remove Authentication Methods добавьте метод аутентификации Domain pass-through (рис. 56);Рис. 56 — Настройка метода аутентификации
- для включения сквозной аутентификации с использованием смарт-карт необходимо внести дополнительные изменения в конфигурацию. Для этого отредактируйте default.ica для каждого ПО Citrix Store, где требуется сквозная аутентификация по смарт-картам;
- используя текстовый редактор, откройте файл default.ica, который находится в папке:
C:\inetpub\wwwroot\Citrix\storename\App_Data\; - если в инфраструктуре не используется аутентификация через NetScaler Gateway, то добавьте следующий параметры
: DisableCtrlAltDel=Off.
Данная настройка будет применяться для всех пользователей; - для включения сквозной аутентификации по смарт-картам с использованием NetScaler Gateway добавьте следующий параметр:
: UseLocalUserAndPassword=On; Подробная информация доступна на сайте: http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-configure-conf-smartcard.html. - выполните настройку пользователя, согласно разделу — Настройка ПК пользователя (см. раздел 2.5). Проверьте, что вход на виртуальную машину пользователя выполняется успешно. Проверьте, что после входа на ПК пользователя (по смарт-карте или по паролю) больше не появляется окно запроса учётных данных или PIN-кода при доступе к StoreFront или/и виртуальной машине пользователя.
- повышение общего уровня безопасности, что происходит за счёт отказа от простых паролей и перехода к строгой аутентификации с использованием второго фактора;
- обеспечение защищённого доступа к виртуальным рабочим столам и приложениям;
- возможность работы со смарт-картами и USB-токенами после аутентификации в защищённой сессии;
- возможность использования электронной подписи;
- поддержка RSA- и ГОСТ-алгоритмов;
- дополнительные преимущества — одна и та же карта, помимо основных функций аутентификации и ЭП, может служить пропуском в помещение (наличие RFID-метки), также может являться зарплатной (платёжное приложение MasterCard или VISA) или транспортной картой;
- доступны и другие варианты кастомизации — нанесение логотипа и использование
корпоративного стиля заказчика.
Свойства Zabbix¶
На закладке Свойства Zabbix
Можно задать:
Включить активные проверки — в данном режиме, в отличие от пассивной проверки, когда Zabbix сервер или прокси запрашивает данные (например, загрузку ЦПУ) и агент Zabbix отправляет результат обратно серверу, агент сначала должен запросить с сервера(ов) список элементов данных для независимой обработки.
Активные проверки требуют более сложной обработки. Активный режим необходим для тех случаев, когда сервер не может напрямую подключится к агенту, например — когда агент располагается за NAT или имеет динамический адрес.
Active Check Servers — Список пар IP:порт (или имя хоста:порт) Zabbix серверов или Zabbix прокси для активных проверок.
Можно указывать несколько адресов разделенных запятыми, чтобы параллельно использовать несколько независимых Zabbix серверов. Пробелы не допустимы
(ВАЖНО: даже после одного адреса необходимо ставить запятую)
Active Check Refresh — Как часто обновлять список активных проверок, в секундах.
Включить удалённые команды — Разрешены ли удаленные команды с Zabbix сервера. С помощью удаленных команд вы можете указать какие из предустановленных команд будут выполнены на наблюдаемом узле сети при выполнении некоторых условий.
Протоколировать удалённые команды — Включение журналирования выполняемых shell команд как предупреждений.
Танец Великих Равнин. Apache
Начинаем охотиться вместе с индейцами племён Апачи.
Настройка
Этого, конечно, недостаточно, потому что свежеустановленный индеец не знает нашего языка. примерно так:
И дадим “пиночек под задочек”:
Убедимся, что он научился разговаривать по-нашенски, зайдя в System Management Portal.
Апачи некогда были гордым и независимым народом, у них это в крови, поэтому со всем уважением и вежливостью попросим Apache браться за работу вместе с нашим Пингвином-Прорицателем:
Прослушавши “Пионерскую Зорьку”, сделав водные процедуры, выгулявши трёхглавую собачку и причесав индейца, переходим к “Производственной Гимнастике”, которая сегодня будет танцевальной (и даже с бубнами).
How to Configure Browsers for Kerberos Authentication?
For Internet Explorer to use Kerberos authentication on Zabbix, you will have to add its URL to Local Intranet sites. Google Chrome uses Internet Explorer settings, so you do not need to configure it separately.
Note. The URL of your Zabbix site must not belong to the list of Trusted sites, otherwise Kerberos won’t work. The site must be specified only in the Intranet sites.
Open Options -> Security in the IE.
Click Sites in the Local intranet, check the options shown in the screenshot below and click Advanced.
Enter your Zabbix server URL.
Go to the Advanced tab and check Enable Integrated Windows Authentication.
Also, you can also put Zabbix URL to the Local Intranet zone using the Group Policies (Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment List. Use zone code 1 for intranet sites).
Add the URL of your Zabbix server to the following parameters of for your Mozilla Firefox:
network.automatic-ntlm-auth.trusted-uris network.negotiate-auth.delegation-uris network.negotiate-auth.trusted-uris
If you come across any issues, see the detailed article on Kerberos configuration in browsers.
After that the configuration is over. If you try to access your Zabbix server URL, you will be authenticated automatically and won’t be prompted to enter your password.
Настройка времени
Каждый тикет (билет) Kerberos сопровождается меткой времени, и если время между клиентом и сервером расходится более чем на 10 минут процесс обмена тикетами прерывается. Что бы этого не происходило нужно настроить синхронизацию времени между нашим веб-сервером и контроллером домена.
Устанавливаем клиент NTP и планировщик задач, если он еще не установлен.
# yum install ntpdate cronie
Делаем первоначальную синхронизацию времени, добавляем запуск синхронизации времени в планировщик и запускаем его.
# ntpdate mydomain.local # echo "0 0 * * * root /usr/sbin/ntpdate mydomain.local" >> /etc/crontab # service crond start
Kerberos
Данная вкладка предназначена для подключения к по протоколу сетевой аутентификации Kerberos.
- Заполните все поля вкладки:
- «Имя компьютера» — задает ;
- «Имя домена» — задает имя домена, в котором ИКС будет как пользователь;
- «DNS-имя контроллера домена» — укажите соответствующее имя;
- «Keytab файл» — предназначено для загрузки .
- Загрузите Keytab-файл по кнопке .
- Нажмите «Сохранить».
Пример создания Keytab-файла
Имя компьютера — Test, имя домена — test.ru. Для создания Keytab-файла выполните следующие действия на контроллере домена:
- Создайте пользователя Test с бессрочным паролем, имя не должно содержать кириллических символов.
- Выполните от имени администратора в командной строке:
ktpass -princ HTTP/Test.test.ru@TEST.RU -mapuser «Test» -pass «Aa123456» -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\ics_01.keytab
где:
- -princ HTTP/Test.test.ru@TEST.RU — имя принципала службы ();
- -mapuser «Test» — пользователь, созданный в контроллере домена;
- -pass «Aa123456» — пароль созданного пользователя;
- -out C:\ics_01.keytab — путь до создаваемого Keytab-файла с указанием его имени.
Для удобства команда создания Keytab-файла указана в веб-интерфейсе на вкладке «Kerberos». Она изменяется в соответствии с введенными значениями полей.
Внимание! При интеграции ИКС с LDAP-сервером FreeIPA команда для генерации keytab-файла, подходящего для настройки Kerberos, будет отличаться. Команда также выводится для удобства на вкладке «Kerberos» и изменяется в соответствии с введенными значениями полей
Пример создания Keytab-файла (FreeIPA)
Имя компьютера — Test, имя домена — test.ru, DNS-имя сервера FreeIPA — server.test.ru. Для создания Keytab-файла выполните следующие действия на сервере FreeIPA:
- Добавьте узел test c IP-адресом ИКС.
- Добавьте службу HTTP c указанием узла test.test.ru.
- Выполните команду:
ipa-getkeytab -s server.test.ru -p HTTP/test.test.ru@TEST.RU -k /tmp/ics_01.keytab
где:
- -s server.test.ru — DNS-имя сервера FreeIPA;
- -p HTTP/test.test.ru@TEST.RU — имя принципала службы (SPN);
- -k /tmp/ics_01.keytab — путь до создаваемого Keytab-файла с указанием его имени.
В случае удачной настройки ИКС сообщит соответствующую информацию: «А-запись», «PTR-запись», «Попытка авторизации» должны иметь статус Ок».
Если попытка прошла неудачно, ИКС выдаст рекомендации по их устранению.
Внимание! При подключении по протоколу Kerberos имя системы будет изменено на «имя.домен». ИКС должен использовать контроллер домена как единственный , иначе необходимо добавить перенаправление DNS-зоны домена на одного или нескольких контроллеров домена
ИКС должен использовать контроллер домена как единственный , иначе необходимо добавить перенаправление DNS-зоны домена на одного или нескольких контроллеров домена.
Настроить авторизацию на прокси с использованием Kerberos
- Укажите в браузере адрес ИКС как имя, под которым ИКС введен в домен (например, test.office1.example.ru). По IP данный тип авторизации работать не будет.
- В настройках службы прокси укажите, что нужно использовать тип авторизации Kerberos.
Важно! Если пользователь не прошел Kerberos-авторизацию, ему будет предложено ввести логин и пароль для LDAP-авторизации. При этом если не используется LDAPS (с сертификатом), пароль при LDAP-авторизации будет передаваться в открытом виде
Если Kerberos не настроен, то авторизация в VPN, связанная с Kerberos, будет недоступна.
Аутентификация LDAP Zabbix в Active Directory
Хотите узнать, как настроить Zabbix LDAP-аутентификацию в Active Directory? В этом уроке мы покажем вам, как аутентифицировать пользователей Zabbix с помощью базы данных Active Directory Microsoft Windows и протокола LDAP.
Список оборудования:
В следующем разделе представлен список оборудования, используемого для создания этого учебника Zabbix.
Все перечисленные выше аппаратные средства можно найти на веб-сайте Amazon.
Zabbix Playlist:
На этой странице мы предлагаем быстрый доступ к списку видеороликов, связанных с установкой Zabbix.
Playlist
Не забудьте подписаться на наш канал YouTube, названный FKIT.
Учебное пособие Zabbix:
На этой странице мы предлагаем быстрый доступ к списку руководств, связанных с установкой Zabbix.
Список учебных пособий
Учебник — Брандмауэр контроллера домена Windows
Во-первых, нам нужно создать правило брандмауэра на контроллере домена Windows.
Это правило брандмауэра позволит серверу Zabbix запрашивать базу данных Active Directory.
На контроллере домена откройте приложение под названием Брандмауэр Windows с расширенной безопасностью
Создайте новое правило входящего брандмауэра.
Выберите параметр ПОРТ.
Выберите опцию TCP.
Выберите опцию «Специальные локальные порты».
Введите TCP-порт 389.
Выберите параметр Разрешить подключение.
Проверьте параметр DOMAIN.
Проверьте опцию PRIVATE.
Проверьте опцию PUBLIC.
Введите описание правила брандмауэра.
Поздравляем, вы создали необходимое правило брандмауэра.
Это правило позволит Zabbix запрашивать базу данных Active Directory.
Учебное пособие — Создание учетной записи Windows Domain
Затем нам нужно создать не менее 2 учетных записей в базе данных Active Directory.
Учетная запись ADMIN будет использоваться для входа в веб-интерфейс Zabbix.
Учетная запись ZABBIX будет использоваться для запроса базы данных Active Directory.
На контроллере домена откройте приложение с именем: Active Directory — пользователи и компьютеры
Создайте новую учетную запись внутри контейнера Users.
Создайте новую учетную запись с именем: admin
Пароль, настроенный для пользователя Admin: 123qwe.
Эта учетная запись будет использоваться для аутентификации в качестве администратора на веб-интерфейсе Zabbix.
Создайте новую учетную запись с именем: zabbix
Пароль, настроенный для пользователя Admin: 123qwe.
Эта учетная запись будет использоваться для запроса паролей, хранящихся в базе данных Active Directory.
Поздравляем, вы создали необходимые учетные записи Active Directory.
Учебное пособие — Zabbix LDAP Authentication в Active Directory
Откройте браузер и введите IP-адрес вашего веб-сервера plus / zabbix.
В нашем примере в браузере был введен следующий URL:
• http://35.162.85.57/zabbix
На экране входа в систему используйте имя пользователя по умолчанию и пароль по умолчанию.
• Имя пользователя по умолчанию: Admin
• Пароль по умолчанию: zabbix
После успешного входа в систему вы будете отправлены на панель инструментов Zabbix.
На экране панели инструментов откройте меню «Администрирование» и выберите параметр «Аутентификация».
На экране «Аутентификация» выберите параметр «LDAP».
Вам необходимо настроить следующие элементы:
• Хост LDAP: 192.168.0.50
• Порт: 389
• Base DN: dc = tech, dc = local
• Атрибут поиска: SaMAccountName
• Связывание DN: zabbix@tech.local
Вам нужно изменить IP-адрес на IP-адрес контроллера домена.
Вам необходимо изменить информацию о домене, чтобы отразить сетевую среду.
Введите имя пользователя администратора, его пароль и нажмите кнопку «Тест».
Если ваш тест завершился успешно, вы должны увидеть следующее сообщение.
После завершения настройки вы должны выйти из веб-интерфейса Zabbix.
Попробуйте войти в систему с помощью пользователя Admin и пароля из базы данных Active Directory.
На экране входа в систему используйте пользователя Admin и пароль из базы данных Active Directory.
• Имя пользователя: Admin
• Пароль: введите базу данных Active Directory.
Поздравляем! Вы настроили аутентификацию LDAP Zabbix в Active Directory с помощью LDAP.
Чтобы аутентифицировать пользователя в Active Directory, учетная запись пользователя также должна существовать в базе данных пользователей сервера Zabbix.
2018-08-10T13:57:26-03:00
Безопасность
В марте 2012 года в исследовательской работе сообщалось об обширном исследовании безопасности механизмов входа в социальные сети . Авторы обнаружили 8 серьезных логических недостатков у известных поставщиков идентификаторов и веб-сайтов проверяющих сторон, таких как OpenID (включая Google ID и PayPal Access), , Janrain , Freelancer , FarmVille и Sears.com . Поскольку исследователи проинформировали поставщиков идентификаторов и веб-сайты проверяющих сторон до публичного объявления об обнаружении уязвимостей, уязвимости были исправлены, и о нарушениях безопасности не сообщалось.
В мае 2014 года была обнаружена уязвимость под названием Covert Redirect . Впервые о «уязвимости скрытого перенаправления, связанной с OAuth 2.0 и OpenID» сообщил его первооткрыватель Ван Цзин, аспирант-математик из Технологического университета Наньян , Сингапур. Фактически, затронуты почти все протоколы единого входа. Covert Redirect использует преимущества сторонних клиентов, восприимчивых к XSS или Open Redirect.
В декабре 2020 года были обнаружены недостатки в федеративных системах аутентификации, которые использовались злоумышленниками во время утечки данных федерального правительства США в 2020 году .
Из-за того, как работает единый вход, отправив запрос на авторизованный веб-сайт для получения токена SSO и отправив запрос с токеном на вышедший из системы веб-сайт, токен не может быть защищен с помощью флага cookie HttpOnly и, следовательно, могут быть украдены злоумышленником при наличии XSS-уязвимости на вышедшем из системы веб-сайте с целью перехвата сеанса . Другая проблема безопасности заключается в том, что если сеанс, используемый для SSO, украден (который может быть защищен с помощью флага cookie HttpOnly, в отличие от токена SSO), злоумышленник может получить доступ ко всем веб-сайтам, использующим систему SSO.
Установка
- Настраиваем TLS на Кибане и Elasticsearch сервере: инструкция. Этот пункт опциональный, но желательный — несолидно ведь предлагать систему аутентификации без шифрования траффика.
- Устанавливаем IIS (Microsoft Internet Information Services) для аутентификации пользователей через NTLM. Так как этот веб-сервер будет использоваться в качестве прокси и никакой другой работы выполнять не будет, можно IIS установить на одном сервере с Кибаной.
- «Улучшаем» IIS:
- Application Request Routing (ARR) — расширение, которое позволяет IIS работать в качестве балансера нагрузки. В нашем случае он будет использваться как обратный прокси сервер (reverse proxy).
- Helicon ISAPI_Rewrite 3 engine — сторонный модуль, эмулирующий работу движка Apache rewrite. Он нужен, потому что IIS (на данный момент) не может установить переменную когда используется NTLM, так как встроенный IIS Rewrite модуль вызывается до аутентификации пользователя.
Создание учетной записи в AD и файла keytab
Для подключения к контроллеру домена нам необходимо подтверждать подлинность. Это выполняется с помощью учетной записи в LDAP и файла keytab.
Создание учетной записи
Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.
В своем примере мы создаем пользователя spnego.
Учетная запись должна быть размещена по пути, в котором присутствуют названия только на латинице. Подразделения и контейнеры не должны быть на русском. В противном случае, при выполнении команды ниже мы получим ошибку «Password set failed! 0x00000020».
Создание keytab-файла
В двух словах, данный файл позволяет пройти идентификацию в Kerberos без запроса пароля. Он содержит пары имен субъектов Kerberos и зашифрованные ключи, полученные из пароля Kerberos.
Мы создадим данный файл на контроллере домена и скопируем на сервер NGINX. Для этого на контроллере домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:
ktpass /princ HTTP/nginx.domain.local@DOMAIN.LOCAL /mapuser spnego@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /out C:\spnego.keytab /pass *
* где:
- nginx.domain.local — полное имя нашего nginx-сервера;
- DOMAIN.LOCAL — наш домен;
- spnego@DOMAIN.LOCAL — учетная запись в AD для выполнения запросов (создана на шаге выше);
- pass * — пароль, который будет задан пользователю (должен соответствовать требованию AD). Система запросит его ввод дважды.
* регистр важен.
В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл spnego.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP.
Kerberos Authentication Debugging & Troubleshooting in Apache
If you have any issues, enable debug mode in apache2:
Enter the following before the closing </VirtualHost> tag in /etc/apache2/sites-available/000-defaults.conf:
LogLevel trace8
Restart apache, and check Kerberos module error in the error.log file.
To make it more convenient, use this command to filter the entries by the IP address:
To work with and diagnose Kerberos, you can use kinit and klist commands.
kinit is a tool to get and cache Kerberos tickets, for example:
If you have generated your keytab file correctly, the command will run, and you will get a message that the authentication has been successful.
Using klist, you can view cached Kerberos tickets:
Настройка устройства TING с несколькими контроллерами доменов¶
К приведенной выше схеме добавим еще один домен со следующими настройками:
локальная сеть |
192.168.140.0/24 |
домен Active Directory |
mod.loc |
контроллер домена Active Directory |
dc1.mod.loc |
IP адрес контроллера домена Active Directory |
192.168.140.2 |
DNS имя устройства TING |
tinga.mod.loc |
IP адрес устройства TING |
192.168.140.8 |
Примечание
Домены должны иметь разные подсети, в нашем случае 192.168.1.0/24 и 192.168.140.0/24.
Настройка DNS
Настройка DNS аналогична настройке при работе с одним контроллером домена.
Создайте на доменном DNS-сервере нужные ресурсные записи для узла TING.
в прямой зоне mod.loc
в обратной зоне 140.168.192.in-addr.arpa
На устройстве TING необходимо добавить переопределение домена на соответствующий DNS сервер, обслуживающий данные зоны.
При использовании на устройстве TING DNS сервера Unbound DNS, необходимо в меню Службы -> Unbound DNS -> Переопределение в секции Переопределение домена добавить переопределение прямой и обратной зоны для второго домена домена:
Синхронизация времени
Удостоверьтесь, что время на устройстве TING и обоих контроллерах домена синхонизировано. Для этого лучше всего , как устройства TING, так и контроллеров доменов из одного источника.
Настройка LDAP-коннектора
По аналогии добавляем в Система -> Доступ -> Серверы коннектор для домена
Описательное имя |
MOD-LOC |
Тип |
LDAP |
Имя хоста или IP-адрес |
192.168.140.2 |
Значение порта |
389 |
Транспортный протокол |
TCP |
Версия протокола |
3 |
Привязать параметры доступа |
имя и пароль |
Область поиска |
Единичный уровень |
Базовый DN |
DC=mod,DC=loc |
Контейнеры для аутентификации |
CN=Users,DC=mod,DC=loc |
Начальный шаблон |
Microsoft AD |
Атрибут присвоения имени пользователю |
sAMAccountName |
Настройки веб-прокси
В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Перенаправляющий прокси -> Настройка Аутентификации, в поле Метод аутентификации укажите ldap-коннектор для домена
Пройдите в раздел Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладку домена Аутентификация по протоколу Kerberos:MOD-LOC.
По аналогии со схемой с одним доменом выполните и проверку аутентификации по протоколу Kerberos второго домена mod.loc
Настройка завершена.
Описание работы
- Пользователи посылают запрос на веб-сервер (IIS), который аутентифицирует их через механизм Windows Authenticated (все остальные методы аутентификации отключены в конфигурации этого веб-сайта).
- Если аутентификация прошла успешно, то IIS устанавливает переменную окружения .
- Эта переменная будет использоваться в дополнительном модуле Helicon rewrite для установки имперсонифицированного HTTP-заголовка (impersonation header) .
- Модуль Helicon rewrite устанавливает также и HTTP-заголовок аутентификации (Basic) для специального технического внутреннего пользователя Elasticsearch.
- Специальная роль в Elasticsearch используется для разрешения запуска поисковых запросов от имени других пользователей. Так как имперсонификация должна быть разрешена только для пользователей домена, то эта роль будет выглядеть примерно так: .
- Настраиваем для X-Pack’a
- Так как доступ пользователей к индексам будет регулироваться только через AD-группы, то AD-realm должен использовать параметер . Это значит, что имя AD-группы будет именем роли в Elasticsearch (см. ниже про безопасность и производительность).
- Все пользователи нашей системы (Кибаны), вне зависимости от того, к каким индексам в Elasticsearch им предоставлен доступ, должны иметь права на чтение и запись в индекс . Значит, в AD нужно создать специальную группу, в которую будут включаться все те пользователи, которым нужно пользоваться Кибаной. Кроме того, в Elasticsearch нужно создать роль с таким же именем и с правами на изменение индекса . Для примера, так будет выглядеть конфигурация пользователя отдела администрирования сетевого оборудования:
- Пользователь Кибаны: AD-группа = ES роль = права на индекс :
- Доступ к сетевым логам: AD-группа = ES роль = права на индексы :
Подключение к Active Directory или Откуда берутся пользователи
Definitions & Users
- Network Definitions — содержат информацию обо всех сетевых элементах (хосты, сети, и т.д.)
- Service Definitions — сопоставление портов и протоколов
- Users & Groups — пользователи и группы
Добавляем группы безопасности из AD в Sophos UTM
Definitions & Users -> Users & Groups -> Groups -> ‘New Group’.Definitions & Users -> Authentication Servers -> Servers — Edit: Authenticate example user: Test
Добавляем AD SSO
- В качестве DNS сервера оставить только DomainController: Network Services-> DNS -> Forwarders
- Добавить UTM в контроллер домена: Definitions & Users -> Authentication Services -> Single Sign-On
Необходимы права, которые позволяют добавлять компьютеры в домен.