Compartilhar via

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

  • Artigo

A SSPR (redefinição de senha self-service) do Microsoft Entra permite que os usuários redefinam as senhas na nuvem, mas a maioria das empresas também tem um ambiente do AD DS (Active Directory Domain Services) local para os usuários. O write-back de senha permite que as alterações de senha na nuvem sejam gravadas 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 o SSPR na nuvem, as senhas atualizadas também são gravadas no ambiente do AD DS local.

Importante

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

Se sua equipe de TI não tiver habilitado a capacidade de redefinir sua própria senha, entre em contato com sua assistência técnica para obter mais assistência.

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

O write-back de senha fornece os seguintes recursos:

  • Imposição de políticas de senha do Active Directory Domain Services (AD DS) local: quando um usuário redefine a senha, é verificado se essa senha atende à política do AD DS local antes de confirmá-la nesse diretório. Essa revisão inclui a verificação do histórico, da complexidade, do tempo, dos filtros de senha e de qualquer outra restrição de senha que você tenha definido no AD DS.
  • Comentários de atraso zero: O write-back de senha é uma operação síncrona. Os usuários serão notificados imediatamente se suas senhas não atenderem à política ou se não puderem ser redefinidas nem alteradas por qualquer motivo.
  • Com suporte à alteração de senhas do painel de acesso e do Microsoft 365: quando usuários federados ou sincronizados com hash de senha alteram suas senhas expiradas ou não expiradas, o write-back dessas senhas é efetuado no ambiente do AD DS local.
  • Dá suporte a write-back de senha quando um administrador as redefine no centro de administração do Microsoft Entra: quandoe um administrador redefine uma senha de usuário no centro de administração do Microsoft Entra, se esse usuário for federado ou sincronizado com hash de senha, o write-back de senha será efetuado no local. Essa funcionalidade não é compatível atualmente com o Portal de Administração do Office.
  • Não exige nenhuma regra 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.
  • Dá suporte à implantação no nível do domínio lado a lado usando o Microsoft Entra Connect ou a sincronização de nuvem para direcionar diferentes conjuntos de usuários, dependendo das necessidades deles, incluindo usuários que estão em domínios desconectados.

Observação

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

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

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 domínios diferentes 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 diferentes domínios para que os usuários de um domínio possam usar o Microsoft Entra Connect enquanto 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 só 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 ou 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 qual tipo de senha o usuário tem. Se a senha do usuário for gerenciada no local:

    • Uma verificação será executada para ver se o serviço de write-back está ativo e em execução. Se estiver, o usuário poderá prosseguir.
    • Se o serviço de write-back estiver inativo, o usuário será informado de que a senha não poderá ser redefinida agora.

  2. Em seguida, o usuário passa pelas entradas de autenticação pertinentes e alcança a página de redefinição de senha.

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

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

  5. A senha criptografada é incluída em uma carga que é enviada 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). Esta retransmissão é protegida por uma senha gerada aleatoriamente que somente a 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 é automaticamente reativado e vê que há uma solicitação de redefinição pendente.

  7. O serviço procurará o usuário em questão usando o atributo de âncora de nuvem. Para essa pesquisa funcionar, as seguintes condições devem ser atendidas:

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

    Quando a chamada vem da nuvem, o mecanismo de sincronização usa o atributo cloudAnchor para procurar o objeto de espaço do conector do Microsoft Entra. Ele então segue o vínculo de volta para o objeto de MV e segue o vínculo de volta para o objeto do AD DS. Como podem existir vários objetos do AD (várias florestas) para o mesmo usuário, o mecanismo de sincronização depende do link Microsoft.InfromADUserAccountEnabled.xxx para escolher o correto.

  8. Depois que a conta do usuário é localizada, será feita uma tentativa para redefinir a senha diretamente na floresta apropriada do AD DS.

  9. Se a operação de definição de senha for realizada com êxito, o usuário será informado de que a senha foi alterada.

    Observação

    Se o hash de senha do usuário for sincronizado com o Microsoft Entra ID usando a sincronização de hash de senha, haverá uma chance de a política de senha local ser mais fraca que a política de senha na nuvem. Nesse caso, a política local é imposta. Essa política garante que a política local seja imposta na nuvem, independentemente de você usar federação ou sincronização de hash de senha para fornecer logon único.

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

    • O serviço foi desativado.
    • A senha selecionada não atendeu às políticas da organização.
    • Não é possível localizar o usuário no ambiente de AD DS local.

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

Segurança de write-back de senha

O write-back de senha é um serviço altamente seguro. Para garantir que as informações sejam protegidas, um modelo de segurança em quatro camadas é habilitado, conforme a seguir:

  • Retransmissão do barramento de serviço específica ao locatário
    • Quando você configura o serviço, é configurada uma retransmissão de barramento de serviço específica de locatário protegida por uma senha forte gerada aleatoriamente à qual a Microsoft nunca tem acesso.
  • Chave de criptografia de senha criptograficamente forte e bloqueada
    • Após a criação da retransmissão do barramento de serviço, é criada uma chave simétrica forte utilizada para criptografar a senha à medida que ela é transmitida. Essa chave existe apenas no repositório secreto de sua empresa na nuvem, que é amplamente bloqueado e auditado, assim como qualquer outra senha no diretório.
  • Segurança de camada de transporte (TLS) padrão do setor
    1. Quando ocorre uma redefinição de senha ou operação de alteração na nuvem, a senha de texto sem formatação é criptografada com a 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 recebe 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. Essa etapa é o que permite a imposição da diretiva de senha local do AD DS (como complexidade, idade, histórico e filtros) na nuvem.
  • Políticas de expiração de mensagem
    • Caso a mensagem fique no barramento de serviço devido ao serviço local estar desativado, ela atingirá o tempo limite e será removida após alguns minutos. O tempo limite e a remoção da mensagem aumenta 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 no seu ambiente local. Essas etapas de criptografia garantem a máxima segurança e confiabilidade do serviço. Elas são descritas da seguinte maneira:

  1. Criptografia de senha com chave RSA de 2048 bits: depois que um usuário envia uma senha para write back 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: todo o pacote (senha + 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 do Barramento de Serviço subjacente exiba ou viole o conteúdo.
  3. Toda a comunicação ocorre via 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. Sobreposição de chave automática a cada seis meses: todas as chaves serão substituídas a cada seis meses ou sempre que o write-back de senha for desabilitado e, em seguida, habilitado novamente no Microsoft Entra Connect, para garantir a máxima segurança e segurança do serviço.

Uso de largura de banda de write-back de senha

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

  • Duas mensagens são enviadas quando o recurso for habilitado ou desabilitado por meio do Microsoft Entra Connect.
  • Uma mensagem é enviada a cada cinco minutos como uma pulsação de 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 de autoatendimento 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 do usuário iniciada pelo administrador (somente nos portais de administração do Azure).

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

O tamanho de cada mensagem descrita 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 for solicitado por uma operação de atualização de senha, e como o tamanho da mensagem é bem pequeno, o uso da largura de banda da capacidade de write-back será efetivamente muito pequeno para ter qualquer impacto real mensurável.

Operações de write-back com suporte

É feito o write-back das senhas em todas as seguintes situações:

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

    • Qualquer operação de alteração de senha voluntária de autoatendimento do usuário final.
    • Qualquer operação para forçar o autoatendimento de alteração de senha do usuário final, 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 do administrador com suporte

    • Qualquer operação de alteração de senha voluntária de autoatendimento do administrador.
    • Qualquer operação para forçar o autoatendimento de alteração de senha do administrador, por exemplo, expiração de senha.
    • Qualquer redefinição de senha de autoatendimento do administrador originada 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 na API do Microsoft Graph.

Operações de write-back sem suporte

Não é feito o write-back das senhas em nenhuma das seguintes situações:

  • Operações do 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 do 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 no centro de administração do Microsoft 365.
    • Nenhum administrador pode usar a ferramenta de redefinição de senha para redefinir sua própria senha para write-back de senha.

Aviso

O uso da caixa de seleção “O usuário deve alterar a senha no próximo logon” em ferramentas administrativas do AD DS local como Usuários e Computadores do Active Directory ou o Centro de Administração do Active Directory tem suporte como uma versão prévia do recurso do Microsoft Entra Connect. Para obter mais informações, consulte Implementar a sincronização de senha com a sincronização do Microsoft Entra Connect.

Observação

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

Próximas etapas

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

Tutorial: Habilitar a redefinição de senha self-service (SSPR)