Pull to refresh

Comments 18

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

и

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

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

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

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

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

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


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

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

А, вы об этом. Тогда вопрос снят, у нас 5 штук Win2008R2 Interprise Edition лицензированные на ядра. Так что тут траблов не наблюдается.
По крайней мере в microsoft сказали что ограничений по кол-ву пользователей у нас нет.
Ограничений естественно нет, это вопрос лицензирования.
Да и в целом, статья не про лицензирование, а про настройку определённой системы в связке с АД, а как лицензировать пользователей в АД это уже личное дело каждого…
Я думаю лишнем это не будет, так как мало кто об этом задумывается до проверки, а потом как правило уже поздно.
Как удалось назначить сервисы для кастомеров притянутых из АД? Что происходит при добавлении нового юзера в АД, как назначается ему сервис?
Сервисы пока не назначали, да и вряд ли будем, у нас всего три очереди получается пока что, и все кастомеры имеют доступ к этим очередям. Но в остальном принцип работы должен остаться таким же как при работе с пользователями в базе. Никакой разницы быть не должно.
а SSO для агентов реализовать пробовали?
Пробовал. Никаких проблем, но делов том, что модуль HTTPBasicAuth, не предполагает какую ли бо проверку на наличие пользователя в определённом OU в домене, а значит любой Кастомер сможет быть и Агентом. Ему достаточно не ввести в конце адреса customer.pl (или стереть это окончание в адресной строке) и у него откроется залогиненый интерфейс агента (что как вы понимаете не есть гут.)

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

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

<Location /otrs>

#Require valid-user
Require user test@DOMAIN.LOC test1@DOMAIN.LOC


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

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

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

теперь в АД в группу добавляем агентов
Как вариант, вполне и вполне. Получается, что апача авторизуется на ЛДАП с помошью учётки otrs@******.local и проверяет состоит ли пользователь в группе.
Создаете ещё один блок
<Location /otrs/index.pl>
бла-бла-бла про аутентификацию керберос
Require ldap-group OTRSAgents


Что-то типа такого
Only those users with full accounts are able to leave comments. Log in, please.