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

Это как посмотреть… Если всё хозяйство внутри периметра ИМХО поднимать ещё одну подсистему, которую ещё и не всякий админ осилит настроить (это печальный факт) — как то не с руки.
А тут простенький логичный гайд (с некоторыми огрехами, я указал в комментарии ниже), который вполне работоспособен, логичен и в принципе соответствует общей концепции внедрения SSO на сервисах внутри компании с доменом AD.
По крайней мере если бы внедрялся аналогичный сервис от MS (не предназначенный для работы в облаке) он бы использовал реализацию SSO аналогичную описанной, а не ADFS.
Ну я бы не назвал настройку связки с KDC более простой чем WS-Fed с автоконфигом по метаданным ;) Просто с федерацией как раз удобно сделать кейс типа — клиенты в БД, а сотрудники в AD. В предложенном кейсе — всех придется пихать в домен, чего я никак не могу рекомендовать…
Признаю — в Вашей точке зрения тоже есть здравый смысл ;)
Каждый смотрит со своей колокольни — у меня OTRS ассоциируется в первую очередь с поддержкой внутренних пользователей.
Полагаю тут (как и всегда) следует исходить из сценария применения и преследуемых конечных целей.
Вот Вы бы написали подробный гайд как сделать это же только через ADFS с хранение внешних клиентов в БД. Я бы с удовольствием почитал и поставил свой плюсик. Да и не определившимся с реализацией тоже было бы полезно иметь возможность ознакомиться с различными вариантами ;)
Мы съехали с ОТРС. У нас он использовался для поддержки внешних пользователей(клиентов), к сожалению было замкнуто все на АД как в статье и пока не растащили окончательно и есть проблемы с полным совпадением ФИО между сотрудником и клиентом например ;(
Вместо ip-адреса контролера домена лучше задать:
  1. Если на предприятии одна площадка — DNS имя домена
  2. Если предприятие распределённое, то сделать DNS имя (CNAME или A записи кому как нравится), указывающее на контроллеры расположенные на одной площадке с OTRS

Тогда OTRS «не ляжет» во время выполнения работ с каким-нибудь одним DC или по причине его смерти.

С вашими настройками OTRS будет нормально работать только на предприятии где меньше 1000 агентов, потом начнутся приколы.
CustomerUserSearchListLimit => 10000,

Потому, что по-умолчанию MaxPageSize стоит в 1000 и увеличивать её не стоит.
https://support.microsoft.com/en-us/kb/315071?wa=wsignin1.0
Разве что если дадите пользователю helpdesk доменадмина ;)

А в krb.ini лучше включить
dns_lookup_kdc = true

Чтобы KDC по DNS искался. Не будете же вы после добавления нового контроллера домена лазить по всем серверам добавлять его в настройки kerberos!
Все правильно Вы говорите. Однако данная работа проводилась на тестовом стенде.
Это Вы на тестовом стенде делали, а в заголовке написано «tutorial» — уверен хоть кто-нибудь да повторить описанные в статье шаги бездумно ;)
Допустим, я поставил OTRS 4.0.8 на Debian 8. Как мне сделать так чтобы у пользователей была авторизация через AD?
Воспользуйтесь данным руководством. Будет даже проще с установкой керберос. Информации полно в гугле.
Only those users with full accounts are able to leave comments. Log in, please.