Данное руководство предназначено для случая, когда уже есть настроенный сервер с установленной OTRS. Подробное руководство об установке OTRS v4 в Windows-среде можно прочитать в здесь .
Прежде чем интегрировать OTRS с Active Directory, нужно определиться с учетными записями и их ролью. Нам понадобятся следующие учетные записи:
В качестве аналога в Active Directory для учетной записи root@localhost будем использовать учетную запись “Admin OTRS” с логином “root”.
В оснастке Active Directory Users and Computers создадим нового пользователя.
При создании учетной записи не забываем снять галочку «Требовать смены пароля при следующем входе в систему».
Предполагаем, что учетные записи для специалиста службы технической поддержки и для пользователя уже существуют. Если нет – создаем их по аналогии.
ВАЖНО: у всех пользователей должен существовать адрес электронной почты. Это обязательное условие для всех пользователей OTRS.
В данном примере все специалисты технической поддержки, которые будут работать в OTRS, будут членами группы OTRSagents. Это важный момент при разграничении прав доступа в системе.
Создаем группу OTRSagents в оснастке Active Directory Users and Computers. Область действия группы – Глобальная. Тип группы – Безопасность. Делаем членами группы ранее созданную учетную запись администратора OTRS (с логином root) и нужных специалистов технической поддержки.
Также важно иметь учетную запись с правами пользователя, которая будет использоваться системой OTRS для чтения каталога Active Directory. Для удобства срок действия пароля данной учетной записи должен быть не ограничен.
Переходим по ссылке http://localhost/otrs/index.pl и авторизуемся под учетной записью root@localhost.
Далее переходим на вкладку Администрирование, Управление агентами, Агенты.
Выбираем учетную запись root@localhost.
Вносим изменения. Важно помнить, что логин и пароль от данной учетной записи должны совпадать с логином и паролем учетной записи Admin OTRS (логин root), созданной нами в Active Directory.
Меняем логин root@localhost на root, соответственно меняем пароль. Устанавливаем адрес электронной почты в поле Email (в данном примере testdomain, помимо прочего, выполняет роль почтового сервера). Нажимаем кнопку Отправить.
Последний шаг – редактирование файла c:\otrs\Kernel\Config.pm.
В данном примере:
Приведенную ниже конфигурацию вставляем после строки «insert your own config settings «here»».
Сохраняем изменения в файл, перезапускаем службу Apache. Если есть проблемы, то служба не стартанет. Читаем логи (c:\otrs\var\log) и исправляем ошибки.
Переходим по ссылке http://localhost/otrs/index.pl для агента. Не забываем проверить и учетную запись root. Также переходим по ссылке http://localhost/otrs/customer.pl, заходим под учетной записью простого пользователя.
Все работает! Настройка интеграции OTRS с активным деревом завершена.
Для аутентификации Апачу необходим так называемый keytab. Чтобы его сгенерировать, необходим протокол (HTTP), полное доменное имя OTRS-сервера и имя домена. Название протокола и имя домена должны быть в верхнем регистре. Также необходим обычный пользователь домена.
В командной строке на контроллере домена выполняем следующее:
На выходе в корне диска С получаем файл. Позже я переименовал файл из helpdesksrv.keytab в apache.keytab и положил в папку c:\Apache2\conf\ (имя файла роли не играет).
Качаем MIT Kerberos и устанавливаем.
Установка простая, без каких-либо особенностей.
Создаем пустой файл c:\Program Files (x86)\MIT\Kerberos\krb.ini и заполняем его, соблюдаем регистр как в примере. Здесь TESTDC1 — имя контроллера домена.
Качаем mod_auth_kerb.so для Apache 2.2.*, копируем его в папку c:\Apache2\modules.
Модифицируем файл c:\Apache2\conf\httpd.conf. Добавляем следующие строки и перезагружаемся:
Редактируем файл c:\otrs\Kernel\Config.pm, добавляем строки:
Перезапускаем службу Apache. Проверяем http://helpdesksrv/otrs/customer.pl. Нас перенаправит, строка в адресной строке браузера изменится на http://helpdesksrv/otrs/customer.pl?Action=CustomerTicketOverview;Subaction=MyTickets.
Создаем заявку через вэб-интерфейс пользователем. Заходим в интерфейс агента и видим, что имя пользователя в заявке отображается некорректно.
Видимо, вставка параметра
в файле c:\otrs\Kernel\Config.pm проходит некорректно.
Модифицируем файл c:\otrs\Kernel\cpan-lib\Apache\DBI.pm, добавляем строки:
Перезапускаем службу Apache.
Теперь имя пользователя отображается корректно.
На этом все. Надеюсь, что мой опыт будет Вам полезен.
Часть 1. Настройка LDAP-аутентификации.
Прежде чем интегрировать OTRS с Active Directory, нужно определиться с учетными записями и их ролью. Нам понадобятся следующие учетные записи:
- агент – специалист службы технической поддержки;
- root-пользователь (очень важный момент – логин и пароль учетной записи root-пользователя должны совпадать с логином и паролем учетной записи администратора в OTRS);
- собственно, пользователь OTRS, который будет обращаться за технической поддержкой;
- учетная запись для чтения каталога Active Directory.
В качестве аналога в Active Directory для учетной записи root@localhost будем использовать учетную запись “Admin OTRS” с логином “root”.
В оснастке Active Directory Users and Computers создадим нового пользователя.
При создании учетной записи не забываем снять галочку «Требовать смены пароля при следующем входе в систему».
Предполагаем, что учетные записи для специалиста службы технической поддержки и для пользователя уже существуют. Если нет – создаем их по аналогии.
ВАЖНО: у всех пользователей должен существовать адрес электронной почты. Это обязательное условие для всех пользователей OTRS.
В данном примере все специалисты технической поддержки, которые будут работать в OTRS, будут членами группы OTRSagents. Это важный момент при разграничении прав доступа в системе.
Создаем группу OTRSagents в оснастке Active Directory Users and Computers. Область действия группы – Глобальная. Тип группы – Безопасность. Делаем членами группы ранее созданную учетную запись администратора OTRS (с логином root) и нужных специалистов технической поддержки.
Также важно иметь учетную запись с правами пользователя, которая будет использоваться системой OTRS для чтения каталога Active Directory. Для удобства срок действия пароля данной учетной записи должен быть не ограничен.
Переходим по ссылке http://localhost/otrs/index.pl и авторизуемся под учетной записью root@localhost.
Далее переходим на вкладку Администрирование, Управление агентами, Агенты.
Выбираем учетную запись root@localhost.
Вносим изменения. Важно помнить, что логин и пароль от данной учетной записи должны совпадать с логином и паролем учетной записи Admin OTRS (логин root), созданной нами в Active Directory.
Меняем логин root@localhost на root, соответственно меняем пароль. Устанавливаем адрес электронной почты в поле Email (в данном примере testdomain, помимо прочего, выполняет роль почтового сервера). Нажимаем кнопку Отправить.
Последний шаг – редактирование файла c:\otrs\Kernel\Config.pm.
В данном примере:
- Домен test.testdomain.ru
- IP контроллера домена — 10.0.0.11
- Учетная запись для чтения Active Directory- helpdesk@test.testdomain.ru с паролем Qwerty123.
- Группа агентов OTRS – OTRSagents в контейнере Users.
Приведенную ниже конфигурацию вставляем после строки «insert your own config settings «here»».
Config.pm
# insert your own config settings "here" #
#
#-------------------LDAP-----------------#
$Self->{'DefaultCharset'} = 'utf-8';
# задействуем LDAP аутентификацию для бэкэнд агентов
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';
$Self->{'AuthModule::LDAP::Host'} = '10.0.0.11';
$Self->{'AuthModule::LDAP::BaseDN'} = 'dc=test, dc= testdomain,dc=ru';
$Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';
# проверка, присутствует ли пользователь в группе, если да, то доступ в OTRS разрешен
$Self->{'AuthModule::LDAP::GroupDN'} = 'cn=OTRSagents,cn=Users,dc=test,dc=testdomain,dc=ru';
$Self->{'AuthModule::LDAP::AccessAttr'} = 'member';
$Self->{'AuthModule::LDAP::UserAttr'} = 'DN';
$Self->{'AuthModule::LDAP::SearchUserDN'} = 'helpdesk@test.testdomain.ru';
$Self->{'AuthModule::LDAP::SearchUserPw'} = 'Qwerty123';
$Self->{'AuthModule::LDAP::Params'} = {
port => 389,
timeout => 120,
async => 0,
version => 3,
sscope => 'sub'
},
# Agent data sync against LDAP
$Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';
$Self->{'AuthSyncModule::LDAP::Host'} = '10.0.0.11';
$Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=test, dc=testdomain,dc=ru';
$Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'helpdesk@test.testdomain.ru';
$Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'Qwerty123';
$Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
UserFirstname => 'givenName',
UserLastname => 'sn',
UserEmail => 'mail',
};
$Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [
'users',
];
#
#
# Authenticate customer users against an LDAP backend #
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP'; #LDAP
$Self->{'Customer::AuthModule::LDAP::Host'} ='10.0.0.11';
$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=test, dc=testdomain,dc=ru';
$Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'helpdesk@test.testdomain.ru';
$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'Qwerty123';
$Self->{CustomerUser} = {
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => '10.0.0.11',
BaseDN => 'dc=test, dc=testdomain,dc=ru',
SSCOPE => 'sub',
UserDN => 'helpdesk@ test.testdomain.ru',
UserPw => 'Qwerty123',
AlwaysFilter => '(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))',
SourceCharset => 'utf-8',
DestCharset => 'utf-8',
},
ReadOnly => 1,
CustomerKey => 'sAMAccountName',
CustomerID => 'mail',
CustomerUserListFields => ['givenname', 'sn', 'mail'],
CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchFields => ['displayName','sAMAccountName','givenName', 'sn', 'mail','description'],
CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchPrefix => '',
CustomerUserSearchSuffix => '*',
CustomerUserSearchListLimit => 10000,
CustomerUserPostMasterSearchFields => ['displayName','sAMAccountName','givenName','sn','mail','description'],
CustomerUserNameFields => ['givenname', 'sn'],
# CustomerUserExcludePrimaryCustomerID => 0,
CacheTTL => 120,
Map => [
# [ 'UserSalutation', 'Title', 'title', 1, 0, 'var' ],
[ 'UserFirstname', 'Firstname', 'givenName', 1, 1, 'var' ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
[ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
],
};
#--------------------------------------------
Сохраняем изменения в файл, перезапускаем службу Apache. Если есть проблемы, то служба не стартанет. Читаем логи (c:\otrs\var\log) и исправляем ошибки.
Переходим по ссылке http://localhost/otrs/index.pl для агента. Не забываем проверить и учетную запись root. Также переходим по ссылке http://localhost/otrs/customer.pl, заходим под учетной записью простого пользователя.
Все работает! Настройка интеграции OTRS с активным деревом завершена.
Часть 2. Настройка сквозной (Single Sign On) аутентификации.
Создание Kerberos token
Для аутентификации Апачу необходим так называемый keytab. Чтобы его сгенерировать, необходим протокол (HTTP), полное доменное имя OTRS-сервера и имя домена. Название протокола и имя домена должны быть в верхнем регистре. Также необходим обычный пользователь домена.
В командной строке на контроллере домена выполняем следующее:
Ktpass -princ HTTP/helpdesksrv.test.testdomain.ru@TEST.TESTDOMAIN.RU -mapuser helpdesk@test.testdomain.ru -pass Qwerty123 -out C:\helpdesksrv.keytab
На выходе в корне диска С получаем файл. Позже я переименовал файл из helpdesksrv.keytab в apache.keytab и положил в папку c:\Apache2\conf\ (имя файла роли не играет).
Установка MIT Kerberos for Windows 4.0.1
Качаем MIT Kerberos и устанавливаем.
Установка простая, без каких-либо особенностей.
Настраиваем MIT Kerberos
Создаем пустой файл c:\Program Files (x86)\MIT\Kerberos\krb.ini и заполняем его, соблюдаем регистр как в примере. Здесь TESTDC1 — имя контроллера домена.
krb.ini
[logging]
default = c:/otrs/var/log/krb5libs.log
kdc = c:/otrs/var/log/krb5kdc.log
admin_server = c:/otrs/var/log/kadmind.log
[libdefaults]
debug=true
default_keytab_file = c:/Apache2/conf/apache.keytab
default_realm = TEST.TESTDOMAIN.RU
dns_lookup_kdc = false
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
TEST.TESTDOMAIN.RU = {
kdc = TESTDC1.test.testdomain.ru
admin_server = TESTDC1.test.testdomain.ru
default_domain = test.testdomain.ru
}
[domain_realm]
.test.testdomain.ru = TEST.TESTDOMAIN.RU
test.testdomain.ru = TEST.TESTDOMAIN.RU
[login]
krb4_convert = true
krb4_get_tickets = false
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Качаем mod_auth_kerb.so для Apache 2.2.*, копируем его в папку c:\Apache2\modules.
Настраиваем Apache
Модифицируем файл c:\Apache2\conf\httpd.conf. Добавляем следующие строки и перезагружаемся:
httpd.conf
# загружаем модуль керберос
LoadModule auth_kerb_module modules/mod_auth_kerb.so
<Directory "c:/otrs/bin/cgi-bin/"> # в данном примере OTRS установлен в папку c:/otrs
AllowOverride None
AuthType Kerberos
AuthName "OTRS Kerberos Authentification"
# указываем путь до keytab-файла
Krb5Keytab c:/Apache2/conf/apache.keytab
KrbAuthRealms TEST.TESTDOMAIN.RU
KrbMethodNegotiate on
KrbSaveCredentials off
Require valid-user
Options +ExecCGI -Includes
Order allow,deny
Allow from all
</Directory>
Настраиваем OTRS
Редактируем файл c:\otrs\Kernel\Config.pm, добавляем строки:
Config.pm
# аутентификация + авторизация LDAP
#+ single sign on
# -------для агентов ---------
# $Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
# $Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} = '@TEST.TESTDOMAIN.RU';
# ------для пользователей ---------
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
$Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@ EST.TESTDOMAIN.RU';
$Self->{CustomerUser} = {
Module => 'Kernel::System::CustomerUser::LDAP',
Params => {
Host => '10.0.0.11',
BaseDN => 'dc=test, dc=testdomain,dc=ru',
SSCOPE => 'sub',
UserDN => 'helpdesk@test.testdomain.ru',
UserPw => 'Qwerty123',
SourceCharset => 'utf-8',
DestCharset => 'utf-8',
},
CustomerKey => 'sAMAccountName',
CustomerID => 'mail',
CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
CustomerUserPostMasterSearchFields => ['mail'],
CustomerUserNameFields => ['givenname', 'sn'],
Map => [
# note: Login, Email and CustomerID needed!
# var, frontend, storage, shown, required, storage-type
[ 'UserSalutation', 'Title', 'title', 1, 0, 'var' ],
[ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
[ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
[ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
[ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
[ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
],
};
Перезапускаем службу Apache. Проверяем http://helpdesksrv/otrs/customer.pl. Нас перенаправит, строка в адресной строке браузера изменится на http://helpdesksrv/otrs/customer.pl?Action=CustomerTicketOverview;Subaction=MyTickets.
Устраняем кракозябры
Создаем заявку через вэб-интерфейс пользователем. Заходим в интерфейс агента и видим, что имя пользователя в заявке отображается некорректно.
Видимо, вставка параметра
$Self->{'DefaultCharset'} = 'utf-8';
в файле c:\otrs\Kernel\Config.pm проходит некорректно.
Модифицируем файл c:\otrs\Kernel\cpan-lib\Apache\DBI.pm, добавляем строки:
$dbh->{'mysql_enable_utf8'} = 1;
$dbh->do('SET NAMES utf8');
Перезапускаем службу Apache.
Теперь имя пользователя отображается корректно.
На этом все. Надеюсь, что мой опыт будет Вам полезен.
Комментарии (13)
Slipeer
02.06.2015 16:21+1Вместо ip-адреса контролера домена лучше задать:
- Если на предприятии одна площадка — DNS имя домена
- Если предприятие распределённое, то сделать DNS имя (CNAME или A записи кому как нравится), указывающее на контроллеры расположенные на одной площадке с OTRS
Тогда OTRS «не ляжет» во время выполнения работ с каким-нибудь одним DC или по причине его смерти.
С вашими настройками OTRS будет нормально работать только на предприятии где меньше 1000 агентов, потом начнутся приколы.
CustomerUserSearchListLimit => 10000,
Потому, что по-умолчанию MaxPageSize стоит в 1000 и увеличивать её не стоит.
https://support.microsoft.com/en-us/kb/315071?wa=wsignin1.0
Разве что если дадите пользователю helpdesk доменадмина ;)
А в krb.ini лучше включить
dns_lookup_kdc = true
Чтобы KDC по DNS искался. Не будете же вы после добавления нового контроллера домена лазить по всем серверам добавлять его в настройки kerberos!supersuperoleg Автор
02.06.2015 16:24Все правильно Вы говорите. Однако данная работа проводилась на тестовом стенде.
Slipeer
02.06.2015 16:29+1Это Вы на тестовом стенде делали, а в заголовке написано «tutorial» — уверен хоть кто-нибудь да повторить описанные в статье шаги бездумно ;)
amaranth
05.06.2015 09:05Допустим, я поставил OTRS 4.0.8 на Debian 8. Как мне сделать так чтобы у пользователей была авторизация через AD?
supersuperoleg Автор
05.06.2015 09:10Воспользуйтесь данным руководством. Будет даже проще с установкой керберос. Информации полно в гугле.
Razaz
А OTRS поддерживает связку с ADFS?
Slipeer
Причём тут ADFS?
Razaz
А зачем городить это все? если проще аутентификацию выгрузить на ADFS? Вы же хотите аутентифицироваться в АД и разговор вроде про SSO? Ну а юзеров просто по LDAP доставать.
Slipeer
Это как посмотреть… Если всё хозяйство внутри периметра ИМХО поднимать ещё одну подсистему, которую ещё и не всякий админ осилит настроить (это печальный факт) — как то не с руки.
А тут простенький логичный гайд (с некоторыми огрехами, я указал в комментарии ниже), который вполне работоспособен, логичен и в принципе соответствует общей концепции внедрения SSO на сервисах внутри компании с доменом AD.
По крайней мере если бы внедрялся аналогичный сервис от MS (не предназначенный для работы в облаке) он бы использовал реализацию SSO аналогичную описанной, а не ADFS.
Razaz
Ну я бы не назвал настройку связки с KDC более простой чем WS-Fed с автоконфигом по метаданным ;) Просто с федерацией как раз удобно сделать кейс типа — клиенты в БД, а сотрудники в AD. В предложенном кейсе — всех придется пихать в домен, чего я никак не могу рекомендовать…
Slipeer
Признаю — в Вашей точке зрения тоже есть здравый смысл ;)
Каждый смотрит со своей колокольни — у меня OTRS ассоциируется в первую очередь с поддержкой внутренних пользователей.
Полагаю тут (как и всегда) следует исходить из сценария применения и преследуемых конечных целей.
Slipeer
Вот Вы бы написали подробный гайд как сделать это же только через ADFS с хранение внешних клиентов в БД. Я бы с удовольствием почитал и поставил свой плюсик. Да и не определившимся с реализацией тоже было бы полезно иметь возможность ознакомиться с различными вариантами ;)
Razaz
Мы съехали с ОТРС. У нас он использовался для поддержки внешних пользователей(клиентов), к сожалению было замкнуто все на АД как в статье и пока не растащили окончательно и есть проблемы с полным совпадением ФИО между сотрудником и клиентом например ;(