Я управляю локальной сетью со списком пользователей, получающих доступ к своим общим домам по NFS при аутентификации через NIS/YP (клиенты и серверы на базе CentOS/Fedora).
Я нахожусь в мучительном процессе перехода от NIS/YP (который медленно, но необратимо прекращается в Red Hat и т.п.) к тому, что казалось наименее сложной в настройке заменой аутентификационной части, SSSD (для клиенты) и LDAP (для базы данных пользователей на серверах).
После ряда испытаний я пришел к тому, что кажется приемлемо работающей настройкой, и начал рассматривать усиление безопасности, но есть кое-что, что продолжает ускользать от меня.
В основном везде стандартные ACL для запросов к базе данных LDAP для аутентификации пользователей, которые входят в систему, имеют что-то вроде этого:
olcAccess: {0}to attrs=userPassword самостоятельно написать с помощью анонимной аутентификации от * none
olcAccess: {1}в attrs=shadowLastChange самостоятельно написать * прочитать
olcAccess: {2}для * чтения *
и все работает без проблем.
Поскольку я бы не хотел, чтобы пользователи заглядывали в записи друг друга, я изменил последний на:
olcAccess: {2}до * от * none
Затем я нашел «olcRequires: authc», который должен отключать анонимные привязки к LDAP (кажется, улучшение безопасности, не так ли?), и включил его, и все, похоже, продолжает работать.
Затем снова, глядя на первый ACL, вы видите, что анонимная аутентификация по паролю пользователя все еще разрешена (что кажется излишним, если действует предыдущее правило), и я попытался удалить его:
olcAccess: {0}to attrs=userPassword от себя =wx от * none
и больше ничего не работает.
Продолжая читать, я обнаружил, что уловка заключается в том, что SSSD должен иметь возможность минимально запрашивать базу данных, чтобы получить достаточную структуру для преобразования имени пользователя, такого как «foo», в отличительное имя LDAP как «uid=foo,ou=People,dc». =example,dc=com', который LDAP сможет затем обработать.
Я понимаю, что SSSD может использовать «прокси-пользователя» для этого, поэтому я добавил такого пользователя в свою базу данных, настроив SSSD для его использования:
ldap_default_bind_dn = cn=autobind,dc=пример,dc=com
ldap_default_authtok = очень секретный пароль
и, подумал я, я добавил необходимые ACL, чтобы он просто делал свою работу:
olcAccess: {0}to attrs=userPassword by self =wx by dn="cn=autobind,dc=example,dc=com" =x by * none
olcAccess: {1}в attrs=shadowLastChange самостоятельно написать dn="cn=autobind,dc=example,dc=com" прочитать * нет
olcAccess: {2}to * by dn="cn=autobind,dc=example,dc=com" прочитано * none
Излишне говорить, что это не работает - не только для входа в систему, что вполне может быть связано с неправильной настройкой SSSD, но и сама база данных становится недоступной для запросов, возвращая ошибку 49 (неверные учетные данные) даже через ldapsearch.
Повторное добавление по анонимной авторизации заставляет его работать снова; очевидно, есть что-то, что я не понимаю правильно.
Я понимаю, что это не кажется чем-то большим, за исключением того, что «анонимный» появляется в моих ACL, что меня очень раздражает, но, похоже, не может получить доступ к чему-либо важному.
Итак, мои вопросы: является ли это более безопасной конфигурацией, при которой «анонимный» доступ полностью удален из ACL для моей пользовательской базы данных LDAP, в конечном итоге заменяя его необходимые функции функциями прокси-пользователя, характерными для использования SSSD? Если нет, что бы вы сделали для дальнейшего усиления безопасности?
