Perguntas frequentes sobre o AD FS

Você pode fazer isso seguindo as etapas descritas em um destes artigos:

• AD FS do Windows Server 2012 R2 para AD FS do Windows Server 2016 ou posterior. (O processo é o mesmo se você está atualizando do AD FS do Windows Server 2016 para o AD FS do Windows Server 2019.)
  • Atualizando para o AD FS no Windows Server 2016 usando um banco de dados WID
  • Atualizando para o AD FS no Windows Server 2016 usando um banco de dados SQL
• AD FS do Windows Server 2012 para AD FS do Windows Server 2012 R2:
  • Migração para o AD FS no Windows Server 2012 R2
• AD FS 2.0 para AD FS do Windows Server 2012:
  • Migração para o AD FS no Windows Server 2012
• AD FS 1.x para AD FS 2.0:
  • Atualizar do AD FS 1.x para o AD FS 2.0

Se precisar atualizar do AD FS 2.0 ou 2.1 (Windows Server 2008 R2 ou Windows Server 2012), use os scripts nativos localizados em C:\Windows\ADFS.

O suporte ao HTTP/2 foi adicionado no Windows Server 2016, mas o HTTP/2 não pode ser usado para autenticação de certificado de cliente. Muitos cenários do AD FS usam autenticação com certificado do cliente. E muitos clientes não dão suporte à repetição de solicitações usando HTTP/1.1. Portanto, a configuração em farm do AD FS redefine as configurações de HTTP do servidor local para HTTP/1.1. Essa reconfiguração exige que o servidor seja reiniciado.

Embora haja suporte para essa configuração, não haveria suporte para novos recursos do AD FS 2016 com ela. O ideal é que essa configuração seja usada temporariamente durante a migração do AD FS 2012 R2 para o AD FS 2016. Ela não deve ser usada por períodos prolongados.

Sim, mas como efeito colateral:

• Você precisará gerenciar manualmente as atualizações dos certificados de autenticação de tokens, pois o Azure AD não poderá acessar os metadados de federação. Para saber como atualizar manualmente certificados de autenticação de tokens, confira Renovar certificados de federação para o Office 365 e o Azure Active Directory.
• Você não poderá usar fluxos de autenticação herdados (por exemplo, o fluxo de autenticação de proxy ExO).

O AD FS é um sistema sem monitoração de estado, de modo que o balanceamento de carga é bastante simples para iniciar sessão. Estas são algumas recomendações importantes para sistemas de balanceamento de carga:

• Os balanceadores de carga não devem ser configurados com afinidade de IP. A afinidade de IP pode causar uma carga indevida sobre um subconjunto dos servidores em alguns cenários do Exchange Online.
• Os balanceadores de carga não podem encerrar as conexões HTTPS nem iniciar uma nova conexão com o servidor do AD FS.
• Os balanceadores de carga devem garantir que o endereço IP da conexão seja convertido no IP de origem no pacote HTTP ao ser enviado ao AD FS. Se um balanceador de carga não puder enviar o IP de origem no pacote HTTP, ele deverá adicionar o endereço IP ao cabeçalho X-Forwarded-For. Essa etapa é necessária para o tratamento correto de determinados recursos relacionados ao IP (por exemplo, IP proibido e bloqueio inteligente de extranet). Se essa configuração não for implementada corretamente, a segurança poderá ser reduzida.
• Os balanceadores de carga devem dar suporte a SNI. Se não for esse o caso, verifique se o AD FS está configurado para criar associações HTTPS para lidar com clientes sem suporte para SNI.
• Os balanceadores de carga devem usar o ponto de extremidade de investigação de integridade HTTP do AD FS para detectar se os servidores do Proxy de aplicativo Web ou do AD FS estão em execução. Ele deverá excluí-los se 200 OK não for retornado.

O AD FS dá suporte a diversas configurações de várias florestas. Eles se baseiam na rede de confiança subjacente do AD DS para autenticar os usuários em vários realms confiáveis. É altamente recomendável usar relações de confiança de floresta bidirecionais porque elas são mais fáceis de configurar, o que ajuda a garantir que o sistema de confiança funcione corretamente.

Além disso:

• Se você tem uma relação de confiança de floresta unidirecional, como uma floresta de rede de perímetro (também conhecida como DMZ) que contém identidades de parceiros, recomendamos implantar o AD FS na floresta corporativa. Trate a floresta da rede de perímetro como outra relação de confiança do provedor de declarações local conectado via LDAP. Nesse caso, a Autenticação Integrada do Windows não funcionará para os usuários da floresta da rede de perímetro. Eles precisarão usar a autenticação de senha, que é o único mecanismo com suporte para LDAP.

  Se não puder usar essa opção, você precisará configurar outro servidor do AD FS na floresta da rede de perímetro. Adicione-o como uma relação de confiança do provedor de declarações no servidor do AD FS na floresta corporativa. Os usuários precisarão realizar a Descoberta de Realm Inicial, mas a Autenticação Integrada do Windows e a autenticação de senha funcionarão. Faça as alterações apropriadas nas regras de emissão no AD FS na floresta da rede de perímetro, pois o AD FS na floresta corporativa não poderá obter mais informações sobre os usuários da floresta da rede de perímetro.

• Relações de confiança no nível do domínio têm suporte e podem funcionar. No entanto, é altamente recomendável que você adote um modelo de confiança no nível da floresta. Você também precisaria garantir o funcionamento correto do roteamento de UPN e da resolução de nomes NetBIOS.

Sim, endereços IPv6 são considerados para locais familiares e desconhecidos.

O AD FS fornece um mecanismo extensível para provedores de autenticação multifator de terceiros a serem integrados. Não há nenhum programa de certificação definido para isso. Presume-se que o fornecedor tenha realizado as validações necessárias antes do lançamento.

A lista de fornecedores que notificaram a Microsoft está disponível aqui: Provedores de autenticação multifator para o AD FS. Pode haver provedores disponíveis dos quais não temos conhecimento. Atualizaremos a lista à medida que descobrirmos novos provedores.

Sim, os proxies de terceiros podem ser colocados na frente dos AD FS, mas qualquer proxy de terceiros precisa ser compatível com o protocolo MS-ADFSPIP a ser usado no lugar do Proxy de Aplicativo Web.

No momento, temos conhecimento dos provedores de terceiros a seguir. Pode haver provedores disponíveis dos quais não temos conhecimento. Atualizaremos essa lista à medida que descobrirmos novos provedores.

• F5 Access Policy Manager
• ADC (Application Delivery Controller) Citrix

Você pode baixar a versão da planilha do AD FS 2016. Você também pode usar essa planilha para o AD FS no Windows Server 2012 R2.

A Apple lançou um conjunto de requisitos chamados ATS (App Transport Security) que podem afetar chamadas de aplicativos iOS que se autenticam no AD FS. Você pode garantir que seus servidores do Proxy de aplicativo Web e do AD FS estejam em conformidade verificando se eles dão suporte aos requisitos de conexão com o ATS. Especificamente, verifique se:

• Seus servidores do Proxy de aplicativo Web e do AD FS dão suporte a TLS 1.2.
• O pacote de criptografia negociado da conexão TLS dará suporte a PFS.

Para saber como habilitar e desabilitar o SSL 2.0 e 3.0 e o TLS 1.0, 1.1 e 1.2, confira Gerenciar protocolos TLS no AD FS.

Para garantir que os servidores do Proxy de aplicativo Web e do AD FS negociem somente conjuntos de criptografia TLS com suporte para ATP, desabilite todos os conjuntos de criptografia que não estão na lista de conjuntos de criptografia em conformidade com ATP. Para desabilitá-los, use os cmdlets do PowerShell do TLS no Windows.

O valor da "subdeclaração" é o hash da ID do cliente e o valor da declaração de âncora.

O tempo de vida do token de atualização será o mesmo do token que o AD FS obtiveram da relação de confiança do provedor de declarações remoto. O tempo de vida do token de acesso será o mesmo do token da terceira parte confiável para a qual o token de acesso está sendo emitido.

Use um id_token personalizado para adicionar informações relevantes no próprio id_token. Para saber mais, confira Personalizar declarações a serem emitidas no id_token.

Um ValueType especial (http://www.w3.org/2001/XMLSchema#json) e um caractere de escape (\x22) foram adicionados no AD FS 2016 para esse cenário. Use as amostras abaixo para a regra de emissão e para a saída final do token de acesso.

Regra de emissão da amostra:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

Declaração emitida no token de acesso:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Com o AD FS no Windows Server 2019, você pode passar o valor do recurso inserido no parâmetro de escopo. Agora, o parâmetro de escopo pode ser organizado como uma lista separada por espaços em que cada entrada é estruturada como recurso/escopo.

O AD FS no Windows Server 2019 dá suporte à PKCE (Chave de Prova para Troca de Código) para o fluxo de concessão de código de autorização OAuth.

Com suporte:

• aza. Se você está usando Extensões do protocolo OAuth 2.0 para clientes de agente e o parâmetro de escopo contém o escopo aza, o servidor emite um novo token de atualização primário e o define no campo refresh_token da resposta. Ele também define o campo refresh_token_expires_in como o tempo de vida do novo token de atualização primário quando um é imposto.
• openid. Permite que o aplicativo solicite o uso do protocolo de autorização OpenID Connect.
• logon_cert. Permite que um aplicativo solicite certificados de logon, que podem ser usados para que os usuários autenticados entrem de maneira interativa. O servidor do AD FS omite o parâmetro access_token da resposta e, em vez disso, fornece uma cadeia de certificados CMS codificada em Base64 ou uma resposta de PKI completa de CMC. Para saber mais, confira Detalhes de processamento.
• user_impersonation. Necessário se você quer solicitar um token de acesso on-behalf-of do AD FS. Para saber mais sobre como usar esse escopo, confira Criar um aplicativo de várias camadas usando OBO (On-Behalf-Of) no OAuth com o AD FS 2016.

Não compatível:

• vpn_cert. Permite que um aplicativo solicite certificados VPN, que podem ser usados para estabelecer conexões VPN usando a autenticação EAP-TLS. Esse escopo deixou de ter suporte.
• email. Permite que um aplicativo solicite uma declaração de email para o usuário conectado. Esse escopo deixou de ter suporte.
• profile. Permite que um aplicativo solicite declarações relacionadas ao perfil para o usuário conectado. Esse escopo deixou de ter suporte.

O certificado SSL do AD FS não é o mesmo que o Certificado de Comunicações de Serviço do AD FS encontrado no snap-in Gerenciamento do AD FS. Para alterar o certificado SSL do AD FS, você precisa usar o PowerShell. Siga as orientações em Gerenciando certificados SSL no AD FS e no WAP 2016.

Para saber como habilitar e desabilitar protocolos SSL e pacotes de criptografia, confira Gerenciar protocolos SSL no AD FS.

• Se a finalidade do proxy for usar um proxy de solicitações do AD FS que usam a Autenticação Integrada do Windows, o certificado SSL do proxy precisará usar a mesma chave que o certificado SSL do servidor de federação.
• Se a propriedade ExtendedProtectionTokenCheck do AD FS estiver habilitada (a configuração padrão no AD FS), o certificado SSL do proxy precisará usar a mesma chave que o certificado SSL do servidor de federação.
• Caso contrário, o certificado SSL do proxy poderá ter uma chave diferente daquela do certificado SSL do AD FS. Ela precisará atender aos mesmos requisitos.

O AD FS mostra somente um método de autenticação na tela de credencial quando um aplicativo exige explicitamente um URI de autenticação específico que é mapeado para um método de autenticação configurado e habilitado. O método é transmitido no parâmetro wauth em solicitações de Web Services Federation. Ele é transmitido no parâmetro RequestedAuthnCtxRef em solicitações do protocolo SAML. Somente o método de autenticação solicitado é exibido. (Por exemplo, credenciais com senha.)

Quando você usa o AD FS com o Azure AD, é comum que os aplicativos enviem o parâmetro prompt=login ao Azure AD. Por padrão, o Azure AD converte esse parâmetro para solicitar uma nova conexão baseada em senha ao AD FS. Esse cenário é o motivo mais comum para você ver uma credencial com senha no AD FS em sua rede ou não ver uma opção para entrar com o certificado. Você pode resolver esse problema com facilidade fazendo uma alteração nas configurações de domínio federado no Azure AD.

Para saber mais, confira Suporte ao parâmetro prompt=login do AD FS (Serviços de Federação do Active Directory).

Para alterar a conta de serviço do AD FS, use o módulo do PowerShell da Conta de Serviço da Caixa de Ferramentas do AD FS. Para obter instruções, confira Alterar conta de serviço do AD FS.

Confira Configurar navegadores para usar a WIA (Autenticação Integrada do Windows) com o AD FS.

Caso não tenha políticas de controle de acesso baseadas no dispositivo no AD FS nem o registro de certificado do Windows Hello para Empresas por meio do AD FS, desligue BrowserSsoEnabled. BrowserSsoEnabled permite que o AD FS colete um PRT (Token de Atualização Primário) do cliente que contém informações sobre o dispositivo. Sem esse token, a autenticação de dispositivo do AD FS não funcionará em dispositivos do Windows 10.

Muitas vezes, os administradores se perguntam por quanto tempo os usuários obtêm SSO (logon único) sem precisar inserir novas credenciais e como os administradores podem controlar esse comportamento. Esse comportamento e as definições de configuração que o controlam são descritos em configurações de logon único do AD FS.

Os tempos de vida padrão dos diversos cookies e tokens estão listados aqui (bem como os parâmetros que regem os tempos de vida):

Dispositivos registrados

• Cookies de PRT e SSO: máximo de 90 dias, regido por PSSOLifeTimeMins. (Se o dispositivo fornecido for usado pelo menos a cada 14 dias. Essa janela de tempo é controlada pelo DeviceUsageWindow.)

• Token de atualização: calculado com base nos parâmetros anteriores para fornecer um comportamento consistente.

• access_token: uma hora por padrão, com base na terceira parte confiável.

• id_token: igual a access_token.

Dispositivos não registrados

• Cookies de SSO: oito horas por padrão, regidas por SSOLifetimeMins. Quando KMSI (Manter-me conectado) está habilitado, o padrão é de 24 horas. Esse padrão é configurável por meio de KMSILifetimeMins.

• Token de atualização: oito horas por padrão. 24 horas se o KMSI estiver habilitado.

• access_token: uma hora por padrão, com base na terceira parte confiável.

• id_token: igual a access_token.

O AD FS não dá suporte a fluxos implícitos para clientes confidenciais. A autenticação do cliente é habilitada somente para o ponto de extremidade do token, e o AD FS não emitirá um token de acesso sem uma autenticação de cliente. Se o cliente confidencial precisar de um token de acesso e também exigir autenticação de usuário, ele precisará usar o fluxo de código de autorização.

O HSTS é um mecanismo de políticas de segurança da Web. Ele ajuda a atenuar ataques de downgrade de protocolo e sequestro de cookie em serviços que têm pontos de extremidade HTTP e HTTPS. Ele permite que os servidores Web declarem que os navegadores da Web (ou outros agentes do usuário em conformidade) só devem interagir com ele usando HTTPS, e nunca o protocolo HTTP.

Todos os pontos de extremidade do AD FS para o tráfego de autenticação na Web são abertos exclusivamente via HTTPS. Portanto, AD FS atenua as ameaças que o mecanismo de política HSTS cria. (Por design, não há downgrade para o HTTP porque não há ouvintes no HTTP.) O AD FS também impede que cookies sejam enviados para outro servidor que tem pontos de extremidade de protocolo HTTP marcando todos os cookies com o sinalizador de segurança.

Assim, você não precisa do HSTS em um servidor do AD FS, porque o HSTS não pode sofrer downgrade. Os servidores do AD FS atendem aos requisitos de conformidade porque eles não podem usar HTTP e porque os cookies são marcados como seguros.

Por fim, o AD FS 2016 (com os patches mais atualizados) e o AD FS 2019 dão suporte à emissão do cabeçalho HSTS. Para configurar esse comportamento, confira Personalizar cabeçalhos de resposta de segurança HTTP com o AD FS.

Não recomendamos que você faça a terminação SSL antes do servidor Proxy de aplicativo Web. Se isso for feito na frente do servidor Proxy de aplicativo Web, X-MS-Forwarded-Client-IP conterá o IP do dispositivo de rede na frente do servidor do Proxy de aplicativo Web. Veja uma breve descrição das várias declarações relacionadas a IP compatíveis com o AD FS:

• X-MS-Client-IP. IP de rede do dispositivo conectado ao STS. Para solicitações de extranet, essa declaração sempre contém o IP do servidor Proxy de aplicativo Web.
• X-MS-Forwarded-Client-IP. Declaração com vários valores que contém os valores encaminhados para o AD FS pelo Exchange Online. Também contém o endereço IP do dispositivo conectado ao servidor Proxy de aplicativo Web.
• Userip. Para solicitações da extranet, essa declaração contém o valor de X-MS-Forwarded-Client-IP. Para solicitações da intranet, essa declaração contém o mesmo valor que X-MS-Client-IP.

O AD FS 2016 (com os patches mais atualizados) e versões posteriores também dão suporte à captura do cabeçalho X-Forwarded-For. Qualquer balanceador de carga ou dispositivo de rede que não fizer o encaminhamento na camada 3 (o IP é preservado) deverá adicionar o IP do cliente de entrada ao cabeçalho X-Forwarded-For padrão do setor.

O ponto de extremidade UserInfo do AD FS sempre retorna a declaração da entidade, conforme especificado nos padrões do OpenID. O AD FS não dá suporte a declarações adicionais solicitadas por meio do ponto de extremidade UserInfo. Se precisar de mais declarações em um token de ID, confira Tokens de ID personalizada no AD FS.

Esse grupo é criado somente quando um controlador de domínio do Windows Server 2016 com a função de controlador de domínio primário do FSMO existe no domínio. Para resolver o erro, crie o grupo manualmente. Siga estas etapas para adicionar as permissões necessárias após adicionar a conta de serviço como membro do grupo:

1. Abra Usuários e Computadores do Active Directory.
2. Clique com o botão direito do mouse no nome de domínio no painel esquerdo e selecione Propriedades.
3. Selecione Segurança. (Se a guia Segurança estiver ausente, ative Recursos Avançados no menu Exibir.)
4. Selecione Avançado, Adicionar e Selecionar uma entidade de segurança.
5. A caixa de diálogo Selecionar Usuário, Computador, Conta de Serviço ou Grupo é exibida. Na caixa Insira o nome do objeto a ser selecionado, digite Grupo de Administradores de Chaves. Selecione OK.
6. Na caixa Aplicável a, selecione Objetos de Usuário descendente.
7. Vá até a parte inferior da página e selecione Limpar tudo.
8. Na seção Propriedades, selecione Ler msDS-KeyCredentialLink e Gravar msDS-KeyCrendentialLink.

Para aplicativos que usam a biblioteca ADAL do Android, a autenticação no Azure AD pode falhar para usuários federados. O aplicativo receberá uma AuthenticationException quando tentar mostrar a página de entrada. No navegador Chrome, a página de entrada do AD FS poderá ser descrita como não segura.

Para todas as versões e todos os dispositivos, o Android não dá suporte ao download de certificados adicionais por meio do campo authorityInformationAccess do certificado. Essa limitação também se aplica ao navegador Chrome. Qualquer certificado de autenticação de servidor que não contiver certificados intermediários causará esse erro se a cadeia de certificados inteira não for transmitida pelo AD FS.

Resolva esse problema configurando os servidores do AD FS e do Proxy de aplicativo Web para enviar os certificados intermediários necessários juntamente com o certificado SSL.

Ao exportar o certificado SSL de um computador para ser importado para o repositório pessoal do computador dos servidores do AD FS e do Proxy de aplicativo Web, lembre-se de exportar a chave privada e selecionar Troca de Informações Pessoais – PKCS nº 12.

Além disso, selecione Incluir todos os certificados no caminho do certificado, se possível, e Exportar todas as propriedades estendidas.

Execute certlm.msc nos servidores Windows e importe o *.pfx no repositório de certificados pessoal do computador. Isso fará com que o servidor transmita toda a cadeia de certificados para a biblioteca ADAL.

O AD FS não dá suporte a solicitações HEAD. Os aplicativos não devem usar solicitações HEAD em pontos de extremidade do AD FS. O uso dessas solicitações pode causar respostas de erro HTTP inesperadas ou atrasadas. Você também poderá receber eventos de erro inesperados no log de eventos do AD FS.

Um token de atualização não será emitido se o token emitido pelo IdP tiver uma validade inferior a uma hora. Para garantir que um token de atualização seja emitido, aumente a validade do token emitido pelo IdP para mais de uma hora.

A criptografia do token RP é definida como AES256. Não é possível alterá-la para nenhum outro valor.

Os farms de modo misto do AD FS devem ser temporários. Recomendamos que, durante o planejamento, você substitua o certificado SSL antes do processo de atualização ou conclua o processo e aumente o nível de comportamento do farm antes de atualizar o certificado SSL. Caso não tenha seguido essa recomendação, use as instruções a seguir para atualizar o certificado SSL.

Em servidores do Proxy de aplicativo Web, você ainda pode usar Set-WebApplicationProxySslCertificate. É preciso usar comandos netsh nos servidores AD FS. Conclua estas etapas:

1. Selecione um subconjunto de servidores do AD FS 2016 para manutenção.

2. Nos servidores selecionados na etapa anterior, importe o novo certificado via MMC.

3. Exclua os certificados existentes:

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. Adicionar os novos certificados:

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. Reinicie o serviço do AD FS no servidor selecionado.

6. Remova um subconjunto dos servidores do Proxy de aplicativo Web para manutenção.

7. Nos servidores do Proxy de aplicativo Web selecionados, importe o novo certificado via MMC.

8. Defina o novo certificado no servidor Proxy de aplicativo Web usando este cmdlet:

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Reinicie o serviço nos servidores do Proxy de aplicativo Web selecionados.

10. Coloque os servidores selecionados do Proxy de aplicativo Web e do AD FS de volta no ambiente de produção.

Atualize o restante dos servidores do Proxy de aplicativo Web e do AD FS da mesma maneira.

Os servidores do AD FS e do aplicativo Web dão suporte a todos os firewalls que não executam a terminação SSL no ponto de extremidade. Além disso, os servidores do AD FS/Proxy de aplicativo Web têm mecanismos integrados para:

• Ajudar a evitar ataques comuns da Web, como cross-site scripting.
• Executar o proxy do AD FS.
• Atender a todos os requisitos definidos pelo protocolo MS-ADFSPIP.

No AD FS 2016, a associação de token é habilitada automaticamente e causa vários problemas conhecidos em cenários de proxy e federação. Esses problemas causam esse evento. Para resolvê-lo, execute o seguinte comando do PowerShell para remover o suporte para a associação de token:

Set-AdfsProperties -IgnoreTokenBinding $true

Após uma atualização para o Windows Server 2019, a versão de configuração do Proxy de aplicativo Web continuará sendo exibida como Windows Server 2016. O Proxy de aplicativo Web não tem novos recursos específicos da versão para o Windows Server 2019. Se o nível de comportamento do farm tiver sido elevado no AD FS, o Proxy de aplicativo Web continuará sendo exibido como Windows Server 2016. Este comportamento ocorre por design.

Quando o ESL é habilitado, o AD FS acompanha a atividade da conta e as localizações conhecidas dos usuários no banco de dados ADFSArtifactStore. Esse banco de dados é dimensionado em relação ao número de usuários e de localizações conhecidas acompanhados. Ao planejar a habilitação do ESL, você pode estimar que o banco de dados ADFSArtifactStore aumentará a uma taxa de até 1 GB a cada 100.000 usuários.

Se o farm do AD FS estiver usando o Banco de Dados Interno do Windows, a localização padrão dos arquivos de banco de dados será C:\Windows\WID\Data. Para evitar o preenchimento dessa unidade, tenha pelo menos 5 GB de armazenamento livre antes de habilitar o ESL. Além do armazenamento em disco, planeje um aumento da memória total do processo após você habilitar o ESL, em até um 1 GB de RAM adicional para populações de usuários de 500.000 ou menos.

Este é o texto do evento:

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

Esse evento ocorre quando as florestas não são confiáveis enquanto o AD FS tenta enumerar todas as florestas em uma cadeia de florestas confiáveis e se conectar em todas elas. Por exemplo, suponha que Floresta A e a Floresta B do AD FS sejam confiáveis e que a Floresta B e a Floresta C também sejam. O AD FS vai enumerar as três florestas e tentará encontrar uma relação de confiança entre as Florestas A e C. Se os usuários da floresta com falha precisarem ser autenticados pelo AD FS, configure uma relação de confiança entre a floresta do AD FS e a floresta com falha. Se os usuários da floresta com falha não precisarem ser autenticados pelo AD FS, ignore esse evento.

Este é o texto do evento:

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

No AD FS 2016, a associação de token é habilitada automaticamente e causa vários problemas conhecidos em cenários de proxy e federação. Esses problemas causam esse evento. Para resolvê-lo, execute o seguinte comando do PowerShell para remover o suporte para a associação de token:

Set-AdfsProperties -IgnoreTokenBinding $true

Este é o texto do evento:

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

Esse evento é esperado quando estas duas afirmações são verdadeiras:

• Você tem um farm de modo misto.
• O AD FS 2019 fornece as informações de nível máximo de comportamento do farm para o servidor de federação primário e não é reconhecido pelo servidor de federação versão 2016.

O AD FS 2019 continua tentando compartilhar no farm o valor de MaxBehaviorLevel Win2019 até que ele se torne obsoleto após dois meses e seja removido automaticamente do farm. Para evitar o recebimento desse evento, migre a função de federação primária para o servidor de federação com a versão mais recente. Siga as instruções em Para atualizar seu farm do AD FS para o nível de comportamento do farm do Windows Server 2019.