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

2025-03-14

A redefinição de senha de autoatendimento (SSPR) do Microsoft Entra permite que os usuários redefinam suas senhas na nuvem, mas a maioria das empresas também tem um ambiente local dos Serviços de Domínio Active 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 Microsoft Entra Connect ou de 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 a reescrita da redefinição de senha de autoatendimento. Se é um utilizador final já registado para redefinição de senha de auto-serviço e precisar aceder novamente à 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:

A retrogravação de senha fornece os seguintes recursos:

Imposição de políticas de palavra-passe dos Serviços de Domínio Active Directory (AD DS) locais: Quando um utilizador redefine a sua palavra-passe, esta é verificada para assegurar que cumpre a política do AD DS local antes de ser registada nesse directó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.
pt-PT: Suporta alterações de palavra-passe a partir do painel de acesso e do Microsoft 365: Quando os utilizadores federados ou sincronizados por hash de palavra-passe vêm alterar as suas palavras-passe expiradas ou não expiradas, essas palavras-passe são registadas novamente no AD DS.
Suporta a escrita reversa da senha quando um administrador a redefine a partir do centro de administração da Microsoft Entra: Quando um administrador redefine a senha de um utilizador no centro de administração da Microsoft Entra, se esse utilizador estiver federado ou tiver o hash da senha sincronizado, a senha será escrita novamente no local. No momento, essa funcionalidade não é suportada no portal de administração do Office.
Não requer nenhumas regras de firewall de entrada: A reversão de palavra-passe utiliza um relay do Azure Service Bus como canal de comunicação subjacente. Toda a comunicação é de saída pela porta 443.
Suporta implantação lado a lado ao nível de domínio usando Microsoft Entra Connect ou sincronização na nuvem para direcionar diferentes conjuntos de utilizadores, dependendo das suas necessidades, incluindo utilizadores que estão em domínios desconectados.

Observação

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 domínios diferentes 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 implementação, consulte Comparação entre o Microsoft Entra Connect e a sincronização na nuvem.

Como funciona a regravação 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:

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á instalado 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.
Em seguida, o utilizador passa os portões de autenticação apropriados e alcança a página Redefinir senha.
O utilizador seleciona uma nova palavra-passe e confirma-a.
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.
A senha criptografada é incluída numa carga útil que é enviada por um canal HTTPS para o relé de barramento de serviço específico do locatário (que é configurado para si durante o processo de configuração de devolução). Este relé é protegido por uma palavra-passe gerada aleatoriamente que apenas a sua instalação no local conhece.
Depois que a mensagem chega ao barramento de serviços, o endpoint de redefinição de senha é ativado automaticamente e verifica que há uma solicitação de redefinição pendente.
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 do AD DS para o MV deve ter a regra de sincronização Microsoft.InfromADUserAccountEnabled.xxx no link.
Quando a chamada chega da nuvem, o mecanismo de sincronização usa o atributo cloudAnchor para procurar o objeto no 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 link Microsoft.InfromADUserAccountEnabled.xxx para escolher o correto.
Depois que a conta de usuário for encontrada, será feita uma tentativa de redefinir a senha diretamente na floresta apropriada do AD DS.
Se a operação de definição de senha for bem-sucedida, o usuário será informado de que sua senha foi alterada.

Observação

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 no local é imposta. Essa política garante que sua política local seja aplicada na nuvem, não importa se você usa sincronização de hash de senha ou federação para fornecer logon único.
Se a operação de definição de senha falhar, um erro solicitará que o usuário tente novamente. A operação pode falhar devido aos seguintes motivos:
- O serviço estava indisponível.
- 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 regravação 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 inquilino
- 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, fortemente encriptada, chave de encriptação de palavra-passe
- 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 através do 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.
de Transport Layer Security (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 numa mensagem HTTPS que é enviada através de um canal criptografado, utilizando certificados TLS/SSL da Microsoft, para o relay do service bus.
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 imposição de sua 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:

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.
Criptografia no nível do pacote comAES-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.
Toda a comunicação ocorre por TLS/SSL: Toda a comunicação com o Service Bus acontece em um canal SSL/TLS. Esta encriptação protege o conteúdo de terceiros não autorizados.
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 regravação de senhas

A reposição de palavra-passe é um serviço de baixa largura de banda que só envia solicitações de volta para o agente no 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 Entra).

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 retroescrita de palavra-passe consome alguns kilobits por segundo da 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 usuário 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 de senha, por exemplo, expiração de 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 voluntária de alteração de senha realizada por autoatendimento por parte do administrador.
- Qualquer operação de alteração de senha forçada pelo autoatendimento administrativo, por exemplo, a expiração da senha.
- Qualquer redefinição de senha de autoatendimento de 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 do Microsoft Graph API.

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
- Qualquer usuário final redefinindo sua própria senha usando o PowerShell versão 1, versão 2 ou a API do Microsoft Graph.
Operações de administrador não suportadas
- 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 usar a ferramenta de redefinição de senha para redefinir a própria senha para reversão de senha.

Observação

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 o write-back de redefinição de senha de autoatendimento (SSPR)