Freigeben über

Optimieren von SQL und Beheben von Latenzproblemen mit AD FS

In einem Update für AD FS 2016haben wir die folgenden Verbesserungen eingeführt, um die datenbankübergreifende Latenz zu reduzieren. Ein bevorstehendes Update für AD FS 2019 enthält diese Verbesserungen.

Speicherinternes Cacheupdate im Hintergrundthread

In früheren Always on Availability (AoA)-Bereitstellungen war die Latenz für jeden "Read"-Vorgang vorhanden, da sich der Masterknoten in einem separaten Rechenzentrum befinden könnte. Der Aufruf zwischen zwei verschiedenen Rechenzentren führte zu einer Latenz.

Im neuesten Update für AD FS wird eine Verringerung der Latenz durch das Hinzufügen eines Hintergrundthreads zum Aktualisieren des AD FS-Konfigurationscaches und einer Einstellung zum Festlegen des Aktualisierungszeitraums ausgerichtet. Die für eine Datenbanksuche aufgewendete Zeit wird im Anforderungsthread erheblich reduziert, da die Datenbankcacheaktualisierungen in den Hintergrundthread verschoben werden.

Wenn die backgroundCacheRefreshEnabled auf "true" festgelegt ist, aktiviert AD FS den Hintergrundthread zum Ausführen von Cacheupdates. Die Häufigkeit des Abrufens von Daten aus dem Cache kann durch Festlegen von cacheRefreshIntervalSecsauf einen Zeitwert angepasst werden. Der Standardwert wird auf 300 Sekunden festgelegt, wenn backgroundCacheRefreshEnabled auf "true" festgelegt ist. Nach der Dauer des festgelegten Werts beginnt AD FS mit der Aktualisierung des Caches, während das Update ausgeführt wird, werden die alten Cachedaten weiterhin verwendet.

Wenn AD FS eine Anforderung für eine Anwendung empfängt, ruft AD FS die Anwendung aus SQL ab und fügt sie dem Cache hinzu. Bei dem Wert cacheRefreshIntervalSecs wird die Anwendung im Cache mithilfe des Hintergrundthreads aktualisiert. Während ein Eintrag im Cache vorhanden ist, verwenden eingehende Anforderungen den Cache, während die Hintergrundaktualisierung ausgeführt wird. Wenn auf einen Eintrag für 5 * cacheRefreshIntervalSecsnicht zugegriffen wird, wird er aus dem Cache gelöscht. Der älteste Eintrag kann auch aus dem Cache gelöscht werden, sobald der konfigurierbare maxRelyingPartyEntries Wert erreicht ist.

Hinweis

Die Daten des Caches werden außerhalb des cacheRefreshIntervalSecs Werts aktualisiert, wenn AD FS eine Benachrichtigung von SQL erhält, die angibt, dass eine Änderung in der Datenbank aufgetreten ist. Diese Benachrichtigung wird den Cache aktualisieren.

Empfehlungen zum Festlegen der Cacheaktualisierung

Der Standardwert für die Cacheaktualisierung ist fünf Minuten. Es wird empfohlen, sie auf 1 Stunde festzulegen, um eine unnötige Datenaktualisierung durch AD FS zu reduzieren, da die Cachedaten aktualisiert werden, wenn SQL-Änderungen vorgenommen werden.

AD FS registriert einen Rückruf für SQL-Änderungen, und bei einer Änderung empfängt AD FS eine Benachrichtigung. Durch diese Methode empfängt AD FS jede neue Änderung von SQL, sobald sie eintritt.

Im Falle eines Netzwerkfehlers, der dazu führt, dass AD FS die SQL-Benachrichtigung fehlt, wird AD FS im durch den Cacheaktualisierungswert angegebenen Intervall aktualisiert. Wenn Konnektivitätsprobleme zwischen AD FS und SQL vermutet werden, wird empfohlen, den Cacheaktualisierungswert auf unter 1 Stunde festzulegen.

Konfigurationsanweisungen

Die Konfigurationsdatei unterstützt mehrere Cacheeinträge. Die unten aufgeführten Punkte können basierend auf den Anforderungen Ihrer Organisation konfiguriert werden.

Im folgenden Beispiel wird die Aktualisierung des Hintergrundcaches aktiviert und der Cacheaktualisierungszeitraum auf 1800 Sekunden oder 30 Minuten festgelegt. Dies muss auf jedem AD FS-Knoten erfolgen, und der AD FS-Dienst muss danach neu gestartet werden. Die Änderungen wirken sich nicht auf andere Knoten aus, und testen Sie den ersten Knoten, bevor Sie die Änderung in allen Knoten vornehmen.

  1. Navigieren Sie zur AD FS-Konfigurationsdatei (Standardspeicherort C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config), und fügen Sie unter dem Abschnitt "Microsoft.IdentityServer.Service" den folgenden Eintrag hinzu:
  • backgroundCacheRefreshEnabled – Gibt an, ob das Feature für den Hintergrundcache aktiviert ist. "true/false"-Werte.
  • cacheRefreshIntervalSecs – Wert in Sekunden, in denen AD FS den Cache aktualisiert. AD FS aktualisiert den Cache, wenn eine Änderung in SQL vorhanden ist. AD FS erhält eine SQL-Benachrichtigung und aktualisiert den Cache.

Hinweis

Bei allen Einträgen in der Konfigurationsdatei wird die Groß-/Kleinschreibung beachtet. <cache cacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />

Zusätzliche unterstützte konfigurierbare Werte:

  • maxRelyingPartyEntries – Maximale Anzahl der Einträge der vertrauenden Seite, die AD FS im Arbeitsspeicher behält. Dieser Wert wird auch vom oAuth-Anwendungsberechtigungscache verwendet. Wenn mehr Anwendungsberechtigungen als RPs vorhanden sind und alle im Arbeitsspeicher gespeichert werden, sollte dieser Wert die Anzahl der Anwendungsberechtigungen sein. Der Standardwert ist 1000.
  • maxIdentityProviderEntries – Dies ist die maximale Anzahl von Forderungsanbietereinträgen, die AD FS im Arbeitsspeicher behält. Der Standardwert ist 200.
  • maxClientEntries – Dies ist die maximale Anzahl von OAuth-Clienteinträgen, die AD FS im Arbeitsspeicher behält. Der Standardwert ist 500.
  • maxClaimDescriptorEntries – Die maximale Anzahl von Anspruchsbeschreibungseinträgen, die AD FS im Arbeitsspeicher behält. Der Standardwert ist 500.
  • maxNullEntries - Dies wird als negativer Cache verwendet. Wenn AD FS nach einem Eintrag in der Datenbank sucht und nicht gefunden wird, fügt AD FS einen negativen Cache hinzu. Dies ist die maximale Größe dieses Caches. Es gibt einen negativen Cache für jeden Objekttyp, es ist kein einzelner Cache für alle Objekte. Der Standardwert ist 50.0000.

Unterstützung mehrerer Artefaktdatenbanken über mehrere Rechenzentren hinweg

Bei früheren Konfigurationen mehrerer Rechenzentren hat AD FS nur eine einzelne Artefaktdatenbank unterstützt, was zu einer rechenzentrumsübergreifenden Rechenzentrumslatenz bei Abrufaufrufen führt.

Um die Rechenzentrumslatenz zu verringern, kann ein AD FS-Administrator jetzt mehrere Artefakt-DB-Instanzen bereitstellen und dann die Konfigurationsdatei eines AD FS-Knotens so ändern, dass sie auf verschiedene Artefakt-DB-Instanzen verweist. Die Artefaktdatenbankverbindungszeichenfolge kann in der Konfigurationsdatei angegeben werden, wodurch eine Artefakt-DB pro Knoten möglich ist. Wenn die Verbindungszeichenfolge nicht in der Konfigurationsdatei vorhanden ist, wird der Knoten auf den vorherigen Entwurf zurückfallen, um die Artefaktdatenbank zu verwenden, die in der Konfigurationsdatenbank vorhanden ist. Hybridumgebungen werden auch mit dieser Konfiguration unterstützt.

Anforderungen

Führen Sie vor dem Einrichten der Unterstützung mehrerer Artefaktdatenbanken ein Update für alle Knoten aus, und aktualisieren Sie die Binärdateien, da Aufrufe mit mehreren Knoten über dieses Feature erfolgen.

  1. Generieren Sie ein Bereitstellungsskript zum Erstellen der Artifact DB: Um mehrere Artefakt-DB-Instanzen bereitzustellen, muss ein Administrator das SQL-Bereitstellungsskript für die Artifact DB generieren. Im Rahmen dieses Updates wurde das vorhandene cmdlet Export-AdfsDeploymentSQLScriptaktualisiert, um optional einen Parameter zu übernehmen, der angibt, für welche AD FS-Datenbank ein SQL-Bereitstellungsskript generiert werden soll.

Um z. B. das Bereitstellungsskript nur für die Artifact DB zu generieren, geben Sie den -DatabaseType-Parameter an, und übergeben Sie den Wert "Artifact". Der optionale -DatabaseType Parameter gibt den AD FS-Datenbanktyp an und kann auf: Alle (Standard), Artefakt oder Konfiguration festgelegt werden. Wenn kein -DatabaseType Parameter angegeben ist, konfiguriert das Skript sowohl die Artefakt- als auch die Konfigurationsskripts.

PS C:\> Export-AdfsDeploymentSQLScript -DestinationFolder <script folder where scripts will be created> -ServiceAccountName <domain\serviceaccount> -DatabaseType "Artifact"

Das generierte Skript sollte auf dem SQL-Computer ausgeführt werden, um die erforderlichen Datenbanken zu erstellen und dem AD FS-Dienstkonto, SQL SA-Berechtigungen für diese Datenbanken zu erteilen.

  1. Erstellen Sie die Artifact DB mithilfe des Bereitstellungsskripts. Kopieren Sie die neu generierten CreateDB.sql und SetPermissions.sql Bereitstellungsskripts auf den SQL Server-Computer, und führen Sie sie aus, um die lokale Artifact DB zu erstellen.

  2. Ändern Sie die Konfigurationsdatei, um die Artifact DB-Verbindung hinzuzufügen. Navigieren Sie zur Konfigurationsdatei des AD FS-Knotens, und fügen Sie unter dem Abschnitt "Microsoft.IdentityServer.Service" einen Einstiegspunkt zur neu konfigurierten ArtifactDB hinzu.

Hinweis

Bei den Werten artifactStore und connectionString ist die Groß-/Kleinschreibung zu berücksichtigen. Stellen Sie sicher, dass sie ordnungsgemäß konfiguriert sind. <artifactStore connectionString="Data Source=.\SQLInstance;Integrated Security=True;Initial Catalog=AdfsArtifactStore" />

Verwenden Sie einen Datenquellenwert, der Ihrer SQL-Verbindung entspricht.

  1. Starten Sie den AD FS-Dienst neu, damit die Änderungen wirksam werden.

Hinweis

Es wird nicht empfohlen, die SQL-Replikation oder Synchronisierung zwischen den Artefaktdatenbanken zu verwenden. Es wird empfohlen, eine Artefaktdatenbank pro Rechenzentrum einzurichten.

Rechenzentrumsübergreifendes Failover und Datenbankwiederherstellung

Es wird empfohlen, Failoverartefaktedatenbanken im selben Rechenzentrum wie die Masterartefaktdatenbank zu erstellen. Wenn ein Failover auftritt, wird die Latenz nicht erhöht. Failoverartefaktdatenbanken in verschiedenen Rechenzentren werden nicht empfohlen. Im Folgenden wird erläutert, wie Aufrufe für die Erkennung von OAuth, SAML, ESL und Tokenwiedergabe mit mehreren Artefaktdatenbanken ausgeführt werden.

  • OAuth und SAML

    Bei OAuth- und SAML-Artefaktanforderungen erstellt der Knoten das Artefakt in der Artefakt-DB, das in der Konfigurationsdatei vorhanden ist. Wenn die Konfigurationsdatei keine Artefaktdatenbankverbindung enthält, wird die allgemeine Artefakt-DB verwendet. Wenn die nächste Anforderung zum Abrufen des Artefakts an einen anderen Knoten geht, übergibt der andere Knoten die Rest-API dem ersten Knoten, um das Artefakt aus der Artefaktdatenbank abzurufen. Dies ist erforderlich, da unterschiedliche Knoten möglicherweise unterschiedliche Artefaktdatenbanken haben und die Knoten dies nicht wissen. Wenn der erste Knoten ausgefallen ist, schlägt die Artefaktauflösung fehl. Aufgrund dieses Designs ist das Replizieren der Artefakt-DB in verschiedenen Rechenzentren nicht erforderlich. Wenn ein gesamtes Rechenzentrum ausgefallen ist, ist höchstwahrscheinlich auch der Knoten, der das Artefakt erstellt hat, ausgefallen, was bedeutet, dass das Artefakt nicht mehr aufgelöst werden kann.

  • Extranetsperrung

    Die Artefaktdatenbank, auf die in der Konfigurationsdatei verwiesen wird, wird für Extranetsperrungsdaten verwendet. Für das ESL-Feature wählt AD FS jedoch einen Master aus, der die Daten in der Artefakt-DB schreibt. Alle Knoten führen einen REST-API-Aufruf an den Masterknoten durch, um die neuesten Informationen zu jedem Benutzer abzurufen und festzulegen. Wenn mehrere Artefaktdatenbanken verwendet werden, muss der Administrator einen Masterknoten für jedes Artefakt-DB oder Rechenzentrum auswählen.

    Um einen Knoten als ESL-Master auszuwählen, navigieren Sie zur Konfigurationsdatei des AD FS-Knotens, und fügen Sie unter dem Abschnitt "Microsoft.IdentityServer.Service" Folgendes hinzu:

    Fügen Sie im Master den folgenden Eintrag hinzu. Bei allen drei Schlüsseln ist die Groß-/Kleinschreibung zu beachten.

    <useractivityfarmrole masterFQDN=[FQDN of the selected primary] isMaster="true"/>

    Fügen Sie auf den anderen Knoten den folgenden Eintrag hinzu:

    <useractivityfarmrole masterFQDN=[FQDN of the selected primary] isMaster="false"/>

    Hinweis

    Da mehrere Artefaktdatenbanken keine Daten synchronisieren, werden ESL-Werte nicht zwischen Artefakt-DBs synchronisiert. Ein Benutzer kann bei einer Anfrage möglicherweise auf ein anderes Rechenzentrum zugreifen, wodurch der ExtranetLockoutThreshold von der Anzahl der Artefakt-DBs abhängt: ExtranetLockoutThreshold * Anzahl der Artefakt-DBs.

    • Token Replay Detection

      Tokenwiedergabeerkennungsdaten werden immer aus der zentralen Artefaktdatenbank aufgerufen. AD FS speichert das Token aus der Anspruchsanbieter-Vertrauensstellung, um sicherzustellen, dass dasselbe Token nicht wiedergegeben werden kann. Wenn ein Angreifer versucht, dasselbe Token wiederzuverspielen, überprüft AD FS, ob das Token in der Artifact DB vorhanden ist. Wenn das Token vorhanden ist, wird die Anforderung abgelehnt. Die zentrale Artefaktdatenbank wird zur Sicherheit verwendet, da die Artifact DB-Daten nicht repliziert werden, könnte ein Angreifer die Anforderung an ein anderes Rechenzentrum senden und ein Token wiedergeben. Das Erstellen zusätzlicher schreibgeschützter Kopien der ArtifactDB verhindert in diesem Szenario keine rechenzentrumsübergreifende Latenz, da nur die zentrale Artefaktdatenbank verwendet wird.