История изменений

Странная экономия, учитывая что купить пару копий win server standard для контроллеров будет стоить вроде тысяч 40-50 - и никакого гемора с самбой.

Две версии Windows Server 2012 R2 Std - 60 тысяч.

Лицензии клиентского доступа на наш парк (Windows CAL license): 138 тысяч.

Железо где всё это крутить (облака не рассматриваю, так-как это всё же AD, а оно в облаках как-то не очень): пусть даже по 30к на тазики- 60 тысяч. Ну или виртуализация, что также не отменяет расходов.

Итого: 60+138+60 = 258 тысяч.

Шеф сказал: давай попробуем samba. Мы сейчас вообще без домена живём, и в целом успешно живём. У нас крайне большой круг задач, хоть и мало народу. Так что всё равно очень много чего приходится делать руками. Так же у нас очень много легаси ПО и сервисов.

Не понял о чем ты - об обратимом шифровании чтоль?

Нет, нет... Что ты. Я смотри об чём: когда у тебя где-либо вылетает окно с BASIC AUTH - там есть птичка - сохранить пароль. Так вот по факту эта птичка не работает начиная с WinVista. - Нам это нужно при доступе по sharepoint. Так вот они там отключили хранение пароля. И таким образом, если у тебя нету kerberos, при каждом открытии документа через протокол sharepoint у тебя будет вылезать окно - введи логин+пароль.

Ну, я других отличий вроде не вижу от своей схемы, так что дедуктивным методов приходим к выводу... :) Я бы на твоем месте поднял мини-лабу в виртуалках из контроллера домена на винде и прокси для проверки.

Да, ты прав. Просто я удивлён вот чему: формально, я могу сделать сервер kerberos, не только на samba. Могу его сделать на: Windows/samba/MIT kerberos server/389 Directory Server (хоть это тот же MIT но всё же). И т.п. Исходя из моего представления: SQUID вообще не должен ходить на kerberos сервер. Он при запуске (ну и видимо когда истекает срок жизни билета), по keytab авторизуется на kerberos сервере. Затем он ожидает билетов от клиентов. Клиент ему предъявил билет - билет валидный. - Всё, он пропустил. Тут я правда не до конца всё же понял, на счёт сессионых ключей kerberos. Но tcpdump на SQUID не показывает никакой активности в сторону samba, когда люди ходят по Интернету.

Более того: формально, мне домен тоже не нужен. Можно поставить на Windows HOME - клиент MIT Kerberos, получить билет, положить его в хранилище MSLSA: , и иметь SSO. Другое дело, что для конечного пользователя это не очень удобно, и есть там моменты с продлением билета. Но всё же. Удобнее конечно залогиниться в ОС, и сразу иметь SSO. Но формально - и такая схема работает.

Странная экономия, учитывая что купить пару копий win server standard для контроллеров будет стоить вроде тысяч 40-50 - и никакого гемора с самбой.

Две версии Windows Server 2012 R2 Std - 60 тысяч.

Лицензии клиентского доступа на наш парк (Windows CAL license): 138 тысяч.

Железо где всё это крутить (облака не рассматриваю, так-как это всё же AD, а оно в облаках как-то не очень): пусть даже по 30к на тазики- 60 тысяч. Ну или виртуализация, что также не отменяет расходов.

Итого: 60+138+60 = 258 тысяч.

Шеф сказал: давай попробуем samba. Мы сейчас вообще без домена живём, и в целом успешно живём. У нас крайне большой круг задач, хоть и мало народу. Так что всё равно очень много чего приходится делать руками. Так же у нас очень много легаси ПО и сервисов.

Не понял о чем ты - об обратимом шифровании чтоль?

Нет, нет... Что ты. Я смотри об чём: когда у тебя где-либо вылетает окно с BASIC AUTH - там есть птичка - сохранить пароль. Так вот по факту эта птичка не работает начиная с WinVista. - Нам это нужно при доступе по sharepoint. Так вот они там отключили хранение пароля. И таким образом, если у тебя нету kerberos, при каждом открытии документа через протокол sharepoint у тебя будет вылезать окно - введи логин+пароль.

Ну, я других отличий вроде не вижу от своей схемы, так что дедуктивным методов приходим к выводу... :) Я бы на твоем месте поднял мини-лабу в виртуалках из контроллера домена на винде и прокси для проверки.

Да, ты прав. Просто я удивлён вот чему: формально, я могу сделать сервер kerberos, не только на samba. Могу его сделать на: Windows/samba/MIT kerberos server/389 Directory Server (хоть это тот же MIT но всё же). И т.п. Исходя из моего представления: SQUID вообще не должен ходить на kerberos сервер. Он при запуске (ну и видимо когда истекает срок жизни билета), по keytab авторизуется на kerberos сервере. Затем он ожидает билетов от клиентов. Клиент ему предъявил билет - билет валидный. - Всё, он пропустил. Тут я правда не до конца всё же понял, на счёт сессионых ключей kerberos. Но tcpdump на SQUID не показывает никакой активности в сторону samba, когда люди ходят по Интернету.