OTRS 4.0.10. Ставим на Ubuntu + AD + Kerberos + SSO (Часть вторая)

[icCE]

Осталось только напомнить о тонкой лицензионной политики MS и использованию AD через сторонние средства.
те надо помнить про стандартные Windows Server CAL.

и

Лицензирование при подключении через промежуточное звено («мультиплексор»)

более подробно тут www.microsoft.com/ru-ru/licensing/Products/cla.aspx

Просто хочу предупредить, так как сами напоролись при написание своей системы документооборота с авторизацией через AD.

[Turilion]

Мне кажется вы что-то путаете, на сколько я понимаю модель лицензирования мелкомягких, а совсем недавно мы приобретали SQLServer 2014 и пришлось основательно покопать в этом направлении, в данном случае CAL непричем, клиент не получает никаких данных от продукта и из его баз данных (в нашем случае контролоер АД). Тут можно только сам сервер Апач притянуть за уши как клиента и только. Но и в этом случае смутно. Авторизоваться в домене при загрузке ОС можно, а получать данные со стороннего сервера на основе такой авторизации нельзя, так что ли?
По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?

[icCE]

Как раз ваш апач и выступает в роли мультиплексора. Пользователей же вы берете из AD?
те получается цыпочка

клиент>apache/kerberos>Domain Controller?

Если подключение к серверу Microsoft происходит не напрямую, а через промежуточное звено («мультиплексор») – программное или аппаратное обеспечение, которое уменьшает количество прямых подключений к серверу – то правила лицензирования не меняются. Клиентские лицензии CAL требуются для каждого устройства /пользователя, работающего с мультиплексором.

Например, ERP-система, обращающаяся к SQL-серверу, является таким мультиплексором. Т.е. подключения происходят не непосредственно к СУБД SQL, а опосредованно – через ERP-систему, а к SQL идет только одно прямое подключение – от ERP. Соответственно, компании необходимо приобрести клиентские лицензии на доступ к SQL (SQL Server CAL) по числу пользователей такой ERP-системы.

Для IIS если мне не изменяет память, если не прошли авторизацию AD (те анонимны) — лицензия не требуется.
Вообще с таким вопросом лучше обратится к грамотному интегратору или написать письмо в MS. При этом надо понимать, что это вопрос чисто юридический. Технически ограничений нет.

Сам я сейчас то же особо много чего не скажу, это было уже 4 года назад и детали не особо помнятся.
Но нужно помнить, что есть такая особенность — особенно если мы хотим быть лицензионно честны.

[icCE]

>Авторизоваться в домене при загрузке ОС можно, а получать данные со стороннего сервера на основе такой авторизации нельзя, так что ли?
Для клиентов в стандартной поставке server обычно идет или 5 или 10 cal лицензий. На каждого следующего в организации, если он обращаться к домену надо покупать лицензию. Если вы получаете данные с linux машин(ы), на нее то же надо лицензию + на всех клиентов если она используется как мультиплексор.

[Turilion]

А, вы об этом. Тогда вопрос снят, у нас 5 штук Win2008R2 Interprise Edition лицензированные на ядра. Так что тут траблов не наблюдается.

[Turilion]

По крайней мере в microsoft сказали что ограничений по кол-ву пользователей у нас нет.

[icCE]

Ограничений естественно нет, это вопрос лицензирования.

[Turilion]

Да и в целом, статья не про лицензирование, а про настройку определённой системы в связке с АД, а как лицензировать пользователей в АД это уже личное дело каждого…

[icCE]

Я думаю лишнем это не будет, так как мало кто об этом задумывается до проверки, а потом как правило уже поздно.

[talifan]

Как удалось назначить сервисы для кастомеров притянутых из АД? Что происходит при добавлении нового юзера в АД, как назначается ему сервис?

[Turilion]

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

[FreeBSD]

а SSO для агентов реализовать пробовали?

[Turilion]

Пробовал. Никаких проблем, но делов том, что модуль HTTPBasicAuth, не предполагает какую ли бо проверку на наличие пользователя в определённом OU в домене, а значит любой Кастомер сможет быть и Агентом. Ему достаточно не ввести в конце адреса customer.pl (или стереть это окончание в адресной строке) и у него откроется залогиненый интерфейс агента (что как вы понимаете не есть гут.)

Хотя чисто теоретически можно допилить уже Apache и Kerberos, что бы они занимались подобной фильтрацией, кому можно открывать index.pl и customer.pl, а кому только customer.pl. Подобный функционал есть. Даже знаю к каком направлении копать.

[FreeBSD]

я ограничиваю вот так

/etc/apache2/sites-available/otrs.conf

<Location /otrs>
…
#Require valid-user
Require user [e-mail] [e-mail]


щас играюсь с параметром
Require ldap-group

[Turilion]

Всё верно, именно в это направлении я и хотел предложит поковырять. Если вас не напрягает добавлять сюда всех агентов и следить за актуальностью списка, то как решение вполне подходит.

[FreeBSD]

решилось добавлением этих строк

AuthLDAPUrl ldap://dc.**********.local/DC=*******,DC=local?userPrincipalName
AuthLDAPBindDN CN=otrs,OU=IT,OU=users,OU=all,DC=******,DC=local
AuthLDAPBindPassword "********"
Require ldap-group CN=otrs-agent,OU=IT,OU=users,OU=all,DC=********,DC=local

теперь в АД в группу добавляем агентов

[Turilion]

Как вариант, вполне и вполне. Получается, что апача авторизуется на ЛДАП с помошью учётки otrs@******.local и проверяет состоит ли пользователь в группе.

[Turilion]

Создаете ещё один блок
<Location /otrs/index.pl>
бла-бла-бла про аутентификацию керберос
Require ldap-group OTRSAgents


Что-то типа такого