Erstellen von Plug-Ins mit dem Risikobewertungsmodell von AD FS 2019

Sie können jetzt eigene Plug-Ins erstellen, um Authentifizierungsanforderungen in verschiedenen Phasen zu blockieren oder ihnen eine Risikobewertung zuzuweisen – beim Empfang der Anforderung sowie vor und nach der Authentifizierung. Erreicht wird dies mit dem neuen Risikobewertungsmodell, das mit AD FS 2019 eingeführt wurde.

Was ist das Risikobewertungsmodell?

Das Risikobewertungsmodell umfasst eine Reihe von Schnittstellen und Klassen, mit denen Entwickler die Header von Authentifizierungsanforderungen lesen und eine eigene Logik zur Risikobewertung implementieren können. Anschließend wird der implementierte Code (das Plug-In) gemäß AD FS-Authentifizierungsprozess ausgeführt. Mithilfe der im Modell enthaltenen Schnittstellen und Klassen können Sie beispielsweise Code implementieren, um Authentifizierungsanforderungen basierend auf der im Anforderungsheader enthaltenen Client-IP-Adresse zu blockieren oder zuzulassen. AD FS führt den Code für jede Authentifizierungsanforderung aus und ergreift gemäß der implementierten Logik geeignete Maßnahmen.

Das Modell ermöglicht es, über ein Plug-In Code in jede der drei Phasen der AD FS-Authentifizierungspipeline einzufügen (siehe unten):

1. Empfangene Anforderung: Ermöglicht die Erstellung von Plug-Ins, um Anforderungen beim Empfang der Authentifizierungsanforderung durch AD FS zuzulassen oder zu blockieren, d. h. vor der Eingabe von Anmeldeinformationen durch den Benutzer. Sie können den in dieser Phase verfügbaren Anforderungskontext (z. B. IP-Adresse des Clients, HTTP-Methode, DNS des Proxyservers usw.) zur Durchführung der Risikobewertung verwenden. Sie können zum Beispiel ein Plug-In erstellen, das die IP-Adresse aus dem Anforderungskontext ausliest und die Authentifizierungsanforderung blockiert, falls die IP-Adresse in der vordefinierten Liste riskanter IP-Adressen enthalten ist.

2. Vorauthentifizierung: Ermöglicht das Erstellen von Plug-Ins zum Zulassen oder Blockieren von Anforderungen an dem Punkt, an dem der Benutzer Anmeldeinformationen angibt, diese aber noch nicht von AD FS ausgewertet wurden. In dieser Phase verfügen Sie neben dem Anforderungskontext auch über Informationen zum Sicherheitskontext (z. B. Benutzertoken, Benutzer-ID usw.) und zum Protokollkontext (z. B. Authentifizierungsprotokoll, Client-ID, Ressourcen-ID usw.), die Sie in Ihrer Risikobewertungslogik nutzen können. Sie können z. B. ein Plug-In erstellen, das Kennwort-Spray-Angriff verhindert, indem es das Benutzerkennwort aus dem Benutzertoken ausliest und die Authentifizierungsanforderung blockiert, wenn das Kennwort in der vordefinierten Liste riskanter Kennwörter enthalten ist.

3. Nach der Authentifizierung: Ermöglicht das Erstellen eines Plug-Ins zur Risikobewertung, nachdem der Benutzer die Anmeldeinformationen eingegeben und AD FS die Authentifizierung durchgeführt hat. In dieser Phase verfügen Sie neben dem Anforderungskontext, dem Sicherheitskontext und dem Protokollkontext auch über Informationen zum Ergebnis der Authentifizierung („Erfolgreich“ oder „Fehler“). Das Plug-In kann basierend auf den verfügbaren Informationen die Risikobewertung ermitteln und zur weiteren Auswertung an Anspruchs- und Richtlinienregeln übergeben.

Zum besseren Verständnis der Erstellung eines Plug-Ins für die Risikobewertung und dessen Ausführung in Übereinstimmung mit dem AD FS-Prozess erstellen wir nachfolgend ein Beispiel-Plug-In, das Anforderungen blockiert, die von einer bestimmten, als riskant eingestuften Extranet-IP-Adresse stammen. Dann registrieren wir das Plug-In bei AD FS und testen abschließend seine Funktionalität.

Hinweis

Alternativ können Sie das Plug-In für Risikobenutzer erstellen, ein Beispiel-Plug-In, das die von Microsoft Entra ID-Schutz ermittelte Risikostufe des Benutzers nutzt, um die Authentifizierung zu blockieren oder eine Multi-Faktor-Authentifizierung (MFA) zu erzwingen. Die Schritte zum Erstellen des Plug-Ins für Risikobenutzer finden Sie hier.

Erstellen eines Beispiel-Plug-Ins

Hinweis

Diese Anleitung soll lediglich veranschaulichen, wie Sie ein Beispiel-Plug-In erstellen können. Die hier erstellte Lösung ist keineswegs für den Einsatz in einem Unternehmen geeignet.

Voraussetzungen

Im Folgenden finden Sie eine Liste der Voraussetzungen zur Erstellung dieses Beispiel-Plug-Ins:

• AD FS 2019 installiert und konfiguriert
• .NET Framework 4.7 und höher
• Visual Studio

Erstellen einer Plug-In-DLL

Das folgende Verfahren leitet Sie durch die Erstellung einer Beispiel-Plugin-DLL:

1. Laden Sie das Beispiel-Plug-In herunter, öffnen Sie die Git Bash, und geben Sie Folgendes ein:

   git clone https://github.com/Microsoft/adfs-sample-RiskAssessmentModel-RiskyIPBlock
   

2. Erstellen Sie eine CSV-Datei an einem beliebigen Speicherort auf Ihrem AD FS-Server (in diesem Fall wurde die Datei authconfigdb.csv unter C:\extensions erstellt), und fügen Sie dieser Datei die IP-Adressen hinzu, die Sie blockieren möchten.

   Das Beispiel-Plug-In blockiert alle Authentifizierungsanforderungen, die von den in dieser Datei aufgeführten Extranet-IP-Adressen stammen.

   Hinweis

   Wenn Sie über eine AD FS-Farm verfügen, können Sie die Datei auf einem oder allen AD FS-Servern erstellen. Jede der Dateien kann verwendet werden, um die riskanten IP-Adressen in AD FS zu importieren. Im Abschnitt Registrieren der Plug-In-DLL bei AD FS wird der Importprozess ausführlich erläutert.

3. Öffnen Sie das Projekt ThreatDetectionModule.sln mit Visual Studio.

4. Entfernen Sie die Datei Microsoft.IdentityServer.dll wie unten gezeigt aus dem Projektmappen-Explorer:
   

5. Fügen Sie wie unten gezeigt einen Verweis auf die Datei Microsoft.IdentityServer.dll für Ihre AD FS-Instanz hinzu:

   a. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf Verweise, und wählen Sie Verweis hinzufügen... aus.
   

   

   b. Wählen Sie im Fenster Verweis-Manager die Option Durchsuchen aus. Wählen Sie im Dialogfeld Zu referenzierende Dateien auswählen... die Microsoft.IdentityServer.dll aus Ihrem AD FS-Installationsordner (hier C:\Windows\ADFS), und klicken Sie auf Hinzufügen.

   Hinweis

   In diesem Fall erstellen wir das Plug-In auf dem AD FS-Server selbst. Wenn sich Ihre Entwicklungsumgebung auf einem anderen Server befindet, kopieren Sie die Datei Microsoft.IdentityServer.dll aus Ihrem AD FS-Installationsordner auf den AD FS-Server Ihrer Dev-Box.
   

   

   c. Klicken Sie im Fenster Verweis-Manager auf OK, nachdem Sie sich vergewissert haben, dass das Kontrollkästchen Microsoft.IdentityServer.dll aktiviert ist.
   

   

6. Jetzt sind alle Klassen und Verweise vorhanden, um einen Build zu erstellen. Da es sich bei der Ausgabe dieses Projekts jedoch um eine DLL handelt, muss sie im globalen Assemblycache (GAC) des AD FS-Servers installiert werden, und die DLL muss zunächst signiert werden. Gehen Sie dazu folgendermaßen vor:

   a. Klicken Sie mit der rechten Maustaste auf den Namen des Projekts, ThreatDetectionModule. Klicken Sie im Menü auf Eigenschaften.
   

   

   b. Klicken Sie auf der Seite Eigenschaften links auf Signieren, und aktivieren Sie dann das Kontrollkästchen Assembly signieren. Wählen Sie im Pulldownmenü Schlüsseldatei mit starkem Namen auswählen: die Option <Neu...> aus.
   

   

   c. Geben Sie im Dialogfeld Schlüssel für einen starken Namen erstellen einen (beliebigen) Namen für den Schlüssel ein, und deaktivieren Sie das Kontrollkästchen Meine Schlüsseldatei mit Kennwort schützen. Klicken Sie dann auf OK.
   

   

   d. Speichern Sie das Projekt wie unten gezeigt:
   

   

7. Erstellen Sie das Projekt, indem Sie wie unten gezeigt auf Erstellen und dann auf Projektmappe neu erstellen klicken:
   

   

   Überprüfen Sie im Ausgabefenster am unteren Bildschirmrand, ob Fehler aufgetreten sind.
   

   

Das Plug-In (DLL) ist jetzt einsatzbereit und befindet sich im Ordner \bin\Debug des Projektordners (in diesem Fall C:\extensions\ThreatDetectionModule\bin\Debug\ThreatDetectionModule.dll).

Der nächste Schritt besteht darin, diese DLL bei AD FS zu registrieren, damit sie gemäß AD FS-Authentifizierungsprozess ausgeführt wird.

Registrieren der Plug-In-DLL bei AD FS

Die DLL muss mithilfe des PowerShell-Befehls Register-AdfsThreatDetectionModule in AD FS auf dem AD FS-Server registriert werden. Vor der Registrierung müssen wir jedoch das Token des öffentlichen Schlüssels abrufen. Dieses Token für den öffentlichen Schlüssel wurde erstellt, als wir den Schlüssel erstellt und die DLL mit diesem Schlüssel signiert haben. Sie können SN.exe folgendermaßen verwenden, um das Token des öffentlichen Schlüssels für die DLL abzurufen:

1. Kopieren Sie die DLL-Datei aus dem Ordner \bin\Debug an einen anderen Speicherort (in diesem Fall C:\extensions).

2. Starten Sie die Developer-Eingabeaufforderung für Visual Studio, und wechseln Sie zu dem Verzeichnis, das sn.exe enthält (im vorliegenden Fall Verzeichnis C:\Programme (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools).

   

3. Führen Sie den Befehl SN mit dem Parameter -T und dem Speicherort der Datei aus (hier SN -T "C:\extensions\ThreatDetectionModule.dll").

   
   

   Der Befehl liefert Ihnen das Token für den öffentlichen Schlüssel (in diesem Fall 714697626ef96b35).

4. Fügen Sie die DLL in den globalen Assemblycache des AD FS-Servers ein. Als bewährte Methode empfiehlt es sich, ein eigenes Installationsprogramm für Ihr Projekt zu erstellen und die Datei mit diesem Installationsprogramm zum globalen Assemblycache hinzuzufügen. Eine andere Lösung ist die Verwendung von Gacutil.exe (weitere Informationen zu Gacutil.exe finden Sie hier) auf Ihrem Entwicklungscomputer. Da sich Visual Studio in diesem Fall auf demselben Server befindet wie AD FS, verwenden wir Gacutil.exe wie folgt:

   a. Wechseln Sie über die Developer-Eingabeaufforderung für Visual Studio zu dem Verzeichnis, das Gacutil.exe enthält (hier Verzeichnis C:\Programme (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools).

   b. Führen Sie den Befehl Gacutil aus (in diesem Fall Gacutil /IF C:\extensions\ThreatDetectionModule.dll):

   

   Hinweis

   Wenn Sie über eine AD FS-Farm verfügen, müssen Sie die oben genannten Schritte auf jedem AD FS-Server in der Farm ausführen.

5. Öffnen Sie Windows PowerShell, und führen Sie den folgenden Befehl aus, um die DLL zu registrieren:

   Register-AdfsThreatDetectionModule -Name "<Add a name>" -TypeName "<class name that implements interface>, <dll name>, Version=10.0.0.0, Culture=neutral, PublicKeyToken=< Add the Public Key Token from Step 2. above>" -ConfigurationFilePath "<path of the .csv file>"
   

   In diesem Fall lautet der Befehl folgendermaßen:

   Register-AdfsThreatDetectionModule -Name "IPBlockPlugin" -TypeName "ThreatDetectionModule.UserRiskAnalyzer, ThreatDetectionModule, Version=10.0.0.0, Culture=neutral, PublicKeyToken=714697626ef96b35" -ConfigurationFilePath "C:\extensions\authconfigdb.csv"
   

   Hinweis

   Sie müssen die DLL nur einmal registrieren, auch wenn Sie über eine AD FS-Farm verfügen.

6. Starten Sie den AD FS-Dienst neu, nachdem Sie die DLL registriert haben.

Das war alles, die DLL ist jetzt bei AD FS registriert und kann verwendet werden!

Hinweis

Wenn Änderungen am Plug-In vorgenommen werden und das Projekt neu erstellt wird, muss die aktualisierte DLL erneut registriert werden. Vor der Registrierung müssen Sie die Registrierung der aktuellen DLL mit folgendem Befehl aufheben:

UnRegister-AdfsThreatDetectionModule -Name "<name used while registering the dll in 5. above>"

In diesem Fall lautet der Befehl folgendermaßen:

UnRegister-AdfsThreatDetectionModule -Name "IPBlockPlugin"

Testen des Plug-Ins

1. Öffnen Sie die zuvor erstellte Datei authconfig.csv (in diesem Fall unter C:\extensions), und fügen Sie die Extranet-IP-Adressen hinzu, die Sie blockieren möchten. Jede IP-Adresse sollte in einer eigenen Zeile ohne Leerzeichen am Ende angegeben werden.
   

   

2. Speichern und schließen Sie die Datei.

3. Importieren Sie die aktualisierte Datei in AD FS, indem Sie den folgenden PowerShell-Befehl ausführen:

   Import-AdfsThreatDetectionModuleConfiguration -name "<name given while registering the dll>" -ConfigurationFilePath "<path of the .csv file>"
   

   In diesem Fall lautet der Befehl folgendermaßen:

   Import-AdfsThreatDetectionModuleConfiguration -name "IPBlockPlugin" -ConfigurationFilePath "C:\extensions\authconfigdb.csv")
   

4. Leiten Sie eine Authentifizierungsanforderung über den Server ein, dessen IP-Adresse Sie der Datei authconfig.csv hinzugefügt haben.

   Für diese Demonstration verwenden wir das Tool AD FS Help Claims X-Ray, um eine Anforderung zu starten. Wenn Sie das X-Ray-Tool ebenfalls verwenden möchten, folgen Sie den Anweisungen.

   Geben Sie die Verbundserverinstanz ein, und klicken Sie auf die Schaltfläche Authentifizierung testen.
   

   

5. Die Authentifizierung wird wie unten dargestellt blockiert.
   

   

Da Sie nun wissen, wie das Plug-In erstellt und registriert wird, gehen wir den Code des Plug-Ins durch, um die Implementierung der mit dem Modell eingeführten neuen Schnittstellen und Klassen zu verstehen.

Plug-In-Code: exemplarische Vorgehensweise

Öffnen Sie das Projekt ThreatDetectionModule.sln mit Visual Studio, und öffnen Sie dann die Hauptdatei UserRiskAnalyzer.cs im Projektmappen-Explorer rechts auf dem Bildschirm

Die Datei enthält die Hauptklasse „UserRiskAnalyzer“, die die abstrakte Klasse ThreatDetectionModule und die Schnittstelle IRequestReceivedThreatDetectionModule implementiert, um die IP-Adresse aus dem Anforderungskontext zu lesen, die ermittelte IP-Adresse mit den aus der AD FS-Datenbank geladenen IP-Adressen zu vergleichen und die Anforderung zu blockieren, sofern es eine Übereinstimmung gibt. Sehen wir uns diese Typen etwas genauer an.

Abstrakte Klasse „ThreatDetectionModule“

Diese abstrakte Klasse lädt das Plug-In in die AD FS-Pipeline und ermöglicht die Ausführung des Plug-In-Codes in Übereinstimmung mit dem AD FS-Prozess.

public abstract class ThreatDetectionModule
{
    protected ThreatDetectionModule();

    public abstract string VendorName { get; }
    public abstract string ModuleIdentifier { get; }

    public abstract void OnAuthenticationPipelineLoad(ThreatDetectionLogger logger, ThreatDetectionModuleConfiguration configData);
    public abstract void OnAuthenticationPipelineUnload(ThreatDetectionLogger logger);
    public abstract void OnConfigurationUpdate(ThreatDetectionLogger logger, ThreatDetectionModuleConfiguration configData);
}

Die Klasse umfasst die folgenden Methoden und Eigenschaften:

Methode	type	Definition
OnAuthenticationPipelineLoad	Void	Wird von AD FS aufgerufen, wenn das Plug-In in die Pipeline geladen wird.
OnAuthenticationPipelineUnload	Void	Wird von AD FS aufgerufen, wenn das Plug-In aus der Pipeline entladen wird.
OnConfigurationUpdate	Void	Wird von AD FS aufgerufen, wenn Konfigurationsaktualisierungen durchgeführt werden.
Property	Type	Definition
VendorName	String	Ruft den Namen des Anbieters ab, der als Plug-In-Besitzer zugewiesen ist.
ModuleIdentifier	String	Ruft den Bezeichner des Plug-Ins ab.

Im vorliegenden Beispiel-Plug-In verwenden wir die Methoden OnAuthenticationPipelineLoad und OnConfigurationUpdate, um die vordefinierten IP-Adressen aus der AD FS-Datenbank zu lesen. OnAuthenticationPipelineLoad wird aufgerufen, wenn das Plug-In bei AD FS registriert wird, während OnConfigurationUpdate beim Importieren der CSV-Datei mit dem Cmdlet Import-AdfsThreatDetectionModuleConfiguration aufgerufen wird.

Schnittstelle „IRequestReceivedThreatDetectionModule“

Mit dieser Schnittstelle können Sie eine Risikobewertung an dem Punkt implementieren, an dem AD FS die Authentifizierungsanforderung empfängt, der Benutzer aber noch keine Anmeldeinformationen eingegeben hat, d. h. in der Phase „Empfangene Anforderung“ des Authentifizierungsprozesses.

public interface IRequestReceivedThreatDetectionModule
{
    Task<ThrottleStatus> EvaluateRequest (
    ThreatDetectionLogger logger,
    RequestContext requestContext );
}

Die Schnittstelle umfasst die Methode EvaluateRequest, die es Ihnen ermöglicht, den Kontext der im Eingabeparameter „requestContext“ übergebenen Authentifizierungsanforderung zum Schreiben Ihrer Risikobewertungslogik zu verwenden. Der Parameter „requestContext“ weist den Typ RequestContext auf.

Als zweiter Eingabeparameter wird „logger“ mit dem Typ ThreatDetectionLogger übergeben. Dieser Parameter kann verwendet werden, um Fehler-, Überwachungs- und/oder Debugmeldungen in AD FS-Protokolle zu schreiben.

Die Methode gibt ThrottleStatus (0 = NotEvaluated, 1 = Block, 2 = Allow) an AD FS zurück, das die Anforderung dann entweder blockiert oder zulässt.

In unserem Beispiel-Plug-In analysiert die EvaluateRequest-Methodenimplementierung die clientIpAddress aus dem requestContext-Parameter und vergleicht sie mit allen aus der AD FS-Datenbank geladenen IP-Adressen. Wenn eine Übereinstimmung gefunden wird, gibt die Methode den Wert 2 (Blockieren) zurück, andernfalls 1 (Zulassen). Basierend auf dem Rückgabewert blockiert AD FS entweder die Anforderung oder lässt sie zu.

Hinweis

Das oben besprochene Beispiel-Plug-In implementiert nur die Schnittstelle „IRequestReceivedThreatDetectionModule“. Das Risikobewertungsmodell bietet jedoch zwei weitere Schnittstellen: „IPreAuthenticationThreatDetectionModule“ (zur Implementierung der Risikobewertungslogik in der Phase der Vorauthentifizierung) und „IPostAuthenticationThreatDetectionModule“ (zur Implementierung der Risikobewertungslogik in der Phase nach der Authentifizierung). Details zu den beiden Schnittstellen finden Sie unten.

Schnittstelle „IPreAuthenticationThreatDetectionModule“

Diese Schnittstelle ermöglicht es Ihnen, eine Logik zur Risikobewertung an dem Punkt zu implementieren, an dem der Benutzer die Anmeldeinformationen angibt, aber bevor AD FS sie auswertet, d. h. in der Phase vor der Authentifizierung.

public interface IPreAuthenticationThreatDetectionModule
{
    Task<ThrottleStatus> EvaluatePreAuthentication (
    ThreatDetectionLogger logger,
    RequestContext requestContext,
    SecurityContext securityContext,
    ProtocolContext protocolContext,
    IList<Claim> additionalClams
  );
}

Die Schnittstelle umfasst die Methode EvaluatePreAuthentication, mit der Sie die in den Eingabeparametern RequestContext requestContext, SecurityContext securityContext, ProtocolContext protocolContext und IList<Claim> additionalClams übergebenen Informationen zum Schreiben einer Risikobewertungslogik vor der Authentifizierung verwenden können.

Hinweis

Eine Liste der Eigenschaften, die mit jedem Kontexttyp übergeben werden, finden Sie in den Klassendefinitionen RequestContext, SecurityContext und ProtocolContext.

Als zweiter Eingabeparameter wird „logger“ mit dem Typ ThreatDetectionLogger übergeben. Dieser Parameter kann verwendet werden, um Fehler-, Überwachungs- und/oder Debugmeldungen in AD FS-Protokolle zu schreiben.

Die Methode gibt ThrottleStatus (0 = NotEvaluated, 1 = Block, 2 = Allow) an AD FS zurück, das die Anforderung dann entweder blockiert oder zulässt.

Schnittstelle „IPostAuthenticationThreatDetectionModule“

Mit dieser Schnittstelle können Sie eine Logik zur Risikobewertung implementieren, nachdem der Benutzer die Anmeldeinformationen angegeben und AD FS die Authentifizierung durchgeführt hat, d. h. in der Phase nach der Authentifizierung.

public interface IPostAuthenticationThreatDetectionModule
{
    Task<RiskScore> EvaluatePostAuthentication (
    ThreatDetectionLogger logger,
    RequestContext requestContext,
    SecurityContext securityContext,
    ProtocolContext protocolContext,
    AuthenticationResult authenticationResult,
    IList<Claim> additionalClams
  );
}

Die Schnittstelle umfasst die Methode EvaluatePostAuthentication, mit der Sie die in den Eingabeparametern RequestContext requestContext, SecurityContext securityContext, ProtocolContext protocolContext und IList<Claim> additionalClams übergebenen Informationen zum Schreiben einer Risikobewertungslogik nach der Authentifizierung verwenden können.

Hinweis

Eine vollständige Liste der Eigenschaften, die mit jedem Kontexttyp übergeben werden, finden Sie in den Klassendefinitionen RequestContext, SecurityContext und ProtocolContext.

Als zweiter Eingabeparameter wird „logger“ mit dem Typ ThreatDetectionLogger übergeben. Dieser Parameter kann verwendet werden, um Fehler-, Überwachungs- und/oder Debugmeldungen in AD FS-Protokolle zu schreiben.

Die Methode gibt die Risikobewertung zurück, die in AD FS-Richtlinien und -Anspruchsregeln verwendet werden kann.

Hinweis

Damit das Plug-In funktioniert, muss die Hauptklasse (in diesem Fall „UserRiskAnalyzer“) die abstrakte Klasse ThreatDetectionModule ableiten und sollte mindestens eine der drei oben beschriebenen Schnittstellen implementieren. Nachdem die DLL registriert wurde, überprüft AD FS, welche der Schnittstellen implementiert sind, und ruft sie in der entsprechenden Phase in der Pipeline auf.

Häufig gestellte Fragen

Warum sollte ich diese Plug-Ins erstellen?
A: Diese Plug-Ins bieten Ihnen nicht nur zusätzliche Möglichkeiten, um Ihre Umgebung vor Angriffen wie beispielsweise Kennwort-Spray-Angriffen zu schützen, sondern geben Ihnen auch die Flexibilität, eine auf Ihren Anforderungen basierende Risikobewertungslogik zu erstellen.

Wo werden die Protokolle erfasst?
A: Sie können Fehlerprotokolle mit der Methode „WriteAdminLogErrorMessage“ in das Ereignisprotokoll „AD FS/Admin“, Überwachungsprotokolle mit der Methode „WriteAuditMessage“ in das Sicherheitsprotokoll „AD FS Auditing“ und Debugprotokolle mit der Methode „WriteDebugMessage“ in das Debugprotokoll „AD FS Tracing“ schreiben.

Kann das Hinzufügen dieser Plug-Ins die Latenzzeit des AD FS-Authentifizierungsprozesses erhöhen?
A: Die Auswirkung auf die Latenzzeit richtet sich nach der Zeit, die für die Ausführung der von Ihnen implementierten Risikobewertungslogik benötigt wird. Wir empfehlen, die Auswirkungen auf die Latenzzeit zu untersuchen, bevor Sie das Plug-In in der Produktionsumgebung bereitstellen.

Warum kann AD FS keine Liste mit riskanten IP-Adressen, Risikobenutzern usw. vorschlagen?
A: Diese Funktion ist derzeit nicht verfügbar, aber wir arbeiten an einer intelligenten Lösung, um riskante IP-Adressen, Risikobenutzer usw. im austauschbaren Risikobewertungsmodell vorzuschlagen. Die Starttermine werden in Kürze veröffentlicht.

Welche weiteren Beispiel-Plug-Ins sind verfügbar?
A: Es stehen folgenden Beispiel-Plug-Ins zur Verfügung:

Name	BESCHREIBUNG
Plug-In für Risikobenutzer	Beispiel-Plug-In, das basierend auf der von Microsoft Entra ID-Schutz ermittelten Risikostufe des Benutzers die Authentifizierung blockiert oder eine Multi-Faktor-Authentifizierung (MFA) erzwingt.