[Sysadmins] LDAP+nss_ldap+nscd

[Sysadmins] LDAP+nss_ldap+nscd

[Vasyl Tereshko]

Добрый день,
Люди добрые, подскажите, кто может, а то совсем мозги закипают.
Есть OpenLDAP и там заведены юзеровские эккаунты, настроен на серверах 
nss_ldap и там всё работает.
А теперь задача - поднять это на клиентской машине, где юзер 
потенциально может получить доступ рута и в nss_ldap.conf 
bindrootdn=<bla-bla> и пароль в nss_ldap.secret положить нельзя.
А ещё неплохо бы, чтобы там же работал nscd.
У меня максимум получается, что от рута id <LDAP user> работает, а от 
обычного - нет. Кто-то может поделиться работающими конфигами ?

-- 
Толми

Re: [Sysadmins] LDAP+nss_ldap+nscd

[Vladimir V. Kamarzin]

>>>>> On 16 Jun 2008 at 19:45 "VT" == Vasyl Tereshko writes:

VT> Добрый день,
VT> Люди добрые, подскажите, кто может, а то совсем мозги закипают.
VT> Есть OpenLDAP и там заведены юзеровские эккаунты, настроен на серверах
VT> nss_ldap и там всё работает.
VT> А теперь задача - поднять это на клиентской машине, где юзер
VT> потенциально может получить доступ рута и в nss_ldap.conf
VT> bindrootdn=<bla-bla> и пароль в nss_ldap.secret положить нельзя.
VT> А ещё неплохо бы, чтобы там же работал nscd.
VT> У меня максимум получается, что от рута id <LDAP user> работает, а от
VT> обычного - нет. Кто-то может поделиться работающими конфигами ?

Можно настроить acl-и на ldap-сервере таким образом, чтобы выполненять
простые операции можно было анонимно, тогда нет нужды вообще использовать
rootbinddn.

access to dn.base=""
        by * read
access to dn.base="cn=Subschema"
        by * read

access to dn.subtree=cn=Monitor
        by * read

access to attrs=userPassword,userPKCS12,sambaPwdLastSet,sambaPwdMustChange,sambaPwdCanChange,shadowMax,shadowExpire
        by dn="cn=ldapadmin,dc=distance,dc=ru" write
        by anonymous auth
        by self write
        by * none
access to attrs=shadowLastChange
        by self write
        by * read

# Deny access to imap/fax/kerberos admin passwords stored
# in ldap tree
access to attrs=goImapPassword
        by dn="cn=ldapadmin,dc=distance,dc=ru" write
        by * none
access to attrs=goKrbPassword
        by dn="cn=ldapadmin,dc=distance,dc=ru" write
        by * none
access to attrs=goFaxPassword
        by dn="cn=ldapadmin,dc=distance,dc=ru" write
        by * none

# Let servers write last user attribute
access to attrs=gotoLastUser
        by * write


access to attrs=sambaLmPassword,sambaNtPassword
        by dn="cn=ldapadmin,dc=distance,dc=ru" write
        by dn="cn=smbpasswd smbpasswd,ou=people,dc=distance,dc=ru" read
        by anonymous auth
        by self write
        by * none

-- 
vvk

Postfix page on f.i: http://freesource.info/wiki/Dokumentacija/Postfix

Russian Postfix irc: irc.freenode.net #postfix-ru

Re: [Sysadmins] LDAP+nss_ldap+nscd

[Vasyl Tereshko]

Vladimir V. Kamarzin пишет:
>>>>>> On 16 Jun 2008 at 19:45 "VT" == Vasyl Tereshko writes:
>>>>>>             
>
> VT> Добрый день,
> VT> Люди добрые, подскажите, кто может, а то совсем мозги закипают.
> VT> Есть OpenLDAP и там заведены юзеровские эккаунты, настроен на серверах
> VT> nss_ldap и там всё работает.
> VT> А теперь задача - поднять это на клиентской машине, где юзер
> VT> потенциально может получить доступ рута и в nss_ldap.conf
> VT> bindrootdn=<bla-bla> и пароль в nss_ldap.secret положить нельзя.
> VT> А ещё неплохо бы, чтобы там же работал nscd.
> VT> У меня максимум получается, что от рута id <LDAP user> работает, а от
> VT> обычного - нет. Кто-то может поделиться работающими конфигами ?
>
> Можно настроить acl-и на ldap-сервере таким образом, чтобы выполненять
> простые операции можно было анонимно, тогда нет нужды вообще использовать
> rootbinddn.
>   
Ага, но тогда я должен давать для anonymous например доступ к такой 
чувствительной информации, как вхождение пользователя в те или иные 
группы, что совсем неправильно.
Можно конечно не использовать bindrootdn, а просто binddn, и прописывать 
его для каждой клиентской станции отдельно, положив например его в 
ou=Computers, и потом прописать соответсвующие ACL, но это несколько 
увеличивает объём администрирования. Что-то ничего разумного в голову не 
приходит.
-- 
Толми

Re: [Sysadmins] LDAP+nss_ldap+nscd

[Mykola S. Grechukh]

2008/6/20 Vasyl Tereshko <>:

говорят, сейчас лучше брать nss_ldapd.

> Ага, но тогда я должен давать для anonymous например доступ к такой
> чувствительной информации, как вхождение пользователя в те или иные группы,
> что совсем неправильно.

когда это вхождение пользователя в posix группы стало sensitive ?

Re: [Sysadmins] LDAP+nss_ldap+nscd

[Ivan Fedorov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Можно настроить acl-и на ldap-сервере таким образом, чтобы выполненять
>> простые операции можно было анонимно, тогда нет нужды вообще использовать
>> rootbinddn.
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org

iEYEARECAAYFAkhgHiYACgkQMJy3oC+NmVufsgCcCV3hTMABVdMUX4FcrhwwainT
BW0An0RFi0+SroFXygzS1VxXToNY0i+Y
=74B/
-----END PGP SIGNATURE-----

>
> Ага, но тогда я должен давать для anonymous например доступ к такой
> чувствительной информации, как вхождение пользователя в те или иные группы,
> что совсем неправильно.
Ну если вы так параноидальны, то подключайтесь ко LDAP через TLS с
проверкой клиентских сертификатов. Тогда чужие во LDAP не залезут
точно.

PS: LDAP с шифрованием работает медленнее, так что будьте к этому
готовы. Оно не сильно заметно на единичных запросах, но в скриптах с
ldapadd и Ко, очень даже заметно.

Re: [Sysadmins] LDAP+nss_ldap+nscd

[Vasyl Tereshko]

Ivan Fedorov пишет:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>   
>>> Можно настроить acl-и на ldap-сервере таким образом, чтобы выполненять
>>> простые операции можно было анонимно, тогда нет нужды вообще использовать
>>> rootbinddn.
>>>       
>> Ага, но тогда я должен давать для anonymous например доступ к такой
>> чувствительной информации, как вхождение пользователя в те или иные группы,
>> что совсем неправильно.
>>     
> Ну если вы так параноидальны, то подключайтесь ко LDAP через TLS с
> проверкой клиентских сертификатов. Тогда чужие во LDAP не залезут
> точно.
>   
Чужих как раз я не боюсь, они просто не доберутся до сервера. Я боюсь 
инсайдеров - доморощенных хакеров, которые лезут во все дыры и хотят 
знать всё, что им не положено.
А на группах сделан доступ к ресурсам, соответственно я хочу, чтобы 
только члены этой группы могли знать кто ещё, кроме него самого имеет 
доступ к ресурсу.

PS А раздать 200-300 пар сертификатов и потом их поддерживать тоже 
веселая задача. Это уж в сторону PKI тогда нужно смотреть...

-- 
Толми

Re: [Sysadmins] LDAP+nss_ldap+nscd

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

24 июня 2008 г. 3:07 пользователь Vasyl Tereshko <tolmi@end.kiev.ua> написал:
> Ivan Fedorov пишет:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>>>
>>>> Можно настроить acl-и на ldap-сервере таким образом, чтобы выполненять
>>>> простые операции можно было анонимно, тогда нет нужды вообще
>>>> использовать
>>>> rootbinddn.
>>>>
>>>
>>> Ага, но тогда я должен давать для anonymous например доступ к такой
>>> чувствительной информации, как вхождение пользователя в те или иные
>>> группы,
>>> что совсем неправильно.
>>>
>>
>> Ну если вы так параноидальны, то подключайтесь ко LDAP через TLS с
>> проверкой клиентских сертификатов. Тогда чужие во LDAP не залезут
>> точно.
>>
>
> Чужих как раз я не боюсь, они просто не доберутся до сервера. Я боюсь
> инсайдеров - доморощенных хакеров, которые лезут во все дыры и хотят знать
> всё, что им не положено.
> А на группах сделан доступ к ресурсам, соответственно я хочу, чтобы только
> члены этой группы могли знать кто ещё, кроме него самого имеет доступ к
> ресурсу.
>
> PS А раздать 200-300 пар сертификатов и потом их поддерживать тоже веселая
> задача. Это уж в сторону PKI тогда нужно смотреть...

Уперся в такую же задачку. Не хочу использовать binddn админа ldap на
каждой машине, но и не пойму, как сделать так, чтобы posix
логин+пароль конкретного пользователя передавался в ldap-сервер в
качестве binddn во время поиска соответствий. Потому что разрешать
возможность чтения всех логинов паролей при анонимном подключении тоже
как-то не бодрит. И клиентские сертификаты тоже не хочется внедрять -
слишком заморочено.

Вопрос даже не в шифровании и не в том, что админская учетка будет
лежать на каждой клиентской машине (с которой можно снять винт или
загрузиться с live-cd и прочитать секретный файл), а в том, что все
вопросы ldap-у задаются от имени админа. Неаккуратненько как-то.
Красивее, когда каждому выдается только то, что права ldap-а ему
позволяют.

Кто-нибудь уже смог это настроить?

Re: [Sysadmins] LDAP+nss_ldap+nscd

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

26 декабря 2008 г. 15:47 пользователь Денис Черносов
<denis0.ru@gmail.com> написал:
> 24 июня 2008 г. 3:07 пользователь Vasyl Tereshko <tolmi@end.kiev.ua> написал:
>> Ivan Fedorov пишет:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>>>
>>>>> Можно настроить acl-и на ldap-сервере таким образом, чтобы выполненять
>>>>> простые операции можно было анонимно, тогда нет нужды вообще
>>>>> использовать
>>>>> rootbinddn.
>>>>>
>>>>
>>>> Ага, но тогда я должен давать для anonymous например доступ к такой
>>>> чувствительной информации, как вхождение пользователя в те или иные
>>>> группы,
>>>> что совсем неправильно.
>>>>
>>>
>>> Ну если вы так параноидальны, то подключайтесь ко LDAP через TLS с
>>> проверкой клиентских сертификатов. Тогда чужие во LDAP не залезут
>>> точно.
>>>
>>
>> Чужих как раз я не боюсь, они просто не доберутся до сервера. Я боюсь
>> инсайдеров - доморощенных хакеров, которые лезут во все дыры и хотят знать
>> всё, что им не положено.
>> А на группах сделан доступ к ресурсам, соответственно я хочу, чтобы только
>> члены этой группы могли знать кто ещё, кроме него самого имеет доступ к
>> ресурсу.
>>
>> PS А раздать 200-300 пар сертификатов и потом их поддерживать тоже веселая
>> задача. Это уж в сторону PKI тогда нужно смотреть...
>
> Уперся в такую же задачку. Не хочу использовать binddn админа ldap на
> каждой машине, но и не пойму, как сделать так, чтобы posix
> логин+пароль конкретного пользователя передавался в ldap-сервер в
> качестве binddn во время поиска соответствий. Потому что разрешать
> возможность чтения всех логинов паролей при анонимном подключении тоже
> как-то не бодрит. И клиентские сертификаты тоже не хочется внедрять -
> слишком заморочено.
>
> Вопрос даже не в шифровании и не в том, что админская учетка будет
> лежать на каждой клиентской машине (с которой можно снять винт или
> загрузиться с live-cd и прочитать секретный файл), а в том, что все
> вопросы ldap-у задаются от имени админа. Неаккуратненько как-то.
> Красивее, когда каждому выдается только то, что права ldap-а ему
> позволяют.
>
> Кто-нибудь уже смог это настроить?

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


>