Forçar o uso da MFA (autenticação multifator) para o locatário do parceiro

Funções apropriadas: Agente administrativo | Agente de vendas | Agente de helpdesk | Administrador de cobrança | Administrador de segurança

Melhor segurança e proteções contínuas de segurança e privacidade estão entre nossas principais prioridades, e continuamos a ajudar os parceiros a proteger seus clientes e locatários.

Para ajudar os parceiros a proteger seus negócios e clientes contra roubo de identidade e acesso não autorizado, ativamos mais proteções de segurança para locatários parceiros. Essas salvaguardas exigem e verificam a MFA. A obrigatoriedade da MFA ajuda os parceiros a proteger seu acesso aos recursos do cliente contra o comprometimento de credenciais.

Este artigo fornece exemplos detalhados e diretrizes para exigir a autenticação multifator (MFA) no Partner Center.

Os parceiros são obrigados a impor a MFA em todas as contas de usuário no locatário do parceiro, incluindo os usuários convidados. Os usuários devem concluir a verificação de MFA para as seguintes áreas:

• Central de Parceiros
• Partner Center API
• Administração Delegada do Parceiro

Opções de MFA com suporte

• Os parceiros que usam a Microsoft têm suporte para a autenticação multifator do Microsoft Entra. Para obter mais informações, consulte Várias maneiras de habilitar a autenticação multifator do Microsoft Entra (MFA com suporte)
• Parceiros que implementaram a autenticação federada MFA integrada. Esses usuários parceiros têm permissão para acessar o Partner Center e gerenciar os clientes usando o GDAP. Consulte os provedores de MFA integrados com ofertas de MFA disponíveis com o AD FS: Configurar métodos para o AD FS.

Partner Center e APIs

A partir de 1º de abril de 2026, todo o uso de Aplicativos+Usuário de APIs do Partner Center imporá o uso da MFA.

As seguintes opções estão disponíveis para parceiros:

• Use métodos de autenticação internos da Microsoft para atender aos requisitos de MFA.
• Se você estiver usando um provedor de identidade federado, verifique se a federação está configurada para aceitar a MFA federada.
• Se você quiser usar o ADFS para configurar o segundo fator externo, consulte os provedores de terceiros com ofertas de MFA disponíveis com o AD FS: Configurar métodos de autenticação para o AD FS
• Implementar MFA: habilite imediatamente a MFA por meio de padrões de segurança ou Acesso Condicional seguindo as diretrizes de padrões de segurança.

Para ajudar a se preparar para esse requisito, a partir de outubro de 2025, as APIs procurarão o token MFA e fornecerão a confirmação de sua presença na resposta. Para obter mais informações, consulte Validar chamadas à API integradas à MFA.

Exemplos de verificação

Para ilustrar como a verificação funciona no Partner Center, considere os exemplos a seguir.

Exemplo 1: o parceiro implementou a autenticação multifator do Microsoft Entra

1. Alejandra trabalha para um CSP chamado Contoso. A Contoso implementou a MFA para todos os seus usuários no locatário do parceiro da Contoso usando a autenticação multifator do Microsoft Entra.

2. A Alejandra inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center. O Partner Center redireciona Alejandra para a ID do Microsoft Entra para entrar.

3. Devido à configuração de autenticação multifator existente do Microsoft Entra pela Contoso, Alejandra é necessária para concluir a verificação de MFA. Após a entrada bem-sucedida e a verificação de MFA, Alejandra é redirecionada de volta para a página de visão geral do Partner Center.

4. Alejandra tenta acessar o Partner Center. Como a Alejandra concluiu a verificação de MFA durante a entrada anterior, a Alejandra pode acessar o Partner Center protegido pela MFA sem precisar passar pela verificação de MFA novamente.

Exemplo 2: o parceiro implementou o MFA que não é da Microsoft usando a federação de identidades

1. Roberto trabalha para um CSP chamado Wingtip. A Wingtip implementou a MFA para todos os seus usuários no locatário do parceiro Wingtip usando a MFA que não é da Microsoft, que é integrada à ID do Microsoft Entra por meio da federação de identidades.

2. O Prashob inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center. O Partner Center redireciona o Prashob para a ID do Microsoft Entra para entrar.

3. Como o Wingtip configurou a federação de identidades, o Microsoft Entra ID redireciona o Prashob para o provedor de identidade federado para concluir a verificação de entrada e MFA. Após a entrada bem-sucedida e a verificação de MFA, o Prashob é redirecionado de volta para a ID do Microsoft Entra e, em seguida, para a página de visão geral do Partner Center.

4. O Prashob tenta acessar o Partner Center. Como o Prashob já concluiu a verificação de MFA durante a entrada anteriormente, ele pode acessar o Partner Center sem precisar passar pela verificação de MFA novamente.

5. Em seguida, Prashob vai para a página de gerenciamento de serviços para adicionar usuários na ID do Microsoft Entra da Contoso. Como a Prashob usou o provedor de autenticação compatível com o Entra com autenticação forte, eles podem acessar o locatário do cliente sem problemas.

A recomendação para Prashob neste exemplo é usar a solução de autenticação multifator do Microsoft Entra ou um provedor de autenticação compatível com o Entra, para que eles possam gerenciar o locatário do cliente com êxito.

Exemplo 3: o parceiro não implementou a MFA

1. Uma parceira do CSP chamada Fabrikam ainda não implementou a MFA. A Microsoft exige que eles implementem uma solução de MFA compatível com a ID do Microsoft Entra.

2. John trabalha para a Fabrikam. A Fabrikam não implementou a MFA para nenhum usuário no locatário do parceiro da Fabrikam.

3. João inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center. O Partner Center redireciona John para a ID do Microsoft Entra para entrar.

4. Como John não concluiu a verificação de MFA, o Partner Center redireciona John para a ID do Microsoft Entra para concluir a verificação de MFA. Como esta é a primeira vez que John é obrigado a concluir o MFA, John também é solicitado a se registrar no MFA. Após o registro e a verificação bem-sucedidos da MFA, John pode acessar a página protegida por MFA.

5. Em outro dia, antes de a Fabrikam implementar a MFA para qualquer usuário, João iniciará uma nova sessão do navegador e irá para a página de visão geral do Partner Center. O Partner Center redireciona João para o Microsoft Entra ID para efetuar login e concluir a verificação de MFA. Como John já registrou a MFA, desta vez ele só precisa concluir a verificação MFA.

Exemplo 4: o parceiro implementou o MFA que não é da Microsoft que não é compatível com o Microsoft Entra

1. Trent trabalha para um CSP chamado Wingtip. Wingtip implementou MFA para todos os usuários no locatário de parceiro da Wingtip usando uma solução de MFA de terceiros em seu ambiente de nuvem com acesso condicional.

2. Trent inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center. O Partner Center redireciona Trent para a ID do Microsoft Entra para entrar.

3. Como o Wingtip usou uma integração não Microsoft MFA que não é compatível com a ID do Microsoft Entra e não tem uma autenticação forte, Trent será impedido de acessar o Partner Center e todas as APIs no Partner Center. Trent é obrigado a apresentar a MFA com Autenticação Forte para obter acesso às páginas protegidas por MFA.

Os parceiros são obrigados a usar um provedor de autenticação compatível com a ID do Microsoft Entra que dê suporte à declaração do método de credencial ("declaração amr" na referência de declarações de token de acesso – plataforma de identidade da Microsoft, refletindo o tipo de credencial real fornecido durante a autenticação.

API do Partner Center

A API do Partner Center dá suporte à autenticação somente de aplicativo e à autenticação de aplicativo e usuário (aplicativo + usuário).

Quando a autenticação de aplicativo+usuário é usada, o Partner Center requer a verificação de MFA. Mais especificamente, quando um aplicativo parceiro envia uma solicitação de API para o Partner Center, ele deve incluir um token de acesso no cabeçalho de autorização da solicitação.

Quando o Partner Center recebe uma solicitação de API com um token de acesso obtido usando a autenticação Aplicativo+Usuário, a API do Partner Center verifica a presença do valor de MFA na declaração AMR (Referência de Método de Autenticação). Você pode usar um decodificador JWT para validar se um token de acesso contém o valor de AMR (referência de método de autenticação) esperado ou não:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

• Se o valor estiver presente, o Partner Center concluirá que a verificação de MFA foi concluída e processará a solicitação de API.

• Se o valor não estiver presente, a API do Partner Center rejeitará a solicitação com a seguinte resposta:

  HTTP/1.1 401 Unauthorized - MFA required
  Transfer-Encoding: chunked
  Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
  WWW-Authenticate: Bearer error="invalid_token"
  Date: Thu, 14 Feb 2019 21:54:58 GMT
  

Ao chamar APIs do Partner Center, os tokens de acesso somente aplicativo só têm suporte para operações que não exigem atribuições de função GDAP em um locatário do cliente.

Para saber mais sobre as práticas recomendadas, consulte Autenticação e autorização de API – Visão geral.

Administração Delegada do Parceiro

Os locatários do parceiro devem usar GDAP (privilégios de administrador delegado) granulares para gerenciar recursos do cliente por meio de portais do Microsoft Online Services (portal.azure.com ou admin.microsoft.com), CLI (interface de linha de comando) e APIs (usando autenticação de aplicativo+usuário). Para obter mais informações, consulte Opções de MFA com suporte.

Usar portais de serviço

Os parceiros CSP podem administrar seus clientes no portal do Partner Center por meio da interface de Gerenciamento de Serviços. Os parceiros podem navegar até o cliente e selecionar Gerenciamento de serviços para poder administrar um serviço específico para o cliente. Os parceiros devem seguir as diretrizes da função GDAP para obter a função GDAP de privilégios mínimos correta para gerenciar seus clientes.

Ao acessar portais do Microsoft Online Services usando privilégios de administrador delegado de parceiro (Admin-On-Behalf-Of) para gerenciar recursos do cliente, muitos desses portais exigem que a conta de parceiro seja autenticada interativamente, com o locatário do Microsoft Entra do cliente definido como o contexto de autenticação. A conta do parceiro é necessária para entrar no locatário do cliente.

A autenticação de ID do Microsoft Entra exige que um usuário conclua a verificação de MFA se houver uma política que exija MFA. Há duas experiências de usuário possíveis, dependendo se a conta do parceiro é uma identidade gerenciada ou federada:

• Se a conta do parceiro for uma identidade gerenciada , a ID do Microsoft Entra solicitará diretamente que o usuário conclua a verificação de MFA. Se a conta do parceiro não tiver se registrado para MFA com a ID do Microsoft Entra antes, o usuário será solicitado a concluir o registro de MFA primeiro.

• Se a conta do parceiro for uma identidade federada , a experiência dependerá de como o administrador do parceiro configurou a federação na ID do Microsoft Entra. Ao configurar a federação na ID do Microsoft Entra, o administrador do parceiro pode indicar à ID do Microsoft Entra se o provedor de identidade federado dá suporte à MFA ou não.

  • Nesse caso, a ID do Microsoft Entra redireciona o usuário para o provedor de identidade federado para concluir a verificação de MFA.
  • Caso contrário, a ID do Microsoft Entra solicitará diretamente que o usuário conclua a verificação de MFA. Se a conta do parceiro não tiver se registrado para MFA com a ID do Microsoft Entra antes, o usuário será solicitado a concluir o registro de MFA primeiro.

A experiência geral é como o cenário em que um locatário do cliente final implementou a MFA para seus administradores. Por exemplo, o locatário do cliente habilitou os padrões de segurança do Microsoft Entra, o que exige que todas as contas com direitos administrativos entrem no locatário do cliente com verificação de MFA, incluindo agentes administrativos e agentes de assistência técnica.

Para fins de teste, os parceiros podem habilitar os padrões de segurança do Microsoft Entra no locatário do cliente e, em seguida, tentar usar os GDAP (Privilégios de Administração Delegada Granular do Parceiro) para acessar o locatário do cliente.

Experiência de registro de MFA

Durante a verificação de MFA, se a conta do parceiro não tiver sido registrada para MFA antes, a ID do Microsoft Entra solicitará que o usuário conclua o registro de MFA primeiro.

Examine mais informações sobre o método Microsoft Authenticator:

Captura de tela da primeira etapa do registro de MFA.

Depois que o usuário seleciona Avançar, ele é solicitado a escolher em uma lista de métodos de verificação.

Captura de tela da segunda etapa do registro do MFA.

Após o registro bem-sucedido, o usuário deve concluir a verificação de MFA usando o método de verificação escolhido.

Problemas comuns

Para entender se sua solicitação é válida, revise a lista de problemas comuns relatados por outros parceiros.

Problema 1: O parceiro precisa de mais tempo para implementar a MFA para seus agentes parceiros

Um parceiro ainda não começou ou ainda está no processo de implementar a Autenticação Multifator (AMF) para seus agentes parceiros que exigem acesso aos Portais de Serviços Online da Microsoft usando privilégios delegados granulares de administração do parceiro para gerenciar recursos do cliente. O parceiro precisa de mais tempo para concluir a implementação da MFA. Esse é um motivo válido para exceção técnica?

Resposta: Não. Um parceiro precisa planejar a implementação da MFA para seus usuários para evitar interrupções.

Problema 2: o parceiro não implementou a MFA porque não precisa de acesso para gerenciar clientes

Um parceiro tem alguns usuários em seus locatários parceiros que não exigem acesso aos Portais dos Serviços Online da Microsoft para gerenciar recursos do cliente usando privilégios de administração delegada granular do parceiro. O parceiro está no processo de implementação da MFA para esses usuários e precisa de mais tempo para concluí-lo. Esse é um motivo válido para exceção técnica?

Resposta: Não. Como essas contas de usuário não estão usando privilégios de administração delegada granular do parceiro para gerenciar recursos do cliente, os usuários não precisarão entrar no tenant do cliente. Todos os usuários precisam ter MFA acessando o Partner Center ou as cargas de trabalho do cliente para gerenciar os recursos do cliente.

Problema 3: o parceiro não implementou a MFA para contas de serviço do usuário

Um parceiro tem algumas contas de usuário nos locatários parceiros dele, que estão sendo usadas por dispositivos como contas de serviço. Essas contas de baixo privilégio não exigem acesso ao Partner Center nem aos Portais de Serviços Online da Microsoft para gerenciar recursos do cliente usando privilégios de administração delegada granular do parceiro. Este é um motivo válido para uma exceção técnica?

Resposta: Não. Como essas contas de usuário não estão usando Privilégios de Administração Delegada Granular do Parceiro para gerenciar recursos do cliente, não é necessário que elas façam login no espaço do cliente. Se a API ou o portal exigisse autenticação de aplicativo+usuário, todos os usuários precisariam usar a MFA para autenticação.

Problema 4: o parceiro não pode implementar a MFA usando o aplicativo Microsoft Authenticator

Um parceiro tem uma política de "mesa limpa", que não permite que os funcionários tragam seus dispositivos móveis pessoais para a área de trabalho. Sem acesso a seus dispositivos móveis pessoais, os funcionários não podem instalar o aplicativo Microsoft Authenticator, que é a única verificação de MFA compatível com os padrões de segurança do Microsoft Entra. Esse é um motivo válido para exceção técnica?

Resposta: Não. O parceiro deve considerar a seguinte alternativa para que seus funcionários ainda possam concluir a verificação de MFA ao acessar o Partner Center:

• O parceiro também pode se inscrever na ID P1 ou P2 do Microsoft Entra ou usar soluções que não sejam do Microsoft MFA compatíveis com a ID do Microsoft Entra que podem fornecer mais métodos de verificação. Para saber mais, consulte Métodos de autenticação com suporte.

Problema 5: o parceiro não pode implementar a MFA devido ao uso de protocolos de autenticação herdados

Um parceiro tem alguns agentes do parceiro que ainda estão usando protocolos de autenticação herdados, que não são compatíveis com MFA. Por exemplo, os usuários ainda estão usando o Outlook 2010, que é baseado em protocolos de autenticação herdados. Habilitar a MFA para esses agentes do parceiro interromperá o uso de protocolos de autenticação herdados. Esse é um motivo válido para exceção técnica?

Resposta: Não. Os parceiros são incentivados a se afastar do uso de protocolos de autenticação herdados devido a possíveis implicações de segurança, pois esses protocolos não podem ser protegidos com a verificação de MFA e são muito mais suscetíveis ao comprometimento de credenciais. Recomendamos que você substitua qualquer autenticação herdada e use padrões de segurança ou Acesso Condicional. Para se preparar para se afastar da autenticação herdada, examine a pasta de trabalho Entradas usando autenticação herdada e as diretrizes sobre como bloquear a autenticação herdada.

Para entender o plano mais recente de suporte à autenticação herdada para o Outlook, leia a postagem sobre a Autenticação Básica e o Exchange Online e siga o blog da equipe do Exchange para obter as próximas notícias.

Problema 6: o parceiro implementou um MFA que não é da Microsoft que não é reconhecido pela ID do Microsoft Entra

Um parceiro implementou a MFA para seus usuários usando uma solução MFA que não seja da Microsoft. No entanto, o parceiro não consegue configurar corretamente a solução MFA que não é da Microsoft para retransmitir para a ID do Microsoft Entra que a verificação de MFA foi concluída durante a autenticação do usuário. Esse é um motivo válido para exceção técnica?

Resposta: Não, os parceiros são obrigados a usar um provedor de autenticação compatível com a ID do Microsoft Entra que dê suporte à declaração de método de credencial ("AMR"), referência de declarações de token de acesso - plataforma de identidade da Microsoft, refletindo o tipo de credencial real fornecido durante a autenticação.

Exigimos que os parceiros implementem uma solução de MFA compatível com a ID do Microsoft Entra para evitar interrupções.

Conteúdo relacionado

• Status dos requisitos de segurança do parceiro