Laden...

Ohne Re-Login aktuelle Gruppenzugehörigkeit im AD abfragen

Erstellt von dataCore vor 11 Jahren Letzter Beitrag vor 11 Jahren 5.451 Views
dataCore Themenstarter:in
92 Beiträge seit 2006
vor 11 Jahren

Gibt es eine Möglichkeit, die Gruppenzugehörigkeit ohne Logout zu aktualisieren? Oder führt kein Weg am Logout vorbei?

16.807 Beiträge seit 2008
vor 11 Jahren

Ich hab die Fälle hin und wieder, dass meine User sofort Zugriff auf die Anwendung haben, wenn ich sie der Gruppe / Rolle hinzufüge; bei manchen, aber das ist wirklich selten, funktionierts aber erst nach einem neuen Login.

Prinzipiell sollte aber IsInRole direkt gegen das AD prüfen, sofern dies verfügbar ist.

dataCore Themenstarter:in
92 Beiträge seit 2006
vor 11 Jahren

Gibt es da keine wissenschaftlich-logische Verhaltensweise?

Ich verwende nun (um mobile Rechner nicht abhängig vom direkten AD-Zugriff zu machen) die folgende Codezeile um seine Gruppenzugehörigkeit auszugeben. Jedoch mit demselben Problem (erst nach Logout/Login, natürlich mit AD-Zugriff, wird die Liste aktualisiert)


List<string> adGroupList = WindowsIdentity.GetCurrent().Groups.Translate(typeof(NTAccount)).Select(p => p.Value).ToList();

16.807 Beiträge seit 2008
vor 11 Jahren

Wenn alles beim ersten Versuch funktionieren würde, bräuchten wir keine Entwickler 😉
Es kommt denke ich drauf an, ob Kerberos oder NTLM verwendet wird. Ich arbeite mit Kerberos.

Vermutlich wird bei WindowsIdentity ein anderer Weg gegangen. Finde den Weg sowieso suboptimal, da Du hier wahrscheinlich unabhängig castest. Sprich beim Login werden alle Gruppen geladen und anschließend existiert kein Kontext zum AD.

Ich verwende das UserPrincipal. Laut WireShark wird bei GetGroups() das AD direkt abgefragt, statt die Gruppen zu cachen.

G
538 Beiträge seit 2008
vor 11 Jahren

Hallo,

also mit dem Login hat es folgendes auf sich:

Fall 1) Windows-Authentifizierung (Kerberos)
Der Benutzer bekommt bei der Anmeldung ein Kerberos-TGT (Ticket-Granting-Ticket), das heißt er darf sich selbst Tickets für bestimmte Ressourcen (DB, Files, Webseiten, etc.) ausstellen. In diesem TGT ist auch der Gruppenvektor des Benutzers enthalten. Selbiger wird beim Login aktualisiert.

Fall 2) Die Anwendung sucht den Benutzer im AD und fragt seine Rollen ab
Die Anwendung kennt nur den Benutzernamen und holt sich die Gruppen im AD. Das führt dazu, dass (sofern nicht gecacht wird) der Gruppenvektor immer aktuell ist - nutzt man NTLM oder AccountManagement (.NET) werden dabei die APIs von LSA benutzt. Ob selbiger einen Cache hat oder nicht kann ich nicht sagen.
Man sollte beachten, dass der AccountManagement Namespace und die von Abt angesprochenen Principals (User und Computer) GetGroups() und GetAuthorizationGroups() anbieten. Ersteres liefert alle DIREKTEN Gruppen und DistributionGroups, letzteres leifert alle Sicherheitsgruppen (auch rekursive). Um die rekursiven Gruppen zu lesen, muss der lesende Account Mitglied in "Windows Authorization Access" sein (das ist eine Well-Known-Group im AD).

GetGroups() ruft im übrigen "MemberOf" des Benutzers ab und GetAuthorizationGroups() ruft "tokenGroups" auf.
Der AccountManagement-Namespace hat aber einige Bugs, die dazu führen können, das GetAuthorizationGroups() nicht funktioniert, weshalb sich ein eigener Rekursiver aufruf von GetGroups als alternative lohnen kann - natürlich nur, wenn vorher GetAuthorizationGroups() gescheitert ist, das ist nämlich deutlich performanter.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

16.807 Beiträge seit 2008
vor 11 Jahren

Der AccountManagement-Namespace hat aber einige Bugs

Gibts dazu irgendwas schriftliches, vielleicht in einem BugTracker und im optimale Falle sogar Workarounds?

G
538 Beiträge seit 2008
vor 11 Jahren

Ich hab mir keine direkten Notitzen gemacht, aber es ist eine LSA-Fehlermeldung, dass GroupPrincipals nicht aufgelöst werden können (in diesem Fall), die undefiniert auftritt. Ich hab 4 Server in einer kleinen Farm, davon waren 2 ständig betroffen und einer zeitweise betroffen.
Ich habe dann GetAuthorizationGroups über das underlyingObject und die tokenGroups-Property nachgebaut - nur löse ich die Gruppen dann von Hand auf und nicht wie der LSA das tut auf einen Schlag.

Andere Unzulänglichkeiten hab ich selbst noch nicht bemerkt, aber in StackOverflow gabs einige Hinweise zu offenen Bugs (mit Connect-Link).
Mehr kann ich aber auch nicht sagen.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)