Überlegungen zum Zustandsserverentwurf

Hinweis

Der Internetauthentifizierungsdienst (Internet Authentication Service, IAS) wurde ab Windows Server 2008 in Netzwerkrichtlinienserver (Network Policy Server, NPS) umbenannt. Der Inhalt dieses Themas gilt sowohl für IAS als auch für NPS. Im gesamten Text wird NPS verwendet, um auf alle Versionen des Diensts zu verweisen, einschließlich der Versionen, die ursprünglich als IAS bezeichnet wurden.

 

Abhängig von Ihrem Entwurf benötigen Sie möglicherweise einen Server, um die Benutzer nachzuverfolgen, die derzeit im Netzwerk angemeldet sind. Die Standard Herausforderung für den Zustandsserver besteht darin, die Informationen in der Zustandsserverdatenbank mit dem tatsächlich angemeldeten Benutzer synchron zu halten. Wenn die Informationen auf dem Zustandsserver nicht synchronisiert sind, können Benutzer mehrere Sitzungen durchführen, wenn sie dazu nicht autorisiert sind. Außerdem könnten Benutzer, die nicht über mehrere Sitzungen verfügen, versehentlich bestraft werden.

Folgendes sollte bei der Implementierung des Zustandsservers berücksichtigt werden:

• Der Zustandsserver muss die Entscheidung in wenigen Sekunden online treffen. Aus diesem Grund benötigt der Zustandsserver eine skalierbare Infrastruktur, die viele Updates und Abfragen pro Sekunde unterstützen kann. Relationale Datenbanken sind für solch große Abfragen mit gleichzeitigen Updates nicht geeignet. Relationale Datenbanken sind in erster Linie so aufgebaut, dass datenkonsistent bleiben und allen Consumern eine konsistente Ansicht der Daten bereitgestellt wird. Sie sind nicht für schnelle Updates erstellt.
• Transaktionskonsistenz bei Updates zwischen mehreren Objekten ist nicht wichtig. Dies liegt daran, dass der Zustandsserver ein kleines Zeitfenster tolerieren kann. Die Transaktionskonsistenz eines einzelnen Updates ist jedoch wichtig, um die Wahrscheinlichkeit zu verringern, dass der Zustandsserver in einem inkonsistenten Zustand bleibt, wenn einer der RADIUS-Server in der Mitte des Updates heruntergefahren wird.
• Persistenz (Speichern des Zustands des Netzwerks in persistentem Speicher) ist nicht wichtig, da die persistenten Informationen schnell mit dem tatsächlichen Zustand des Netzwerks synchronisiert werden.
• Wenn ISDN oder andere Formen von Multilink im Netzwerk unterstützt werden, sollte der Zustandsserver in der Lage sein, Szenarien zu verarbeiten, die diese Features verwenden.

Ein möglicher Entwurf besteht darin, sowohl eine Authentifizierungserweiterungs-DLL als auch eine Autorisierungserweiterungs-DLL zu implementieren. Jede dieser DLLs kann über das Netzwerk mit einer Datenbank kommunizieren. Die DLL für die Autorisierungserweiterung kann die Datenbank mit Informationen darüber aktualisieren, wer derzeit im Netzwerk angemeldet ist. Die Authentifizierungserweiterungs-DLL kann die Datenbank nach diesen Informationen abfragen, um zu entscheiden, ob die Authentifizierungsanforderung eines bestimmten Benutzers akzeptiert oder abgelehnt werden soll. Wenn der Benutzer bereits angemeldet ist, wird die Anforderung abgelehnt.

Der Vorteil, dass die Autorisierungserweiterungs-DLL die Zustandsserverdatenbank aktualisiert, besteht darin, dass die Autorisierungserweiterungs-DLL Zugriff auf weitere Informationen über den authentifizierten Benutzer hat. Die Autorisierungserweiterungs-DLL hat Zugriff auf alle Autorisierungsattribute aus dem NPS-Autorisierungsmechanismus. Beispielsweise verfügen einige Benutzer möglicherweise über Autorisierungen, die es ihnen ermöglichen, mehrere Sitzungen zu haben. Der Zustandsserver sollte solche Benutzer als Sonderfall behandeln.