Perguntas frequentes sobre GDAP

Alguém com a função agente administrador em uma organização parceira pode criar uma solicitação de relação GDAP.

Sim. As solicitações de relação GDAP expiram após 90 dias.

Não. Relações GDAP permanentes com clientes não são possíveis por motivos de segurança. A duração máxima de uma relação GDAP é de dois anos. Você pode definir estender automaticamente para Habilitado para estender uma relação de administrador por seis meses, até que a extensão finalizada ou automática seja definida como Desabilitado.

Não. A relação GDAP não dá suporte a assinaturas compradas por meio de contratos empresariais.

Sim. Uma relação GDAP pode se estender automaticamente por seis meses até terminar ou estender automaticamente definido como Desabilitado.

• Se a relação GDAP com o cliente expirar, solicitar uma relação GDAP novamente.
• Você pode usar análise de relação GDAP para acompanhar as datas de expiração da relação GDAP e se preparar para a renovação.

Para estender ou renovar uma relação GDAP, um parceiro ou cliente deve definir estender automaticamente para Habilitado. Saiba mais em Gerenciar de extensão do GDAP Auto e de API.

Sim. Se o GDAP estiver ativo, ele poderá ser estendido.

Digamos que um GDAP seja criado por 365 dias com a extensão automática definida como Habilitada. No 365º dia, a Data de Término é atualizada efetivamente por 180 dias.

Sim. Você pode estender automaticamente qualquer GDAP ativo.

Não. O consentimento do cliente não é necessário para definir a extensão automática para Habilitada em relação a um GDAP ativo existente.

Não. As permissões granulares atribuídas a grupos de segurança continuam as-is.

Não. Você não pode estender automaticamente a relação de administrador com uma função de Administrador Global.

A página Relações Granulares Expirando só está disponível para usuários parceiros com as funções Administradores Globais e Agente de Administração. Esta página ajuda a filtrar GDAPs que expiram em diferentes linhas do tempo e ajuda a atualizar a extensão automática (habilitar/desabilitar) para um ou mais GDAPs.

Não. Não há nenhuma alteração nas assinaturas existentes de um cliente quando uma relação GDAP expira.

Consulte Solucionar problemas de autenticação multifator do Microsoft Entra e Não é possível usar a autenticação multifator do Microsoft Entra para entrar nos serviços de nuvem depois que você perder o telefone ou o número de telefone mudar para obter diretrizes.

Um parceiro deve solicitar o administrador de autenticação do Privileged função do Microsoft Entra ao criar o primeiro GDAP.

• Essa função permite que um parceiro redefina uma senha e o método de autenticação para um usuário administrador ou não administrador. A função de administrador de autenticação com privilégios faz parte das funções configuradas pela Ferramenta Liderada pela Microsoft e está planejada para estar disponível com GDAP Padrão durante o fluxo Criar Cliente (planejado para setembro).
• O parceiro pode fazer com que o administrador do cliente tente Redefinir a senha.
• Por precaução, o parceiro deve configurar a SSPR (redefinição de senha de autoatendimento) para seus clientes. Para obter mais informações, consulte Permitir que as pessoas redefinam suas próprias senhas.

• Em uma organização de parceiros, as pessoas com a função agente administrador do recebem uma notificação de encerramento.
• Em uma organização de de clientes, as pessoas com a função de administrador global recebem uma notificação de encerramento.

Sim. Os parceiros podem ver quando um cliente remove o GDAP nos logs de atividades do Partner Center.

Não. O GDAP é uma funcionalidade opcional para parceiros que desejam gerenciar os serviços de seus clientes de maneira mais granular e associada ao tempo. Você pode escolher com quais clientes deseja criar uma relação GDAP.

A resposta depende de como você deseja gerenciar seus clientes.

• Se quiser que os usuários parceiros possam gerenciar todos os clientes, você pode colocar todos os usuários parceiros em um grupo de segurança e que um grupo pode gerenciar todos os seus clientes.
• Se você preferir ter vários usuários parceiros gerenciando vários clientes, atribua esses usuários parceiros a grupos de segurança separados para isolamento do cliente.

Sim. Revendedores indiretos (provedores indiretos e parceiros de cobrança direta) podem criar solicitações de relação GDAP no Partner Center.

Como parte da configuração do GDAP, verifique se os grupos de segurança criados no locatário do parceiro com usuários parceiros estão selecionados. Verifique também se as funções desejadas do Microsoft Entra são atribuídas ao grupo de segurança. Consulte Atribuir funções do Microsoft Entra.

Os clientes agora podem excluir CSPs da política de acesso condicional para que os parceiros possam fazer a transição para GDAP sem serem bloqueados.

• Incluir usuários – essa lista de usuários normalmente inclui todos os usuários que uma organização está direcionando em uma política de Acesso Condicional.
• As seguintes opções estão disponíveis para incluir ao criar uma política de Acesso Condicional:
• Selecionar usuários e grupos
• Usuários convidados ou externos (versão prévia)
• Essa seleção fornece várias opções que podem ser usadas para direcionar políticas de Acesso Condicional para tipos de usuários convidados ou externos específicos e locatários específicos que contêm esses tipos de usuários. Há vários tipos diferentes de usuários convidados ou externos que podem ser selecionados e várias seleções podem ser feitas:
• Usuários do provedor de serviços, por exemplo, um CSP (Provedor de Soluções na Nuvem).
• Você pode especificar um ou mais locatários para os tipos de usuário selecionados ou especificar todos os locatários.
• de acesso de parceiro externo – políticas de acesso condicional direcionadas a usuários externos podem interferir no acesso do provedor de serviços, por exemplo, privilégios de administrador delegado granulares. Para obter mais informações, consulte Introdução aos privilégios de administrador delegado granular (GDAP). Para políticas destinadas a locatários de provedor de serviços de destino, use o usuário do provedor de serviços tipo de usuário externo disponível no Usuários convidados ou externos opções de seleção.
• Excluir usuários – quando as organizações incluem e excluem um usuário ou grupo, o usuário ou grupo é excluído da política, pois uma ação de exclusão substitui uma ação de inclusão na política.
• As seguintes opções estão disponíveis para exclusão ao criar uma política de Acesso Condicional:
• Usuários convidados ou externos
• Essa seleção fornece várias opções que podem ser usadas para direcionar políticas de Acesso Condicional para tipos de usuários convidados ou externos específicos e locatários específicos que contêm esses tipos de usuários. Há vários tipos diferentes de usuários convidados ou externos que podem ser selecionadose várias seleções podem ser feitas:
• Usuários do provedor de serviços, por exemplo, um CSP (Provedor de Soluções na Nuvem)
• Um ou mais locatários podem ser especificados para os tipos de usuário selecionados ou você pode especificar todos os locatários. Para obter mais informações, consulte:
• Experiência de API do Graph: API Beta com as novas informações de tipo de usuário externo
• política de acesso condicional
• acesso condicional de usuários externos

Sim. Independentemente do plano de suporte que você tem, a função menos privilegiada para os usuários parceiros poderem criar tíquetes de suporte para o cliente é o administrador de suporte do Serviço.

Não. No momento, o parceiro não pode encerrar um GDAP em status de pendente de aprovação. Ele expiraria em 90 dias se o cliente não tomasse nenhuma ação.

Somente após 365 dias (limpeza) após o término ou expiração da relação GDAP, você poderá reutilizar o mesmo nome para criar uma nova relação GDAP.

Sim. Um parceiro pode gerenciar seus clientes entre regiões sem criar novos locatários de parceiro por região do cliente. Ela é aplicável somente à função de gerenciamento de clientes fornecida pelo GDAP (Relações de Administração). A função e os recursos de transação ainda estão limitados ao de território autorizado.

Não. Um provedor de serviços não pode fazer parte da organização multilocatário, ele é mutuamente exclusivo.

1. Verifique se o GDAP está configurado corretamente, incluindo como você concede permissões para grupos de segurança.
2. Verifique se as permissões granulares do grupo de segurança estão corretas.
3. Consulte as perguntas frequentes do Security Copilot para obter ajuda.

Para obter mais informações sobre APIs e GDAP, consulte a documentação do desenvolvedor do Partner Center.

Sim. Recomendamos que os parceiros usem as APIs beta GDAP para produção e, posteriormente, mudem para APIs v.1 quando estiverem disponíveis. Embora haja um aviso: "Não há suporte para o uso dessas APIs em aplicativos de produção", essa orientação genérica é para qualquer API beta no Graph e não é aplicável às APIs beta do GDAP Graph.

Sim. Você pode criar relações GDAP usando APIs, o que permite aos parceiros dimensionar esse processo. Mas a criação de várias relações GDAP não está disponível no Partner Center. Para obter informações sobre APIs e GDAP, consulte a documentação do desenvolvedor do Partner Center.

A API funciona para um grupo de segurança por vez, mas você pode mapear vários grupos de segurança para várias funções no Partner Center.

Faça chamadas individuais para cada recurso. Ao fazer uma única solicitação POST, passe apenas um recurso e seus escopos correspondentes. Por exemplo, para solicitar permissões para https://graph.windows.net/Directory.AccessAsUser.All e https://graph.microsoft.com/Organization.Read.All, faça duas solicitações diferentes, uma para cada.

Use o link fornecido para pesquisar o nome do recurso: Verificar aplicativos da Microsoft de primeira parte em relatórios de entrada –do Active Directory. Por exemplo, para localizar a ID do Recurso 000000003-0000-0000-c0000-000000000000000 para graph.microsoft.com:

Esse erro geralmente ocorre quando um identificador incorreto é usado no filtro de consulta. Para resolvê-lo, verifique se você está usando a propriedade enterpriseApplicationId com a ID de recurso correta, não o nome do recurso.

• solicitação incorreta For enterpriseApplicationId, não use um nome de recurso como graph.microsoft.com.
• solicitação correta Em vez disso, para enterpriseApplicationId, use a ID do recurso, como 00000003-0000-0000-c0000-0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Por exemplo, no início do graph.microsoft.com recurso, somente o escopo "perfil" foi consentido. Agora, precisamos adicionar perfil e user.read também. Para adicionar novos escopos a um aplicativo consentido anteriormente:

1. Use o método DELETE para revogar o consentimento do aplicativo existente do locatário do cliente.
2. Use o método POST para criar o consentimento do aplicativo com os escopos extras.

Concatene os escopos necessários usando uma vírgula seguida por um espaço. Por exemplo, "escopo": "profile, User.Read"

1. Confirme se as propriedades 'displayName' e 'applicationId' no corpo da solicitação são precisas e correspondem ao aplicativo que você está tentando consentir no locatário do cliente.
2. Verifique se você está usando o mesmo aplicativo para gerar o token de acesso que está tentando consentir no locatário do cliente. Por exemplo: se a ID do aplicativo for "12341234-1234-1234-12341234", a declaração "appId" no token de acesso também deverá ser "12341234-1234-1234-12341234".
3. Verifique se uma das seguintes condições foi atendida:

• Você tem um DAP (Privilégio de Administrador Delegado) ativo e o usuário também é membro do grupo segurança de agentes administradores no locatário do parceiro.
• Você tem uma relação GDAP (Privilégio de Administrador Delegado Granular) ativa com o locatário do Cliente com pelo menos uma das três funções GDAP a seguir e concluiu a Atribuição de Acesso:
  • Função administrador global, administrador de aplicativos ou administrador de aplicativos na nuvem.
  • O usuário parceiro é membro do Grupo de Segurança especificado na Atribuição de Acesso.

• Para gerenciar o Azure com particionamento de acesso por cliente (que é a melhor prática recomendada), crie um grupo de segurança (como do Azure Managers) e aninhar em agentes administradores.
• Para acessar uma assinatura do Azure como proprietário de um cliente, você pode atribuir qualquer de função interna do Microsoft Entra (como leitores do Directory, a função menos privilegiada) ao grupo de segurança Azure Managers. Para obter as etapas para configurar o GDAP do Azure, consulte cargas de trabalho com suporte por GDAP (privilégios de administrador delegado granulares).

Sim. Para obter informações sobre como restringir as permissões de administrador de um usuário atribuindo funções menos privilegiadas no Microsoft Entra, consulte funções com privilégios mínimos por tarefa no Microsoft Entra.

É recomendável atribuir a função de de administrador de suporte do Serviço . Para saber mais, consulte funções com privilégios mínimos por tarefa no Microsoft Entra.

• Para reduzir a lacuna entre as funções do Microsoft Entra disponíveis na API do Partner Center versus na interface do usuário, uma lista de nove funções está disponível na interface do usuário do Partner Center em julho de 2024.
• Em Colaboração:
  • Administrador do Microsoft Edge
  • Administrador de Visitas Virtuais
  • Administrador de Metas do Viva
  • Administrador do Viva Pulse
  • Administrador do Yammer
• Em Identidade:
  • Administrador de Gerenciamento de Permissões
  • Administrador de fluxos de trabalho do ciclo de vida
• Em Outros:
  • Administrador de identidade visual organizacional
  • Aprovador de Mensagens Organizacionais

Não. A função menos privilegiada para os usuários parceiros poderem criar tíquetes de suporte para o cliente é o administrador de suporte do serviço . Portanto, para poder criar tíquetes de suporte para o cliente, um usuário parceiro deve estar em um grupo de segurança e atribuído a esse cliente com essa função.

Para obter informações sobre todas as funções, consulte funções internas do Microsoft Entra. Para obter informações sobre cargas de trabalho, consulte cargas de trabalho com suporte por GDAP (privilégios de administrador delegado granulares).

Muitas funções são usadas para o Centro de Administração do Microsoft 365. Para obter mais informações, consulte funções de centro de administração do Microsoft 365 comumente usadas.

Sim. Crie um grupo de segurança, atribua funções aprovadas e atribua usuários de locatários parceiros a esse grupo de segurança.

O acesso somente leitura às assinaturas do cliente é fornecido pelo de leitor global, de leitores do Diretório e funções de de suporte do Parceiro 2.

Recomendamos que você remova os agentes parceiros da função agente administrador do e adicione-os apenas a um grupo de segurança GDAP. Dessa forma, eles podem administrar serviços (gerenciamento de serviço e solicitações de serviço de log, por exemplo), mas não podem comprar e gerenciar assinaturas (alterar quantidade, cancelar, agendar alterações e assim por diante).

Os grupos de segurança atribuídos à relação perdem o acesso a esse cliente. A mesma coisa acontece se um cliente termina uma relação DAP.

Sim. A remoção das relações GDAP com um cliente não encerra a relação de revendedor dos parceiros com o cliente. Os parceiros ainda podem comprar produtos para o cliente e gerenciar o orçamento do Azure e outras atividades relacionadas.

Não. Todas as funções em uma relação GDAP têm o mesmo tempo de expiração: a duração escolhida quando a relação foi criada.

Não. Você não precisa de GDAP para atender aos pedidos de clientes novos e existentes. Você pode continuar a usar o mesmo processo para atender aos pedidos de clientes no Partner Center.

As relações GDAP são por cliente. Você pode ter vários relacionamentos por cliente. Cada relação GDAP pode ter funções diferentes e usar diferentes grupos do Microsoft Entra em seu Locatário CSP. No Partner Center, a atribuição de função funciona no nível de relação cliente a GDAP. Se você quiser atribuir funções multicustomer, você pode automatizar o uso de APIs.

Os administradores convidados do GDAP não conseguem gerenciar suas próprias informações de segurança no My Security-Info. Em vez disso, eles precisam da assistência do administrador do locatário em que são convidados para qualquer registro, atualização ou exclusão de informações de segurança. As organizações podem configurar políticas de acesso entre locatários para confiar na MFA do locatário CSP confiável. Caso contrário, os administradores convidados do GDAP são limitados apenas a métodos registráveis pelo administrador de locatários (que é SMS ou Voz). Para saber mais, consulte políticas de acesso entre locatários.

Alinhe-se ao princípio de orientação da Confiança Zero: use o acesso de privilégio mínimo:

• É recomendável usar uma função menos privilegiada por tarefas de tarefa e carga de trabalho cargas de trabalho com suporte por GDAP (privilégios de administrador delegado granular) com suporte do GDAP.
• Quando for necessário contornar problemas conhecidos listados, trabalhe com o cliente para solicitar uma função de Administrador Global associada ao tempo.
• Não recomendamos substituir a função de Administrador Global por todas as funções possíveis do Microsoft Entra.

Sim. Durante o período de transição, o DAP e o GDAP coexistirão, com as permissões GDAP tendo precedência sobre as permissões da DAP para o Microsoft 365, Dynamics 365e cargas de trabalho do Azure.

DAP e GDAP coexistem durante o período de transição. No entanto, eventualmente, o GDAP está substituindo o DAP para garantir que forneçamos uma solução mais segura para nossos parceiros e clientes. Recomendamos que você faça a transição de seus clientes para o GDAP o mais rápido possível para garantir a continuidade.

Não há alterações no fluxo de relação DAP existente enquanto DAP e GDAP coexistem.

No momento, o DAP é concedido quando um novo locatário do cliente é criado. Em 25 de setembro de 2023, a Microsoft não concede mais DAP para criação de novos clientes e, em vez disso, concede GDAP Padrão com funções específicas. As funções padrão variam de acordo com o tipo de parceiro, conforme mostrado na tabela a seguir:

Os parceiros podem implementar do PIM (Privileged Identity Management) em um grupo de segurança GDAP no locatário do parceiro para elevar o acesso de alguns usuários de alto privilégio, just-in-time (JIT) para conceder a eles funções de alto privilégio, como administradores de senha com remoção automática de acesso. Até de janeiro de 2023, era necessário que cada do Grupo de Acesso Privilegiado (nome antigo do recurso pim para grupos ) tivesse que estar em um grupo de atribuível à função . Essa restrição agora é removida. Dada essa alteração, é possível habilitar mais de 500 grupos por de locatário nodo PIM, mas apenas até 500 grupos podem ser atribuíveis à função. Resumo:

• Os parceiros podem usar atribuíveis a função e grupos de não atribuíveis a função no PIM. Essa opção efetivamente remove o limite de 500 grupos/locatário no PIM.
• Com as atualizações mais recentes, há duas maneiras de integrar grupo ao PIM (UX-wise): no menu pim ou no menu grupos de . Independentemente da maneira que você escolher, o resultado líquido é o mesmo.
  • A capacidade de integrar grupos atribuíveis a função/não atribuíveis por função por meio do menu PIM já está disponível.
  • A capacidade de integrar grupos atribuíveis a função/não atribuíveis por função por meio do menu Grupos já está disponível.
• Para obter mais informações, consulte PIM (Privileged Identity Management) para Grupos (versão prévia) – Microsoft Entra.

O GDAP geralmente está disponível com suporte para todos os serviços de nuvem comerciais da Microsoft (Microsoft 365, Dynamics 365, Microsoft Azuree cargas de trabalho do Microsoft Power Platform). Para obter mais informações sobre como o DAP e o GDAP podem coexistir e como o GDAP tem precedência, pesquise estas perguntas frequentes sobre o Como as permissões GDAP têm precedência sobre permissões DAP enquanto DAP e GDAP coexistem? pergunta.

Você pode executar essa ação com APIs.

Não. Os ganhos do PEC não são afetados quando você faz a transição para o GDAP. Não há alterações no PAL com a transição, garantindo que você continue a ganhar PEC.

• Se o cliente de um parceiro tiver apenas DAP e DAP for removido, o PEC não será perdido.
• Se o cliente de um parceiro tiver DAP e passar para o GDAP para Microsoft 365 e Azure simultaneamente, e o DAP for removido, o PEC não será perdido.
• Se o cliente do parceiro tiver DAP e ele mudar para o GDAP para Microsoft 365, mas manter o Azure as-is (eles não se movem para o GDAP) e o DAP for removido, o PEC não será perdido, mas o acesso à assinatura do Azure será perdido.
• Se uma função RBAC for removida, o PEC será perdido, mas a remoção do GDAP não removerá o RBAC.

Quando o usuário faz parte do grupo de segurança GDAP e do grupo de agentes administradores do DAP e o cliente tem relações DAP e GDAP, o acesso GDAP tem precedência no nível de parceiro, cliente e carga de trabalho.

Por exemplo, se um usuário parceiro entrar para uma carga de trabalho e houver DAP para a função de administrador global e GDAP para a função de leitor global, o usuário parceiro só obterá permissões de leitor global.

Se houver três clientes com atribuições de funções GDAP apenas para o grupo de segurança GDAP (não agentes administradores):

A tabela a seguir descreve o que acontece quando um usuário entra em um locatário de cliente diferente.

DAP e GDAP não são tipos de associação qualificados para designações do Parceiro de Soluções. aDisabling ou transição de DAP para GDAP não afeta sua obtenção de designações de Parceiro de Soluções. Além disso, a renovação de benefícios de competência herdada ou benefícios do Parceiro de Soluções não é afetada. Para exibir os outros tipos de associação de parceiros qualificados para designação do Parceiro de Soluções, consulte designações de parceiros do Partner Center Solutions.

Em relação à relação entre o Azure Lighthouse e o DAP/GDAP, considere-os como caminhos paralelos separados para recursos do Azure. Cortar um não deve afetar o outro.

• No cenário do Azure Lighthouse, os usuários do locatário do parceiro nunca fazem logon no locatário do cliente e não têm nenhuma permissão do Microsoft Entra no locatário do cliente. Suas atribuições de função RBAC do Azure também são mantidas no locatário do parceiro.
• No cenário GDAP, os usuários da entrada do locatário do parceiro para o locatário do cliente. A atribuição de função RBAC do Azure para o grupo de agentes administradores também está no locatário do cliente. Você pode bloquear o caminho GDAP (os usuários não podem mais entrar) enquanto o caminho do Azure Lighthouse não é afetado. Por outro lado, você pode cortar a relação do Lighthouse (projeção) sem afetar o GDAP. Para obter mais informações, consulte a documentação do Azure Lighthouse.

Os MSPs (Provedores de Serviços Gerenciados) registrados no programa CSP (Provedor de Soluções na Nuvem) como revendedores indiretos ou cobrança direta parceiros agora podem usar o Microsoft 365 Lighthouse para configurar o GDAP para qualquer locatário do cliente. Como já existem algumas maneiras de os parceiros gerenciarem sua transição para o GDAP, esse assistente permite que os parceiros do Lighthouse adotem recomendações de função específicas às suas necessidades comerciais. Ele também permite que eles adotem medidas de segurança, como acesso just-in-time (JIT). Os MSPs também podem criar modelos GDAP por meio do Lighthouse para salvar e reaplicar facilmente as configurações que permitem acesso ao cliente com privilégios mínimos. Para obter mais informações e exibir uma demonstração, consulte o assistente de instalação do Lighthouse GDAP. Os MSPs podem configurar o GDAP para qualquer locatário do cliente no Lighthouse. Para acessar os dados de carga de trabalho do cliente no Lighthouse, é necessária uma relação GDAP ou DAP. Se o GDAP e o DAP coexistirem em um locatário do cliente, as permissões GDAP têm precedência para técnicos msp em grupos de segurança habilitados para GDAP. Para obter mais informações sobre os requisitos do Microsoft 365 Lighthouse, consulte Requirements for Microsoft 365 Lighthouse.

A sequência correta a seguir para este cenário é:

1. Crie uma relação GDAP para Microsoft 365 e Azure.
2. Atribuir funções do Microsoft Entra a grupos de segurança para Microsoft 365 e ado Azure.
3. Configure o GDAP para ter precedência sobre o DAP.
4. Remova o DAP.

A sequência a seguir pode resultar em perda de acesso para assinaturas do Azure:

1. Remova o DAP. Você não necessariamente perde o acesso a uma assinatura do Azure removendo o DAP. Mas, neste momento, você não pode procurar o diretório do cliente para fazer atribuições de função RBAC do Azure (como atribuir um novo usuário do cliente como colaborador do RBAC da assinatura).
2. Crie uma relação GDAP para Microsoft 365 e Azure juntos. Você pode perder o acesso à assinatura do Azure nesta etapa assim que o GDAP for configurado.
3. Atribuir funções do Microsoft Entra a grupos de segurança para Microsoft 365 e Azure

Você recupera o acesso às assinaturas do Azure após a conclusão da instalação do GDAP do Azure.

Se você tiver assinaturas do Azure sem o DAP que gerencia como proprietário, ao adicionar o GDAP para Microsoft 365 a esse cliente, poderá perder o acesso às assinaturas do Azure. Para evitar o acesso perdido, mova o cliente para o GDAP do Azure ao mesmo tempo que você mova o cliente para o Microsoft 365 GDAP.

Não. Relacionamentos, uma vez aceitos, não são reutilizáveis.

Se você tiver uma relação de revendedor existente com o cliente, ainda precisará estabelecer uma relação GDAP para gerenciar suas assinaturas do Azure.

1. Crie um grupo de segurança (por exemplo, Azure Managers) no Microsoft Entra.
2. Crie uma relação GDAP com a função de de leitor de diretório .
3. Torne o grupo de segurança um membro do grupo de agente de administração do . Depois de executar essas etapas, você poderá gerenciar a assinatura do Azure do cliente por meio do AOBO. Você não pode gerenciar a assinatura por meio da CLI/Powershell.

Sim. Você pode criar um plano do Azure mesmo que não haja DAP ou GDAP com uma relação de revendedor existente. Mas, para gerenciar essa assinatura, você precisa de DAP ou GDAP.

À medida que os parceiros fazem a transição do DAP para o GDAP, eles devem garantir que o seguinte esteja em vigor para ver os detalhes da empresa:

• Uma relação GDAP ativa.
• Qualquer uma das seguintes funções do Microsoft Entra é atribuída: Administrador Global, Leitores de Diretório, Leitor Global. Consulte conceder permissões granulares a grupos de segurança.

Quando um CSP faz logon no portal do Azure do cliente (portal.azure.come) usando suas credenciais de CSP e existe uma relação GDAP, o CSP percebe que seu nome de usuário é "user_" seguido por algum número. Ele não exibe seu nome de usuário real como no DAP. É por design.

Os parceiros devem explicitamente conceder permissões granulares a grupos de segurança no GDAP Padrão.
A partir de 10 de outubro de 2023, o DAP não está mais disponível com relações de revendedor. O link de Relação do Revendedor de Solicitação atualizado está disponível na interface do usuário do Partner Center e a URL da propriedade "/v1/customers/relationship requests" do contrato de API retorna a URL de convite a ser enviada ao administrador do locatário do cliente.

Sim, os parceiros devem explicitamente conceder permissões granulares a grupos de segurança no GDAP Padrão para gerenciar o cliente.

Parceiros com relação de revendedor somente sem DAP ou GDAP podem criar clientes, fazer e gerenciar pedidos, baixar chaves de software, gerenciar a RI do Azure. Eles não podem exibir os detalhes da empresa do cliente, não podem exibir usuários ou atribuir licenças aos usuários, não podem registrar tíquetes em nome dos clientes e não podem acessar e administrar centros de administração específicos do produto (por exemplo, centro de administração do Teams).)

Para que um parceiro ou CPV acesse e gerencie um locatário do cliente, a entidade de serviço do aplicativo deve ser consentida no locatário do cliente. Quando o DAP estiver ativo, eles deverão adicionar a entidade de serviço do aplicativo ao SG de Agentes administradores no locatário do parceiro. Com o GDAP, o parceiro deve garantir que seu aplicativo seja consentido no locatário do cliente. Se o aplicativo usar permissões delegadas (Aplicativo + Usuário) e um GDAP ativo existir com qualquer uma das três funções (Administrador de Aplicativos de Nuvem, Administrador de Aplicativos, Administrador Global) a API de consentimento poderá ser usada. Se o aplicativo usa permissões somente de aplicativo, ele deve ser consentido manualmente, seja pelo parceiro ou pelo cliente que tenha qualquer uma das três funções (Administrador de Aplicativos na Nuvem, Administrador de Aplicativos, Administrador Global), usando URL de consentimento do administrador em todo o locatário.

Se você vir o seguinte erro:

"Não é possível validar sua solicitação 'Criar nova relação GDAP' no momento. Lembre-se de que conexões anônimas não são permitidas para esse serviço. Se você acredita que recebeu essa mensagem por erro, tente sua solicitação novamente. Selecione para saber mais sobre as ações que você pode executar. Se o problema persistir, entre em contato com o código de mensagem de referência e suporte 715-123220 e a ID da transação: guid.".

Altere a forma como você se conecta à Microsoft para permitir que o serviço de verificação de identidade seja executado corretamente. Isso ajuda a garantir que sua conta não esteja comprometida e esteja em conformidade com os regulamentos aos quais a Microsoft deve aderir.

Coisas que você pode fazer:

• Limpe o cache do navegador.
• Desative a prevenção de rastreamento no navegador ou adicione nosso site à sua lista de exceções/segurança.
• Desative qualquer programa ou serviço de VPN (Rede Virtual Privada) que você possa estar usando.
• Conecte-se diretamente do seu dispositivo local em vez de por meio de uma VM (máquina virtual).

Se depois de tentar as etapas anteriores, você ainda não conseguir se conectar, sugerimos consultar seu Suporte técnico de TI para verificar suas configurações para ver se elas podem ajudar a identificar o que está causando o problema. Às vezes, o problema está nas configurações de rede da sua empresa. O administrador de TI precisaria resolver o problema, por exemplo, listando nosso site com segurança ou fazendo outros ajustes de configuração de rede.

• Restricted (Direct Bill): New GDAP (Relações de Administrador) NÃO PODE ser criado. Os GDAPs existentes e suas atribuições de função podem ser atualizados.
• Suspenso (Cobrança Direta/Provedor Indireto/Revendedor Indireto): não é possível criar um novo GDAP. GDAPs existentes e suas atribuições de função NÃO PODEM ser atualizados.
• Restrito (Cobrança Direta) + Ativo (Revendedor Indireto): Para a Conta Direta Restrita: não é possível criar um novo GDAP (Relações de Administrador). Os GDAPs existentes e suas atribuições de função podem ser atualizados. Para o Revendedor Indireto Ativo: novo GDAP pode ser criado, GDAPs existentes e suas atribuições de função podem ser atualizadas. Quando o novo GDAP offboarded não pode ser criado, o GDAP existente e suas atribuições de função não podem ser atualizados.

Sim. A versão atual do GDAP dá suporte a todos os produtos: Microsoft 365, Dynamics 365, Microsoft Power Platforme Microsoft Azure.