Как мне аутентифицироваться на ldap.google.com?
Я настроил 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?
Thx
Это немного вводит в заблуждение, потому что «INVALID_CREDENTIALS» на самом деле является гораздо более общей ошибкой, чем подразумевается. На самом деле это обычно является результатом ошибки разрешений, а не неверных учетных данных. Я столкнулся с этим при настройке собственного локального сервера OpenLDAP. Проблема скорее всего в том, что у вашего пользователя нет разрешения на привязку / аутентификацию к серверу LDAPS в первую очередь.
Причина, по которой ldapsearch работает для демона getent & sss, заключается в том, что они, вероятно, используют либо ваши учетные данные администратора LDAP, либо, если вы правильно настроили его, вашу учетную запись прокси-пользователя привязки. (Вы никогда не должны связывать аутентификацию напрямую через диспетчер.)
Проблема вызвана вашими ACL (списками управления доступом) для LDAP. По сути, вы хотите разрешить всем пользователям читать весь каталог (за исключением конфиденциальных объектов, таких как поля пароля и т. Д.
Я не знаю, как выглядят ваши списки контроля доступа в настоящее время, но вы хотите сделать следующее: начните со следующего ACL.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ЭТО НЕ ЗАЩИЩЕНО ПО УМОЛЧАНИЮ
access to *
by self write
by users auth
by users read
Фактически, это позволяет пользователям аутентифицироваться и читать все объекты, а также перезаписывать свои собственные пользовательские объекты, чтобы они могли делать такие вещи, как изменение своих паролей и тому подобное.
Имейте в виду, что эта конфигурация лишь немного более безопасна, чем конфигурация по умолчанию, которая разрешает анонимные привязки, что не должен допускать ни один достойный администратор. Вы должны быть ОЧЕНЬ строги в отношении того, что имеют пользователи доступ путем настройки контроля доступа для определенных атрибутов. Этот ACL очень открытый, поэтому вам следует приложить дополнительные усилия, чтобы заблокировать его еще больше.
Правильно настроенные серверы LDAP с хорошими схемами уже имеют некоторые встроенные охрана для охранника паролей и других конфиденциальных объектов, но вы всегда должны это проверять.
Перейдите к документации и внимательно прочтите ее. LDAP - огромный монстр, и его, к сожалению, слишком легко испортить.