[Comm] LDAP и PAM: вопрос для повышения образованности

[Comm] LDAP и PAM: вопрос для повышения образованности

[Денис Черносов]

Настраиваю Ldap по этой инструкции:
http://www.altlinux.org/OpenLDAP

Всё понятно, кроме одного момента: даже с TLS не хочется подключаться
к LDAP через какого-то прокси-юзера или разрешать всем анонимам читать
пароли юзеров. В первом случае дыра в безопасности, связанная с
хранением настроек прокси-юзера на каждой рабочей станции (которую
могут банально унести и прочитать файл с другой системы). Во втором -
дыра с доступом к OpenLDAP.

Есть ли какой-то способ заставить pam формировать binddn динамически,
в зависимости от проверяемого клиента?

Сейчас я вижу в логах сервера:

Jan  6 12:56:13 gate slapd[30060]: conn=478 fd=39 ACCEPT from
IP=<wks_ip>:52928 (IP=0.0.0.0:636)
Jan  6 12:56:13 gate slapd[30060]: conn=478 fd=39 TLS established
tls_ssf=256 ssf=256
->   Jan  6 12:56:13 gate slapd[30060]: conn=478 op=0 BIND dn="" method=128
Jan  6 12:56:13 gate slapd[30060]: conn=478 op=0 RESULT tag=97 err=0 text=
Jan  6 12:56:13 gate slapd[30060]: conn=478 op=1 SRCH
base="ou=People,<base_dn>" scope=1 deref=0
filter="(&(objectClass=posixAccount)(uid=admin))"
Jan  6 12:56:13 gate slapd[30060]: conn=478 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Jan  6 12:56:13 gate slapd[30060]: conn=478 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jan  6 12:56:15 gate slapd[30060]: conn=478 fd=39 closed (connection lost)


Можно сделать так:

->   Jan  6 12:56:13 gate slapd[30060]: conn=478 op=0 BIND
dn="cn=proxy-root,ou=People,<base_dn>" method=128


А хотелось бы видеть что-то типа:


>Jan  6 12:56:13 gate slapd[30060]: conn=478 op=0 BIND dn="cn=admin,ou=People,<base_dn>" method=128
...

Со всеми вытекающими.

Возможно ли это в принципе? Или может я зря этого хочу?

Re: [Comm] LDAP и PAM: вопрос для повышения образованности

[Dmitriy M. Maslennikov]

Может вам вообще не хранить пароли в LDAP, а использовать Kerberos?
Это гораздо безопаснее.

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] LDAP и PAM: вопрос для повышения образованности

[Денис Черносов]

6 января 2009 г. 13:38 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> Может вам вообще не хранить пароли в LDAP, а использовать Kerberos?
> Это гораздо безопаснее.
>
> То есть LDAP используется как протокол для получения информации о
> пользователях, а проверкой паролей (аутентификацией) занимается
> Kerberos. Кроме того вы сможете работать теми же пользователями со
> всеми сетевыми сервисами, которые поддерживают Kerberos, не давая им
> доступа к паролям и не передавая его по сети.
>

А есть инструкция? А то у меня от внедрения LDAP немного крыша едет
(перфекционизм проклятый - всё хочется до тонкостей разобрать, а не
просто под кальку заделать). Опасаюсь, что Kerberos мой проект вообще
в долгострой превратит...

Re: [Comm] LDAP и PAM: вопрос для повышения образованности

[Timur Batyrshin]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

On Tue, 6 Jan 2009 13:32:02 +0400
Денис Черносов wrote:

> Настраиваю Ldap по этой инструкции:
> http://www.altlinux.org/OpenLDAP
> 
> Всё понятно, кроме одного момента: даже с TLS не хочется подключаться
> к LDAP через какого-то прокси-юзера или разрешать всем анонимам читать
> пароли юзеров. В первом случае дыра в безопасности, связанная с
> хранением настроек прокси-юзера на каждой рабочей станции (которую
> могут банально унести и прочитать файл с другой системы). Во втором -
> дыра с доступом к OpenLDAP.

Раздел Секьюрити/Корректный ACL прочитали?
Там как раз есть ACL о том, чтобы позволить менять пароль пользователя
самому пользователю и админу, анонимам проходить аутентификацию и
запретить все остальные операции с полем userPassword.
Они указываются в конфигах сервера LDAP.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] LDAP и PAM: вопрос для повышения образованности

[Dmitriy M. Maslennikov]

6 января 2009 г. 12:46 пользователь Денис Черносов
<denis0.ru@gmail.com> написал:
> А есть инструкция? А то у меня от внедрения LDAP немного крыша едет
> (перфекционизм проклятый - всё хочется до тонкостей разобрать, а не
> просто под кальку заделать). Опасаюсь, что Kerberos мой проект вообще
> в долгострой превратит...
У меня только в голове. И я LDAP уже очень давно не занимался. Могу
только вводную дать: Kerberos - это протокол, который состоит из трех:
соединение с KDC сервером (представление клиента и получение ключа для
быстрого обращения к KDC серверу в дальнейшем), получение ключа от KDC
сервера к требуемому серверу. Обращение к требуемому серверу.

Из всего этого следует, что необходимо настроить KDC сервер, который
хранит пользователей в виде <имя>@<REALM>, и сервисы в похожем виде (в
имени используется префикс в виде типа сервиса с полным доменным
именем сервиса) и пароли пользователей и сервисов (для взаимной
аутентификации). Соответственно выбираем REALM (обычно имя домена
записанное в верхнем регистре), создаем базу данных, указываем
используемые протоколы шифрования, заводим всех пользователей (есть
всякие графические штуковины, которые еще сразу в LDAP записи заводят
и прочее, можно вручную...), и все необходимые сервисы (как минимум
вам понадобиться ваш LDAP сервер). После этого настраиваете LDAP
сервер, так, чтобы он мог аутентифицировать пользователей с помощью
Kerberos (GSSAPI так может).

После этого вы используете nss_ldap для получения данных
пользователей, а pam_krb5 для входа пользователей в систему. PAM
модуль пытается получить TGT (Ticket Grant Ticket) с паролем
пользователя у KDC. Если получилось - пользователь входит в систему.
Кроме того данный билет сохраняется для пользователя и используется
автоматически при подключении к тому же ldap (например NSS модулем). О
настройке LDAP толком ничего не помню, кроме того, что она у меня
работала, и LDAP серверу надо указать, как имя пользователя отобразить
на dn, которое будет ему соответствовать. Это общий принцип. О
настройке конкретных вещей к соответствующим руководствам.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [Comm] LDAP и PAM: вопрос для повышения образованности

[Денис Черносов]

6 января 2009 г. 14:13 пользователь Timur Batyrshin <batyrshin@ieml.ru> написал:
> On Tue, 6 Jan 2009 13:32:02 +0400
> Денис Черносов wrote:
>
>> Настраиваю Ldap по этой инструкции:
>> http://www.altlinux.org/OpenLDAP
>>
>> Всё понятно, кроме одного момента: даже с TLS не хочется подключаться
>> к LDAP через какого-то прокси-юзера или разрешать всем анонимам читать
>> пароли юзеров. В первом случае дыра в безопасности, связанная с
>> хранением настроек прокси-юзера на каждой рабочей станции (которую
>> могут банально унести и прочитать файл с другой системы). Во втором -
>> дыра с доступом к OpenLDAP.
>
> Раздел Секьюрити/Корректный ACL прочитали?
> Там как раз есть ACL о том, чтобы позволить менять пароль пользователя
> самому пользователю и админу, анонимам проходить аутентификацию и
> запретить все остальные операции с полем userPassword.
> Они указываются в конфигах сервера LDAP.

Читал. Именно этот акл я и поставил (точнее оставил по умолчанию). Но.
К LDAP обращается не юзер, а PAM-модуль и/или nss. И всегда либо
анонимно, либо от bind_dn, либо (если речь идет про поиск рутовой
учетки) от root_bind_dn. Что я и пытался показать на логах
ldap-сервера.

Если речь идет об интеграции, например, самбы и LDAP, то проблем
особых в таком подходе нет - подразумевается, что эти службы либо
находятся на одном сервере, либо на разных, но серверах (которых по
определению меньше, чем клиентов и наблюдают за ними строже, чем за
остальными). Опять же, им [службам типа самбы] реально нужно юзеров
добавлять/удалять/модифицировать.

Но когда на каждом клиенте светится учетка LDAP, которая позволяет
считать (а вообще и записать и стереть) учетные данные всего домена,
то это уже как-то не очень красиво...

Ввиду того, что у меня контора не сверхбольшая и отношения к гос.
тайне не имеет, то я, пожалуй, утрусь и сделаю по-простому. Но если
возникнет задача спроектировать и внедрить сеть сторонней организации
за какие-то деньги и под какие-то обязательства, то я уже буду чесать
репу в пользу других вариантов. Наверное, того же Kerberos. Хотя это и
усложняет систему за счет доп. компонента, без которого даже в сеть не
зайдешь.

И все же мне не очень понятно, почему нельзя формировать bind_dn
динамически при запросе от pam_ldap.so (если nss_ldap запрашивает
только общую информацию, то для нее (него?) как раз можно сделать
отдельную учетку в ldap, без права просмотра атрибутов UserPassword и
подобных).
Возможно это связано с быстродействием... Возможно еще с чем-то. А
может просто никто до этого не заморачивался.

Может запрос на улучшение pam_ldap сделать в багзиллу?