Pull to refresh

Comments 10

Было интересно, только вот у меня вопрос возник, я правильно понял, что рабочие станции должны быть под Linux, чтобы использовать этот сервер аутенфикации? Или это не важно? Ну и я не совсем понял для чего этот сервер, для аутенфикации рабочей станции, чтобы из любого места сети можно было подключиться или же это для авторизованного выхода в интернет?
Я просто как раз начинающий, поэтому не совсем знаком с этим.
Я обкатывал это только на Linux. BSD-системы в таком окружении тоже должны работать, но наверняка будут нюансы. Наверняка можно будет и Mac докрутить, PAM и утилиты Kerberos там тоже есть, только глубоко уж очень засунуты. Что до применения, по сути — это снова для построения систем с единой точкой аутентификации. Т.е. использовать один логин/пароль для всего. Можно таким образом связать множество сервисов. Базы данных, файлопомойки, почту, и.т.п. У меня заготовка статьи на эту тему уже есть, но когда я её допишу полностью — хороший вопрос.
Спасибо, ну мне было бы интересно про это почитать. А где используются такие системы и для чего это собственно нужно?
Собственно, самый известный вам пример системы использующей подобную схему — Microsoft Active Directory или Novell eDirectory. Если помните, с пользователями в AD можно связать что угодно. Для чего нужно? Централизация и упрощение администрирования всего зоопарка пользователей и компьютеров в локальной сети предприятия. Вместо генерации кучи паролей к каждому сервису, для каждого юзера достаточно создать один, и что самое главное, этот пароль не будет гулять по сети в открытом виде. Керберизация позволяет также связать служебные сервисы. Например, базы данных. Вместо того, чтобы производить изменения в БД с помощью вебморды какой и опять же передавать где-то там пароль в открытом виде, можно разрешить ходить только вот таким юзерам. Что резко увеличивает безопасность.
Не важно в целом. Даже windows можно подключить для аутентификации.
Тут есть один интересный момент. У вас ldap что позволяет анонимно читать данные в нем?
Позволяет. Но если полностью закрыть anonymous bind, потеряем возможность чтения тех же адресных книг. ACL для LDAP — очень и очень тонкая вещь. И требует очень вдумчивого разбора. Кстати, этим тоже занимаемся в настоящее время.
Технически просто должно происходить как.
1. Пользователь авторизуется в Kerberos V
2. Идет LDAP bind под его учеткой в Kerberos и происходит чтение данных.
Да, так без проблем делается, надо будет просто поправить дефолтную конфигурацию тогда. Фидбэк дельный, сенкс.
Sign up to leave a comment.

Articles