Как мне исправить мой ldap olcAccess, чтобы пользователи могли связываться с ним?

Общие сведения

У меня есть супер простой сервер openldap, на котором практически ничего нет, кроме пользователя admin, пары OU и пользователь.

Я могу войти и авторизоваться против него с пользователем admin cn = admin, dc = example, dc = com , однако любые добавленные мной пользователи не могут подключиться к нему для аутентификации.

Вот древовидное представление каталога, чтобы было понятно: Here is a tree view of the directory

Первоначально я пытался авторизоваться против него для использования с OpenVPN, журналы, которые я там получил, были Неверный пароль для DN LDAP "uid = myuser, ou = users, dc = example, dc = com"

Однако я знал, что пароль был правильным, что привело меня к тому, что я сейчас застрял ....

Этот сервер является с использованием конфигурации cn = config , без использования файла конфигурации!

Вот фрагмент (что, на мой взгляд, актуально) из вывода slapcat -b cn = config :

Как вы видете,Я слепо добавляю записи olcAccess , чтобы попытаться разрешить их.

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=example,dc=com
olcAccess: {0} to * by * auth
olcAccess: {1} to * by anonymous auth
olcAccess: {2}to * by self auth
olcAccess: {3}to * by * read
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none
olcAccess: {5}to dn.base="" by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW:: <<hidden>>
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 03eab422-8c94-1038-90ce-9fb3bcaac9c4
creatorsName: cn=admin,cn=config
createTimestamp: 20181205044311Z
entryCSN: 20181206111241.430739Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20181206111241Z

У меня есть olcAccess: {0} to * by * auth в качестве ТОП-записи {0} - Afaik, должен разрешить авторизацию кому угодно / чему угодно ??

Я использую Apache Directory Studio, чтобы помочь взаимодействовать с сервером, вот скриншот проверки пароля: Validate Password

А вот и тест на «привязку»: Bind Test

Все работает отлично от пользователя cn = admin, dc = example, dc = com .

Я пытаюсь просто добавить нескольких базовых пользователей, например: uid = myuser, ou = users, dc = example, dc = com и разрешить им аутентифицировать себя в каталоге. Мне действительно не нужно ничего особенного, например, роли и т. Д. Все пользователи будут на одном уровне и разделены на группы, через которые внешние службы будут фильтровать их для аутентификации.

Эти пользователи, которых я добавляю, являются объектным классом posixAccount.

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

Я попытался перезапустить сервер после внесения записей olcAccess , поэтому отметьте эту запись из списка.

0
задан 6 December 2018 в 13:42
1 ответ

Таким образом, ACL была отвлекающим маневром.

Очевидно, LDAP заботится о том, как хешировать пароль пользователя, учетная запись администратора имеет SSHA. Новые пользователи, которых я создавал, я использовал хеш SHA512 для пароля. Как только я сбросил пароли пользователей с помощью хеширования SSHA, привязка заработала. Тьфу.

Я немного почитаю, но если кто-нибудь знает, как я могу преобразовать своих пользователей в использование хеширования SHA512 или SSHA-512, я был бы признателен. А пока оставлю как есть.

Также для всех, кто сталкивается с чем-то подобным в отношении ACL. Теперь он работает, просто применив olcAccess: {0} к * by * read как единственное правило olcAccess , и, похоже, все в порядке.

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

Теги

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