Domande frequenti su GDAP

  • Articolo

Ruoli appropriati: tutti gli utenti interessati al Centro per i partner

Le autorizzazioni di amministratore delegate (GDAP) granulari consentono ai partner di accedere ai carichi di lavoro dei clienti in modo più granulare e associato al tempo, che può aiutare a risolvere i problemi di sicurezza dei clienti.

Con GDAP, i partner possono fornire più servizi ai clienti che potrebbero essere a disagio con i livelli elevati di accesso ai partner.

GDAP aiuta anche i clienti che hanno requisiti normativi per fornire solo l'accesso con privilegi minimi ai partner.

Configurazione di GDAP

Chi può richiedere una relazione GDAP?

Un utente con il ruolo agente Amministrazione in un'organizzazione partner può creare una richiesta di relazione GDAP.

Una richiesta di relazione GDAP scade se il cliente non esegue alcuna azione?

Sì. Le richieste di relazione GDAP scadono dopo 90 giorni.

Posso creare una relazione GDAP con un cliente permanente?

No. Le relazioni GDAP permanenti con i clienti non sono possibili per motivi di sicurezza. La durata massima di una relazione GDAP è di due anni. È possibile impostare Estensione automatica su Abilitato per estendere una relazione di amministratore di sei mesi, fino alla chiusura o all'estensione automatica impostata su Disabilitato.

Una relazione GDAP con un cliente può estendersi automaticamente o di nuovo?

Sì. Una relazione GDAP può estendersi automaticamente di sei mesi fino alla chiusura o all'estensione automatica impostata su Disabilitato.

Cosa faccio quando scade la relazione GDAP con un cliente?

Se la relazione GDAP con il cliente scade, richiedere di nuovo una relazione GDAP.

È possibile usare l'analisi delle relazioni GDAP per tenere traccia delle date di scadenza delle relazioni GDAP e prepararsi per il rinnovo.

In che modo un cliente può estendere o rinnovare una relazione GDAP?

Per estendere o rinnovare una relazione GDAP, il partner o il cliente deve impostare Estensione automatica su Abilitato.

Un GDAP attivo in scadenza può essere presto aggiornato per l'estensione automatica?

Sì, se GDAP è attivo, potrebbe essere esteso.

Quando l'estensione automatica entra in azione?

Si supponga che venga creato un GDAP per 365 giorni con estensione automatica impostata su Abilitato. Nel 365° giorno, data di fine verrebbe aggiornata in modo efficace entro 180 giorni.

I messaggi di posta elettronica vengono inviati quando l'estensione automatica viene attivata/disabilitata?

Nessun messaggio di posta elettronica verrà inviato al partner e al cliente.

Un GDAP creato con PLT (Partner Led Tool), MLT (Microsoft Led Tool), l'interfaccia utente del Centro per i partner, l'API del Centro per i partner può essere estesa automaticamente?

Sì, qualsiasi GDAP attivo può essere esteso automaticamente.

No, il consenso del cliente non è necessario per impostare l'estensione automatica su Abilitato su un GDAP attivo esistente.

Le autorizzazioni granulari devono essere riassegnate ai gruppi di sicurezza dopo l'estensione automatica?

No, le autorizzazioni granulari assegnate ai gruppi di sicurezza continuano così come sono.

È possibile estendere automaticamente una relazione di amministratore con il ruolo Amministrazione istrator globale?

No, la relazione di amministratore con il ruolo Amministrazione istrator globale non può essere estesa automaticamente.

Perché non è possibile visualizzare la pagina Relazioni granulari in scadenza nell'area di lavoro Clienti?

La pagina Relazioni granulari in scadenza consente di filtrare i GDAP in scadenza in sequenze temporali diverse, consente di aggiornare uno o più GDAP per l'estensione automatica (abilitazione/disabilitazione), è disponibile solo per gli utenti partner con ruoli di Amministrazione istrator globali e Amministrazione Agent.

Se una relazione GDAP scade, le sottoscrizioni esistenti del cliente sono interessate?

No. Non viene apportata alcuna modifica alle sottoscrizioni esistenti di un cliente alla scadenza di una relazione GDAP.

In che modo un cliente può reimpostare la password e il dispositivo MFA se sono bloccati dal proprio account e non possono accettare una richiesta di relazione GDAP da un partner?

Per indicazioni, vedere Risolvere i problemi di autenticazione a più fattori di Microsoft Entra e non usare l'autenticazione a più fattori Di Microsoft Entra per accedere ai servizi cloud dopo aver perso il telefono o il numero di telefono cambia.

Quali ruoli hanno bisogno di un partner per reimpostare una password amministratore e un dispositivo MFA se un amministratore del cliente è bloccato dal proprio account e non può accettare una richiesta di relazione GDAP da un partner?

Per poter reimpostare la password e il metodo di autenticazione per un utente (amministratore o non amministratore) è necessario richiedere al partner il ruolo Microsoft Entra come amministratore o non amministratore. Il ruolo privileged Authentication Amministrazione istrator fa parte dei ruoli configurati da MLT (Microsoft Led Tool) ed è previsto che sia disponibile con GDAP predefinito durante la creazione del flusso del cliente (previsto per settembre).

Il partner potrebbe avere l'amministratore del cliente provare a reimpostare la password. Per precauzione, il partner deve configurare la reimpostazione della password self-service per i clienti. Fare riferimento a Consenti agli utenti di reimpostare le proprie password.

Chi riceve un messaggio di posta elettronica di notifica di terminazione della relazione GDAP?

All'interno di un'organizzazione partner, le persone con il ruolo agente Amministrazione ricevono una notifica di terminazione.

All'interno di un'organizzazione del cliente , gli utenti con il ruolo di amministratore globale ricevono una notifica di terminazione.

È possibile visualizzare quando un cliente rimuove GDAP nei log attività?

Sì. I partner possono vedere quando un cliente rimuove GDAP nei log attività del Centro per i partner.

Devo creare una relazione GDAP con tutti i miei clienti?

No. GDAP è una funzionalità facoltativa per i partner che vogliono gestire i servizi del cliente in modo più granulare e associato al tempo. È possibile scegliere i clienti con cui si vuole creare una relazione GDAP.

Se si hanno più clienti, è necessario avere più gruppi di sicurezza per tali clienti?

La risposta dipende dalla modalità di gestione dei clienti.

  • Se si vuole che gli utenti partner possano gestire tutti i clienti, è possibile inserire tutti gli utenti partner in un unico gruppo di sicurezza e che un gruppo possa gestire tutti i clienti.

  • Se si preferisce avere diversi utenti partner che gestiscono vari clienti, assegnare tali utenti partner a gruppi di sicurezza separati per l'isolamento dei clienti.

I rivenditori indiretti possono creare richieste di relazione GDAP nel Centro per i partner?

Sì. I rivenditori indiretti (e i provider indiretti e i partner con fatturazione diretta) possono creare richieste di relazione GDAP nel Centro per i partner.

Perché un utente partner con GDAP non può accedere a un carico di lavoro come AOBO (Amministrazione per conto di)?

Come parte della configurazione di GDAP, assicurarsi che i gruppi di sicurezza creati nel tenant partner con gli utenti partner siano selezionati. Assicurarsi anche che i ruoli di Microsoft Entra desiderati vengano assegnati al gruppo di sicurezza. Vedere Assegnare i ruoli di Microsoft Entra.

I clienti possono ora escludere i CSP dai criteri di accesso condizionale in modo che i partner possano passare a GDAP senza essere bloccati.

Includi utenti : questo elenco di utenti include in genere tutti gli utenti che un'organizzazione ha come destinazione un criterio di accesso condizionale.

Per la creazione di un criterio di accesso condizionale sono disponibili le opzioni seguenti:

  • Selezionare utenti e gruppi
    • Utenti guest o esterni (anteprima)
      • Questa selezione offre diverse opzioni che possono essere usate per impostare come destinazione i criteri di accesso condizionale a tipi di utenti guest o esterni specifici e tenant specifici contenenti tali tipi di utenti. Esistono diversi tipi di utenti guest o esterni che possono essere selezionati e possono essere effettuate più selezioni:
        • Utenti del provider di servizi, ad esempio cloud solution provider (CSP).
      • È possibile specificare uno o più tenant per i tipi di utente selezionati oppure specificare tutti i tenant.

Accesso partner esterno: i criteri di accesso condizionale destinati agli utenti esterni potrebbero interferire con l'accesso al provider di servizi, ad esempio privilegi di amministratore delegati granulari. Per altre informazioni, vedere Introduzione ai privilegi di amministratore delegato granulari (GDAP). Per i criteri destinati ai tenant del provider di servizi di destinazione, usare il tipo di utente esterno del provider di servizi disponibile nelle opzioni di selezione Utenti guest o esterni.

Screenshot dell'esperienza utente dei criteri CA destinata ai tipi di utenti guest ed esterni di organizzazioni Specifiche di Microsoft Entra.

Escludi utenti : quando le organizzazioni includono ed escludono un utente o un gruppo, l'utente o il gruppo viene escluso dai criteri, perché un'azione di esclusione sostituisce un'azione di inclusione nei criteri.

Quando si crea un criterio di accesso condizionale sono disponibili le opzioni seguenti:

  • Utenti guest o esterni
    • Questa selezione offre diverse opzioni che possono essere usate per impostare come destinazione i criteri di accesso condizionale a tipi di utenti guest o esterni specifici e tenant specifici contenenti tali tipi di utenti. Esistono diversi tipi di utenti guest o esterni che possono essere selezionati e possono essere effettuate più selezioni:
      • Utenti del provider di servizi, ad esempio cloud solution provider (CSP)
    • È possibile specificare uno o più tenant per i tipi di utente selezionati oppure specificare tutti i tenant.

Screenshot dei criteri della CA.

Per altre informazioni, vedi:

È necessaria una relazione GDAP per creare ticket di supporto anche se si dispone del supporto Premier per i partner?

Sì, indipendentemente dal piano di supporto di cui si dispone, il ruolo con privilegi minimi per gli utenti partner per poter creare ticket di supporto per il cliente è l'amministratore del supporto tecnico.

Il GDAP nello stato Approvazione in sospeso può essere terminato dal partner?

No, il partner non può attualmente terminare un GDAP nello stato Approvazione in sospeso . Scadrà entro 90 giorni se il cliente non esegue alcuna azione.

Dopo la chiusura di una relazione GDAP, è possibile riutilizzare lo stesso nome di relazione GDAP per creare una nuova relazione?

Solo dopo 365 giorni (pulizia) la relazione GDAP è Terminata o Scaduta, è possibile riutilizzare lo stesso nome per creare una nuova relazione GDAP.

API GDAP

Le API sono disponibili per creare una relazione GDAP con i clienti?

Per informazioni sulle API e sulla GDAP, vedere la documentazione per sviluppatori del Centro per i partner.

È possibile usare le API GDAP beta per la produzione?

Sì. È consigliabile che i partner usino le API BETA GDAP per la produzione e che in seguito passino alle API v.1 quando diventano disponibili.

Anche se è presente un avviso, "L'uso di queste API nelle applicazioni di produzione non è supportato", che linee guida generiche è per qualsiasi API beta in Graph e non è applicabile alle API Graph GDAP beta.

È possibile creare più relazioni GDAP con clienti diversi contemporaneamente?

Sì. Le relazioni GDAP possono essere create usando le API, consentendo ai partner di ridimensionare questo processo. La creazione di più relazioni GDAP non è tuttavia disponibile nel Centro per i partner. Per informazioni sulle API e sulla GDAP, vedere la documentazione per sviluppatori del Centro per i partner.

È possibile assegnare più gruppi di sicurezza in una relazione GDAP usando una chiamata API?

L'API funziona per un gruppo di sicurezza alla volta, ma è possibile eseguire il mapping di più gruppi di sicurezza a più ruoli nel Centro per i partner.

Come è possibile richiedere più autorizzazioni per le risorse per l'applicazione?

Effettuare singole chiamate per ogni risorsa. Quando si effettua una singola richiesta POST, passare una sola risorsa e i relativi ambiti corrispondenti.

Ad esempio, per richiedere le autorizzazioni sia per https://graph.windows.net/Directory.AccessAsUser.All e https://graph.microsoft.com/Organization.Read.All, effettuare due richieste diverse, una per ognuna.

Come è possibile trovare l'ID risorsa per una determinata risorsa?

Usare il collegamento fornito per cercare il nome della risorsa: Verificare le applicazioni Microsoft proprietarie nei report di accesso - Active Directory. Esempio:

Per trovare l'ID risorsa (ad esempio: 00000003-0000-0000-c0000-00000000000000 per graph.microsoft.com):

Screenshot della schermata Manifesto per un'app di esempio, con l'ID risorsa evidenziato.

Cosa devo fare se si verifica l'errore "Request_UnsupportedQuery" con il messaggio" "Clausola di filtro di query non supportata o non valida specificata per la proprietà 'appId' della risorsa 'ServicePrincipal'"?

Questo errore si verifica in genere quando viene usato un identificatore non corretto nel filtro di query.

Per risolverlo, assicurarsi di usare la proprietà enterpriseApplicationId con l'ID risorsa corretto, non il nome della risorsa.

  • Richiesta non corretta

    Per enterpriseApplicationId, non usare un nome di risorsa come graph.microsoft.com.

    Screenshot di una richiesta non corretta, in cui enterpriseApplicationId usa graph.microsoft.com.

  • Richiesta corretta

    Per enterpriseApplicationId usare invece l'ID risorsa, ad esempio 00000003-0000-0000-c000-000000000000000000.

    Screenshot di una richiesta corretta, in cui enterpriseApplicationId usa un GUID.

Come è possibile aggiungere nuovi ambiti alla risorsa di un'applicazione che è già stata consensata nel tenant del cliente?

Esempio: in precedenza in graph.microsoft.com'ambito "profilo" della risorsa è stato concesso il consenso. Ora si vuole aggiungere anche il profilo e user.read.

Per aggiungere nuovi ambiti a un'applicazione con consenso precedente:

  1. Usare il metodo DELETE per revocare il consenso dell'applicazione esistente dal tenant del cliente.

  2. Usare il metodo POST per creare un nuovo consenso dell'applicazione con gli ambiti aggiuntivi.

    Nota

    Se l'applicazione richiede autorizzazioni per più risorse, eseguire il metodo POST separatamente per ogni risorsa.

Ricerca per categorie specificare più ambiti per una singola risorsa (enterpriseApplicationId)?

Concatenare gli ambiti necessari usando una virgola seguita da uno spazio. Esempio: "scope": "profile, User.Read"

Cosa devo fare se viene visualizzato un errore "400 Richiesta non valida" con il messaggio "Token non supportato. Impossibile inizializzare il contesto di autorizzazione"?

  1. Verificare che le proprietà 'displayName' e 'applicationId' nel corpo della richiesta siano accurate e corrispondano all'applicazione che si sta tentando di fornire il consenso nel tenant del cliente.

  2. Assicurarsi di usare la stessa applicazione per generare il token di accesso che si sta tentando di fornire il consenso nel tenant del cliente.

    Esempio: se l'ID applicazione è "12341234-1234-1234-12341234", l'attestazione "appId" nel token di accesso deve essere anche "12341234-1234-1234-1234-12341234".

  3. Verificare che sia soddisfatta una delle condizioni seguenti:

    • Si dispone di un daP (Delegated Amministrazione Privilege) attivo e l'utente è anche membro del gruppo di sicurezza Amministrazione Agents nel tenant partner.

    • Si dispone di una relazione Granular Delegated Amministrazione Privilege (GDAP) attiva con il tenant del cliente con almeno uno dei tre ruoli GDAP seguenti ed è stata completata l'assegnazione di accesso:

      • Ruolo Amministrazione istrator globale, application Amministrazione istrator o applicazione cloud Amministrazione istrator.
      • L'utente partner è membro del gruppo di sicurezza specificato nell'assegnazione di accesso.

Ruoli

Quali ruoli GDAP sono necessari per accedere a una sottoscrizione di Azure?
Sono disponibili indicazioni sui ruoli con privilegi minimi che è possibile assegnare agli utenti per attività specifiche?

Sì. Per informazioni su come limitare le autorizzazioni di amministratore di un utente assegnando ruoli con privilegi minimi in Microsoft Entra, vedere Ruoli con privilegi minimi per attività in Microsoft Entra.

Qual è il ruolo con privilegi minimi che è possibile assegnare al tenant di un cliente e poter comunque creare ticket di supporto per il cliente?

È consigliabile assegnare il ruolo di amministratore del supporto del servizio. Per altre informazioni, vedere Ruoli con privilegi minimi per attività in Microsoft Entra.

È possibile aprire ticket di supporto per un cliente in una relazione GDAP da cui sono stati esclusi tutti i ruoli di Microsoft Entra?

No. Il ruolo con privilegi minimi per gli utenti partner per poter creare ticket di supporto per il cliente è l'amministratore del supporto tecnico del servizio. Pertanto, per poter creare ticket di supporto per il cliente, un utente partner deve trovarsi in un gruppo di sicurezza e assegnato a tale cliente con tale ruolo.

Dove è possibile trovare informazioni su tutti i ruoli e i carichi di lavoro inclusi in GDAP?

Per informazioni su tutti i ruoli, vedere Ruoli predefiniti di Microsoft Entra.

Per informazioni sui carichi di lavoro, vedere Carichi di lavoro supportati da privilegi di amministratore delegati granulari (GDAP).

Quale ruolo GDAP concede l'accesso al centro Amministrazione Microsoft 365?

Molti ruoli vengono usati per Amministrazione Microsoft 365 Center. Per altre informazioni, vedere Ruoli dell'interfaccia di amministrazione di Microsoft 365 comunemente usati.

È possibile creare gruppi di sicurezza personalizzati per GDAP?

Sì. Creare un gruppo di sicurezza, assegnare ruoli approvati e quindi assegnare utenti tenant partner a tale gruppo di sicurezza.

Quali ruoli GDAP forniscono l'accesso in sola lettura alle sottoscrizioni del cliente e quindi non consentono all'utente di gestirli?

L'accesso in sola lettura alle sottoscrizioni del cliente viene fornito dai ruoli di supporto del lettore globale, del lettore directory e del livello 2 del partner.

Quale ruolo è necessario assegnare agli agenti partner (attualmente Amministrazione agenti) se si vuole gestire il tenant del cliente ma non modificare le sottoscrizioni del cliente?

È consigliabile rimuovere gli agenti partner dal ruolo agente Amministrazione e aggiungerli solo a un gruppo di sicurezza GDAP. In questo modo, possono amministrare i servizi (ad esempio, gestione dei servizi e registrare le richieste di servizio), ma non possono acquistare e gestire le sottoscrizioni (modificare la quantità, annullare, pianificare le modifiche e così via).

Cosa accade se un cliente concede ruoli GDAP al partner e quindi rimuove i ruoli o le relazioni GDAP?

I gruppi di sicurezza assegnati alla relazione perdono l'accesso a tale cliente. La stessa cosa accade se un cliente termina una relazione DAP.

Un partner può continuare a eseguire transazioni per un cliente dopo aver rimosso tutte le relazioni GDAP con il cliente?

Sì, la rimozione delle relazioni GDAP con un cliente non termina la relazione di rivenditore dei partner con il cliente. I partner possono comunque acquistare prodotti per il cliente e gestire il budget di Azure e altre attività correlate.

Alcuni ruoli nella mia relazione GDAP con il cliente hanno più tempo di scadenza rispetto ad altri?

No. Tutti i ruoli in una relazione GDAP hanno lo stesso tempo di scadenza: la durata scelta al momento della creazione della relazione.

Ho bisogno di GDAP per soddisfare gli ordini per i clienti nuovi ed esistenti nel Centro per i partner?

No. Non è necessario GDAP per soddisfare gli ordini per i clienti nuovi ed esistenti. È possibile continuare a usare lo stesso processo per soddisfare gli ordini dei clienti nel Centro per i partner.

È necessario assegnare un ruolo agente partner a tutti i clienti oppure assegnare un ruolo agente partner a un solo cliente?

Le relazioni GDAP sono per cliente. È possibile avere più relazioni per cliente. Ogni relazione GDAP può avere ruoli diversi e usare diversi gruppi di Microsoft Entra all'interno del tenant CSP.

Nel Centro per i partner, l'assegnazione di ruolo funziona a livello di relazione da cliente a GDAP. Per l'assegnazione di ruolo multicustomer, è possibile automatizzare l'uso delle API.

Un utente partner può avere ruoli GDAP e un account guest?

Gli account guest sono supportati da GDAP, ma non con la relazione DAP.

È necessario il provisioning di DAP/GDAP per il provisioning delle sottoscrizioni di Azure?

No, non è necessario usare DAP o GDAP per acquistare Piani di Azure e effettuare il provisioning delle sottoscrizioni di Azure per un cliente. Il processo per creare una sottoscrizione di Azure per un cliente è documentato in Creare una sottoscrizione per il cliente di un partner - Gestione costi Microsoft e fatturazione. Per impostazione predefinita, il gruppo Amministrazione Agents nel tenant del partner diventa il proprietario delle sottoscrizioni di Azure di cui è stato effettuato il provisioning per il cliente. Accedere al portale di Azure usando l'ID del Centro per i partner.

Per effettuare il provisioning dell'accesso al cliente, è necessaria una relazione GDAP. La relazione GDAP deve includere almeno il ruolo Microsoft Entra di Lettori directory. Per effettuare il provisioning dell'accesso in Azure, usare la pagina di controllo di accesso (IAM). Per AOBO, accedere al Centro per i partner e usare la pagina Gestione dei servizi per effettuare il provisioning dell'accesso al cliente.

Quali ruoli di Microsoft Entra sono supportati da GDAP?

GDAP supporta attualmente solo i ruoli predefiniti di Microsoft Entra. I ruoli Microsoft Entra personalizzati non sono supportati.

Perché gli amministratori GDAP e gli utenti B2B non sono in grado di aggiungere metodi di autenticazione in aka.ms/mysecurityinfo?

Gli amministratori guest GDAP non sono in grado di gestire le proprie informazioni di sicurezza in My Security-Info. Avranno invece bisogno dell'assistenza dell'amministratore tenant in cui sono guest per qualsiasi registrazione, aggiornamento o eliminazione delle informazioni di sicurezza. Le organizzazioni possono configurare criteri di accesso tra tenant per considerare attendibile l'autenticazione a più fattori dal tenant CSP attendibile. In caso contrario, gli amministratori guest GDAP saranno limitati solo ai metodi registrabili dall'amministratore dei tenant ,ovvero SMS o Voce. Per altre informazioni, vedere Criteri di accesso tra tenant.

DAP e GDAP

GDAP sostituisce DAP?

Sì. Durante il periodo di transizione, DAP e GDAP coesisteranno, con le autorizzazioni GDAP che hanno la precedenza sulle autorizzazioni DAP per i carichi di lavoro di Microsoft 365, Dynamics 365 e Azure .

Posso continuare a usare DAP o devo passare tutti i miei clienti a GDAP?

DAP e GDAP coesistono durante il periodo di transizione. Tuttavia, GDAP sostituirà infine DAP per garantire che forniamo una soluzione più sicura per i nostri partner e clienti. È consigliabile passare i clienti al GDAP il prima possibile per garantire la continuità.

Mentre DAP e GDAP coesistono, ci saranno modifiche al modo in cui viene creata una relazione DAP?

Non sono state apportate modifiche al flusso di relazione DAP esistente, mentre DAP e GDAP coesistono.

Quali ruoli di Microsoft Entra vengono concessi per il GDAP predefinito come parte di Create customer?

Al momento la creazione di un nuovo tenant del cliente viene concessa da DAP. A partire dal 25 settembre 2023, Microsoft non concederà più DAP per la creazione di nuovi clienti e concederà invece il GDAP predefinito con ruoli specifici. I ruoli predefiniti variano in base al tipo di partner, come illustrato nella tabella seguente:

Ruoli di Microsoft Entra concessi per il GDAP predefinito Partner con fatturazione diretta Provider indiretti Rivenditori indiretti Partner di dominio fornitori di Pannello di controllo (CPV) Advisor Rifiuto esplicito di GDAP predefinito (nessun DAP)
1. Lettori directory. Può leggere le informazioni base della directory. Comunemente usato per concedere l'accesso in lettura alla directory alle applicazioni e ai guest. x x x x x
2. Writer di directory. Può leggere e scrivere informazioni di base sulla directory. Per concedere l'accesso alle applicazioni, non destinato agli utenti. x x x x x
3. Licenza Amministrazione istrator. Possono gestire licenze dei prodotti per utenti e gruppi. x x x x x
4. Supporto del servizio Amministrazione istrator. Può eseguire la lettura delle informazioni di integrità dei servizi e gestire i ticket di supporto. x x x x x
5. User Amministrazione istrator. Può gestire tutti gli aspetti di utenti e gruppi, inclusa la reimpostazione delle password per gli amministratori con limitazioni. x x x x x
6. Ruolo con privilegi Amministrazione istrator. Può gestire le assegnazioni di ruolo in Microsoft Entra e tutti gli aspetti di Privileged Identity Management. x x x x x
7. Helpdesk Amministrazione istrator. Può reimpostare le password per gli amministratori non amministratori e help desk. x x x x x
8. Autenticazione con privilegi Amministrazione istrator. Può accedere a visualizzare, impostare e reimpostare le informazioni sul metodo di autenticazione per qualsiasi utente (amministratore o non amministratore). x x x x x
9. Applicazione cloud Amministrazione istrator. Può creare e gestire tutti gli aspetti delle registrazioni di app e delle app aziendali, ad eccezione del Proxy di applicazione. x x x x
10. Applicazione Amministrazione istrator. Può creare e gestire tutti gli aspetti delle registrazioni di app e delle app aziendali. x x x x
11. Lettore globale. Può leggere tutto ciò che un amministratore globale può, ma non può aggiornare nulla. x x x x x
12. Provider di identità esterno Amministrazione istrator. Può gestire la federazione tra le organizzazioni Microsoft Entra e i provider di identità esterni. x
13. Nome di dominio Amministrazione istrator. Può gestire i nomi di dominio nel cloud e in locale. x
Come funziona GDAP con Privileged Identity Management in Microsoft Entra?

I partner possono implementare Privileged Identity Management (PIM) in un gruppo di sicurezza GDAP nel tenant del partner per elevare l'accesso di alcuni utenti con privilegi elevati, just-in-time (JIT) per concedere loro ruoli con privilegi elevati come gli amministratori delle password con rimozione automatica dell'accesso.

Per abilitare questa implementazione, la sottoscrizione a Microsoft Entra ID P2 è necessaria gratuitamente da PIM. I partner Microsoft possono accedere per ottenere i dettagli.

Fino a gennaio 2023, era necessario che ogni gruppo di accesso con privilegi (nome precedente per la funzionalità PIM per i gruppi) fosse in un gruppo assegnabile a ruoli. Questa restrizione è stata rimossa. Dato questo, è possibile abilitare più di 500 gruppi per tenant in PIM, ma solo fino a 500 gruppi possono essere assegnabili a ruoli.

Riepilogo:

  • I partner possono usare gruppi assegnabili a ruoli e non assegnabili a ruoli in PIM. In questo modo si rimuove in modo efficace il limite di 500 gruppi/tenant in PIM.

  • Con gli aggiornamenti più recenti, è possibile eseguire l'onboarding del gruppo in PIM (UX-wise): dal menu PIM o dal menu Gruppi . Indipendentemente dal modo scelto, il risultato netto è lo stesso.

    • La possibilità di eseguire l'onboarding di gruppi assegnabili/non assegnabili da ruoli tramite il menu PIM è già disponibile.

    • La possibilità di eseguire l'onboarding di gruppi assegnabili/non assegnabili da ruoli tramite il menu Gruppi è già disponibile.

  • Per altre informazioni, vedere Privileged Identity Management (PIM) per i gruppi (anteprima) - Microsoft Entra.

Come coesistere DAP e GDAP se un cliente acquista Microsoft Azure e Microsoft 365 o Dynamics 365?

GDAP è disponibile a livello generale con supporto per tutti i servizi cloud commerciali Microsoft (Carichi di lavoro di Microsoft 365, Dynamics 365, Microsoft Azure e Microsoft Power Platform ). Per altre informazioni sul modo in cui DAP e GDAP possono coesistere e sul modo in cui GDAP ha la precedenza, vedere Come la GDAP avrà la precedenza su DAP.

Ho una base clienti di grandi dimensioni (ad esempio 10.000 account cliente). Ricerca per categorie transizione da DAP a GDAP?

Questa azione può essere eseguita dalle API.

No. Gli utili pec non saranno interessati quando si passa a GDAP. Non ci sono modifiche all'elenco di accesso alla pubblicazione con la transizione, assicurandoti di continuare a guadagnare pec.

Il pec è interessato quando viene rimosso DAP/GDAP?
  • Se il cliente di un partner ha solo DAP e daP viene rimosso, la pec non viene persa.
  • Se il cliente di un partner dispone di DAP e passa al GDAP per Office e Azure contemporaneamente, e DAP viene rimosso, la pec non viene persa.
  • Se il cliente del partner ha DAP e passa a GDAP per Office, ma mantiene Azure così com'è (non si spostano in GDAP) e DAP viene rimosso, la pec non andrà persa, ma l'accesso alla sottoscrizione di Azure andrà perso.
  • Se viene rimosso un ruolo controllo degli accessi in base al ruolo, pec viene perso, ma la rimozione di GDAP non rimuoverà il controllo degli accessi in base al ruolo.
In che modo le autorizzazioni GDAP hanno la precedenza sulle autorizzazioni DAP mentre DAP e GDAP coesistono?

Quando l'utente fa parte del gruppo di sicurezza GDAP e del gruppo di agenti daP Amministrazione e il cliente ha relazioni DAP e GDAP, l'accesso GDAP ha la precedenza a livello di partner, cliente e carico di lavoro.

Ad esempio, se un utente partner accede per un determinato carico di lavoro ed è presente DAP per il ruolo amministratore globale e GDAP per il ruolo lettore globale, l'utente partner ottiene solo le autorizzazioni di lettura globale.

Se sono presenti tre clienti con assegnazioni di ruoli GDAP solo a gruppi di sicurezza GDAP (non agenti Amministrazione):

Diagramma che mostra la relazione tra utenti diversi come membri di *agente Amministrazione* e gruppi di sicurezza GDAP.

Customer Relazione con il partner
Cliente 1 DAP (nessun GDAP)
Cliente 2 DAP + GDAP
Cliente 3 GDAP (nessun DAP)

La tabella seguente descrive quando un utente accede a un tenant del cliente diverso.

Utente di esempio Tenant del cliente di esempio Comportamento Commenti
Utente 1 Cliente 1 DAP Questo esempio è DAP così com'è.
Utente 1 Cliente 2 DAP Non esiste alcuna assegnazione di ruolo GDAP al gruppo di agenti Amministrazione, che comporta un comportamento DAP.
Utente 1 Cliente 3 Nessun accesso Non esiste alcuna relazione DAP, quindi il gruppo di agenti Amministrazione non ha accesso al cliente 3.
Utente 2 Cliente 1 DAP Questo esempio è DAP così com'è
Utente 2 Cliente 2 GDAP GDAP ha la precedenza su DAP perché è presente un ruolo GDAP assegnato all'utente 2 tramite il gruppo di sicurezza GDAP anche se l'utente fa parte del gruppo di agenti Amministrazione.
Utente 2 Cliente 3 GDAP Questo esempio è un cliente solo GDAP.
Utente 3 Cliente 1 Nessun accesso Non esiste alcuna assegnazione di ruolo GDAP al cliente 1.
Utente 3 Cliente 2 GDAP L'utente 3 non fa parte del gruppo di agenti Amministrazione, con un comportamento di solo GDAP.
Utente 3 Cliente 3 GDAP Comportamento solo GDAP
La disabilitazione di DAP o la transizione a GDAP influisce sui vantaggi di competenza legacy o sulle designazioni dei partner soluzioni ottenute?

DAP e GDAP non sono tipi di associazione idonei per le designazioni di Solutions Partner e la disabilitazione o la transizione da DAP a GDAP non influisce sul raggiungimento delle designazioni dei partner soluzioni. Anche il rinnovo dei vantaggi di competenza legacy o dei vantaggi dei partner soluzioni non sarà interessato.

Passare a Designazioni partner del Centro per i partner per visualizzare quali altri tipi di associazione partner sono idonei per le designazioni dei partner soluzioni.

Come funziona GDAP con Azure Lighthouse? GDAP e Azure Lighthouse influiscono l'uno sull'altro?

Per quanto riguarda la relazione tra Azure Lighthouse e DAP/GDAP, considerarli come percorsi paralleli disaccoppiati alle risorse di Azure, quindi severarne uno non dovrebbe influire sull'altro.

  • Nello scenario di Azure Lighthouse, gli utenti del tenant partner non accedono mai al tenant del cliente e non dispongono di autorizzazioni Microsoft Entra nel tenant del cliente. Le assegnazioni di ruolo controllo degli accessi in base al ruolo di Azure vengono mantenute anche nel tenant del partner.

  • Nello scenario GDAP, gli utenti dall'accesso del tenant partner al tenant del cliente e l'assegnazione del ruolo controllo degli accessi in base al ruolo di Azure al gruppo di agenti Amministrazione si trovano anche nel tenant del cliente. È possibile bloccare il percorso GDAP (gli utenti non possono più accedere) mentre il percorso di Azure Lighthouse non è interessato. Al contrario, è possibile severare la relazione Lighthouse (proiezione) senza influire sul GDAP. Per altre informazioni, vedere la documentazione di Azure Lighthouse .

Come funziona GDAP con Microsoft 365 Lighthouse?

I provider di servizi gestiti (MSP) registrati nel programma Cloud Solution Provider (CSP) come rivenditori indiretti o partner con fatturazione diretta possono ora usare Microsoft 365 Lighthouse per configurare GDAP per qualsiasi tenant del cliente. Poiché esistono alcuni modi in cui i partner gestiscono già la transizione a GDAP, questa procedura guidata consente ai partner Lighthouse di adottare raccomandazioni di ruolo specifiche per le proprie esigenze aziendali. Consente inoltre di adottare misure di sicurezza come l'accesso JIT (Just-In-Time). I provider di servizi cloud possono anche creare modelli GDAP tramite Lighthouse per salvare e riapplicare facilmente le impostazioni che consentono l'accesso con privilegi minimi ai clienti. Per altre informazioni e per visualizzare una demo, vedere la configurazione guidata di Lighthouse GDAP.

I provider di servizi gestito possono configurare GDAP per qualsiasi tenant del cliente in Lighthouse. Per accedere ai dati del carico di lavoro del cliente in Lighthouse, è necessaria una relazione GDAP o DAP. Se GDAP e DAP coesistono in un tenant del cliente, le autorizzazioni GDAP hanno la precedenza per i tecnici MSP nei gruppi di sicurezza abilitati per GDAP. Per altre informazioni sui requisiti per Microsoft 365 Lighthouse, vedere Requisiti per Microsoft 365 Lighthouse.

Qual è il modo migliore per passare a GDAP e rimuovere DAP senza perdere l'accesso alle sottoscrizioni di Azure se si hanno clienti con Azure?

La sequenza corretta da seguire per questo scenario è:

  1. Creare una relazione GDAP per Microsoft 365 e Azure.
  2. Assegnare i ruoli di Microsoft Entra ai gruppi di sicurezza per Microsoft 365 e Azure.
  3. Configurare GDAP per avere la precedenza su DAP.
  4. Rimuovere DAP.

Importante

Se non si seguono questi passaggi, gli agenti di Amministrazione esistenti che gestiscono Azure potrebbero perdere l'accesso alle sottoscrizioni di Azure per il cliente.

La sequenza seguente potrebbe comportare la perdita dell'accesso alle sottoscrizioni di Azure:

  1. Rimuovere DAP.

    Non si perde necessariamente l'accesso a una sottoscrizione di Azure rimuovendo DAP. Tuttavia, in questo momento non è possibile esplorare la directory del cliente per eseguire assegnazioni di ruolo di Controllo degli accessi in base al ruolo di Azure, ad esempio l'assegnazione di un nuovo utente cliente come collaboratore del controllo degli accessi in base al ruolo della sottoscrizione.

  2. Creare una relazione GDAP per Microsoft 365 e Azure insieme.

    È possibile che si perda l'accesso alla sottoscrizione di Azure in questo passaggio non appena viene configurato GDAP.

  3. Assegnare i ruoli di Microsoft Entra ai gruppi di sicurezza per Microsoft 365 e Azure

    Dopo il completamento dell'installazione di Azure GDAP di Azure, si otterrà nuovamente l'accesso alle sottoscrizioni di Azure.

Ho clienti con sottoscrizioni di Azure senza DAP. Se si spostano in GDAP per Microsoft 365, si perderà l'accesso alle sottoscrizioni di Azure?

Se si hanno sottoscrizioni di Azure senza DAP gestite come proprietario, aggiungendo GDAP per Microsoft 365 al cliente, è possibile che si perda l'accesso alle sottoscrizioni di Azure. Per evitare questo problema, spostare il cliente in Azure GDAP nello stesso momento in cui si sposta il cliente in Microsoft 365 GDAP.

Importante

Se questi passaggi non vengono seguiti, gli agenti Amministrazione esistenti che gestiscono Azure potrebbero perdere l'accesso alle sottoscrizioni di Azure per il cliente.

No. Le relazioni, una volta accettate, non sono riutilizzabili.

Se si ha una relazione di rivenditore con i clienti senza DAP e chi non ha alcuna relazione GDAP, è possibile accedere alla sottoscrizione di Azure?

Se si ha una relazione di rivenditore esistente con il cliente, è comunque necessario stabilire una relazione GDAP per poter gestire le sottoscrizioni di Azure.

  1. Creare un gruppo di sicurezza (ad esempio, Manager di Azure) in Microsoft Entra.
  2. Creare una relazione GDAP con il ruolo lettore di directory.
  3. Impostare il gruppo di sicurezza come membro del gruppo Amministrazione Agent.

Al termine, sarà possibile gestire la sottoscrizione di Azure del cliente tramite AOBO. La sottoscrizione non può essere gestita tramite l'interfaccia della riga di comando/PowerShell.

È possibile creare un piano di Azure per i clienti senza DAP e che non hanno alcuna relazione GDAP?

Sì, è possibile creare un piano di Azure anche se non è presente alcun DAP o GDAP con una relazione di rivenditore esistente; Tuttavia, per gestire tale sottoscrizione, è necessario DAP o GDAP.

Perché la sezione Dettagli società nella pagina Account in Clienti non visualizza più i dettagli quando viene rimosso DAP?

Quando i partner passano da DAP a GDAP, devono assicurarsi che siano disponibili le informazioni seguenti per visualizzare i dettagli aziendali:

Perché il mio nome utente viene sostituito con "user_somenumber" in portal.azure.com quando esiste una relazione GDAP?

Quando un provider di servizi di configurazione accede al portale di Azure del cliente (portal.azure.come) usando le credenziali CSP e esiste una relazione GDAP, il CSP rileva che il nome utente è "user_" seguito da un numero. Non visualizza il nome utente effettivo come in DAP. Questo si verifica per motivi strutturali.

Screenshot del nome utente che mostra la sostituzione.

Quali sono le sequenze temporali per Stop DAP e grant Default GDAP con la creazione di un nuovo cliente?
Tipo di tenant Data disponibilità Comportamento dell'API del Centro per i partner (POST /v1/customers)
enableGDAPByDefault: true		 Comportamento dell'API del Centro per i partner (POST /v1/customers)
enableGDAPByDefault: false		 Comportamento dell'API del Centro per i partner (POST /v1/customers)
Nessuna modifica alla richiesta o al payload		 Comportamento dell'interfaccia utente del Centro per i partner
Sandbox 25 settembre 2023 (solo API) DAP = No. GDAP predefinito = Sì DAP = No. GDAP predefinito = No DAP = Sì. GDAP predefinito = No GDAP predefinito = Sì
Produzione 10 ottobre 2023 (API e interfaccia utente) DAP = No. GDAP predefinito = Sì DAP = No. GDAP predefinito = No DAP = Sì. GDAP predefinito = No Opt-in/out disponibile: GDAP predefinito
Produzione 27 novembre 2023 (implementazione ga completata il 2 dicembre) DAP = No. GDAP predefinito = Sì DAP = No. GDAP predefinito = No DAP = No. GDAP predefinito = Sì Opt-in/out disponibile: GDAP predefinito

I partner devono concedere in modo esplicito autorizzazioni granulari ai gruppi di sicurezza nel GDAP predefinito.
A partire dal 10 ottobre 2023, DAP non è più disponibile con le relazioni dei rivenditori. Il collegamento aggiornato Request Reseller Relationship è disponibile nell'interfaccia utente del Centro per i partner e l'URL della proprietà "/v1/customers/relationship requests" restituisce l'URL di invito da inviare all'amministratore del tenant del cliente.

Un partner deve concedere autorizzazioni granulari ai gruppi di sicurezza nel GDAP predefinito?

Sì, i partner devono concedere in modo esplicito autorizzazioni granulari ai gruppi di sicurezza nel GDAP predefinito per gestire il cliente.

Quali azioni possono essere eseguite da un partner con la relazione Reseller, ma nessun DAP e nessun GDAP nel Centro per i partner?

I partner con relazione di rivenditore solo senza DAP o GDAP possono creare clienti, effettuare e gestire ordini, scaricare chiavi software, gestire l'istanza riservata di Azure. Non possono visualizzare i dettagli aziendali dei clienti, non possono visualizzare gli utenti o assegnare licenze agli utenti, non possono registrare i ticket per conto dei clienti e non possono accedere e amministrare interfacce di amministrazione specifiche del prodotto (ad esempio, l'interfaccia di amministrazione di Teams).

Per consentire a un partner o APV di accedere e gestire un tenant del cliente, è necessario fornire il consenso all'entità servizio dell'app nel tenant del cliente. Quando DAP è attivo, è necessario aggiungere l'entità servizio dell'app al Amministrazione Agents SG nel tenant partner. Con GDAP, il partner deve assicurarsi che l'app venga acconsentito nel tenant del cliente. Se l'app usa autorizzazioni delegate (App + Utente) e un GDAP attivo esiste con uno dei tre ruoli (Cloud Application Amministrazione istrator, Application Amministrazione istrator, Global Amministrazione istrator) è possibile usare l'API di consenso. Se l'app usa solo le autorizzazioni dell'applicazione, deve essere autorizzato manualmente, dal partner o dal cliente che dispone di uno dei tre ruoli (Applicazione cloud Amministrazione istrator, Application Amministrazione istrator, Global Amministrazione istrator), usando l'URL di consenso amministratore a livello di tenant.

Quale azione deve essere eseguita da un partner per un errore 715-123220 o connessioni anonime per questo servizio?

Se viene visualizzato l'errore seguente:

"Non è possibile convalidare la richiesta "Crea nuova relazione GDAP" in questo momento. Tenere presente che le connessioni anonime non sono consentite per questo servizio. Se si ritiene di aver ricevuto questo messaggio in errore, riprovare la richiesta. Fare clic per informazioni sull'azione che è possibile eseguire. Se il problema persiste, contattare il supporto tecnico e il codice del messaggio di riferimento 715-123220 e ID transazione: guid."

Modificare il modo in cui ci si connette a Microsoft per consentire il corretto funzionamento del servizio di verifica delle identità, in modo da garantire che l'account non sia stato compromesso ed è conforme alle normative che Microsoft deve rispettare.

Operazioni consentite:

  • Cancellare la cache del browser.
  • Disattivare la prevenzione del rilevamento nel browser o aggiungere il sito all'elenco di eccezioni/attendibili.
  • Disattivare qualsiasi programma o servizio di rete privata virtuale (VPN) che si stia eventualmente usando.
  • Connetti direttamente dal dispositivo locale anziché tramite una macchina virtuale (VM).

Dopo aver provato questi passaggi, non è ancora possibile connettersi, è consigliabile consultare l'help desk IT per verificare se le impostazioni possono aiutare a identificare cosa sta causando il problema. A volte il problema riguarda le impostazioni di rete dell'azienda, nel qual caso l'amministratore IT dovrà risolvere il problema, ad esempio, inserendo il sito o altre modifiche alle impostazioni di rete.

Quali azioni GDAP sono consentite per un partner a cui è stato eseguito l'offboarding (con restrizioni, sospese)?
  • Con restrizioni (fatturazione diretta): non è possibile creare un nuovo GDAP (relazioni Amministrazione). È possibile aggiornare i GDAP esistenti e le assegnazioni di ruolo.
  • Sospeso (Direct Bill/Indirect Provider/Indirect Reseller): non è possibile creare un nuovo GDAP. Non è possibile aggiornare i GDAP esistenti e le relative assegnazioni di ruolo.
  • Con restrizioni (fatturazione diretta) + Attivo (rivenditore indiretto): è possibile creare un nuovo GDAP (Amministrazione Relazioni). È possibile aggiornare i GDAP esistenti e le assegnazioni di ruolo.

Offerte

La gestione delle sottoscrizioni di Azure è inclusa in questa versione di GDAP?

Sì. La versione corrente di GDAP supporta tutti i prodotti: Microsoft 365, Dynamics 365, Microsoft Power Platform e Microsoft Azure.