Compartilhar via

Remover o uso de senha da ID do Microsoft Entra

As senhas são um dos métodos de autenticação menos seguros disponíveis. Eles são vulneráveis a uma ampla gama de ameaças, incluindo phishing, preenchimento de credenciais, ataques de força bruta e engenharia social. Para obter os benefícios da autenticação sem senha na ID do Microsoft Entra, você deve garantir que as senhas não estejam mais disponíveis como uma opção de entrada em seu locatário.

O embaralhamento de senhas garante que os usuários não possam autenticar-se usando senhas. Isso os força a usar credenciais sem senha mais seguras resistentes a phishing, como Windows Hello para Empresas, chaves de segurança FIDO2 ou chave de passagem no Microsoft Authenticator. Como não há nenhuma referência conhecida da senha após o embaralhamento, isso reduz a superfície de ataque para agentes mal-intencionados.

Este artigo fornece diretrizes sobre como criptografar senhas para usuários híbridos sincronizados do Active Directory Domain Services (AD DS) no local e usuários apenas na nuvem no Microsoft Entra ID.

Pré-requisitos

Embaralhar senhas para contas de usuário híbrido sincronizadas do AD DS local

As organizações com usuários sincronizados do Active Directory DS local para o Microsoft Entra ID devem criptografar senhas de usuário no ambiente local, uma vez que esse local é a fonte de autoridade para as contas de usuário sincronizadas e suas senhas. Se sua organização usar a autenticação de nuvem e sincronizar hashes de senha com a ID do Microsoft Entra, essas senhas mexidas também serão sincronizadas com a nuvem. O processo de sincronização garante que os usuários não estejam cientes de suas senhas no local ou na nuvem, impedindo seu uso e orientando os usuários a usar credenciais sem senha mais seguras resistentes a phishing.

Embaralhar senhas de usuários no local com um valor aleatório gerado por script.

No Active Directory, não é possível remover um atributo de senha de uma conta de usuário. Portanto, para evitar que a senha seja usada, você pode alterar a senha periodicamente.

Se você tiver aplicativos herdados que ainda exigem uma senha para autenticação, os usuários poderão continuar a usar a redefinição de senha de autoatendimento (SSPR) para definir sua senha para um valor previamente conhecido, permitindo o acesso a esses aplicativos por um tempo determinado, até que sua senha seja embaralhada novamente.

Você pode usar o script a seguir para embaralhar automaticamente qualquer senha que os usuários redefinirem para um estado padrão conhecido.

O script permite embaralhar a senha de um usuário em seu domínio do AD DS. Ele gera uma senha aleatória de 64 caracteres e a define para o usuário especificado no nome da variável $samAccountName. Você deve modificar a variável $samAccountName no script para direcionar o usuário apropriado. Use as credenciais de uma conta de administrador com permissões apropriadas no AD DS local.

Cuidado

Execute o script somente de um ambiente seguro e confiável e verifique se o script não está registrado. Trate o host em que o script é executado como um host privilegiado, com o mesmo nível de segurança que um controlador de domínio.

$samAccountName = <sAMAccountName of the user>

Import-Module ActiveDirectory

function Generate-RandomPassword{
    [CmdletBinding()]
    param (
      [int]$Length = 64
    )
  $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+[]{};:,.<>/?\|`~"
  $random = New-Object System.Random
  $password = ""
  for ($i = 0; $i -lt $Length; $i++) {
    $index = $random.Next(0, $chars.Length)
    $password += $chars[$index]
  }
  return $password
}

Import-Module ActiveDirectory

$NewPassword = ConvertTo-SecureString -String (Generate-RandomPassword) -AsPlainText -Force

Set-ADAccountPassword -Identity $samAccountName -NewPassword $NewPassword -Reset

Observação

Se o script de codificação de senha for executado com menos frequência do que a política de idade da senha atual, considere aumentar a idade da senha como maior que essa frequência ou definir a idade da senha como 0, o que desabilita a expiração da senha.

Randomizar senhas para contas de usuário de nuvem na ID do Microsoft Entra

Os usuários sem senha baseados em nuvem devem ter sua senha definida como um valor aleatório. A randomização da senha impede que o usuário saiba a senha e a use para autenticar. Opcionalmente, as organizações podem permitir que os usuários finais redefinam a senha se encontrarem um aplicativo em que precisem da senha. Execute o script rotineiramente para embaralhar quaisquer senhas que os usuários alterarem para retornar a um estado conhecido.

O exemplo de script do PowerShell a seguir gera uma senha aleatória de 64 caracteres e a define para o usuário especificado no nome da variável $userId em relação à ID do Microsoft Entra. Modifique a variável $userId do script para corresponder ao seu ambiente e, em seguida, execute-a em uma sessão do PowerShell. Quando solicitado a autenticar na ID do Microsoft Entra, use as credenciais de uma conta com uma função que pode redefinir senhas.

$userId = "<UPN of the user>"

function Generate-RandomPassword{
    [CmdletBinding()]  
    param (  
      [int]$Length = 64  
    )  
  $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+[]{};:,.<>/? \|`~"  
  $rng = [System.Security.Cryptography.RandomNumberGenerator]::Create()  
  $bytes = New-Object byte[] $Length  
  $rng.GetBytes($bytes)  
  $password = -join ($bytes | ForEach-Object { $chars[$_ % $chars.Length] })  
  $rng.Dispose()  
  return $password  
}

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph.Users.Actions
Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All" -NoWelcome

$passwordParams = @{
 UserId = $userId
 AuthenticationMethodId = "28c10230-6103-485e-b985-444c60001490"
 NewPassword = Generate-RandomPassword
}

Reset-MgUserAuthenticationMethodPassword @passwordParams

Cuidado

Execute o script somente de um ambiente seguro e confiável e verifique se o script não está registrado. Trate o host em que o script é executado como um host privilegiado, com o mesmo nível de segurança que um controlador de domínio.

Mais considerações para organizações que impõem completamente a autenticação resistente a phishing

Se sua organização não precisar mais de senhas, porque todos os aplicativos e cenários são compatíveis com credenciais sem senha, talvez você não precise mais fornecer aos usuários opções de recuperação de senha de autoatendimento. Considere desabilitar ferramentas que permitem que os usuários anulem as senhas embaralhadas e recuperem o acesso à senha.

Conteúdo relacionado

Implantar uma autenticação resistente a phishing no Microsoft Entra ID

  • Last updated on