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

Замість введення

Будь-яка досить велика організація рано чи пізно стикається з необхідністю впровадження системи тікетів або helpdesk. І наша організація не виняток, у зв'язку з чим керівництвом було поставлено завдання вибрати і впровадити систему.

Відверто кажучи сумнівів з приводу вибору особливих не було, з особистих міркувань вибір припав на OTRS. Потужна та гнучка з величезною кількістю звітів, які так любить керівництво. Але як виявилося впровадити її зовсім нетривіальне завдання. Муки тривали два тижні, були перелопачены тонни інофрмацію, перепробовано купа різних мінлива, і складалося враження, що я повний кретин, або одне з двох, тому як у всіх мануалах і в купі відгуків всі в один голос стверджували що все працює відмінно ставитися і налаштовується, а у мене ні як.

Насправді проблема всіх цих мануалів в тому, що все начебто так само як у тебе, але десь трохи не ту версію пакету, трохи не така структура AD і т. д. Ось з-за всіх цих чуть чуть і не складається квітка кам'яний. Одним словом методом проб і помилок, читань документації і аналізу мінлива був вироблений свій, цілком робочий метод, який я і хотів би викласти.

Вихідні дані та вимоги

  • В організації піднято ОГОЛОШЕННЯ на двох контролерах Win2008r2 і раз вже так, то потрібна інтеграція з AD, т. к. на мій погляд інтеграція всього і вся особливо з LDAP «is the true way»
  • Багато сервісів (такі як пошта і Jabber) підняті на Linux, і в якості ОС обрана Ubuntu Server 14.04, і раз вже OTRS це OpenSource, то ставити її на проприетарную ОС це на мій погляд моветон, тому будемо ставити на Ubuntu. До речі, якщо буде цікаво в наступних статтях спробуємо розповім про свій досвід підняття цих сервісів та інтеграції їх з AD і OTRS. (Інтеграція OTRS і Jabber взагалі дуже класна і корисна штука)
  • Можливість швидко підняти на машині файлопомойку для сканування службових записок та ін
  • І останнє, раз у нас є AD, і при включенні комп'ютера користувач все одно вводить свій пароль і система вже на цьому етапі знає хто працює в системі, то треба було б позбавити його зайвих вводів паролів і логінів і реалізувати наскрізну авторизацію.
Ось стандартний набір вимог, як я вже і сказав в мережі працює корпоративна пошта і Jabber, і доп вимогою було інтегрувати OTRS і з ними теж. Але так як стаття і так вийшла величезна про інтеграцію OTRS з ними розповім коли буду писати про них.

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

  1. Перший це SSPI, але він не підходить, бо це модуль для OTRS під Windows
  2. Другий це самописний модуль ADSSO, по суті просто допиленный модуль авторизації LDAP, що на мій погляд милицю.
  3. Третій це знову ж самописний модуль NTLM авторизації для OTRS, що знову ж таки милиця.
  4. І останній — це штатний модуль 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 = UKR
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 (тобто без коментарів):

Повідомлення «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 -- UKR 
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. Це дасть нам можливість працювати з доменними користувачами як з локальними, а значить призначати їх власниками об'єктів і давати права на доступ. Що дасть можливість підняти кулі на линуксовой машині. Наводимо рядки:
пароль:compat
group: compat

до виду
пароль: 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, так що ставимо весь стек відразу, тим більше що Apache MySQL і нам і так треба, а в 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 довірені:

image

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

image

Після чого перезапускаємо 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'} = 'D'; 

# Учетка для підключення до 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-скрипт.
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 as read 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-скрипт.
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». Зберігаємо і все ок.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.