całej zaufanych domen

Question

Moja aplikacja definiuje autoryzowanych użytkowników za pomocą protokołu LDAP (zazwyczaj Active Directory):

1. Klient definiuje serwer LDAP (TreeA) i grupę (Groupa). Dowolni użytkownicy w GroupA mogą korzystać z aplikacji.
2. W czasie logowania, użytkownik wysyła swoją nazwę użytkownika i hasło - jeżeli wiążą się z TreeA LDAP ze swoich mandatów działa, a ich konto użytkownika jest w GroupA, są dobre, aby przejść

I” napotykamy na sytuację, w której dwa Active Directories ufają sobie nawzajem, a określona GroupA w TreeA zawiera użytkowników z TreeB. Tak więc krok 2 nie powiedzie się, ponieważ próbuję uwierzytelnić UserB (z drzewaB) przed TreeA.

Aplikacja ma dostęp do TreeA, więc przypuszczam, że mogłaby wyglądać w GroupA i zobaczyć tam UserB. Ale skąd miałaby wiedzieć, że musi wysyłać żądania powiązania do TreeB, aby uwierzytelnić nazwę użytkownika i hasło?

Czy istnieje lepszy sposób podejścia do tego?
Czy takie żądania powiązania z TreeA automagicznie zostaną przekazane do TreeB, ponieważ istnieje relacja zaufania?

Answer 1

Może to oznaczać, że masz problem z konfiguracją na serwerze LDAP (TreeA). Napisałeś, że istnieje zaufanie między TreeA i TreeB, dzięki czemu możesz dodać UserB (z TreeB) jako członka GroupA w TreeA. Jeśli możesz to zrobić, to powinieneś zaufać poprawnemu kierunkowi między TreeA i TreeB. Powinieneś zrozumieć, że zaufanie oznacza tylko to, że Active Directory B sprawdza tylko hasło użytkownika, ale UserB domyślnie nie będzie miał dostępu do żadnych zasobów z Active Directory A. UserB może nie mieć uprawnień do przypisania LDAP do serwera A. W przypadku, gdy problem zostanie rozwiązany przez przyznanie użytkownikowi UserB pozwolenia na logowanie zdalne na serwerze A i dostęp odczytu do GroupA i prawdopodobnie odczytać uprawnienia do jednostki organizacyjnej, w której istnieje grupa A. Możesz spróbować Insight for Active Directory monitorować dostęp AD, aby zlokalizować problemy z uprawnieniami.

Inną możliwą przyczyną problemu może być użycie interfejsu API, którego używasz do dostępu do LDAP. W twe pytanie nie napisałeś żadnych informacji o API. Czy korzystasz z interfejsu Win32 API, takiego jak ldap_bind_s, czy też używasz DirectoryEntry w .NET? W obu przypadkach ważne może być użycie jawnej nazwy domeny wraz z nazwą konta (dla UserB) podczas wiązania lub użycie nazwy użytkownika i hasła do bieżącego użytkownika poświadczenia użytkownika.

Korzystanie z konta stałego z drzewa A dla wszystkich dostępów do drzewa A (również w przypadku testów dotyczących UserB) może również rozwiązać problem, ale możliwe jest tylko użycie jakiegoś rodzaju aplikacji.

W jakikolwiek sposób więcej informacji w pytaniu może zawęzić problem i sposoby rozwiązania problemu.

Answer 2

Może powinieneś używać replikacji ldap, aby obiekty były zawsze obecne na obu serwerach?

Answer 3

Aplikacja ma dostęp do TreeA, więc przypuszczam, że to wyglądać w GroupA i zobaczyć UserB tam. Ale jak by to było wiedzieć, że musi wysłać żądania bind do TreeB, aby uwierzytelnić nazwę użytkownika i hasło ?

atrybut w GroupA member dadzą pełną nazwę wyróżniającą (DN) każdego członka, który może wyglądać:

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

tak, kiedy próby „user2” do uwierzytelnienia, można dopasować CN i wiedzą, że powinieneś uwierzytelniać wobec "TreeB" zamiast "TreeA". (Prawdopodobnie będziesz miał pewien rodzaj tabeli odwzorowującej DN na nazwę hosta serwera AD). Lub po prostu wymusić na nim brutalne i wypróbować "TreeB", jeśli otrzymasz "brak takiego użytkownika" z "TreeA".

Będziesz musiał podjąć decyzję, jak postępować w przypadku duplikatów nazw użytkowników w dwóch drzewkach - czy jeden ma pierwszeństwo przed drugim?

Innym podejściem byłoby wymaganie od użytkowników określenia, którego drzewa są uwierzytelniane, na przykład poprzez zalogowanie się przy użyciu nazwy użytkownika, np. "Użytkownik1@treea.foobar.com".

Answer 4

Powiedzmy masz domeny A i domeny B, który zaufanego siebie, a jeśli chcesz, aby uwierzytelnić użytkownika B z domeny B przeciwko domenie A na Serwer domena A tak, co trzeba zrobić to:

1. Personifikowanie użytkownika B w domenie A za pomocą interfejsów API Win32.

2. Uwierzytelnij użytkownika B na domenę A za pomocą usługi DirectoryEntry, a następnie uzyskaj dostęp do AD domeny domeny A dla innych informacji o użytkowniku, takich jak przypisane grupy.

Zaimplementowałem go w aplikacji ASP.NET, która używa uwierzytelniania systemu Windows.

Mamy nadzieję, że pomoże,