Аутентификация пользователя LDAP через доверенные домены - PullRequest
5 голосов
/ 19 февраля 2011

Мое приложение определяет авторизованных пользователей через LDAP (обычно Active Directory):

  1. Заказчик определяет сервер LDAP (TreeA) и группу (GroupA).Приложение могут использовать любые пользователи в GroupA.
  2. Во время входа в систему пользователь отправляет свое имя пользователя и пароль - если привязка к LDAP TreeA с их учетными данными работает, И их учетная запись находится в GroupA, онивсе хорошо

Я столкнулся с ситуацией, когда две Active Directory доверяют друг другу, и указанная GroupA в TreeA содержит пользователей из TreeB.Таким образом, шаг № 2 завершается неудачно, потому что я пытаюсь аутентифицировать UserB (из TreeB) для TreeA.

Приложение имеет доступ к TreeA, поэтому я предполагаю, что оно может заглянуть в GroupA и увидеть там UserB.Но как ему узнать, что ему нужно отправлять запросы на привязку в TreeB для аутентификации имени пользователя и пароля?

Есть ли лучший способ приблизиться к этому?
Должны ли такие запросы на привязку к TreeA автоматически перенаправляться в TreeBпоскольку есть доверительные отношения ??

Ответы [ 4 ]

1 голос
/ 23 февраля 2011

Может быть, у вас просто проблема с настройкой на сервере LDAP (TreeA). Вы написали, что между TreeA и TreeB существует доверие, так что вы можете добавить UserB (из TreeB) в качестве члена GroupA в TreeA. Если вы можете сделать это, то вы успешно установите доверие в правильном направлении между TreeA и TreeB. Вы должны понимать, что доверие означает только то, что Active Directory B проверяет только пароль пользователя, но UserB по умолчанию не будет иметь доступа ни к каким ресурсам из Active Directory A. UserB может не иметь разрешения на привязку LDAP к серверу A. В случае, если проблема будет решена путем предоставления пользователю B разрешения удаленного входа в систему на сервере A и доступа на чтение к GroupA и, вероятно, разрешения на чтение для подразделения, где существует GroupA. Вы можете попробовать Insight for Active Directory , чтобы отслеживать доступ AD и локализовать проблемы с разрешениями.

Другой возможной причиной вашей проблемы может быть использование API, который вы используете для доступа к LDAP. В вашем вопросе вы не написали никакой информации об API. Используете ли вы Win32 API, например ldap_bind_s , или используете DirectoryEntry в .NET? В обоих случаях может быть важно, чтобы вы использовали явное доменное имя вместе с именем учетной записи (для пользователя B) во время привязки или использовали null для имени и пароля для учетных данных текущего пользователя.

Использование фиксированной учетной записи из TreeA для всех обращений к TreeA (также для тестов на UserB) также может решить проблему, но это возможно только при использовании приложения.

Любая дополнительная информация в вашем вопросе может сузить проблему и способы ее решения.

0 голосов
/ 11 октября 2012

Допустим, у вас есть домен A и домен B, которые доверяют друг другу, и если вы хотите аутентифицировать пользователя B из домена B в домене A на сервере домена A, то что вам нужно сделать:

  1. Олицетворение пользователя B в домене A с использованием Win32 API.

  2. Аутентификация пользователя B в домене A с использованием DirectoryEntry, после чего вы можете получить доступ к AD домена A для получения другой пользовательской информации, такой каккак назначенные группы.

Я реализовал это в приложении ASP.NET, которое использует проверку подлинности Windows.

Надеюсь, это поможет,

0 голосов
/ 22 февраля 2011

Приложение имеет доступ к TreeA, поэтому я полагаю, что оно может заглянуть в GroupA и увидеть там UserB.Но как ему узнать, что ему нужно отправлять запросы на привязку в TreeB для аутентификации имени пользователя и пароля?

Атрибут member в GroupA даст полное отличительное имя (dn) каждого члена,который может выглядеть примерно так:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com

Итак, когда «User2» пытается аутентифицироваться, вы можете сопоставить CN и знать, что вы должны проходить аутентификацию на «TreeB» вместо «TreeA».(Предположительно, у вас есть какая-то таблица, сопоставляющая DN с именем хоста сервера AD.) Или просто переберите его и попробуйте «TreeB», если вы получили «нет такого пользователя» из «TreeA».

Вам нужно будет принять решение, как обрабатывать случай дублирования имен пользователей в двух деревьях - имеет ли одно приоритет над другим?

Другой подход заключается в том, чтобы требовать от пользователей указывать, какое дерево онипроводите аутентификацию, например, войдя в систему с именем пользователя, например «user1@treea.foobar.com» .

0 голосов
/ 22 февраля 2011

Может быть, вам следует использовать репликацию ldap таким образом, чтобы объекты всегда присутствовали на обоих серверах?

...