Nejčastější dotazy k GDAP

příslušné role: Všichni uživatelé, kteří se zajímají o Partnerské centrum

Podrobná delegovaná oprávnění správce (GDAP) poskytují partnerům přístup k úlohám zákazníků způsobem, který je podrobnější a časově omezené, což může pomoct řešit problémy se zabezpečením zákazníků.

S GDAP mohou partneři poskytovat více služeb zákazníkům, kteří se mohou cítit nepříjemně s vysokou úrovní přístupu partnerů.

GDAP také pomáhá zákazníkům, kteří mají regulační požadavky na poskytování pouze přístupu s minimálními oprávněními partnerům.

Nastavení GDAP

Kdo může požádat o vztah GDAP?

Někdo, kdo má roli administrátora v partnerské organizaci, může vytvořit žádost o vztah GDAP.

Vyprší platnost žádosti o vztah GDAP, pokud zákazník neprovede žádnou akci?

Ano. Platnost žádostí o vztah GDAP vyprší po 90 dnech.

Můžu vytvořit vztah GDAP s trvalým zákazníkem?

Ne. Trvalé vztahy GDAP se zákazníky nejsou z bezpečnostních důvodů možné. Maximální doba trvání relace GDAP je dva roky. Můžete nastavit Automatické rozšíření na Povoleno, aby prodloužilo vztah správce o šest měsíců, dokud nebude ukončen nebo dokud nebude automatické rozšíření nastaveno na Zakázáno.

Může se vztah GDAP se zákazníkem automaticky rozšířit?

Ano. Relace GDAP se může automaticky prodloužit o šest měsíců, dokud není ukončena nebo než je automatické prodloužení nastaveno na Zakázáno.

Co mám dělat, když vyprší platnost vztahu GDAP se zákazníkem?

• Pokud vyprší platnost relace GDAP s vaším zákazníkem, požádat o relaci GDAP znovu.
• Pomocí analýzy relací GDAP můžete sledovat data vypršení platnosti relací GDAP a připravit se na jejich prodloužení.

Jak může zákazník prodloužit nebo obnovit vztah GDAP?

Pokud chcete prodloužit nebo obnovit vztah GDAP, musí partner nebo zákazník nastavit Automatické prodloužení na Povoleno. Další informace najdete ve správě automatického prodloužení GDAP a API.

Je možné automaticky prodloužit platnost aktivního GDAP, který brzy vyprší?

Ano. Pokud je GDAP aktivní, můžete ho rozšířit.

Kdy začne automatické rozšíření fungovat?

Řekněme, že se GDAP vytvoří na dobu 365 dnů, kdy je automatické prodloužení povoleno. 365. den se koncové datum efektivně aktualizuje o 180 dní.

Je možné automaticky rozšířit GDAP vytvořený pomocí nástroje PlT (Partner Led Tool), Microsoft Led Tool, uživatelského rozhraní Partnerského centra nebo rozhraní API Partnerského centra?

Ano. Můžete automaticky rozšířit libovolnou aktivní GDAP.

Vyžaduje se souhlas zákazníka k nastavení automatického rozšíření proti stávajícím aktivním GDAP?

Ne. Souhlas zákazníka není nutný k nastavení automatického rozšíření na Povoleno pro stávající aktivní GDAP.

Mají se podrobná oprávnění znovu přiřadit skupinám zabezpečení po automatickém rozšíření?

Ne. Podrobná oprávnění přiřazená skupinám zabezpečení zůstávají nezměněna.

Je možné automaticky rozšířit vztah správce s rolí globálního správce?

Ne. Vztah správce nelze automaticky prodloužit s rolí globálního správce.

Proč se mi v pracovním prostoru Zákazníci nezobrazuje stránka **Expirující podrobné vztahy**?

Stránka Expirující granulární vztahy je dostupná pouze pro partnerské uživatele s rolemi administrativního agenta. Tato stránka pomáhá filtrovat GDAPs, jejichž platnost vyprší v různých obdobích, a pomáhá aktualizovat automatické prodloužení (povolení nebo zakázání) pro jednu nebo více GDAPs.

Pokud vyprší platnost relace GDAP, ovlivní to stávající předplatná zákazníka?

Ne. Když vyprší platnost relace GDAP, nedojde k žádné změně stávajících předplatných zákazníka.

Jak může zákazník resetovat svoje heslo a zařízení MFA, pokud je jeho účet uzamčený a nemůže od partnera přijmout žádost o vztah GDAP?

Pokyny najdete v tématu Řešení problémů s Microsoft Entra vícefaktorovým ověřováním a Nelze použít Microsoft Entra vícefaktorové ověřování pro přihlášení ke cloudovým službám po ztrátě telefonu nebo změně telefonního čísla.

Jaké role potřebuje partner k resetování hesla správce a zařízení pro vícefaktorové ověřování, pokud je správce zákazníka vyloučen z přístupu ke svému účtu a nemůže přijmout žádost o vztah GDAP od partnera?

Partner musí při vytváření první GDAP požádat o roli Správce s privilegovaným ověřováním Microsoft Entra.

• Tato role umožňuje partnerovi resetovat heslo a metodu ověřování pro správce nebo uživatele bez oprávnění správce. Role správce privilegovaného ověřování je součástí rolí nastavených nástrojem Microsoft-led a plánuje se, že bude k dispozici s výchozím GDAP během procesu vytváření zákazníka (dostupné od září).
• Partner může požádat správce zákazníka, aby zkusil Resetovat heslo.
• Jako preventivní opatření musí partner pro své zákazníky nastavit samoobslužné resetování hesla. Další informace najdete v tématu Umožnit uživatelům resetovat vlastní hesla.

Kdo obdrží e-mail s oznámením o ukončení vztahu GDAP?

• V organizaci partnera obdrží oznámení o ukončení lidé s rolí Admin agent.
• V organizaci zákazníka obdrží oznámení o ukončení lidé s rolí globálního správce.

Můžu se v protokolech aktivit podívat, kdy zákazník odebere GDAP?

Ano. Partneři můžou zjistit, kdy zákazník odebere GDAP v protokolech aktivit v Partnerském centru.

Musím vytvořit vztah GDAP se všemi svými zákazníky?

Ne. GDAP je volitelná možnost pro partnery, kteří chtějí spravovat služby zákazníka podrobnějším a časově ohraničeným způsobem. Můžete zvolit, se kterými zákazníky chcete vytvořit relaci GDAP.

Pokud mám více zákazníků, potřebuji pro tyto zákazníky mít více skupin zabezpečení?

Odpověď závisí na tom, jak chcete spravovat zákazníky.

• Pokud chcete, aby vaši partneři mohli spravovat všechny zákazníky, můžete všechny své partnerské uživatele umístit do jedné skupiny zabezpečení a že jedna skupina může spravovat všechny vaše zákazníky.
• Pokud dáváte přednost tomu, aby různí uživatelé partnerů spravovali různé zákazníky, přiřaďte tyto uživatele partnerů k oddělení skupin zabezpečení pro izolaci zákazníků.

Můžou nepřímí prodejci vytvářet žádosti o vztahy GDAP v Partnerském centru?

Ano. Nepřímí prodejci (a nepřímí poskytovatelé a partneři s přímým vyúčtováním) můžou vytvářet žádosti o vztahy GDAP v Partnerském centru.

Proč nemůže partner s GDAP přistupovat k úloze jako AOBO (správce jménem uživatele)?

V rámci nastavení GDAP se ujistěte, že jsou vybrány skupiny zabezpečení, které byly vytvořeny v partnerském tenantovi s uživateli partnera. Ujistěte se také, že požadované Microsoft Entra role jsou přiřazené ke skupině zabezpečení. Projděte si Assign Microsoft Entra role.

Jaký je doporučený další krok, pokud zásady podmíněného přístupu nastavené zákazníkem zablokují veškerý externí přístup, včetně přístupu správce přístupu CSP jménem tenanta zákazníka?

Zákazníci teď můžou vyloučit poskytovatele cloudových služeb ze zásad podmíněného přístupu, aby partneři mohli přejít na GDAP bez blokování.

• Zahrnout uživatele – Tento seznam uživatelů obvykle zahrnuje všechny uživatele, na které organizace cílí, v zásadách podmíněného přístupu.
• Při vytváření zásad podmíněného přístupu jsou k dispozici následující možnosti:
• Výběr uživatelů a skupin
• Hosté nebo externí uživatelé (Preview)
• Tento výběr nabízí několik možností, které lze použít k cílení zásad podmíněného přístupu na konkrétní typy hostů nebo externích uživatelů a konkrétní tenanty obsahující tyto typy uživatelů. Existuje několik různých typů hosta nebo externích uživatelů, které je možné vybrat, a je možné vybrat několik možností:
• Uživatelé poskytovatele služeb, například poskytovatel cloudových řešení (CSP).
• Pro vybrané typy uživatelů můžete zadat jednoho nebo více tenantů nebo můžete zadat všechny tenanty.
• přístup externího partnera – zásady podmíněného přístupu, které cílí na externí uživatele, můžou kolidovat s přístupem poskytovatele služeb, například podrobná delegovaná oprávnění správce. Další informace najdete v tématu Úvod k podrobným delegovaným oprávněním správce (GDAP). cs-CZ: Pro zásady zaměřené na nájemníky poskytovatelů služeb použijte typ externího uživatele Poskytovatel služby, který je k dispozici v možnostech výběru Host nebo externí uživatelé.
• vyloučit uživatele – pokud organizace zahrnují i vylučují uživatele nebo skupinu, je uživatel nebo skupina ze zásady vyloučen, protože akce vyloučení přepíše akci zahrnutí do zásad.
• Při vytváření zásad podmíněného přístupu můžete vyloučit následující možnosti:
• Host nebo externí uživatelé
• Tento výběr nabízí několik možností, které lze použít k cílení zásad podmíněného přístupu na konkrétní typy hostů nebo externích uživatelů a konkrétní tenanty obsahující tyto typy uživatelů. Existuje několik různých typů hosta nebo externích uživatelů, kteří mohou být vybránia lze provést několik výběrů:
• Uživatelé poskytovatele služeb, například poskytovatele cloudových řešení (CSP)
• Pro vybrané typy uživatelů je možné zadat jednoho nebo více tenantů nebo můžete zadat všechny tenanty. Další informace najdete zde:
• Zkušenost s Graph API: API beta s informacemi o novém typu externího uživatele
• zásad podmíněného přístupu
• Podmíněný přístup externím uživatelům

Potřebuji mít vztah GDAP k vytváření tiketů podpory, i když mám službu Premier Support for Partners?

Ano. Bez ohledu na plán podpory, který máte, je nejnižší privilegovanou rolí pro uživatele partnerů, kteří budou moct vytvářet lístky podpory pro zákazníka, správce podpory služeb.

Může být GDAP ve stavu **Čeká na schválení** ukončen partnerem?

Ne. Partner momentálně nemůže ukončit GDAP ve stavu Schválení čeká na vyřízení. Pokud zákazník neudělá žádnou akci, vyprší za 90 dnů.

Po ukončení relace GDAP můžu znovu použít stejný název relace GDAP k vytvoření nové relace?

Až po uplynutí 365 dnů (vyčištění) po ukončení nebo vypršení platnosti relace GDAP můžete znovu použít stejný název k vytvoření nové relace GDAP.

Může partner v jedné oblasti spravovat své zákazníky v různých oblastech?

Ano. Partner může spravovat své zákazníky napříč oblastmi bez vytváření nových partnerských tenantů pro každou oblast zákazníka. Vztahuje se pouze na roli správy zákazníků, kterou poskytuje GDAP (vztahy správců). Role a možnosti transakcí jsou stále omezené na vaše autorizované teritorium.

Může být poskytovatel služeb součástí víceklientských organizací, co je Error-Action 103?

Ne. Poskytovatel služeb nemůže být součástí víceklientských organizací, které se vzájemně vylučují.

Co mám dělat, když se při přechodu na Microsoft Security Copilot na stránce Správy služeb v Partnerském centru zobrazí chyba Nejde získat informace o účtu?

1. Ujistěte se, že je GDAP správně nastavený, včetně způsobu udělení oprávnění pro skupiny zabezpečení.
2. Ujistěte se, že jsou správná podrobná oprávnění skupiny zabezpečení .
3. Nápovědu najdete v Security Copilot nejčastějších dotazech.

Mohou poskytovatel CSP a zákazník se vztahem GDAP vytvořit víceklientskou organizaci?

Možnosti víceklientských organizací nejsou podporovány mezi poskytovatelem CSP a zákazníkem, který má vztah GDAP. Možnosti GDAP umožňují partnerovi CSP spravovat služby Microsoft pro jinou organizaci. Funkce víceklientské organizace jsou určeny pro použití mezi klienty vlastněnými stejnou organizací.

GDAP API

Jsou k dispozici rozhraní API pro vytvoření vztahu GDAP se zákazníky?

Další informace o rozhraních API a GDAP najdete v dokumentaci pro vývojáře v partnerském centru .

Můžu pro produkční prostředí používat beta rozhraní API GDAP?

Ano. Doporučujeme, aby partneři používali beta rozhraní API GDAP pro produkční a pozdější přechod na rozhraní API v.1, jakmile budou k dispozici. I když existuje upozornění, že použití těchto rozhraní API v produkčních aplikacích není podporováno, toto obecné doporučení platí pouze pro jakékoli beta rozhraní API pod Graph a není použitelné na beta verzi GDAP Graph API.

Můžu vytvořit více relací GDAP s různými zákazníky najednou?

Ano. Relace GDAP můžete vytvářet pomocí rozhraní API, která partnerům umožní škálovat tento proces. Vytváření více relací GDAP ale není k dispozici v Partnerském centru. Informace o rozhraních API a GDAP najdete v dokumentaci pro vývojáře v partnerském centru .

Je možné v relaci GDAP přiřadit více skupin zabezpečení pomocí jednoho volání rozhraní API?

API funguje pouze pro jednu skupinu zabezpečení najednou, ale v Centru pro partnery můžete přiřadit více skupin zabezpečení k více rolím.

Jak můžu pro aplikaci požádat o více oprávnění k prostředkům?

Proveďte jednotlivá volání pro každý prostředek. Při vytváření jednoho požadavku POST předejte pouze jeden prostředek a jeho odpovídající obory. Pokud například chcete požádat o oprávnění pro https://graph.microsoft.com/Directory.AccessAsUser.All i https://graph.microsoft.com/Organization.Read.All, proveďte dva různé požadavky, jednu pro každou.

Jak najdu ID prostředku pro daný prostředek?

Pomocí poskytnutého odkazu vyhledejte název prostředku: Ověření prvotních aplikací Microsoft v sestavách přihlašování – služba Active Directory. Pokud chcete například najít ID prostředku 00000003-0000-0000-c000-0000000000000 pro graph.microsoft.com:

Co mám dělat, když se zobrazí chyba "Request_UnsupportedQuery" se zprávou: "Nepodporovaná nebo neplatná klauzule filtru dotazu zadaná pro vlastnost appId prostředku ServicePrincipal"?

K této chybě obvykle dochází při použití nesprávného identifikátoru ve filtru dotazu. Pokud chcete tento problém vyřešit, ujistěte se, že používáte vlastnost enterpriseApplicationId se správným ID prostředku , nikoli názvem prostředku.

• Nesprávný požadavek U enterpriseApplicationId nepoužívejte název prostředku, jako je graph.microsoft.com.
• Správný požadavek Místo toho, pro enterpriseApplicationId, použijte ID zdroje, například 00000003-0000-0000-c000-000000000000.

Jak mohu přidat nové obory do prostředku aplikace, u které již byl udělen souhlas v tenantu zákazníka?

Například v prostředku graph.microsoft.com byl dříve udělen pouze rozsah profilu. Teď potřebujeme přidat také profil a user.read. Přidání nových oborů do dříve odsouhlasené aplikace:

1. K odvolání souhlasu stávající aplikace uděleného tenantovi zákazníka použijte metodu DELETE.
2. Pomocí metody POST vytvořte nový souhlas aplikace s dalšími rozsahy oprávnění.

Poznámka

Pokud vaše aplikace vyžaduje oprávnění pro více prostředků, spusťte pro každý prostředek metodu POST samostatně.

Jak určím více oborů pro jeden prostředek (enterpriseApplicationId)?

Zřetězte požadované obory pomocí čárky a mezery. Například „scope“: „profile, User.Read“

Co mám dělat, když se zobrazí chyba 400 Chybný požadavek se zprávou "Nepodporovaný token". Nelze inicializovat kontext autorizace?

1. Ověřte, že vlastnosti displayName a applicationId v textu požadavku jsou přesné a odpovídají aplikaci, se kterou se pokoušíte souhlasit s tenantem zákazníka.
2. Ujistěte se, že používáte stejnou aplikaci k vygenerování přístupového tokenu, ke kterému se pokoušíte udělit souhlas s tenantem zákazníka. Například: Pokud je ID aplikace "12341234-1234-1234-12341234", deklarace identity "appId" v přístupovém tokenu by měla být také "12341234-1234-1234-12341234".
3. Ověřte splnění jedné z následujících podmínek:

• Máte aktivní oprávnění delegovaného správce (DAP) a uživatel je také členem skupiny zabezpečení Agenti pro správu v partnerském tenantovi.
• Máte aktivní vztah Granulárního Delegovaného Administrativního Oprávnění (GDAP) s tenantem zákazníka s alespoň jednou z následujících tří rolí v rámci GDAP, a dokončili jste přiřazení přístupu.
  • Správce aplikací nebo role Správce cloudových aplikací
  • Partner uživatel je členem skupiny zabezpečení zadané v přiřazení přístupu.

Role

Které role GDAP jsou potřeba pro přístup k Azure předplatnému?

• Pokud chcete spravovat Azure pomocí dělení na jednotlivé zákazníky (což je doporučený postup), vytvořte skupinu zabezpečení (například Azure Manažeři) a vložit ji pod Admin agenty.
• Pokud chcete získat přístup k předplatnému Azure jako vlastník pro zákazníka, můžete přiřadit libovolnou vestavěnou roli Microsoft Entra (například Čtenáři adresáře, nejméně privilegovanou roli) skupině zabezpečení Azure Managers. Postup nastavení Azure GDAP najdete v tématu Workloads podporované podrobnými delegovanými oprávněními správce (GDAP).

Existují pokyny k nejméně privilegovaným rolím, které můžu přiřadit uživatelům pro konkrétní úlohy?

Ano. Informace o tom, jak omezit oprávnění správce uživatele přiřazením nejméně privilegovaných rolí v Microsoft Entra, najdete v tématu Náležení privilegovaných rolí podle úlohy v Microsoft Entra.

Jaká je nejméně privilegovaná role, kterou můžu přiřadit tenantovi zákazníka a přitom vytvořit podpůrné tikety pro zákazníka?

Doporučujeme přiřadit roli správce podpory služby. Další informace najdete v tématu Nejníže privilegované role dle úlohy v Microsoft Entra.

Které Microsoft Entra role byly zpřístupněny v uživatelském rozhraní Partnerského centra v červenci 2024?

• Aby se snížila mezera mezi Microsoft Entra rolemi dostupnými v rozhraní API Partnerského centra a uživatelským rozhraním, seznam devíti rolí je k dispozici v uživatelském rozhraní Partnerského centra v červenci 2024.
• V části Spolupráce:
  • správce Microsoft Edge
  • Správce virtuálních návštěv
  • správce Viva Goals
  • Viva Pulse Administrátor
  • Správce Yammeru
• V části Identita:
  • Správce správy oprávnění
  • Správce pracovních postupů životního cyklu
• V části Jiné:
  • Správce brandingu organizace
  • Schvalovatel zpráv organizace

Které Microsoft Entra role byly zpřístupněny v uživatelském rozhraní Partnerského centra v prosinci 2024?

• Aby se snížila mezera mezi Microsoft Entra rolemi dostupnými v rozhraní API Partnerského centra a uživatelským rozhraním, byl v prosinci 2024 zpřístupněn seznam 17 rolí.
• V části Spolupráce:
  • Analytik přehledů
  • správce migrace Microsoft 365
  • Zapisovatel zpráv organizace
  • Vestavěný administrátor SharePoint
  • Správce telefonních služeb Teams
  • Správce úspěchu uživatelského prostředí
• V části Zařízení:
  • správce záruky hardwaru Microsoft
  • Microsoft Specialista na záruku hardwaru
• V části Identita:
  • Správce přiřazení atributů
  • Čtenář přiřazení atributů
  • Správce definic atributů
  • Čtečka definic atributů
  • Správce protokolu atributů
  • Čtenář protokolu atributů
  • Správce rozšiřitelnosti ověřování
  • Globální správce zabezpečeného přístupu
  • Tvůrce tenanta

Můžu otevřít lístky podpory pro zákazníka ve vztahu GDAP, ze kterého jsou vyloučeny všechny role Microsoft Entra?

Ne. Nejmíň privilegovaná role pro uživatele partnera, aby mohli vytvářet lístky podpory pro zákazníka, je správce podpory služby service. Aby bylo možné vytvářet podporované tikety pro zákazníka, musí být partnerský uživatel členem bezpečnostní skupiny a mít přiřazenou roli k tomuto zákazníkovi.

Kde najdu informace o všech rolích a úlohách zahrnutých v GDAP?

Informace o všech rolích najdete v tématu Microsoft Entra vestavěné role. Informace o úlohách najdete v tématu Úlohy podporované podrobnými delegovanými oprávněními správce (GDAP).

Jaká role GDAP poskytuje přístup k centru Správa Microsoftu 365?

Mnoho rolí se používá pro Správa Microsoftu 365 Center. Další informace najdete v tématu Používané role Centrum pro správu Microsoftu 365.

Můžu pro GDAP vytvořit vlastní skupiny zabezpečení?

Ano. Vytvořte skupinu zabezpečení, přiřaďte schválené role a pak k této skupině zabezpečení přiřaďte uživatele partnerského tenanta.

Které role GDAP poskytují přístup jen pro čtení k předplatným zákazníka, a proto jim nedovolují, aby je uživatel spravoval?

Přístup k předplatným zákazníka pro čtení poskytují role Globální čtenář, Čtenář adresáře a role Partner podpory úrovně 2.

Jakou roli mám přiřadit svým agentům partnerů (aktuálně agentům pro správu), pokud chci, aby spravovali tenanta zákazníka, ale neupravovali předplatná zákazníka?

Doporučujeme odebrat partnerské agenty z agenta správce roli a přidat je jenom do skupiny zabezpečení GDAP. Tímto způsobem můžou spravovat služby (například správa služeb a žádosti o službu protokolů), ale nemůžou kupovat a spravovat předplatná (změna množství, zrušení, plánování změn atd.).

Co se stane, když zákazník partnerovi udělí role GDAP a poté odstraní role nebo ukončí vztah GDAP?

Skupiny zabezpečení přiřazené k relaci ztratí přístup k danému zákazníkovi. Totéž se stane, když zákazník ukončí relaci DAP.

Může partner pokračovat v transakci pro zákazníka po odebrání veškerého vztahu GDAP se zákazníkem?

Ano. Odebrání vztahů GDAP se zákazníkem neukončí partnerský prodejní vztah se zákazníkem. Partneři můžou dál nakupovat produkty pro zákazníka a spravovat Azure rozpočet a další související aktivity.

Můžou některé role v mém vztahu GDAP s mým zákazníkem mít delší dobu na vypršení platnosti než jiné?

Ne. Všechny role v relaci GDAP mají stejnou dobu k vypršení platnosti: doba trvání zvolená při vytvoření relace.

Potřebuji GDAP k plnění objednávek pro nové a stávající zákazníky v Partnerském centru?

Ne. Ke splnění objednávek pro nové a stávající zákazníky nepotřebujete GDAP. Ke splnění objednávek zákazníků v Partnerském centru můžete dál používat stejný postup.

Musím přiřadit jednu roli agenta partnera všem zákazníkům, nebo můžu přiřadit roli agenta partnera jenom jednomu zákazníkovi?

Relace GDAP jsou pro jednotlivé zákazníky. Pro každého zákazníka můžete mít více vztahů. Každý vztah GDAP může mít různé role a používat různé skupiny Microsoft Entra v CSP Tenant. V Partnerském centru funguje přiřazení rolí na úrovni vztahu zákazníka k GDAP. Pokud chcete přiřazení role s více zákazníky automatizovat pomocí rozhraní API, můžete tak učinit.

Může mít partner uživatel role GDAP a účet hosta?

Ne. Účty hostů nefungují s GDAP. Zákazníci musí odebrat všechny účty hostů, aby GDAP fungovaly.

Proč nemůžou správci GDAP + B2B přidávat metody ověřování v aka.ms/mysecurityinfo?

Správci hostů GDAP nemůžou spravovat své bezpečnostní informace na Moje bezpečnostní informace. Místo toho potřebují pomoc správce tenanta, v kterém jsou hostem, pro registraci, aktualizaci nebo odstranění bezpečnostních údajů. Organizace mohou nakonfigurovat zásady přístupu mezi tenanty tak, aby důvěřovaly vícefaktorovému ověřování od důvěryhodného tenanta CSP. V opačném případě jsou správci hosta GDAP omezeni pouze na metody, které může zaregistrovat správce tenantů, což je krátká služba zpráv (SMS) nebo Hlas. Další informace se dozvíte v zásadách přístupu mezi tenanty.

Jaké role může partner použít k povolení automatického rozšíření?

Zarovnejte se s vedoucím principem nulová důvěra (Zero Trust): Použijte přístup s minimálními oprávněními:

• Doporučujeme použít nejméně privilegovanou roli podle úloh a úkoly v zátěži podporované podrobnými delegovanými oprávněními správce (GDAP).
• Pokud je potřeba vyřešit uvedené známé problémy, požádejte zákazníka o roli globálního správce vázané na čas.
• Nedoporučujeme nahrazovat roli globálního správce všemi dostupnými rolemi Microsoft Entra.

DAP a GDAP

Nahrazuje GDAP DAP?

Ano. Během přechodného období bude daP a GDAP existovat společně s oprávněními GDAP, která mají přednost před oprávněními DAP pro úlohy Microsoft 365, Dynamics 365 a Azure.

Můžu dál používat DAP nebo musím převést všechny své zákazníky na GDAP?

DAP a GDAP existují společně během přechodného období. Nakonec ale GDAP nahrazuje DAP, abychom zajistili bezpečnější řešení pro naše partnery a zákazníky. Doporučujeme, abyste zákazníky co nejdříve převést na GDAP, abyste zajistili kontinuitu.

Zatímco DAP a GDAP spolu existují, existují nějaké změny ve způsobu vytváření relace DAP?

Stávající tok relace DAP se nijak nemění, zatímco daP a GDAP spolu existují.

Jaké Microsoft Entra role by byly uděleny pro výchozí GDAP jako součást vytvoření zákazníka?

DAP se v současné době uděluje při vytvoření nového zákaznického tenanta. Dne 25. září 2023 Microsoft už neuděluje daP pro vytvoření nového zákazníka a místo toho uděluje výchozí GDAP s konkrétními rolemi. Výchozí role se liší podle typu partnera, jak je znázorněno v následující tabulce:

Microsoft Entra role udělené pro výchozí GDAP	Partneři s přímým vyúčtováním	Nepřímí zprostředkovatelé	Nepřímí prodejci	Partneři domény	dodavatelé ovládacích panelů (CPV)	Advisor	Odhlášení z výchozího GDAP (bez DAP)
1. Čtenáři adresáře. Může číst základní informace o adresáři. Běžně se používá k udělení přístupu ke čtení adresáře aplikacím a hostům.	x	x	x	x	x
2. tvůrců adresářů. Může číst a zapisovat základní informace o adresáři. Pro udělení přístupu k aplikacím, které nejsou určené pro uživatele.	x	x	x	x	x
3. správce licencí. Může spravovat licence produktů pro uživatele a skupiny.	x	x	x	x	x
4. správce podpory služeb. Může číst informace o stavu služeb a spravovat lístky podpory.	x	x	x	x	x
5. správce uživatelů. Může spravovat všechny aspekty uživatelů a skupin, včetně resetování hesel pro omezené správce.	x	x	x	x	x
6. správce privilegovaných rolí. Může spravovat přiřazení rolí v Microsoft Entra a všechny aspekty Privileged Identity Management.	x	x	x	x	x
7. správce helpdesku. Může resetovat hesla pro správce, kteří nejsou správci a správci helpdesku.	x	x	x	x	x
8. správce privilegovaného ověřování. Má právo zobrazovat, nastavovat a resetovat informace o způsobu ověřování pro libovolného uživatele (administrátor nebo běžný uživatel).	x	x	x	x	x
9. správce cloudových aplikací. Může vytvářet a spravovat všechny aspekty registrace aplikací a podnikových aplikací kromě proxy aplikací.	x	x		x	x
10. správce aplikací. Může vytvářet a spravovat všechny aspekty registrace aplikací a podnikových aplikací.	x	x		x	x
11. Globální Čtenář. Může číst všechno, co Globální správce může, ale nemůže nic aktualizovat.	x	x	x	x	x
12. správce externího zprostředkovatele identity. Může spravovat federaci mezi Microsoft Entra organizacemi a externími zprostředkovateli identit.				x
13. správce názvu domény. Může spravovat názvy domén v cloudu a v místním prostředí.				x

Jak GDAP funguje s Privileged Identity Management v Microsoft Entra?

Partneři můžou implementovat Privileged Identity Management (PIM) ve skupině zabezpečení GDAP v tenantovi partnera, aby zvýšili přístup několika uživatelů s vysokými oprávněními, a to za běhu (JIT), aby jim udělili role s vysokými oprávněními, jako jsou správci hesel s automatickým odebráním přístupu. Do ledna 2023 bylo nutné, aby každá privilegovaná skupina přístupu (dřívější název pro funkci PIM for Groups) byla v přiřaditelné roli skupiny. Toto omezení je nyní odebráno. Vzhledem k této změně je možné povolit více než 500 skupin na tenanta vPIM, ale pouze 500 skupin je možné přiřadit role. Shrnutí:

• Partneři mohou v PIM používat jak přiřaditelné, tak i nepřiřaditelné skupiny rolí. Tato možnost účinně odstraňuje limit 500 skupin na tenant v PIM.
• S nejnovějšími aktualizacemi existují dva způsoby, jak připojit skupiny k PIM (UX) z nabídky PIM nebo z nabídky Skupiny. Bez ohledu na způsob, jakým zvolíte, je čistý výsledek stejný.
  • Možnost přidání skupin, které lze nebo nelze přiřadit rolí, prostřednictvím nabídky PIM je již dostupná.
  • Možnost přidání skupin s přiřaditelnou rolí a bez přiřaditelné role prostřednictvím nabídky Skupiny je již dostupná.
• Další informace najdete v tématu Privileged Identity Management (PIM) pro skupiny (Preview) – Microsoft Entra.

Jak může dap a GDAP existovat, pokud zákazník koupí Microsoft Azure a Microsoft 365 nebo Dynamics 365?

GDAP je obecně dostupná s podporou všech Microsoft komerčních cloudových služeb (Microsoft 365, Dynamics 365, Microsoft Azure a Microsoft Power Platform úloh). Další informace o tom, jak mohou DAP a GDAP koexistovat a jak má GDAP přednost, najdete v části nejčastějších dotazů pod otázkou Jak mají oprávnění GDAP přednost před oprávněními DAP, když DAP a GDAP koexistují?.

Mám velkou zákaznickou základnu (například 10 000 zákaznických účtů). Jak můžu přejít z DAP na GDAP?

Tuto akci můžete provést pomocí rozhraní API.

Jsou příjmy v rámci partnerem získaného kreditu (PEC) ovlivněny, když přecházím z DAP na GDAP? Existuje nějaký vliv na odkaz pro správce partnera (PAL)?

Ne. Vaše příjmy PEC se při přechodu na GDAP nedotknou. V rámci přechodu nedochází k žádným změnám v PAL, takže můžete i nadále získávat PEC.

Je PEC ovlivněna po odebrání DAP/GDAP?

• Pokud má zákazník partnera pouze DAP a DAP se odstraní, PEC se neztratí.
• Pokud má zákazník partnera DAP a přejde na GDAP pro Microsoft 365 a Azure současně a DAP se odebere, PEC se neztratí.
• Pokud má zákazník partnera DAP a přejde na GDAP pro Microsoft 365, ale ponechá Azure beze změny (nepřesunou se do GDAP) a DAP se odstraní, PEC se neztratí, ale ztratí se přístup k předplatnému Azure.
• Pokud je role RBAC odebrána, dojde ke ztrátě PEC, ale odebrání GDAP neodebere RBAC.

Jak mohou mít oprávnění GDAP přednost před oprávněními DAP, když existují společně oprávnění DAP a GDAP?

Pokud je uživatel součástí skupiny zabezpečení GDAP i skupiny agentů správce DAP a má zákazník vztahy jak s DAP, tak s GDAP, má přístup GDAP přednost na úrovni partnera, zákazníka a úlohy.

Pokud se například uživatel partnera přihlásí k úloze a má DAP pro roli globálního správce a GDAP pro roli globálního čtenáře, partnerský uživatel získá pouze oprávnění globálního čtenáře.

Pokud existují tři zákazníci s přiřazením rolí GDAP jenom ke skupině zabezpečení GDAP (ne agentům pro správu):

Zákazník	Vztah s partnerem
Zákazník 1	DAP (bez GDAP)
Zákazník 2	DAP a GDAP oba společně
Zákazník tři	GDAP (bez DAP)

Následující tabulka popisuje, co se stane, když se uživatel přihlásí k jinému tenantovi zákazníka.

Příklad uživatele	Příklad zákaznického klienta	Chování	Komentáře
Uživatel 1	Zákazník 1	DAP	Tento příklad je DAP as-is.
Uživatel 1	Zákazník 2	DAP	K agentům Admin není přiřazena žádná role GDAP, což vede k chování DAP.
Uživatel 1	Zákazník tři	Žádný přístup	Neexistuje žádná relace DAP, takže agenti admin skupiny nemají přístup ke třem zákazníkům.
Uživatel 2	Zákazník 1	DAP	Tento příklad je DAP as-is.
Uživatel 2	Zákazník 2	GDAP	GDAP má přednost před DAP, protože je k uživateli přiřazená role GDAP 2 prostřednictvím skupiny zabezpečení GDAP, i když je uživatel součástí skupiny agenta pro správu.
Uživatel 2	Zákazník tři	GDAP	Tento příklad je pouze pro zákazníky GDAP.
Uživatel tři	Zákazník 1	Žádný přístup	Neexistuje žádné přiřazení role GDAP k zákazníkovi.
Uživatel tři	Zákazník 2	GDAP	Uživatel tři není součástí skupiny Agent pro správu, což vede k chování jen GDAP.
Uživatel tři	Zákazník tři	GDAP	Chování pouze pro GDAP

Ovlivní zakázání DAP nebo přechod na GDAP benefity starších kompetencí nebo označení Partnera řešení, kterých jsem dosáhl?

DAP a GDAP nejsou vhodné typy přidružení pro označení partnerů řešení. Zakázání nebo přechod z DAP na GDAP nemá vliv na získání označení Partnera řešení. Prodloužení výhod starších kompetencí nebo výhod partnerů řešení také nemá vliv. Pokud chcete zobrazit ostatní typy přidružení partnerů, které mají nárok na označení Partnera pro řešení, přečtěte si označení partnerů v Partnerském centru.

Jak GDAP funguje s Azure Lighthouse? Ovlivňují se GDAP a Azure Lighthouse navzájem?

Pokud jde o vztah mezi Azure Lighthouse a DAP/GDAP, představte si je jako oddělené paralelní cesty k Azure prostředkům. Přerušení jednoho by nemělo ovlivnit druhý.

• Ve scénáři Azure Lighthouse se uživatelé z partnerského prostředí nikdy nepřihlašují do prostředí zákazníka a nemají v prostředí zákazníka žádná oprávnění Microsoft Entra. Přiřazení rolí Azure RBAC se také uchovávají v partnerském tenantovi.
• Ve scénáři GDAP se uživatelé z partnerského tenanta přihlašují k tenantovi zákazníka. Přiřazení role RBAC Azure ke skupině správců agentů je také v tenantovi zákazníka. Cestu GDAP (uživatelé už se nemůžou přihlásit) můžete zablokovat, zatímco cesta Azure Lighthouse zůstane neovlivněná. Naopak relace Lighthouse (projekce) můžete oddělit, aniž by to mělo vliv na GDAP. Další informace najdete v dokumentaci k Azure Lighthouse.

Jak GDAP funguje s Microsoft 365 Lighthouse?

Poskytovatelé spravovaných služeb zaregistrovaní v programu Cloud Solution Provider (CSP) jako indirect resellers nebo direct bill partneři teď můžou k nastavení GDAP pro libovolného zákazníka používat Microsoft 365 Lighthouse. Vzhledem k tomu, že partneři již mají několik způsobů, jak spravovat svůj přechod na GDAP, tento průvodce umožňuje partnerům Lighthouse přijmout doporučení rolí, která jsou přizpůsobena jejich konkrétním obchodním potřebám. Umožňuje jim také přijmout bezpečnostní opatření, jako je včasný přístup (JIT). Poskytovatelé cloudových služeb můžou také vytvářet šablony GDAP prostřednictvím Lighthouse, aby bylo možné snadno uložit a znovu použít nastavení, která umožňují přístup nejméně privilegovaných zákazníků. Další informace a zobrazení ukázky naleznete v průvodci nastavením Lighthouse GDAP. Poskytovatelé cloudových služeb můžou nastavit GDAP pro libovolného tenanta zákazníka ve službě Lighthouse. Pro přístup k datům úloh zákazníka ve Lighthouse se vyžaduje vztah GDAP nebo DAP. Pokud GDAP a DAP existují společně v tenantovi zákazníka, mají oprávnění GDAP přednost pro techniky MSP ve skupinách zabezpečení s podporou GDAP. Další informace o požadavcích na Microsoft 365 Lighthouse najdete v tématu Požádky o Microsoft 365 Lighthouse.

Jaký je nejlepší způsob, jak přejít na GDAP a odebrat DAP bez ztráty přístupu k Azure předplatným, pokud mám zákazníky s Azure?

Správná posloupnost, která se má v tomto scénáři provést, je:

1. Vytvořte relaci GDAP pro both Microsoft 365 a Azure.
2. Přiřaďte Microsoft Entra role skupinám zabezpečení pro both Microsoft 365 a Azure.
3. Nakonfigurujte GDAP tak, aby měl přednost před DAP.
4. Odeberte DAP.

Důležitý

Pokud tyto kroky neuděláte, stávající agenti pro správu Azure můžou ztratit přístup k Azure předplatným pro zákazníka.

Následující posloupnost může vést k zavření přístupu k Azure předplatná:

1. Odeberte DAP. Odebráním programu DAP nemusíte nutně ztratit přístup k předplatnému Azure. V tuto chvíli ale nemůžete procházet adresář zákazníka a provádět žádná přiřazení rolí RBAC Azure (například přiřazení nového uživatele zákazníka jako přispěvatel RBAC předplatného).
2. Vytvořte relaci GDAP pro Microsoft 365 i Azure dohromady. Po nastavení GDAP můžete přijít o přístup k předplatnému Azure.
3. Přiřazení rolí Microsoft Entra skupinám zabezpečení pro Microsoft 365 i Azure.

Po dokončení Azure nastavení GDAP znovu získáte přístup k Azure předplatným.

Mám zákazníky s předplatnými Azure bez DAP. Pokud je přesunu do GDAP pro Microsoft 365, ztratím přístup k předplatným Azure?

Pokud máte Azure předplatná sout DAP, která spravujete jako vlastníka, můžete při přidávání GDAP pro Microsoft 365 k danému zákazníkovi ztratit přístup k předplatným Azure. Pokud se chcete vyhnout ztrátě přístupu, přesuňte zákazníka na Azure GDAP at stejnou dobu že zákazníka přesunete do Microsoft 365 GDAP.

Důležitý

Pokud tyto kroky nebudete následovat, stávající agenti pro správu, kteří spravují Azure, můžou ztratit přístup k předplatnému Azure pro zákazníka.

Je možné použít jeden odkaz na relaci s více zákazníky?

Ne. Relace, po přijetí, nejsou opakovaně použitelné.

Pokud mám vztah prodejce se zákazníky bez DAP a kteří nemají žádný vztah GDAP, můžu získat přístup k jejich Azure předplatnému?

Pokud máte existující vztah prodejce se zákazníkem, stále potřebujete vytvořit relaci GDAP, aby bylo možné spravovat jejich Azure předplatná.

1. V Microsoft Entra vytvořte skupinu zabezpečení (například Azure Manažeři).
2. Vytvořte relaci GDAP s rolí čtenáře adresáře.
3. Nastavte skupinu zabezpečení jako člena skupiny Agent pro správu. Po provedení těchto kroků můžete spravovat předplatné Azure zákazníka prostřednictvím AOBO. Předplatné nemůžete spravovat pomocí rozhraní příkazového řádku nebo PowerShellu.

Můžu vytvořit plán Azure pro zákazníky bez DAP a kteří nemají žádný vztah GDAP?

Ano. Plán Azure můžete vytvořit, i když není vyžadován DAP nebo GDAP, pokud existuje aktuální vztah s prodejcem. Abyste ale mohli toto předplatné spravovat, potřebujete DAP nebo GDAP.

Proč se na stránce „Účet“ v části „Zákazníci“ již nezobrazují podrobnosti o společnosti, když je odstraněn DAP?

Když partneři přecházejí z DAP na GDAP, musí zajistit, aby byly splněny následující podmínky pro zobrazení podrobností o společnosti:

• Aktivní relace GDAP.
• Je přiřazena některá z následujících rolí Microsoft Entra: Čtenář adresáře, Globální čtenář. Viz poskytování detailních oprávnění skupinám zabezpečení.

Proč je moje uživatelské jméno nahrazeno znakem "user_somenumber" v portal.azure.com, když existuje relace GDAP?

Když se CSP přihlásí do portálu Azure zákazníka (portal.azure.com) pomocí svých přihlašovacích údajů CSP a existuje vztah GDAP, všimne si, že jeho uživatelské jméno je "user_" následované určitým číslem. Nezobrazuje se jejich skutečné uživatelské jméno jako v DAP. Je to podle návrhu.

Jaké jsou časové osy pro ukončení DAP a udělení výchozího GDAP při vytváření nového zákazníka?

Typ tenanta	Datum dostupnosti	Chování rozhraní API Partnerského centra (POST /v1/customers) enableGDAPByDefault: true	Chování rozhraní API Partnerského centra (POST /v1/customers) enableGDAPByDefault: false	Chování API Partnerského centra (POST /v1/customers) Žádná změna požadavku nebo datové části	Chování uživatelského rozhraní Partnerského centra
Sandbox	25. září 2023 (jenom rozhraní API)	DAP = Ne. Výchozí GDAP = Ano	DAP = Ne. Výchozí hodnota GDAP: Ne	DAP = Ano. Výchozí GDAP = Ne	Výchozí GDAP = Ano
Výroba	10. října 2023 (API a uživatelské rozhraní)	DAP = Ne. Výchozí GDAP = Ano	DAP = Ne. Výchozí GDAP = Ne	DAP = Ano. Výchozí hodnota GDAP = Ne	Možnost přihlášení/odhlášení je k dispozici: Výchozí GDAP
Výroba	27. listopadu 2023 (uvedení GA bylo ukončeno 2. prosince)	DAP = Ne. Výchozí GDAP = Ano	DAP = Ne. Výchozí GDAP = Ne	DAP = Ne. Výchozí GDAP = Ano	Přihlášení/odhlášení k dispozici: Výchozí GDAP

Partneři musí explicitně udělit podrobná oprávnění skupinám zabezpečení ve výchozím GDAP.
Od 10. října 2023 už není DAP k dispozici v partnerských vztazích s prodejci. Aktualizovaný odkaz Request Reseller Relationship je k dispozici v uživatelském rozhraní Partnerského centra a adresa URL vlastnosti smlouvy API "/v1/customers/relationship requests" vrátí adresu URL pozvánky, která se odešle správci zákaznického tenanta.

Má partner udělit podrobná oprávnění skupinám zabezpečení ve výchozím GDAP?

Ano, partneři musí explicitně udělit podrobná oprávnění skupinám zabezpečení ve výchozím GDAP pro správu zákazníka.

Jaké činnosti může partner s prodejním vztahem, ale bez DAP a GDAP, provádět v Partnerském centru?

Partneři, kteří mají vztah prodejce jenom bez DAP nebo GDAP, můžou vytvářet zákazníky, zadávat a spravovat objednávky, stahovat klíče softwaru, spravovat Azure RI. Nemůžou zobrazit podrobnosti o společnosti zákazníka, nemůžou zobrazit uživatele ani přiřazovat licence uživatelům, nemůžou protokolovat lístky jménem zákazníků a nemůžou přistupovat k centerm pro správu konkrétních produktů a spravovat je (například Centrum pro správu Teams).)

Jaký krok musí partner udělat při přechodu z DAP na GDAP v souvislosti se souhlasem?

Aby měl partner nebo CPV přístup k tenantovi zákazníka a mohl ho spravovat, musí být služební principál aplikace odsouhlasen v tenantovi zákazníka. Když je DAP aktivní, musí přidat instanční objekt aplikace do skupiny agentů pro správu v partnerském tenantovi. U GDAP musí partner zajistit, aby byla jejich aplikace odsouhlasená v tenantovi zákazníka. Pokud aplikace používá delegovaná oprávnění (App + Uživatel) a aktivní GDAP existuje s některou ze tří rolí (správce cloudových aplikací, správce aplikací), můžete použít rozhraní API pro vyjádření souhlasu. Pokud aplikace používá pouze oprávnění aplikace, musí s ním souhlasit ručně buď partner, nebo zákazník, který má některou ze tří rolí (správce cloudových aplikací, správce aplikací), pomocí adresy URL souhlasu správce v rámci celého tenanta.

Jaká akce musí partner provést pro chybu 715–123220 nebo anonymní připojení nejsou pro tuto službu povolená?

Pokud se zobrazí následující chyba:

"V tuto chvíli nemůžeme ověřit vaši žádost o vytvoření nové relace GDAP. Doporučujeme, aby pro tuto službu nebyla povolena anonymní připojení. Pokud se domníváte, že se vám tato zpráva zobrazila omylem, zkuste žádost zopakovat. Vyberte pro zobrazení akcí, které můžete provést. Pokud problém přetrvává, obraťte se na podporu a uveďte zprávu s kódem 715–123220 a ID transakce: guid.

Změňte způsob připojení k Microsoft, aby služba ověření identity běžela správně. Pomáhá zajistit, aby váš účet nebyl ohrožen a dodržoval předpisy, které Microsoft musí dodržovat.

Co můžete udělat:

• Vymažte mezipaměť prohlížeče.
• Vypněte ochranu před sledováním v prohlížeči nebo přidejte náš web do seznamu výjimek nebo bezpečných.
• Vypněte všechny programy nebo služby virtuální privátní sítě (VPN), které možná používáte.
• Připojte se přímo z místního zařízení místo virtuálního počítače.

Pokud se po vyzkoušení předchozích kroků stále nemůžete připojit, doporučujeme se s it helpdeskem poradit, abyste zkontrolovali nastavení a zjistili, jestli vám můžou pomoct zjistit, co je příčinou problému. Někdy je problém v nastavení sítě vaší společnosti. Správce IT by tento problém potřeboval vyřešit, například bezpečným výpisem našeho webu nebo provedením dalších úprav nastavení sítě.

Jaké akce GDAP jsou povoleny pro partnera, který je v procesu opuštění, je omezený, pozastavený nebo již opustil systém?

• Restricted (Direct Bill): Nelze vytvořit nové GDAP (adminská spojení). Stávající GDAP a jejich přiřazení rolí je možné aktualizovat.
• Pozastaveno (přímé účtování/nepřímý poskytovatel/nepřímý prodejce): Nový GDAP, se nedá vytvořit. Stávající GDAP a jejich přiřazení rolí nelze aktualizovat.
• Restricted (Direct Bill) + Active (Nepřímý prodejce): Pro omezený Direct Bill: Nové vztahy GDAP (správcovské vztahy) nelze vytvořit. Stávající GDAP a jejich přiřazení rolí je možné aktualizovat. V případě aktivního nepřímého prodejce: Je možné vytvořit nové GDAP, stávající GDAP a jejich přiřazení rolí je možné aktualizovat. Když je ukončeno používání a nový GDAP nelze vytvořit, stávající GDAP a jejich přiřazení rolí se nedají aktualizovat.

Nabídky

Je správa předplatných Azure součástí této verze GDAP?

Ano. Aktuální verze GDAP podporuje všechny produkty: Microsoft 365, Dynamics 365, Microsoft Power Platform a Microsoft Azure.

příslušné role: Všichni uživatelé, kteří se zajímají o Partnerské centrum

Podrobná delegovaná oprávnění správce (GDAP) poskytují partnerům přístup k úlohám zákazníků způsobem, který je podrobnější a časově omezené, což může pomoct řešit problémy se zabezpečením zákazníků.

S GDAP mohou partneři poskytovat více služeb zákazníkům, kteří se mohou cítit nepříjemně s vysokou úrovní přístupu partnerů.

GDAP také pomáhá zákazníkům, kteří mají regulační požadavky na poskytování pouze přístupu s minimálními oprávněními partnerům.

Někdo, kdo má roli administrátora v partnerské organizaci, může vytvořit žádost o vztah GDAP.

Ano. Platnost žádostí o vztah GDAP vyprší po 90 dnech.

Ne. Trvalé vztahy GDAP se zákazníky nejsou z bezpečnostních důvodů možné. Maximální doba trvání relace GDAP je dva roky. Můžete nastavit Automatické rozšíření na Povoleno, aby prodloužilo vztah správce o šest měsíců, dokud nebude ukončen nebo dokud nebude automatické rozšíření nastaveno na Zakázáno.

Ano. Relace GDAP se může automaticky prodloužit o šest měsíců, dokud není ukončena nebo než je automatické prodloužení nastaveno na Zakázáno.

• Pokud vyprší platnost relace GDAP s vaším zákazníkem, požádat o relaci GDAP znovu.
• Pomocí analýzy relací GDAP můžete sledovat data vypršení platnosti relací GDAP a připravit se na jejich prodloužení.

Pokud chcete prodloužit nebo obnovit vztah GDAP, musí partner nebo zákazník nastavit Automatické prodloužení na Povoleno. Další informace najdete ve správě automatického prodloužení GDAP a API.

Ano. Pokud je GDAP aktivní, můžete ho rozšířit.

Řekněme, že se GDAP vytvoří na dobu 365 dnů, kdy je automatické prodloužení povoleno. 365. den se koncové datum efektivně aktualizuje o 180 dní.

Ano. Můžete automaticky rozšířit libovolnou aktivní GDAP.

Ne. Souhlas zákazníka není nutný k nastavení automatického rozšíření na Povoleno pro stávající aktivní GDAP.

Ne. Podrobná oprávnění přiřazená skupinám zabezpečení zůstávají nezměněna.

Ne. Vztah správce nelze automaticky prodloužit s rolí globálního správce.

Stránka Expirující granulární vztahy je dostupná pouze pro partnerské uživatele s rolemi administrativního agenta. Tato stránka pomáhá filtrovat GDAPs, jejichž platnost vyprší v různých obdobích, a pomáhá aktualizovat automatické prodloužení (povolení nebo zakázání) pro jednu nebo více GDAPs.

Ne. Když vyprší platnost relace GDAP, nedojde k žádné změně stávajících předplatných zákazníka.

Pokyny najdete v tématu Řešení problémů s Microsoft Entra vícefaktorovým ověřováním a Nelze použít Microsoft Entra vícefaktorové ověřování pro přihlášení ke cloudovým službám po ztrátě telefonu nebo změně telefonního čísla.

Partner musí při vytváření první GDAP požádat o roli Správce s privilegovaným ověřováním Microsoft Entra.

• Tato role umožňuje partnerovi resetovat heslo a metodu ověřování pro správce nebo uživatele bez oprávnění správce. Role správce privilegovaného ověřování je součástí rolí nastavených nástrojem Microsoft-led a plánuje se, že bude k dispozici s výchozím GDAP během procesu vytváření zákazníka (dostupné od září).
• Partner může požádat správce zákazníka, aby zkusil Resetovat heslo.
• Jako preventivní opatření musí partner pro své zákazníky nastavit samoobslužné resetování hesla. Další informace najdete v tématu Umožnit uživatelům resetovat vlastní hesla.

• V organizaci partnera obdrží oznámení o ukončení lidé s rolí Admin agent.
• V organizaci zákazníka obdrží oznámení o ukončení lidé s rolí globálního správce.

Ano. Partneři můžou zjistit, kdy zákazník odebere GDAP v protokolech aktivit v Partnerském centru.

Ne. GDAP je volitelná možnost pro partnery, kteří chtějí spravovat služby zákazníka podrobnějším a časově ohraničeným způsobem. Můžete zvolit, se kterými zákazníky chcete vytvořit relaci GDAP.

Odpověď závisí na tom, jak chcete spravovat zákazníky.

• Pokud chcete, aby vaši partneři mohli spravovat všechny zákazníky, můžete všechny své partnerské uživatele umístit do jedné skupiny zabezpečení a že jedna skupina může spravovat všechny vaše zákazníky.
• Pokud dáváte přednost tomu, aby různí uživatelé partnerů spravovali různé zákazníky, přiřaďte tyto uživatele partnerů k oddělení skupin zabezpečení pro izolaci zákazníků.

Ano. Nepřímí prodejci (a nepřímí poskytovatelé a partneři s přímým vyúčtováním) můžou vytvářet žádosti o vztahy GDAP v Partnerském centru.

V rámci nastavení GDAP se ujistěte, že jsou vybrány skupiny zabezpečení, které byly vytvořeny v partnerském tenantovi s uživateli partnera. Ujistěte se také, že požadované Microsoft Entra role jsou přiřazené ke skupině zabezpečení. Projděte si Assign Microsoft Entra role.

Zákazníci teď můžou vyloučit poskytovatele cloudových služeb ze zásad podmíněného přístupu, aby partneři mohli přejít na GDAP bez blokování.

• Zahrnout uživatele – Tento seznam uživatelů obvykle zahrnuje všechny uživatele, na které organizace cílí, v zásadách podmíněného přístupu.
• Při vytváření zásad podmíněného přístupu jsou k dispozici následující možnosti:
• Výběr uživatelů a skupin
• Hosté nebo externí uživatelé (Preview)
• Tento výběr nabízí několik možností, které lze použít k cílení zásad podmíněného přístupu na konkrétní typy hostů nebo externích uživatelů a konkrétní tenanty obsahující tyto typy uživatelů. Existuje několik různých typů hosta nebo externích uživatelů, které je možné vybrat, a je možné vybrat několik možností:
• Uživatelé poskytovatele služeb, například poskytovatel cloudových řešení (CSP).
• Pro vybrané typy uživatelů můžete zadat jednoho nebo více tenantů nebo můžete zadat všechny tenanty.
• přístup externího partnera – zásady podmíněného přístupu, které cílí na externí uživatele, můžou kolidovat s přístupem poskytovatele služeb, například podrobná delegovaná oprávnění správce. Další informace najdete v tématu Úvod k podrobným delegovaným oprávněním správce (GDAP). cs-CZ: Pro zásady zaměřené na nájemníky poskytovatelů služeb použijte typ externího uživatele Poskytovatel služby, který je k dispozici v možnostech výběru Host nebo externí uživatelé.
• vyloučit uživatele – pokud organizace zahrnují i vylučují uživatele nebo skupinu, je uživatel nebo skupina ze zásady vyloučen, protože akce vyloučení přepíše akci zahrnutí do zásad.
• Při vytváření zásad podmíněného přístupu můžete vyloučit následující možnosti:
• Host nebo externí uživatelé
• Tento výběr nabízí několik možností, které lze použít k cílení zásad podmíněného přístupu na konkrétní typy hostů nebo externích uživatelů a konkrétní tenanty obsahující tyto typy uživatelů. Existuje několik různých typů hosta nebo externích uživatelů, kteří mohou být vybránia lze provést několik výběrů:
• Uživatelé poskytovatele služeb, například poskytovatele cloudových řešení (CSP)
• Pro vybrané typy uživatelů je možné zadat jednoho nebo více tenantů nebo můžete zadat všechny tenanty. Další informace najdete zde:
• Zkušenost s Graph API: API beta s informacemi o novém typu externího uživatele
• zásad podmíněného přístupu
• Podmíněný přístup externím uživatelům

Ano. Bez ohledu na plán podpory, který máte, je nejnižší privilegovanou rolí pro uživatele partnerů, kteří budou moct vytvářet lístky podpory pro zákazníka, správce podpory služeb.

Ne. Partner momentálně nemůže ukončit GDAP ve stavu Schválení čeká na vyřízení. Pokud zákazník neudělá žádnou akci, vyprší za 90 dnů.

Až po uplynutí 365 dnů (vyčištění) po ukončení nebo vypršení platnosti relace GDAP můžete znovu použít stejný název k vytvoření nové relace GDAP.

Ano. Partner může spravovat své zákazníky napříč oblastmi bez vytváření nových partnerských tenantů pro každou oblast zákazníka. Vztahuje se pouze na roli správy zákazníků, kterou poskytuje GDAP (vztahy správců). Role a možnosti transakcí jsou stále omezené na vaše autorizované teritorium.

Ne. Poskytovatel služeb nemůže být součástí víceklientských organizací, které se vzájemně vylučují.

1. Ujistěte se, že je GDAP správně nastavený, včetně způsobu udělení oprávnění pro skupiny zabezpečení.
2. Ujistěte se, že jsou správná podrobná oprávnění skupiny zabezpečení .
3. Nápovědu najdete v Security Copilot nejčastějších dotazech.

Možnosti víceklientských organizací nejsou podporovány mezi poskytovatelem CSP a zákazníkem, který má vztah GDAP. Možnosti GDAP umožňují partnerovi CSP spravovat služby Microsoft pro jinou organizaci. Funkce víceklientské organizace jsou určeny pro použití mezi klienty vlastněnými stejnou organizací.

Další informace o rozhraních API a GDAP najdete v dokumentaci pro vývojáře v partnerském centru .

Ano. Doporučujeme, aby partneři používali beta rozhraní API GDAP pro produkční a pozdější přechod na rozhraní API v.1, jakmile budou k dispozici. I když existuje upozornění, že použití těchto rozhraní API v produkčních aplikacích není podporováno, toto obecné doporučení platí pouze pro jakékoli beta rozhraní API pod Graph a není použitelné na beta verzi GDAP Graph API.

Ano. Relace GDAP můžete vytvářet pomocí rozhraní API, která partnerům umožní škálovat tento proces. Vytváření více relací GDAP ale není k dispozici v Partnerském centru. Informace o rozhraních API a GDAP najdete v dokumentaci pro vývojáře v partnerském centru .

API funguje pouze pro jednu skupinu zabezpečení najednou, ale v Centru pro partnery můžete přiřadit více skupin zabezpečení k více rolím.

Proveďte jednotlivá volání pro každý prostředek. Při vytváření jednoho požadavku POST předejte pouze jeden prostředek a jeho odpovídající obory. Pokud například chcete požádat o oprávnění pro https://graph.microsoft.com/Directory.AccessAsUser.All i https://graph.microsoft.com/Organization.Read.All, proveďte dva různé požadavky, jednu pro každou.

Pomocí poskytnutého odkazu vyhledejte název prostředku: Ověření prvotních aplikací Microsoft v sestavách přihlašování – služba Active Directory. Pokud chcete například najít ID prostředku 00000003-0000-0000-c000-0000000000000 pro graph.microsoft.com:

K této chybě obvykle dochází při použití nesprávného identifikátoru ve filtru dotazu. Pokud chcete tento problém vyřešit, ujistěte se, že používáte vlastnost enterpriseApplicationId se správným ID prostředku , nikoli názvem prostředku.

• Nesprávný požadavek U enterpriseApplicationId nepoužívejte název prostředku, jako je graph.microsoft.com.
• Správný požadavek Místo toho, pro enterpriseApplicationId, použijte ID zdroje, například 00000003-0000-0000-c000-000000000000.

Například v prostředku graph.microsoft.com byl dříve udělen pouze rozsah profilu. Teď potřebujeme přidat také profil a user.read. Přidání nových oborů do dříve odsouhlasené aplikace:

1. K odvolání souhlasu stávající aplikace uděleného tenantovi zákazníka použijte metodu DELETE.
2. Pomocí metody POST vytvořte nový souhlas aplikace s dalšími rozsahy oprávnění.

Poznámka

Pokud vaše aplikace vyžaduje oprávnění pro více prostředků, spusťte pro každý prostředek metodu POST samostatně.

Zřetězte požadované obory pomocí čárky a mezery. Například „scope“: „profile, User.Read“

1. Ověřte, že vlastnosti displayName a applicationId v textu požadavku jsou přesné a odpovídají aplikaci, se kterou se pokoušíte souhlasit s tenantem zákazníka.
2. Ujistěte se, že používáte stejnou aplikaci k vygenerování přístupového tokenu, ke kterému se pokoušíte udělit souhlas s tenantem zákazníka. Například: Pokud je ID aplikace "12341234-1234-1234-12341234", deklarace identity "appId" v přístupovém tokenu by měla být také "12341234-1234-1234-12341234".
3. Ověřte splnění jedné z následujících podmínek:

• Máte aktivní oprávnění delegovaného správce (DAP) a uživatel je také členem skupiny zabezpečení Agenti pro správu v partnerském tenantovi.
• Máte aktivní vztah Granulárního Delegovaného Administrativního Oprávnění (GDAP) s tenantem zákazníka s alespoň jednou z následujících tří rolí v rámci GDAP, a dokončili jste přiřazení přístupu.
  • Správce aplikací nebo role Správce cloudových aplikací
  • Partner uživatel je členem skupiny zabezpečení zadané v přiřazení přístupu.

• Pokud chcete spravovat Azure pomocí dělení na jednotlivé zákazníky (což je doporučený postup), vytvořte skupinu zabezpečení (například Azure Manažeři) a vložit ji pod Admin agenty.
• Pokud chcete získat přístup k předplatnému Azure jako vlastník pro zákazníka, můžete přiřadit libovolnou vestavěnou roli Microsoft Entra (například Čtenáři adresáře, nejméně privilegovanou roli) skupině zabezpečení Azure Managers. Postup nastavení Azure GDAP najdete v tématu Workloads podporované podrobnými delegovanými oprávněními správce (GDAP).

Ano. Informace o tom, jak omezit oprávnění správce uživatele přiřazením nejméně privilegovaných rolí v Microsoft Entra, najdete v tématu Náležení privilegovaných rolí podle úlohy v Microsoft Entra.

Doporučujeme přiřadit roli správce podpory služby. Další informace najdete v tématu Nejníže privilegované role dle úlohy v Microsoft Entra.

• Aby se snížila mezera mezi Microsoft Entra rolemi dostupnými v rozhraní API Partnerského centra a uživatelským rozhraním, seznam devíti rolí je k dispozici v uživatelském rozhraní Partnerského centra v červenci 2024.
• V části Spolupráce:
  • správce Microsoft Edge
  • Správce virtuálních návštěv
  • správce Viva Goals
  • Viva Pulse Administrátor
  • Správce Yammeru
• V části Identita:
  • Správce správy oprávnění
  • Správce pracovních postupů životního cyklu
• V části Jiné:
  • Správce brandingu organizace
  • Schvalovatel zpráv organizace

• Aby se snížila mezera mezi Microsoft Entra rolemi dostupnými v rozhraní API Partnerského centra a uživatelským rozhraním, byl v prosinci 2024 zpřístupněn seznam 17 rolí.
• V části Spolupráce:
  • Analytik přehledů
  • správce migrace Microsoft 365
  • Zapisovatel zpráv organizace
  • Vestavěný administrátor SharePoint
  • Správce telefonních služeb Teams
  • Správce úspěchu uživatelského prostředí
• V části Zařízení:
  • správce záruky hardwaru Microsoft
  • Microsoft Specialista na záruku hardwaru
• V části Identita:
  • Správce přiřazení atributů
  • Čtenář přiřazení atributů
  • Správce definic atributů
  • Čtečka definic atributů
  • Správce protokolu atributů
  • Čtenář protokolu atributů
  • Správce rozšiřitelnosti ověřování
  • Globální správce zabezpečeného přístupu
  • Tvůrce tenanta

Ne. Nejmíň privilegovaná role pro uživatele partnera, aby mohli vytvářet lístky podpory pro zákazníka, je správce podpory služby service. Aby bylo možné vytvářet podporované tikety pro zákazníka, musí být partnerský uživatel členem bezpečnostní skupiny a mít přiřazenou roli k tomuto zákazníkovi.

Informace o všech rolích najdete v tématu Microsoft Entra vestavěné role. Informace o úlohách najdete v tématu Úlohy podporované podrobnými delegovanými oprávněními správce (GDAP).

Mnoho rolí se používá pro Správa Microsoftu 365 Center. Další informace najdete v tématu Používané role Centrum pro správu Microsoftu 365.

Ano. Vytvořte skupinu zabezpečení, přiřaďte schválené role a pak k této skupině zabezpečení přiřaďte uživatele partnerského tenanta.

Přístup k předplatným zákazníka pro čtení poskytují role Globální čtenář, Čtenář adresáře a role Partner podpory úrovně 2.

Doporučujeme odebrat partnerské agenty z agenta správce roli a přidat je jenom do skupiny zabezpečení GDAP. Tímto způsobem můžou spravovat služby (například správa služeb a žádosti o službu protokolů), ale nemůžou kupovat a spravovat předplatná (změna množství, zrušení, plánování změn atd.).

Skupiny zabezpečení přiřazené k relaci ztratí přístup k danému zákazníkovi. Totéž se stane, když zákazník ukončí relaci DAP.

Ano. Odebrání vztahů GDAP se zákazníkem neukončí partnerský prodejní vztah se zákazníkem. Partneři můžou dál nakupovat produkty pro zákazníka a spravovat Azure rozpočet a další související aktivity.

Ne. Všechny role v relaci GDAP mají stejnou dobu k vypršení platnosti: doba trvání zvolená při vytvoření relace.

Ne. Ke splnění objednávek pro nové a stávající zákazníky nepotřebujete GDAP. Ke splnění objednávek zákazníků v Partnerském centru můžete dál používat stejný postup.

Relace GDAP jsou pro jednotlivé zákazníky. Pro každého zákazníka můžete mít více vztahů. Každý vztah GDAP může mít různé role a používat různé skupiny Microsoft Entra v CSP Tenant. V Partnerském centru funguje přiřazení rolí na úrovni vztahu zákazníka k GDAP. Pokud chcete přiřazení role s více zákazníky automatizovat pomocí rozhraní API, můžete tak učinit.

Ne. Účty hostů nefungují s GDAP. Zákazníci musí odebrat všechny účty hostů, aby GDAP fungovaly.

Správci hostů GDAP nemůžou spravovat své bezpečnostní informace na Moje bezpečnostní informace. Místo toho potřebují pomoc správce tenanta, v kterém jsou hostem, pro registraci, aktualizaci nebo odstranění bezpečnostních údajů. Organizace mohou nakonfigurovat zásady přístupu mezi tenanty tak, aby důvěřovaly vícefaktorovému ověřování od důvěryhodného tenanta CSP. V opačném případě jsou správci hosta GDAP omezeni pouze na metody, které může zaregistrovat správce tenantů, což je krátká služba zpráv (SMS) nebo Hlas. Další informace se dozvíte v zásadách přístupu mezi tenanty.

Zarovnejte se s vedoucím principem nulová důvěra (Zero Trust): Použijte přístup s minimálními oprávněními:

• Doporučujeme použít nejméně privilegovanou roli podle úloh a úkoly v zátěži podporované podrobnými delegovanými oprávněními správce (GDAP).
• Pokud je potřeba vyřešit uvedené známé problémy, požádejte zákazníka o roli globálního správce vázané na čas.
• Nedoporučujeme nahrazovat roli globálního správce všemi dostupnými rolemi Microsoft Entra.

Ano. Během přechodného období bude daP a GDAP existovat společně s oprávněními GDAP, která mají přednost před oprávněními DAP pro úlohy Microsoft 365, Dynamics 365 a Azure.

DAP a GDAP existují společně během přechodného období. Nakonec ale GDAP nahrazuje DAP, abychom zajistili bezpečnější řešení pro naše partnery a zákazníky. Doporučujeme, abyste zákazníky co nejdříve převést na GDAP, abyste zajistili kontinuitu.

Stávající tok relace DAP se nijak nemění, zatímco daP a GDAP spolu existují.

DAP se v současné době uděluje při vytvoření nového zákaznického tenanta. Dne 25. září 2023 Microsoft už neuděluje daP pro vytvoření nového zákazníka a místo toho uděluje výchozí GDAP s konkrétními rolemi. Výchozí role se liší podle typu partnera, jak je znázorněno v následující tabulce:

Microsoft Entra role udělené pro výchozí GDAP	Partneři s přímým vyúčtováním	Nepřímí zprostředkovatelé	Nepřímí prodejci	Partneři domény	dodavatelé ovládacích panelů (CPV)	Advisor	Odhlášení z výchozího GDAP (bez DAP)
1. Čtenáři adresáře. Může číst základní informace o adresáři. Běžně se používá k udělení přístupu ke čtení adresáře aplikacím a hostům.	x	x	x	x	x
2. tvůrců adresářů. Může číst a zapisovat základní informace o adresáři. Pro udělení přístupu k aplikacím, které nejsou určené pro uživatele.	x	x	x	x	x
3. správce licencí. Může spravovat licence produktů pro uživatele a skupiny.	x	x	x	x	x
4. správce podpory služeb. Může číst informace o stavu služeb a spravovat lístky podpory.	x	x	x	x	x
5. správce uživatelů. Může spravovat všechny aspekty uživatelů a skupin, včetně resetování hesel pro omezené správce.	x	x	x	x	x
6. správce privilegovaných rolí. Může spravovat přiřazení rolí v Microsoft Entra a všechny aspekty Privileged Identity Management.	x	x	x	x	x
7. správce helpdesku. Může resetovat hesla pro správce, kteří nejsou správci a správci helpdesku.	x	x	x	x	x
8. správce privilegovaného ověřování. Má právo zobrazovat, nastavovat a resetovat informace o způsobu ověřování pro libovolného uživatele (administrátor nebo běžný uživatel).	x	x	x	x	x
9. správce cloudových aplikací. Může vytvářet a spravovat všechny aspekty registrace aplikací a podnikových aplikací kromě proxy aplikací.	x	x		x	x
10. správce aplikací. Může vytvářet a spravovat všechny aspekty registrace aplikací a podnikových aplikací.	x	x		x	x
11. Globální Čtenář. Může číst všechno, co Globální správce může, ale nemůže nic aktualizovat.	x	x	x	x	x
12. správce externího zprostředkovatele identity. Může spravovat federaci mezi Microsoft Entra organizacemi a externími zprostředkovateli identit.				x
13. správce názvu domény. Může spravovat názvy domén v cloudu a v místním prostředí.				x

Partneři můžou implementovat Privileged Identity Management (PIM) ve skupině zabezpečení GDAP v tenantovi partnera, aby zvýšili přístup několika uživatelů s vysokými oprávněními, a to za běhu (JIT), aby jim udělili role s vysokými oprávněními, jako jsou správci hesel s automatickým odebráním přístupu. Do ledna 2023 bylo nutné, aby každá privilegovaná skupina přístupu (dřívější název pro funkci PIM for Groups) byla v přiřaditelné roli skupiny. Toto omezení je nyní odebráno. Vzhledem k této změně je možné povolit více než 500 skupin na tenanta vPIM, ale pouze 500 skupin je možné přiřadit role. Shrnutí:

• Partneři mohou v PIM používat jak přiřaditelné, tak i nepřiřaditelné skupiny rolí. Tato možnost účinně odstraňuje limit 500 skupin na tenant v PIM.
• S nejnovějšími aktualizacemi existují dva způsoby, jak připojit skupiny k PIM (UX) z nabídky PIM nebo z nabídky Skupiny. Bez ohledu na způsob, jakým zvolíte, je čistý výsledek stejný.
  • Možnost přidání skupin, které lze nebo nelze přiřadit rolí, prostřednictvím nabídky PIM je již dostupná.
  • Možnost přidání skupin s přiřaditelnou rolí a bez přiřaditelné role prostřednictvím nabídky Skupiny je již dostupná.
• Další informace najdete v tématu Privileged Identity Management (PIM) pro skupiny (Preview) – Microsoft Entra.

GDAP je obecně dostupná s podporou všech Microsoft komerčních cloudových služeb (Microsoft 365, Dynamics 365, Microsoft Azure a Microsoft Power Platform úloh). Další informace o tom, jak mohou DAP a GDAP koexistovat a jak má GDAP přednost, najdete v části nejčastějších dotazů pod otázkou Jak mají oprávnění GDAP přednost před oprávněními DAP, když DAP a GDAP koexistují?.

Tuto akci můžete provést pomocí rozhraní API.

Ne. Vaše příjmy PEC se při přechodu na GDAP nedotknou. V rámci přechodu nedochází k žádným změnám v PAL, takže můžete i nadále získávat PEC.

• Pokud má zákazník partnera pouze DAP a DAP se odstraní, PEC se neztratí.
• Pokud má zákazník partnera DAP a přejde na GDAP pro Microsoft 365 a Azure současně a DAP se odebere, PEC se neztratí.
• Pokud má zákazník partnera DAP a přejde na GDAP pro Microsoft 365, ale ponechá Azure beze změny (nepřesunou se do GDAP) a DAP se odstraní, PEC se neztratí, ale ztratí se přístup k předplatnému Azure.
• Pokud je role RBAC odebrána, dojde ke ztrátě PEC, ale odebrání GDAP neodebere RBAC.

Pokud je uživatel součástí skupiny zabezpečení GDAP i skupiny agentů správce DAP a má zákazník vztahy jak s DAP, tak s GDAP, má přístup GDAP přednost na úrovni partnera, zákazníka a úlohy.

Pokud se například uživatel partnera přihlásí k úloze a má DAP pro roli globálního správce a GDAP pro roli globálního čtenáře, partnerský uživatel získá pouze oprávnění globálního čtenáře.

Pokud existují tři zákazníci s přiřazením rolí GDAP jenom ke skupině zabezpečení GDAP (ne agentům pro správu):

Zákazník	Vztah s partnerem
Zákazník 1	DAP (bez GDAP)
Zákazník 2	DAP a GDAP oba společně
Zákazník tři	GDAP (bez DAP)

Následující tabulka popisuje, co se stane, když se uživatel přihlásí k jinému tenantovi zákazníka.

Příklad uživatele	Příklad zákaznického klienta	Chování	Komentáře
Uživatel 1	Zákazník 1	DAP	Tento příklad je DAP as-is.
Uživatel 1	Zákazník 2	DAP	K agentům Admin není přiřazena žádná role GDAP, což vede k chování DAP.
Uživatel 1	Zákazník tři	Žádný přístup	Neexistuje žádná relace DAP, takže agenti admin skupiny nemají přístup ke třem zákazníkům.
Uživatel 2	Zákazník 1	DAP	Tento příklad je DAP as-is.
Uživatel 2	Zákazník 2	GDAP	GDAP má přednost před DAP, protože je k uživateli přiřazená role GDAP 2 prostřednictvím skupiny zabezpečení GDAP, i když je uživatel součástí skupiny agenta pro správu.
Uživatel 2	Zákazník tři	GDAP	Tento příklad je pouze pro zákazníky GDAP.
Uživatel tři	Zákazník 1	Žádný přístup	Neexistuje žádné přiřazení role GDAP k zákazníkovi.
Uživatel tři	Zákazník 2	GDAP	Uživatel tři není součástí skupiny Agent pro správu, což vede k chování jen GDAP.
Uživatel tři	Zákazník tři	GDAP	Chování pouze pro GDAP

DAP a GDAP nejsou vhodné typy přidružení pro označení partnerů řešení. Zakázání nebo přechod z DAP na GDAP nemá vliv na získání označení Partnera řešení. Prodloužení výhod starších kompetencí nebo výhod partnerů řešení také nemá vliv. Pokud chcete zobrazit ostatní typy přidružení partnerů, které mají nárok na označení Partnera pro řešení, přečtěte si označení partnerů v Partnerském centru.

Pokud jde o vztah mezi Azure Lighthouse a DAP/GDAP, představte si je jako oddělené paralelní cesty k Azure prostředkům. Přerušení jednoho by nemělo ovlivnit druhý.

• Ve scénáři Azure Lighthouse se uživatelé z partnerského prostředí nikdy nepřihlašují do prostředí zákazníka a nemají v prostředí zákazníka žádná oprávnění Microsoft Entra. Přiřazení rolí Azure RBAC se také uchovávají v partnerském tenantovi.
• Ve scénáři GDAP se uživatelé z partnerského tenanta přihlašují k tenantovi zákazníka. Přiřazení role RBAC Azure ke skupině správců agentů je také v tenantovi zákazníka. Cestu GDAP (uživatelé už se nemůžou přihlásit) můžete zablokovat, zatímco cesta Azure Lighthouse zůstane neovlivněná. Naopak relace Lighthouse (projekce) můžete oddělit, aniž by to mělo vliv na GDAP. Další informace najdete v dokumentaci k Azure Lighthouse.

Poskytovatelé spravovaných služeb zaregistrovaní v programu Cloud Solution Provider (CSP) jako indirect resellers nebo direct bill partneři teď můžou k nastavení GDAP pro libovolného zákazníka používat Microsoft 365 Lighthouse. Vzhledem k tomu, že partneři již mají několik způsobů, jak spravovat svůj přechod na GDAP, tento průvodce umožňuje partnerům Lighthouse přijmout doporučení rolí, která jsou přizpůsobena jejich konkrétním obchodním potřebám. Umožňuje jim také přijmout bezpečnostní opatření, jako je včasný přístup (JIT). Poskytovatelé cloudových služeb můžou také vytvářet šablony GDAP prostřednictvím Lighthouse, aby bylo možné snadno uložit a znovu použít nastavení, která umožňují přístup nejméně privilegovaných zákazníků. Další informace a zobrazení ukázky naleznete v průvodci nastavením Lighthouse GDAP. Poskytovatelé cloudových služeb můžou nastavit GDAP pro libovolného tenanta zákazníka ve službě Lighthouse. Pro přístup k datům úloh zákazníka ve Lighthouse se vyžaduje vztah GDAP nebo DAP. Pokud GDAP a DAP existují společně v tenantovi zákazníka, mají oprávnění GDAP přednost pro techniky MSP ve skupinách zabezpečení s podporou GDAP. Další informace o požadavcích na Microsoft 365 Lighthouse najdete v tématu Požádky o Microsoft 365 Lighthouse.

Správná posloupnost, která se má v tomto scénáři provést, je:

1. Vytvořte relaci GDAP pro both Microsoft 365 a Azure.
2. Přiřaďte Microsoft Entra role skupinám zabezpečení pro both Microsoft 365 a Azure.
3. Nakonfigurujte GDAP tak, aby měl přednost před DAP.
4. Odeberte DAP.

Důležitý

Pokud tyto kroky neuděláte, stávající agenti pro správu Azure můžou ztratit přístup k Azure předplatným pro zákazníka.

Následující posloupnost může vést k zavření přístupu k Azure předplatná:

1. Odeberte DAP. Odebráním programu DAP nemusíte nutně ztratit přístup k předplatnému Azure. V tuto chvíli ale nemůžete procházet adresář zákazníka a provádět žádná přiřazení rolí RBAC Azure (například přiřazení nového uživatele zákazníka jako přispěvatel RBAC předplatného).
2. Vytvořte relaci GDAP pro Microsoft 365 i Azure dohromady. Po nastavení GDAP můžete přijít o přístup k předplatnému Azure.
3. Přiřazení rolí Microsoft Entra skupinám zabezpečení pro Microsoft 365 i Azure.

Po dokončení Azure nastavení GDAP znovu získáte přístup k Azure předplatným.

Pokud máte Azure předplatná sout DAP, která spravujete jako vlastníka, můžete při přidávání GDAP pro Microsoft 365 k danému zákazníkovi ztratit přístup k předplatným Azure. Pokud se chcete vyhnout ztrátě přístupu, přesuňte zákazníka na Azure GDAP at stejnou dobu že zákazníka přesunete do Microsoft 365 GDAP.

Důležitý

Pokud tyto kroky nebudete následovat, stávající agenti pro správu, kteří spravují Azure, můžou ztratit přístup k předplatnému Azure pro zákazníka.

Ne. Relace, po přijetí, nejsou opakovaně použitelné.

Pokud máte existující vztah prodejce se zákazníkem, stále potřebujete vytvořit relaci GDAP, aby bylo možné spravovat jejich Azure předplatná.

1. V Microsoft Entra vytvořte skupinu zabezpečení (například Azure Manažeři).
2. Vytvořte relaci GDAP s rolí čtenáře adresáře.
3. Nastavte skupinu zabezpečení jako člena skupiny Agent pro správu. Po provedení těchto kroků můžete spravovat předplatné Azure zákazníka prostřednictvím AOBO. Předplatné nemůžete spravovat pomocí rozhraní příkazového řádku nebo PowerShellu.

Ano. Plán Azure můžete vytvořit, i když není vyžadován DAP nebo GDAP, pokud existuje aktuální vztah s prodejcem. Abyste ale mohli toto předplatné spravovat, potřebujete DAP nebo GDAP.

Když partneři přecházejí z DAP na GDAP, musí zajistit, aby byly splněny následující podmínky pro zobrazení podrobností o společnosti:

• Aktivní relace GDAP.
• Je přiřazena některá z následujících rolí Microsoft Entra: Čtenář adresáře, Globální čtenář. Viz poskytování detailních oprávnění skupinám zabezpečení.

Když se CSP přihlásí do portálu Azure zákazníka (portal.azure.com) pomocí svých přihlašovacích údajů CSP a existuje vztah GDAP, všimne si, že jeho uživatelské jméno je "user_" následované určitým číslem. Nezobrazuje se jejich skutečné uživatelské jméno jako v DAP. Je to podle návrhu.

Typ tenanta	Datum dostupnosti	Chování rozhraní API Partnerského centra (POST /v1/customers) enableGDAPByDefault: true	Chování rozhraní API Partnerského centra (POST /v1/customers) enableGDAPByDefault: false	Chování API Partnerského centra (POST /v1/customers) Žádná změna požadavku nebo datové části	Chování uživatelského rozhraní Partnerského centra
Sandbox	25. září 2023 (jenom rozhraní API)	DAP = Ne. Výchozí GDAP = Ano	DAP = Ne. Výchozí hodnota GDAP: Ne	DAP = Ano. Výchozí GDAP = Ne	Výchozí GDAP = Ano
Výroba	10. října 2023 (API a uživatelské rozhraní)	DAP = Ne. Výchozí GDAP = Ano	DAP = Ne. Výchozí GDAP = Ne	DAP = Ano. Výchozí hodnota GDAP = Ne	Možnost přihlášení/odhlášení je k dispozici: Výchozí GDAP
Výroba	27. listopadu 2023 (uvedení GA bylo ukončeno 2. prosince)	DAP = Ne. Výchozí GDAP = Ano	DAP = Ne. Výchozí GDAP = Ne	DAP = Ne. Výchozí GDAP = Ano	Přihlášení/odhlášení k dispozici: Výchozí GDAP

Partneři musí explicitně udělit podrobná oprávnění skupinám zabezpečení ve výchozím GDAP.
Od 10. října 2023 už není DAP k dispozici v partnerských vztazích s prodejci. Aktualizovaný odkaz Request Reseller Relationship je k dispozici v uživatelském rozhraní Partnerského centra a adresa URL vlastnosti smlouvy API "/v1/customers/relationship requests" vrátí adresu URL pozvánky, která se odešle správci zákaznického tenanta.

Ano, partneři musí explicitně udělit podrobná oprávnění skupinám zabezpečení ve výchozím GDAP pro správu zákazníka.

Partneři, kteří mají vztah prodejce jenom bez DAP nebo GDAP, můžou vytvářet zákazníky, zadávat a spravovat objednávky, stahovat klíče softwaru, spravovat Azure RI. Nemůžou zobrazit podrobnosti o společnosti zákazníka, nemůžou zobrazit uživatele ani přiřazovat licence uživatelům, nemůžou protokolovat lístky jménem zákazníků a nemůžou přistupovat k centerm pro správu konkrétních produktů a spravovat je (například Centrum pro správu Teams).)

Aby měl partner nebo CPV přístup k tenantovi zákazníka a mohl ho spravovat, musí být služební principál aplikace odsouhlasen v tenantovi zákazníka. Když je DAP aktivní, musí přidat instanční objekt aplikace do skupiny agentů pro správu v partnerském tenantovi. U GDAP musí partner zajistit, aby byla jejich aplikace odsouhlasená v tenantovi zákazníka. Pokud aplikace používá delegovaná oprávnění (App + Uživatel) a aktivní GDAP existuje s některou ze tří rolí (správce cloudových aplikací, správce aplikací), můžete použít rozhraní API pro vyjádření souhlasu. Pokud aplikace používá pouze oprávnění aplikace, musí s ním souhlasit ručně buď partner, nebo zákazník, který má některou ze tří rolí (správce cloudových aplikací, správce aplikací), pomocí adresy URL souhlasu správce v rámci celého tenanta.

Pokud se zobrazí následující chyba:

"V tuto chvíli nemůžeme ověřit vaši žádost o vytvoření nové relace GDAP. Doporučujeme, aby pro tuto službu nebyla povolena anonymní připojení. Pokud se domníváte, že se vám tato zpráva zobrazila omylem, zkuste žádost zopakovat. Vyberte pro zobrazení akcí, které můžete provést. Pokud problém přetrvává, obraťte se na podporu a uveďte zprávu s kódem 715–123220 a ID transakce: guid.

Změňte způsob připojení k Microsoft, aby služba ověření identity běžela správně. Pomáhá zajistit, aby váš účet nebyl ohrožen a dodržoval předpisy, které Microsoft musí dodržovat.

Co můžete udělat:

• Vymažte mezipaměť prohlížeče.
• Vypněte ochranu před sledováním v prohlížeči nebo přidejte náš web do seznamu výjimek nebo bezpečných.
• Vypněte všechny programy nebo služby virtuální privátní sítě (VPN), které možná používáte.
• Připojte se přímo z místního zařízení místo virtuálního počítače.

Pokud se po vyzkoušení předchozích kroků stále nemůžete připojit, doporučujeme se s it helpdeskem poradit, abyste zkontrolovali nastavení a zjistili, jestli vám můžou pomoct zjistit, co je příčinou problému. Někdy je problém v nastavení sítě vaší společnosti. Správce IT by tento problém potřeboval vyřešit, například bezpečným výpisem našeho webu nebo provedením dalších úprav nastavení sítě.

• Restricted (Direct Bill): Nelze vytvořit nové GDAP (adminská spojení). Stávající GDAP a jejich přiřazení rolí je možné aktualizovat.
• Pozastaveno (přímé účtování/nepřímý poskytovatel/nepřímý prodejce): Nový GDAP, se nedá vytvořit. Stávající GDAP a jejich přiřazení rolí nelze aktualizovat.
• Restricted (Direct Bill) + Active (Nepřímý prodejce): Pro omezený Direct Bill: Nové vztahy GDAP (správcovské vztahy) nelze vytvořit. Stávající GDAP a jejich přiřazení rolí je možné aktualizovat. V případě aktivního nepřímého prodejce: Je možné vytvořit nové GDAP, stávající GDAP a jejich přiřazení rolí je možné aktualizovat. Když je ukončeno používání a nový GDAP nelze vytvořit, stávající GDAP a jejich přiřazení rolí se nedají aktualizovat.

Ano. Aktuální verze GDAP podporuje všechny produkty: Microsoft 365, Dynamics 365, Microsoft Power Platform a Microsoft Azure.