Compartilhar via

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

  • Artigo

Funções apropriadas: Agente administrativo | Administrador de vendas | Agente de ajuda | Administrador de cobrança | Administrador global

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 suas empresas e clientes contra roubo de identidade e acesso não autorizado, ativamos mais proteções de segurança para locatários parceiros. Estas salvaguardas obrigam e verificam a AMF. O Mandating MFA ajuda os parceiros a proteger seu acesso aos recursos do cliente contra o comprometimento de credenciais.

Este artigo fornece exemplos detalhados e orientações para a obrigatoriedade da autenticação multifator (MFA) no Partner Center.

Os parceiros que participam do programa CSP (Provedor de Soluções na Nuvem), CPVs (Fornecedores do Painel de Controle) e Consultores devem implementar os Requisitos de Segurança do Parceiro para permanecerem em conformidade.

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:

Partner Center

Algumas páginas do Partner Center são protegidas por MFA, incluindo:

  • Todas as páginas na guia Clientes (ou seja, todas as páginas com uma URL que começa com https://partner.microsoft.com/commerce/*)
  • Todas as páginas na guia Solicitações do cliente de suporte>(por exemplo, todas as páginas acessadas com uma URL que começa com )https://partner.microsoft.com/dashboard/v2/support/customers/*
  • Todas as páginas na guia Faturamento

Outras páginas no Partner Center, como a página Visão geral e a página de verificação Status de integridade do serviço, não exigem MFA.

A tabela a seguir mostra quais tipos de usuário estão autorizados a acessar essas páginas protegidas por MFA (e são afetados por esse recurso).

Páginas protegidas por MFA Agentes administrativos Agente de vendas Agentes de assistência técnica Administrador global Administrador de cobrança
Todas as páginas na guia Clientes x x x
Todas as páginas na guia Solicitações do cliente de suporte > x x
Página de faturamento x x x
Espaço de trabalho de segurança x x

Para acessar essas páginas, você deve primeiro concluir a verificação do MFA.

Opções de MFA com suporte

  • Os parceiros que usam a Microsoft oferecem suporte à autenticação multifator do Microsoft Entra. Para obter mais informações, consulte Várias maneiras de habilitar a autenticação multifator do Microsoft Entra (com suporte para MFA)
  • 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.

Importante

Os parceiros são obrigados a usar um provedor de autenticação compatível com a declaração MFA integrada do Microsoft Entra ID. A declaração integrada indica o tipo de credencial real fornecido durante a autenticação. Os parceiros são obrigados a usar MFA integrada para gerenciar locatários de clientes com GDAP.

Partner Center e APIs

Para as seguintes APIs do Partner Center, o acesso App+User e o Microsoft Entra ID Support MFA são necessários:

  • Descobrir (preço/catálogo/promoção)
  • Fazer transações e gerenciar
  • Cobrança e reconciliação
  • Gerenciar clientes usando acesso delegado/AOBO
  • Atribuição de usuário e licença (somente com DAP)
  • Atribuição de usuário e licença (com GDAP)
  • Solicitação de Relações de Administrador Granular e atribuição de acesso

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

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 parceiro da Contoso usando a autenticação multifator do Microsoft Entra.

  2. Alejandra inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não é protegida por MFA). O Partner Center redireciona Alejandra para o Microsoft Entra ID para entrar.

  3. Devido à configuração existente da autenticação multifator do Microsoft Entra pela Contoso, Alejandra é necessária para concluir a verificação de MFA. Após o login bem-sucedido 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 uma das páginas protegidas por MFA no Partner Center. Como Alejandra concluiu a verificação de MFA durante o login anteriormente, Alejandra pode acessar a página protegida por MFA sem ser obrigado a passar pela verificação de MFA novamente.

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

  1. Roberto trabalha para um CSP chamado Wingtip. A Wingtip implementou MFA para todos os seus usuários sob o locatário parceiro Wingtip usando MFA não-Microsoft, que é integrado ao Microsoft Entra ID via federação de identidades.

  2. Prashob inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não é protegida por MFA). O Partner Center redireciona Prashob para o Microsoft Entra ID para entrar.

  3. Como o Wingtip tem federação de identidade de instalação, o Microsoft Entra ID redireciona Prashob para o provedor de identidade federado para concluir a entrada e a verificação de MFA. Após a entrada bem-sucedida e a verificação de MFA, 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. Roberto tenta acessar uma das páginas protegidas por MFA no Partner Center. Como Prashob já concluiu a verificação de MFA durante o login anteriormente, ele pode acessar a página protegida de MFA sem ser obrigado a passar pela verificação de MFA novamente.

  5. Em seguida, Prashob vai para a página de gerenciamento de serviço para adicionar usuários na ID do Microsoft Entra da Contoso. Como a Prashob usou o provedor de autenticação compatível com 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 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 recomenda que eles implementem uma solução MFA compatível com o Microsoft Entra ID.

  2. John trabalha para a Fabrikam. A Fabrikam não implementou a MFA para nenhum usuário sob o locatário 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 (que não é protegida por MFA). O Partner Center redireciona John para o Microsoft Entra ID para entrar.

  4. Depois de entrar com êxito, John é redirecionado de volta para a página de visão geral do Partner Center, porque ele não concluiu a verificação de MFA.

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

  6. Em outro dia, antes que a Fabrikam implemente a MFA para qualquer usuário, John inicia uma nova sessão do navegador e vai para a página de visão geral do Partner Center (que não é protegida por MFA). O Partner Center redireciona John para o Microsoft Entra ID para entrar sem prompt de MFA.

  7. John tenta acessar uma das páginas protegidas por MFA no Partner Center. Como John não concluiu a verificação de MFA, o Partner Center redireciona John para o Microsoft Entra ID para concluir a verificação de MFA. Como John registrou MFA, desta vez ele só foi solicitado a concluir a verificação MFA.

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

  1. Trent trabalha para um CSP chamado Wingtip. A Wingtip implementou MFA para todos os seus usuários sob o locatário parceiro Wingtip usando MFA não-Microsoft 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 (que não é protegida por MFA). O Partner Center redireciona Trent para o Microsoft Entra ID para entrar.

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

Como Trent está acessando as páginas protegidas pelo MFA, ele é obrigado a apresentar o MFA com o Strong Auth para obter acesso às páginas protegidas pelo MFA.

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

Recomendamos fortemente que os Parceiros CSP implementem MFA compatível com o Microsoft Entra ID imediatamente para aumentar a linha de base de segurança do seu locatário.

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 App+User é usada, o Partner Center exige a verificação de MFA. Mais especificamente, quando um aplicativo parceiro envia uma solicitação de API ao Partner Center, ele deve incluir um token de acesso no cabeçalho de autorização da solicitação.

Observação

A estrutura do Modelo de Aplicativo Seguro é uma estrutura escalonável para autenticar parceiros CSP e CPVs por meio da arquitetura da MFA do Microsoft Azure ao chamar as APIs do Partner Center. Você deve implementar essa estrutura ao usar MFA na automação de serviços.

Quando o Partner Center recebe uma solicitação de API com um token de acesso obtido usando a autenticação App+User, a API do Partner Center verifica a presença do valor MFA na declaração AMR (Authentication Method Reference). 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": "23ec45a3-5127-4185-9eff-c8887839e6ab",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "4988e250-5aee-482a-9136-6d269cb755c0",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
  "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:03ce8ca8-8373-4021-8f25-d5dd45c7b12f
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 para aplicativos 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 parceiros devem usar privilégios de administrador delegado granular (GDAP) para gerenciar recursos do cliente por meio de portais (portal.azure.com ou admin.microsoft.com) do Microsoft Online Services), interface de linha de comando (CLI) e APIs (usando autenticação App+User). Para obter mais informações, consulte Opções de MFA com suporte.

Usar portais de serviço

Os parceiros CSP podem administrar seus clientes a partir do 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 precisarão seguir a orientação de função GDAP para obter a função GDAP de privilégios mínimos 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 do parceiro se autentique interativamente, com o locatário do cliente Microsoft Entra definido como o contexto de autenticação. A conta de parceiro é necessária para entrar no locatário do cliente.

A autenticação de ID do Microsoft Entra requer 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 de parceiro for uma identidade gerenciada , o Microsoft Entra ID solicitará diretamente que o usuário conclua a verificação de MFA. Se a conta de parceiro não tiver se registrado para MFA com o Microsoft Entra ID antes, o usuário será solicitado a concluir o registro de MFA primeiro.

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

    • Em caso afirmativo, o Microsoft Entra ID redireciona o usuário para o provedor de identidade federado para concluir a verificação de MFA.
    • Caso contrário, o Microsoft Entra ID solicita diretamente que o usuário conclua a verificação de MFA. Se a conta de parceiro não tiver se registrado para MFA com o Microsoft Entra ID 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 o 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 a verificação de MFA, incluindo agentes de administração e agentes de suporte técnico.

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 privilégios de administração delegada granular do parceiro (GDAP) para acessar o locatário do cliente.

Observação

Nem todos os portais do Microsoft Online Service exigem que as contas de parceiro entrem no locatário do cliente ao acessar os recursos do cliente usando o GDAP. Em vez disso, alguns exigem apenas que as contas de parceiro entrem no locatário parceiro. Um exemplo é o Centro de Administração do Exchange. Com o tempo, esperamos que esses portais exijam que as contas de parceiros entrem no locatário do cliente ao usar o GDAP.

Experiência de registro de MFA

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

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

Captura de tela da primeira etapa no registro do 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 no registro do MFA.

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

Problemas comuns

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

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

Um parceiro não iniciou ou ainda está no processo de implementação da MFA para os agentes do parceiro dele que precisam acessar os Portais do Microsoft Online Services usando Privilégios de Administração Delegada do Parceiro para gerenciar os 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 de MFA para seus usuários para evitar interrupções.

Observação

Mesmo que um parceiro não tenha implementado a MFA para seus agentes parceiros, os agentes parceiros ainda poderão acessar os portais do Microsoft Online Services usando os Privilégios de Administração Delegada do Parceiro se puderem concluir o registro de MFA e a verificação de MFA quando solicitados durante a entrada no locatário do cliente. Concluir o registro da MFA não habilita automaticamente o usuário para a MFA.

Problema 2: O parceiro não implementou o 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 do Microsoft Online Services para gerenciar recursos do cliente usando Privilégios de Administração Delegada 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 do Parceiro para gerenciar recursos do cliente, elas não precisarão entrar no locatário do cliente. Eles não serão afetados pelo Microsoft Entra ID que exige verificação de MFA durante a entrada no locatário 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 o MFA para contas de serviço de 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 com privilégios baixos não exigem acesso ao Partner Center nem aos Portais do Microsoft Online Services para gerenciar recursos de clientes usando Privilégios de Administração Delegada do Parceiro. Esta é uma razão válida 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 do Parceiro para gerenciar recursos do cliente, elas não precisam entrar no locatário do cliente. Eles não serão afetados pelo Microsoft Entra ID que exige verificação de MFA durante a entrada no locatário do cliente. Se a API ou o portal exigirem autenticação app+user, todos os usuários precisarão usar MFA para autenticação.

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

Um parceiro tem uma política de "mesa limpa", que não permite que os funcionários levem seus dispositivos móveis pessoais para sua á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 suportada pelos 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 no Microsoft Entra ID P1 ou P2 ou usar soluções MFA que não sejam da Microsoft compatíveis com o Microsoft Entra ID que podem fornecer mais métodos de verificação. Para saber mais, consulte Métodos de autenticação suportados.

Problema 5: O parceiro não pode implementar 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ê remova qualquer autenticação herdada e use padrões de segurança ou Acesso Condicional. Para se preparar para se afastar da autenticação herdada, revise a pasta de trabalho Entradas usando autenticação herdada e as orientações 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 uma MFA que não é da Microsoft que não é reconhecida pelo Microsoft Entra ID

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 não-Microsoft para retransmitir para o Microsoft Entra ID que a verificação 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 o ID do Entra que ofereça 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.

Recomendamos vivamente que implemente imediatamente a MFA compatível com o Microsoft Entra ID para aumentar a linha de base de segurança do seu inquilino.

Próximas etapas