Ajustar o SQL e resolver problemas de latência com o AD FS
Em uma atualização do AD FS 2016, apresentamos os seguintes aprimoramentos para reduzir a latência entre bancos de dados. Uma atualização futura do AD FS 2019 incluirá essas melhorias.
Atualização do cache na memória no thread em segundo plano
Em implantações anteriores do AoA (disponibilidade sempre ativada), existia latência para qualquer operação de "Leitura", pois o nó mestre poderia estar localizado em um datacenter 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 atualização. O tempo gasto para uma pesquisa de banco de dados é significativamente reduzido no thread de solicitação, pois as atualizações de cache de banco de dados são movidas para o thread em segundo plano.
Quando o backgroundCacheRefreshEnabled for 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 personalizada para um valor 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. Embora exista 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á removida do cache. A entrada mais antiga também pode ser removida do cache depois que o valor maxRelyingPartyEntries configurável for atingido.
Observação
Os dados do cache serão atualizados fora do valor cacheRefreshIntervalSecs se o AD FS receber uma notificação do SQL indicando que ocorreu uma alteração no banco de dados. Essa notificação disparará o cache a ser atualizado.
Recomendações para definir a atualização de cache
O valor padrão para a atualização do cache é de cinco minutos. É recomendável defini-lo como 1 hora para reduzir uma atualização de dados desnecessária pelo AD FS porque os dados de cache serão atualizados se ocorrerem alterações no SQL.
O AD FS registra um retorno de chamada 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 ocorre.
No caso de uma falha de rede, que resulta em AD FS sem a notificação do SQL, 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 dá suporte a várias entradas de cache. Os seguintes listados abaixo podem ser configurados com base nas necessidades da sua organização.
O exemplo a seguir habilita a atualização de 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 o serviço do AD FS deve ser reiniciado posteriormente. As alterações não afetam outros nós e testam o primeiro nó antes de fazer a alteração em todos os nós.
- 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 "true/false".cacheRefreshIntervalSecs– valor em segundos em que 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 do SQL e atualizará o cache.
Observação
Todas as entradas no arquivo de configuração diferenciam maiúsculas de minúsculas. <cache cacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />
Valores configuráveis adicionais com suporte:
- 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ões 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 – esse é o número máximo de entradas do provedor de declarações que o AD FS manterá na memória. O valor padrão é 200.
- maxClientEntries – esse é o número máximo de entradas de cliente OAuth que o AD FS manterá na memória. O valor padrão é 500.
- maxClaimDescriptorEntries – o número máximo de entradas do descritor de declaração que o AD FS manterá na memória. O valor padrão é 500.
- maxNullEntries – isso é usado como cache negativo. Quando o AD FS procura uma entrada no banco de dados e não é encontrada, o AD FS adiciona em cache negativo. Esse é o tamanho máximo desse cache. Há um cache negativo para cada tipo de objeto, não é um único cache para todos os objetos. O valor padrão é 50,0000.
Suporte a vários bancos de dados de artefatos entre datacenters
Para configurações anteriores de vários datacenters, o AD FS só tem suporte para um único banco de dados de artefato, causando latência de datacenter entre centros durante chamadas de recuperação.
Para reduzir a latência entre os datacenters, um administrador do AD FS agora pode implantar várias instâncias de banco de dados de artefato e modificar o arquivo de configuração de um nó do AD FS para apontar para instâncias de banco de dados de artefato diferentes. A cadeia de conexão do banco de dados de artefato pode ser fornecida no arquivo de configuração, permitindo um BD de artefato por nó. Se a cadeia de conexão não estiver presente no arquivo de configuração, o nó retornará ao design anterior para usar o banco de dados de artefato, que está presente no BD de configuração. Também há suporte para ambientes híbridos com essa configuração.
Requisitos
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 as chamadas de vários nós ocorrem por meio desse recurso.
- Gerar script de implantação para criar o BD de Artefato: para implantar várias instâncias de banco de dados de artefato, um administrador precisará gerar o script de implantação do SQL para o BD de Artefato. Como parte dessa atualização, o cmdlet
Export-AdfsDeploymentSQLScriptexistente foi atualizado para usar opcionalmente um parâmetro que especifica para qual banco de dados do AD FS gerar um script de implantação do SQL.
Por exemplo, para gerar o script de implantação apenas para o Banco de Dados do Artefato, especifique o parâmetro -DatabaseType e passe o valor "Artifact". O parâmetro opcional -DatabaseType 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 de Artefato e Configuração.
PS C:\> Export-AdfsDeploymentSQLScript -DestinationFolder <script folder where scripts will be created> -ServiceAccountName <domain\serviceaccount> -DatabaseType "Artifact"
O script gerado deve ser executado no computador do SQL para criar os bancos de dados necessários e conceder à conta de serviço do AD FS, permissões de SA do SQL para esses bancos de dados.
Crie o Banco de Dados de Artefato usando o script de implantação. Copie os scripts de implantação CreateDB.sql e SetPermissions.sql recém-gerados para o computador do SQL Server e execute-os para criar o BD de Artefato local.
Modifique o arquivo de configuração para adicionar a conexão do Banco de Dados de Artefato. Navegue até o arquivo de configuração do nó do AD FS e, na seção "Microsoft.IdentityServer.Service", adicione um ponto de entrada ao ArtifactDB recém-configurado.
Observação
artifactStore e connectionString diferenciam maiúsculas de minúsculas. Verifique se eles estão configurados corretamente. <artifactStore connectionString="Data Source=.\SQLInstance;Integrated Security=True;Initial Catalog=AdfsArtifactStore" />
Use um valor de Fonte de Dados que corresponda à sua conexão de SQL.
- Reinicie o serviço do AD FS para que as alterações entrem em vigor.
Observação
Não é recomendável usar a replicação ou a sincronização do SQL entre os bancos de dados de artefato. A recomendação é configurar um banco de dados de artefato por datacenter.
Failover entre datacenter e recuperação de banco de dados
É recomendável criar bancos de dados de artefato de failover no mesmo datacenter que o banco de dados de artefato mestre. Se ocorrer um failover, não haverá aumento na latência. Os bancos de dados do Artefato de Failover entre os datacenters não são recomendados. A seguir, detalhamos como as chamadas para o OAuth, SAML, ESL e a detecção de reprodução de token funcionam com vários bancos de dados de artefatos.
OAuth e SAML
Para solicitações de artefato do OAuth e SAML, o nó criará o artefato no BD de artefato presente no arquivo de configuração. Se o arquivo de configuração não contiver uma conexão de banco de dados de artefato, ele usará o banco de dados de artefato comum. Quando a próxima solicitação para buscar o artefato for para outro nó, o outro nó fará a API REST para o primeiro nó para buscar o artefato do banco de dados de artefato. Isso é necessário, pois nós diferentes podem ter bancos de dados de artefato diferentes e os nós não sabem disso. Se o primeiro nó estiver inativo, a resolução do artefato falhará. Devido a esse design, a replicação do BD de artefato em diferentes os datacenters não é necessária. Se um datacenter inteiro estiver inativo, provavelmente o nó, que criou o artefato também está inativo, significa que o artefato não pode mais ser resolvido.
Bloqueio de Extranet
O banco de dados de Artefato referenciado no arquivo de configuração será usado para dados de Bloqueio de Extranet. No entanto, para o recurso de ESL, o AD FS escolhe um mestre, que grava os dados no banco de dados de artefato. Todos os nós fazem uma chamada à API REST para o nó mestre para obter e definir as informações mais recentes sobre cada usuário. 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 artefato.
Para selecionar um nó para ser o mestre do ESL, navegue até o arquivo de configuração do nó do AD FS e, na seção "Microsoft.IdentityServer.Service", adicione o seguinte:
No mestre, adicione a seguinte entrada. Todas as três chaves diferenciam maiúsculas de 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"/>
Observação
Como vários bancos de dados de artefatos não sincronizam dados, os valores de ESL não serão sincronizados entre os bancos de dados de artefato. 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.
Detecção de reprodução de token
Os dados de detecção de reprodução de token são sempre chamados do banco de dados de Artefato central. O AD FS salva o token do Provedor de Declarações de Confiança, 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 do Artefato. Se o token estiver presente, a solicitação será rejeitada. O banco de dados de Artefato central é usado para segurança, já que os dados do DB de Artefato 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 somente leitura adicionais do ArtifactDB não impedirá a latência entre datacenters nesse cenário, pois apenas o banco de dados de Artefato central é usado.