Olá pessoal. No artigo de hoje vou abordar uma funcionalidade do AD FS muito interessante que ajuda a proteger contas de domínio de ataques como “password spray” usando o AD FS Extranet lockout. Essa funcionalidade é chamada AD FS Extranet Smart Lockout.
Tópicos abordados no artigo de hoje
No artigo de hoje, vamos abordar os seguintes tópicos e tarefas:
- O que é o AD FS Extranet Lockout
- O que é o Extranet Smart Lockout
- Boas práticas de configuração de políticas de senhas
- Como configurar a política de senhas no AD local
- Como habilitar e configurar o AD FS Extranet Lockout
- Como configurar o AD FS Extranet Smart Lockout
- Como monitorar as atividades dos usuários
O que é o AD FS Extranet Lockout
O Extranet lockout ou soft lockout foi introduzido no serviço AD FS dos sistemas operacionais Windows Server versão 2012 R2. Essa funcionalidade foi criada para bloquear sucessíveis autenticações maliciosas externas à organização na tentativa de acesso usando brute force ou password guessing attack. Essas categorias de ataques causam o bloqueio de contas no AD local causando transtornos aos usuários e às organizações.
O que é o Extranet Smart Lockout
O ESL ou Extranet Smart Lockout é a evolução do Extranet Lockout e está disponível a partir do serviço AD FS instalado nos sistemas operacionais windows Server 2016 e mais recentes. Com essa funcionalidade, o serviço AD FS armazena locais de origem onde cada usuário efetuou um ou vários acessos válidos e permite diferenciar um acesso feito pelo dono da credencial com senha inválida de um ataque feito contra aquela conta.
Boas práticas de configuração de políticas de senhas
As políticas de Extranet Lockout do AD FS funcionam de forma independente da política de bloqueio do AD local, mas é altamente recomendável definir o limite de senhas inválidas menor que o definido no AD local e o tempo de reset dos contadores maior que os definidos no AD local. Exemplo:
Quantidade de tentativas de acesso inválidas no AD FS: 3 tentativas
Tempo para reset dos contadores no AD FS: 40 minutos
Quantidade de tentativas de acesso inválidas no AD: 6 tentativas
Tempo para reset dos contadores no AD: 30 minutos
Com a configuração acima, caso um ataque externo ocorra contra uma credencial, o acesso externo é bloqueado após a terceira tentativa, e qualquer tentativa com senha válida ou inválida é bloqueado por 40 minutos. Como a política de acesso no AD local possui um limite de até 6 tentativas inválidas, a conta não é bloqueada no AD.
Nota: Existem casos onde o usuário efetua o acesso ao AD FS da rede interna levando aos administradores acreditarem que há algum problema com a política do AD FS. Este cenário pode ser facilmente identificado através do monitoramento da conta do usuário que iremos abordar no último tópico deste artigo.
Configurando a política de bloqueio no AD local
Como primeiro passo para nossa demonstração, vamos criar a política de bloqueio de contas no AD local seguindo os passos abaixo:
1 – No servidor controlador de domínio, vamos alterar a política padrão disponível no Controle de Políticas > Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
2 – Vamos alterar o parâmetro Account lockout threshold para 6. Após aplicar esta alteração, recebemos a sugestão de tempo de bloqueio e tempo de reset automático da conta para 30 minutos.
Configurando o AD FS Extranet Lockout
Com a política de bloqueio criada no AD local, vamos ativar e definir as métricas de controle de senhas inválidas no AD FS seguindo a boa prática definida nos tópicos anteriores. Vamos rodar o comando abaixo no servidor primário AD FS:
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 3 -ExtranetObservationWindow (new-timespan -Minutes 40)
Vamos confirmar as configurações da política executando o comando abaixo:
Get-AdfsProperties
Configurando o AD FS Extranet Smart Lockout
Em um servidor Windows 2016 é necessário ter atualizações disponibilizadas em Junho de 2018 e o nível da Farm deve ser 2016 para que esta funcionalidade seja utilizada. É preciso que o serviço de gerenciamento remoto do Windows esteja ativo em todos os servidores AD FS.
Para utilizar o ESL, em servidores Windows Server 2016, é preciso atualizar a base de dados Artifact no AD FS incluindo a tabela AdfsArtifactStore.AccountActivity. Vamos executar os comandos abaixo para configurar as permissões na base de dados e para criar a tabela:
1 – Vamos colar o comando abaixo no PowerShell ISE para facilitar a execução de mais de uma linha de comando.
2 – Vamos entrar com o usuário com permissão de administrador no serviço AD FS.
3 – Vamos entrar com a senha.
4 – Clique em OK para gravar as credenciais.
$cred = Get-Credential Update-AdfsArtifactDatabasePermission -Credential $cred
Os comandos abaixo fazem as alterações das tabelas e permissões na base de dados do AD FS.
# 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 ADFS 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()
}
}
Após executar o script acima, confirme clicando em Yes to All.
Mais informações sobre as etapas acima podem ser adquiridas na documentação oficial da Microsoft através deste link.
Monitorando a atividade dos usuários
A funcionalidade de monitoramento de atividade dos usuários auxilia os administradores a identificar onde está a motivo do bloqueio de acesso ao serviço. Para coletarmos informações de atividades de uma conta, vamos rodar no AD FS o comando abaixo:
Get-ADFSAccountActivity otto@ulyneves.com
Percebemos dois parâmetros que nos permite identificar se houve alguma tentativa externa de acesso com senha inválida de uma localização conhecida ou não: BadpwdCountFamiliar e BadpwdCountUnknown.
No atributo FamiliarIps, podemos identificar os IPs externos onde o usuário Otto já efetuou acesso com sucesso. Esses endereços IPs permitem a classificação de localidade como familiar no AD FS.
Como teste, vamos entrar propositalmente com a senha inválida do usuário otto@ulyneves.com no portal do AD FS.
Identificamos abaixo que o contador parou de incrementar na terceira tentativa conforme política ESL configurada. Percebemos que foi classificada como familiar, pois efetuei o teste de uma localidade onde o acesso foi feito com sucesso anteriormente.
Com o contador abaixo em 3, mesmo com senha válida, meu acesso foi bloqueado por 40 minutos e será zerado após este período.
Confirmamos no AD local que o usuário Otto possui o atributo badPwdCount com valor 3, que confirma o limite de tentativas feitas pelo AD FS no PDC para confirmar as credenciais fornecidas durante o teste.
Conseguimos confirmar com o teste acima que, seguindo as boas práticas definidas pela Microsoft, é possível proteger as credenciais do AD local de ataques externos à organização.
Caso o usuário precise efetuar o acesso externo e não possa aguardar o tempo de reset automático, e possível efetuar o reset do atributo BadpwdCountFamiliar com o comando abaixo:
Reset-ADFSAccountLockout otto@ulyneves.com -Location Familiar
Com o reset efetuado e de posse das credenciais válidas, o acesso do usuário Otto@ulyneves.com é permitido na aplicação.
Resumo
No artigo de hoje, explicamos como proteger contas de AD local utilizando políticas de controle de senhas inválidas e demonstramos como configurar a funcionalidade Extranet smart lockout disponíveis nas versões do AD FS 2019 e 2016.
Espero que este conteúdo tenha contribuído com o enriquecimento do conhecimento de vocês em Azure AD FS.
Gostaram do post? Curtam e compartilhem. 🙂
Tem alguma sugestão ou observação, comente.
[ ]’s
Ulysses Neves
