Preguntas más frecuentes sobre GDAP

Alguien con el rol de agente de administración de en una organización asociada puede crear una solicitud de relación de GDAP.

Sí. Las solicitudes de relación de GDAP expiran después de 90 días.

No. Las relaciones de GDAP permanentes con los clientes no son posibles por motivos de seguridad. La duración máxima de una relación de GDAP es de dos años. Puede establecer extensión automática de en Habilitado para ampliar una relación de administrador en seis meses, hasta que finalice o se extienda automáticamente en Deshabilitado.

No. La relación de GDAP no admite suscripciones adquiridas a través de contratos enterprise.

Sí. Una relación de GDAP puede extenderse automáticamente durante seis meses hasta que finalice o se extienda automáticamente establecido en Deshabilitado.

• Si expira la relación de GDAP con el cliente, solicitar una relación de GDAP de nuevo.
• Puede usar análisis de relaciones de GDAP para realizar un seguimiento de las fechas de expiración de la relación de GDAP y prepararse para su renovación.

Para ampliar o renovar una relación de GDAP, un asociado o cliente debe establecer extensión automática de en Habilitado. Obtenga más información en Manage GDAP Auto extend and API.

Sí. Si GDAP está activo, se puede extender.

Supongamos que se crea un GDAP durante 365 días con la extensión automática establecida en Habilitado. En el día 365, la fecha de finalización se actualiza eficazmente en 180 días.

Sí. Puede extender automáticamente cualquier GDAP activo.

No. El consentimiento del cliente no es necesario para establecer la extensión automática en Habilitado en un GDAP activo existente.

No. Los permisos granulares asignados a los grupos de seguridad continúan as-is.

No. No se puede extender automáticamente la relación de administrador con un rol de administrador global.

La página Relaciones granulares de expiración solo está disponible para los usuarios asociados con los roles Administradores globales y Agente de administración. Esta página ayuda a filtrar los GDAP que expiran en diferentes escalas de tiempo y ayuda a actualizar la extensión automática (habilitar o deshabilitar) para uno o varios GDAP.

No. No hay ningún cambio en las suscripciones existentes de un cliente cuando expira una relación de GDAP.

Consulte Solución de problemas de autenticación multifactor de Microsoft Entra y No se puede usar la autenticación multifactor de Microsoft Entra para iniciar sesión en los servicios en la nube después de perder el teléfono o el número de teléfono cambia para obtener instrucciones.

Un asociado debe solicitar al administrador de autenticación con privilegios rol de Microsoft Entra al crear el primer GDAP.

• Este rol permite a un asociado restablecer una contraseña y el método de autenticación para un usuario administrador o no administrador. El rol de administrador de autenticación con privilegios forma parte de los roles configurados por la herramienta led de Microsoft y está previsto que esté disponible con el GDAP predeterminado durante el flujo de creación de clientes (planeado para septiembre).
• El asociado podría hacer que el administrador del cliente intente Restablecer la contraseña.
• Como medida de precaución, el asociado debe configurar SSPR (autoservicio de restablecimiento de contraseña) para sus clientes. Para obtener más información, consulte Permitir que los usuarios restablezcan sus propias contraseñas.

• Dentro de una organización de asociado de , las personas con el agente de administración de rol reciben una notificación de terminación.
• Dentro de una organización de cliente, las personas con el rol de administrador global de reciben una notificación de terminación.

Sí. Los partners pueden ver cuándo un cliente quita el GDAP en los registros de actividad del Centro de partners.

No. GDAP es una funcionalidad opcional para los partners que desean administrar los servicios de sus clientes de forma más granular y limitada. Puede elegir con qué clientes desea crear una relación de GDAP.

La respuesta depende de cómo quiera administrar sus clientes.

• Si quiere que los usuarios asociados puedan administrar todos los clientes, puede colocar todos los usuarios asociados en un grupo de seguridad y ese grupo puede administrar todos los clientes.
• Si prefiere tener varios usuarios asociados que administran varios clientes, asigne esos usuarios asociados a grupos de seguridad independientes para el aislamiento de los clientes.

Sí. Los revendedores indirectos (y proveedores indirectos y asociados de factura directa) pueden crear solicitudes de relación de GDAP en el Centro de partners.

Como parte de la configuración de GDAP, asegúrese de que los grupos de seguridad creados en el inquilino del asociado con los usuarios asociados estén seleccionados. Asegúrese también de que los roles deseados de Microsoft Entra se asignan al grupo de seguridad. Consulte Asignar roles de Microsoft Entra.

Los clientes ahora pueden excluir los CSP de la directiva de acceso condicional para que los asociados puedan realizar la transición a GDAP sin bloquearse.

• Incluir usuarios: esta lista de usuarios suele incluir a todos los usuarios que una organización tiene como destino una directiva de acceso condicional.
• Las siguientes opciones están disponibles para incluir al crear una directiva de acceso condicional:
• Selección de usuarios y grupos
• Usuarios invitados o externos (versión preliminar)
• Esta selección proporciona varias opciones que se pueden usar para dirigir las directivas de acceso condicional a tipos de usuario invitado o externo específicos y inquilinos específicos que contienen esos tipos de usuarios. Hay varios tipos diferentes de usuarios invitados o externos que se pueden seleccionar y se pueden realizar varias selecciones:
• Usuarios del proveedor de servicios, por ejemplo, un proveedor de soluciones en la nube (CSP).
• Puede especificar uno o varios inquilinos para los tipos de usuario seleccionados o puede especificar todos los inquilinos.
• acceso de asociado externo: las directivas de acceso condicional destinadas a usuarios externos podrían interferir con el acceso del proveedor de servicios, por ejemplo, privilegios de administrador delegados pormenorizados. Para obtener más información, consulte Introducción a privilegios de administrador delegados granulares (GDAP). En el caso de las directivas destinadas a los inquilinos del proveedor de servicios de destino, use el usuario del proveedor de servicios de tipo de usuario externo disponible en las opciones de selección de usuarios invitados o externos de o externos.
• Excluir usuarios: cuando las organizaciones incluyen y excluyen a un usuario o grupo, el usuario o grupo se excluye de la directiva, ya que una acción de exclusión invalida una acción de inclusión en la directiva.
• Las siguientes opciones están disponibles para excluir al crear una directiva de acceso condicional:
• Usuarios invitados o externos
• Esta selección proporciona varias opciones que se pueden usar para dirigir las directivas de acceso condicional a tipos de usuario invitado o externo específicos y inquilinos específicos que contienen esos tipos de usuarios. Hay varios tipos diferentes de usuarios invitados o externos que se pueden seleccionary se pueden realizar varias selecciones:
• Usuarios del proveedor de servicios, por ejemplo, un proveedor de soluciones en la nube (CSP)
• Se pueden especificar uno o varios inquilinos para los tipos de usuario seleccionados o puede especificar todos los inquilinos. Para obtener más información, consulte:
• experiencia de Graph API: API beta con la nueva información de tipo de usuario externo
• de directiva de acceso condicional
• usuarios externos de acceso condicional

Sí. Independientemente del plan de soporte técnico que tenga, el rol con menos privilegios para que los usuarios asociados puedan crear incidencias de soporte técnico para su cliente es administrador de soporte técnico del servicio.

No. El asociado no puede finalizar actualmente un GDAP en estado pendiente de aprobación. Expiraría en 90 días si el cliente no realiza ninguna acción.

Solo después de 365 días (limpieza) después de que la relación de GDAP finalice o expire, puede reutilizar el mismo nombre para crear una nueva relación de GDAP.

Sí. Un asociado puede administrar sus clientes entre regiones sin crear nuevos inquilinos de asociado por región de cliente. Solo es aplicable al rol de administración de clientes proporcionado por GDAP (relaciones de administrador). El rol de transacción y las funcionalidades siguen limitados a la territorio autorizado.

No. Un proveedor de servicios no puede formar parte de una organización multiinquilino, que son mutuamente excluyentes.

1. Asegúrese de que GDAP está configurado correctamente, incluida la forma de conceder permisos de para grupos de seguridad.
2. Asegúrese de que los permisos de grupo de seguridad de granulares sean correctos.
3. Consulte las preguntas más frecuentes de Security Copilot para obtener ayuda.

Para obtener más información sobre las API y el GDAP, consulte la documentación para desarrolladores del Centro de partners de .

Sí. Se recomienda que los asociados usen las API de GDAP beta de para producción y versiones posteriores cambien a las API v.1 cuando estén disponibles. Aunque hay una advertencia, "No se admite el uso de estas API en aplicaciones de producción", esa guía genérica es para cualquier API beta en Graph y no es aplicable a las API de Graph de GDAP beta.

Sí. Puede crear relaciones de GDAP mediante API, lo que permite a los asociados escalar este proceso. Pero la creación de varias relaciones de GDAP no está disponible en el Centro de partners. Para obtener información sobre las API y el GDAP, consulte la documentación para desarrolladores del Centro de partners de .

La API funciona para un grupo de seguridad a la vez, pero puede asignar varios grupos de seguridad a varios roles en el Centro de partners.

Realice llamadas individuales para cada recurso. Al realizar una única solicitud POST, pase solo un recurso y sus ámbitos correspondientes. Por ejemplo, para solicitar permisos para https://graph.windows.net/Directory.AccessAsUser.All y https://graph.microsoft.com/Organization.Read.All, realice dos solicitudes diferentes, una para cada una.

Use el vínculo proporcionado para buscar el nombre del recurso: Comprobar aplicaciones de Microsoft de primera entidad en informes de inicio de sesión: Active Directory. Por ejemplo, para buscar el identificador de recurso 00000003-0000-0000-c000-0000000000000 para graph.microsoft.com:

Este error suele producirse cuando se usa un identificador incorrecto en el filtro de consulta. Para resolverlo, asegúrese de que usa la propiedad enterpriseApplicationId con el identificador de recurso de correcto, no el nombre del recurso.

• solicitud incorrecta Para enterpriseApplicationId, no use un nombre de recurso como graph.microsoft.com.
• correcto solicitud en su lugar, para enterpriseApplicationId, use el identificador de recurso, como 00000003-0000-0000-c000-000000000000000.

Por ejemplo, anteriormente en graph.microsoft.com recurso solo se consiente el ámbito de "perfil". Ahora es necesario agregar también el perfil y user.read. Para agregar nuevos ámbitos a una aplicación con consentimiento anterior:

1. Use el método DELETE para revocar el consentimiento de la aplicación existente del inquilino del cliente.
2. Use el método POST para crear el consentimiento de la aplicación con los ámbitos adicionales.

Concatene los ámbitos necesarios mediante una coma seguida de un espacio. Por ejemplo, "scope": "profile, User.Read"

1. Confirme que las propiedades "displayName" y "applicationId" del cuerpo de la solicitud son precisas y coinciden con la aplicación que intenta dar su consentimiento en el inquilino del cliente.
2. Asegúrese de que usa la misma aplicación para generar el token de acceso que está intentando dar su consentimiento en el inquilino del cliente. Por ejemplo: Si el identificador de aplicación es "12341234-1234-1234-12341234", la notificación "appId" del token de acceso también debe ser "12341234-1234-1234-12341234".
3. Compruebe que se cumple una de las condiciones siguientes:

• Tiene un privilegio de administrador delegado activo (DAP) y el usuario también es miembro del grupo Seguridad de agentes de administración en el inquilino del asociado.
• Tiene una relación activa con privilegios de administrador delegado granular (GDAP) con el inquilino cliente con al menos uno de los tres roles de GDAP siguientes y completó la asignación de acceso:
  • Administrador global, Administrador de aplicaciones o Rol administrador de aplicaciones en la nube.
  • El usuario asociado es miembro del grupo de seguridad especificado en la asignación de acceso.

• Para administrar Azure con particiones de acceso por cliente (que es el procedimiento recomendado), cree un grupo de seguridad (por ejemplo, Administradores de Azure) y anidarlo en Agentes de administración.
• Para acceder a una suscripción de Azure como propietario de un cliente, puede asignar cualquier rol integrado de Microsoft Entra (como lectores de directorio, el rol con privilegios mínimos) al grupo de seguridad Administradores de Azure. Para conocer los pasos para configurar Azure GDAP, consulte Cargas de trabajo compatibles con privilegios de administrador delegados pormenorizados (GDAP).

Sí. Para obtener información sobre cómo restringir los permisos de administrador de un usuario mediante la asignación de roles con privilegios mínimos en Microsoft Entra, consulte roles con privilegios mínimos por tarea en Microsoft Entra.

Se recomienda asignar el rol de administrador de soporte técnico de Service. Para obtener más información, consulte roles con privilegios mínimos por tarea en Microsoft Entra.

• Para reducir la brecha entre los roles de Microsoft Entra disponibles en la API del Centro de partners frente a la interfaz de usuario, hay una lista de nueve roles disponibles en la interfaz de usuario del Centro de partners en julio de 2024.
• En Colaboración:
  • Administrador de Microsoft Edge
  • Administrador de visitas virtuales
  • Administrador de objetivos Viva
  • Administrador de Pulso Viva
  • Administrador de Yammer
• En Identidad:
  • Administrador de administración de permisos
  • Administrador de flujos de trabajo del ciclo de vida
• En Otros:
  • Administrador de personalización de marca organizativa
  • Aprobador de mensajes de la organización

No. El rol con privilegios mínimos para que los usuarios asociados puedan crear incidencias de soporte técnico para su cliente es el administrador de soporte técnico del servicio . Por lo tanto, para poder crear incidencias de soporte técnico para el cliente, un usuario asociado debe estar en un grupo de seguridad y asignarlo a ese cliente con ese rol.

Para obtener información sobre todos los roles, consulte roles integrados de Microsoft Entra. Para obtener información sobre las cargas de trabajo, consulte Cargas de trabajo compatibles con privilegios de administrador delegados pormenorizados (GDAP).

Muchos roles se usan para el Centro de administración de Microsoft 365. Para obtener más información, consulte Roles del Centro de administración de Microsoft 365 usados habitualmente.

Sí. Cree un grupo de seguridad, asigne roles aprobados y, a continuación, asigne usuarios de inquilino de asociados a ese grupo de seguridad.

El acceso de solo lectura a las suscripciones del cliente lo proporciona el lector global de , lector de directoriosy roles de de partner.

Se recomienda quitar los agentes asociados del agente de administración rol y agregarlos solo a un grupo de seguridad de GDAP. De este modo, pueden administrar servicios (solicitudes de servicio de administración y registro de servicios, por ejemplo), pero no pueden comprar y administrar suscripciones (cambiar cantidad, cancelar, programar cambios, etc.).

Los grupos de seguridad asignados a la relación pierden el acceso a ese cliente. Lo mismo sucede si un cliente finaliza una relación DAP.

Sí. Quitar las relaciones de GDAP con un cliente no finaliza la relación de revendedor de los partners con el cliente. Los partners todavía pueden comprar productos para el cliente y administrar el presupuesto de Azure y otras actividades relacionadas.

No. Todos los roles de una relación de GDAP tienen el mismo tiempo de expiración: la duración que se eligió cuando se creó la relación.

No. No necesita GDAP para cumplir los pedidos de clientes nuevos y existentes. Puede seguir usando el mismo proceso para cumplir los pedidos de los clientes en el Centro de partners.

Las relaciones de GDAP son por cliente. Puede tener varias relaciones por cliente. Cada relación de GDAP puede tener roles diferentes y usar diferentes grupos de Microsoft Entra dentro del inquilino de CSP. En el Centro de partners, la asignación de roles funciona en el nivel de relación de cliente a GDAP. Si desea realizar la asignación de roles multicustomer, puede automatizar mediante las API.

Los administradores invitados de GDAP no pueden administrar su propia información de seguridad en My Security-Info. En su lugar, necesitan la ayuda del administrador de inquilinos en el que son invitados para cualquier registro, actualización o eliminación de información de seguridad. Las organizaciones pueden configurar directivas de acceso entre inquilinos para confiar en MFA desde el inquilino de CSP de confianza. De lo contrario, los administradores invitados de GDAP solo se limitan a los métodos que el administrador de inquilinos puede registrar (que es SMS o Voz). Para más información, consulte directivas de acceso entre inquilinos.

Alinee con el principio de guiding de Confianza cero: Use el acceso con privilegios mínimos:

• Se recomienda usar un rol con privilegios mínimos por tareas y tareas de carga de trabajo cargas de trabajo compatibles con privilegios de administrador delegados granulares (GDAP) compatibles con GDAP.
• Cuando sea necesario solucionar problemas conocidos enumerados, trabaje con el cliente para solicitar un rol de administrador global con límite de tiempo.
• No se se recomienda reemplazar el rol de administrador global por todos los roles posibles de Microsoft Entra.

Sí. Durante el período de transición, coexistirán DAP y GDAP, con permisos de GDAP que tienen prioridad sobre los permisos DAP para Microsoft 365, Dynamics 365y cargas de trabajo de Azure.

DAP y GDAP coexisten durante el período de transición. Sin embargo, finalmente el GDAP reemplaza DAP para asegurarnos de que proporcionamos una solución más segura para nuestros asociados y clientes. Se recomienda realizar la transición de los clientes a GDAP lo antes posible para garantizar la continuidad.

No hay ningún cambio en el flujo de relación DAP existente mientras coexisten DAP y GDAP.

DAP se concede actualmente cuando se crea un nuevo inquilino de cliente. El 25 de septiembre de 2023, Microsoft ya no concede DAP para la creación de nuevos clientes y, en su lugar, concede el GDAP predeterminado con roles específicos. Los roles predeterminados varían según el tipo de asociado, como se muestra en la tabla siguiente:

Los asociados pueden implementar Privileged Identity Management (PIM) en un grupo de seguridad de GDAP en el inquilino del asociado para elevar el acceso de algunos usuarios con privilegios elevados, just-in-time (JIT) para concederles roles con privilegios elevados, como administradores de contraseñas con eliminación automática del acceso. Hasta enero de 2023, era necesario que cada grupo de acceso con privilegios (nombre anterior de la característica PIM para grupos) tuviera que estar en un grupo de asignable a roles. Esta restricción ahora se ha quitado . Dado este cambio, es posible habilitar más de 500 grupos por inquilino en PIM, pero solo se pueden asignar roles a 500 grupos. Resumen:

• Los asociados pueden usar grupos de a los que se pueden asignar roles en PIM tanto como no asignables a roles. Esta opción quita eficazmente el límite de 500 grupos/tenant en PIM.
• Con las actualizaciones más recientes, hay dos maneras de incorporar grupo a PIM (con experiencia de usuario): desde el menú de PIM de o desde el menú de Grupos. Independientemente de la manera que elija, el resultado neto es el mismo.
  • La capacidad de incorporar grupos a los que se pueden asignar roles o no a roles a través del menú PIM ya está disponible.
  • La capacidad de incorporar grupos a los que se pueden asignar roles o no a roles a través del menú Grupos ya está disponible.
• Para obtener más información, consulte Privileged Identity Management (PIM) for Groups (versión preliminar): Microsoft Entra.

GDAP está disponible con carácter general con compatibilidad con todos los servicios en la nube comerciales de Microsoft (microsoft 365, Dynamics 365, Microsoft Azurey cargas de trabajo de Microsoft Power Platform). Para obtener más información sobre cómo pueden coexistir DAP y GDAP y cómo GDAP tiene prioridad, busque estas preguntas más frecuentes sobre los permisos de GDAP ¿Cómo tienen prioridad los permisos de DAP mientras coexisten DAP y GDAP? pregunta.

Puede realizar esta acción con las API.

No. Las ganancias de PEC no se ven afectadas cuando realiza la transición a GDAP. No hay ningún cambio en PAL con la transición, lo que garantiza que sigue ganando PEC.

• Si el cliente de un asociado solo tiene DAP y se quita DAP, pec no se pierde.
• Si el cliente de un asociado tiene DAP y se mueven a GDAP para Microsoft 365 y Azure simultáneamente, y DAP se quita, pec no se pierde.
• Si el cliente del asociado tiene DAP y se mueven a GDAP para Microsoft 365, pero mantienen Azure as-is (no se mueven a GDAP) y DAP se quita, pec no se pierde, pero se pierde el acceso a la suscripción de Azure.
• Si se quita un rol RBAC, se pierde PEC, pero la eliminación de GDAP no quita RBAC.

Cuando el usuario forma parte del grupo de seguridad GDAP y del grupo de agentes de administración de DAP y el cliente tiene relaciones daP y GDAP, el acceso de GDAP tiene prioridad en el nivel de asociado, cliente y carga de trabajo.

Por ejemplo, si un usuario asociado inicia sesión para una carga de trabajo y hay DAP para el rol de administrador global y GDAP para el rol lector global, el usuario asociado solo obtiene permisos de lector global.

Si hay tres clientes con asignaciones de roles de GDAP solo al grupo de seguridad de GDAP (no a los agentes de administración):

En la tabla siguiente se describe lo que sucede cuando un usuario inicia sesión en un inquilino de cliente diferente.

DAP y GDAP no son tipos de asociación aptos para las designaciones de asociados de soluciones. aDisabling or transition from DAP to GDAP doesn't affect your logro of Solutions Partner designs. Además, la renovación de las ventajas de competencia heredadas o las ventajas de asociados de soluciones no se ve afectada. Para ver los otros tipos de asociación de asociados aptos para la designación de partners de soluciones, consulte designaciones de asociados del Centro de partners.

Con respecto a la relación entre Azure Lighthouse y DAP/GDAP, piense en ellas como rutas paralelas desacopladas para los recursos de Azure. El desenlazamiento de uno no debe afectar al otro.

• En el escenario de Azure Lighthouse, los usuarios del inquilino del asociado nunca inician sesión en el inquilino del cliente y no tienen permisos de Microsoft Entra en el inquilino del cliente. Sus asignaciones de roles de RBAC de Azure también se conservan en el inquilino del asociado.
• En el escenario de GDAP, los usuarios del inquilino del asociado inician sesión en el inquilino del cliente. La asignación de roles RBAC de Azure al grupo agentes de administración también está en el inquilino del cliente. Puede bloquear la ruta de acceso de GDAP (los usuarios ya no pueden iniciar sesión) mientras la ruta de acceso de Azure Lighthouse no se ve afectada. Por el contrario, puede interrumpir la relación lighthouse (proyección) sin afectar al GDAP. Para más información, consulte la documentación de de Azure Lighthouse.

Los proveedores de servicios administrados (MSP) inscritos en el programa Proveedor de soluciones en la nube (CSP) como revendedores indirectos o factura directa asociados ahora pueden usar Microsoft 365 Lighthouse para configurar GDAP para cualquier inquilino de cliente. Dado que ya hay varias maneras en que los asociados administran su transición a GDAP, este asistente permite a los asociados de Lighthouse adoptar recomendaciones de rol específicas de sus necesidades empresariales. También les permite adoptar medidas de seguridad como el acceso Just-In-Time (JIT). Los MSP también pueden crear plantillas de GDAP a través de Lighthouse para guardar y volver a aplicar fácilmente la configuración que habilita el acceso de los clientes con privilegios mínimos. Para obtener más información y ver una demostración, consulte el Asistente para configuración de GDAP de Lighthouse. Los MSP pueden configurar GDAP para cualquier inquilino de cliente en Lighthouse. Para acceder a los datos de carga de trabajo del cliente en Lighthouse, se requiere una relación de GDAP o DAP. Si los permisos de GDAP y DAP coexisten en un inquilino de cliente, los permisos de GDAP tienen prioridad para los técnicos de MSP en grupos de seguridad habilitados para GDAP. Para obtener más información sobre los requisitos de Microsoft 365 Lighthouse, consulte Requirements for Microsoft 365 Lighthouse.

La secuencia correcta que se debe seguir para este escenario es:

1. Cree una relación de GDAP para Tanto Microsoft 365 como Azure.
2. Asigne roles de Microsoft Entra a grupos de seguridad para Tanto Microsoft 365 como Azure.
3. Configure GDAP para que tenga prioridad sobre DAP.
4. Quite DAP.

La siguiente secuencia podría dar lugar a perder el acceso a las suscripciones de Azure:

1. Quite DAP. No necesariamente pierde el acceso a una suscripción de Azure mediante la eliminación de DAP. Pero en este momento, no puede examinar el directorio del cliente para realizar ninguna asignación de roles de RBAC de Azure (por ejemplo, asignar un nuevo usuario de cliente como colaborador de RBAC de suscripción).
2. Cree una relación de GDAP para tanto Microsoft 365 como Azure juntos. podría perder el acceso a la suscripción de Azure en este paso en cuanto se configure el GDAP.
3. Asignación de roles de Microsoft Entra a grupos de seguridad para Tanto Microsoft 365 como Azure

Recuperará el acceso a las suscripciones de Azure una vez completada la configuración de GDAP de Azure.

Si tiene suscripciones de Azure sin DAP que administra como propietario, al agregar GDAP para Microsoft 365 a ese cliente, puede perder el acceso a las suscripciones de Azure. Para evitar el acceso perdido, mueva el cliente al de GDAP de Azure al mismo tiempo que mueva el cliente a GDAP de Microsoft 365.

No. Las relaciones, una vez aceptadas, no son reutilizables.

Si tiene una relación de revendedor existente con el cliente, debe establecer una relación de GDAP para administrar sus suscripciones de Azure.

1. Cree un grupo de seguridad (por ejemplo, Administradores de Azure) en Microsoft Entra.
2. Cree una relación de GDAP con el rol lector de directorios de .
3. Convierta el grupo de seguridad en miembro del grupo de Agente de administración. Después de realizar estos pasos, puede administrar la suscripción de Azure del cliente mediante AOBO. No puede administrar la suscripción mediante la CLI o PowerShell.

Sí. Puede crear un plan de Azure incluso si no hay ningún DAP o GDAP con una relación de revendedor existente. Pero para administrar esa suscripción, necesita DAP o GDAP.

A medida que los partners pasan de DAP a GDAP, deben asegurarse de que están disponibles lo siguiente para ver los detalles de la empresa:

• Una relación de GDAP activa.
• Se asignan cualquiera de los siguientes roles de Microsoft Entra: Administrador global, Lectores de directorios, Lectores globales. Consulte conceder permisos pormenorizados a grupos de seguridad.

Cuando un CSP inicia sesión en Azure Portal de su cliente (portal.azure.come) con sus credenciales de CSP y existe una relación de GDAP, el CSP observa que su nombre de usuario es "user_" seguido de algún número. No muestra su nombre de usuario real como en DAP. Es por diseño.

Los asociados deben conceder explícitamente permisos pormenorizados a grupos de seguridad en el GDAP predeterminado.
A partir del 10 de octubre de 2023, DAP ya no está disponible con relaciones de revendedor. El vínculo De relación de revendedor de solicitudes actualizado está disponible en la interfaz de usuario del Centro de partners y la dirección URL de propiedad del contrato de API "/v1/customers/relationship requests" devuelve la dirección URL de invitación que se enviará al administrador del inquilino del cliente.

Sí, los asociados deben conceder explícitamente permisos granulares a los grupos de seguridad en el GDAP predeterminado para administrar el cliente.

Los asociados con la relación de revendedor solo sin DAP o GDAP pueden crear clientes, realizar y administrar pedidos, descargar claves de software, administrar Azure RI. No pueden ver los detalles de la empresa del cliente, no pueden ver usuarios ni asignar licencias a los usuarios, no pueden registrar incidencias en nombre de los clientes y no pueden acceder a los centros de administración específicos del producto (por ejemplo, centro de administración de Teams).

Para que un asociado o CPV accedan y administren un inquilino de cliente, la entidad de servicio de su aplicación debe dar su consentimiento en el inquilino del cliente. Cuando DAP está activo, deben agregar la entidad de servicio de la aplicación al SG de agentes de administración en el inquilino del asociado. Con GDAP, el asociado debe asegurarse de que su aplicación está con consentimiento en el inquilino del cliente. Si la aplicación usa permisos delegados (Aplicación + usuario) y existe un GDAP activo con cualquiera de los tres roles (Administrador de aplicaciones en la nube, Administrador de aplicaciones, Administrador de aplicaciones, Administrador global) api de consentimiento se puede usar. Si la aplicación solo usa permisos de aplicación, el asociado o el cliente deben dar su consentimiento manualmente, ya sea con cualquiera de los tres roles (Administrador de aplicaciones en la nube, Administrador de aplicaciones, Administrador global), mediante dirección URL de consentimiento del administrador de todo el inquilino.

Si ve el siguiente error:

"No se puede validar la solicitud "Crear nueva relación de GDAP" en este momento. Tenga en cuenta que no se permiten conexiones anónimas para este servicio. Si cree que recibió este mensaje en error, vuelva a intentar la solicitud. Seleccione esta opción para obtener información sobre las acciones que puede realizar. Si el problema persiste, póngase en contacto con el código de mensaje de referencia y soporte técnico 715-123220 y id. de transacción: guid".

Cambie cómo se conecta a Microsoft para permitir que el servicio de verificación de identidad se ejecute correctamente. Ayuda a garantizar que su cuenta no está en peligro y cumple con las normativas a las que Microsoft debe cumplir.

Cosas que puede hacer:

• Borre la memoria caché del explorador.
• Desactive la prevención de seguimiento en el explorador o agregue nuestro sitio a su lista de excepciones o seguras.
• Desactive cualquier programa o servicio de red privada virtual (VPN) que pueda usar.
• Conéctese directamente desde el dispositivo local en lugar de a través de una máquina virtual (VM).

Si después de probar los pasos anteriores, todavía no puede conectarse, se recomienda consultar con el departamento de soporte técnico de TI para comprobar la configuración para ver si pueden ayudar a identificar lo que está causando el problema. A veces, el problema está en la configuración de red de la empresa. El administrador de TI tendría que solucionar el problema, por ejemplo, mediante una lista segura de nuestro sitio o realizar otros ajustes de configuración de red.

• Restringido (factura directa): no se puede crear el nuevo GDAP (relaciones de administrador). Se pueden actualizar los GDAP existentes y sus asignaciones de roles.
• Suspendido (Proveedor indirecto de factura directa/revendedor indirecto): no se puede crear el nuevo GDAP. No se pueden actualizar los GDAP existentes y sus asignaciones de roles.
• Restringido (factura directa) + activo (revendedor indirecto): para factura directa restringida: no se puede crear un nuevo GDAP (relaciones de administrador). Se pueden actualizar los GDAP existentes y sus asignaciones de roles. Para revendedor indirecto activo: se puede crear un nuevo GDAP, se pueden actualizar los GDAP existentes y sus asignaciones de roles. Cuando no se puede crear un GDAP nuevo a bordo, no se pueden actualizar las asignaciones de roles y GDAP existentes.

Sí. La versión actual de GDAP admite todos los productos: Microsoft 365, Dynamics 365, Microsoft Power Platformy Microsoft Azure.