LDAP: почему хранение пароля root в ldap conf файлы?

Rsync по SSH для безопасного резервного копирования. Пустой rsync не шифруется, если Вы не туннелируете через какую-то VPN.

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

Я не использовал DFSR, но от того, что я могу сказать его больше о репликации (который, да, резервное копирование), чем специализированное резервное копирование.

0
задан 22 September 2010 в 19:14
3 ответа

Как sysadmin1138 говорит, Вам действительно нужен доступ для чтения к базе данных LDAP. Вы можете achive это путем добавления специального пользователя LDAP с доступом для чтения к каждому атрибуты (кроме userPassword).

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: <some sha1 hash> 

И затем в файле управления доступом (принимающий OpenLDAP здесь):

access to *
        by dn.regex="cn=admin,dc=example,dc=com" read
        by * read

Вы могли также дать доступ для чтения анонимным пользователям (только ограничивающий userPassword). Затем Вы хотите, нуждаются в специальном администраторском пользователе, можно просто отбросить libnss_ldap.secret и pam_ldap.secret. Это работает одинаково хорошо, и uid и gecos поля Вашей пользовательской базы данных являются задним образом всем тем секретом так или иначе. Это - то, что я обычно делаю. Вы могли бы хотеть установить пределы размера и ограничить доступ к почтовому атрибуту аутентифицируемым пользователям:

sizelimit 100
timelimit 60

access to attrs=userPassword
        by anonymous auth
        by * none

access to attrs=mail
    by self read
    by users read
    by * none

access to *
        by * read

Надежда, которая помогает!

1
ответ дан 4 December 2019 в 15:08

IIRC, пользователь и пароль, который должен быть сохранен, существуют тот, который может считать все соответствующие атрибуты LDAP. Это именно так происходит, что LDAP-корень может считать их всех. Если время потрачено для создания пользователя в структуре LDAP, которая имеет способность считать корректные атрибуты, но не записать им, она позволит меньшему количеству привилегированной учетной записи быть сохраненным в тех файлах. Я полагаю, что это - лучшая практика так или иначе.

1
ответ дан 4 December 2019 в 15:08

Единственный способ избежать этого использует kerberos с ldap. Не используйте ldap для аутентификации, но kerberos.

Если у Вас есть основанный на Redhat Linux, можно попробовать freeipa. Их версия 2 почти сделана, и она показывает большое обещание (я протестировал ее в лаборатории, и действительно легко настроить, поддержать и расшириться). Как только версия 2 отсутствует как производство, я намереваюсь использовать его везде, я могу ;-)

Если Вы не используете красный основанный на шляпе Linux, то мир боли перед Вами для получения этой работы. Это возможно, но не для слабонервных. Я нашел, что эти практические руководства относительно этого материала работают вполне хорошо: системные практические руководства rj, пропустите не kerberos/ldap материал. Ubuntu имеет общественный документ (те два слова не внушают большое доверие мне) для установки этого материала: человечность openldap/kerberos.

К счастью с freeipa, если у Вас нет серверов окон, у нас будет достойный AD эквивалент для linux/unix.

0
ответ дан 4 December 2019 в 15:08
  • 1
    Аутентификация LDAP передана в открытом тексте? Поскольку я вывел некоторые пакеты прямо сейчас, и существует authenciation простой: <некоторая строка символов и цифр>. Таким образом, это - открытый текст на самом деле? –  John 24 September 2010 в 16:57
  • 2
    И какая установка является худшей болью в заднице? OpenLDAP + SSL или OpenLDAP + Kerberos. –  John 24 September 2010 в 17:02
  • 3
    , которого Вы могли начать осуществлять сниффинг с dsniff monkey.org/~dugsong/dsniff, чтобы видеть, получаете ли Вы на самом деле учетные данные. При использовании tls/ssl он не будет работать –  natxo asenjo 24 September 2010 в 17:04
  • 4
    это зависит от того, сколько Вы знаете о kerberos. Если у Вас уже есть openldap для аутентификации, и информация об учетной записи, добавляя ssl должна быть легче, чем хождение kerberos путем. Однако, после того как Вы устанавливаете kerberos область, у Вас есть действительно единая точка входа к Вашей kerberized среде. Можно войти kerberos область и оттуда войти в остальную часть серверов, не имея необходимость вводить пароль снова. –  natxo asenjo 24 September 2010 в 17:21

Теги

Похожие вопросы