Domande frequenti su GDAP

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

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

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 amministrazione di sei mesi, fino a quando non viene terminata o estesa automaticamente su Disabilitato.

No. La relazione GDAP non supporta le sottoscrizioni acquistate tramite contratti Enterprise.

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

• Se la relazione GDAP con il cliente scade, richiedere di nuovo una relazione GDAP.
• È possibile usare 'analisi delle relazioni GDAP per tenere traccia delle date di scadenza delle relazioni GDAP e prepararsi per il loro rinnovo.

Per estendere o rinnovare una relazione GDAP, un partner o un cliente deve impostare Estensione automatica su Abilitato. Per altre informazioni, vedere Manage GDAP Auto extend and API.

Sì. Se GDAP è attivo, può essere esteso.

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

Sì. È possibile estendere automaticamente qualsiasi GDAP attivo.

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

No. Le autorizzazioni granulari assegnate ai gruppi di sicurezza continuano as-is.

No. Non è possibile estendere automaticamente la relazione di amministratore con un ruolo di amministratore globale.

La pagina Relazioni granulari in scadenza è disponibile solo per gli utenti partner con i ruoli Amministratore globale e Agente di amministrazione. Questa pagina consente di filtrare i GDAP in scadenza in diverse sequenze temporali e di aggiornare l'estensione automatica (abilita/disabilita) per uno o più GDAP.

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

Fare riferimento a Risolvere i problemi di autenticazione a più fattori di Microsoft Entra e Non è possibile 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 per indicazioni.

Un partner deve richiedere l'amministratore di autenticazione con privilegi ruolo Microsoft Entra durante la creazione del primo GDAP.

• Questo ruolo consente a un partner di reimpostare una password e il metodo di autenticazione per un utente amministratore o non amministratore. Il ruolo di amministratore dell'autenticazione con privilegi fa parte dei ruoli configurati da Microsoft Led Tool ed è previsto che sia disponibile con GDAP predefinito durante il flusso di creazione del cliente (previsto per settembre).
• Il partner potrebbe avere l'amministratore del cliente provare Reimpostare la password.
• Per precauzione, il partner deve configurare la reimpostazione della password self-service per i clienti. Per altre informazioni, vedere Consentire agli utenti di reimpostare le proprie password.

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

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

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.

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.

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.

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. Fare riferimento 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 destinati a 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 Introduction to granulard admin privileges (GDAP). Per i criteri destinati ai tenant del provider di servizi di destinazione, usare l'utente del provider di servizi tipo di utente esterno disponibile nelle opzioni di selezione guest o esterni.
• Escludere gli 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 selezionatie 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. Per altre informazioni, vedere:
• 'esperienza api Graph: API Beta con le informazioni sul nuovo tipo di utente esterno
• criteri di accesso condizionale
• utenti esterni con accesso condizionale

Sì. Indipendentemente dal piano di supporto disponibile, il ruolo con privilegi minimi per gli utenti partner può creare ticket di supporto per il cliente è l'amministratore del supporto tecnico.

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.

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

Sì. Un partner può gestire i propri clienti tra aree senza creare nuovi tenant partner per area del cliente. È applicabile solo al ruolo di gestione dei clienti fornito da GDAP (Relazioni di amministratore). Le funzionalità e i ruoli delle transazioni sono ancora limitati alle territorio autorizzato.

No. Un provider di servizi non può far parte di un'organizzazione multi-tenant, ma si escludono a vicenda.

1. Assicurarsi che GDAP sia configurato correttamente, inclusa la modalità di concessione delle autorizzazioni di per i gruppi di sicurezza.
2. Assicurarsi che le autorizzazioni del gruppo di sicurezza granulari siano corrette.
3. Per informazioni, vedere le domande frequenti su Security Copilot.

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

Sì. È consigliabile che i partner usino le API GDAP beta per la produzione e passare successivamente 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.

Sì. È possibile creare relazioni GDAP usando le API, che consente ai partner di ridimensionare questo processo. Tuttavia, la creazione di più relazioni GDAP non è disponibile nel Centro per i partner. Per informazioni sulle API e sulla GDAP, vedere la documentazione per sviluppatori del Centro per i partner .

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.

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 autorizzazioni sia per https://graph.windows.net/Directory.AccessAsUser.All che per https://graph.microsoft.com/Organization.Read.All, effettuare due richieste diverse, una per ognuna.

Usare il collegamento fornito per cercare il nome della risorsa: Verificare le applicazioni Microsoft proprietarie nei report di accesso - Active Directory. Ad esempio, per trovare l'ID risorsa 00000003-0000-0000-c000-000000000000000 graph.microsoft.com 03-

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.
• Correggere la richiesta, per enterpriseApplicationId, usare l'ID risorsa, ad esempio 00000003-0000-0000-c000-000000000000000.

Ad esempio, in precedenza in graph.microsoft.com risorsa è stato concesso solo l'ambito "profilo". È ora necessario aggiungere anche 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.

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

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. Ad 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 privilegio amministratore delegato (DAP) attivo e l'utente è anche membro del gruppo Sicurezza agenti di amministrazione nel tenant partner.
• Si dispone di una relazione Granular Delegated Admin Privilege (GDAP) attiva con il tenant del cliente con almeno uno dei tre ruoli GDAP seguenti e l'assegnazione di accesso è stata completata:
  • Amministratore globale, Amministratore applicazione o Ruolo amministratore applicazione cloud.
  • L'utente partner è membro del gruppo di sicurezza specificato nell'assegnazione di accesso.

• Per gestire Azure con il partizionamento degli accessi per cliente (procedura consigliata), creare un gruppo di sicurezza (ad esempio Manager di Azure) e annidarlo in Agenti di amministrazione.
• Per accedere a una sottoscrizione di Azure come proprietario per un cliente, è possibile assegnare qualsiasi ruolo predefinito di Microsoft Entra (ad esempio, lettori di Directory, il ruolo con privilegi minimi) al gruppo di sicurezza Manager di Azure. Per la procedura per configurare Azure GDAP, vedere Carichi di lavoro supportati da privilegi di amministratore delegati granulari (GDAP).

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.

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

• Per ridurre il divario tra i ruoli di Microsoft Entra disponibili nell'API del Centro per i partner rispetto all'interfaccia utente, un elenco di nove ruoli è disponibile nell'interfaccia utente del Centro per i partner nel mese di luglio 2024.
• In Collaborazione:
  • Amministratore di Microsoft Edge
  • Amministratore visite virtuali
  • Amministratore viva goals
  • Viva Pulse Administrator
  • Amministratore di Yammer
• In Identità:
  • Amministratore gestione autorizzazioni
  • Amministratore flussi di lavoro del ciclo di vita
• In Altro:
  • Amministratore personalizzazione dell'organizzazione
  • Responsabile approvazione messaggi dell'organizzazione

No. Il ruolo con privilegi minimi per gli utenti partner per poter creare ticket di supporto per il cliente è l'amministratore del supporto 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.

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).

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

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

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

È consigliabile rimuovere gli agenti partner dal ruolo agente amministratore 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).

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

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.

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

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.

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.

Gli amministratori guest GDAP non sono in grado di gestire le proprie informazioni di sicurezza in My Security-Info. Hanno 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 sono limitati solo ai metodi registrabili dall'amministratore dei tenant (ovvero SMS o Voce). Per altre informazioni, vedere criteri di accesso tra tenant.

Allinearsi al principio guida di Zero Trust: usare l'accesso con privilegi minimi:

• È consigliabile usare un ruolo con privilegi minimi per attività e attività del carico di lavoro carichi di lavoro supportati da privilegi di amministratore delegato granulari (GDAP) supportati da GDAP.
• Quando è necessario risolvere i problemi noti elencati, rivolgersi al cliente per richiedere un ruolo di amministratore globale associato al tempo.
• È non consigliabile sostituire il ruolo di amministratore globale con tutti i possibili ruoli di Microsoft Entra.

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

DAP e GDAP coesistono durante il periodo di transizione. Tuttavia, alla fine GDAP sta sostituendo DAP per garantire che forniamo una soluzione più sicura per i nostri partner e clienti. Ti consigliamo di passare i tuoi clienti a GDAP il prima possibile per garantire la continuità.

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

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

I partner possono implementare PIM (Privileged Identity Management) 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. Fino a gennaio 2023, era necessario che ogni gruppo di accesso con privilegi (nome precedente per la funzionalità PIM per i gruppi) avesse dovuto trovarsi in un gruppo di assegnabile ai ruoli. Questa restrizione è ora rimossa. Data questa modifica, è possibile abilitare più di 500 gruppi per tenant in PIM, ma solo fino a 500 gruppi possono essere assegnabili a ruoli. Sommario:

• I partner possono usare assegnabili a ruoli e gruppi di non assegnabili a ruoli in PIM. Questa opzione rimuove il limite per 500 gruppi/tenant in PIM.
• Con gli aggiornamenti più recenti, è possibile eseguire l'onboarding di di gruppo in PIM (UX-wise): dal menu PIM o dal menu gruppi di . 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.

GDAP è disponibile a livello generale con supporto per tutti i servizi cloud commerciali Microsoft (Microsoft 365, Dynamics 365, Microsoft Azuree carichi di lavoro di Microsoft Power Platform). Per altre informazioni sul modo in cui DAP e GDAP possono coesistere e su come GDAP ha la precedenza, cercare queste domande frequenti nella Come le autorizzazioni GDAP hanno la precedenza sulle autorizzazioni DAP mentre DAP e GDAP coesistono? domanda.

È possibile eseguire questa azione con le API.

No. Gli utili pec non sono 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.

• 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 Microsoft 365 e Azure contemporaneamente e DAP viene rimosso, la pec non viene persa.
• Se il cliente del partner ha DAP e passa a GDAP per Microsoft 365, ma mantiene Azure as-is (non si spostano in GDAP) e daP viene rimosso, pec non viene perso, ma l'accesso alla sottoscrizione di Azure viene perso.
• Se viene rimosso un ruolo controllo degli accessi in base al ruolo, pec viene perso, ma la rimozione di GDAP non rimuove il controllo degli accessi in base al ruolo.

Quando l'utente fa parte del gruppo di sicurezza GDAP e del gruppo di agenti amministratore DAP 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 carico di lavoro ed è presente DAP per il ruolo di 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 al gruppo di sicurezza GDAP (non agli agenti di amministrazione):

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

DAP e GDAP non sono tipi di associazione idonei per le designazioni di Solutions Partner. aDisabling o transizione da DAP a GDAP non influisce sul raggiungimento delle designazioni di Solutions Partner. Inoltre, il rinnovo dei vantaggi di competenza legacy o dei vantaggi dei partner soluzioni non è interessato. Per visualizzare gli altri tipi di associazione partner idonei per la designazione di Solutions Partner, vedere designazioni partner del Centro per i partner.

Per quanto riguarda la relazione tra Azure Lighthouse e DAP/GDAP, considerarle come percorsi paralleli separati alle risorse di Azure. Severing one 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. Anche l'assegnazione di ruolo controllo degli accessi in base al ruolo di Azure al gruppo Agenti amministratore si trova 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 azure Lighthouse.

Provider di servizi gestiti (MSP) registrati nel programma Cloud Solution Provider (CSP) come rivenditori indiretti o fatturazione diretta partner 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 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 di per Microsoft 365 Lighthouse.

La sequenza corretta da seguire per questo scenario è:

1. Creare una relazione GDAP per sia Microsoft 365 che 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.

La sequenza seguente potrebbe causare perdita di accesso alle sottoscrizioni di Azure:

1. Rimuovere DAP. Non si perde necessariamente l'accesso a una sottoscrizione di Azure rimuovendo DAP. In questo momento, tuttavia, 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. L'accesso alla sottoscrizione di Azure potrebbe andare perso in questo passaggio non appena viene configurato GDAP.
3. Assegnare i ruoli di Microsoft Entra ai gruppi di sicurezza per Microsoft 365 e Azure

L'accesso alle sottoscrizioni di Azure viene recuperato al termine dell'installazione di GDAP di Azure.

Se si dispone di sottoscrizioni di Azure senza DAP gestito come proprietario, quando si aggiunge GDAP per Microsoft 365 a tale cliente, si potrebbe perdere l'accesso alle sottoscrizioni di Azure. Per evitare di perdere l'accesso, spostare il cliente in GDAP di Azure contemporaneamente che si sposta il cliente in Microsoft 365 GDAP.

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

Se si ha una relazione di rivenditore esistente con il cliente, è comunque necessario stabilire una relazione GDAP per 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 di lettura della directory .
3. Impostare il gruppo di sicurezza come membro del gruppo Admin Agent. Dopo aver eseguito questi passaggi, è possibile gestire la sottoscrizione di Azure del cliente tramite AOBO. Non è possibile gestire la sottoscrizione tramite l'interfaccia della riga di comando o PowerShell.

Sì. È possibile creare un piano di Azure anche se non esiste una relazione DAP o GDAP con una relazione rivenditore esistente. Ma per gestire tale sottoscrizione, è necessario DAP o GDAP.

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

• Relazione GDAP attiva.
• A uno dei seguenti ruoli di Microsoft Entra vengono assegnati: Amministratore globale, Lettori directory, Lettore globale. Fare riferimento a concedere autorizzazioni granulari ai gruppi di sicurezza.

Quando un CSP accede al portale di Azure del cliente (portal.azure.come) usando le credenziali CSP e esiste una relazione GDAP, il CSP nota che il nome utente è "user_" seguito da un numero. Non visualizza il nome utente effettivo come in DAP. È per progettazione.

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.

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

I partner con relazione di rivenditore solo senza DAP o GDAP possono creare clienti, effettuare e gestire ordini, scaricare le 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 all'amministratore 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 (Amministratore applicazioni cloud, Amministratore applicazioni, Amministratore applicazioni globali) api di consenso può essere usata. 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 (Amministratore applicazione cloud, Amministratore applicazioni, Amministratore globale), usando URL di consenso amministratore a livello di tenant.

Se viene visualizzato l'errore seguente:

"Al momento non è possibile convalidare la richiesta "Crea nuova relazione GDAP". 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. Selezionare questa opzione per informazioni sulle azioni 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 la modalità di connessione a Microsoft per consentire il corretto funzionamento del servizio di verifica delle identità. Garantisce che l'account non sia compromesso ed è conforme alle normative a cui Microsoft deve rispettare.

Operazioni che è possibile eseguire:

• 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 vpn (Virtual Private Network) che si potrebbe usare.
• Connettersi direttamente dal dispositivo locale anziché tramite una macchina virtuale.

Se dopo aver provato i passaggi precedenti, non è ancora possibile connettersi, è consigliabile consultare l'help desk IT per verificare le impostazioni per verificare se possono aiutare a identificare cosa sta causando il problema. In alcuni casi, il problema riguarda le impostazioni di rete dell'azienda. L'amministratore IT dovrà risolvere il problema, ad esempio, elencando il sito o apportando altre modifiche alle impostazioni di rete.

• Con restrizioni (fatturazione diretta): non è possibile creare un nuovo GDAP (Relazioni amministrative). È 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): per la fattura diretta con restrizioni: non è possibile creare un nuovo GDAP (relazioni di amministrazione). È possibile aggiornare i GDAP esistenti e le assegnazioni di ruolo. Per rivenditore indiretto attivo: è possibile creare nuovi GDAP esistenti e aggiornare le assegnazioni di ruolo. Quando non è possibile creare un nuovo GDAP in modalità offboarding, non è possibile aggiornare i GDAP esistenti e le assegnazioni di ruolo.

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