Вииду того, что статья и так получилась слишком большая, а к тому же хочеться добавить к ней её пару нюансов разбиваю её на несколько частей, и дальнейшие дополнения буду публиковать как отдельные части.
Часть первая: подготовка системы
Часть вторая: установка и настройка OTRS
Часть третья: исправляем косяки прикручиваем плюшки
Любая достаточно крупная организация рано или поздно сталкивается с необходимостью внедрения системы тикетов или helpdesk. И наша организация не исключение, в связи с чем руководством была поставлена задача выбрать и внедрить систему.
Откровенно говоря сомнений по поводу выбора особых не было, по личным соображениям выбор пал на OTRS. Мощная и гибкая с огромным количеством отчётов, которые так любит руководство. Но как оказалось внедрить её совсем нетривиальная задача. Мучения продолжались две недели, были перелопачены тонны инофрмации, перепробовано куча различных мануалов, и складывалось впечатление, что я либо полный кретин, либо одно из двух, потому как во всех мануалах и в куче отзывов все в один голос утверждали что всё работает и отлично ставиться и настраивается, а у меня ни как.
На самом деле проблема всех этих мануалов в том, что всё вроде бы так же как у тебя, но где-то чуть-чуть не та версия пакета, чуть чуть не такая структура AD и т. д. Вот из-за всех этих чуть чуть и не складывается цветок каменный. Одним словом методом проб и ошибок, чтений документации и анализа мануалов был выработан свой, вполне рабочий метод, который я и хотел бы изложить.
Вот стандартный набор требований, как я уже и сказал в сети работает корпоративная почта и Jabber, и доп требованием было интегрировать OTRS и с ними тоже. Но так-как статья и так получилась огромная об интеграции OTRS с ними расскажу когда буду писать о них.
На самом деле ставиться OTRS не сложно и даже с AD интегрируется на раз, вся загвоздка была именно в сквозной авторизации или (SSO). В сети было найдено куча мануалов на этот счёт, но ни один мне не подошел по разным причинам, в одном OTRS ставился на Windows, в другом слишком старая версия OTRS, в третьем использовался модуль-адаптер писанный неизвестно кем и когда.
В целом скажу, что есть 4 способа реализации сквозной авторизации.
Вот последний как раз на мой взгляд (и думаю со мной многие согласятся) самый правильный и безопасный. Итак, исходные данные:
Иная конфигурация тоже возможна из конфига OTRS вы сами поймете как его настроить на другие расположения пользователей и агентов.
Сервер OTRS будет читать информацию из LDAP от имени пользователя otrs.admin, на период настройки дадим ему права администратора домена, после настройки отберём и их и даже право логинеться на машинах, ему нужно просто иметь возможность читать информацию из LDAP.
На финальном этапе установка спросит хотим ли мы предустановить какое-то ПО, выбираем установку OpenSSH сервер.
Соглашаемся принять ключик и вводим пароль пользоваетля helpdesk
Повышаем права до root
! ВНИМАНИЕ! Все дальнейшие действия выполняем от su и после перезагрузок системы не забываем опять поднять права до root.
Проверяем актуальность информации в файлах /etc/hostname и /etc/hosts: в первом должно быть имя нашей машины большими буквами, во втором должна быть запись типа: 127.0.0.1 helpdesk.domain.ru helpdesk
Если что-то не так — исправляем. Теперь пробуем пинговать все контроллеры домена по IP, полному и сокращенному имени. Должны пинговаться по всякому. Если нет, разбираемся с настройками сети.
для не искушенных можно выполнить команды по очереди
Отличная статья по этому поводу есть на сайте техподдержки 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
Ставим необходимые пакеты:
Для работы Kerberos очень важно что бы часы на компьютерах шли синхронно и разница во времени не превышала 5 минут. Настраиваем синхронизацию времени с контролером домена в файле /etc/ntp.conf
Как понятно из названия файл отвечает за настройки демона ntp, который периодически проводит подстройку системных часов. Сервер точного времени задается директивой server, так что нам надо закомментировать все строчки с указанием серверов точного времени которые там есть и вписать свои.
Комментируем все срочки начинающиеся на server:
И вписываем свои:
У меня два контроллера домена и на каждом поднята служба точного времени. После этого сохраняем файл и перезапускаем демона с новыми настройками:
Вывод должен быть таким:
Демон запустился с новыми настройками и синхронизирует часы. Настройка керберос происходит путем правки файла krb5.conf:
Перво наперво включим логи, для этого добавим в самое начало файла секцию:
А дальше надо объяснить kerberos в каком домене (в терминологии Kerberos — в каком реалме) он работает и кто этим реалмом рулит. Для этого правим секции:
Теперь надо проверить работоспособность нашего конфига, для этого попытаемся получить тикет kerberos в домене для какого-нибудь пользователя:
После чего она запросит пароль и попытается получить тикет. Если всё прошло успешно, то команда промолчит, то есть вывод будет пустой. Как-то так:
Проверим, получили ли мы тикет, вводим:
И видим что-то такое:
Как видно, тикет мы получили успешно и всё ОК. Значит конфиг работает. Теперь грохнем тикет, пока что он нам не нужен.
Вывод так же пустой, и значит тикет уничтожился (обратите внимание, команда уничтожает ВСЕ тикеты находящиеся в кеше).
Для этого правим файл /etc/samba/smb.conf:
Здесь правим секцию [global]:
Проверяем корректность конфигурации коммандой:
Вывод будет приблизительно такой:
Нажав Enter, мы увидем скомпилированный smb.conf (то есть без комментариев):
Cообщение «rlimit_max:increasing rlimit_max(1024) to minimum Windows limit(16384)» возникает из-за разницы пула лимитов между Windows и Ubuntu, мы избавимся от него чуть позже, когда поправим лимиты.
Теперь пробуем неспосредственно войти в домен. Для этого исполняем комманду:
Она сначала запросит пароль пользователя и в случае если всё ОК, то вывод будет типа этого:
Проверить корректность подключения к домену можно коммандой:
Её вывод должен быть таким:
Проверить правильность настройки на этом этапе можно попробовав проиндексировать общие ресурсы любой машины в домене. Получаем билет:
И пробуем посмотреть ресурсы любой машины, например файл-сервера:
Ключик -k говорит, что нужно использовать kerberos, File-server — имя машины в домене имеющей расшареные ресурсы. В выводе команды вы должны увидеть список общих ресурсов указанной машины, если да, всё — ок, до настоящего момента всё сделано правильно. После чего уничтожаем тикеты командой:
Для этого правим всё тот же /etc/samba/smb.conf и добавляем в секцию [global] следующие строки:
Проверяем корректность нашей конфигурации:
И если всё ок, перезапускаем демоны (именно в такой последовательности):
Если сервисы перезапустились нормально вывод будет приблизительно такой:
У вас так же? Тогда идём дальше. Пора поправить лимиты, на которые ругается самба. Правятся они в файле/etc/security/limits.conf. Надо дописать в конец файла две строчки:
После этой операции надо перезагрузить машину:
или
Кому как нравиться.
После перезагрузки проверяем установила ли наша машина доверительные отношения с доменом:
Вывод должен быть типа этого:
Напомню, что всё команды выполняются от root'а. Поначалу у меня происходил затык на этом этапе, потому как после ребута забывал повысить права до su. Все секреты (тикеты и пр.) хранятся в базхах самбы /var/lib/samba/private/*.tdb доступ к которым имеет только root. Так что не забываем после перезагрузок повысить права и все команды выполняем от суперпользователя. Также проверяем, что winbind видит пользователей и группы в домене:
и
Раз уж вводим машину в домен, добавим и возможность логиниться на машину под доменными учётками. Для этого в файле /etc/nsswitch.conf добавляем источник данных winbind. Это так же даст нам возможность работать с доменными пользователями как с локальными, а значит назначать их владельцами объектов и давать права на доступ. Что даст возможность поднять шары на линуксовой машине. Приводим строки:
к виду
Так же рекомендуют добавить в конец файла строчку:
Этот этап проверяем запрашивая список пользователей и групп командами:
и
В выводе ищем доменных пользователей и группы и если находим, значит всё ок. И последнее: дадим возможность открывать сессии доменным пользователям, в предыдущих версиях убунту для этого нужны были нетривиальные пляски с ударным инструментом, сейчас же с нашей задачей прекрасно справиться PAM.D, добавляем в файл /etc/pam.d/common-session строчку:
Теперь reboot и пробуем залогиниться под доменной учёткой, если получается, значит все предыдущие этапы выполнены правильно.
На следующие 3 этапа я потратил 2 недели, пока разобрался что к чему. Как это часто бывает всё оказалось довольно просто и завелось с первого раза, нужно было просто проанализировать тонну информации и свести в единую последовательность действий
На этих трёх этапах мне очень помогла вот эта статья.
Итак, протокол Kerberos, это протокол сетевой аутентификации основанный на принципе доверия третьей стороне, так нам говорит справочник. Что это значит? А это значит, что в процессе аутентификации фигурирует третья сторона, которой поумолчанию доверяют участники взаимодействия, такая сторона называется Key Distribution Center, если проще, прежде чем обратиться к серверу, клиент посылает сообщение KDC, а KDC в свою очередь направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени. Назначение этих ключей – проведение аутентификации клиента и сервера.
Для людей знакомых с криптографией скажу, что весь механизм Kerberos чуть более чем полностью копирует механизм PKI. Фактически это он и есть только заточенный под другие задачи. Только вместо центра сертификации данном случае Центр распространения ключей (KDC). Обычно располагается на контроллере домена.
Новое слово «принципиал», в терминологиий Kerberos так называются участники сетевого взаимодействия, то есть те кто обращаются к KDC за ключами.
Выполнить это шаг можно двумя способами сложным и попроще. Почему то все мануалы в сети описывают более сложный способ, а именно создание ключа Kerberos на контроллере домена при помощи утилиты ktpass (страшный зверь с неимоверным количеством ключей) и последующее копирование его на Linux-машину. Я не отрицаю канонической правильности данного пути, но извольте, команда получается в несколько строк и я так и не постиг дзен при её использовании.
Как оказалось есть способ проще — создание ключа непосредственно на Linux-машине. В сетия я нашел только одно упоминание о нём, возможно плохо искал, но он работает.
Так же для того что бы контролировать правильность на данном этапе нам потребуется кое-что сделать на контроллере домена.
Первым делом идём на контроллер и открываем оснастку «AD-пользователи и компьютеры», открываем контейнер с компьютерами и ищем нашу Linux-машину, она должна была там появиться после того как мы её включили в домен. Нашли — ок. Идём дальше.
Теперь нужен редактор ADSI, открываем командную строку, набираем:
И жмём интер. Видим дерево консоли копирующее по своей структуре консоль AD. Находим тут нашу машину, открываем её свойства и ищем в списке атрибут servicePrincipalName. Сейчас там должно быть две записи типа HOST/hepldesk.domain.ru и HOST/helpdesk.
Обе начинаются на HOST в одной полное в другой сокращенное имя нашей машины, это значит что сейчас наша машина принципиал HOST, то есть рядовая машина в домене.
Теперь идём на Линукс-машины и исполняем команду:
Вывод у команды пустой, но после исполнения должен создаться файл /etc/krb5.keytab, или любой другой, смотря что вы указывали в файле smb.conf в директиве dedicated keytab file. Но ведь OTRS, это веб-приложение и наша линукс-машина будет предоставлять услуги http, а значит надо добавить ещё принципиала HTTP. Сказано — сделано:
Если вы теперь посмотрите в список принципалов, в свойствах машины на домене то заметите, что там добавлись еще два — "HTTP/helpdesk.domain.ru" и "HTTP/helpdesk" (маленький нюанс: информация в окне редактора ADSI не обновляется автоматически, поэтому закрываем свойства машины, жмём F5 и снова их открываем).
В принципе это уже значит что добавление прошло успешно. Тем не менее, давайте посмотрим что сейчас находится в keytab:
Для полной уверенности можно получить Kerberos билет от KDC для только что заведенных принципалов:
Смотрим билеты командой:
В выводе будет полный список имеющихся в данный момент билетов, и среди них должны быть билеты HTTP, если есть, то всё ок, и если вы не перфекционист, можно переходить к следующему этапу.
А для остальных скажу, я как раз перфекционист и считаю несколько не правильным хранить все ключи в одном файле, давайте ка выделим всё что касательно HTTP в отельный ключевой файл.Сделать это можно с помощью ktutil. Расширеных функций редактирования она не поддерживает, поэтому его можно запустить через rlwrap.
Загружаем сожержимое keytab-файла:
Просмотрим, что у нас сейчас есть в нём:
Нас интересует всё что начинается с HTTP, всё лишнее удаляем:
Должно получится как-то так:
Теперь сохраним всё что осталось в отдельный файл:
И выходим из утилиты:
Отличный мануал по настройке сервисов в Ubuntu 14 вот тут
.
Вот не знаю как для вас, а для меня если веб-сервер, то LAMP, так что ставим весь стек сразу, тем более что MySQL и Apache нам и так нужно, а в php есть удобная функция phpinfo(); с помощью которой мы будем мониторить переменные окружения.
Во время установки mysql-server он попросит задать пароль для суперпользователя mysql (root@localhost), попрошу не путать с суперпользователем системным, хоть они и оба root, это разные пользователи. Хотя никто не запрещает указать одинаковые пароли для них. Так вот указываем этот пароль и запоминаем его, он нам ещё будет нужен.
После того как поставятся все пакеты нам надо будет сразу немного настроить MySQL, для этого открываем файл /etc/mysql/my.cnf:
Находим в файле две строчки с указанием максимального размера принимаемых пакетов. Строчки начинаются max_allowed_packet. По умолчанию этот артибут выставлен в 16 мегабайт, меняем на 20 Мб в обеих строчках:
А также надо изменить размер лог-файла innodb, насколько я понял это аналог лога транзакций в MS SQL. Для этого надо найти такую строку:
И добавить после неё ещё одну строчку следующего содержания:
Можно сделать и побольше, но OTRS рекомендует именно такой объем. Теперь маленький нюанс: пока старые лог-файлы есть, MySQL не сможет создать новые файлы и соответственно увеличить их объем, поэтому идем в папку /var/lib/mysql и удаляем или перемещаем куда ни будь (лучше переместит, удалить всегда успеем) два файла с именами типа ib_logfile0 и ib_logfile1.
Теперь перезапускаем MySQL:
Проверяем что на месте старых лог-файлов создались новые увеличенного объема, значит всё ОК. После этого открываем браузер на соседней машине и заходим по адресу helpdesk, должна открыться стартовая страница Apache2. Открылась? Значит всё ок —Apache установлен.
Объясним Апачу что делать со скриптами PHP и PERL, для этого в файле /etc/apache2/mods-enabled/mime.conf раскоментируем 220-ую строчку AddHandler и приведём её к виду:
А так же добавим за ней ещё одну такого вида:
Теперь включаем модули php5, perl и cgi, а затем перезапустим Apache:
Теперь проверим, всё ли работает. Для этого создадим две дирректории в /var/www/html:
И создадим по тестовому файлу в каждой:
Первый файл (index.php) мы заполняем следующим образом:
Во второй пишем следующее:
Устанавливаем права:
И ещё нюанс: надо объяснить апачу что в дирректории /var/www/html/perl/ лежат скрипты и он может их исполнять. Для этого добавляем в файл /etc/apache2/sites-available/000-default.conf после строки DocumentRoot вот такой блок:
И перезапускаем apachephp5:
Теперь пробуем открыть в браузере адреса helpdesk/perl/index.cgi и helpdesk/php/index.php. Должны открыться, обратите внимание в php скрипте есть небольшой блок, вынесенный на самый верх страницы, текущая дата, и несколько переменных окружения, этот блок нам ещё пригодиться когда мы будем отлаживать Kerberos — аутентификацию.
Также по короткому имени страничка может не открыться и придется вписать полное имя компьютера, то есть helpdesk.domain.ru/php/index.php и helpdesk.domain.ru/perl/index.cgi. Как это исправлять рассматривать не буду, тем более что к теме это относиться мало, скажу только что копать надо в сторону настроек DNS и Apache.
С этим пунктом всё должно быть ещё проще. Ставим модуль:
Включаем его:
Перезапускаем Apache:
И добавляем авторизацию для папки где лежит php-скрипт (на самом деле её включить можно для любой папки, просто в php-скрипте у нас ежё есть блок с выводом переменных окружения, поэтому будет отлаживать на нём). Для этого опять открываем /etc/apache2/sites-available/000-default.conf и добавляем туда после блока для папки perl еще один блок для папки php:
Даём Апачу права читать наш файл с ключами Kerberos:
Рестартуем Apache:
Теперь заходим в браузере по адресу helpdesk/php/index.php и если всё Ок, то мы увидим запрос авторизации. Вводим учетный данные какого либо пользователя домена и нас должно пустить. Если пустило и вверху страницы в строчка Remote_user, Auth_type и Auth_user, вывелись соответствующие значения то всё чудесно. Kerberos аутентификация работает.
Осталась самая малость, сделать эту аутентификацию прозрачной, то есть что бы пользователь не вводил свой логин и пароль, а они брались прямо из его сеанса в домене.
Для этого в первую очередь в файле /etc/apache2/sites-available/000-default.conf исправляем строчку:
на
Теперь настроим браузер пользователя:
В IE надо добавить сайт helpdesk и helpdesk.domain.ru в доверенные:
После чего на вкладке безопасность надо разрешить встроенную аутентификацию Windows.
После чего перезапускаем IE и пробуем зайти на наш скрипт: теперь он не должен спрашивать логин и пароль, а сразу же аутентифицировать пользователя.
Перейдем к настройке Mozilla Firefox, здесь все проще и без перезапусков. Наберите в адресной строке «about:config», в строке фильтра — «network.neg». Впишите свой домен в две строки, как показано на рисунке.
Теперь снова открываем вбраузере helpdesk/php/index.php и если страница открывается сразу не запрашивая логин и пароль и показывает в верхнем блоке полный логин пользователя, поздравляю, прозрачная аутентификация настроена. Мы закончили самый большой и трудный этап во всей работе.
! ВНИМАНИЕ! Все манипуляции в браузере надо проводить с машины залогиненной в домене под доменной учёткой!
Часть первая: подготовка системы
Часть вторая: установка и настройка OTRS
Часть третья: исправляем косяки прикручиваем плюшки
Вместо введения
Любая достаточно крупная организация рано или поздно сталкивается с необходимостью внедрения системы тикетов или 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
И перезапускаем 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
Даём Апачу права читать наш файл с ключами 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 и если страница открывается сразу не запрашивая логин и пароль и показывает в верхнем блоке полный логин пользователя, поздравляю, прозрачная аутентификация настроена. Мы закончили самый большой и трудный этап во всей работе.
! ВНИМАНИЕ! Все манипуляции в браузере надо проводить с машины залогиненной в домене под доменной учёткой!