Como funciona o write-back da redefinição de senha self-service no Microsoft Entra ID?

A SSPR (redefinição de senha de autoatendimento) do Microsoft Entra permite que os usuários redefinam suas senhas na nuvem, mas a maioria das empresas também tem um ambiente local do AD DS (Active Directory Domain Services) para os usuários. O recurso de escrita de volta de senha permite que as alterações de senha na nuvem sejam escritas de volta em um diretório local no local em tempo real, usando o Microsoft Entra Connect ou a sincronização de nuvem do Microsoft Entra Connect. Quando os usuários alteram ou redefinem suas senhas usando o SSPR na nuvem, as senhas atualizadas também são escritas de volta no ambiente local do AD DS.

Há suporte para write-back de senha em ambientes que usam os seguintes modelos de identidade híbrida:

• Sincronização de hash de senha
• Autenticação de passagem
• Serviços de Federação do Active Directory

O recurso de write-back de senha fornece os seguintes recursos:

• Aplicação das políticas de senha do Active Directory Domain Services (AD DS) local: quando um usuário redefine a senha, ela é verificada para garantir que atende à política do AD DS local antes de ser confirmada nesse diretório. Essa revisão inclui a verificação do histórico, complexidade, idade, filtros de senha e quaisquer outras restrições de senha que você definir no AD DS.
• Comentários de atraso zero: o write-back de senha é uma operação síncrona. Os usuários são notificados imediatamente se a senha não atender à política ou não puder ser redefinida ou alterada por qualquer motivo.
• Suporte para alterações de senha no painel de acesso e no Microsoft 365: quando usuários federados ou com sincronização de hash de senha alteram suas senhas expiradas ou não expiradas, essas senhas são gravadas no AD DS.
• Dá suporte à reversão de senha quando um administrador as redefine no Centro de Administração do Microsoft Entra: quando um administrador redefine a senha de um usuário no Centro de Administração do Microsoft Entra, se esse usuário for federado ou tiver o hash de senha sincronizado, a senha será gravada novamente no local. No momento, não há suporte para essa funcionalidade no portal de administração do Office.
• Não requer regras de firewall de entrada: o write-back de senha usa uma retransmissão do Barramento de Serviço do Azure como canal de comunicação subjacente. Toda a comunicação é de saída pela porta 443.
• Dá suporte à implantação lado a lado no nível do domínio usando o Microsoft Entra Connect ou a sincronização de nuvem para direcionar diferentes conjuntos de usuários, dependendo de suas necessidades, incluindo usuários que estão em domínios desconectados.

Para começar a usar o write-back do SSPR, conclua um ou ambos os seguintes tutoriais:

• Tutorial: habilitar write-back da redefinição de senha self-service (SSPR)
• Tutorial: habilitar o write-back da redefinição de senha self-service da sincronização de nuvem do Microsoft Entra Connect em um ambiente local

Implantação lado a lado do Microsoft Entra Connect e da sincronização de nuvem

Você pode implantar o Microsoft Entra Connect e a sincronização de nuvem lado a lado em diferentes domínios para direcionar diferentes conjuntos de usuários. Isso ajuda usuários existentes a continuarem fazendo write-back das alterações de senha enquanto a opção é adicionada em casos em que os usuários estão em domínios desconectados devido a uma fusão ou divisão da empresa. O Microsoft Entra Connect e a sincronização de nuvem podem ser configurados em domínios diferentes para que os usuários de um domínio possam usar o Microsoft Entra Connect enquanto os usuários em outro domínio usam a sincronização de nuvem. A sincronização de nuvem também pode fornecer maior disponibilidade porque não depende de uma única instância do Microsoft Entra Connect. Para ver uma comparação dos recursos das duas opções de implantação, confira Comparação entre o Microsoft Entra Connect e a sincronização de nuvem.

Como funciona o write-back de senha

Quando uma conta de usuário configurada para federação, sincronização de hash de senha (ou, no caso de uma implantação do Microsoft Entra Connect, autenticação de passagem) tenta redefinir ou alterar uma senha na nuvem, as seguintes ações ocorrem:

1. Uma verificação é executada para ver que tipo de senha o usuário tem. Se a senha for gerenciada localmente:

   • Uma verificação é executada para ver se o serviço de write-back está em execução. Se for, o usuário poderá continuar.
   • Se o serviço de write-back estiver inativo, o usuário será informado de que sua senha não pode ser redefinida no momento.

2. Em seguida, o usuário passa pelas portas de autenticação apropriadas e chega à página Redefinir senha .

3. O usuário seleciona uma nova senha e a confirma.

4. Quando o usuário seleciona Enviar, a senha de texto não criptografado é criptografada com uma chave pública criada durante o processo de configuração de write-back.

5. A senha criptografada é incluída em um payload que é enviado por um canal HTTPS para a retransmissão de barramento de serviço específica do locatário (que é configurada para você durante o processo de configuração de write-back). Essa retransmissão é protegida por uma senha gerada aleatoriamente que somente sua instalação local sabe.

6. Depois que a mensagem chega ao barramento de serviço, o ponto de extremidade de redefinição de senha é ativado automaticamente e vê que tem uma solicitação de redefinição pendente.

7. Em seguida, o serviço procura o usuário usando o atributo de âncora de nuvem. Para que essa pesquisa seja bem-sucedida, as seguintes condições devem ser atendidas:

   • O objeto de usuário deve existir no espaço do conector do AD DS.
   • O objeto de usuário deve estar vinculado ao objeto MV (metaverso) correspondente.
   • O objeto de usuário deve estar vinculado ao objeto de conector do Microsoft Entra correspondente.
   • O link do objeto de conector do AD DS para o MV deve ter a regra de sincronização Microsoft.InformADUserAccountEnabled.xxx no link.

   Quando a chamada vem da nuvem, o mecanismo de sincronização usa o atributo cloudAnchor para pesquisar o objeto de espaço do conector do Microsoft Entra. Em seguida, ele segue o link de volta para o objeto MV e, em seguida, segue o link de volta para o objeto AD DS. Como pode haver vários objetos do AD DS (várias florestas) para o mesmo usuário, o mecanismo de sincronização depende do Microsoft.InformADUserAccountEnabled.xxx link para escolher o correto.

8. Depois que a conta de usuário for encontrada, será feita uma tentativa de redefinir a senha diretamente na floresta apropriada do AD DS.

9. Se a operação do conjunto de senhas for bem-sucedida, o usuário será informado de que sua senha foi alterada.

   Observação

   Se o hash da senha do usuário for sincronizado com o Microsoft Entra ID por meio da sincronização de hash de senha, existe a possibilidade de que a política de senha local seja mais fraca do que a política de senha na nuvem. Nesse caso, a política local é aplicada. Essa política garante que sua política local seja aplicada na nuvem, independentemente de você usar sincronização de hash de senha ou federação para fornecer logon único.

10. Se a operação de conjunto de senhas falhar, um erro solicitará que o usuário tente novamente. A operação pode falhar devido aos seguintes motivos:

    • O serviço estava inativo.
    • A senha selecionada não atende às políticas da organização.
    • Não é possível localizar o usuário no ambiente local do AD DS.

    As mensagens de erro fornecem orientação aos usuários para que eles possam tentar resolver sem intervenção do administrador.

Segurança de retorno de senha

O write-back de senha é um serviço altamente seguro. Para garantir que suas informações estejam protegidas, um modelo de segurança em quatro camadas está habilitado da seguinte maneira:

• A retransmissão do barramento de serviço específica do locatário
  • Quando você configura o serviço, uma retransmissão de barramento de serviço específica do locatário é configurada e protegida por uma senha forte gerada aleatoriamente à qual a Microsoft nunca tem acesso.
• Chave de criptografia de senha forte e bloqueada
  • Depois que a retransmissão de barramento de serviço é criada, uma chave simétrica forte é criada para criptografar a senha à medida que ela é transmitida. Essa chave só reside no repositório de segredos da sua empresa na nuvem, que está fortemente bloqueado e auditado, assim como qualquer outra senha no diretório.
• Protocolo TLS (TLS) padrão do setor
  1. Quando uma operação de redefinição ou alteração de senha ocorre na nuvem, a senha de texto sem formatação é criptografada com sua chave pública.
  2. A senha criptografada é colocada em uma mensagem HTTPS que é enviada por um canal criptografado usando certificados TLS/SSL da Microsoft para a retransmissão do barramento de serviço.
  3. Depois que a mensagem chega ao barramento de serviço, o agente local é ativado e se autentica no barramento de serviço usando a senha forte gerada anteriormente.
  4. O agente local pega a mensagem criptografada e a descriptografa usando a chave privada.
  5. O agente local tenta definir a senha por meio da API SetPassword do AD DS. Esta etapa é o que permite a imposição da política de senha local do AD DS (como complexidade, idade, histórico e filtros) na nuvem.
• Políticas de expiração de mensagem
  • Se a mensagem permanecer no barramento de serviço porque o serviço local está inativo, ela será removida após alguns minutos. O tempo limite e a remoção da mensagem aumentam ainda mais a segurança.

Detalhes da criptografia de write-back de senha

Depois que um usuário envia uma redefinição de senha, a solicitação de redefinição passa por várias etapas de criptografia antes de chegar ao seu ambiente local. Essas etapas de criptografia garantem a máxima confiabilidade e segurança do serviço. Eles são descritos da seguinte maneira:

1. Criptografia de senha com chave RSA de 2048 bits: depois que um usuário envia uma senha para ser gravada novamente no local, a senha enviada em si é criptografada com uma chave RSA de 2048 bits.
2. Criptografia em nível de pacote com AES-GCM de 256 bits: o pacote inteiro, a senha mais os metadados necessários, é criptografado usando AES-GCM (com um tamanho de chave de 256 bits). Essa criptografia impede que qualquer pessoa com acesso direto ao canal subjacente do Barramento de Serviço visualize ou viole o conteúdo.
3. Toda a comunicação ocorre pelo TLS/SSL: toda a comunicação com o Barramento de Serviço ocorre em um canal SSL/TLS. Essa criptografia protege o conteúdo de terceiros não autorizados.
4. Substituição automática de chave a cada seis meses: todas as chaves são substituídas a cada seis meses ou sempre que a gravação de senha é desabilitada e habilitada novamente no Microsoft Entra Connect, para garantir a segurança máxima do serviço.

Uso de largura de banda para retorno de senha

O write-back de senha é um serviço de baixa largura de banda que só envia solicitações de volta ao agente local nas seguintes circunstâncias:

• Duas mensagens são enviadas quando o recurso está habilitado ou desabilitado por meio do Microsoft Entra Connect.
• Uma mensagem é enviada a cada cinco minutos como uma pulsação do serviço enquanto o serviço está em execução.
• Duas mensagens são enviadas sempre que uma nova senha é enviada:
  • A primeira mensagem é uma solicitação para executar a operação.
  • A segunda mensagem contém o resultado da operação e é enviada nas seguintes circunstâncias:
    • Sempre que uma nova senha é enviada durante uma redefinição de senha self-service do usuário.
    • Sempre que uma nova senha é enviada durante uma operação de alteração de senha do usuário.
    • Sempre que uma nova senha é enviada durante uma redefinição de senha de usuário iniciada pelo administrador (somente nos portais de administração do Entra).

Considerações sobre tamanho da mensagem e largura de banda

O tamanho de cada uma das mensagens descritas anteriormente normalmente é inferior a 1 KB. Mesmo sob cargas extremas, o próprio serviço de write-back de senha consome alguns quilobits por segundo de largura de banda. Como cada mensagem é enviada em tempo real, somente quando exigido por uma operação de atualização de senha e, como o tamanho da mensagem é tão pequeno, o uso da largura de banda da funcionalidade de write-back é muito pequeno para ter um impacto mensurável.

Operações de write-back com suporte

As senhas são gravadas novamente em todas as seguintes situações:

• Operações de usuário final com suporte

  • Qualquer operação de alteração de senha voluntária de autoatendimento do usuário final.
  • Qualquer operação de alteração forçada de senha self-service do usuário final, por exemplo, expiração de senha.
  • Qualquer redefinição de senha de autoatendimento do usuário final originária do portal de redefinição de senha.

• Operações de administrador com suporte

  • Qualquer operação de alteração de senha voluntária de autoatendimento do administrador.
  • Qualquer operação de autoatendimento do administrador para forçar a alteração de senha, por exemplo, expiração de senha.
  • Qualquer redefinição de senha de autoatendimento do administrador originária do portal de redefinição de senha.
  • Qualquer redefinição de senha do usuário final iniciada pelo administrador no centro de administração do Microsoft Entra.
  • Qualquer redefinição de senha do usuário final iniciada pelo administrador da API do Microsoft Graph.

Operações de write-back sem suporte

As senhas não são gravadas novamente em nenhuma das seguintes situações:

• Operações de usuário final sem suporte

  • Qualquer usuário final que redefine sua própria senha usando o PowerShell versão 1, versão 2 ou a API do Microsoft Graph.

• Operações de administrador sem suporte

  • Qualquer redefinição de senha do usuário final iniciada pelo administrador do PowerShell versão 1 ou versão 2.
  • Qualquer redefinição de senha do usuário final iniciada pelo administrador do Centro de administração do Microsoft 365.
  • Qualquer administrador não pode usar a ferramenta de redefinição de senha para redefinir sua própria senha para write-back de senha.

Próximas etapas

Para começar a usar o write-back do SSPR, conclua o seguinte tutorial: