Posts Tagged ‘ldap’

Debian: Аутентификация и авторизация пользователей с помощью LDAP

Написал admin . Опубликовано в Unix просмотров 4 671

Так себеПойдетХорошоПонравилосьОтличный пост (1 votes, average: 5,00 out of 5)
Загрузка...

Начнем с того, что хранение всей информации для аутентификации пользователя, в одном месте — это и хорошо и плохо. Хорошо, потому что удобно администрировать аккаунты пользователей, быстро разворачивать системы и сервисы в сети и тд. Плохо, потому что опасно как со стороны безопасности, так и со стороны отказоустойчивости. Но от этих минусов есть рецепты, поэтому единое хранилище больше хорошо, чем плохо…

Теперь о том, чего нам необходимо добиться.

1. Получить резолвинг имен пользователей и групп из каталога LDAP
2. Разрешить аутентификацию пользователей с помощью LDAP
3. Разграничить права доступа на тот или иной сервер (не всем нужно иметь доступ на все сервера допустим по ssh)
4. Разрешить использовать sudo информацию из LDAP
5. Хранить и спользовать публичные ssh ключи пользователей для аутентификации в ssh

И так по порядку:

1. NSS-LDAP (Name Services Switch) необходим для подтягивания из LDAP в систему таких данных как имена пользователей, группы и другой информации, которая обычно хранится в файлах каталога /etc

aliases, ethers, group, hosts, netgroup, networks, passwd, protocols, rpc, services , shadow

Репликация LDAP (часть 1)

Написал admin . Опубликовано в Databases, Unix просмотров 901

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Обзор

Репликация LDAP может пригодиться в тех случаях, когда необходимо иметь несколько идентичных копий директорий LDAP. К примеру клиенты директории LDAP географически распределены и локальные копии директории были бы более предпочтительны в плане скорости доступа. Репликацию можно настроить как на полное дерево, так и на отдельные ветки директории.

Стандартная модель репликации LDAP выглядит в виде иерархии, где есть один master сервер и несколько slave (еще их называют shadow) серверов.

Master сервер отвечает за поддержание slave серверов в актуальном состоянии. Все изменения в директории вносятся на нем и по средством репликации переносятся на slave.
Slave сервера предоставляют каталог для поиска пользователям. Все запросы на поиск обрабатывают они, а не master. Все slave сервера соответственно работают в режиме read-only и не позволяют вносить изменения в данные директории. Этим занимается только master сервер. В случае попытки сделать на slave сервере операцию изменения данных (удаление, изменение или добавление записи), он вернет клиенту ссылку (refferal) на master сервер. Клиент при получении такой ссылки, будет обязан повторно выполнить операцию на предложенном master сервере.