Децентрализованный usermanagement

Я все еще говорю что LDAP, даже, учитывая Ваши протесты. Единая точка отказа централизованной аутентификации является проблемой, это было известно в течение нескольких лет, который является, почему Windows избавился от модели PDC/BDC WinNT и пошел с мультиведущим устройством распределенная модель с Active Directory. eDirectory Novell (очень прекрасный сервер LDAP среди прочего) делал мультиведущее устройство больше 15 лет теперь. Оба могут функционировать хорошо кратковременно разделенные от остальной части сети аутентификации, по медленным каналам WAN, и функционировать несмотря на обычное, подвешивают/перезагружают/восстанавливают процесс, который отмечает весь IT. За исключением расширенных времен простоя (день или больше) это - в основном решенная проблема.

Просто не так в пространстве с открытым исходным кодом, которое я видел. OpenLDAP действительно имеет репликацию между несколькими серверами LDAP, которая дает Вам Вашу отказоустойчивость.

Расширение немного, если у Вас действительно есть среда Active Directory для работы с Samba, идет со способами работать с AD, это сделает мультиосновную обработку идентификационных данных. Если один DC снизится, то он будет говорить с другими. Если Вы не боитесь тихого в разработке Samba 4, можно даже настроить абсолютно основанную на Linux AD среду и использовать winbind на клиент-серверах для обработки распределенного автора.

Простое решение состояло бы в том, чтобы иметь основную систему и задание крона, которое работает на отдельных узлах к rsync passwd, тень и файлы группы регулярно. Похоже на противный, грязный взлом, все же.

В более широком смысле Вы могли использовать марионетку в качестве всего инструмента управления конфигурацией затрагивания. Это включает учетные записи пользователей. В действительности Вы определяете все пользовательские атрибуты и составы группы глобально. Затем на группе машины, или на машину, основание Вы определяете группы или отдельных пользователей, которые имеют доступ к системе. Так как аутентификация и авторизация происходит локально, даже если Ваш puppetmaster снижается, пользователи могут все еще войти в систему. Вы только потеряли бы распространение изменения.

Так как марионетка только управляет теми файлами и обслуживает Вас, явно определяют, это помогает централизованно управлять некоторыми аспектами, пока локально руководящие другие.

Поэтому Active Directory требует (хорошо, почти так или иначе) нескольких серверов. Так, чтобы, когда один из них умирает, Вы не были завинчены.

Если у Вас есть база пользователей какого-либо размера, Вы не хотите полагаться на децентрализованное управление, даже если это через что-то как марионетка. Перемещения Добавляют, и Изменения (MAC) не будут никакой забавой. Вообще. Плюс, без централизованной аутентификации, необходимо будет управлять локальными учетными записями, учетными записями самбы, htaccess учетные записи..., где как Вы/could/централизованно аутентифицируют всех сразу.

Пересмотрите централизованную аутентификацию для своей собственной исправности.

Что-то вроде этого работало бы? По-видимому, они используют MySQL, чтобы масштабировать установку OpenLDAP и копировать его.

Я думаю, что Kerberos может также быть настроен, чтобы быть распределенным. Это - более старая статья, которая обсуждает немного об этом.

Я не знаю, есть ли у Вас какие-либо системы Windows AD в Вашей сети, но если Вы делаете можно настроить модули для аутентификации против этого.

Я все еще говорю, что LDAP является самым легким / лучший выбор. Безумно надежный, очень легкий поддержать. Я выполнял основных/ведомых пар LDAP в производстве в течение нескольких лет теперь без отказа. В моем предыдущем задании они обеспечили аутентификацию для 20 - 30 серверов и сотен рабочих станций. Насколько я знаю они никогда не заменяли в результате отказа. Когда я сознательно заменил бы (перезагрузка / обновление / и т.д.), никто не заметил.

Однако существует решение, которое делает почти точно, что Вы описываете, но с преимуществом того, чтобы быть централизованно управляемым: NIS. Это распределяет passwd, хосты, группу, и т.д. через протокол клиент-сервер, но, насколько я понимаю, полностью способно к продолжению функционировать, если сервер уходит. Это - немного комплекса, но поддерживается каждым *, как будто отклоняют ОС, о которой я могу думать.

LDAP является большим, но он действительно добавляет некоторую сложность, которую Вы не могли бы быть снабжены для обработки. Кроме того, необходимо будет создать инструменты и управление конфигурацией на серверах для работы с LDAP. В то время как модули PAM (Сменные Модули аутентификации) в Linux имеют большое значение в поддержке некоторых Ваших потребностей, они не могут встретить их всех.

Я мог бы также предложить использование чего-то как марионетка (http://reductivelabs.com/products/puppet/). В то время как я не использовал его очень, это может быть хорошо как комплексное решение для Вас вместо LDAP или как средство для добавления инструментов и обращения к случаям, которые не делает LDAP.

хотя это не хорошее, можно копировать ldap базу данных (или часть его) на ldap клиентах (на самом деле, серверы)

слабость этого - то, что база данных повреждается, как ldap клиенты повреждаются, преимущество состоит в том, что у Вас будет много копий, делая Ваши данные невероятно безопасными и если соединение отбрасывает между основными и ведомыми базами данных, можно продолжить использовать копию вместо этого

Я соглашусь с остальными и предложу LDAP. Если Вы действительно хотите локальные passwd файлы, тем не менее, рассматривают генерацию их от LDAP. Вы могли или генерировать их где-нибудь централизованно и затем распределить их (марионетка, rsync, и т.д.), или у Вас мог быть каждый клиент, генерируют его собственное. Если сервер LDAP недоступен, локальный passwd файл должен все еще там возвратиться. Наличие сервера LDAP там и поддержание информации позволяют Вам идти вперед и использовать или создавать инструменты, в которых Вы нуждаетесь для настройки и управления пользователями, поэтому если Вы когда-нибудь решаете доверять своей сети/набору избыточные серверы, у Вас есть очень простой миграционный путь.