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

  • Artigo

A redefinição de senha de autoatendimento (SSPR) do Microsoft Entra permite que os usuários redefina suas senhas na nuvem, mas a maioria das empresas também tem um ambiente local dos Serviços de Domínio Ative Directory (AD DS) para os usuários. O write-back de senha permite que as alterações de senha na nuvem sejam gravadas novamente em um diretório local em tempo real usando o Microsoft Entra Connect ou a sincronização na nuvem do Microsoft Entra Connect. Quando os usuários alteram ou redefinem suas senhas usando SSPR na nuvem, as senhas atualizadas também são gravadas de volta no ambiente AD DS local.

Importante

Este artigo conceitual explica a um administrador como funciona o write-back de redefinição de senha de autoatendimento. Se você for um usuário final já registrado para redefinição de senha de autoatendimento e precisar voltar à sua conta, vá para https://aka.ms/sspr.

Se a sua equipa de TI não tiver ativado a capacidade de repor a sua própria palavra-passe, contacte o seu serviço de assistência para obter assistência adicional.

O write-back de senha é suportado em ambientes que usam os seguintes modelos de identidade híbrida:

O write-back de senha fornece os seguintes recursos:

  • Aplicação de diretivas de senha dos Serviços de Domínio Ative Directory (AD DS) locais: quando um usuário redefine sua senha, ela é verificada para garantir que ela atenda à sua política do AD DS local antes de confirmá-la nesse diretório. Esta análise inclui a verificação do histórico, complexidade, idade, filtros de palavra-passe e quaisquer outras restrições de palavra-passe definidas no AD DS.
  • Feedback de atraso zero: O write-back de senha é uma operação síncrona. Os usuários são notificados imediatamente se sua senha não atender à política ou não puder ser redefinida ou alterada por qualquer motivo.
  • Suporta alterações de palavras-passe no painel de acesso e no Microsoft 365: quando os utilizadores sincronizados do hash de palavras-passe ou federados tentam alterar as palavras-passe expiradas ou não expiradas, essas palavras-passe são novamente gravadas no AD DS.
  • Suporta write-back de senha quando um administrador as redefine a partir do 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 estiver federado ou o hash de senha sincronizado, a senha será gravada novamente no local. No momento, essa funcionalidade não é suportada 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 um canal de comunicação subjacente. Toda a comunicação é de saída pela porta 443.
  • Suporta implantação lado a lado no nível de domínio usando o Microsoft Entra Connect ou sincronização na nuvem para direcionar diferentes conjuntos de usuários, dependendo de suas necessidades, incluindo usuários que estão em domínios desconectados.

Nota

A conta de serviço local que lida com solicitações de write-back de senha não pode alterar as senhas de usuários que pertencem a grupos protegidos. Os administradores podem alterar suas senhas na nuvem, mas não podem usar o write-back de senha para redefinir uma senha esquecida para seu usuário local. Para obter mais informações sobre grupos protegidos, consulte Contas e grupos protegidos no AD DS.

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

Microsoft Entra Connect e sincronização na nuvem lado a lado

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

Como funciona a repetição de escrita de palavras-passe

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 é realizada para ver que tipo de senha o usuário tem. Se a palavra-passe for gerida no local:

    • Uma verificação é executada para ver se o serviço de write-back está ativo e em execução. Se for, o usuário pode prosseguir.
    • 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 os portões de autenticação apropriados e chega à página Redefinir senha .

  3. O utilizador seleciona uma nova palavra-passe e confirma-a.

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

  5. A senha criptografada é incluída em uma carga que é enviada por um canal HTTPS para sua 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). Esta retransmissão é protegida por uma palavra-passe gerada aleatoriamente que apenas a sua instalação no local conhece.

  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 ser vinculado ao objeto de metaverso (MV) correspondente.
    • O objeto de usuário deve estar vinculado ao objeto de conector correspondente do Microsoft Entra.
    • O link do objeto do conector AD DS para o MV deve ter a regra Microsoft.InfromADUserAccountEnabled.xxx de sincronização no link.

    Quando a chamada chega da nuvem, o mecanismo de sincronização usa o atributo cloudAnchor para procurar o objeto de espaço do conector 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.InfromADUserAccountEnabled.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 de definição de senha for bem-sucedida, o usuário será informado de que sua senha foi alterada.

    Nota

    Se o hash de senha do usuário for sincronizado com o ID do Microsoft Entra usando a sincronização de hash de senha, há uma chance 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 é imposta. Esta política garante que a política no local é aplicada na cloud, independentemente de utilizar a sincronização do hash de palavras-passe ou a federação para permitir o início de sessão ú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 fora do ar.
    • 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 a intervenção do administrador.

Segurança de write-back 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 de quatro camadas é habilitado da seguinte maneira:

  • Retransmissão de 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 protegida por uma senha forte gerada aleatoriamente à qual a Microsoft nunca tem acesso.
  • Bloqueado, criptograficamente forte, chave de criptografia de senha
    • Depois que a retransmissão do barramento de serviço é criada, uma chave simétrica forte é criada para criptografar a senha à medida que ela vem pelo fio. Essa chave só vive na loja secreta da sua empresa na nuvem, que é fortemente bloqueada e auditada, assim como qualquer outra senha no diretório.
  • Segurança da camada de transporte (TLS) padrão do setor
    1. Quando ocorre uma operação de redefinição ou alteração de senha 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 Microsoft TLS/SSL para sua retransmissão de barramento de serviço.
    3. Depois que a mensagem chega no barramento de serviço, o agente local é ativado e autenticado no barramento de serviço usando a senha forte que foi 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 aplicaçã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 mensagens
    • Se a mensagem ficar no barramento de serviço porque o serviço local está inativo, ela expira e é removida após vários minutos. O tempo limite e a remoção da mensagem aumentam ainda mais a segurança.

Detalhes de 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. São descritos da seguinte forma:

  1. Encriptação de palavra-passe com chave RSA de 2048 bits: depois de um utilizador submeter uma palavra-passe para ser escrita novamente no local, a própria palavra-passe submetida é encriptada com uma chave RSA de 2048 bits.
  2. Criptografia no nível do pacote com AES-GCM de 256 bits: Todo o pacote, 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 Service Bus visualize ou adultere o conteúdo.
  3. Toda a comunicação ocorre através de TLS/SSL: Toda a comunicação com o Service Bus acontece num canal SSL/TLS. Esta encriptação protege o conteúdo de terceiros não autorizados.
  4. Substituição automática de chaves a cada seis meses: Todas as chaves são substituídas a cada seis meses ou sempre que o write-back de senha é desativado e, em seguida, reativado no Microsoft Entra Connect, para garantir a máxima segurança e proteção do serviço.

Uso da largura de banda de write-back de senha

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

  • Duas mensagens são enviadas quando o recurso é habilitado ou desabilitado por meio do Microsoft Entra Connect.
  • Uma mensagem é enviada uma vez a cada cinco minutos como uma pulsação de serviço enquanto o serviço estiver em execução.
  • Duas mensagens são enviadas cada vez 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:
      • Cada vez que uma nova senha é enviada durante uma redefinição de senha de autoatendimento do usuário.
      • Cada vez que uma nova senha é enviada durante uma operação de alteração de senha de usuário.
      • Cada vez que uma nova senha é enviada durante uma redefinição de senha de usuário iniciada pelo administrador (somente dos portais de administração do Azure).

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

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 está consumindo alguns kilobits 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 porque o tamanho da mensagem é muito pequeno, o uso de largura de banda do recurso de write-back é muito pequeno para ter um impacto mensurável.

Operações de write-back suportadas

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

  • Operações de utilizador final suportadas

    • Qualquer operação de alteração voluntária de senha de autoatendimento do usuário final.
    • Qualquer operação de autoatendimento do usuário final força a alteração da senha, por exemplo, a expiração da senha.
    • Qualquer redefinição de senha de autoatendimento do usuário final originada do portal de redefinição de senha.

  • Operações de administrador suportadas

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

Operações de write-back sem suporte

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

  • Operações de utilizador final não suportadas
    • Um utilizador final a repor a sua própria palavra-passe com o PowerShell versão 1, versão 2 ou com a Microsoft Graph API.
  • Operações de administrador sem suporte
    • Qualquer redefinição de senha de usuário final iniciada pelo administrador a partir do PowerShell versão 1 ou versão 2.
    • Qualquer redefinição de senha de usuário final iniciada pelo administrador a partir do centro de administração do Microsoft 365.
    • Nenhum administrador pode utilizar a ferramenta de reposição de palavra-passe para repor a sua própria palavra-passe para a repetição de escrita de palavras-passe.

Aviso

O uso da caixa de seleção "O usuário deve alterar a senha no próximo logon" nas ferramentas administrativas locais do AD DS, como Usuários e Computadores do Ative Directory ou no Centro Administrativo do Ative Directory, é suportado como um recurso de visualização do Microsoft Entra Connect. Para obter mais informações, consulte Implementar sincronização de hash de senha com o Microsoft Entra Connect Sync.

Nota

Se um usuário tiver a opção "A senha nunca expira" definida no Ative Directory (AD), o sinalizador forçar alteração de senha não será definido no Ative Directory (AD), portanto, o usuário não será solicitado a alterar a senha durante o próximo login, mesmo que a opção para forçar o usuário a alterar sua senha no próximo logon seja selecionada durante uma redefinição de senha de usuário final iniciada pelo administrador.

Próximos passos

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

Tutorial: Habilitar write-back de redefinição de senha de autoatendimento (SSPR)