Может ли SSSD выполнять аутентификацию через LDAP с анонимной привязкой, запрещенной в списках ACL, и принудительно включенной olcRequires: authc?

Я управляю локальной сетью со списком пользователей, получающих доступ к своим общим домам по NFS при аутентификации через NIS/YP (клиенты и серверы на базе CentOS/Fedora).

Я нахожусь в мучительном процессе перехода от NIS/YP (который медленно, но необратимо прекращается в Red Hat и т.п.) к тому, что казалось наименее сложной в настройке заменой аутентификационной части, SSSD (для клиенты) и LDAP (для базы данных пользователей на серверах).

После ряда испытаний я пришел к тому, что кажется приемлемо работающей настройкой, и начал рассматривать усиление безопасности, но есть кое-что, что продолжает ускользать от меня.

В основном везде стандартные ACL для запросов к базе данных LDAP для аутентификации пользователей, которые входят в систему, имеют что-то вроде этого:

olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read

и все работает без проблем.

Поскольку я бы не хотел, чтобы пользователи заглядывали в записи друг друга, я изменил последний на:

olcAccess: {2}to * by * none

Затем я нашел «olcRequires: authc», который должен отключать анонимные привязки к LDAP (кажется, улучшение безопасности, не так ли?), и включил его, и все, похоже, продолжает работать.

Затем снова, глядя на первый ACL, вы видите, что анонимная аутентификация по паролю пользователя все еще разрешена (что кажется излишним, если действует предыдущее правило), и я попытался удалить его:

olcAccess: {0}to attrs=userPassword by self =wx by * none

и больше ничего не работает.

Продолжая читать, я обнаружил, что уловка заключается в том, что SSSD должен иметь возможность минимально запрашивать базу данных, чтобы получить достаточную структуру для преобразования имени пользователя, такого как «foo», в отличительное имя LDAP как «uid=foo,ou=People,dc». =example,dc=com’, который LDAP сможет затем обработать.

Я понимаю, что SSSD может использовать «прокси-пользователя» для этого, поэтому я добавил такого пользователя в свою базу данных, настроив SSSD для его использования:

ldap_default_bind_dn = cn=autobind,dc=example,dc=com
ldap_default_authtok = verysecretpassword

и, подумал я, я добавил необходимые ACL, чтобы он просто делал свою работу:

olcAccess: {0}to attrs=userPassword by self =wx by dn="cn=autobind,dc=example,dc=com" =x by * none
olcAccess: {1}to attrs=shadowLastChange by self write by dn="cn=autobind,dc=example,dc=com" read by * none
olcAccess: {2}to * by dn="cn=autobind,dc=example,dc=com" read by * none

Излишне говорить, что это не работает — не только для входа в систему, что вполне может быть связано с неправильной настройкой SSSD, но и сама база данных становится недоступной для запросов, возвращая ошибку 49 (неверные учетные данные) даже через ldapsearch.

Повторное добавление by anonymous auth заставляет его работать снова; очевидно, есть что-то, что я не понимаю правильно.

Я понимаю, что это не кажется чем-то большим, за исключением того, что «анонимный» появляется в моих ACL, что меня очень раздражает, но, похоже, не может получить доступ к чему-либо важному.

Итак, мои вопросы: является ли более безопасной конфигурация, в которой «анонимный» доступ полностью удален из ACL для моей пользовательской базы данных LDAP, в конечном итоге заменив его необходимые функции функциями прокси-пользователя, характерными для использования SSSD? Если нет, что бы вы сделали для дальнейшего усиления безопасности?

тот, где «анонимный» доступ полностью удален из ACL для моей пользовательской базы данных LDAP, в конечном итоге заменив его необходимые функции функциями прокси

В данном случае нет. Ты Можно запретить все операции чтения/поиска для анонимных подключений и привязать SSSD к учетной записи компьютера до того, как он выполнит поиск пользователя (я использую для этого Kerberos, SSSD автоматически выбирает /etc/krb5.keytab), но анонимным клиентам все равно нужно auth права по минимуму.

В частности, by anonymous auth необходим в списках управления доступом OpenLDAP для работы первоначальной «простой» привязки, потому что соединение, выполняющее привязку, по-прежнему находится в анонимном состоянии до тех пор, пока привязка не завершится успешно.

Поэтому, если вы определяете учетную запись «прокси», вы просто немного смещаете проблему, но не меняете ее на самом деле — анонимному соединению по-прежнему требуются права «авторизации», чтобы привязать как прокси-аккаунт. Или, другими словами, если вы требуете, чтобы клиент уже был аутентифицирован для аутентификации, то как он будет аутентифицироваться в качестве прокси-аккаунта в первую очередь?

Кроме того, я бы обычно не использовал olcRequires: authc глобально по той причине, что это предотвращает чтение записи rootDSE (нулевое DN), как клиенты обнаруживают какие механизмы аутентификации доступны на сервере, а также доступен ли StartTLS (если порт 636 не используется). Запрещая анонимным соединениям читать атрибуты нулевого DN, вы, вероятно, нарушите аутентификацию SASL (например, Kerberos/GSSAPI) и ограничитесь только «простой привязкой» на основе пароля.