GroupPrincipal.GetMembers und domänenübergreifende Mitglieder Fehler

Question

Ich habe 2-Domänen, A und B. Die Domäne A die Gruppe GroupA welche Benutzer von Domäne B enthält
My Code:

using (var context = new PrincipalContext(ContextType.Domain, DomainName, User, Password)) 
{ 

    using (var groupPrincipal = GroupPrincipal.FindByIdentity(context, IdentityType.SamAccountName, 
                   groupName)) 
    { 
     if (groupPrincipal == null) return null; 
     using (var principalSearchResult = groupPrincipal.GetMembers(true)) 
     { 
      var changedUsersFromGroup = 
       principalSearchResult 
       .Where(member => member is UserPrincipal) 
       .Where(member => IsModifiedUser(member, usnChanged)) 
       .Cast<UserPrincipal>() 
       .Select(adsUser => new AdsUser(adsUser)).Cast<IAdsUser>() 
       .ToArray(); 

      return changedUsersFromGroup; 
     } 
    } 

} 

-System .DirectoryServices.AccountManagement.PrincipalOperationException: Beim Versuch, eine Cross-Store-Referenz aufzulösen, konnte das Zielprinzipal nicht in der Domäne gefunden werden, die von der SID des Prinzipals angegeben wird.

Aber wenn ich Benutzer hinzufügen von hier

new PrincipalContext(ContextType.Domain, DomainName, User, Password) 

zu Domäne B, funktioniert es richtig.
Wie kann ich es beheben?

Answer 1

Problem gefunden und an MS als Fehler gemeldet. derzeit unmöglich, es mit zu tun.net :(aber es funktioniert über native C++ API über Abfragen

Answer 2

Überprüfen Sie, ob es sich anders verhält, wenn nicht UserPrincipal, z.

var changedUsersFromGroup = principalSearchResult.ToArray(); 

Per other threads könnte es dort einige Problem sein. Auch nach MSDN, GetMembers (true) zurückgegebene Principalsammlung, die keine Gruppenobjekte enthält, werden nur Blattknoten zurückgegeben, und so brauchen Sie dieses Casting möglicherweise überhaupt nicht. Als nächstes wird überprüft, wie viele Ergebnisse diese Suche zurückgeben würde. Wenn Ihr AD viele Benutzer/verschachtelte Gruppen hat, ist es möglicherweise besser, GetMembers (true) nicht zu verwenden, um sicherzustellen, dass es für kleine Benutzergruppen funktioniert.

Answer 3

Es scheint, dass Sie ein PrincipalContext der Domäne A definieren (damit Sie die Gruppe erhalten), aber da die Benutzer innerhalb der Gruppe in Domäne B definiert sind, kann der Kontext nicht auf sie zugreifen (da es ein Domäne A-Kontext ist).

Möglicherweise müssen Sie einen zweiten 'PricipalContext' für Domäne B definieren und die Abfrage ausführen und die Objekte filtern, indem Sie möglicherweise die Liste der SIDs der Benutzer in der Gruppe Domäne A verwenden (Sie müssen die Liste der SIDs, ohne dass der zugrunde liegende Code versucht, sie zu lösen.

Hoffe es hilft!

Answer 4

Leider kann ich testen zur Zeit nicht, aber vielleicht können Sie versuchen, diese

var contextB = new PrincipalContext(ContextType.Domain, DomainName_B, User_B, Password_B) 
[..] 
    var changedUsersFromGroup = 
        principalSearchResult 
        .Where(member => member is UserPrincipal) 
        .Where(member => IsModifiedUser(member, usnChanged)) 
        .Select(principal => Principal.FindByIdentity(contextB, principal.SamAccountName)) 
        .Cast<UserPrincipal>() 
        .Select(adsUser => new AdsUser(adsUser)).Cast<IAdsUser>() 
        .ToArray(); 

Diese funktionieren könnte, aber nur, wenn alle Mitglieder in Domäne B natürlich sind. Wenn sie in verschiedenen Domänen gemischt sind, müssen Sie sie möglicherweise vorher filtern und durch Ihre Domänen iterieren.
Alternativ können Sie Ihre Anwendung mit einem Domänenkonto ausführen? Übergeben Sie dann nicht Benutzer/Pass und geben Sie die erforderlichen Zugriffsrechte für dieses Konto, um den Fehler zu vermeiden.
Erläuterung: Der Domänenkontext wechselt für die abgerufenen Principals (Sie können dies im Debugging-Modus anzeigen, wenn Sie den neuen AdsUser/IAdsUser-Cast-Part auskommentieren). Dies ist der eine, der die Ausnahme zu verursachen scheint. Obwohl dies genau der Teil ist, den ich nicht testen kann, denke ich, dass die Erstellung von AdsUser eine neue ldap Bindung an die Ziel-Domain erzeugt. Dies schlägt mit den "ursprünglichen" Anmeldeinformationen fehl. Ist AdsUser Teil von ActiveDS oder Drittanbieter?
Ich habe keinen Hinweis gefunden, wenn das Übergeben von Anmeldeinformationen die Standardauthentifizierung verwendet, aber ich denke, es sollte. Die Verwendung der Anmeldedaten der Anwendung verwendet negotiate und "handling this over" für den neuen AdsUser (..) sollte das Problem ebenfalls beheben.