Я настроил SSSD и openldap для успешного запроса ldaps: //ldap.google.com. Я могу использовать ldapsearch для выполнения запросов и могу взаимодействовать с каталогом, используя как sssctl, так и getent. К сожалению, все мои попытки пройти аутентификацию в качестве пользователя в каталоге встречались с INVALID_CREDENTIALS (код ошибки ldap 49). Я воспроизвел это поведение на нескольких клиентах. Я могу наблюдать эти сбои в журнале аудита LDAP в консоли администратора GSuite как LDAP bind with uid=brian,ou=Users,dc=XXX,dc=com failed with INVALID_CREDENTIALS.
В моей учетной записи включен 2 фактора, но я использую пароль приложения, чтобы попытаться аутентифицироваться. Я проверил пароль в четыре раза и даже создал новый, чтобы проверить это. Сервер Google ldap ведет себя так, как будто не может пройти аутентификацию.
Есть идеи, как я могу настроить безопасную внешнюю аутентификацию на ldap.google.com?
Спасибо
Это немного вводит в заблуждение, потому что "INVALID_CREDENTIALS" на самом деле является гораздо более общей ошибкой, чем подразумевается. На самом деле это обычно результат ошибки разрешений, а не неверных учетных данных. Я столкнулся с этим при настройке собственного локального сервера OpenLDAP. Проблема скорее всего в том, что у вашего пользователя нет разрешения на привязку / аутентификацию к серверу LDAPS в первую очередь.
Причина, по которой ldapsearch работает для демона getent & sss, заключается в том, что они, вероятно, используют либо ваши учетные данные администратора LDAP, либо, если вы правильно настроили его, вашу учетную запись прокси-пользователя привязки. (Вы никогда не должны связывать аутентификацию напрямую через менеджера).
Проблема вызвана вашими ACL (списками управления доступом) для LDAP. По сути, вы хотите разрешить всем пользователям читать весь каталог (за исключением конфиденциальных объектов, таких как поля пароля и т. Д.).
Я не знаю, как выглядят ваши ACL в настоящее время, но вы хотите начать со следующего ACL.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ЭТО НЕ ЗАЩИЩЕНО ПО УМОЛЧАНИЮ
access to *
by self write
by users auth
by users read
Фактически, это позволяет пользователям аутентифицироваться и читать все объекты, а также перезаписывать свои собственные пользовательские объекты, чтобы они могли выполнять такие действия, как изменение своих паролей и т. Д.
Имейте в виду, что эта конфигурация только слегка более безопасен, чем стандартный, который разрешает анонимные привязки, чего не должен допускать ни один достойный администратор. Вы должны ОЧЕНЬ строго относиться к тому, к чему у пользователей есть доступ, устанавливая контроль доступа для определенных атрибутов. Этот ACL очень открытый, поэтому вы должны приложить все усилия, чтобы заблокировать его и дальше.
Правильно настроенные серверы LDAP с хорошими схемами уже имеют некоторые встроенные средства защиты для защиты паролей и других конфиденциальных объектов, но вы всегда должны это проверять.
Обратитесь к документации и внимательно прочтите ее. LDAP - огромный монстр, и, к сожалению, его слишком легко испортить.