Я держу в организации почтовый сервер на 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 в пользу nginx, но это значит отказаться от Kerberos (а это не только SSO, это в принципе безопасная аутентификация), либо ставить OTRS на IIS, а тут вам ещё и прожорливую графику придется держать и за лицензию платить)
Так что из трех зол, как говорится.
Хотя кто-то ради пары освобожденных мегабайт оперативки на сервер готов заставить по несколько раз вводить пароли тысячный штат организации, держать в актуальном состоянии соответствующую базу и восстанавливать по 10-20 забытых паролей в день.
На мой взгляд дискуссия на тему SSO но на Apache или на nginx но без SSO, не имеет смысла. Ответ очевиден.
Ни в коем случае не оспариваю ваше утверждение, более того, понимаю что так оно намного проще и должно быть. Ещё когда пытался разобраться с Kerberos, так себе и представлял этот механизм. Но упрямая википедия немного ввела в диссонанс, сообщив что:
Если клиент хочет обратиться к серверу, Он посылает сообщение KDC. KDC направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени. Назначение этих ключей – проведение аутентификации клиента и сервера
Решил не спорить с ней и написал в статье как написано там.
Хотя в той же вики написанно
на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным
Возможно речь идёт о механизме сеансовых мандатов, о которых, как я понимаю вы и говорите.
Или радикальное решение, давайте просто рассылку будем делать с info@domain.
По вашей логике если я подниму вебсервер на IIS мне придется покупать CAL на каждого посетителя моего сайта?
PS к тому же кроссплатформенная, и когда последний раз смотрел была ещё и бесплатная)
При это вполне понятная мне конструкция типа username = replace(username,'@DOMAIN.RU') хоть ты тресни, не прокатывает.
Так что из трех зол, как говорится.
Хотя кто-то ради пары освобожденных мегабайт оперативки на сервер готов заставить по несколько раз вводить пароли тысячный штат организации, держать в актуальном состоянии соответствующую базу и восстанавливать по 10-20 забытых паролей в день.
На мой взгляд дискуссия на тему SSO но на Apache или на nginx но без SSO, не имеет смысла. Ответ очевиден.
Решил не спорить с ней и написал в статье как написано там.
Хотя в той же вики написанно
Возможно речь идёт о механизме сеансовых мандатов, о которых, как я понимаю вы и говорите.