Ajuste preciso de SQL y resolución de problemas de latencia con AD FS

En una actualización de AD FS 2016, se introdujeron las siguientes mejoras para reducir la latencia entre bases de datos. Una próxima actualización de AD FS 2019 incluirá estas mejoras.

Actualización de la memoria caché en subproceso en segundo plano

En implementaciones anteriores de Disponibilidad Always On (AoA), existía latencia para cualquier operación de "lectura", ya que el nodo maestro podría encontrarse en un centro de datos separado. La llamada entre dos centros de datos diferentes dio lugar a una latencia.

En la última actualización de AD FS, se logra una reducción de la latencia mediante la adición de un hilo en segundo plano para actualizar la caché de configuración de AD FS y una configuración para establecer el intervalo de actualización. El tiempo invertido en una búsqueda de base de datos se reduce significativamente en el subproceso de solicitud, ya que las actualizaciones de caché de la base de datos se mueven al subproceso en segundo plano.

Cuando se establece en backgroundCacheRefreshEnabled true, AD FS permitirá que el subproceso en segundo plano ejecute actualizaciones de caché. La frecuencia de captura de datos de la memoria caché se puede personalizar a un valor de hora estableciendo cacheRefreshIntervalSecs. El valor predeterminado se establece en 300 segundos cuando backgroundCacheRefreshEnabled se establece en true. Después de la duración del valor establecido, AD FS comienza a actualizar su caché y mientras la actualización está en curso, se seguirán usando los datos de caché antiguos.

Cuando AD FS recibe una solicitud de una aplicación, AD FS recupera la aplicación de SQL y la agrega a la memoria caché. En el valor cacheRefreshIntervalSecs, la aplicación de la memoria caché se actualiza mediante el subproceso en segundo plano. Aunque existe una entrada en la memoria caché, las solicitudes entrantes usarán la memoria caché mientras la actualización en segundo plano está en curso. Si no se tiene acceso a una entrada durante 5 * cacheRefreshIntervalSecs, se quita de la memoria caché. La entrada más antigua también se puede quitar de la memoria caché una vez alcanzado el valor configurable maxRelyingPartyEntries .

Recomendaciones para establecer la actualización de caché

El valor predeterminado para la actualización de caché es de cinco minutos. Se recomienda establecerlo en 1 hora para reducir una actualización de datos innecesaria por AD FS, ya que los datos de caché se actualizarán si se producen cambios en SQL.

AD FS registra un callback para los cambios de SQL y, cuando se produce un cambio, AD FS recibe una notificación. A través de este método, AD FS recibe cada nuevo cambio de SQL en cuanto se produce.

En caso de que se produzca un error de red, lo que da lugar a que AD FS falte la notificación de SQL, AD FS se actualizará en el intervalo especificado por el valor de actualización de caché. Si se sospecha algún problema de conectividad entre AD FS y SQL, se recomienda establecer el valor de actualización de caché en menos de 1 hora.

Instrucciones de configuración

El archivo de configuración admite varias entradas de caché. Las siguientes opciones se pueden configurar en función de las necesidades de su organización.

En el ejemplo siguiente se habilita la actualización de caché en segundo plano y se establece el período de actualización de caché en 1800 segundos o 30 minutos. Esto debe hacerse en cada nodo de AD FS y el servicio de AD FS debe reiniciarse posteriormente. Los cambios no afectan a otros nodos y prueban el primer nodo antes de realizar el cambio en todos los nodos.

1. Vaya al archivo de configuración de AD FS (ubicación predeterminada C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) y, en la sección "Microsoft.IdentityServer.Service", agregue la entrada siguiente:

• backgroundCacheRefreshEnabled : especifica si la característica de caché en segundo plano está habilitada. Valores "verdadero/falso".
• cacheRefreshIntervalSecs - Valor en segundos en el que AD FS actualizará la memoria caché. AD FS actualizará la memoria caché si hay algún cambio en SQL. AD FS recibirá una notificación de SQL y actualizará la memoria caché.

Valores configurables adicionales admitidos:

• maxRelyingPartyEntries - Número máximo de entradas de parte confiable que AD FS mantendrá en memoria. Este valor también lo usa la caché de permisos de la aplicación oAuth. Si hay más permisos de aplicación que los RPs y si todos se almacenarán en memoria, este valor debería ser el número de permisos de aplicación. El valor predeterminado es 1000.
• maxIdentityProviderEntries - este es el número máximo de entradas del proveedor de reclamaciones que AD FS mantendrá en memoria. El valor predeterminado es 200.
• maxClientEntries : este es el número máximo de entradas de cliente de OAuth que AD FS mantendrá en memoria. El valor predeterminado es 500.
• maxClaimDescriptorEntries - Número máximo de entradas del descriptor de reclamo que AD FS almacenará en memoria. El valor predeterminado es 500.
• maxNullEntries : se usa como caché negativa. Cuando AD FS busca una entrada en la base de datos y no se encuentra, AD FS agrega una memoria caché negativa. Este es el tamaño máximo de esa memoria caché. Hay una caché negativa para cada tipo de objetos, no es una sola caché para todos los objetos. El valor predeterminado es 50 0000.

Compatibilidad con varias bases de datos de artefactos en centros de datos

En el caso de las configuraciones anteriores de varios centros de datos, AD FS solo admite una base de datos artifact única, lo que provoca una latencia entre centros de datos durante las llamadas de recuperación.

Para reducir la latencia entre centros de datos, un administrador de AD FS ahora puede implementar varias instancias de base de datos de artefactos y, a continuación, modificar el archivo de configuración de un nodo de AD FS para que apunte a diferentes instancias de base de datos de artefactos. La cadena de conexión de la base de datos de artefactos se puede proporcionar en el archivo de configuración, lo que permite una base de datos de artefacto por nodo. Si la cadena de conexión no está presente en el archivo de configuración, el nodo volverá al diseño anterior para usar la base de datos de artefactos, que está presente en la base de datos de configuración. Los entornos híbridos también se admiten con esta configuración.

Requirements

Antes de configurar la compatibilidad con varias bases de datos de artefactos, ejecute una actualización en todos los nodos y actualice los archivos binarios, ya que las llamadas a varios nodos se producen a través de esta característica.

1. Generar script de implementación para crear la base de datos de artefactos: para implementar varias instancias de base de datos de artefactos, un administrador deberá generar el script de implementación de SQL para la base de datos artifact. Como parte de esta actualización, el cmdlet existente Export-AdfsDeploymentSQLScriptse ha actualizado para tomar opcionalmente un parámetro que especifica la base de datos de AD FS para la que generar un script de implementación de SQL.

Por ejemplo, para generar el script de implementación solo para Artifact DB, especifique el parámetro y pase el valor -DatabaseType como "Artifact". El parámetro opcional -DatabaseType especifica el tipo de base de datos de AD FS y se puede establecer en: Todos (valor predeterminado), Artefacto o Configuración. Si no se especifica ningún -DatabaseType parámetro, el script configurará los scripts artifact y Configuration.

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

El script generado debe ejecutarse en la máquina SQL para crear las bases de datos necesarias y conceder a la cuenta de servicio de AD FS permisos de SA de SQL a esas bases de datos.

1. Cree la base de datos artifact mediante el script de implementación. Copie los scripts de implementación recién generados CreateDB.sql y SetPermissions.sql a la máquina con SQL Server y ejecútelos para crear la base de datos de artefactos local.

2. Modifique el archivo de configuración para agregar la conexión de artifact DB. Vaya al archivo de configuración del nodo de AD FS y, en la sección "Microsoft.IdentityServer.Service", agregue un punto de entrada a ArtifactDB recién configurado.

3. Reinicie el servicio AD FS para que los cambios surtan efecto.

Conmutación por error entre centros de datos y recuperación de bases de datos

Se recomienda crear bases de datos de artefactos de conmutación por error en el mismo centro de datos que la base de datos de artefactos maestros. Si se produce una conmutación por error, no habrá ningún aumento en la latencia. No se recomiendan bases de datos de artefactos de conmutación por error entre centros de datos. A continuación se detalla cómo llama a OAuth, SAML, ESL y función de detección de reproducción de tokens con varias bases de datos de artefactos.

• OAuth y SAML

  En el caso de las solicitudes de artefacto de OAuth y SAML, el nodo creará el artefacto en la base de datos del artefacto presente en el archivo de configuración. Si el archivo de configuración no contiene una conexión de base de datos de artefactos, usará la base de datos de artefacto común. Cuando la siguiente solicitud para capturar el artefacto se dirige a otro nodo, el otro nodo realizará una API rest al primer nodo capture el artefacto de la base de datos del artefacto. Esto es necesario, ya que los distintos nodos pueden tener bases de datos de artefactos diferentes y los nodos no saben sobre eso. Si el 1º nodo está inactivo, se producirá un error en la resolución del artefacto. Debido a este diseño, no es necesario replicar la base de datos de artefactos en distintos centros de datos. Si un centro de datos completo está inactivo, lo más probable es que el nodo que creó el artefacto también esté inactivo, significa que el artefacto ya no se puede resolver.

• Bloqueo de extranet

  La base de datos artifact a la que se hace referencia en el archivo de configuración se usará para los datos de bloqueo de extranet. Sin embargo, para la característica ESL, AD FS elige un patrón, que escribe los datos en la base de datos de artefactos. Todos los nodos realizan una llamada API REST al nodo maestro para obtener y establecer la información más reciente sobre cada usuario. Si hay varias bases de datos de artefactos en uso, el administrador debe seleccionar un nodo maestro para cada base de datos de artefacto o centro de datos.

  Para seleccionar un nodo como maestro ESL, vaya al archivo de configuración del nodo de AD FS y, en la sección "Microsoft.IdentityServer.Service", agregue lo siguiente:

  En el patrón, agregue la siguiente entrada. Las tres claves distinguen mayúsculas de minúsculas.

  <useractivityfarmrole masterFQDN=[FQDN del principal seleccionado] isMaster="true"/>

  En los demás nodos, agregue la entrada siguiente:

  <useractivityfarmrole masterFQDN=[FQDN del principal seleccionado] isMaster="true"/>

  Note

  Dado que varias bases de datos de artefactos no sincronizan datos, los valores de ESL no se sincronizarán entre bases de datos de artefacto. Un usuario puede alcanzar potencialmente un centro de datos diferente para una solicitud, por lo que la extranetLockoutThreshold depende del número de bases de datos de artefactos, ExtranetLockoutThreshold * Número de bases de datos de artefactos.

  • Detección de reproducción de token

    Los datos de detección de reproducción de tokens siempre se llaman desde la base de datos de artefactos central. AD FS guarda el token de la confianza del proveedor de notificaciones, lo que garantiza que no se pueda reproducir el mismo token. Si un atacante intenta reproducir el mismo token, AD FS comprueba si el token existe en la base de datos artifact. Si el token está presente, se rechazará la solicitud. La base de datos de artefactos central se usa para la seguridad, ya que los datos de la base de datos de artefactos no se replican, un atacante podría enviar la solicitud a otro centro de datos y reproducir un token. La creación de copias adicionales de solo lectura de ArtifactDB no impedirá la latencia entre centros de datos en este escenario, ya que solo se usa la base de datos de artefacto central.