Perguntas frequentes sobre o GDAP

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

Sim. As solicitações de relacionamento GDAP expiram após 90 dias.

Não. As relações GDAP permanentes com os clientes não são possíveis por razões de segurança. A duração máxima de uma relação GDAP é de dois anos. Você pode definir de extensão automática para habilitado para estender um relacionamento de administrador por seis meses, até que seja encerrado ou a extensão automática seja definida como desativado.

Não. A relação GDAP não suporta subscrições adquiridas através de contratos empresariais.

Sim. Uma relação GDAP pode se estender automaticamente por seis meses até ser encerrada ou a extensão automática definida como Desabilitada.

• Se o relacionamento GDAP com seu cliente expirar, solicitar um relacionamento GDAP novamente.
• Você pode usar de análise de relacionamento GDAP para acompanhar as datas de expiração do relacionamento GDAP e se preparar para sua renovação.

Para estender ou renovar um relacionamento GDAP, um parceiro ou cliente deve definir de extensão automática para habilitado. Saiba mais em Manage GDAP Auto extend e API.

Sim. Se o GDAP estiver ativo, ele pode ser estendido.

Digamos que um GDAP seja criado por 365 dias com a extensão automática definida como Habilitado. No 365º dia, a Data de Término é efetivamente atualizada em 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 como Ativado 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. Não é possível estender automaticamente o relacionamento 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 Administrativo. 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á alteração nas assinaturas existentes de um cliente quando um relacionamento 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 em serviços de nuvem depois que você perder seu telefone ou o número de telefone mudar para obter orientação.

Um parceiro deve solicitar ao administrador de autenticação Privileged função 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 privilegiada faz parte das funções configuradas pela Microsoft Led Tool e está planejada para estar disponível com GDAP padrão durante o fluxo Criar cliente (planejado para setembro).
• O parceiro pode pedir administrador do cliente tente Redefinir a senha.
• Como precaução, o parceiro deve configurar SSPR (Self-service password reset) para seus clientes. Para obter mais informações, consulte Permitir que as pessoas redefina suas próprias senhas.

• Dentro de um parceiro organização , as pessoas com a função de agente administrador recebem uma notificação de encerramento.
• Dentro de uma organização cliente , 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 é um recurso opcional para parceiros que desejam gerenciar os serviços de seus clientes de forma mais granular e limitada no tempo. Você pode escolher com quais clientes deseja criar um relacionamento GDAP.

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

• Se você 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 esse 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 (e provedores indiretos e parceiros de cobrança direta) podem criar solicitações de relacionamento GDAP no Partner Center.

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

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

• Incluir usuários - Essa lista de usuários geralmente inclui todos os usuários que uma organização está segmentando em uma política de Acesso Condicional.
• As seguintes opções estão disponíveis para inclusão ao criar uma política de Acesso Condicional:
• Selecionar usuários e grupos
• Usuários convidados ou externos (visualização)
• 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 convidados ou usuários externos que podem ser selecionados, e várias seleções podem ser feitas:
• Usuários de provedores 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 pode especificar todos os locatários.
• Acesso de parceiro externo - As políticas de acesso condicional destinadas a utilizadores externos podem interferir com o acesso do fornecedor 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 provedores de serviços, use o tipo de usuário provedor de serviços usuário externo disponível nas opções de seleção Convidado ou usuários externos.
• 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:
• Utilizadores 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 convidados ou usuários externos que podem ser selecionados, e várias seleções podem ser feitas:
• Usuários de provedores 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 mais informações, consulte:
• Graph API Experience: API Beta com as novas informações de tipo de usuário externo
• Política de acesso condicional
• Acesso condicional utilizadores externos

Sim. Independentemente do plano de suporte que você tenha, a função menos privilegiada para que os usuários parceiros possam criar tíquetes de suporte para seus clientes é o administrador de suporte de serviço.

Não. Atualmente, o parceiro não pode encerrar um GDAP no status Aprovação pendente. Expiraria em 90 dias se o cliente não tomasse nenhuma medida.

Somente após 365 dias (limpeza) após o término ou expiração do relacionamento GDAP, você poderá reutilizar o mesmo nome para criar um novo relacionamento GDAP.

Sim. Um parceiro pode gerenciar seus clientes entre regiões sem criar novos locatários parceiros por região do cliente. É aplicável apenas à função de gerenciamento de clientes fornecida pelo GDAP (Admin Relations). A função e os recursos de transação ainda estão limitados ao seu Território autorizado.

Não. Um provedor de serviços não pode fazer parte de uma organização multilocatário, eles são mutuamente exclusivos.

1. Verifique se o GDAP está configurado corretamente, incluindo como você concede permissões de para grupos de segurança.
2. Certifique-se de que as permissões granulares do grupo de segurança estão corretas.
3. Consulte a de 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 GDAP beta para produção e, posteriormente, alternem para APIs v.1 quando estiverem disponíveis. Embora haja um aviso, "O uso dessas APIs em aplicativos de produção não é suportado", 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 que os parceiros dimensionem esse processo. Mas a criação de vários relacionamentos 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 de cada 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 uma.

Use o link fornecido para procurar o nome do recurso: Verificar aplicativos primários da Microsoft em relatórios de entrada - Ative Directory. Por exemplo, para localizar a ID de recurso 00000003-0000-0000-c000-0000000000000 para graph.microsoft.com:

Este 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 de correta, não o nome do recurso.

• Solicitação incorreta Para 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-c000-0000000000000.

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

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 um novo consentimento de aplicativo com os escopos extras.

Concatene os escopos necessários usando uma vírgula seguida de um espaço. Por exemplo, "escopo": "perfil, 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 com o locatário do cliente.
2. Certifique-se de que está a utilizar a mesma aplicação para gerar o token de acesso que está a tentar consentir para o inquilino 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 é atendida:

• Você tem um Privilégio de Administrador Delegado (DAP) ativo e o usuário também é membro do grupo Segurança de Agentes de Administração no locatário parceiro.
• Você tem um relacionamento GDAP (Granular Delegated Admin Privilege) ativo 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 de 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 prática recomendada recomendada), crie um grupo de segurança (como Azure Managers) e aninha-o em Admin agents.
• 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 Gerentes do Azure. Para conhecer as etapas para configurar o Azure GDAP, consulte Cargas de trabalho suportadas por privilégios de administrador delegado granular (GDAP).

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 menos privilegiadas por tarefa no Microsoft Entra.

Recomendamos atribuir a função de administrador de suporte do Serviço . Para saber mais, consulte Funções menos privilegiadas por tarefa no Microsoft Entra.

• Para reduzir a lacuna entre as funções do Microsoft Entra disponíveis na API do Partner Center versus a interface do usuário, uma lista de nove funções estará disponível na interface do usuário do Partner Center em julho de 2024.
• No âmbito da colaboração:
  • Administrador do Microsoft Edge
  • Administrador de Visitas Virtuais
  • Administrador Viva Goals
  • Administrador Viva Pulse
  • Administrador do Yammer
• Em Identidade:
  • Administrador de Gerenciamento de Permissões
  • Administrador de fluxos de trabalho de ciclo de vida
• Em Outros:
  • Administrador de Branding Organizacional
  • Aprovador de Mensagens Organizacionais

Não. A função menos privilegiada para que os usuários parceiros possam criar tíquetes de suporte para seus clientes é o administrador de suporte do Service. 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 suportadas por privilégios de administrador delegado granular (GDAP).

Muitas funções são usadas para o Microsoft 365 Admin Center. Para obter mais informações, consulte Funções do centro de administração do Microsoft 365 mais usadas.

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

O acesso somente leitura às assinaturas do cliente é fornecido pelo de leitura Global, de leitor de diretório e funções de suporte de nível 2 de parceiro.

Recomendamos que você remova os agentes parceiros da função de agente Admin e adicione-os apenas a um grupo de segurança GDAP. Dessa forma, eles podem administrar serviços (gerenciamento de serviços 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 ao relacionamento perdem o acesso a esse cliente. A mesma coisa acontece se um cliente encerra um relacionamento DAP.

Sim. A remoção das relações GDAP com um cliente não encerra o relacionamento 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 um relacionamento GDAP têm o mesmo tempo para expiração: a duração que foi escolhida quando o relacionamento foi criado.

Não. Você não precisa de GDAP para atender pedidos de clientes novos e existentes. Você pode continuar a usar o mesmo processo para atender aos pedidos dos 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 grupos diferentes do Microsoft Entra dentro do seu locatário CSP. No Partner Center, a atribuição de função funciona no nível de relacionamento cliente-GDAP. Se quiser atribuir funções a vários clientes, você pode automatizar usando APIs.

Os administradores convidados do GDAP não conseguem gerenciar suas próprias informações de segurança em My Security-Info. Em vez disso, eles precisam da assistência do administrador do locatário do qual 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 no MFA do locatário CSP confiável. Caso contrário, os administradores convidados do GDAP estão limitados apenas aos métodos registráveis pelo administrador dos inquilinos (que é SMS ou Voz). Para saber mais, consulte Políticas de acesso entre locatários.

Alinhe-se com o Princípio orientador do Zero Trust: Use o acesso com privilégios mínimos:

• Recomendamos o uso de uma função menos privilegiada por tarefas e tarefas de carga de trabalho Cargas de trabalho suportadas por privilégios de administrador delegado granular (GDAP) suportadas pelo GDAP.
• Quando for necessário contornar os problemas conhecidos listados, trabalhe com seu cliente para solicitar uma função de Administrador Global com limite de 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 do DAP para do Microsoft 365, Dynamics 365e cargas de trabalho do Azure.

O DAP e o GDAP coexistem durante o período de transição. No entanto, eventualmente, o GDAP está substituindo o DAP para garantir que fornecemos 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 relacionamento DAP existente enquanto DAP e GDAP coexistem.

Atualmente, 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 a 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 de Gerenciamento de Identidade Privilegiada (PIM) 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-lhes funções de alto privilégio, como administradores de senha com remoção automática de acesso. Até de janeiro de 2023, era exigido que todos os de Grupo de Acesso Privilegiado (antigo nome do recurso PIM para Grupos ) estivessem em um grupo atribuível a função. Esta restrição foi agora eliminada. Dada essa alteração, é possível habilitar mais de 500 grupos por de locatário no PIM, mas apenas até 500 grupos podem ser atribuíveis por função. Sumário:

• Os parceiros podem usar grupos atribuíveis e não atribuíveis por função no PIM. Esta opção remove efetivamente o limite de 500 grupos/tenant no PIM.
• Com as atualizações mais recentes, há duas maneiras de integrar grupo ao PIM (em termos de UX): no menu PIM ou no menu Grupos de . Independentemente da forma escolhida, o resultado líquido é o mesmo.
  • A capacidade de integrar grupos atribuíveis/não atribuíveis por meio do menu PIM já está disponível.
  • A capacidade de integrar grupos atribuíveis ou não atribuíveis por meio do menu Grupos já está disponível.
• Para obter mais informações, consulte Privileged Identity Management (PIM) for Groups (visualização) - Microsoft Entra.

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

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

Não. Seus ganhos 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 o DAP for removido, o PEC não será perdido.
• Se o cliente de um parceiro tiver DAP e ele mudar para 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 GDAP para Microsoft 365, mas mantiver o Azure as-is (eles não se movem para 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 de administração de 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 receberá apenas 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 Admin):

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 de Parceiros de Soluções. aDesativar ou fazer a transição do DAP para o GDAP não afeta a obtenção das designações de Parceiro de Soluções. Além disso, a renovação dos benefícios de competência herdados ou dos benefícios do parceiro de soluções não é afetada. Para ver os outros tipos de associação de parceiros elegíveis para a designação de Parceiro de Soluções, consulte Designações de Parceiros de Soluções do Partner Center.

Em relação à relação entre o Azure Lighthouse e o DAP/GDAP, pense neles como caminhos paralelos dissociados para os recursos do Azure. Separar um não deve afetar o outro.

• No cenário do Azure Lighthouse, os usuários do locatário parceiro nunca entram 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 do RBAC do Azure também são mantidas no locatário parceiro.
• No cenário GDAP, os usuários do locatário parceiro entram no locatário do cliente. A atribuição da função RBAC do Azure ao grupo de agentes Admin 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 for afetado. Por outro lado, você pode cortar a relação Farol (projeção) sem afetar o GDAP. Para obter mais informações, consulte a documentação do Azure Lighthouse.

Os Provedores de Serviços Gerenciados (MSPs) inscritos no programa CSP (Provedor de Soluções na Nuvem) como revendedores indiretos ou parceiros de de cobrança direta agora podem usar o Microsoft 365 Lighthouse para configurar o GDAP para qualquer locatário do cliente. Como já existem algumas maneiras pelas quais os parceiros já estão gerenciando sua transição para o GDAP, esse assistente permite que os parceiros do Lighthouse adotem recomendações de função específicas para suas necessidades de negócios. Também lhes permite adotar medidas de segurança, como o acesso just-in-time (JIT). Os MSPs também podem criar modelos GDAP através do Lighthouse para salvar e reaplicar facilmente as configurações que permitem o acesso do cliente com privilégios mínimos. Para obter mais informações e exibir uma demonstração, consulte o assistente de configuração do GDAP do Lighthouse. Os MSPs podem configurar o GDAP para qualquer locatário de cliente no Lighthouse. Para acessar os dados de carga de trabalho do cliente no Lighthouse, é necessário um relacionamento GDAP ou DAP. Se GDAP e DAP coexistirem em um locatário cliente, as permissões GDAP terão 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. Atribua funções do Microsoft Entra a grupos de segurança para Microsoft 365 e Azure.
3. Configure o GDAP para ter precedência sobre o DAP.
4. Remova o DAP.

A sequência a seguir pode resultar na perda acesso às assinaturas do Azure:

1. Remova o DAP. Você não necessariamente perde o acesso a uma assinatura do Azure removendo o DAP. Mas, no momento, você não pode navegar no diretório do cliente para fazer nenhuma atribuição de função do RBAC do Azure (como atribuir um novo usuário do cliente como colaborador RBAC de 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. Atribua 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 tiver subscrições do Azure sem DAP que gere como proprietário, quando adicionar GDAP para Microsoft 365 a esse cliente, poderá perder o acesso às subscrições do Azure. Para evitar a perda de acesso, mova o cliente para o Azure GDAP ao mesmo tempo que você mova o cliente para o Microsoft 365 GDAP.

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

Se você tiver um relacionamento de revendedor existente com o cliente, ainda precisará estabelecer um relacionamento GDAP para gerenciar suas assinaturas do Azure.

1. Crie um grupo de segurança (por exemplo, Gerentes do Azure) no Microsoft Entra.
2. Crie uma relação GDAP com a função leitor de diretório .
3. Torne o grupo de segurança membro do grupo Admin Agent. Depois de executar essas etapas, você pode gerenciar a assinatura do Azure do seu cliente por meio do AOBO. Não é possível gerenciar a assinatura por meio de CLI/Powershell.

Sim. Você pode criar um plano do Azure mesmo que não haja DAP ou GDAP com um relacionamento 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 de seu cliente (portal.azure.come) usando suas credenciais 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 conceder explicitamente 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 relacionamentos de revendedores. O link Request Reseller Relationship 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 do convite a ser enviada ao administrador do locatário do cliente.

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

Os parceiros com relacionamento de revendedor somente sem DAP ou GDAP podem criar clientes, fazer e gerenciar pedidos, baixar chaves de software, gerenciar o Azure RI. Eles não podem visualizar os detalhes da empresa do cliente, não podem visualizar 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 está ativo, eles devem adicionar a entidade de serviço do aplicativo ao SG de Agentes Administrativos no locatário 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 existir um GDAP ativo com qualquer uma das três funções (Administrador de Aplicativo na Nuvem, Administrador de Aplicativo, Administrador Global) API de consentimento poderá ser usada. Se o aplicativo usar apenas permissões de aplicativo, ele deverá ser consentido manualmente, seja pelo parceiro ou cliente que tenha qualquer uma das três funções (Cloud Application Administrator, Application Administrator, Global Administrator), usando URL de consentimento de administrador em todo o locatário.

Se vir o seguinte erro:

"Não é possível validar sua solicitação 'Criar novo relacionamento GDAP' no momento. Esteja ciente de que conexões anônimas não são permitidas para este serviço. Se acredita que recebeu esta mensagem por engano, tente o seu pedido novamente. Selecione esta opção para saber mais sobre as ações que você pode tomar. Se o problema persistir, entre em contato com o suporte e o código de mensagem de referência 715-123220 e 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. Ajuda a garantir que a sua conta não está comprometida e está em conformidade com os regulamentos aos quais a Microsoft tem de aderir.

Coisas que pode fazer:

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

Se, depois de tentar as etapas anteriores, você ainda não conseguir se conectar, sugerimos consultar o Help Desk de TI para verificar suas configurações e 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. Seu administrador de TI precisaria resolver o problema, por exemplo, listando nosso site com segurança ou fazendo outros ajustes de configuração de rede.

• Restrito (Fatura Direta): Novo GDAP (Relações com Administradores) NÃO PODE ser criado. GDAPs existentes e suas atribuições de função PODEM ser atualizados.
• Suspenso (fatura direta/provedor indireto/revendedor indireto): Novo GDAP NÃO pode ser criado. GDAPs existentes e suas atribuições de função NÃO podem ser atualizados.
• Restrito (Fatura Direta) + Ativo (Revendedor Indireto): Para Fatura Direta Restrita: NÃO É possível criar novos GDAP (Relações com Administradores). GDAPs existentes e suas atribuições de função PODEM ser atualizados. Para Revendedor Indireto Ativo: Novos GDAP PODEM ser criados, GDAPs existentes e suas atribuições de função PODEM ser atualizados. Quando o novo GDAP offboard 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 suporta todos os produtos: Microsoft 365, Dynamics 365, Microsoft Power Platforme Microsoft Azure.