LDAP аутентификации пользователей через доверенных доменов

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

Приложение имеет доступ к TreeA, , так что я предполагаю, что это может выглядеть в GroupA и увидеть USERB там. Но как бы он знал, что ему нужно отправить bind просит 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'.

Answer 4

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

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

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

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

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