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 и происходит чтение данных.
Да, так без проблем делается, надо будет просто поправить дефолтную конфигурацию тогда. Фидбэк дельный, сенкс.
Only those users with full accounts are able to leave comments. Log in, please.