Пробовал. Никаких проблем, но делов том, что модуль HTTPBasicAuth, не предполагает какую ли бо проверку на наличие пользователя в определённом OU в домене, а значит любой Кастомер сможет быть и Агентом. Ему достаточно не ввести в конце адреса customer.pl (или стереть это окончание в адресной строке) и у него откроется залогиненый интерфейс агента (что как вы понимаете не есть гут.)
Хотя чисто теоретически можно допилить уже Apache и Kerberos, что бы они занимались подобной фильтрацией, кому можно открывать index.pl и customer.pl, а кому только customer.pl. Подобный функционал есть. Даже знаю к каком направлении копать.
Аналогично. До сих пор помню серийники от всех своих операционок и софта, а так же все пароли и много номеров телефонов. А год рождения жены постоянно забываю(
Я держу в организации почтовый сервер на IMAP, делаю рассылку под 300-400мб ежедневно, как вы думаете как скоро кончится место у меня в исходящих? И зачем мне вообще держать для этих целей ящик, мне достаточно только адрес. Для перфекционистов вроде вас, могу предложит забить в postfix правило безусловной переадресации с адреса noreply@domain на, например, info@domain.
Или радикальное решение, давайте просто рассылку будем делать с info@domain.
Как правило такого ящика и не существует вовсе… Внезапно, почтовый ящик и почтовый адрес совсем не одно и то же и для отправки письма необходимо указать почтовый адрес отправителя (так от нас требует протокол), но это не знакчит, что по этому адресу должен существовать ящик… Так что указание фейкового noreply@domain это просто вынужденный ход, иначе сервер просто не примет такое письмо. А куда слать ответы можно указать и в теле самого письма. А-ля «если у вас возникли вопросы по поводу $Theme1, то пишите на $mail1, если по поводу $Theme2, то пишите на $mail2» и всё…
Да и в целом, статья не про лицензирование, а про настройку определённой системы в связке с АД, а как лицензировать пользователей в АД это уже личное дело каждого…
Сервисы пока не назначали, да и вряд ли будем, у нас всего три очереди получается пока что, и все кастомеры имеют доступ к этим очередям. Но в остальном принцип работы должен остаться таким же как при работе с пользователями в базе. Никакой разницы быть не должно.
Мне кажется вы что-то путаете, на сколько я понимаю модель лицензирования мелкомягких, а совсем недавно мы приобретали SQLServer 2014 и пришлось основательно покопать в этом направлении, в данном случае CAL непричем, клиент не получает никаких данных от продукта и из его баз данных (в нашем случае контролоер АД). Тут можно только сам сервер Апач притянуть за уши как клиента и только. Но и в этом случае смутно. Авторизоваться в домене при загрузке ОС можно, а получать данные со стороннего сервера на основе такой авторизации нельзя, так что ли?
По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?
Ну если так, то и тут есть куча более простых решений, навскидку сразу USB-over-Network. Клиент-серверная фигня, причём позволяет пробросить что угодно куда угодно, главное, что бы были USB.
PS к тому же кроссплатформенная, и когда последний раз смотрел была ещё и бесплатная)
Не совсем понимаю зачем такой огород городить, если устройство можно просто воткнуть в usb порт на хосте и пробросить в виртуалку штатными средствами qemu.
Хотя чисто теоретически можно допилить уже Apache и Kerberos, что бы они занимались подобной фильтрацией, кому можно открывать index.pl и customer.pl, а кому только customer.pl. Подобный функционал есть. Даже знаю к каком направлении копать.
Или радикальное решение, давайте просто рассылку будем делать с info@domain.
По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?
PS к тому же кроссплатформенная, и когда последний раз смотрел была ещё и бесплатная)
При это вполне понятная мне конструкция типа username = replace(username,'@DOMAIN.RU') хоть ты тресни, не прокатывает.