"Aутентификация Squid+Kerberos c LDAP авторизацией в Active Directory (http://blog.ronix.net.ua/2008/08/squidkerberos-c-ldap-active...)"URL: http://blog.ronix.net.ua/2008/08/squidkerberos-c-ldap-active...
Новость: http://www.opennet.me/opennews/art.shtml?num=17431
И вот мне интересно. Ну когда же хоть кто-нибудь напишет нормальную методику использования Active Directory, как средства аутентификации? Чтобы на UNIX'овом хосте висела Samba, являлась членом директории и апдейтила /etc/krb5.keytab, а сервисы аутентицировались _этим кейтабом_ (см. ключ '-k' в kinit(1) -- эта возможность в Kerberos'е есть) _безо всяких там костылей_? Без создания пользователей левых в директории, etc?
А тако ж кто первым поймет, как этот механизм можно использовать для локального кэширования директории через proxy overlay OpenLDAP'а?-)
Так а в чем же дело?
Вот и напишите, если никто до этого не удосужился :)
А мне интересно, зачем вообще это упорное скрещивание ежа и ужа? Для чего делать unix-системы, зарекомендовавшие себя своей надежностью зависимыми от win-систем, которые такой надежностью не страдают? Не хочется юзеров утруждать вводом паролей - делайте привязку по MAC/IP/Ident. Централизация - это не всегда хорошо.
>делайте привязку по MAC/IP/Ident.У таких решений проблемы с масштабированием и юзабельностью.Вот вы не лопните это настраивать для 10 000 машин раскиданых по всей планете?А если надо доступ ремотных сотрудников по VPN?Что, начинаем всасывать?А если доступ сотрудника из дома или ремотного офиса?С другой машины?Ы?В AD в этом плане просто - есть юзер, у него один логин и пароль которые годны для всего что доверяет данным контроллерам домена авторизацию.Есть удобное управление этим зоопарком.С какой именно машины юзер произведет логин вообще по барабану - набор прав и авторизация привязаны только к персоналии юзера.Собственно потому это и юзают.
А чтобы *все* приложения на основе именно этих данных аутентифицировали юзера и решали какие ему права можно?Да и MAC и IP как бы спуфнуть можно.Хапнув практически нахаляву чьи-то неслабые права.А при нужде "вон ту машину" отдать в другой отдел или другому сотруднику - упс... геморройчик с перераздачей прав обеспечен.
AD... нет, было бы желание а при физическом доступе к машине уж как минимум локально выполняемые политики и прочий шыт можно и заоверрайдить внаглую при наличии умений да и на некоторые ограничения будучи локальным админом можно в принципе с прибором положить.А pwned DC разумеется означает что pwned потенциально и вообще все что этому DC доверяло в плане авторизации.Тем не менее, с точки зрения сетевых дел довольно непозорный протокол керберос супротив ламерской привязки по MAC & IP от дебилов - разница однако.
> Централизация - это не всегда хорошо.
For sure. Если вы видите красивого огромного колосса, не забывайте все-таки о том что ноги у него все-таки из глины.AD в этом плане традиций не нарушило.
>>делайте привязку по MAC/IP/Ident.
>У таких решений проблемы с масштабированием и юзабельностью.Вот вы не лопните это
>настраивать для 10 000 машин раскиданых по всей планете?А если надоДа ради бога, не делайте привязку по MAC/IP/Ident, я это для примера привел, потому что КАК ПРАВИЛО - когда заводят речь об аутентификации пользователей squid в AD, подоплека у этого разговора одна - юзеры капризничают и не желают дважды вводить свой пассворд.
Я же считаю, что в данном случае потраченная на скрещивание squid и AD энергия достойна бы более полезного применения - скажем для развертывания LDAP-сервера под управлением unix взамен виндовому AD.
В данном случае лучше разделить слои. Т.е., каждому -- своё. Squid умеет работать с RADIUS. OpenRADIUS, в свою очередь, умеет работать с AD или с IAS (который замечатльно работает с AD). Получается чистая и непорочная *никс-система. То, что надо для спокойного сна линукс-пуриста.
тогда нет смысла в аутентификации вообще - если мы пользователя привязываем к MAC.
а если пользователь перешел на другой комп? тогда не видно кто именно из пользователей этого компа ходил на определенный сайт.
(в комментах к первому посту - я писала об этом)
Это уже другой вопрос, я говорил он нецелесообразности мешать кислое с пресным.Есть вещи, которые целесообразнее всего решать не техническими, а административными мерами. Описанная вами ситуация из этого разряда.
За доступ к "определенным" сайтам должна следовать ответственность. Ответственность несет пользователь, за которым закреплен ПК. Если ПК в силу необходимости пользуются несколько сотрудников - ответственность несут все им пользующиеся в равной степени.
Иначе всегда найдется приемлемая отговорка.
ваш подход для ленивого админа "фашиста", для людей а также их идентификации используються и будут использоваться индивидуальные пароли и ключи
бугага
Вы, должно быть, представляете противоположную сторону - бездельник-порнушник, предпочитающий развлекаться за чужой счет?
Используйте на здоровье ключи и пароли. Перечитайте мой первый пост - вы не дали себе труда до конца его осмыслить.
осмыслением вы себя неутруждаете, мой пост относился к цитирую "Это уже другой вопрос, я говорил он нецелесообразности мешать кислое с пресным" и т.д, а не к более ранним вашим произведениям
"Есть вещи, которые целесообразнее всего решать не техническими, а административными мерами. Описанная вами ситуация из этого разряда." как раз нет. Это и есть техническая мера, т.к. сайты на которые уж точно нельзя ходить - действительно закрыты. С помощью подобной схемы аутентификации- легче отследить куда именно ходил тот или иной сотрудник в нужное время ВНЕ ЗАВИСИМОСТИ от того компьютера который он использовал.
А со случаями обмена паролями пользователями не встречались? Такое происходит, когда =хромает= именно административный ресурс.А как закрыть _все_ сайты, на которые =уж точно нельзя ходить=? (:
Статья понравилась, но... городить AD и настраивать виндовый DNS мне не с руки, а тем, у кого это уже сгорожено, мб установить вместо сквида что-то виндовое? Отсюда и вопрос об =ужах и ежах= вашего оппонента, скорее всего.
>За доступ к "определенным" сайтам должна следовать ответственность.Отлично.А как насчет ситуации: есть файлы на ЛОКАЛЬНОМ сервере, есть юзеры, у некоего юзера есть доступ к нужным по его работе файлам.Допустим машина сдохла.Или ее отдали в другой отдел.Как, видны потенциальные грабельки?Да, если машин 10 - можно и так, с дерганием админа на каждый такой факт (как только не дернули - потенциально дыра в security т.к. посторонний сотрудник м этой машиной автоматически получает чужие права с какого-то хрена).А если машин 10 000 да еще в разных офисах - при таком подходе админу вообще проще будет застрелиться.
В общем у AD есть как минусы так и плюсы (главным из минусов является то что это решение - от такого отвратного вендора как Майкрософт что дает ему в *минус* сто очков форы, решения от MS имхо можно юзать только сугубо как last resort, потому как попадалово на много денег, постоянные дойки и несовместимость с тем за что не уплачено MS и т.п. "счастье" с дорогими лицензиями, дурным ограничиловом, навязанным набором далеко не бесплатного софта, невозможностью слезть по простому с продукции MS и т.п.).
Понятно... отвечаем на те вопросы, на которые отвечать удобно. Вопрос "нахрена скрещивать squid с active directory, если надежность windows-систем по сравнению с unix не выдерживает никакой критики" мы дружно предпочли не заметить.
До свидания, желаю много счастья и немного больше здравого смысла.
>не выдерживает никакой критики" мы дружно предпочли не заметить.Я думаю что это вполне пригодится тем у кого есть виндовая инфраструктура с AD но совсем нет желания платить столько сколько MS хочет за свой ISA например.Кроме того - возня единоразовая и не будет траха с заведением на проксе аккаунтов потому как аккаунты юзеров в этом случае уже есть - в AD, собственно.До некоторой степени практично в ряде ситуаций.Надежность... ну, виндовые машины традиционно уходят в ребут как минимум 1 раз в месяц.
>за свой ISA например.Кроме того - возня единоразовая и не будет
>траха с заведением на проксе аккаунтов потому как аккаунты юзеров в
>этом случае уже есть - в AD, собственно.До некоторой степени практичноНу да. Зато когда заглючивает контроллер домена, у пользователя нет ничего - ни сети, ни интернета, ни почты. Это мы уже проходили. Корпоративную почту отстоять не удалось, купили-таки эксчейндж, зато вскоре после получения вожделенного мелкософтовского продукта прекратились всякие разговоры о дальнейшем изничтожении юникс-серверов в конторе. До покупки exchange почты не было только в одном случае - если вырубалось электричество, после покупки почта вставала колом при каждом чихе в ДНС...
>До покупки exchange почты не было только в одном случае -
>если вырубалось электричество, после покупки почта вставала колом при каждом чихе в ДНС...Открою страшную истину - форточки настраивать - тоже нужна голова и руки :)
Я так юзаю и то и то - беру так сказать лучшее из обеих миров ...
Кстати, насчёт сквида и аторизации, можно radius прикрутить ( и не только к нему).
Я не понимаю, чего все так взъелись. AD, предположим, уже есть. Воротить что-то отдельно? Файлики с MAC-адресами? Заставлять пользователей вводить пароли (RADIUS)? Зачем?Падает AD? Ну дак, ребята, книжки почитайте, железо нормальное купите. Не ставьте всё сразу на одну машину. Реплицируйте, бэкапьтесь.
IMO - отличное решение. Юзерам удобно. Админу удобно. Что ещё надо?
>Я не понимаю, чего все так взъелись. AD, предположим, уже есть. Воротить
>что-то отдельно? Файлики с MAC-адресами? Заставлять пользователей вводить пароли
>Падает AD? Ну дак, ребята, книжки почитайте, железо нормальное купите. Не ставьте
>всё сразу на одну машину. Реплицируйте, бэкапьтесь.Дорогой Ононим. Если бы Вы знали, сколько у нас в конторе серверов, сколько они стоят все вместе и по отдельности, и какого уровня люди все это обслуживают - Вы бы немедленно убились о ближайшую стенку от испепеляющей зависти и осознания собственного ничтожества.
Все Вами перечисленное и весь Ваш личный опыт (несомненно, полученный в последние полгода после покупки второго сервера начального уровня и прочтения толстого талмуда "Администрирования Windows 2003 для чайников") никак не коррелирует с реальным положением дел.
>никак не коррелирует с реальным положением дел.Как же ты прав. Когда обслуживаешь один сервер, не понимаешь, что тут сложного, но когда их второй десяток на тебе и сервисов, ешь их мать, навалом, и разные. Начинаешь нервно думать, что ты сам себя где-то нае..л. А так, MS AD вещь в себе, отказ шлюза (другая машина) в принципе приводил к тому, что почта не заводилась. Только после рестарта самого сервера. Жуть...до сих пор не могу понять из-за чего. Чисто человеческое спасибо.