Как пройти аутентификацию на 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?
Спасибо
1 ответ
Это немного вводит в заблуждение, потому что "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 - огромный монстр, и, к сожалению, слишком легко все испортить.