Данное руководство предназначено для случая, когда уже есть настроенный сервер с установленной OTRS. Подробное руководство об установке OTRS v4 в Windows-среде можно прочитать в здесь .
image

Часть 1. Настройка LDAP-аутентификации.


Прежде чем интегрировать OTRS с Active Directory, нужно определиться с учетными записями и их ролью. Нам понадобятся следующие учетные записи:
  • агент – специалист службы технической поддержки;
  • root-пользователь (очень важный момент – логин и пароль учетной записи root-пользователя должны совпадать с логином и паролем учетной записи администратора в OTRS);
  • собственно, пользователь OTRS, который будет обращаться за технической поддержкой;
  • учетная запись для чтения каталога Active Directory.

В качестве аналога в Active Directory для учетной записи root@localhost будем использовать учетную запись “Admin OTRS” с логином “root”.
В оснастке Active Directory Users and Computers создадим нового пользователя.

image

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

ВАЖНО: у всех пользователей должен существовать адрес электронной почты. Это обязательное условие для всех пользователей OTRS.

В данном примере все специалисты технической поддержки, которые будут работать в OTRS, будут членами группы OTRSagents. Это важный момент при разграничении прав доступа в системе.

Создаем группу OTRSagents в оснастке Active Directory Users and Computers. Область действия группы – Глобальная. Тип группы – Безопасность. Делаем членами группы ранее созданную учетную запись администратора OTRS (с логином root) и нужных специалистов технической поддержки.

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

image

Переходим по ссылке http://localhost/otrs/index.pl и авторизуемся под учетной записью root@localhost.

image

Далее переходим на вкладку Администрирование, Управление агентами, Агенты.

image

Выбираем учетную запись root@localhost.

image

Вносим изменения. Важно помнить, что логин и пароль от данной учетной записи должны совпадать с логином и паролем учетной записи Admin OTRS (логин root), созданной нами в Active Directory.

Меняем логин root@localhost на root, соответственно меняем пароль. Устанавливаем адрес электронной почты в поле Email (в данном примере testdomain, помимо прочего, выполняет роль почтового сервера). Нажимаем кнопку Отправить.

image

Последний шаг – редактирование файла c:\otrs\Kernel\Config.pm.
В данном примере:
  1. Домен test.testdomain.ru
  2. IP контроллера домена — 10.0.0.11
  3. Учетная запись для чтения Active Directory- helpdesk@test.testdomain.ru с паролем Qwerty123.
  4. Группа агентов 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, заходим под учетной записью простого пользователя.

image

Все работает! Настройка интеграции 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 и устанавливаем.

image

Установка простая, без каких-либо особенностей.

Настраиваем 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.

image

Устраняем кракозябры

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

image

Видимо, вставка параметра

$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.

image

Теперь имя пользователя отображается корректно.

На этом все. Надеюсь, что мой опыт будет Вам полезен.

Комментарии (13)


  1. Razaz
    02.06.2015 13:36

    А OTRS поддерживает связку с ADFS?


    1. Slipeer
      02.06.2015 16:01

      Причём тут ADFS?


      1. Razaz
        02.06.2015 16:27

        А зачем городить это все? если проще аутентификацию выгрузить на ADFS? Вы же хотите аутентифицироваться в АД и разговор вроде про SSO? Ну а юзеров просто по LDAP доставать.


        1. Slipeer
          02.06.2015 16:37
          +1

          если проще аутентификацию выгрузить на ADFS

          Это как посмотреть… Если всё хозяйство внутри периметра ИМХО поднимать ещё одну подсистему, которую ещё и не всякий админ осилит настроить (это печальный факт) — как то не с руки.
          А тут простенький логичный гайд (с некоторыми огрехами, я указал в комментарии ниже), который вполне работоспособен, логичен и в принципе соответствует общей концепции внедрения SSO на сервисах внутри компании с доменом AD.
          По крайней мере если бы внедрялся аналогичный сервис от MS (не предназначенный для работы в облаке) он бы использовал реализацию SSO аналогичную описанной, а не ADFS.


          1. Razaz
            02.06.2015 16:45

            Ну я бы не назвал настройку связки с KDC более простой чем WS-Fed с автоконфигом по метаданным ;) Просто с федерацией как раз удобно сделать кейс типа — клиенты в БД, а сотрудники в AD. В предложенном кейсе — всех придется пихать в домен, чего я никак не могу рекомендовать…


            1. Slipeer
              02.06.2015 16:50

              Признаю — в Вашей точке зрения тоже есть здравый смысл ;)
              Каждый смотрит со своей колокольни — у меня OTRS ассоциируется в первую очередь с поддержкой внутренних пользователей.
              Полагаю тут (как и всегда) следует исходить из сценария применения и преследуемых конечных целей.


            1. Slipeer
              02.06.2015 16:55
              +1

              Вот Вы бы написали подробный гайд как сделать это же только через ADFS с хранение внешних клиентов в БД. Я бы с удовольствием почитал и поставил свой плюсик. Да и не определившимся с реализацией тоже было бы полезно иметь возможность ознакомиться с различными вариантами ;)


              1. Razaz
                02.06.2015 17:02

                Мы съехали с ОТРС. У нас он использовался для поддержки внешних пользователей(клиентов), к сожалению было замкнуто все на АД как в статье и пока не растащили окончательно и есть проблемы с полным совпадением ФИО между сотрудником и клиентом например ;(


  1. Slipeer
    02.06.2015 16:21
    +1

    Вместо ip-адреса контролера домена лучше задать:

    1. Если на предприятии одна площадка — DNS имя домена
    2. Если предприятие распределённое, то сделать 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!


    1. supersuperoleg Автор
      02.06.2015 16:24

      Все правильно Вы говорите. Однако данная работа проводилась на тестовом стенде.


      1. Slipeer
        02.06.2015 16:29
        +1

        Это Вы на тестовом стенде делали, а в заголовке написано «tutorial» — уверен хоть кто-нибудь да повторить описанные в статье шаги бездумно ;)


  1. amaranth
    05.06.2015 09:05

    Допустим, я поставил OTRS 4.0.8 на Debian 8. Как мне сделать так чтобы у пользователей была авторизация через AD?


    1. supersuperoleg Автор
      05.06.2015 09:10

      Воспользуйтесь данным руководством. Будет даже проще с установкой керберос. Информации полно в гугле.