OTRS 4.0.10. Ставим на Ubuntu + AD + Kerberos + SSO

Вместо введения

Любая достаточно крупная организация рано или поздно сталкивается с необходимостью внедрения системы тикетов или helpdesk. И наша организация не исключение, в связи с чем руководством была поставлена задача выбрать и внедрить систему.

Откровенно говоря сомнений по поводу выбора особых не было, по личным соображениям выбор пал на OTRS. Мощная и гибкая с огромным количеством отчётов, которые так любит руководство. Но как оказалось внедрить её совсем нетривиальная задача. Мучения продолжались две недели, были перелопачены тонны инофрмации, перепробовано куча различных мануалов, и складывалось впечатление, что я либо полный кретин, либо одно из двух, потому как во всех мануалах и в куче отзывов все в один голос утверждали что всё работает и отлично ставиться и настраивается, а у меня ни как.

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

Исходные данные и требования

В организации поднят AD на двух контроллерах Win2008r2 и раз уж так, то нужна интеграция с AD, т. к. на мой взгляд интеграция всего и вся особенно с LDAP «is the true way»
Много сервисов (такие как почта и Jabber) подняты на Linux, и в качестве ОС выбрана Ubuntu Server 14.04, и раз уж OTRS это OpenSource, то ставить её на проприетарную ОС это на мой взгляд моветон, поэтому будем ставить на Ubuntu. Кстати если будет интересно в следующих статьях попробуем расскажу о своем опыте поднятия этих сервисов и интеграции их c AD и OTRS. (Интеграция OTRS и Jabber вообще очень класная и полезная штука)
Возможность быстро поднять на машине файлопомойку для сканирования служебок и пр.
И последнее, раз у нас есть AD, и при включении компьютера пользователь все равно вводит свой пароль и система уже на этом этапе знает кто работает в системе, то надо бы избавить его лишних вводов паролей и логинов и реализовать сквозную авторизацию.

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

На самом деле ставиться OTRS не сложно и даже с AD интегрируется на раз, вся загвоздка была именно в сквозной авторизации или (SSO). В сети было найдено куча мануалов на этот счёт, но ни один мне не подошел по разным причинам, в одном OTRS ставился на Windows, в другом слишком старая версия OTRS, в третьем использовался модуль-адаптер писанный неизвестно кем и когда.
В целом скажу, что есть 4 способа реализации сквозной авторизации.

Первый это SSPI, но он не подходит, потому как это модуль для OTRS под Windows
Второй это самописный модуль ADSSO, по сути просто допиленный модуль авторизации LDAP, что на мой взгляд костыль.
Третий это опять же самописный модуль NTLM авторизации для OTRS, что опять же костыль.
И последний — это штатный модуль OTRS HTTPBasicAuth в компании с Kerberos аутентификацией.

Вот последний как раз на мой взгляд (и думаю со мной многие согласятся) самый правильный и безопасный. Итак, исходные данные:

Сеть 192.168.0.0/16
Домен DOMAIN.RU
Контроллеры домена на них же и DNS и NTP
PDC — ad1.domain.ru (192.168.10.1)
SDC — ad2.domain.ru (192.168.10.2)
GATE 192.168.10.10
Все пользователи домена находятся в организейшн юнит ORGANIZATION внутри которого раскиданы по группам.
Создана группа OTRSagents, в которую включены сервисники, то есть те кто принимает заявки (в терминологии OTRS «Агенты»).
Клиентами, то есть теми кто отправляет заявки (в терминологии OTRS «Кустомер») будут все пользователи домена без исключения.

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

Сервер OTRS будет читать информацию из LDAP от имени пользователя otrs.admin, на период настройки дадим ему права администратора домена, после настройки отберём и их и даже право логинеться на машинах, ему нужно просто иметь возможность читать информацию из LDAP.

1.Подготовка системы

1.1 Ставим Ubuntu Server с такими настройками (это мои настройки, у вас могут быть другие)

IP: 192.168.10.14
MASK: 255.255.0.0
GATE: 192.168.10.10
DNS: 192.168.10.1 192.168.10.2 8.8.8.8
NAME: HELPDESK
USER: helpdesk
PASS: strongpass

На финальном этапе установка спросит хотим ли мы предустановить какое-то ПО, выбираем установку OpenSSH сервер.

1.2. Цепляемся по SSH к новому серверу

ssh 192.168.10.14 -l helpdesk

Соглашаемся принять ключик и вводим пароль пользоваетля helpdesk
Повышаем права до root

sudo su

! ВНИМАНИЕ! Все дальнейшие действия выполняем от su и после перезагрузок системы не забываем опять поднять права до root.

Проверяем актуальность информации в файлах /etc/hostname и /etc/hosts: в первом должно быть имя нашей машины большими буквами, во втором должна быть запись типа: 127.0.0.1 helpdesk.domain.ru helpdesk

Если что-то не так — исправляем. Теперь пробуем пинговать все контроллеры домена по IP, полному и сокращенному имени. Должны пинговаться по всякому. Если нет, разбираемся с настройками сети.

1.3. Обновляемся и ставим mc

apt-get update && apt-get -y upgrade && apt-get install -y mc

для не искушенных можно выполнить команды по очереди

apt-get update apt-get -y upgrade apt-get install -y mc

2. Вводим машину в домен и настраиваем доменную авторизацию. Настраиваем Samba, Kerberos и Winbind.

Отличная статья по этому поводу есть на сайте техподдержки Ubuntu: help.ubuntu.ru/wiki/%D0%B2%D0%B2%D0%BE%D0%B4_%D0%B2_%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD_windows

2.1. Ставим и настраиваем Kerberos

Ставим необходимые пакеты:

apt-get install krb5-user samba winbind libpam-krb5 libpam-winbind libnss-winbind ntp smbclient rlwrap

Для работы Kerberos очень важно что бы часы на компьютерах шли синхронно и разница во времени не превышала 5 минут. Настраиваем синхронизацию времени с контролером домена в файле /etc/ntp.conf

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

mcedit /etc/ntp.conf

Комментируем все срочки начинающиеся на server:

#server 0.ubuntu.pool.ntp.org  #server 1.ubuntu.pool.ntp.org  #server 2.ubuntu.pool.ntp.org  #server 3.ubuntu.pool.ntp.org  # Use Ubuntu's ntp server as a fallback.  #server ntp.ubuntu.com

И вписываем свои:

server 192.168.10.1  server 192.168.10.2

У меня два контроллера домена и на каждом поднята служба точного времени. После этого сохраняем файл и перезапускаем демона с новыми настройками:

service ntp restart

Вывод должен быть таким:

root@HELPDESK:/home/helpdesk# service ntp restart  * Stopping NTP server ntpd                                              [ OK ]  * Starting NTP server ntpd                                              [ OK ]

Демон запустился с новыми настройками и синхронизирует часы. Настройка керберос происходит путем правки файла krb5.conf:

mcedit /etc/krb5.conf

Перво наперво включим логи, для этого добавим в самое начало файла секцию:

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log

А дальше надо объяснить kerberos в каком домене (в терминологии Kerberos — в каком реалме) он работает и кто этим реалмом рулит. Для этого правим секции:

[libdefaults] default_realm = DOMAIN.RU          #(Вписываем свой домен большими буквами) [realms]                                           #Добавляем информацию о контроллерах DOMAIN.RU = {                               #домена. Думаю всё понятно. Если в сети kdc = ad1.domain.ru                       #несколько контроллеров то вписываем их kdc = ad2.domain.ru                        #все. Лишним не будет, как мне кажется admin_server = ad1.domain.ru		 admin_server = ad2.domain.ru default_domain = domain.ru } [domain_realm]                               #Здесь мы сообщаем о возможных .domain.ru = DOMAIN.RU               #псевдонимах нашего домена(реалма) domain.ru = DOMAIN.RU

Теперь надо проверить работоспособность нашего конфига, для этого попытаемся получить тикет kerberos в домене для какого-нибудь пользователя:

kinit username@DOMAIN.COM		#здесь username — любой пользователь домена, !имя домена заглавными!

После чего она запросит пароль и попытается получить тикет. Если всё прошло успешно, то команда промолчит, то есть вывод будет пустой. Как-то так:

root@HELPDESK:/home/helpdesk# kinit otrs.admin@DOMAIN.RU  Password for otrs.admin@DOMAIN.RU:  root@HELPDESK:/home/helpdesk#

Проверим, получили ли мы тикет, вводим:

klist

И видим что-то такое:

root@HELPDESK:/home/helpdesk# klist  Ticket cache: FILE:/tmp/krb5cc_0  Default principal: test@DOMAIN.RU  Valid starting       Expires              Service principal  10.08.2015 15:46:01  11.08.2015 01:46:01  krbtgt/DOMAIN.RU@DOMAIN.RU  renew until 11.08.2015 15:45:57

Как видно, тикет мы получили успешно и всё ОК. Значит конфиг работает. Теперь грохнем тикет, пока что он нам не нужен.

Kdestroy

Вывод так же пустой, и значит тикет уничтожился (обратите внимание, команда уничтожает ВСЕ тикеты находящиеся в кеше).

2.2 Пора настроить SAMBA и подключиться к домену.

Для этого правим файл /etc/samba/smb.conf:

mcedit /etc/samba/smb.conf

Здесь правим секцию [global]:

[global] # Эти две опции нужно писать именно в заглавном регистре, причём workgroup без # последней секции после точки, а realm - полное имя домена  workgroup = RUS realm = DOMAIN.RU # Эти две опции отвечают как раз за авторизацию через AD security = ADS encrypt passwords = true # Просто важные  dns proxy = no  socket options = TCP_NODELAY # Если вы не хотите, чтобы самба пыталась при случае вылезти в лидеры в домене или рабочей группе, # или даже стать доменконтроллером, то всегда прописывайте эти пять опций именно в таком виде domain master = no local master = no preferred master = no os level = 0 domain logons = no # Отключить поддержку принтеров load printers = no show add printer wizard = no printcap name = /dev/null disable spoolss = yes

Проверяем корректность конфигурации коммандой:

testparm

Вывод будет приблизительно такой:

Load smb config files from /etc/samba/smb.conf  rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)  Processing section "[printers]"  Processing section "[print$]"  Loaded services file OK.  Server role: ROLE_DOMAIN_MEMBER  Press enter to see a dump of your service definitions

Нажав Enter, мы увидем скомпилированный smb.conf (то есть без комментариев):

Cообщение «rlimit_max:increasing rlimit_max(1024) to minimum Windows limit(16384)» возникает из-за разницы пула лимитов между Windows и Ubuntu, мы избавимся от него чуть позже, когда поправим лимиты.

Теперь пробуем неспосредственно войти в домен. Для этого исполняем комманду:

net ads join -U username -D DOMAIN 		#username - администратор домена

Она сначала запросит пароль пользователя и в случае если всё ОК, то вывод будет типа этого:

Using short domain name -- RUS  Joined 'HELPDESK' to dns domain 'domain.ru'

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

net ads testjoin

Её вывод должен быть таким:

Join is OK

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

kinit username@DOMAIN.COM

И пробуем посмотреть ресурсы любой машины, например файл-сервера:

smbclient -k -L //File-server

Ключик -k говорит, что нужно использовать kerberos, File-server — имя машины в домене имеющей расшареные ресурсы. В выводе команды вы должны увидеть список общих ресурсов указанной машины, если да, всё — ок, до настоящего момента всё сделано правильно. После чего уничтожаем тикеты командой:

kdestroy

2.3 Настраиваем Winbind

Для этого правим всё тот же /etc/samba/smb.conf и добавляем в секцию [global] следующие строки:

# Опции сопоставления доменных пользователей и виртуальных пользователей в системе через Winbind. # Диапазоны идентификаторов для виртуальных пользователей и групп. idmap config * : range = 10000-20000 idmap config * : backend = tdb  # Эти опции не стоит выключать. winbind enum groups = yes winbind enum users = yes # Использовать домен по умолчанию для имён пользователей. Без этой опции имена пользователей и групп # будут использоваться с доменом, т.е. вместо username - DOMAIN\username. # Возможно именно это вам и нужно, однако обычно проще этот параметр включить.  winbind use default domain = yes # Если вы хотите разрещить использовать командную строку для пользователей #домена, то добавьте следующую строку, иначе в качестве shell'а будет вызываться #/bin/false template shell = /bin/bash # Для автоматического обновления билета Kerberos модулем pam_winbind.so нужно добавить строчку winbind refresh tickets = yes # Так же надо объяснить самбе что она теперь будет пользоваться kerberos # аутентификацией и показать где лежит ключик (его мы создадим на следеющем # шаге), а для этого после строки «passdb backend = tdbsam» добавляем ещё две: kerberos method = system keytab dedicated keytab file = /etc/krb5.keytab

Проверяем корректность нашей конфигурации:

testparm

И если всё ок, перезапускаем демоны (именно в такой последовательности):

service winbind stop service smbd restart service winbind start

Если сервисы перезапустились нормально вывод будет приблизительно такой:

root@HELPDESK:/home/helpdesk# service winbind stop  winbind stop/waiting  root@HELPDESK:/home/helpdesk# service smbd restart  smbd stop/waiting  smbd start/running, process 4859  root@HELPDESK:/home/helpdesk# service winbind start  winbind start/running, process 4871

У вас так же? Тогда идём дальше. Пора поправить лимиты, на которые ругается самба. Правятся они в файле/etc/security/limits.conf. Надо дописать в конец файла две строчки:

*               -    nofile            16384 root            -    nofile            16384

После этой операции надо перезагрузить машину:

shutdown -r now

или

reboot

Кому как нравиться.

После перезагрузки проверяем установила ли наша машина доверительные отношения с доменом:

wbinfo -t

Вывод должен быть типа этого:

checking the trust secret for domain DCN via RPC calls succeeded

Напомню, что всё команды выполняются от root’а. Поначалу у меня происходил затык на этом этапе, потому как после ребута забывал повысить права до su. Все секреты (тикеты и пр.) хранятся в базхах самбы /var/lib/samba/private/*.tdb доступ к которым имеет только root. Так что не забываем после перезагрузок повысить права и все команды выполняем от суперпользователя. Также проверяем, что winbind видит пользователей и группы в домене:

wbinfo -u

wbinfo -g

2.4. Ну и ещё один бонус

Раз уж вводим машину в домен, добавим и возможность логиниться на машину под доменными учётками. Для этого в файле /etc/nsswitch.conf добавляем источник данных winbind. Это так же даст нам возможность работать с доменными пользователями как с локальными, а значит назначать их владельцами объектов и давать права на доступ. Что даст возможность поднять шары на линуксовой машине. Приводим строки:

passwd:         compat group:     compat

к виду

passwd:         compat winbind group:          compat winbind

Так же рекомендуют добавить в конец файла строчку:

files:          dns mdns4_minimal[NotFound=return] mdns4

Этот этап проверяем запрашивая список пользователей и групп командами:

getent passwd

getent group

В выводе ищем доменных пользователей и группы и если находим, значит всё ок. И последнее: дадим возможность открывать сессии доменным пользователям, в предыдущих версиях убунту для этого нужны были нетривиальные пляски с ударным инструментом, сейчас же с нашей задачей прекрасно справиться PAM.D, добавляем в файл /etc/pam.d/common-session строчку:

session  optional  pam_mkhomedir.so skel=/etc/skel/ umask=0077

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

3. Создаем ключить Kerberos и добавляем принципиала HTTP в домен.

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

Итак, протокол Kerberos, это протокол сетевой аутентификации основанный на принципе доверия третьей стороне, так нам говорит справочник. Что это значит? А это значит, что в процессе аутентификации фигурирует третья сторона, которой поумолчанию доверяют участники взаимодействия, такая сторона называется Key Distribution Center, если проще, прежде чем обратиться к серверу, клиент посылает сообщение KDC, а KDC в свою очередь направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени. Назначение этих ключей – проведение аутентификации клиента и сервера.

Для людей знакомых с криптографией скажу, что весь механизм Kerberos чуть более чем полностью копирует механизм PKI. Фактически это он и есть только заточенный под другие задачи. Только вместо центра сертификации данном случае Центр распространения ключей (KDC). Обычно располагается на контроллере домена.

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

Выполнить это шаг можно двумя способами сложным и попроще. Почему то все мануалы в сети описывают более сложный способ, а именно создание ключа Kerberos на контроллере домена при помощи утилиты ktpass (страшный зверь с неимоверным количеством ключей) и последующее копирование его на Linux-машину. Я не отрицаю канонической правильности данного пути, но извольте, команда получается в несколько строк и я так и не постиг дзен при её использовании.

Как оказалось есть способ проще — создание ключа непосредственно на Linux-машине. В сетия я нашел только одно упоминание о нём, возможно плохо искал, но он работает.

Так же для того что бы контролировать правильность на данном этапе нам потребуется кое-что сделать на контроллере домена.
Первым делом идём на контроллер и открываем оснастку «AD-пользователи и компьютеры», открываем контейнер с компьютерами и ищем нашу Linux-машину, она должна была там появиться после того как мы её включили в домен. Нашли — ок. Идём дальше.

Теперь нужен редактор ADSI, открываем командную строку, набираем:

adsiedit.msc

И жмём интер. Видим дерево консоли копирующее по своей структуре консоль AD. Находим тут нашу машину, открываем её свойства и ищем в списке атрибут servicePrincipalName. Сейчас там должно быть две записи типа HOST/hepldesk.domain.ru и HOST/helpdesk.

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

Теперь идём на Линукс-машины и исполняем команду:

net ads keytab create

Вывод у команды пустой, но после исполнения должен создаться файл /etc/krb5.keytab, или любой другой, смотря что вы указывали в файле smb.conf в директиве dedicated keytab file. Но ведь OTRS, это веб-приложение и наша линукс-машина будет предоставлять услуги http, а значит надо добавить ещё принципиала HTTP. Сказано — сделано:

net ads keytab add HTTP

Если вы теперь посмотрите в список принципалов, в свойствах машины на домене то заметите, что там добавлись еще два — "HTTP/helpdesk.domain.ru" и "HTTP/helpdesk" (маленький нюанс: информация в окне редактора ADSI не обновляется автоматически, поэтому закрываем свойства машины, жмём F5 и снова их открываем).

В принципе это уже значит что добавление прошло успешно. Тем не менее, давайте посмотрим что сейчас находится в keytab:

klist -ek /etc/krb5.keytab			#тут вводим ваше имя файла keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- --------------------------------------------------------------------------  2 host/helpdesk.domain.ru@DOMAIN.RU (DES cbc mode with CRC-32)  2 host/helpdesk.domain.ru@DOMAIN.RU (DES cbc mode with RSA-MD5)  2 host/helpdesk.domain.ru@DOMAIN.RU (ArcFour with HMAC/md5)  2 host/helpdesk@DOMAIN.RU (DES cbc mode with CRC-32)  2 host/helpdesk@DOMAIN.RU (DES cbc mode with RSA-MD5)  2 host/helpdesk@DOMAIN.RU (ArcFour with HMAC/md5)  2 HELPDESK$@DOMAIN.RU (DES cbc mode with CRC-32)  2 HELPDESK$@DOMAIN.RU (DES cbc mode with RSA-MD5)  2 HELPDESK$@DOMAIN.RU (ArcFour with HMAC/md5)  2 HTTP/helpdesk.domain.ru@DOMAIN.RU (DES cbc mode with CRC-32)  2 HTTP/helpdesk.domain.ru@DOMAIN.RU (DES cbc mode with RSA-MD5)  2 HTTP/helpdesk.domain.ru@DOMAIN.RU (ArcFour with HMAC/md5)  2 HTTP/helpdesk@DOMAIN.RU (DES cbc mode with CRC-32)  2 HTTP/helpdesk@DOMAIN.RU (DES cbc mode with RSA-MD5)  2 HTTP/helpdesk@DOMAIN.RU (ArcFour with HMAC/md5)

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

kvno HTTP/web.domain.ru@DOMAIN.RU HTTP/web@DOMAIN.RU HTTP/web.domain.ru@DOMAIN.RU: kvno = 2 HTTP/web@DOMAIN.RU: kvno = 2

Смотрим билеты командой:

klist -e

В выводе будет полный список имеющихся в данный момент билетов, и среди них должны быть билеты HTTP, если есть, то всё ок, и если вы не перфекционист, можно переходить к следующему этапу.

А для остальных скажу, я как раз перфекционист и считаю несколько не правильным хранить все ключи в одном файле, давайте ка выделим всё что касательно HTTP в отельный ключевой файл.Сделать это можно с помощью ktutil. Расширеных функций редактирования она не поддерживает, поэтому его можно запустить через rlwrap.

rlwrap ktutil

Загружаем сожержимое keytab-файла:

ktutil: read_kt /etc/krb5.keytab

Просмотрим, что у нас сейчас есть в нём:

ktutil: list

Нас интересует всё что начинается с HTTP, всё лишнее удаляем:

ktutil: delent 1			#Вместо 1 пишем номер удаляемого ключа

Должно получится как-то так:

ktutil:  list  slot KVNO Principal  ---- ---- ---------------------------------------------------------------------     1    2        HTTP/helpdesk.domain.ru@DOMAIN.RU     2    2        HTTP/helpdesk.domain.ru@DOMAIN.RU     3    2        HTTP/helpdesk.domain.ru@DOMAIN.RU     4    2        HTTP/helpdesk.domain.ru@DOMAIN.RU     5    2        HTTP/helpdesk.domain.ru@DOMAIN.RU     6    2                  HTTP/HELPDESK@DOMAIN.RU     7    2                  HTTP/HELPDESK@DOMAIN.RU     8    2                  HTTP/HELPDESK@DOMAIN.RU     9    2                  HTTP/HELPDESK@DOMAIN.RU    10    2                  HTTP/HELPDESK@DOMAIN.RU

Теперь сохраним всё что осталось в отдельный файл:

ktutil:  write_kt /etc/httpd.keytab

И выходим из утилиты:

quit

4. Ставим Apache2 и модули. (LAMP) + Perl

Отличный мануал по настройке сервисов в Ubuntu 14 вот тут
.
Вот не знаю как для вас, а для меня если веб-сервер, то LAMP, так что ставим весь стек сразу, тем более что MySQL и Apache нам и так нужно, а в php есть удобная функция phpinfo(); с помощью которой мы будем мониторить переменные окружения.

Итак, поехали. Ставим Apache

apt-get install mysql-server apache2 php5 libapache2-mod-php5 libapache2-mod-auth-mysql php5-mysql php5-cgi libapache2-mod-php5 php5-common php-pear

Во время установки mysql-server он попросит задать пароль для суперпользователя mysql (root@localhost), попрошу не путать с суперпользователем системным, хоть они и оба root, это разные пользователи. Хотя никто не запрещает указать одинаковые пароли для них. Так вот указываем этот пароль и запоминаем его, он нам ещё будет нужен.

После того как поставятся все пакеты нам надо будет сразу немного настроить MySQL, для этого открываем файл /etc/mysql/my.cnf:

mcedit /etc/mysql/my.cnf

Находим в файле две строчки с указанием максимального размера принимаемых пакетов. Строчки начинаются max_allowed_packet. По умолчанию этот артибут выставлен в 16 мегабайт, меняем на 20 Мб в обеих строчках:

max_allowed_packet = 20M

А также надо изменить размер лог-файла innodb, насколько я понял это аналог лога транзакций в MS SQL. Для этого надо найти такую строку:

# * InnoDB

И добавить после неё ещё одну строчку следующего содержания:

innodb_log_file_size = 512M

Можно сделать и побольше, но OTRS рекомендует именно такой объем. Теперь маленький нюанс: пока старые лог-файлы есть, MySQL не сможет создать новые файлы и соответственно увеличить их объем, поэтому идем в папку /var/lib/mysql и удаляем или перемещаем куда ни будь (лучше переместит, удалить всегда успеем) два файла с именами типа ib_logfile0 и ib_logfile1.

Теперь перезапускаем MySQL:

service mysql restart

Проверяем что на месте старых лог-файлов создались новые увеличенного объема, значит всё ОК. После этого открываем браузер на соседней машине и заходим по адресу helpdesk, должна открыться стартовая страница Apache2. Открылась? Значит всё ок —Apache установлен.

Теперь Perl.

apt-get install perl libapache2-mod-perl2 libdbd-mysql-perl libnet-dns-perl libnet-ldap-perl libio-socket-ssl-perl libpdf-api2-perl libsoap-lite-perl libgd-text-perl libgd-graph-perl libapache-dbi-perl libyaml-libyaml-perl
Объясним Апачу что делать со скриптами PHP и PERL, для этого в файле /etc/apache2/mods-enabled/mime.conf раскоментируем 220-ую строчку AddHandler и приведём её к виду:

AddHandler cgi-script .cgi .pl

А так же добавим за ней ещё одну такого вида:

AddHandler php5-script .php

Теперь включаем модули php5, perl и cgi, а затем перезапустим Apache:

a2enmod php5 a2enmod perl a2enmod cgi service apache2 restart

Теперь проверим, всё ли работает. Для этого создадим две дирректории в /var/www/html:

mkdir /var/www/html/php mkdir /var/www/html/perl

И создадим по тестовому файлу в каждой:

touch /var/www/html/php/index.php touch /var/www/html/perl/index.cgi

Первый файл (index.php) мы заполняем следующим образом:

cat /var/www/html/php/index.php <html>  <body>  <div style="width: 100%; font-size: 40px; font-weight: bold; text-align:center;">  <?php  print Date("Y/m/d");  echo "<br>Path        :".$_SERVER['PHP_SELF'];  echo "<br>Remote User :".$_SERVER['REMOTE_USER'];  echo "<br>Auth type   :".$_SERVER['AUTH_TYPE'];  echo "<br>Auth User   :".$_SERVER['PHP_AUTH_USER'];  ?>  </div>  <?php  phpinfo();  ?>  </body>  </html>

Во второй пишем следующее:

cat /var/www/html/perl/index.cgi #!/usr/bin/perl print "Content-type: text/html\n\n"; print "<html>\n<body>\n"; print "<div style=\"width: 100%; font-size: 40px; font-weight: bold; text-align: center;\">\n"; print "CGI Test Page"; print "\n</div>\n"; print "</body>\n</html>\n";

Устанавливаем права:

chmod 755 /var/www/html/php/index.php  chmod 755 /var/www/html/perl/index.cgi

И ещё нюанс: надо объяснить апачу что в дирректории /var/www/html/perl/ лежат скрипты и он может их исполнять. Для этого добавляем в файл /etc/apache2/sites-available/000-default.conf после строки DocumentRoot вот такой блок:
<Directory "/var/www/html/perl"> AllowOverride All Options +ExecCGI Require all granted </Directory>
И перезапускаем apachephp5:

service apache2 restart

Теперь пробуем открыть в браузере адреса helpdesk/perl/index.cgi и helpdesk/php/index.php. Должны открыться, обратите внимание в php скрипте есть небольшой блок, вынесенный на самый верх страницы, текущая дата, и несколько переменных окружения, этот блок нам ещё пригодиться когда мы будем отлаживать Kerberos — аутентификацию.

Также по короткому имени страничка может не открыться и придется вписать полное имя компьютера, то есть helpdesk.domain.ru/php/index.php и helpdesk.domain.ru/perl/index.cgi. Как это исправлять рассматривать не буду, тем более что к теме это относиться мало, скажу только что копать надо в сторону настроек DNS и Apache.

5. Настраиваем Kerberos аутентификацию в Apache2. Проверяем работоспособность аутентификации. Настраиваем прозрачную аутентификацию.

С этим пунктом всё должно быть ещё проще. Ставим модуль:

apt-get install libapache2-mod-auth-kerb

Включаем его:

a2enmod auth_kerb

Перезапускаем Apache:

service apache2 restart

И добавляем авторизацию для папки где лежит php-скрипт (на самом деле её включить можно для любой папки, просто в php-скрипте у нас ежё есть блок с выводом переменных окружения, поэтому будет отлаживать на нём). Для этого опять открываем /etc/apache2/sites-available/000-default.conf и добавляем туда после блока для папки perl еще один блок для папки php:
<Directory /var/www/html/php> AuthType Kerberos AuthName "Kerberos Authntication" KrbAuthRealms DOMAIN.RU Krb5Keytab /etc/httpd.keytab KrbMethodNegotiate Off KrbSaveCredentials Off KrbVerifyKDC Off Require valid-user </Directory>
Даём Апачу права читать наш файл с ключами Kerberos:

chmod 644 /etc/httpd.keytab

Рестартуем Apache:

service apache2 restart

Теперь заходим в браузере по адресу helpdesk/php/index.php и если всё Ок, то мы увидим запрос авторизации. Вводим учетный данные какого либо пользователя домена и нас должно пустить. Если пустило и вверху страницы в строчка Remote_user, Auth_type и Auth_user, вывелись соответствующие значения то всё чудесно. Kerberos аутентификация работает.

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

Для этого в первую очередь в файле /etc/apache2/sites-available/000-default.conf исправляем строчку:
KrbMethodNegotiate Off
на
KrbMethodNegotiate On
Теперь настроим браузер пользователя:

IE

В IE надо добавить сайт helpdesk и helpdesk.domain.ru в доверенные:

После чего на вкладке безопасность надо разрешить встроенную аутентификацию Windows.

После чего перезапускаем IE и пробуем зайти на наш скрипт: теперь он не должен спрашивать логин и пароль, а сразу же аутентифицировать пользователя.

FireFox

Перейдем к настройке Mozilla Firefox, здесь все проще и без перезапусков. Наберите в адресной строке «about:config», в строке фильтра — «network.neg». Впишите свой домен в две строки, как показано на рисунке.

Теперь снова открываем вбраузере helpdesk/php/index.php и если страница открывается сразу не запрашивая логин и пароль и показывает в верхнем блоке полный логин пользователя, поздравляю, прозрачная аутентификация настроена. Мы закончили самый большой и трудный этап во всей работе.

! ВНИМАНИЕ! Все манипуляции в браузере надо проводить с машины залогиненной в домене под доменной учёткой!

6. Установка и настройка OTRS

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

6.1. Суть предлагаемого метода и необходимые пакеты

Ставить мы будем последнюю стабильную версию, на данный момент это 4.0.10, на самом деле это не существенно, потому как мы изначально пошли канонически правильным путем и не стали использовать всякие прокладки и костыли типа адамтеров NTLM, SSPI и прочего, а подняли полноценную Kerberos аутентификацию. А за неё в OTRS отвечает модуль HTTPBasicAuth, который не претерпел существенных изменений, поэтому описываемый способ будет работать на всех версиях системы начиная как минимум с 3.1.1.

В чем собственно суть способа? А вся суть заключается в том, что OTRS вообщем то и не проводит никакой авторизации и аутентификации пользователя, а просто берёт имя залогиневшегося пользователя из переменной окружения $_ENV[‘Remote_User’] ищет его в своей базе и если находит, то открывает для него интерфейс Кустомера в залогиненом виде. То есть вся нагрузка по верификации пользователя ложится на плечи Apache, который механизмом Kerberos аутентифицирует пользователя и если ему это удалось, то загоняет его логин в переменную окружения. Откуда его и подхватывает OTRS, считая, что если там что-то есть, то аутентификация уже прошла успешно. Итак, приступим.

Отличная статья по этому поводу вот тут. Очень подробно описан процесс установки.

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

Вот перечень пакетов, которые потребуются нам на этом этапе:

libapache2-mod-perl2
libtemplate-perl
libarchive-zip-perl
libjson-xs-perl
libmail-imapclient-perl
libdbd-mysql-perl
libnet-dns-perl
libnet-ldap-perl
libio-socket-ssl-perl
libpdf-api2-perl
libsoap-lite-perl
libgd-text-perl
libgd-graph-perl
libapache-dbi-perl
libyaml-libyaml-perl
mysql-server
wget

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

apt-get install libapache2-mod-perl2 libtemplate-perl libarchive-zip-perl libjson-xs-perl libmail-imapclient-perl libdbd-mysql-perl libnet-dns-perl libnet-ldap-perl libio-socket-ssl-perl libpdf-api2-perl libsoap-lite-perl libgd-text-perl libgd-graph-perl libapache-dbi-perl libyaml-libyaml-perl mysql-server wget

6.2. Ставим OTRS

Как уже сказано выше ставить мы будет версию 4.0.10, последнюю на момент написания статьи. Качаем сам OTRS:

cd ~ wget http://ftp.otrs.org/pub/otrs/otrs-4.0.10.tar.gz

Распаковываем архив:

tar zxf ./otrs-4.0.10.tar.gz

Перемещаем распакованный OTRS папку /opt:

mv ./otrs-4.0.10 /opt

И создаем симлинк на него в этой же папке:

ln -s /opt/otrs-4.0.10/ /opt/otrs

Проверяем все ли модули мы поставили:

perl /opt/otrs/bin/otrs.CheckModules.pl

Если нужны какие то дополнительные модули ставим (в выводе предыдущей команды напротив каждого модуля есть подсказка как его установить, если его нет). Заводим пользователя для OTRS:

useradd -r -d /opt/otrs/ -c 'OTRS user' otrs

И включаем его в группу www-data:

usermod -g www-data otrs

Имейте ввиду: наша машина включена в домен и winbind биндит всех пользователей в локальную базу пользователей, поэтому надо проследить, что бы в домене не было пользователя с логином «otrs». Если он есть — удаляем его и перезагружаем линукс-машину.

Создаем дефолтные конфиги для OTRS:

cd /opt/otrs/Kernel cp Config.pm.dist Config.pm cp Config/GenericAgent.pm.dist Config/GenericAgent.pm

И настраиваем права свеже созданному пользователю:

cd /opt/otrs bin/otrs.SetPermissions.pl --otrs-user=otrs --web-group=www-data /opt/otrs

Осталось создать vhost Апача для OTRS и можно конфигурировать систему:

cp /opt/otrs/scripts/apache2-httpd.include.conf /etc/apache2/sites-available/otrs.conf

Включаем vhost OTRS:

a2ensite otrs

И перечитываем конфиги Apache:

service apache2 reload

Всё. Установка закончена, теперь можем занятся конфигурацией OTRS.

6.3. Начальное конфигурирование системы OTRS. Интеграция с LDAP (в нашем случае AD)

Начальное конфигурирование системы происходит через веб-интерфейс. Заходим по адресу helpdesk/otrs/installer.pl, видим мастер установки OTRS:

Жмем далее и видим лицензионное соглашение, внимаааательно его читаем и жмем «принят условия».

На третьем этапе надо выбрать используемую базу данных, в нашем случае база MySQL, так что жмем далее. Тут уже поинтереснее, надо ввести логин того самого пользователя MySQL root@localhost, этот пароль мы создавали на шаге 6, когда ставили Apache и MySQL сервер.

OTRS попробует подключиться к серверу баз данных (localhost) и если всё нормально — создаст для себя базу с именем otrs и пользователем otrs, а так же с очень хитрым паролем, его мы тоже запоминаем куда ни будь в блокнотик, на всякий случай.

Настраиваем почту. На выходе OTRS сообщит пароль дефолтного пользователя root@localhost, запоминаем его пароль.

Переходим по ссылке «главная страница» и видим приглашения залогиниться, вот сюда-то и вводим только записанные логин и пароль. По большому счёту установка OTRS уже закончена, но нам ведь этого мало и не для того мы столько возились с Kerberos, нам нужна интеграция с AD и сквозная аутентификация, поэтому идем дальше.

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

Итак для начала. В домене, должен быть один пользователь который полностью совпадает с администратором OTRS, он у нас будет и LDAP читать и остальных админов OTRS мы через него заведём. В моём случае это пользователь otrs.admin, кстати, на период установки я давал ему права администратора домена и все манипуляции на домене, как то включение машины в домен, получение тикетов и пр. проводил от имени именно этого пользователя, после установки эти права у него можно отобрать, более того, запретить ему логиниться на машины домена, ему надо только читать информацию из LDAP, не более того.

И так, в интерфейсе Агента OTRS, переходим на вкладку «Администрирование», заходим в раздел «агенты» видим единственного агента, жмём на него и меняем его учетные данные в соответствии с данными пользователя в домене, как я уже сказал выше, в моём случае это логин otrs.admin и соответствующий ему доменный пароль, жмем «отправить» внизу страницы и пробуем выйти и зайти снова уже с новыми учетными данными.

! ВНИМАНИЕ! совпадать с данными доменного пользователя должен не только логин, но и пароль!

Теперь отключим возможность самостоятельной регистрации кустомеров. «Администрирование»-«Конфигурация системы»-(в выпадающем списке слева выбираем «Framework»)-«Frontend::Customer» на CustomerPanelCreateAccount указываем «Нет» и жмем внизу кнопку «Обновить». Тут же можно поправить название организации которое будет высвечиваться у кустомеров в CustomerHeadline. Здесь ещё куча других настроек, которые можно будет покрутить и попробовать, но это позже, сейчас нас интересует интеграция с LDAP.

Настройка интеграции OTRS с LDAP будет происходить через конфигурационный файл /opt/otrs/Kernel/Config.pm:

mcedit /opt/otrs/Kernel/Config.pm

Находим строчку # insert your own config settings «here» # и вставляем после неё вот такой конфиг:

# Настройки LDAP аутентификации для Агентов # # Включаем LDAP аутентификацию и авторизацию для Агентов #  $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';  # IP адрес LDAP каталога # $Self->{'AuthModule::LDAP::Host'} = '192.168.10.1';   # Тоже думаю понятно, указываем корень LDAP # $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=domain,dc=ru';   # Указываем какое поле будем использовать в качестве UID # $Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';   # Указываем где искать. Мои агенты заведены в группу OTRSagents в OU organization # # Тут можно указать свой путь для Агентов, если они у вас в другом месте # $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=OTRSagents,ou=organization,dc=domain,dc=ru';  $Self->{'AuthModule::LDAP::AccessAttr'} = 'member';  $Self->{'AuthModule::LDAP::UserAttr'} = 'DN';   # Учётка для подключения к LDAP # $Self->{'AuthModule::LDAP::SearchUserDN'} = 'otrs.admin@domain.ru';  $Self->{'AuthModule::LDAP::SearchUserPw'} = 'пароль пользователя otrs.admin';   # Указываем фильтр и параметры подключения к LDAP# $Self->{'AuthModule::LDAP::AlwaysFilter'} = '';  $Self->{'AuthModule::LDAP::Params'} = {  port => 389,  timeout => 120,  async => 0,  version => 3,  sscope => 'sub'  };  # Конец настроек LDAP аутентификации для Агентов #  # Настройка модуля синхронизации Агентов с LDAP # # Синхронизируем базу агентов с LDAP #  $Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP';   # IP Адресс LDAP каталога # $Self->{'AuthSyncModule::LDAP::Host'} = '192.168.10.1';   # Указываем BaseDN # $Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=domain, dc=ru';   # Указываем какое поле берём в качестве UID # $Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName';   # Учетка для подключения к LDAP # $Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'otrs.admin@domain.ru';  $Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'пароль пользователя otrs.admin';   # Указываем соответствие полей # $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {  UserFirstname => 'givenName',  UserLastname => 'sn',  UserEmail => 'mail',  };  # И кого синхронизировать # $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [  'users', 'basic_admin',  ];  # Конец настроек модуля синхронизации Агентов #  # Настройки авторизации Кустомеров # # Тут всё просто, нужно просто включить модуль HTTPBasicAuth # # Включаем HTTPBasicAuth для кустомеров # $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';  # И указываем какие странички открывать в случае успешной авторизации # $Self->{CustomerPanelLoginURL1} = 'http://helpdesk.domain.ru/otrs/customer.pl';  $Self->{CustomerPanelLogoutURL1} = 'http://helpdesk.domain.ru/otrs/customer.pl';  # Конец настроек авторизации Кустомеров #  # А теперь подтянем базу кустомеров из LDAP # # Кустомерами у нас будут все пользователи домена без исключения # $Self->{CustomerUser} = {  Module => 'Kernel::System::CustomerUser::LDAP',  Params => {  Host => '192.168.10.1',  BaseDN => 'DC=domain,DC=ru',  SSCOPE => 'sub',  UserDN =>'otrs.admin@domain.ru',  UserPw => 'пароль пользователя otrs.admin',  AlwaysFilter => '(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))',  SourceCharset => 'utf-8',  DestCharset => 'utf-8',  },   # Указываем соответствие поле # # Капец какое шаманство, нифига не понял, но работает #  CustomerKey => 'sAMAccountName',  CustomerID => 'mail',  CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],  CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],  CustomerUserSearchPrefix => '',  CustomerUserSearchSuffix => '*',  CustomerUserSearchListLimit => 10000,  CustomerUserPostMasterSearchFields => ['mail'],  CustomerUserNameFields => ['givenname', 'sn'],  Map => [  # А вот тут уже более менее понятно и даже можно самому поковырять и # # подобавлять поля по своему хотению # # Кстати, поля: Login, Email и CustomerID обязательны! #  [ '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' ],  [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],  ],  };  # Конец конфига #

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

Переходим по адресу helpdesk.domain.ru/otrs/index.pl, вводим логин и пароль доменной учётной записи состояще в группе OTRSagents. Должно всё прокатить. У вновь залогинившегося агента будет отсутствовать вкладка администрирования, включить её можно войдя под учёткой изначального админа, в моём случае это otrs.admin и раздав права доступа новому агенту.

Обратите внимание: агенты создаются в базе OTRS после первого входа.

Так же надо проверить, что OTRS подтянул из LDAP базу Кустомеров. Для этого переходим «Администрирование» — «Учётная запись клиента». Тут мы должны увидить полный перечень пользователей домена в табличном виде, логин, имя, email и т.д.

Проверяем, всё ли успешно подтянулось из домена.

Для доступа же Кустомеров потребуется ещё небольшая доработка, прежде всего потребуется включить Kerberos аутентификацию на папках со скриптами. Скрипты лежат тут /opt/otrs/bin/cgi-bin..

Для включения Kerberos потребуются манипуляции аналогичные тем, что мы проводили на шаге 7 с папкой /var/www/html/php. Открываем файл конфига виртуального хоста otrs:

mcedit /etc/apache2/site-available/otrs.conf

И видим следующие конфигурации локейшена /otrs и директории /opt/otrs/bin/cgi-bin. Первый кусок:

<Location /otrs> #        ErrorDocument 403 /otrs/customer.pl ErrorDocument 403 /otrs/index.pl SetHandler  perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders PerlOptions +SetupEnv  <IfModule mod_version.c> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> <IfVersion >= 2.4> Require all granted </IfVersion> </IfModule> <IfModule !mod_version.c> Order allow,deny Allow from all </IfModule> </Location>

И второй кусок:

<Directory "/opt/otrs/var/httpd/htdocs/"> AllowOverride None  <IfModule mod_version.c> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> <IfVersion >= 2.4> Require all granted </IfVersion> </IfModule> <IfModule !mod_version.c> Order allow,deny  Allow from all </IfModule>  <IfModule mod_filter.c> <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/javascript application/javascript text/css text/xml application/json text/json </IfModule> </IfModule>  # Make sure CSS and JS files are read as UTF8 by the browsers. AddCharset UTF-8 .css AddCharset UTF-8 .js  # Set explicit mime type for woff fonts since it is relatively new and apache may not know about it. AddType application/font-woff .woff  </Directory>

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

Первый кусок:

<Location /otrs> ErrorDocument 403 /otrs/index.pl SetHandler  perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders PerlOptions +SetupEnv AuthType Kerberos AuthName "Kerberos Authntication" KrbAuthRealms RUS.LOCAL Krb5Keytab /etc/httpd.keytab KrbMethodNegotiate On KrbSaveCredentials Off KrbVerifyKDC Off Require valid-user </Location>

Второй кусок:

<Directory "/opt/otrs/bin/cgi-bin/"> AllowOverride All Options +ExecCGI -Includes AuthType Kerberos AuthName "Kerberos Authntication" KrbAuthRealms RUS.LOCAL Krb5Keytab /etc/httpd.keytab KrbMethodNegotiate On KrbSaveCredentials Off KrbVerifyKDC Off Require valid-user </Directory>

После чего перечитаем конфиги Апача и перезапустим его:

service apache2 reload service apache2 restart

После этих манипуляций, при попытке доступа к скриптам OTRS Apache попытается аутентифицировать пользователя и если успешно — загонит его логин в переменную $_ENV[‘REMOTE_USER’], откуда модуль аутентификации OTRS HTTPBasicAuth, считает имя пользователя, прошерстит свою базу и если найдет такого пользователя, то откроет страницу Кустомера в залогинененом виде.

И всё вроде бы ничего, вот только страница Кустомера, если мы сейча попытаемся на неё зайти, скажет нам совсем странную вешь, «Авторизация прошла успешно, но не удалось найти пользователя в базе».

Начинаем отладку. Для этого скачиваем пару скриптов на перле:
whoami.pl
test.pl

Забрасываем их к остальным скриптам OTRS в папку /opt/otrs/bin/cgi-bin, выставляем им права и владельца аналогичного тем, что там уже лежат и пробуем их открыть в браузере.

Первый скрипт просто проверяет наличие переменной $_ENV[‘REMOTE_USER’] и если в ней что-то есть, то выводит сообщение о том, что мы кажется загонились в домене NT c такой-то учёткой, если так и есть, и он показывает нам правильную учётку, то всё ок.

Второй скрипт показывает нам какую строку получает OTRS в качестве логина пользователя. И вот тут-то и видим, что OTRS получает что-то типа username@DOMAIN.RU, но мы то знаем, что в качестве логина у нас используется sAMAccountName, то есть просто username, без домена, да и в списке Клиентов на предыдущем этапе мы так же видели, что логины у нас без имени домена.

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

Благо поправить это совсем просто, хотя пока я разобрался как, ушло прилично сил и времени.

Для этого опять идем в интерфейс Агента, «Администрирование» — «Конфигурация системы» — «Framework» — «Frontend::Customer::Auth», находим параметр Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp, включаем его, а в поле для ввода оставляем то что там есть, для тех кто стёр значение по умолчанию, там должна быть вот такая регулярка
^(.+?)@.+?$
К сожалению регулярные выражения на Perle остаются для меня недоступной магией и запредельным шаманством, поэтому не могу пояснить как оно работает (буду крайне признателен, если кто ни будь даст пояснения в комментах, и я с удовольствием добавлю его в статью) Но в двух словах, оно отбрасывает от имени пользователя всё что после символа «@» включительно.

Жмём «отправить» внизу страницы и топаем по адресу интерфейса Кустомера: helpdesk.domain.ru/otrs/customer.pl
Всё должно работать.

P.S.

В интерфейсе кустомера есть косячёк, на кнопке выхода вместо имени пользователя красуется %c %c, тоесть как-то так «Выход из системы %с %с». Исправляется это очень легко. Открываем файл /opt/otrs/Kernel/Language/ru.pm:
mcedit /opt/otrs/Kernel/Language/ru.pm
Находим строку «%c %c» (обратите внимание символу русские), если не получится, то номер строки 3070, и меняем «%c %c» на «%s %s». Сохраняем и всё ок.

ссылка на оригинал статьи http://habrahabr.ru/post/264617/