Comments 18
Осталось только напомнить о тонкой лицензионной политики MS и использованию AD через сторонние средства.
те надо помнить про стандартные Windows Server CAL.
и
Лицензирование при подключении через промежуточное звено («мультиплексор»)
более подробно тут www.microsoft.com/ru-ru/licensing/Products/cla.aspx
Просто хочу предупредить, так как сами напоролись при написание своей системы документооборота с авторизацией через AD.
те надо помнить про стандартные Windows Server CAL.
и
Лицензирование при подключении через промежуточное звено («мультиплексор»)
более подробно тут www.microsoft.com/ru-ru/licensing/Products/cla.aspx
Просто хочу предупредить, так как сами напоролись при написание своей системы документооборота с авторизацией через AD.
Мне кажется вы что-то путаете, на сколько я понимаю модель лицензирования мелкомягких, а совсем недавно мы приобретали SQLServer 2014 и пришлось основательно покопать в этом направлении, в данном случае CAL непричем, клиент не получает никаких данных от продукта и из его баз данных (в нашем случае контролоер АД). Тут можно только сам сервер Апач притянуть за уши как клиента и только. Но и в этом случае смутно. Авторизоваться в домене при загрузке ОС можно, а получать данные со стороннего сервера на основе такой авторизации нельзя, так что ли?
По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?
По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?
Как раз ваш апач и выступает в роли мультиплексора. Пользователей же вы берете из AD?
те получается цыпочка
клиент>apache/kerberos>Domain Controller?
Для IIS если мне не изменяет память, если не прошли авторизацию AD (те анонимны) — лицензия не требуется.
Вообще с таким вопросом лучше обратится к грамотному интегратору или написать письмо в MS. При этом надо понимать, что это вопрос чисто юридический. Технически ограничений нет.
Сам я сейчас то же особо много чего не скажу, это было уже 4 года назад и детали не особо помнятся.
Но нужно помнить, что есть такая особенность — особенно если мы хотим быть лицензионно честны.
те получается цыпочка
клиент>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 машин(ы), на нее то же надо лицензию + на всех клиентов если она используется как мультиплексор.
Для клиентов в стандартной поставке server обычно идет или 5 или 10 cal лицензий. На каждого следующего в организации, если он обращаться к домену надо покупать лицензию. Если вы получаете данные с linux машин(ы), на нее то же надо лицензию + на всех клиентов если она используется как мультиплексор.
Да и в целом, статья не про лицензирование, а про настройку определённой системы в связке с АД, а как лицензировать пользователей в АД это уже личное дело каждого…
Как удалось назначить сервисы для кастомеров притянутых из АД? Что происходит при добавлении нового юзера в АД, как назначается ему сервис?
а SSO для агентов реализовать пробовали?
Пробовал. Никаких проблем, но делов том, что модуль HTTPBasicAuth, не предполагает какую ли бо проверку на наличие пользователя в определённом OU в домене, а значит любой Кастомер сможет быть и Агентом. Ему достаточно не ввести в конце адреса customer.pl (или стереть это окончание в адресной строке) и у него откроется залогиненый интерфейс агента (что как вы понимаете не есть гут.)
Хотя чисто теоретически можно допилить уже Apache и Kerberos, что бы они занимались подобной фильтрацией, кому можно открывать index.pl и customer.pl, а кому только 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
/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
теперь в АД в группу добавляем агентов
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
теперь в АД в группу добавляем агентов
Создаете ещё один блок
<Location /otrs/index.pl>
бла-бла-бла про аутентификацию керберос
Require ldap-group OTRSAgents
Что-то типа такого
<Location /otrs/index.pl>
бла-бла-бла про аутентификацию керберос
Require ldap-group OTRSAgents
Что-то типа такого
Sign up to leave a comment.
OTRS 4.0.10. Ставим на Ubuntu + AD + Kerberos + SSO (Часть вторая)