Ajuste fino do SQL e resolução de problemas de latência com o AD FS

Em uma atualização para AD FS 2016, introduzimos os seguintes aprimoramentos para reduzir a latência entre bancos de dados. Uma próxima atualização para o AD FS 2019 incluirá essas melhorias.

Atualização de cache em memória em thread de segundo plano

Em implementações anteriores de Always On Availability (AoA), havia latência para qualquer operação de "Leitura", pois o nó principal podia estar localizado num centro de dados separado. A chamada entre dois datacenters diferentes resultou em latência.

Na atualização mais recente do AD FS, uma redução na latência é direcionada por meio da adição de um thread em segundo plano para atualizar o cache de configuração do AD FS e uma configuração para definir o período de tempo de atualização. O tempo gasto para uma pesquisa de banco de dados é significativamente reduzido no thread de solicitação, à medida que as atualizações de cache do banco de dados são movidas para o thread em segundo plano.

Quando o backgroundCacheRefreshEnabled estiver definido como true, o AD FS habilitará o thread em segundo plano para executar atualizações de cache. A frequência de busca de dados do cache pode ser configurada para um intervalo de tempo definindo cacheRefreshIntervalSecs. O valor padrão é definido como 300 segundos quando backgroundCacheRefreshEnabled é definido como true. Após a duração do valor definido, o AD FS começa a atualizar seu cache e, enquanto a atualização estiver em andamento, os dados de cache antigos continuarão a ser usados.

Quando o AD FS recebe uma solicitação para um aplicativo, o AD FS recupera o aplicativo do SQL e o adiciona ao cache. No valor cacheRefreshIntervalSecs, o aplicativo no cache é atualizado usando o thread em segundo plano. Enquanto existir uma entrada no cache, as solicitações de entrada usarão o cache enquanto a atualização em segundo plano estiver em andamento. Se uma entrada não for acessada por 5 * cacheRefreshIntervalSecs, ela será descartada do cache. A entrada mais antiga também pode ser descartada do cache assim que o valor de maxRelyingPartyEntries configurável for atingido.

Recomendações para definir a atualização do cache

O valor padrão para a atualização do cache é cinco minutos. Recomenda-se defini-lo com o parâmetro por 1 hora para reduzir uma atualização de dados desnecessária pelo AD FS, pois os dados de cache serão atualizados se ocorrerem alterações no SQL.

O AD FS regista uma chamada de retorno para alterações do SQL e, após uma alteração, o AD FS recebe uma notificação. Por meio desse método, o AD FS recebe cada nova alteração do SQL assim que ela ocorre.

No caso de uma falha de rede, que resulte na falta da notificação SQL do AD FS, o AD FS será atualizado no intervalo especificado pelo valor de atualização do cache. Se houver suspeita de problemas de conectividade entre o AD FS e o SQL, é recomendável definir o valor de atualização do cache como inferior a 1 hora.

Instruções de configuração

O arquivo de configuração suporta várias entradas de cache. Os itens a seguir listados abaixo podem ser configurados com base nas necessidades da sua organização.

O exemplo a seguir habilita a atualização do cache em segundo plano e define o período de atualização do cache como 1800 segundos ou 30 minutos. Isso deve ser feito em cada nó do AD FS e, posteriormente, o serviço AD FS deve ser reiniciado. As alterações não afetam outros nós, e deve-se testar o primeiro nó antes de fazer a alteração em todos os nós.

1. Navegue até o arquivo de configuração do AD FS (local padrão C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) e, na seção "Microsoft.IdentityServer.Service", adicione a entrada abaixo:

• backgroundCacheRefreshEnabled - Especifica se o recurso de cache em segundo plano está habilitado. valores "verdadeiros/falsos".
• cacheRefreshIntervalSecs - Valor em segundos no qual o AD FS atualizará o cache. O AD FS atualizará o cache se houver alguma alteração no SQL. O AD FS receberá uma notificação SQL e atualizará o cache.

Valores configuráveis adicionais suportados:

• maxRelyingPartyEntries - Número máximo de entradas de terceira parte confiável que o AD FS manterá na memória. Esse valor também é usado pelo cache de permissão do aplicativo oAuth. Se houver mais permissões de aplicativo do que RPs e se todas forem armazenadas na memória, esse valor deverá ser o número de permissões de aplicativo. O valor padrão é 1000.
• maxIdentityProviderEntries - Este é o número máximo de entradas do provedor de declarações que o AD FS manterá na memória. O valor predefinido é 200.
• maxClientEntries - Este é o número máximo de entradas de cliente OAuth que o AD FS manterá na memória. O valor padrão é 500.
• maxClaimDescriptorEntries - Número máximo de entradas do descritor de reivindicação que o AD FS manterá na memória. O valor padrão é 500.
• maxNullEntries - Este é usado como cache negativo. Quando o AD FS procura uma entrada no banco de dados e ela não é encontrada, o AD FS adiciona um cache negativo. Este é o tamanho máximo desse cache. Há cache negativo para cada tipo de objetos, não é um único cache para todos os objetos. O valor padrão é 50.0000.

Suporte a vários bancos de dados de artefatos em datacenters

Para configurações anteriores de múltiplos data centers, o AD FS apenas suportava um único banco de dados Artifact, causando latência entre centros de dados durante chamadas de recuperação.

Para reduzir a latência entre datacenters, um administrador do AD FS agora pode implantar várias instâncias de banco de dados de artefato e, em seguida, modificar o arquivo de configuração de um nó do AD FS para apontar para diferentes instâncias de banco de dados de artefatos. A cadeia de conexão do banco de dados de artefatos pode ser fornecida no arquivo de configuração, permitindo um banco de dados de artefatos individual por nó. Se a cadeia de conexão não estiver presente no arquivo de configuração, o nó voltará ao design anterior para utilizar a base de dados de artefatos, que se encontra na base de dados de configuração. Ambientes híbridos também são suportados com essa configuração.

Requirements

Antes de configurar o suporte a vários bancos de dados de artefatos, execute uma atualização em todos os nós e atualize os binários, pois chamadas de vários nós ocorrem por meio desse recurso.

1. Gerar script de implantação para criar o banco de dados de artefatos: para implantar várias instâncias de banco de dados de artefatos, um administrador precisará gerar o script de implantação SQL para o banco de dados de artefatos. Como parte desta atualização, o cmdlet Export-AdfsDeploymentSQLScriptexistente foi atualizado para, opcionalmente, incluir um parâmetro especificando para qual banco de dados do AD FS gerar um script de implantação SQL.

Por exemplo, para gerar o script de implantação apenas para o Artifact DB, especifique o parâmetro -DatabaseType e passe o valor "Artifact". O parâmetro -DatabaseType opcional especifica o tipo de banco de dados do AD FS e pode ser definido como: Todos (padrão), Artefato ou Configuração. Se nenhum parâmetro -DatabaseType for especificado, o script configurará os scripts Artifact e Configuration.

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

O script gerado deve ser executado na máquina SQL para criar os bancos de dados necessários e conceder à conta de serviço do AD FS, SQL SA permissões para esses bancos de dados.

1. Crie o banco de dados de artefatos usando o script de implantação. Copie os scripts de implantação de CreateDB.sql e SetPermissions.sql recém-gerados para a máquina do SQL Server e execute-os para criar o banco de dados de artefatos local.

2. Modifique o arquivo de configuração para adicionar a conexão Artifact DB. Navegue até o arquivo de configuração do nó AD FS e, na seção "Microsoft.IdentityServer.Service", adicione um ponto de entrada ao ArtifactDB recém-configurado.

3. Reinicie o serviço AD FS para que as alterações entrem em vigor.

Failover entre centros de dados e recuperação de bases de dados

É recomendável criar bancos de dados de artefatos de tolerância a falhas no mesmo centro de dados que o banco de dados de artefatos mestre. Se ocorrer um failover, não haverá aumento na latência. Não é recomendado usar bancos de dados de artefatos de failover em datacenters diferentes. "A seguir, detalha-se como as chamadas para OAuth, SAML, ESL e a deteção de repetição de tokens funcionam com múltiplas bases de dados de artefactos."

• OAuth e SAML

  Para solicitações de artefato OAuth e SAML, o nó criará o artefato no banco de dados de artefatos presente no arquivo de configuração. Se o arquivo de configuração não contiver uma conexão de banco de dados de artefatos, ele usará o banco de dados de artefatos comum. Quando a próxima solicitação para buscar o artefato for direcionada a outro nó, este realizará uma chamada à API REST para o primeiro nó a fim de buscar o artefato do banco de dados de artefatos. Isso é necessário porque diferentes nós podem ter diferentes bases de dados de artefatos e os nós não têm conhecimento disso. Se o 1º nó estiver inativo, a resolução do artefacto falhará. Devido a esse design, não é necessário replicar o banco de dados de artefatos em diferentes datacenters. Se um datacenter inteiro estiver inativo, muito provavelmente o nó que criou o artefato também está inativo, o que significa que o artefato não pode mais ser resolvido.

• Bloqueio de Extranet

  O banco de dados Artifact, mencionado no ficheiro de configuração, será utilizado para os dados de bloqueio de Extranet. No entanto, para o recurso ESL, o AD FS escolhe um mestre, que grava os dados no banco de dados de artefatos. Todos os nós fazem uma chamada de API REST para o nó principal para obter e atualizar as informações mais recentes sobre cada utilizador. Se vários bancos de dados de artefatos estiverem em uso, o administrador deverá selecionar um nó mestre para cada banco de dados ou datacenter de artefatos.

  Para selecionar um nó para ser o ESL master, navegue até ao ficheiro de configuração do nó AD FS e, na secção "Microsoft.IdentityServer.Service", adicione o seguinte:

  No servidor mestre, adicione a seguinte entrada. Todas as três chaves são sensíveis a maiúsculas e minúsculas.

  <useractivityfarmrole masterFQDN=[FQDN do primário selecionado] isMaster="true"/>

  Nos outros nós, adicione a seguinte entrada:

  <useractivityfarmrole masterFQDN=[FQDN do primário selecionado] isMaster="false"/>

  Note

  Como vários bancos de dados de artefatos não sincronizam dados, os valores ESL não serão sincronizados entre DBs de artefatos. Um usuário pode potencialmente atingir um datacenter diferente para uma solicitação, tornando o ExtranetLockoutThreshold dependente do número de DBs de Artefato, ExtranetLockoutThreshold * Número de DBs de Artefato.

  • Deteção de Replay de Token

    Os dados de deteção de repetição de token são sempre obtidos do banco de dados central do Artifact. O AD FS salva o token da Confiança do Provedor de Declarações, garantindo que o mesmo token não possa ser reproduzido. Se um invasor tentar reproduzir o mesmo token, o AD FS verificará se o token existe no Banco de Dados de Artefatos. Se o token estiver presente, a solicitação será rejeitada. O banco de dados Artifact central é usado para segurança, como os dados do Artifact DB não são replicados, um invasor pode enviar a solicitação para outro datacenter e reproduzir um token. A criação de cópias adicionais somente leitura do ArtifactDB não impedirá a latência entre datacenters nesse cenário, pois apenas o ArtifactDB central é usado.