LINUX.ORG.RU
решено Форум — Admin  

Помогите с организацией доступа к LDAP

 


0

1

Изучаю LDAP с целью хранения пользовательских учеток для разных сервисов: Samba, Squid и т.п. Возник вопрос по организации досупа к каталогу. Подскажите как корректнее поступить.

Имеется сервер N1 с LDAP и сервер N2 с Samba. На серваке N2 установлен nslcd для получения данных об учетках пользователей. В его конфиге (nslcd) предалагается добавить учетную запись LDAP для просмотра каталога (параметр binddn), а также учетку rootDN (параметр rootpwmoddn). Правильно ли я понимаю то, что учетка rootDN должна указываться только если я хочу менять пароли пользователей с данного сервера?

Каким образом корректнее сделать пользователя для просмотра каталога в nslcd (binddn)? Могу ли я добавить пользователя в том-же виде, как определен rootDN? Например:

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: password

dn: cn=nslcd,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: nslcd
description: nslcd user
userPassword:: password
★★

вопрос мало касается LDAP, в названии и тэгах должен быть этот демон кэширования.

Каким образом корректнее сделать пользователя для просмотра каталога в nslcd (binddn)?

Сделай да укажи в конфиге. Как ты его назовешь твоё дело. И то и другое подойдёт. Главное этому пользователю дать права на чтение соотв. ветки, где нужная демону инфа хранится.

mos ★★☆☆☆
()
Ответ на: комментарий от mos

Спасибо за ответ. Я видимо не правильно сформулировал.

Как я понимаю, многие сервисы (в том числе и nslcd) используют для просмотра информации какую-либо учетную запись в LDAP, давать им rootDN (если им не требуется информация о паролях) не очень безопасно. Поэтому и хочу узнать, каким образом правильнее (может быть более общепринято) заводить учетки для таких нужд.

Есть вариант создавать учетки как в примере выше, а есть вариант создавать их также как обычные учетные записи пользователей (типа posixAccount). Как лучше?

static ★★
() автор топика
Ответ на: комментарий от static

Есть вариант создавать учетки как в примере выше, а есть вариант создавать их также как обычные учетные записи пользователей (типа posixAccount). Как лучше?

Не имеет значения. Если нет нужды держать uid/gid/shell/home для учетной записи - ей не нужен класс posixAccount. Кроме того можно в любой момент поменять учетную запись, добавив ей класс и атрибуты, или наоборот - удалив класс и атрибуты.

Nastishka ★★★★★
()
Ответ на: комментарий от static

1)
Всё, что хочет как-то взаимодействовать с LDAP «использует какую-либо учетную запись». Только это называется binddn. bind - в данном случае обратиться, dn (distinguished name) - каким именем представиться серверу LDAP.

2)
«информацию о паролях» доступна не исключительно rootDN, а тому dn (binddn) кому разрешено (средствами LDAP ACL) её читать/писать. часто этот ACL выглядит так: to attrs=userPassword,userPKCS12 by self write by anonymous auth by * none
можно добавить перед by * none что-нибудь типа by cn=nslcd,ou=srv,dc=example,dc=org write

3) «учетки» не бывают обычными или не обычными - у них есть разный objectClass. думаю simplesecurityobject для таких «учеток» и придуман, по крайней мере, как я понимаю, объекты с этим классом так используют.

mos ★★☆☆☆
()
Ответ на: комментарий от static

да, еще dn (distinguished name) используется в отношении LDAP совсем не только в процессе обращения к серверу, это вообще столбовое понятие - если говорить просто, то идентификатор любого объекта. справа корень дерева, и налево пошла через запятую можно сказать цепочка по которой с правого края будет rdn (relative distinguished name) - имя собственно объекта. uid=vasya,ou=zhitely,dc=muhosransk,dc=ru

и понятия учетка как такого тоже конечно нет, всё есть объект (запись) в дереве справочника (т.е. собственно directory). а уже для запрашивающей программы объект там может являться чем она его считает. и использует для своих нужд (показывает как контакт в телефоне, или даёт залогиниться на сервер. или узнает какой ресурс примаунтить в точке монитрвания. вариантов масса).

mos ★★☆☆☆
()
Ответ на: комментарий от mos

Да, я себе примерно так все и представляю.

Изучаю по руководству администратора с http://www.pro-ldap.ru. Там все конечно достаточно подробно расписано, но нехватает примеров касающихся организации. Наподобии того о чем я спрашивал.

Сейчас как-раз разбираюсь с ACL и сразу решил убрать анонимный доступ, а всем остальным разрешить только необходимое.

static ★★
() автор топика
Ответ на: комментарий от static

Во-первых, я бы использовал как можно больше руководств.
Во-вторых, из них как можно меньше русских.)
В-третьих, я бы повременил с действиями типа всё всем запретил и т.д.

mos ★★☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin