Ubuntu single sign on что это

Обновлено: 01.07.2024

OTRS: Установка на Ubuntu, аутентификация в Active Directory и Single sign on

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

Требования

Для начала определимся с требованиями. Допустим у нас уже есть центральный сервер, с развернутой на нём службой каталогов (Active Directory). Необходимо сделать так, чтобы пользователи могли авторизовываться в системе, создавать заявки, а технические специалисты отвечать на них и собственно выполнять. Для этих целей поставим виртуальную машину и развернём на ней OTRS.

Установка OTRS

В начале своих изысканий я наткнулся на такую замечательную вещь, как OTRS Appliance. Это готовый ISO-образ (скачать версию 3.3.7), который можно подключить к виртуальной машине как CD-ROM и автоматически установить OTRS. Это вселяло надежду на скорое решение проблемы, но моя радость была бы не полной. если бы не некоторые грабли. В частности часть системы вынесена в отдельный RAM диск и после установки пакетов (например mc) они живут ровно до перезагрузки. Естественно это было неприемлемо и я решил установить OTRS вручную на чистую Ubuntu 14.04.

Качаем исходники и распаковываем их в каталог /opt/otrs-3.3.7

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

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

Создаём пользователя для Otrs

Если файлов конфигов (не .dist а именно .pm) нет, то копируем их из файлов дистрибьютива:

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

Дальше создаём vhost для Апача (который у нас должен уже стоять кстати):

У меня он получился в результате вот такой (я не менял его).

Теперь включаем этот vhost. Эта команда создаёт симлинк в папке sites-enable. После этого можем перезагрузить апач.

Настройка авторизации пользователей в Active Directory

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

Требования к аккаунтам
У пользователей в AD должно быть заполнено поля с информацией об имени (Имя. Фамилия, Отчество (инициал) и email). Без этого они не пройдёт аутентификацию.

на CustomerPanelCreateAccount указываем «Нет» и жмем внизу кнопку «Обновить».

Сквозная авторизация (SSO)

Для работы в OTRS пользователь должен быть авторизован, т.е. системе должен быть известен ID пользователя. Обычно таким ID выступает логин. Стандартно пользователю предлагается ввести логин и пароль в форме авторизации. Используя Authentication backends, OTRS может выполнить авторизацию пользователя.

Если предположить, что при открытии страницы OTRS пользователь уже известен, то повторно запрашивать авторизацию не надо. Т.к. в моем случае все пользователи уже авторизованы в домене Windows, логично это как-то использовать. Таким образом, нужно данные авторизации передать в OTRS.

Алгоритм авторизации

1. Пользователь включает компьютер, авторизуется в домене с помощью Kerberos. В Kerberos контроллер домена именуется центром распространения ключей Key Distribution Center (KDC). На высоком уровне это выглядит так: при регистрации пользователя на компьютере формируется серия обменов данными с контроллером домена (DC), и в случае успеха пользователю назначается билет на право получения билетов (TGT). Впоследствии при каждом обращении к службе, такой как общая папка или приложение, TGT используется, чтобы получить билет для доступа к службе или приложению.
2. С TGT пользователь обращается браузером (тестировалось под Internet Explorer) к веб-серверу (Apache2). Для того, чтобы бразер отдавал веб-серверу TGT нужно сделать соответствующую настройку клиента.

3. Там модуль Апача mod_auth_kerb получает от браузера билет TGT и обращается с ним к KDC (он же контроллер домена). При этом сам хост с апачем должен быть введен в домен и на быть принципиалом Kerberos чтобы осуществить это обращение.

Чтобы работал этот этап нужно сделать две вещи. Во-первых в дефолтном конфиге vhost-а для otrs разрешить использовать файлы .htaccess вот так (зменить None на All):

и собственно разместить файл .htaccess

/opt/otrs/bin/cgi-bin/.htaccess

6. Пользователь видит панель OTRS в залогиненном виде. Если в переменной окружения нет имени пользователя, то всплывает окно авторищации, в котором пользователь вводит свой логин и пароль.

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

Готовим систему

Ставим пакеты для Kerberos и Samba

/etc/hostname
Прописываем имя машины. Желательно капсом. Так точно работает.

/etc/resolv.conf

Конфиги для LDAP-Auth + SSO

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

/etc/krb5.conf

Теперь настраиваем .htaccess
/opt/otrs/bin/cgi-bin/.htaccess
/opt/otrs/bin/cgi-bin/.htaccess

Отлично, теперь вводим веб-сервер в домен.
Во-первых создаём юзера helpdesk в Active Directory.

Далее собственно вводим в домен сервер.

Далее после загрузки сервер должен выдавать нам данные о домена при следующих запросах:

Запрос службы RPC

Идём на контроллер домена и генерируем там файл krb5.keytab

Потом на веб-сервере кладём его в /etc/krb5.keytab и даём права апачу читать его

Далее настраиваем OTRS на то, чтобы пользователи (Customers) могли авторизовываться автоматически.

/opt/otrs/Kernel/Config.pm

И добавляем файл адаптера авторизации.

Чтобы было понятнее, вот сам фикс:

Теперь авторизация для клиентов должна работать успешно.

Установка задания Cron

Настройка кодировки отображения имён пользователей

У меня после установке и логине юзеров в тикетах их имена отображались неправильно (вместо них были иероглифы). Помогло следующее решение. В конфиге добавляем параметры:

Важные детали

1 Должна быть создана учётка helpdesk на AD
2. Открывать Otrs надо по символическому а не по IP адресу
3. На KDC должен быть сгенерирован keytab файл и скопирован на веб-сервер
4. wbinfo -u должен выдавать список юзеров, веб-сервер должен быть в домене

Тормозит OTRS

Администрирование -> Конфигурирование системы -> Framework:Core -> CheckMXRecord = Нет
Включает проверку MX record почтовых адресов клиента до отправки почты или приема почтовой или телефонной заявки.

Ссылки

Спасибо!

Если вам помогла статья, или вы хотите поддержать мои исследования и блог - вот лучший способ сделать это:

Андрей Токарчук :

Выполнил все как у вас в инструкции но при входе на Customer.pl выдает в логах апача ошибку в файлы adsso 39 строка на функцию no logobject
В чом может быть проблема?
Стоит ubuntu 14

Андрей Токарчук :

Кто помнит, я на своем блоге показывал как настроить технологию SSO (Single Sing-on) применительно в доменной структуре для авторизации пользователей на терминальном сервере через доменную аутентификацию без какого-либо запроса ввода связки логин&пароль со стороны пользователя при подключении к терминальному серверу. Это было замечательно сделано и воплощено на одной из работ.

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

Домен контроллер на базе Windows Server 2016 (srv-dc.polygon.local) 192.168.2.2
Mikrotik в роли шлюза (192.168.2.1)
Ubuntu 14.04.5 Server amd64 с ролью LAMP (srv-trusty.polygon.local) 192.168.2.100

Система Ubuntu 14.04 с обновленным ядром поставленным по заметке.
На домен контроллере в оснастке DNS созданы A записи: srv-gw.polygon.local & srv-trusty.polygon.local
Начинаю.

Шаг №1: Действия на домен контроллере.

Авторизуюсь на домен контроллере с правами группу «Администраторы домена» и создаю специального пользователя, для эксперимента делать это я буду через консоль командной строки, но Вы можете через GUI-оснастку «Пользователи и компьютеры Active Directory»:

C:\Windows\system32>dsadd user "cn=webserver,ou=it,dc=polygon,dc=local" -pwd Aa1234567 -mustchpwd no -canchpwd no -pwdneverexpires yes -UPN webserver@polygon.local

Для пояснения указанных параметров:

Если посмотреть в оснастке «Пользователи и компьютеры Active Directory» на свойства учетной записи webserver вкладка «Учетная запись» можно будет видеть, что для этой учетной записи создан keytab файл который будет использоваться с системы srv-trusty.polygon.local

Затем передаем данный keytab файл на систему srv-trusty.polygon.local такими способами которыми можно из Windows системы достучаться (к примеру: WinSCP клиент и т. д.) до Ubuntu системы или наоборот:

Технология единого входа (англ. Single Sign-On) - это механизм, позволяющий пользователю пройти аутентификацию (вход со своими учетными данными) единовременно и получить доступ к различным программным продуктам, используя один идентификатор.

Таким образом ключевым моментом здесь является то, что пользователю требуется войти в систему для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу. [Источник 1]

Содержание

Общая схема систем единого входа

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

Информация, предоставленная конечным пользователем в рамках процедуры входа в первичный домен, может использоваться для поддержки входа во вторичный домен несколькими способами:

Напрямую: информация, предоставленная пользователем, передается на вторичный домен в качестве составной части данных при входе во вторичную систему.
Косвенно: информация, предоставленная пользователем, используется для извлечения других идентификационных и аутентификационных данных пользователя, хранящихся в базе управляющей информации технологии единого входа. Извлечённая информация затем используется как основа для операции входа во вторичный домен.
Немедленно: для установления сеанса со вторичным доменом как составной части установления первоначального сеанса. Это означает, что во время выполнения операции первичного входа автоматически вызываются клиенты приложений и устанавливаются необходимые соединения.
В отложенном режиме: информация временно сохраняется или кэшируется, используется по мере необходимости во время выполнения конечным пользователем запроса к сервисам вторичного домена. [Источник 2]

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

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

Вторичные домены должны доверять первичному в том, что он:

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

При передаче между первичным доменом и вторичными доменами аутентификационные данные должны защищаться от перехвата или прослушивания, поскольку это может привести к атакам, при которых злоумышленник будет выдавать себя за реального пользователя. [Источник 3]

Основные достоинства и недостатки SSO

Достоинства	Потенциальные недостатки
Снижение времени, требуемого для повторного ввода паролей;	Попытка первоначальной реализации может быть сложной, в зависимости от количества существующих не сопоставимых систем
Снижение количества паролей, необходимых для различных программных продуктов;	Скомпромитированные входные данные (credentials) пользователя могут привести к доступу к большому числу приложений
Снижение нагрузки на сеть, связанной с многократными процедурами аутентификации;	Производитель либо не использует существующий открытый стандарт, либо использует стандарты, несовместимые со стандартами, используемыми другими приложениями.
Снижении стоимости IT-системы за счет снижения количества инцидентов ИБ, связанных с учетными данными пользователей;	Данный механизм требует установки специальных агентов, поддерживаются не все устройства и операционные системы.

Методы SSO

Технология единого входа включает в себя следующие методы:

Single Sign-On — метод, позволяющий пользователю получить доступ ко многим ресурсам, выполнив авторизацию в одном из них.
Single Sign-Off (Signle Log Out) — обратный метод, прекращающий доступ пользователя к ресурсам после выполнения выхода из одного из ресурсов.
Just-In-Time Provisioning — создание учетной записи, если она отсутствует в целевом приложении.

Основные преимущества SSO

Преимущества для конечных пользователей	Преимущества для администратора безопасности
Необходимо хранить в памяти только один механизм аутентификации. Для аутентификации на основе пароля это означает, что пользователям надо помнить только один пароль	Запись регистрационных данных пользователя в одном месте для управления и обеспечения безопасности.
При употреблении паролей пользователи должны изменять только один пароль и следовать только одному набору правил паролирования.	Возможность ведения общих для организации политик паролирования и обеспечения безопасности, позволяющих обеспечить "сквозную" безопасность, возможно в рамках приложений и систем. Это позволит избежать проблем с несоответствием требований по сложности паролей и периодам их смены в различных системах.
Единственный вход для каждого пользователя в домене SSO, обычно только один раз в день.	Проще контролировать информацию о правах доступа пользователя (user security information) и при необходимости корректировать ее, чем при отслеживании всех отдельных систем, к которым имеет доступ пользователь. Это особенно важно, когда пользователям назначают роли с другими уровнями доступа.

Протоколы, обеспечивающие технологию единого входа

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

Протоколы семейства WS-Security (WS-Trust [LK07], WS-Federation[KM09]);
Протокол SAML
Протокол OpenID
Протокол OAuth
Протокол Kerberos [KN93]

Протоколы семейства WS-

С учетом требований, описанных в спецификации WS-Federation Passive Requestor Profile, протоколом поддерживаются следующие форматы маркеров безопасности:

Сертификат X.509;
Билет Kerberos;
XrML–токен;
SAML-токен.

Протокол SAML

SAML (англ. security assertion markup language — язык разметки декларации безопасности) — язык разметки, основанный на языке XML. Открытый стандарт обмена данными аутентификации и авторизации между участниками, в частности, между поставщиком учётных записей (англ. identity provider) и поставщиком сервиса (англ. service provider). SAML — продукт OASIS, разработанный Техническим комитетом безопасности сервиcов. SAML создан в 2001 году; последнее значимое обновление SAML было опубликовано в 2005 году, но расширения протокола постоянно выпускались через дополнительные, опциональные стандарты.

Протокол OpenID

OpenID — открытый стандарт децентрализованной системы аутентификации, предоставляющей пользователю возможность создать единую учётную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов, используя услуги третьих лиц.

Идентификатор OpenID
Клиент OpenID (ЦП)
Провайдер OpenID (ЦИ)

Идентификатор OpenID – это строка, которая является уникальной для каждого пользователя. Один идентификатор не может принадлежать более чем одному пользователю. Различают следующие два вида идентификаторов:

Идентификатор, предъявленный пользователем;
Заявленный идентификатор – преобразованная строка, которая была получена Целевое Приложение от пользователя, необходимая для нахождения Центра Идентификации (этот процесс называется "обнаружением провайдера"), который должен будет провести процедуру аутентификации.

Клиент OpenID (ЦП) – онлайн – ресурс (чаще всего веб-сайт, но им также может быть файл, изображение или любой ресурс, к которому необходимо контролировать доступ), который использует OpenID для идентификации обращающихся к нему пользователя.

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

Схема протокола выглядит следующим образом:

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

Протокол OAuth

Клиентский браузер, с помощью которого пользователь (владелец защищенных ресурсов), способен делегировать приложению (третьей стороне) доступ к ним;
Приложение – сторона, которая пытается получить доступ к ресурсам от имени их владельца;
Провайдер – объединение двух компонентов модели CBA: сервер, на котором хранятся ресурсы (ЦП), и сервер, на котором происходит процесс авторизации и выпуск токенов (ЦИ).

Схема протокола имеет следующий вид:

Приложение запрашивает временный токен необходимый для инициации процесса авторизации по протоколу OAuth;
После проверки приложения провайдер выпускает токен, действительный в течение небольшого промежутка времени;
Получив временный токен, приложение перенаправляет пользователя по OAuth User Authorization URL для прохождения процесса аутентификации.
Если пользователь доверяет приложению (временный токен получен), то он предоставляет свои идентификационные данные провайдеру.
В случае успешной аутентификации клиента браузер перенаправляется на страницу приложения.
Приложение запрашивает у провайдера токен, необходимый для получения доступа к ресурсам (запрос должен содержать временный токен, выпущенный на шаге 2)
Если проверка прошла успешно, провайдер выпускает токен, необходимый для доступа к защищенным ресурсам.
Приложение предоставляет токен провайдеру для получения доступа к ресурсам от имени клиента.
Провайдер проверяет каждый входящий запрос и если приложение авторизовано (токен действителен) предоставляет доступ к защищенным ресурсам.

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

Продолжая тему интеграции систем на базе Linux в доменную инфраструктуру Active Directory (AD), в этой заметке мы рассмотрим вопрос настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows. Начнём с настроек на стороне Linux-сервера, который будет выступать в качестве сервера SSH на базе пакета OpenSSH (описание установки и базовой настройки рассмотрено ранее ).

Для начала включим поддержку GSSAPI для службы сервера OpenSSH и пропишем ограничение по группам доступа:

Фрагмент изменённых и добавленных строк конфигурационного файла:

Разрешённые группы нужно указывать через пробел. В списке могут фигурировать как локальные (для локальных пользователей) так и доменные (для доменных пользователей) группы доступа, при этом их названия должны быть указаны в нижнем регистре, так как их возвращает команда groups для текущего пользователя.

Для вступления изменений в силу перезапускаем службу сервера SSH:

Теперь нам нужно реализовать возможность для Kerberos-подсистемы представляться разным службам от имени принципала (SPN) HOST/@ .
Посмотрим что возвращает команда:

Как видно, мы получаем список ключей, которые хранятся в keytab-файле указанном в параметре default_keytab_name конфигурационного файла /etc/krb5.conf , который мы задали ранее конфигурируя систему для Squid. Однако в силу того, что дополнительно мы создавали файл /etc/default/squid3 где прописали путь к keytab-файлу необходимому для Squid, мы смело можем отключить параметр default_keytab_name конфигурационного файла /etc/krb5.conf ,
чтобы в системе по умолчанию использовался файл /etc/krb5.keytab . Итак, отредактируем файл krb5.conf :

Закомментируем в нём ранее записанную нами строку:

Добавляем в дефолтный keytab-файл ( /etc/krb5.keytab ) записи типа HOST/* с помощью команды:

что в нашем случае будет выглядеть как:

Отредактируем конфигурационный файл Samba4:

Добавим в него строчку:

Снова выполним команду вывода списка доступных SPN и убедимся в том, что выводятся данные файла /etc/krb5.keytab и в них есть записи вида HOST/@

В категории настроек Connection > Data включаем опцию Use system username, чтобы использовалось имя текущего пользователя Windows (будет указано в скобках):

В категории настроек Connection > Auth > GSSAPI включаем опции Attempt GSSAPI… и Allow GSSAPI…

Пробуем выполнить подключение кнопкой Open.

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

Как видим на скриншоте, пользователь Петя Резинкин (доменный логин petya ), включенный в доменную группу безопасности KOM-SRV-Linux-Administrators успешно вошёл в систему без ввода пароля. В процессе первого входа для пользователя был успешно создан домашний каталог. Пользователь смог выполнить команду с повышением прав через sudo.

В случае если подключиться через SSН с помощью PuTTY без явного указания пароля не получается (выходит предложение ввести пароль) включаем расширенное логирование в конфигурационном файле sshd_config

Фрагмент файла отвечающий за функции логирования:

После сохранения файла перезапускаем службу сервера SSH и запускаем наблюдение за системным логом аутентификации:

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