Compartilhar via


Visão geral do bloqueio da Extranet do AD FS e do Bloqueio Inteligente da Extranet

O ESL (Bloqueio Inteligente da Extranet) protege seus usuários contra o bloqueio de contas da extranet por atividades maliciosas.

O ESL permite que o AD FS diferencie entre tentativas de entrada de um local familiar para um usuário e tentativas de entrada do que pode ser um invasor. O AD FS pode bloquear invasores, permitindo que usuários válidos continuem a usar suas contas. Essa distinção impede e protege contra ataques de negação de serviço e determinadas classes de ataques de pulverização de senha ao usuário. O ESL está disponível para o AD FS no Windows Server 2016 e é integrado ao AD FS no Windows Server 2019.

O ESL só está disponível para as solicitações de autenticação de nome de usuário e senha que vêm por meio da extranet com o Proxy de Aplicativo Web ou um proxy de terceiros. Qualquer proxy de terceiros deve dar suporte ao protocolo MS-ADFSPIP a ser usado no lugar do Proxy de Aplicativo Web, como o Gerenciador de Políticas de Acesso F5 BIG-IP. Consulte a documentação de proxy de terceiros para determinar se o proxy dá suporte ao protocolo MS-ADFSPIP.

Recursos no AD FS 2019

O Bloqueio Inteligente da Extranet no AD FS 2019 adiciona as seguintes vantagens em comparação com o AD FS 2016:

  • Limites de bloqueio independentes para locais familiares e desconhecidos. Usuários em locais válidos podem ter mais espaço para erro que solicitações de locais suspeitos.
  • Modo de auditoria para bloqueio inteligente enquanto continua a impor o comportamento de bloqueio reversível anterior. Essa distinção permite que você aprenda sobre locais familiares do usuário e ainda seja protegido pelo recurso de bloqueio de extranet que está disponível no AD FS 2012 R2.

Informações da configuração

Quando a ESL está habilitada, uma tabela no banco de dados Artifact, AdfsArtifactStore.AccountActivity, é criada. Um nó também é selecionado no farm do AD FS como o nó primário "Atividade do Usuário". Em uma configuração de WID (Banco de Dados Interno do Windows), esse nó é sempre o nó primário. Em uma configuração SQL, um nó é selecionado para ser o nó primário da Atividade do Usuário.

Para exibir o nó selecionado como o nó primário "Atividade do Usuário", use (Get-AdfsFarmInformation).FarmRoles.

Todos os nós secundários entrarão em contato com o nó primário em cada nova entrada por meio da Porta 80 para saber o valor mais recente das contagens de senhas incorretas e novos valores de localização familiar. Os nós secundários também atualizam o nó primário depois que a entrada é processada.

Diagram showing the sign-in process between primary nodes, secondary nodes, and the client.

Se o nó secundário não puder contatar o nó primário, o nó secundário gravará eventos de erro no log de administrador do AD FS. As autenticações continuam sendo processadas, mas o AD FS gravará apenas o estado atualizado localmente. O AD FS tenta entrar em contato com o nó primário a cada 10 minutos. O AD FS volta para o nó primário depois que o nó primário está disponível.

Terminologia

  • FamiliarLocation: durante uma solicitação de autenticação, o ESL verifica todos os IPs (protocolos de Internet) apresentados. Esses IPs serão uma combinação de IP de rede, IP encaminhado e o IP opcional x-forwarded-for. Se a solicitação for bem-sucedida, todos os IPs serão adicionados à tabela Atividade da Conta como "IPs familiares". Se a solicitação tiver todos os IPs presentes nos "IPs familiares", a solicitação será tratada como um local "familiar".
  • UnknownLocation: se uma solicitação recebida tiver pelo menos um IP não presente na lista FamiliarLocation existente, a solicitação será tratada como um local "Desconhecido". Essa ação lida com cenários de proxy, como a autenticação herdada do Exchange Online, em que os endereços Exchange Online lidam com solicitações com êxito e com falha.
  • badPwdCount: um valor que representa o número de vezes que uma senha incorreta foi enviada e a autenticação não teve êxito. Para cada usuário, contadores separados são mantidos para locais familiares e locais desconhecidos.
  • UnknownLockout: um valor booliano por usuário, se o usuário estiver impedido de acessar de locais desconhecidos. Esse valor é calculado com base nos valores badPwdCountUnfamiliar e ExtranetLockoutThreshold.
  • ExtranetLockoutThreshold: esse valor determina o número máximo de tentativas de senha incorretas. Quando o limite é atingido, o AD FS rejeita as solicitações da extranet até que a janela de observação seja aprovada.
  • ExtranetObservationWindow: esse valor determina a duração em que as solicitações de nome de usuário e senha de locais desconhecidos estão bloqueadas. Quando a janela for aprovada, o AD FS começará a executar a autenticação de nome de usuário e senha de locais desconhecidos novamente.
  • ExtranetLockoutRequirePDC: quando habilitado, o bloqueio de extranet requer um PDC (controlador de domínio primário). Quando desabilitado: o bloqueio de extranet faz fallback para outro controlador de domínio caso o PDC não esteja disponível.
  • ExtranetLockoutMode: controla o modo Apenas Log vs. Imposto da ESL.
    • ADFSSmartLockoutLogOnly: a ESL está habilitada. O AD FS grava eventos de administrador e auditoria, mas não rejeita solicitações de autenticação. Esse modo destina-se a ser habilitado para que FamiliarLocation seja preenchido antes que ADFSSmartLockoutEnforce esteja habilitado.
    • ADFSSmartLockoutEnforce: suporte completo para bloquear solicitações de autenticação desconhecidas quando os limites são atingidos.

Há suporte para endereços IPv4 e IPv6.

Anatomia de uma transação

  • Verificação pré-autorização: durante uma solicitação de autenticação, o ESL verifica todos os IPs apresentados. Esses IPs serão uma combinação de IP de rede, IP encaminhado e o IP opcional x-forwarded-for. Nos logs de auditoria, esses IPs são listados no campo <IpAddress> na ordem de x-ms-forwarded-client-ip, x-forwarded-for, x-ms-proxy-client-ip.

    Com base nesses IPs, o AD FS determina se a solicitação é de um local familiar e verifica se o respectivo badPwdCount é menor que o limite definido ou se a última tentativa com falha ocorreu por mais tempo do que o período de tempo da janela de observação. Se uma dessas condições for verdadeira, o AD FS permitirá essa transação para processamento adicional e validação de credenciais. Se ambas as condições forem falsas, a conta já estará em um estado bloqueado até que a janela de observação seja aprovada. Depois que a janela de observação for aprovada, o usuário poderá realizar uma tentativa de autenticação. No Windows Server 2019, o AD FS verifica o limite apropriado com base em se o endereço IP corresponde a um local familiar ou não.

  • Logon com êxito: se o logon for com êxito, os IPs da solicitação serão adicionados à lista de IP de localização familiar do usuário.

  • Logon com falha: se o logon falhar, badPwdCount aumentará. O usuário entrará em um estado de bloqueio se o invasor enviar mais senhas incorretas para o sistema do que o limite permitido. (badPwdCount > ExtranetLockoutThreshold)

Diagram showing the process of successful and unsuccessful authentication.

O valor UnknownLockout é igual a True quando a conta é bloqueada. Esse bloqueio significa que o badPwdCount do usuário está acima do limite. Por exemplo, alguém tentou mais senhas do que o sistema permite. Nesse estado, há duas maneiras pelas quais um usuário válido pode fazer logon:

  • Aguarde o tempo de ObservationWindow se passar.
  • Para redefinir o estado de Bloqueio, redefinir o badPwdCount de volta para zero com Reset-ADFSAccountLockout.

Se nenhuma redefinição ocorrer, a conta terá permissão para uma única tentativa de senha no AD para cada janela de observação. Após essa tentativa, a conta retorna ao estado bloqueado e a janela de observação é reiniciada. O valor badPwdCount só será redefinido automaticamente após um logon de senha com êxito.

Modo Apenas Log versus modo Impor

A tabela AccountActivity é preenchida durante o modo Apenas Log e o modo Impor. Se o modo Apenas Log for ignorado e o ESL for movido diretamente para o modo Impor sem o período de espera recomendado, os IPs familiares dos usuários não serão conhecidos pelo AD FS. O ESL então se comportaria como ADBadPasswordCounter, potencialmente bloqueando o tráfego de usuário legítimo se a conta de usuário estiver sob um ataque de força bruta ativa. Se o modo Apenas Log for ignorado e o usuário entrar em um estado bloqueado com UnknownLockout igual a True e tentar entrar com uma senha íntegra de um IP que não esteja na lista de IP "familiar", ele não poderá entrar. O modo Apenas Log é recomendado por 3 a 7 dias para evitar esse cenário. Se as contas estiverem ativamente sob ataque, um mínimo de 24 horas do modo Apenas Log será necessário para evitar bloqueios para usuários legítimos.

Configuração de bloqueio inteligente de extranet

As seções a seguir descrevem os pré-requisitos e as configurações para habilitar o ESL para o AD FS 2016.

Pré-requisitos para o AD FS 2016

  1. Instalar atualizações em todos os nós no farm.

    Primeiro, verifique se todos os servidores do AD FS do Windows Server 2016 estão atualizados pelas Atualizações do Windows de junho de 2018 e se o Farm do AD FS 2016 é executado no nível de comportamento do Farm de 2016.

  2. Verificar permissões.

    O ESL requer que o gerenciamento remoto do Windows esteja habilitado em todos os servidores do AD FS.

  3. Atualizar permissões de banco de dados de artefato.

    O ESL requer que a conta de serviço do AD FS tenha permissões para criar uma nova tabela no banco de dados de artefatos do AD FS. Entre em qualquer servidor do AD FS como administrador do AD FS e conceda essa permissão em uma janela de prompt de comando do PowerShell executando os seguintes comandos:

    PS C:\>$cred = Get-Credential
    PS C:\>Update-AdfsArtifactDatabasePermission -Credential $cred
    

    Observação

    O espaço reservado $cred é uma conta que tem permissões de administrador do AD FS. Isso deve fornecer as permissões de gravação para criar a tabela.

    Os comandos anteriores podem falhar devido à falta de permissão suficiente porque o Farm do AD FS está usando o SQL Server e a credencial fornecida antes não tem permissão de administrador no SQL Server. Nesse caso, configure permissões de banco de dados manualmente no banco de dados do SQL Server quando estiver conectado ao banco de dados do AdfsArtifactStore executando o seguinte comando:

    # when prompted with “Are you sure you want to perform this action?”, enter Y.
    
    [CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact = 'High')]
    Param()
    
    $fileLocation = "$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
    
    if (-not [System.IO.File]::Exists($fileLocation))
    {
    write-error "Unable to open AD FS configuration file."
    return
    }
    
    $doc = new-object Xml
    $doc.Load($fileLocation)
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $connString = $connString -replace "Initial Catalog=AdfsConfigurationV[0-9]*", "Initial Catalog=AdfsArtifactStore"
    
    if ($PSCmdlet.ShouldProcess($connString, "Executing SQL command sp_addrolemember 'db_owner', 'db_genevaservice' "))
    {
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cli.Open()
    
    try
    {
    
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = "sp_addrolemember 'db_owner', 'db_genevaservice'"
    $cmd.Connection = $cli
    $rowsAffected = $cmd.ExecuteNonQuery()
    if ( -1 -eq $rowsAffected )
    {
    write-host "Success"
    }
    }
    finally
    {
    $cli.CLose()
    }
    }
    

Verifique se o Log de Auditoria de Segurança do AD FS está habilitado

Esse recurso usa logs de Auditoria de Segurança, portanto, a auditoria deve ser habilitada no AD FS e na política local em todos os servidores do AD FS.

Instruções de configuração

O ESL usa a propriedade ExtranetLockoutEnabled do AD FS. Essa propriedade foi usada anteriormente para controlar Bloqueio Reversível da Extranet no Server 2012 R2. Se o ESL estiver habilitado e você quiser exibir a configuração da propriedade atual, execute Get-AdfsProperties.

Recomendações de configuração

Ao configurar o ESL, siga as melhores práticas para definir limites:

ExtranetObservationWindow (new-timespan -Minutes 30)

ExtranetLockoutThreshold: Half of AD Threshold Value

AD value: 20, ExtranetLockoutThreshold: 10

O bloqueio do Active Directory funciona independentemente do bloqueio da ESL. No entanto, se o bloqueio do Active Directory estiver habilitado, selecione ExtranetLockoutThreshold no Limite de Bloqueio de Conta do AD FS no AD.

ExtranetLockoutRequirePDC - $false

Quando habilitado, o bloqueio da extranet requer um PDC (controlador de domínio primário). Quando desabilitado e configurado como false, o bloqueio da extranet fará fallback para outro controlador de domínio caso o PDC não esteja disponível.

Para definir esta propriedade, execute:

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-TimeSpan -Minutes 30) -ExtranetLockoutRequirePDC $false

Habilitar o modo "Apenas login"

No modo Apenas Log, o AD FS preenche informações de localização familiares dos usuários e grava eventos de auditoria de segurança, mas não bloqueia nenhuma solicitação. Esse modo é usado para validar se o bloqueio inteligente está em execução e para permitir que o AD FS "aprenda" locais familiares para os usuários antes de habilitar o modo Impor. Conforme o AD FS aprende, ele armazena a atividade de entrada por usuário (seja no modo Apenas Log ou no modo Impor). Defina o comportamento de bloqueio como Apenas Log executando o seguinte cmdlet:

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

O modo Apenas Log deve ser usado como um estado temporário para que o sistema possa aprender o comportamento de entrada antes de introduzir a imposição de bloqueio com o comportamento de bloqueio inteligente. A duração recomendada para o modo Apenas Log é de 3 a 7 dias. Se as contas estiverem ativamente sob ataque, o modo Apenas Log deverá ser executado por um mínimo de 24 horas.

No AD FS 2016, se o comportamento Bloqueio Reversível da Extranet 2012 R2 estiver habilitado antes de habilitar o Bloqueio Inteligente da Extranet, o modo Apenas Log desabilitará o comportamento de "Bloqueio Reversível da Extranet". O Bloqueio Inteligente do AD FS não bloqueia os usuários no modo Apenas Log. No entanto, o AD local pode bloquear o usuário com base na configuração do AD. Examine as políticas de bloqueio do AD para saber como o AD local pode bloquear usuários.

No AD FS 2019, outra vantagem é habilitar o modo Apenas Log para bloqueio inteligente, enquanto continua a impor o comportamento de bloqueio reversível anterior usando o PowerShell abaixo:

Set-AdfsProperties -ExtranetLockoutMode 3

Para que o novo modo entre em vigor, reinicie o serviço do AD FS em todos os nós no Farm usando:

Restart-service adfssrv

Depois que o modo estiver configurado, você poderá habilitar o bloqueio inteligente usando o parâmetro EnableExtranetLockout:

Set-AdfsProperties -EnableExtranetLockout $true

Habilitar modo "Impor"

Depois de se sentir confortável com o limite de bloqueio e a janela de observação, o ESL pode ser movido para o modo Impor usando o seguinte cmdlet PSH:

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

Para que o novo modo entre em vigor, reinicie o serviço do AD FS em todos os nós no Farm usando o comando a seguir.

Restart-service adfssrv

Gerenciar a atividade da conta de usuário

O AD FS fornece três cmdlets para gerenciar dados de atividade da conta. Esses cmdlets se conectam automaticamente ao nó no Farm que contém a função primária.

Observação

Você pode usar A JEA (Administração Just Enough) para delegar os commandlets do AD FS para redefinir os bloqueios de conta. Por exemplo, você pode delegar permissões ao pessoal do Suporte Técnico para usar comandos ESL. Para mais informações, confira Delegar acesso de comando do PowerShell do AD FS a usuários não administradores.

Você pode substituir esse comportamento passando o parâmetro -Server.

Get-ADFSAccountActivity -UserPrincipalName

O cmdlet se conecta automaticamente ao nó primário do farm usando o ponto de extremidade REST da Atividade da Conta. Portanto, todos os dados devem ser sempre consistentes. Leia a atividade da conta atual de uma conta de usuário usando:

Get-ADFSAccountActivity user@contoso.com

Propriedades:

  • BadPwdCountFamiliar: incrementado quando uma autenticação não tem êxito em um local conhecido.
  • BadPwdCountUnknown: incrementado quando uma autenticação não tem êxito em um local desconhecido.
  • LastFailedAuthFamiliar: se a autenticação não tiver êxito de um local familiar, LastFailedAuthFamiliar será definido como tempo de autenticação mal-sucedida.
  • LastFailedAuthUnknown: se a autenticação não tiver êxito de um local desconhecido, LastFailedAuthUnknown será definido como tempo de autenticação mal-sucedida.
  • FamiliarLockout: valor booliano que é True se o BadPwdCountFamiliar>ExtranetLockoutThreshold.
  • UnknownLockout: valor booliano que é True se o BadPwdCountUnknown>ExtranetLockoutThreshold.
  • FamiliarIPs: máximo de 20 IPs que são familiares para o usuário. Quando 20 IPs são excedidos, o IP mais antigo da lista será removido.

Set-ADFSAccountActivity

Set-ADFSAccountActivity adiciona locais familiares. A lista de IP familiar tem no máximo 20 entradas. Se 20 entradas forem excedidas, o IP mais antigo da lista será removido.

Set-ADFSAccountActivity user@contoso.com -AdditionalFamiliarIps “1.2.3.4”

Reset-ADFSAccountLockout

Redefine o contador de bloqueio de uma conta de usuário para cada local familiar (badPwdCountFamiliar) ou contadores local desconhecidos (badPwdCountUnfamiliar). Quando você redefine um contador, o valor FamiliarLockout ou UnfamiliarLockout é atualizado, pois o contador de redefinição é menor que o limite.

Reset-ADFSAccountLockout user@contoso.com -Location Familiar

Reset-ADFSAccountLockout user@contoso.com -Location Unknown

Informações de log de eventos e atividades do usuário para bloqueio da extranet do AD FS

As seções a seguir descrevem como monitorar o log de eventos, a atividade da conta de usuário e os bloqueios.

Connect Health

A maneira recomendada de monitorar a atividade da conta de usuário é por meio do Connect Health. O Connect Health gera relatórios para download em IPs arriscados e tentativas de senha incorretas. Cada item no relatório de IP Suspeito mostra informações agregadas sobre as atividades de entrada no AD FS com falha que excedem o limite designado. Notificações por email podem ser definidas como administradores de alerta com configurações de email personalizáveis quando ocorrem atividades de entrada do AD FS com falha. Para mais informações e instruções de instalação, confira Monitorar o AD FS usando o Microsoft Entra Connect Health.

Eventos de Bloqueio Inteligente da Extranet do AD FS

Observação

Para solucionar problemas de ESL, confira Como mitigar ataques de pulverização de senha e bloqueios de conta.

Para que os eventos de Bloqueio Inteligente da Extranet sejam gravados, o ESL deve ser habilitado no modo Apenas Log ou Impor e a auditoria de segurança do AD FS deve estar habilitada. O AD FS grava eventos de bloqueio de extranet no log de auditoria de segurança quando:

  • Um usuário está bloqueado, o que significa que o usuário atinge o limite de bloqueio para tentativas de entrada malsucedidas.
  • O AD FS recebe uma tentativa de logon para um usuário que já está no estado de bloqueio.

No modo Apenas Log, verifique o log de auditoria de segurança para eventos de bloqueio. Para qualquer evento encontrado, você pode verificar o estado do usuário usando o cmdlet Get-ADFSAccountActivity para determinar se o bloqueio ocorreu de endereços IP familiares ou não familiares. Você também pode usar o cmdlet Get-ADFSAccountActivity para verificar novamente a lista de endereços IP familiares para esse usuário.

ID do evento Descrição
1203 Esse evento é gravado para cada tentativa de senha incorreta. Assim que badPwdCount atingir o valor especificado em ExtranetLockoutThreshold, a conta será bloqueada no AD FS pela duração especificada em ExtranetObservationWindow.
ID da atividade: %1
XML: %2
1210 Esse evento é gravado sempre que um usuário é bloqueado.
ID da atividade: %1
XML: %2
557 (AD FS 2019) Erro ao tentar se comunicar com o serviço REST do repositório de contas no nó %1. Se você usa um farm de WID, o nó primário poderá estar offline. Se esse for um farm de SQL, o AD FS selecionará automaticamente um novo nó para hospedar a função primária do repositório de usuários.
562 (AD FS 2019) Erro ao se comunicar com o ponto de extremidade do repositório de contas no servidor %1.
Mensagem de exceção: %2
563 (AD FS 2019) Erro ao calcular o status de bloqueio da extranet. Devido ao valor da autenticação de configuração %1 será permitido para esse usuário e a emissão de token continuará. Se você usa um farm de WID, o nó primário poderá estar offline. Se esse for um farm de SQL, o AD FS selecionará automaticamente um novo nó para hospedar a função primária do repositório de usuários.
Nome do servidor do repositório de contas: %2
ID de usuário: %3
Mensagem de exceção: %4
512 A conta do usuário a seguir está bloqueada. Uma tentativa de entrada está sendo permitida devido à configuração do sistema.
ID da atividade: %1
Usuário: %2
IP do cliente: %3 Contagem de
senha incorreta: %4
Última tentativa de senha incorreta: %5
515 A conta de usuário a seguir estava em um estado bloqueado e a senha correta foi fornecida. Essa conta pode estar comprometida.
Mais Dados
ID da Atividade: %1
Usuário: %2
IP do Cliente: %3
516 A conta de usuário a seguir foi bloqueada devido a muitas tentativas de senha incorretas.
ID da atividade: %1
Usuário: %2
IP do cliente: %3 Contagem de
senha incorreta: %4
Última tentativa de senha incorreta: %5

Perguntas frequentes sobre ESL

Um Farm do AD FS que usa o Bloqueio Inteligente da Extranet no modo Impor verá bloqueios de usuário mal-intencionados?

Se o Bloqueio Inteligente do AD FS estiver definido como modo Impor, você nunca verá a conta do usuário legítimo bloqueada por força bruta ou negação de serviço. A única maneira de um bloqueio de conta mal-intencionado impedir que um usuário entre é se o ator inválido tiver a senha do usuário ou puder enviar solicitações de um endereço IP válido (familiar) conhecido para esse usuário.

O que acontece é que o ESL está habilitado e o ator mal-intencionado tem uma senha de usuário?

O objetivo típico do cenário de ataque de força bruta é adivinhar uma senha e entrar com êxito. Se um usuário for falsificado ou se uma senha for adivinhada, o recurso ESL não bloqueará o acesso, pois a entrada atenderá a critérios com êxito de senha correta mais novo IP. O IP de atores ruins apareceria como um familiar. A melhor mitigação nesse cenário é limpar a atividade do usuário no AD FS e exigir a autenticação multifator para os usuários. Você deve instalar a Proteção por Senha do Microsoft Entra para garantir que as senhas adivinháveis não entrem no sistema.

Se meu usuário nunca tiver se conectado com êxito de um IP e tentar com a senha errada algumas vezes, ele poderá entrar depois de digitar a senha corretamente?

Se um usuário enviar várias senhas incorretas (por exemplo, ao digitar de modo incorreto) e, na tentativa seguinte, acertar a senha, o usuário entrará imediatamente com êxito. Essa entrada bem-sucedida limpará a contagem de senhas incorretas e adicionará esse IP à lista FamiliarIPs. No entanto, se ele ultrapassar o limite de entradas com falha do local desconhecido, entrará no estado de bloqueio. Então ele deve aguardar a janela de observação e entrar com uma senha válida. Ele pode precisar de intervenção do administrador para redefinir a conta.

O ESL também funciona na intranet?

Se os clientes se conectarem diretamente aos servidores do AD FS e não por meio de servidores Proxy de Aplicativo Web, o comportamento do ESL não se aplicará.

Estou vendo endereços IP da Microsoft no campo IP do cliente. O ESL bloqueia ataques de força bruta com proxie EXO?  

O ESL funciona bem para evitar Exchange Online ou outros cenários de ataque de força bruta de autenticação herdada. Uma autenticação herdada tem uma "ID de atividade" de 00000000-0000-0000-0000-000000000000. Nesses ataques, o ator ruim está aproveitando Exchange Online autenticação básica (também conhecida como autenticação herdada) para que o endereço IP do cliente apareça como um da Microsoft. Os servidores online do Exchange na nuvem proxy da verificação de autenticação em nome do cliente Outlook. Nesses cenários, o endereço IP do remetente mal-intencionado estará no x-ms-forwarded-client-ip e o IP do servidor do Microsoft Exchange Online estará no valor x-ms-client-ip. O Bloqueio Inteligente da Extranet verifica IPs de rede, IPs encaminhados, x-forwarded-client-IP e o valor x-ms-client-ip. Se a solicitação for com êxito, todos os IPs serão adicionados à lista familiar. Se uma solicitação entrar e qualquer um dos IPs apresentados não estiver na lista familiar, a solicitação será marcada como desconhecida. O usuário familiar poderá entrar com êxito enquanto as solicitações dos locais desconhecidos serão bloqueadas.

Posso estimar o tamanho do ADFSArtifactStore antes de habilitar o ESL?

Com o ESL habilitado, o AD FS acompanha a atividade da conta e as localizações conhecidas para os usuários no banco de dados ADFSArtifactStore. Esse banco de dados é dimensionado em tamanho em relação ao número de usuários e localizações conhecidas acompanhados. Ao planejar a habilitação do ESL, você pode estimar o aumento do tamanho do banco de dados ADFSArtifactStore a uma taxa de até 1 GB a cada 100 mil usuários. Se o farm do AD FS usa o WID (Banco de Dados Interno do Windows), a localização padrão dos arquivos de banco de dados é C:\Windows\WID\Data. Para evitar o preenchimento desta unidade, verifique se você tem um mínimo de 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 depois de habilitar o ESL em até um 1 GB de RAM para populações de usuário de 500 mil ou menos.

Confira também