GroupPrincipal.GetMembers schlägt fehl, wenn die Gruppe (oder untergeordnete Gruppe, falls rekursiv) ForeignSecurityPrincipal enthält

8

Dies ist nicht so sehr eine Frage als Information für jemanden, der das gleiche Problem hat.

Der folgende Fehler tritt auf:

%Vor%

Wenn der folgende Code ausgeführt wird und eine Gruppe oder eine untergeordnete Gruppe ein ForeignSecurityPrincipal enthält:

%Vor%

Ich habe einen Supportanruf bei Microsoft erhalten und sie haben dies als Problem bestätigt. Ein Fehler wurde intern ausgelöst, aber es wurde nicht bestätigt, ob dies behoben wird.

Microsoft schlug den folgenden Problemumgehungscode vor, aber es führt aufgrund der wiederholten Aufrufe von UserPrincipal.FindByIdentity zu Problemen bei Gruppen mit einer großen Anzahl von Benutzern.

%Vor%

Der obige Code könnte geändert werden, um fremde Sicherheitsprinzipale zu finden, die Probleme in Gruppen verursachen.

Microsoft hat die folgenden Informationen zu den Fremdsicherheitsprinzipalen bereitgestellt:

Dies ist eine Klasse von Objekten in AD, die einen Sicherheitsprinzipal von einer externen Quelle darstellt (also eine andere Gesamtstruktur / Domäne oder eines der "speziellen" Konten unten). Die Klasse ist hier dokumentiert: Ссылка Und der Container ist hier dokumentiert: Ссылка Ein FSP ist kein echtes Objekt in AD, sondern ein Platzhalter (Zeiger) auf ein Objekt, das in einer anderen, vertrauenswürdigen Domäne / Gesamtstruktur lebt. Es kann auch eine der "speziellen Identitäten" sein, die eine Reihe von bekannten Konten sind, die auch als FSPs klassifiziert sind, da ihre SIDs sich von der Domänen-SID unterscheiden. Zum Beispiel der anonyme, authentifizierte Benutzer, Stapel und mehrere andere Konten, wie hier dokumentiert: Ссылка

    
Simon Vane 01.06.2012, 16:23
quelle

3 Antworten

2

Die accountmanagement Bibliothek hat viele traurige Mängel, dies ist nur ein weiterer von vielen ...

Eine Sache, die Sie tun können, um Dinge etwas schneller zu machen, wäre, Ihre LDAP-Abfrage so anzupassen, dass sie sowohl Gruppenmitgliedschaft als auch Objekttyp gleichzeitig als Teil der Abfrage statt in der Schleife prüft. Ehrlich gesagt bezweifle ich, dass es viel Unterschied machen wird.

Der größte Teil der Inspiration für die Abfrage kam von Wie schreibe ich eine LDAP-Abfrage, um zu testen, ob der Benutzer Mitglied einer Gruppe ist? .

Abfrage: (&(!objectClass=foreignSecurityPrincipal)(memberof=CN=YourGroup,OU=Users,DC=YourDomain,DC=com))

Hinweis: Dies ist eine nicht getestete Abfrage ...

WENN es eine Möglichkeit gibt, eine LDAP-Abfrage in AccountManagement auszuführen (ein weiterer Fehler von mir), wäre dies das Ende Ihrer Probleme, da Sie die Abfrage ausführen und AccountManagement von dort übernehmen lassen könnten, aber diese Option existiert nicht ...

Aufgrund persönlicher Erfahrung sehe ich keine anderen Möglichkeiten, wenn Sie bei AccountManagement bleiben. Was Sie tun könnten, ist AccountManagement zu entleeren und nur DirectoryServices zu verwenden. Unter der Haube wickelt alle AccountManagement DirectoryEntry-Objekte sowieso, Sie könnten ein paar Hilfsklassen schreiben, um ähnliche Dinge zu tun.

    
Peter 01.06.2012 17:49
quelle
2

Sicher, das ist ein alter Faden, aber könnte jemandem helfen. Ich habe den unten stehenden Codeblock benutzt, um das Problem zu lösen. Die Principal-Klasse macht eine Eigenschaft namens StructuralObjectClass verfügbar, die Ihnen die AD-Klasse dieses Principals angibt. Ich habe damit entschieden, ob das Objekt ein Benutzer ist. GetMembers (true) rekursiv rekursiv alle verschachtelten Member in der fraglichen groupPrincipal.

Hoffe das hilft jemandem.

%Vor%

Danke, R

    
Raghu 26.08.2016 01:46
quelle
0

Alternativ können Sie diesen Code verwenden, um die Mitglieder zu erhalten:

%Vor%     
jmoreno 08.04.2015 18:42
quelle