Optimisation de SQL et résolution des problèmes de latence avec AD FS

  • Article

Dans une mise à jour pour AD FS 2016, nous avons introduit les améliorations suivantes pour réduire la latence entre les bases de données. Une prochaine mise à jour pour AD FS 2019 inclura ces améliorations.

Mise à jour du cache en mémoire dans le thread d’arrière-plan

Dans les déploiements AoA (Disponibilité Always On) précédents, la latence existait pour toute opération « Lecture », car le nœud maître pouvait se trouver dans un centre de données distinct. L’appel entre deux centres de données différents a causé une latence.

Dans la dernière mise à jour d’AD FS, une réduction de la latence est ciblée par l’ajout d’un thread d’arrière-plan pour actualiser le cache de configuration d’AD FS et d’un paramètre pour définir la période d’actualisation. Le temps consacré à une recherche dans une base de données est considérablement réduit dans le thread de requêtes, car les mises à jour du cache de la base de données sont déplacées dans le thread d’arrière-plan.

Lorsque backgroundCacheRefreshEnabled est défini sur true, AD FS permet au thread d’arrière-plan d’exécuter les mises à jour du cache. La fréquence d’extraction des données du cache peut être personnalisée sur une valeur de temps en paramétrant cacheRefreshIntervalSecs. La valeur par défaut est définie sur 300 secondes quand backgroundCacheRefreshEnabled est défini sur true. Après la durée de la valeur définie, AD FS commence à actualiser son cache et pendant que la mise à jour est en cours, les anciennes données du cache continueront d’être utilisées.

Quand AD FS reçoit une requête pour une application, AD FS récupère l’application à partir de SQL et l’ajoute au cache. Au niveau de la valeur cacheRefreshIntervalSecs, l’application dans le cache est actualisée à l’aide du thread d’arrière-plan. Lorsqu’une entrée existe dans le cache, les requêtes entrantes utilisent le cache pendant que l’actualisation en arrière-plan est en cours. Si une entrée n’est pas accessible pour 5 * cacheRefreshIntervalSecs, elle est supprimée du cache. L’entrée la plus ancienne peut également être supprimée du cache une fois la valeur maxRelyingPartyEntries configurable atteinte.

Notes

Les données du cache sont actualisées en dehors de la valeur cacheRefreshIntervalSecs si AD FS reçoit une notification de SQL indiquant qu’une modification s’est produite dans la base de données. Cette notification déclenche l’actualisation du cache.

Suggestions pour paramétrer l’actualisation du cache

La valeur par défaut de l’actualisation du cache est de cinq minutes. Il est recommandé de la définir sur 1 heure pour réduire une actualisation inutile des données par AD FS, car les données du cache seront actualisées si des modifications SQL se produisent.

AD FS inscrit un rappel pour les modifications SQL et, en cas de modification, AD FS reçoit une notification. Grâce à cette méthode, AD FS reçoit chaque nouvelle modification de SQL dès qu’elle se produit.

En cas de problème réseau, qui entraîne l’absence de notification SQL dans AD FS, AD FS s’actualise à l’intervalle spécifié par la valeur d’actualisation du cache. Si des problèmes de connectivité sont suspectés entre AD FS et SQL, il est recommandé de définir la valeur d’actualisation du cache sur une valeur inférieure à 1 heure.

Instructions de configuration

Le fichier de configuration prend en charge plusieurs entrées de cache. Les éléments répertoriés ci-dessous peuvent être tous configurés en fonction des besoins de votre organisation.

L’exemple suivant active l’actualisation du cache en arrière-plan et définit la période d’actualisation du cache sur 1800 secondes ou 30 minutes. Cette opération doit être effectuée sur chaque nœud AD FS et le service AD FS doit être redémarré par la suite. Les modifications n’ont pas d’impact sur les autres nœuds et testent le premier nœud avant d’effectuer la modification à tous les nœuds.

  1. Accédez au fichier de configuration AD FS (emplacement par défaut C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) et, sous la section « Microsoft.IdentityServer.Service », ajoutez l’entrée ci-suivante :
  • backgroundCacheRefreshEnabled : Spécifie si la fonctionnalité de cache en arrière-plan est activée. Valeurs «true/false».
  • cacheRefreshIntervalSecs : Valeur en secondes à laquelle AD FS actualise le cache. AD FS actualise le cache en cas de modification dans SQL. AD FS reçoit une notification SQL et actualise le cache.

Notes

Toutes les entrées dans le fichier de configuration respectent la casse. <cache cacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />

Valeurs configurables supplémentaires prises en charge :

  • maxRelyingPartyEntries : nombre maximal d’entrées de partie de confiance qu’AD FS conserve en mémoire. Cette valeur est également utilisée par le cache d’autorisation de l’application oAuth. S’il y a plus d’autorisations d’application que de RP et si toutes sont stockées en mémoire, cette valeur doit être le nombre d’autorisations d’application. La valeur par défaut est 1000.
  • maxIdentityProviderEntries : il s’agit du nombre maximal d’entrées de fournisseur de revendications qu’AD FS conserve en mémoire. La valeur par défaut est 200.
  • maxClientEntries: il s’agit du nombre maximal d’entrées clientes OAuth qu’AD FS conserve en mémoire. La valeur par défaut est 500.
  • maxClaimDescriptorEntries : nombre maximal d’entrées de descripteur de revendication qu’AD FS conserve en mémoire. La valeur par défaut est 500.
  • maxNullEntries : il s’agit d’un cache négatif. Quand AD FS recherche une entrée dans la base de données et qu’elle est introuvable, AD FS ajoute un cache négatif. Il s’agit de la taille maximale de ce cache. Il existe un cache négatif pour chaque type d’objets. Il ne s’agit pas d’un cache unique pour tous les objets. La valeur par défaut est 50 0000.

Prise en charge de plusieurs bases de données d’artefacts dans les centres de données

Concernant les configurations antérieures de plusieurs centres de données, AD FS ne prenait en charge qu’une seule base de données Artifact, ce qui entraînait une latence entre les centres de données pendant les appels de récupération.

Pour réduire la latence entre les centres de données, un administrateur AD FS peut désormais déployer plusieurs instances de base de données d’artefacts, puis modifier le fichier de configuration d’un nœud AD FS pour qu’il pointe vers différentes instances de base de données d’artefacts. La chaîne de connexion de la base de données d’artefacts peut être fournie dans le fichier de configuration, ce qui autorise une base de données d’artefacts par nœud. Si la chaîne de connexion n’est pas présente dans le fichier de configuration, le nœud revient à la conception précédente pour utiliser la base de données d’artefacts, qui est présente dans la base de données de configuration. Les environnements hybrides sont aussi pris en charge avec cette configuration.

Configuration requise

Avant de configurer la prise en charge de plusieurs bases de données d’artefacts, exécutez une mise à jour sur tous les nœuds, puis mettez à jour les fichiers binaires, car les appels à plusieurs nœuds se produisent via cette fonctionnalité.

  1. Générer un script de déploiement pour créer la base de données d’artefacts : pour déployer plusieurs instances de base de données d’artefacts, un administrateur doit générer le script de déploiement SQL pour la base de données d’artefacts. Dans le cadre de cette mise à jour, l’applet de commande Export-AdfsDeploymentSQLScript existante a été mise à jour pour prendre éventuellement un paramètre spécifiant la base de données AD FS pour laquelle générer un script de déploiement SQL.

Par exemple, pour générer le script de déploiement uniquement pour la base de données d’artefacts, spécifiez le paramètre -DatabaseType et transmettez la valeur « Artifact ». Le paramètre facultatif -DatabaseType spécifie le type de base de données AD FS et peut être défini sur : Tout (par défaut), Artefact ou Configuration. Si aucun paramètre -DatabaseType n’est spécifié, le script configure les scripts Artifact et Configuration.

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

Le script généré doit être exécuté sur l’ordinateur SQL pour créer les bases de données requises et accorder au compte de service AD FS des autorisations SA SQL à ces bases de données.

  1. Créez la base de données d’artefacts à l’aide du script de déploiement. Copiez les scripts de déploiement CreateDB.sql et SetPermissions.sql nouvellement générés sur la machine SQL Server et exécutez-les pour créer la base de données d’artefacts locale.

  2. Modifiez le fichier de configuration pour ajouter la connexion à la base de données d’artefacts. Accédez au fichier de configuration du nœud AD FS et, sous la section « Microsoft.IdentityServer.Service », ajoutez un point d’entrée à la nouvelle base de données d’artefacts configurée.

Notes

artifactStore et connectionString sont des valeurs qui respectent la casse. Vérifiez qu’elles sont correctement configurées. <artifactStore connectionString="Data Source=.\SQLInstance;Integrated Security=True;Initial Catalog=AdfsArtifactStore" />

Utilisez une valeur de source de données qui correspond à votre connexion SQL.

  1. Redémarrez le service AD FS pour que les modifications soient prises en compte.

Notes

Il n’est pas recommandé d’utiliser la réplication ou la synchronisation SQL entre les bases de données d’artefacts. Il est suggéré de configurer une seule base de données d’artefacts par centre de données.

Basculement entre centres de données et récupération de bases de données

Il est recommandé de créer des bases de données d’artefacts de basculement sur le même centre de données que la base de données d’artefacts principale. Si un basculement se produit, il n’y a aucune augmentation de la latence. Les bases de données d’artefacts de basculement entre les centres de données ne sont pas recommandées. Les éléments suivants expliquent comment les appels pour OAuth, SAML, ESL et la détection de relecture de jetons fonctionnent avec plusieurs bases de données d’artefacts.

  • OAuth et SAML

    Pour les requêtes d’artefact OAuth et SAML, le nœud crée l’artefact dans la base de données d’artefacts présente dans le fichier de configuration. Si le fichier de configuration ne contient pas de connexion à une base de données d’artefacts, il utilise la base de données d’artefacts commune. Lorsque la requête suivante d’extraction de l’artefact va à un autre nœud, l’autre nœud positionne l’API REST au premier nœud pour extraire l’artefact de la base de données d’artefacts. Cela est nécessaire, car les différents nœuds peuvent avoir des bases de données d’artefacts différentes et les nœuds l’ignorent. Si le 1er nœud est en panne, la résolution de l’artefact échoue. En raison de cette conception, la réplication de la base de données d’artefacts dans différents centres de données n’est pas nécessaire. Si un centre de données entier est en panne, il est fort probable que le nœud qui a créé l’artefact soit également en panne, ce qui signifie que l’artefact ne peut plus être résolu.

  • Verrouillage extranet

    La base de données d’artifacts référencée dans le fichier de configuration est utilisée pour les données de verrouillage extranet. Cependant, pour la fonctionnalité ESL, AD FS choisit un ESL principal qui écrit les données dans la base de données d’artefacts. Tous les nœuds effectuent un appel d’API REST au nœud principal pour obtenir et définir les dernières informations sur chaque utilisateur. Si plusieurs bases de données d’artefacts sont utilisées, l’administrateur doit sélectionner un nœud principal pour chaque base de données d’artefacts ou centre de données.

    Pour sélectionner un nœud à utiliser comme ESL principal, accédez au fichier de configuration du nœud AD FS et, dans la section « Microsoft.IdentityServer.Service », ajoutez les éléments suivants :

    Sur l’ESL principal, ajoutez l’entrée suivante. Les trois clés respectent la casse.

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

    Sur les autres nœuds, ajoutez l’entrée suivante :

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

    Notes

    Étant donné que plusieurs bases de données d’artefacts ne synchronisent pas les données, les valeurs ESL ne sont pas synchronisées entre les bases de données d’artefacts. Un utilisateur peut potentiellement atteindre un autre centre de données pour une requête, ce qui rend ExtranetLockoutThreshold dépendant du nombre de bases de données d’artefacts, ExtranetLockoutThreshold * Nombre de bases de données d’artefacts.

    • Détection de relecture de jetons

      Les données de détection de relecture de jetons sont toujours appelées à partir de la base de données d’artefacts centrale. AD FS enregistre le jeton à partir de l’approbation du fournisseur de revendications, ce qui garantit que le même jeton ne peut pas être relu. Si un attaquant essaye de relire le même jeton, AD FS vérifie si le jeton existe dans la base de données d’artefacts. Si le jeton est présent, la requête est rejetée. La base de données d’artefacts centrale est utilisée à des fins de sécurité, car, étant donné que les données de la base de données d’artefacts ne sont pas répliquées, un attaquant peut envoyer la requête à un autre centre de données et relire un jeton. La création de copies supplémentaires en lecture seule de la base de données d’artefacts n’empêche pas la latence entre les centres de données dans ce scénario, car seule la base de données d’artefacts centrale est utilisée.