Nejčastější dotazy k GDAP

Někdo, kdo má roli agenta správce 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 prodloužit vztah správce o šest měsíců, dokud se neukončí nebo automatické prodloužení nastaví na Zakázáno.

Ne. Vztah GDAP nepodporuje předplatná zakoupená prostřednictvím smluv Enterprise.

Ano. Relace GDAP se může automaticky prodloužit o šest měsíců do ukončení nebo automatického prodloužení nastaveného 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 prodloužit vztah GDAP, musí partner nebo zákazník nastavit Automatické rozšíření na Povoleno. Další informace najdete v správa GDAP Auto rozšíření a API.

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

Řekněme, že se GDAP vytvoří po dobu 365 dnů s automatickým prodloužením nastaveným na 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í budou pokračovat as-is.

Ne. Vztah správce nemůžete automaticky rozšířit s rolí globálního správce.

Stránka odstupňované relace konci platnosti je dostupná jenom pro partnerské uživatele s rolemi globálních správců a agenta pro správu. Tato stránka pomáhá filtrovat hodnoty GDAPs, jejichž platnost vyprší na různých časových osách, a pomáhá aktualizovat automatické rozšíř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.

Přečtěte si Řešení potíží s vícefaktorovým ověřováním Microsoft Entra a Nejde použít vícefaktorové ověřování Microsoft Entra k přihlášení ke cloudovým službám po ztrátě telefonu nebo změny telefonního čísla s pokyny.

Partner musí při vytváření prvního GDAP požádat správce privilegovaného ověřování roli 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 Tool a plánuje se, že budou dostupné s výchozím GDAP během vytváření toku zákazníka (plánované na září).
• Partner může mít, aby správce zákazníka zkusil Resetovat heslo.
• Partner musí pro své zákazníky nastavit samoobslužné resetování hesla (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í osoby s agentem Admin.
• V organizaci zákazníka obdrží oznámení o ukončení osoby s rolí globálního správce 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 vybrané skupiny zabezpečení vytvořené v partnerském tenantovi s uživateli partnera. Ujistěte se také, že požadované role Microsoft Entra jsou přiřazené ke skupině zabezpečení. Přečtěte si přiřazení rolí Microsoft Entra.

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). V případě zásad určených pro tenanty poskytovatele cílových služeb použijte typ externího uživatele, který je k dispozici v možnostech Host nebo externích uživatelů, možnosti výběru.
• 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 Poskytovatel 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 tady:
• rozhraní Graph API: Beta rozhraní API s informacemi o novém typu externího uživatele
• zásad podmíněného přístupu
• externím uživatelům podmíněného přístupu

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 nejčastějších dotazech ke kopírování zabezpečení.

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í podporované, platí obecné pokyny pro jakékoli beta rozhraní API v Graphu a neplatí pro rozhraní Graph API beta verze.

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 .

Rozhraní API funguje najednou pro jednu skupinu zabezpečení, ale v Partnerském centru můžete namapovat více skupin zabezpečení na více rolí.

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.windows.net/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ěřit sestavy přihlašování aplikací Microsoftu první strany – 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 pro EnterpriseApplicationId nepoužívejte název prostředku, jako je graph.microsoft.com.
• použít správné požadavek pro enterpriseApplicationId, použijte ID zdroje, například 000000003-0000-0000-c000-00000000000000.

Například dříve v graph.microsoft.com prostředku byl 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 z tenanta zákazníka použijte metodu DELETE.
2. Pomocí metody POST vytvořte nový souhlas aplikace s dalšími obory.

Zřetězení požadovaných oborů pomocí čárky následované mezerou 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 oprávnění podrobného delegovaného správce (GDAP) s tenantem zákazníka s alespoň jednou z následujících tří rolí GDAP a dokončili jste přiřazení přístupu:
  • Role globálního správce, správce aplikací nebo 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ým postupem), vytvořte skupinu zabezpečení (například Azure Managers) a ji vnořit do agentů pro správu.
• Pokud chcete získat přístup k předplatnému Azure jako vlastníka zákazníka, můžete přiřadit libovolné předdefinované role Microsoft Entra (například čtenáři adresáře, nejnižší privilegovanou roli) Azure Managers skupiny zabezpečení. Postup nastavení GDAP v Azure najdete v tématu Úlohy 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, naleznete v tématu Nejméně privilegované role podle úlohy v Microsoft Entra.

Doporučujeme přiřadit roli správce podpory služby. Další informace najdete v tématu Nejméně privilegované role podle úkolů v aplikaci Microsoft Entra.

• Aby se snížila mezera mezi rolemi Microsoft Entra 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
  • Viva Goals Administrator
  • Viva Pulse Administrator
  • 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

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é vytvořit lístky podpory pro zákazníka, musí být partner uživatel ve skupině zabezpečení a přiřazený danému zákazníkovi s danou rolí.

Informace o všech rolích naleznete v tématu předdefinované role Microsoft Entra. 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 Centrum pro správu Microsoftu 365. Další informace najdete v tématu Běžně používané role Centra 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 jen pro čtení poskytuje globální čtenář, čtenář adresářůa partnerská vrstva 2 podporují role.

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čí vztah prodejce partnerů se zákazníkem. Partneři si stále můžou koupit produkty pro zákazníka a spravovat rozpočet Azure 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 rámci vašeho tenanta CSP. 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ícecustomery automatizovat pomocí rozhraní API.

Správci hostů GDAP nemůžou spravovat své vlastní informace o zabezpečení na Informace o zabezpečení . Místo toho potřebují pomoc správce tenanta, ve kterém je host, aby se mohli registrovat, aktualizovat nebo odstranit bezpečnostní údaje. Organizace můžou nakonfigurovat zásady přístupu mezi tenanty tak, aby důvěřovaly vícefaktorovému ověřování z 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 SMS nebo Hlas). Další informace najdete v tématu zásady přístupu mezi tenanty.

Zarovnejte se s principem nulové důvěryhodnosti Guid: Použijte přístup s nejnižšími oprávněními:

• Doporučujeme použít nejméně privilegovanou roli podle úloh a úloh úloh úloh podporovaných podrobnými delegovanými oprávněními správce (GDAP) podporovanými 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 nahradit roli globálního správce všemi možný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 Microsoft 365, Dynamics 365a úlohy 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 tenanta zákazníka. 25. září 2023 už Microsoft 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:

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 všechny privilegované skupiny přístupu (dříve název PIM pro funkce skupiny) byly v skupině role. 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 můžou v PIM používat a skupiny, které se nedají přiřazovat role. Tato možnost efektivně odebere limit 500 skupin/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 onboardingu skupin přiřazených rolí nebo skupin, které nejsou přiřazené rolí, prostřednictvím nabídky PIM je už dostupná.
  • Možnost onboardingu skupin přiřazených rolí nebo skupin, které nejsou přiřazené rolí, prostřednictvím nabídky Skupiny je už dostupná.
• Další informace najdete v tématu Privileged Identity Management (PIM) pro skupiny (Preview) – Microsoft Entra.

GDAP je obecně dostupná s podporou všech komerčních cloudových služeb Microsoftu (Microsoft 365, Dynamics 365, Microsoft Azurea úloh microsoft Power Platform). Další informace o tom, jak může daP a GDAP existovat a jak má přednost GDAP, najdete v této nejčastější dotazy Jak mají oprávnění GDAP přednost před oprávněními DAP, zatímco DAP a GDAP spolu existují? otázku.

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 se v palu neprocházejí žádné změny, takže budete i nadále získávat PEC.

• Pokud má zákazník partnera jenom DAP a DAP se odebere, pec se neztratí.
• Pokud má zákazník partnera DAP a současně přejde do GDAP pro Microsoft 365 a Azure a odebere se DAP, pec se neztratí.
• Pokud má zákazník partnera DAP a přejde do GDAP pro Microsoft 365, ale azure as-is (nepřesunou se do GDAP) a DAP se odebere, pec se neztratí, ale ztratí se přístup k předplatnému Azure.
• Pokud je role RBAC odebrána, dojde ke ztrátě pece, 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 DAP i 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á roli globálního správce a GDAP pro roli globálního čtenáře, získá partnerský uživatel 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):

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

DAP a GDAP nejsou vhodné typy přidružení pro označení partnerů řešení. aDisabling nebo přechod z DAP na GDAP nemá vliv na dosažení označení partnerů ř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 Lighthousem a DAP/GDAP, představte si je jako oddělené paralelní cesty k prostředkům Azure. Udělování jednoho by nemělo mít vliv na druhou.

• Ve scénáři Azure Lighthouse se uživatelé z partnerského tenanta nikdy nepřihlašují k tenantovi zákazníka a nemají v tenantovi zákazníka žádná oprávnění Microsoft Entra. Jejich 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 Azure RBAC ke skupině agentů pro správu je také v tenantovi zákazníka. Cestu GDAP (uživatelé už se nemůžou přihlásit) můžete zablokovat, i když cesta Azure Lighthouse nemá vliv. Naopak relace Lighthouse (projekce) můžete oddělit, aniž by to mělo vliv na GDAP. Další informace najdete v dokumentaci ke službě Azure Lighthouse.

Poskytovatelé spravovaných služeb zaregistrovaní v programu Cloud Solution Provider (CSP) jako nepřímých prodejců nebo přímým vyúčtováním partneři teď můžou používat Microsoft 365 Lighthouse k nastavení GDAP pro libovolného tenanta zákazníka. Vzhledem k tomu, že partneři už spravují svůj přechod na GDAP, tento průvodce umožňuje partnerům Lighthouse přijmout doporučení rolí specifická pro své obchodní potřeby. Umožňuje jim také přijmout bezpečnostní opatření, jako je přístup ZA běhu (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 pro Microsoft 365 Lighthouse najdete v tématu Požadavky na Microsoft 365 Lighthouse.

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

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

Následující posloupnost může vést ke ztrátě ztrátě přístupových k předplatným Azure:

1. Odeberte DAP. Odebráním 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 přiřazení rolí Azure RBAC (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 společně. V tomto kroku můžete přijít o přístup k předplatnému Azure hned po nastavení GDAP.
3. Přiřazení rolí Microsoft Entra ke skupinám zabezpečení pro Microsoft 365 i Azure

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

Pokud máte předplatná Azure bez DAP, která spravujete jako vlastníka, můžete při přidávání GDAP pro Microsoft 365 do daného zákazníka přijít o přístup k předplatným Azure. Pokud se chcete vyhnout ztrátě přístupu, přesuňte zákazníka do azure GDAP současně, že zákazníka přesunete do GDAP Microsoftu 365.

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 vztah GDAP, abyste mohli spravovat svá předplatná Azure.

1. Vytvořte skupinu zabezpečení (například Azure Managers) v Microsoft Entra.
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 v případě, že neexistuje žádný plán DAP nebo GDAP s existujícím vztahem prodejce. 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 se podrobnosti o společnosti zobrazily takto:

• Aktivní relace GDAP.
• Jsou přiřazeny některé z následujících rolí Microsoft Entra: globální správce, čtenáři adresářů, globální čtenář. Přečtěte si udělení podrobných oprávnění skupinám zabezpečení.

Když se poskytovatel CSP přihlásí k webu Azure Portal zákazníka (portal.azure.come) pomocí svých přihlašovacích údajů CSP a existuje vztah GDAP, poskytovatel CSP si všimne, ž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.

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 pro vztahy prodejců. Aktualizovaný odkaz Request Reseller Relationship je k dispozici v uživatelském rozhraní Partnerského centra a adresa URL vlastnosti "/v1/customers/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 softwarové klíče, spravovat rezervované instance Azure. 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 partner nebo CPV měli přístup k tenantovi zákazníka a mohli ho spravovat, musí být instanční objekt aplikace v tenantovi zákazníka odsouhlasený. 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 jejich aplikace byla v tenantovi zákazníka odsouhlasený. 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í, globální správce) můžete použít rozhraní API pro vyjádření souhlasu. Pokud aplikace používá pouze oprávnění aplikace, musí s ní souhlasit ručně buď partner, nebo zákazník, který má některou ze tří rolí (správce cloudových aplikací, správce aplikací, globální správce), 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. Výběrem získáte informace o akcích, které můžete provést. Pokud problém přetrvává, obraťte se na kód podpory a referenční zprávy 715–123220 a ID transakce: guid.

Změňte způsob připojení k Microsoftu, aby služba ověření identity fungovala správně. Pomáhá zajistit, aby váš účet nebyl ohrožen a dodržoval předpisy, které musí microsoft 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. Váš správce IT by tento problém potřeboval vyřešit například tak, že web vypisuje bezpečným výpisem nebo provede jiné úpravy nastavení sítě.

• Restricted (Direct Bill): New GDAP (Admin Relationships) cannot be created. Stávající GDAP a jejich přiřazení rolí je možné aktualizovat.
• Pozastaveno (přímý účet/ nepřímý poskytovatel nebo 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ý přímý účet: Nové relace GDAP (vztahy správců) 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ž není možné vytvořit nový GDAP, 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 Platforma Microsoft Azure.