Настройка sso windows server 2016

Обновлено: 04.07.2024

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

В связи с этим, для упрощения работы с удаленным рабочим столом в Windows Server 2008 появилась возможность использования технологии прозрачной авторизации Single Sign-on (SSO). Благодаря ей пользователь при входе на терминальный сервер может использовать учетные данные, введенные им при логине на свой локальный компьютер, с которого происходит запуск клиента удаленного рабочего стола.

В статье приведен обзор алгоритма работы технологии прозрачной авторизации Single Sign-On и поставщика услуг безопасности Credential Security Service Provider (CredSSP). Рассмотрен способ настройки клиентской и серверной частей. Также освещен ряд практических вопросов связанных с прозрачной авторизацией для служб удаленных рабочих столов.

Теоретическая информация

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

Впервые механизмы прозрачной авторизации появились в Windows Server 2008 и Windows Vista. благодаря новому поставщику услуг безопасности CredSSP. С его помощью кэшированные учетные данные передавались через безопасный канал (используя Transport Layer Security (TLS)). Впоследствии Microsoft выпустила соответствующие обновления для Windows XP SP3.

Рассмотрим это более подробно. CredSSP может использоваться в следующих сценариях:

для сетевого уровня аутентификации (NLA), позволяя пользователю быть узнанным до полной установки соединения;
для SSO, сохраняя учетные данные пользователя и передавая их на терминальный.

При восстановлении сеанса внутри фермы, CredSSP ускоряет процесс установки соединения, т.к. терминальный сервер определяет пользователя без установки полноценного соединения (по аналогии c NLA).

Процесс аутентификации происходит по следующему алгоритму:

Клиент инициирует установку безопасного канал с сервером, используя TLS. Сервер передает ему свой сертификат, содержащий имя, удостоверяющий центр и публичный ключ. Сертификат сервера может быть самоподписанным.
Между сервером и клиентом устанавливается сессия. Для неё создается соответствующий ключ, который в дальнейшем будет участвовать в шифровании. CredSSP использует протокол Simple and Protected Negotiate (SPNEGO) для взаимной аутентификации сервера и клиента так, чтобы каждый из них мог доверять друг другу. Этот механизм позволяет клиенту и серверу выбрать механизм аутентификации (например, Kerberos или NTLM).
Для защиты от перехвата, клиент и сервер поочередно шифруют сертификат сервера, используя ключ сессии, и передают его друг другу.
Если результаты обмена и исходный сертификат совпадают, CredSSP на клиенте посылает учетные данные пользователя на сервер.

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

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

1. Запустить редактор реестра regedit и перейти в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Добавить значение tspkg к ключу Security Packages (остальные значения этого ключа следует оставить неизменными).

3. Перейти в ветку реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders.

4. Добавить значение credssp.dll к ключу SecurityProviders (остальные значения этого ключа следует оставить неизменными).

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

Computer Configuration\Administrative Templates\System\Credentials Delegation.

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

Рис. 1. Управление передачей учетных данных при помощи групповых политик

Для использования SSO следует включить политику:

Разрешить передачу учетных данных, установленных по умолчанию.

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

В окне редактирования политики (рис. 2) нажать кнопку «Показать»

Рис. 2. Окно редактирования групповой политики

Добавить список терминальных серверов (рис. 3).

Рис. 3. Добавление терминального сервера для прозрачной авторизации

Строка добавления сервера имеет следующий формат:

TERMSRV/имя_сервера.

Также можно задать сервера по маске домена. В этом случае строка приобретает вид:

TERMSRV/*.имя_домена.

Если нет возможности использовать групповые политики, соответствующие настройки можно установить при помощи редактора реестра. Например, для настройки Windows XP Sp3 можно использовать следующий файл реестра:

Windows Registry Editor Version 5.00

«Security Packages»=hex (7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\

«SecurityProviders»="msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll"

Для использования технологии Single Sign-On на терминальном сервере необходимо выполнить следующие действия.

Открыть консоль настройки служб терминалов (tsconfig.msc).
В разделе подключения перейти в свойства RDP-Tcp.
На вкладке «Общие» установить уровень безопасности «Согласование» или «SSL (TLS 1.0)» (рис. 4).

Рис. 4. Настройка уровня безопасности на терминальном сервере

На этом настройку клиентской и серверной части можно считать законченной.

Практическая информация

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

Технология Single Sign-On работает только при соединении с компьютеров под управлением операционной системы не Windows XP SP3 и более старших версий. В качестве терминального сервера могут быть использованы компьютеры с операционной системой Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2.
Если терминальный сервер, к которому устанавливается соединение, не может быть аутентифицирован через Kerberos или SSL-сертификат, SSO работать не будет. Это ограничение можно обойти с помощью политики:
Разрешить делегирование учетных данных, установленных по умолчанию с проверкой подлинности сервера «толькоNTLM».
Алгоритм включения и настройки данной групповой политики аналогичен представленному выше. Файл реестра, соответствующей данной настройке имеет следующий вид.

Аутентификация данным способом менее безопасна, чем при использовании сертификатов или Kerberos.

Если для какого-либо сервера сохранены учетные данные в настройках терминального клиента, то они имеют более высокий приоритет, чем текущие учетные данные.
Single Sign-On работает только при использовании доменных аккаунтов.
Если подключение к терминальному серверу идет через TS Gateway, в некоторых случаях возможен приоритет настроек сервера TS Gateway над настройками SSO терминального клиента.
Если терминальный сервер настроен каждый раз запрашивать учетные данные пользователей, SSO работать не будет.
Технология прозрачной авторизации работает только с паролями. В случае использования смарт-карт, она работать не будет.

В некоторых случаях возможна ситуация когда на одном и том же терминальном клиенте технология прозрачной авторизации может работать или не работать в зависимости от профиля подключающегося пользователя. Проблема решается пересозданием профиля пользователя. Если это является слишком трудоемкой задачей можно попробовать воспользоваться советами из обсуждения: «RemoteApp Single Sign On (SSO) from a Windows 7 client» форумов Microsoft Technet. В частности, рекомендуется сбросить настройки Internet Explorer или одобрить соответствующую надстройку для него.

Еще одним серьезным ограничением технологии SSO является то, что она не работает при запуске опубликованных приложений через TS Web Access. При этом пользователь вынужден дважды вводить учетные данные: при входе на веб-интерфейс и при авторизации на терминальном сервере.

В Windows Server 2008 R2 ситуация изменилась в лучшую сторону. Более подробную информацию об этом можно получить в статье: «Introducing Web Single Sign-On for RemoteApp and Desktop Connections"».

Заключение

В статье рассмотрена технология прозрачной авторизации на терминальных серверах Single Sign-On. Её использование позволяет сократить время, затрачиваемое пользователем для входа на терминальный сервер и запуск удаленных приложений. Кроме того, с её помощью достаточно единожды вводить учетные данные при входе на локальный компьютер и затем использовать их при соединении с терминальными серверами домена. Механизм передачи учетных данных достаточно безопасен, а настройка серверной и клиентской части предельно проста.

27.12.2018

Windows Server 2012 R2, Windows Server 2016

комментариев 17

Single Sign-On (SSO — технология единого входа) это технология, позволяющая уже аутентифицированному (вошедшему в систему) пользователю получать доступ к другим сервисам без повторной аутентификации. Применительно к технологии терминальных серверов Remote Desktop Services, SSO позволяет избавить пользователя, выполнившего вход на доменном компьютере, от многократного ввода имени и пароля своей учетной записи в окне RDP клиента при подключении к RDS серверам или запуске опубликованных приложений RemoteApp.

В этой статье мы опишем особенности настройки прозрачной авторизации (Single Sign-On) пользователей на серверах RDS под управлением Windows Server 2016 и 2012 R2.

Требования к окружению:

Сервер Connection Broker и все RDS сервера должны работать под управлением Windows Server 2012 или выше;
SSO работает только в доменном окружении: должны использоваться учетные записи пользователей Active Directory, а RDS сервера и рабочие станции пользователей должны быть включены в домен;
На RDP клиентах должна использоваться версия клиента RDP 8.0 и выше (не получится установить эту версию RDP клиента в Windows XP);
На стороне клиента поддерживаются следующие версии Windows 10 / 8.1 / 7;
SSO работает с парольной аутентификацией (смарт карты не поддерживаются);
Уровень безопасности RDP (Security Layer) в настройках подключения должен быть установлен в Negotiate или SSL (TLS 1.0), а шифрование High или FIPS Compliant.

Процедура настройки Single Sign-On состоит из следующих этапов:

Необходимо выпустить и назначить SSL сертификат на серверах RD Gateway, RD Web и RD Connection Broker;
Включить Web SSO на сервере RDWeb;

Итак, в первую очередь нужно выпустить и назначить SSL сертификат. В EKU (Enhanced Key Usage) сертификата должно обязательно присутствовать идентификатор Server Authentication. Мы опускаем процедуру получения сертификата, т.к. это она выходит за рамки статьи (можно сгенерировать самоподписанный SSL сертификат, но его придется добавлять в доверенные на всех клиентах через GPO).

SSL сертификат привязывается в свойствах RDS Deployment в подразделе Certificates.

Далее на всех серверах c ролью Web Access для каталога IIS RDWeb нужно включать “Windows Authentication” и отключить анонимную проверку подлинности (Anonymous Authentication).

После сохранения изменений, IIS нужно перезапустить: iisreset /noforce

Если используется шлюз RD Gateway, убедитесь, что он не используется для подключения внутренних клиентов (должна стоять галка Bypass RD Gateway server for local address).

Следующий этап – настройка политики делегирования учетных данных. Создайте новую доменную GPO и привяжите ее к OU с пользователями (компьютерами), которым нужно разрешить SSO доступ на RDS сервера. Если вы хотите разрешить SSO для всех пользователей домена, допустимо редактировать Default Domain Policy.

Эта политика находится в разделе GPO Computer Configuration -> Administrative Templates -> System -> Credential Delegation -> Allow delegation defaults credential (Конфигурация компьютера -> Административные шаблоны -> Передача учетных данных -> Разрешить передачу учетных данных, установленных по-умолчанию). Политика разрешает определенным серверам доступ к учетным данным пользователей Windows.

Далее, чтобы избежать появления окна с предупреждением о надежности издателя удаленного приложения, нужно с помощью GPO на клиентских компьютерах добавить адрес сервера с ролью Connection Broker в доверенную зону с помощью политики «Список назначений зоны безопасности для веб-сайтов» (по аналогии со статьей Как убрать предупреждение системы безопасности при открытии файла в Windows):

User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page-> Site to Zone assignment list (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность)

Укажите FQDN имя сервера RDCB и зону 2 (Trusted sites).

Далее нужно включить политику Logon options (Параметры входа) в разделе User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security -> Trusted Sites Zone (Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность -> Зона надежных сайтов) и в выпадающем списке выбрать ‘Automatic logon with current username and password‘ (Автоматический вход в сеть с текущим именем пользователя и паролем).

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

Do you trust the publisher of this RemoteApp program?

Скопируйте значение отпечатка сертификата и добавьте его в список отпечатков политики Specify SHA1 thumbprints of certificates representing RDP publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Administrative Templates -> Windows Components -> Windows Desktop Services -> Remote Desktop Connection Client (Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Клиент подключения к удаленному рабочему столу).

На этом настройка SSO закончена, и после применения политик, пользователь должен подключатся к ферме RDS по протоколу RDP без повторного ввода пароля.

Your Windows logon credentials will be used to connect.

Чтобы использовать RD Gateway с SSO нужно для пользователей включить политику Set RD Gateway Authentication Method (User Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> RD Gateway) и установить ее значение на Use Locally Logged-On Credentials.

Для использования Web SSO на RD Web Access, обратите внимание, что рекомендуется использовать Internet Explorer с включенным Active X компонентом MsRdpClientShell (Microsoft Remote Desktop Services Web Access Control).

Единый Sign-On (SSO) позволяет пользователям выполнять проверку подлинности один раз и обращаться к нескольким ресурсам без запроса дополнительных учетных данных. В этой статье описывается поведение по умолчанию AD FS для единого входа, а также параметры конфигурации, позволяющие настроить это поведение.

Поддерживаемые типы отдельных Sign-On

AD FS поддерживает несколько типов единого Sign-Onного взаимодействия:

Единый вход сеанса

Файлы cookie единого входа сеанса записываются для пользователя, прошедшего проверку подлинности, что устраняет дальнейшие запросы, когда пользователь переключает приложения в течение определенного сеанса. Однако если определенный сеанс завершается, пользователь снова получит запрос на ввод учетных данных.

Постоянный единый вход

Файлы cookie постоянного единого входа записываются для пользователя, прошедшего проверку подлинности, что исключает дальнейшие запросы, когда пользователь переключает приложения в течение срока действия файла cookie постоянного единого входа. Различие между постоянным SSO и ВХОДом в сеансе заключается в том, что постоянный единый вход можно поддерживать в разных сеансах.

Единый вход для конкретного приложения

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

для Windows Server 2012 R2, чтобы включить пссо для сценария "оставаться в системе", необходимо установить это исправление , которое также входит в состав накопительного пакета обновления 2014 августа для Windows RT 8,1, Windows 8.1 и Windows Server 2012 R2.

Задача	PowerShell	Описание
Включить или отключить постоянный единый вход	Set-AdfsProperties –EnablePersistentSso <Boolean>	Постоянный единый вход включен по умолчанию. Если она отключена, файл cookie ПССО не записывается.
"Включить/отключить" оставаться в системе "	Set-AdfsProperties –EnableKmsi <Boolean>	Функция "оставаться в системе" отключена по умолчанию. Если он включен, конечный пользователь увидит вариант "оставаться в системе" на AD FS странице входа.

AD FS 2016-одно Sign-On и устройства с проверкой подлинности

Постоянный единый вход включен по умолчанию. Если она отключена, файл cookie ПССО не записывается. |

Окно "Использование устройства" (по умолчанию — 14 дней) регулируется свойством AD FS девицеусажевиндовиндайс.

Максимальное значение одного Sign-On периода (90 дней по умолчанию) регулируется свойством AD FS персистентссолифетимеминс.

Оставаться в системе для устройств без проверки подлинности

При отключенном функции "оставаться срок действия единого входа по умолчанию составляет 8 часов. Это можно настроить с помощью свойства Ссолифетиме. Свойство измеряется в минутах, поэтому его значение по умолчанию — 480.

При включенном параметре функции "оставаться по умолчанию используется период единого входа 24 часа. Это можно настроить с помощью свойства Кмсилифетимеминс. Свойство измеряется в минутах, поэтому его значение по умолчанию — 1440.

Поведение многофакторной проверки подлинности (MFA)

Важно отметить, что при предоставлении относительно длительных периодов единого входа AD FS будет запрашивать дополнительную проверку подлинности (многофакторную проверку подлинности), когда предыдущий вход был основан на первичных учетных данных, а для текущего входа требуется MFA. Это зависит от конфигурации единого входа. AD FS при получении запроса на проверку подлинности сначала определяет, существует ли контекст единого входа (например, файл cookie), а затем, если требуется MFA (например, если запрос поступает из-за пределов), он будет оценивать, содержит ли контекст единого входа MFA. В противном случае будет предложено указать MFA.

Отзыв ПССО

Чтобы защитить систему безопасности, AD FS будет отклонять все постоянные файлы cookie единого входа, ранее выданные при выполнении следующих условий. Для этого пользователю потребуется предоставить свои учетные данные для повторной проверки подлинности в AD FS.

Изменения пароля пользователя

Параметр постоянного единого входа отключен в AD FS

Устройство отключено администратором в случае утери или кражи

AD FS получает файл cookie постоянного единого входа, который выдается в результате "оставаться в системе", но параметр "оставаться в системе" отключен в AD FS

AD FS администратор установил время отсечки для постоянного единого входа. Если этот файл настроен, AD FS будет отклонять все хранимые файлы cookie единого входа, выданные до этого момента

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

разрешить пользователям Office 365 доступ к SharePoint в сети

После включения и настройки ПССО в AD FS AD FS будет записывать постоянный файл cookie после того, как пользователь прошел проверку подлинности. Когда пользователь поступает в следующий раз, если постоянный файл cookie по-прежнему действителен, пользователю не нужно предоставлять учетные данные для повторной проверки подлинности. кроме того, можно избежать дополнительного запроса проверки подлинности для Office 365 и SharePoint пользователей в сети, настроив следующие два правила утверждений в AD FS для активации сохраняемости в Microsoft Azure AD и SharePoint в сети. чтобы разрешить пссо пользователям Office 365 доступ к SharePoint в сети, необходимо установить это исправление , которое также входит в состав накопительного пакета обновления 2014 августа для Windows RT 8,1, Windows 8.1 и Windows Server 2012 R2.

Правило преобразования выдачи, которое пройдет через утверждение Инсидекорпоратенетворк

[x] администратор включил функцию функции "оставаться [и]
[x] пользователь щелкает флажок функции "оставаться на странице входа в формы

AD FS выдает новый маркер обновления только в том случае, если срок действия более нового маркера обновления превышает предыдущий токен. Максимальное время существования маркера составляет 84 дней, но AD FS сохраняет маркер в течение 14-дневного скользящего окна. Если маркер обновления действителен в течение 8 часов, что является обычным временем единого входа, новый маркер обновления не будет выдаваться.

Хорошая информация:
Федеративные пользователи, у которых нет синхронизированного атрибута LastPasswordChangeTimestamp , выдают файлы cookie сеанса и маркеры обновления с максимальным сроком хранения 12 часов.
Это происходит потому, что Azure AD не может определить, когда следует отозвать маркеры, связанные со старыми учетными данными (например, с измененным паролем). Поэтому Azure AD необходимо чаще проверять, чтобы убедиться в том, что пользователь и связанные с ним маркеры все еще находятся в хорошем виде.

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

Итак, наша тема – «Как реализовать Single Sign-On для веб-приложения в условиях разношёрстности и нормальной лохматости системного зоопарка».

Single Sign-On. Вводная

Доверился кому, так доверяй во всём.
© Цецилий Стаций

Для тех, кто не в курсе (хотя они вряд ли станут читать этот материал), скажу, что Single Sign-On (в дальнейшем повествовании – «SSO») в общепринятом представлении не является ни технологией, ни тем более неким магическим протоколом. SSO – это подход, метод, позволяющий реализовать связность AAA (Authentication & Authorization & Accounting) между разнородными системами и приложениями без дополнительных телодвижений со стороны конечного пользователя.

Типичными примерами SSO являются, например, решения, построенные целиком на продуктах Microsoft; в этом случае сервер(ы) Active Directory обеспечивают не только хранение каталога, но и управляют поведением подключенных к домену рабочих станций, установленным на них софтом и всем прочим, вплоть до железа (мы же все умеем запрещать политиками тот же USB). Сквозная парадигма AAA в такой ситуации обеспечивается почти автоматически при использовании продуктов Microsoft, то есть в гомогенной среде.

В качестве примеров:

Два из трёх вышеперечисленных пункта не имеют никакого отношения к SSO .

Аксиома

Задача

На входе мы имеем:

Веб-приложение, построенное на платформе InterSystems.
Линуксовые серверы, на котором оно крутится. Серверы расположены в интранете Заказчика.
Развитая Microsoft-инфраструктура Заказчика, в том числе и весьма неплохо настроенные групповые политики на грамотном лесе доменов и связке контроллеров.
Уважаемый Заказчик, сказавший ключевые фразы «Надо!» и «Чтобы было готово вчера!».
И, к счастью, полноценный тестовый сервер, так что нам есть где развернуться!

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

Танцуем с Пингвинами. Linux

Домен: Эукариоты, Царство: Животные, Подцарство: Эуметазои, Тип: Хордовые, Подтип: Позвоночные, Инфратип: Челюстноротые, Надкласс: Четвероногие, Класс: Птицы, Подкласс: Новонёбные, Отряд: Пингвинообразные, Семейство: Пингвиновые, Вид: Oracle Linux Server release 7.2

Установка

Нам достался вполне оперившийся потомок/клон RHEL под именем Oracle Linux Server release 7.2.

Настройка

Как всегда, Линукс в его серверном виде прост, беззаботен и безотказен, но нам важно убедиться, что он правильно сконфигурирован, особенно в части сетевых настроек.

Тестирование

Сначала смотрим на настройки DNS, т.к. это критично для работоспособности всего решения:

На этом этапе необходимо проверить доступность серверов DNS (которые, в нашем случае, являются и домен-контроллерами). Сделать это можно по-разному, просто используйте свои любимые утилиты и методы проверки (host, dig, telnet, ping, …). Важно, чтобы нужные нам порты были доступны и работоспособны, а в случае DNS это в первую очередь TCP/53. И не забываем про кощунство и жадность сетевых администраторов и безопасников (я сам такой), которые могут закрыть вам всё, включая ICMP, и оставить только парочку затребованных и согласованных портов. Что есть правильно.

Собачий вальс. Kerberos

Це́рбер, также Ке́рбер (от др.-греч. Κέρβερος, лат. Cerberus) — в греческой мифологии порождение Тифона и Ехидны (Тартара и Геи), трёхголовый пёс, у которого из пастей течёт ядовитая смесь. Цербер охранял выход из царства мёртвых Аида, не позволяя умершим возвращаться в мир живых. Однако это удивительное по силе существо было побеждено Гераклом в одном из его подвигов.

Уверен, что не нужно напоминать про необходимость правильной настройки Kerberos для «плодотворного сотрудничества» с MSAD.

Разумеется, для установки и конфигурирования вам необходимы root'овые права на сервере. Или sudo. Или «Звоните Солу».

Установка

Установка и настройка необходимых пакетов производится довольно просто, если «злые сетевые админы» дали вашему серверу выход в Интернет.

К сожалению, Интернет с доступом к репозиториям нужен на этапе установки, если добрые админы не установили всё нужное заблаговременно.

И всё печально, если нет ни доступа, ни установленных пакетов.

Однако будем оптимистами и, считая, что админы хотя бы на часик открыли канал, выполняем установку:

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

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

Настройка

Вполне работающий файл конфигурации Kerberos изначально будет выглядеть примерно так:

Тестирование

На следующем шаге у нас, как правило, всё происходит очень просто.
Просто убеждаемся, что всё плохо:

Зовём специалистов по трёхголовым собачкам (AKA сисадмина, знающего сверхсекретный доменный админский логин/пароль), и просим его ввести его примерно вот так:

После этого klist должен вернуть уже что-то осмысленное.
Засим нашу собачку считаем готовой, хотя…

Танец Великих Равнин. Apache

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

Начинаем охотиться вместе с индейцами племён Апачи.

Установка

Как и прежде, пакеты – это наше всё (за исключением всемогущих шаманов-Админов, разумеется):

Настройка

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

И дадим “пиночек под задочек”:

Убедимся, что он научился разговаривать по-нашенски, зайдя в System Management Portal.

Апачи некогда были гордым и независимым народом, у них это в крови, поэтому со всем уважением и вежливостью попросим Apache браться за работу вместе с нашим Пингвином-Прорицателем:

Прослушавши “Пионерскую Зорьку”, сделав водные процедуры, выгулявши трёхглавую собачку и причесав индейца, переходим к “Производственной Гимнастике”, которая сегодня будет танцевальной (и даже с бубнами).

Танцуем Самбу!

Са́мба (порт. samba) — бразильский танец, символ национальной идентичности бразильцев. Танец обрёл мировую известность благодаря бразильским карнавалам. Одна из разновидностей самбы вошла в обязательную пятёрку латиноамериканской программы бальных танцев. Исполняется в темпе 50-52 удара в минуту, в размере 2/4 или 4/4.

Как всем нам прекрасно известно, наша любимая Samba в серверном варианте совершенно логично разделена на три основных исполняемых модуля: (smb|nmb|winbind)d.

Теоретически нам нужен только работоспособный winbindd. Да, это всего лишь один из демонов Самбы. Но он, установленный отдельно от всего пакета, почему-то на имеющейся платформе работать не захотел, а разбираться в причинах его недовольства не захотелось уже мне.

Поэтому устанавливаемся по полной.

Установка

Процедура очень проста, особенно, если ваш(а) Админ(ша) танцует вместе с вами.

Костюмчик готов, затягиваем галстук:

Настройка

Мало прийти на карнавал, нужно ещё и немного потанцевать (уже с бубнами):

Репетируем первые шаги (разумеется, ошибаемся на первых порах):

Зовём на помощь учителей танца, и («Как много нам открытий чудных. ») это оказываются те же самые кинологи, помогавшие нам в приручении нашего трёхглавого щеночка!

И надеемся на чудо… Всё зависит от рук и от места, откуда они растут…

"Разлук так много на земле.
И разных судеб,
Надежду дарит на заре.
Паромщик людям”
© Prodigy & Rammstein, 2048

Если затем видим примерно вот такое:

то Счастье уже почти Есть!

Тестирование

Проверяем его (Счастья) наличие:

Медляк. mod_auth_ntlm_winbind

Прежде чем танцевать медленный танец, придется кого-то на него пригласить, ведь в одиночку под него двигаться не считается приемлемым. Улучите момент и подойдите к приглянувшейся девушке. Собравшись танцевать медленный танец, объявите о своем намерении потенциальной партнерше прямо, без ненужного многословия. Не будьте излишне развязны и напористы, оставьте за ней решение, согласиться или нет. В последнем случае она откажется, но поблагодарит вас.

Установка

Найдите в Сети живой репозиторий с mod_auth_ntlm_winbind.
Да, их мало живых (я забрал с какого-то svn).
Да, версии совсем не новые.
Да, вам нужно будет их собрать «вручную».
Да, не все соберутся.
Да, даже после патчей и правок вручную.
Да, для сборки понадобится полностью настроенное окружение (gcc + glib + apxs + headers + *-dev + …).
И ДА, это – единственный известный мне вариант, который работает стабильно.

Настройка

С настройкой всё более-менее элементарно, добавьте в ваш конфиг-файл Apache (в основной, либо в conf.d/xyz.conf, по желанию):

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

Белый танец. Кто кого.

Бочка мёда

пользователь, успешно залогинившись в Windows под своим доменным аккаунтом,
пройдя все проверки в MSAD,
зашёл затем веб-браузером в приложение, разработанное на одном из продуктов InterSystems,
установленном на Linux-сервере, который тоже включен в домен,
на котором установлен и настроен веб-сервер Apache с нужным модулем,
вернул нам имя доменного аккаунта пользователя (sAMAccountName).

И мы его получаем!

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

Парочка ложек дёгтя

Пока только браузеры от MS (IE, Edge) нативно работают с NTLM (а мы используем именно NTML). Впрочем, и в FireFox, и в Chrome есть возможность донастройки, более того, в корпоративной среде возможна как их централизованная настройка, так и дистрибуция преднастроенных пакетов средствами групповых политик.
Не всем сразу становится понятно, что же делать с полученным REMOTE_USER на стороне InterSystems Caché. Единого мнения на сей счёт пока нет, а вариантов много самых разнообразных, начиная от задания всем пользователям одного сверхсекретного пароля с последующим вызовом %session.Login() и до создания своей пользовательско-ролевой модели безопасности. Есть тема для дискуссии!

Single Sign-On. Выводная

Я буду весьма признателен, если подскажете в комментариях более удачную конфигурацию; допускаю даже, что появилась новая механика взаимодействия AAA для связки Linux + Apache + MSAD, про которую я не знаю.

В данной инструкции описывается настройка аутентификации пользователей на веб-прокси через протокол Kerberos.

Данный функционал особенно актуален в доменной среде Active Directory (AD), где данная технология позволяет реализовать аутентификацию в стиле Single Sign On (SSO).

SSO-аутентификация избавляет доменного пользователя от повторных запросов на прохождение аутентификации. Пользователь вводит доменный логин / пароль всего один раз - при логоне в операционную систему. При последующем обращении в Интернет через прокси-сервер, аутентификация происходит прозрачно и автоматически.

Настройка SSO аутентификации в Active Directory состоит из нескольких этапов:

Для дальнейшей настроки примем следующие значения:

домен Active Directory

контроллер домена Active Directory

dc.ztest.int (Windows Server 2016)

IP адрес контроллера домена Active Directory

имя устройства TING

IP адрес устройства TING

Установка, настройка контроллера домена, а также разворачивание домена Active Directory должна осуществляться компетентными специалистами согласно документации. Мы предполагаем, что такая настройка уже выполнена согласно предоставленных выше данных.

Настройка домена Active Directory.¶

Создайте на доменном DNS-сервере нужные ресурсные записи для узла TING.

ting IN A 192.168.0.2 в прямой зоне ting.local 2.1.168.192.in-addr.arpa IN PTR ting.ztest.int. в обратной зоне 1.168.192.in-addr.arpa

Проверьте правильность введенных данных, выполнив следующие команды в терминале Windows:

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

Задайте даной учетной записи пароль и установите флажок Срок действия пароля неограничен.

Примечание

Данная учетная запись нам понадобится для настройки LDAP коннектора на устройстве TING.

Настройка устройства TING.¶

1. Настройка имени устройства и DNS¶

Установить флаг Не используйте локальную службу DNS в качестве сервера имен для этой системы
В поле DNS-серверы прописать IP адрес контроллера домена ( 192.168.1.3 )

2. Настройка сетевого времени¶

Перейдите в раздел Службы -> Сетевое время -> Общие.

В поле Серверы времени укажите имя контроллера домена dc.ztest.int либо IP адрес контроллера домена 192.168.1.3 .

Примечание

Время на контроллере домена и устройстве TING должно быть синхронизированно.

3. Настройка LDAP коннектора¶

Пройдите в раздел Система -> Доступ -> Серверы, в правом верхнем углу нажмите на кнопку Добавить сервер и задайте следующие настройки:

Описательное имя	INT-DC
Тип	LDAP
Имя хоста или IP-адрес	192.168.1.3
Значение порта	389
Транспортный протокол	TCP
Версия протокола	3
Привязать параметры доступа	имя и пароль 1
Область поиска	Единичный уровень
Базовый DN	DC=ztest,DC=int
Контейнеры для аутентификации	CN=Users,DC=ztest,DC=int 2
Начальный шаблон	Microsoft AD
Атрибут присвоения имени пользователю	sAMAccountName

имя и пароль учетной записи, созданной при настроке домена для создания LDAP коннектора.

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

4. Проверка LDAP коннектора¶

5. Настройки веб-прокси¶

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Основные настройки прокси, установите флаг Включить прокси, если он еще не установлен.

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Перенаправляющий прокси -> Настройка Аутентификации, в поле Метод аутентификации укажите ваш настроенный LDAP-коннектор.

6. Установка плагина os-proxy-sso¶

Пройдите в раздел Система -> Прошивка -> Обновления. На вкладке Плагины нажмите на кнопку + напротив плагина os-proxy-sso для его установки.

После установки плагина os-proxy-sso, в разделе Службы -> Веб-прокси появляется подраздел Технология единого входа (SSO).

Настройка аутентификации по протоколу Kerberos может быть осуществлена как вручную, так и автоматически. Предпочтительным является автоматический способ настройки, рассмотренный в п.7. Ручной способ настройки аутентификации по протоколу Kerberos рассматривается в п.8.

7. Автоматическая настройка аутентификации по протоколу Kerberos¶

7.1 Включите Single Sign On

В разделе Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладке Общие настройки, установите флаг Включить единый вход для прокси-сервера.

При необходимости вы можете включить/выключить использование Basic аутентификации, установив/сняв соответствующий флажок Basic Autentification 3

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

Если вы отключите Basic аутентификацию, то пользователи, чьи компьютеры не входят в домен, не будут обслуживаться прокси-сервером.

В поле Реализация AD Kerberos выберите значение Windows 2008 with AES.

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

происходит автогенерация конфигурационного файла krb5.conf для библиотеки Kerberos

модифицируется конфигурационный файл Squid /usr/local/sbin/squid.conf для загрузки хелпера Kerberos-аутентификации negotiate_kerberos_auth

производится перезапуск веб-прокси сервера Squid

7.2 Настройте аутентификацию по протоколу Kerberos

Перейдите в раздел Службы -> Веб-прокси -> Технология единого входа (SSO) -> Аутентификация по протоколу Kerberos и нажмите кнопку Обновить

Все пункты, кроме Файл keytab должны быть отмечены зеленым.

Если это не так - перепроверьте все шаги.

Создайте учетную запись компьютера с необходимыми SPN в Active Directory:

В поле Имя администратора AD, укажите имя учетной записи администратора домена.

В поле Пароль администратора AD, укажите пароль для учетной записи администратора домена.

Нажмите на кнопку Создать keytab-файл.

создается учетная запись компьютера с именем, указанным на закладке Общие
прописываются необходимые SPN-имена
генерируется keytab-файл /usr/local/etc/squid/squid.keytab на устройстве TING c SPN-именами / ключами для керберизированной службы

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

Все пункты должны быть отмечены зеленым.

Если это не так - перепроверьте все шаги.

Результат должен быть такой:

7.3 Проверьте правильность настроек.

Для этого введите Имя пользователя и Пароль пользователя домена в соответствующие поля и нажмите Проверить вход через Kerberos

В случае, если все настройки были сделаны верно, вы увидите положительный результат проверки, подобный, как на изображении выше.

7.4 Примените настройки.

Для этого либо в разделе Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладке Общие настройки, либо в разделе Службы->Веб-прокси->Администрирование нажмите кнопку Применить

8. Ручная настройка аутентификации в Active Directory через Kerberos¶

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

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

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

После чего выполнить следующие шаги:

8.1. Пройдите в раздел Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладку Аутентификация по протоколу Kerberos, нажмите кнопку Обновить - и убедитесь, что все пункты, за исключением Файл keytab отмечены зеленым. Если это не так, то необходимо проверить настройки.

8.2. Создайте в домене учетную запись компьютера с именем, совпадающим в поле Kerberos-аккаунт этой машины в AD на вкладке Службы -> Веб-прокси -> Технология единого входа (SSO) -> Общие настройки

Примечание

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

Читайте также: