Często zadawane pytania dotyczące GDAP

Osoba z rolą agenta administratora w organizacji partnerskiej może utworzyć żądanie relacji GDAP.

Tak. Żądania relacji GDAP wygasają po upływie 90 dni.

Nie. Trwałe relacje GDAP z klientami nie są możliwe ze względów bezpieczeństwa. Maksymalny czas trwania relacji GDAP wynosi dwa lata. Możesz ustawić automatyczne rozszerzanie na włączone, aby przedłużyć relację administratora o sześć miesięcy, aż do zakończenia lub automatycznego rozszerzania na Wyłączone.

Nie. Relacja GDAP nie obsługuje subskrypcji zakupionych w ramach umów Enterprise Agreement.

Tak. Relacja GDAP może być automatycznie przedłużana o sześć miesięcy do momentu zakończenia lub automatycznego rozszerzenia ustawionego na wartość Wyłączone.

• Jeśli relacja GDAP z klientem wygaśnie, zażądać relacji GDAP ponownie.
• Możesz użyć analizy relacji GDAP do śledzenia dat wygaśnięcia relacji GDAP i przygotowania do ich odnowienia.

Aby rozszerzyć lub odnowić relację GDAP, partner lub klient musi ustawić Automatyczne rozszerzanie na włączone. Dowiedz się więcej na temat Manage GDAP Auto extend and API.

Tak. Jeśli GDAP jest aktywny, można go rozszerzyć.

Załóżmy, że GDAP jest tworzony przez 365 dni z automatycznym rozszerzeniem ustawionym na włączone. W ciągu 365 dni data zakończenia skutecznie aktualizuje się o 180 dni.

Tak. Możesz automatycznie rozszerzyć dowolną aktywną aplikację GDAP.

Nie. Zgoda klienta nie jest wymagana, aby ustawić automatyczne rozszerzenie na Włączone dla istniejącej aktywnej GDAP.

Nie. Szczegółowe uprawnienia przypisane do grup zabezpieczeń kontynuują as-is.

Nie. Nie można automatycznie rozszerzyć relacji administratora z rolą administratora globalnego.

Strona Wygasające szczegółowe relacje jest dostępna tylko dla użytkowników partnerskich z rolami administratorów globalnych i agenta administracyjnego. Ta strona pomaga filtrować wygasające GDAPs na różnych osiach czasu i pomaga aktualizować automatyczne rozszerzanie (włączanie/wyłączanie) dla co najmniej jednego modułu GDAPs.

Nie. Nie ma żadnych zmian w istniejących subskrypcjach klienta po wygaśnięciu relacji GDAP.

Zapoznaj się z Rozwiązywanie problemów z uwierzytelnianiem wieloskładnikowym firmy Microsoft i nie można używać uwierzytelniania wieloskładnikowego firmy Microsoft w celu zalogowania się do usług w chmurze po utracie telefonu lub zmianie numeru telefonu, aby uzyskać wskazówki.

Partner musi poprosić administrator uwierzytelniania uprzywilejowanego rolę Microsoft Entra podczas tworzenia pierwszego GDAP.

• Ta rola umożliwia partnerowi zresetowanie hasła i metody uwierzytelniania dla administratora lub użytkownika niebędącego administratorem. Rola administratora uwierzytelniania uprzywilejowanego jest częścią ról skonfigurowanych przez narzędzie led firmy Microsoft i ma być dostępna w domyślnym przepływie GDAP podczas tworzenia klienta (planowanego na wrzesień).
• Partner może spróbować zresetować hasło.
• Jako środek ostrożności partner musi skonfigurować samoobsługowe resetowanie hasła dla swoich klientów. Aby uzyskać więcej informacji, zobacz Zezwalaj użytkownikom na resetowanie własnych haseł.

• W organizacji partnera osoby z rolą administratora otrzymują powiadomienie o zakończeniu.
• W organizacji klienta osoby z rolą administratora globalnego otrzymują powiadomienie o zakończeniu pracy.

Tak. Partnerzy mogą zobaczyć, kiedy klient usunie aplikację GDAP w dziennikach aktywności Centrum partnerskiego.

Nie. GDAP to opcjonalna funkcja dla partnerów, którzy chcą zarządzać usługami swoich klientów w bardziej szczegółowy i ograniczony czas. Możesz wybrać klientów, z którymi chcesz utworzyć relację GDAP.

Odpowiedź zależy od tego, jak chcesz zarządzać klientami.

• Jeśli chcesz, aby użytkownicy partnerów mogli zarządzać wszystkimi klientami, możesz umieścić wszystkich użytkowników partnerów w jednej grupie zabezpieczeń i że jedna grupa może zarządzać wszystkimi klientami.
• Jeśli wolisz mieć różnych partnerów zarządzających różnymi klientami, przypisz tych użytkowników partnerów do oddzielnych grup zabezpieczeń na potrzeby izolacji klientów.

Tak. Odsprzedawcy pośredni (i pośredni dostawcy i partnerzy rozliczani bezpośrednio) mogą tworzyć żądania relacji GDAP w Centrum partnerskim.

W ramach konfiguracji programu GDAP upewnij się, że wybrano grupy zabezpieczeń utworzone w dzierżawie partnera z użytkownikami partnerskimi. Upewnij się również, że odpowiednie role entra firmy Microsoft są przypisane do grupy zabezpieczeń. Zapoznaj się Przypisywanie ról usługi Microsoft Entra.

Klienci mogą teraz wykluczać dostawców CSP z zasad dostępu warunkowego, aby partnerzy mogli przejść do usługi GDAP bez blokowania.

• uwzględnij użytkowników — ta lista użytkowników zazwyczaj obejmuje wszystkich użytkowników, których organizacja jest przeznaczona w zasadach dostępu warunkowego.
• Podczas tworzenia zasad dostępu warunkowego dostępne są następujące opcje:
• Wybieranie użytkowników i grup
• Użytkownicy-goście lub zewnętrzni (wersja zapoznawcza)
• Ten wybór zawiera kilka opcji, które mogą służyć do określania zasad dostępu warunkowego do określonych typów gości lub użytkowników zewnętrznych i określonych dzierżaw zawierających tych typów użytkowników. Istnieje kilka różnych typów użytkowników-gości lub użytkowników zewnętrznych, które można wybrać, a można wybrać wiele opcji:
• Użytkownicy dostawcy usług, na przykład Dostawca rozwiązań w chmurze (CSP).
• Można określić co najmniej jedną dzierżawę dla wybranych typów użytkowników lub określić wszystkie dzierżawy.
• dostęp partnera zewnętrznego — zasady dostępu warunkowego przeznaczone dla użytkowników zewnętrznych mogą zakłócać dostęp dostawcy usług, na przykład szczegółowe uprawnienia administratora delegowanego. Aby uzyskać więcej informacji, zobacz Introduction to granular delegated admin privileges (GDAP). W przypadku zasad przeznaczonych dla dzierżaw dostawców usług należy użyć użytkownika dostawcy usług typu użytkownika zewnętrznego dostępnego w opcjach wyboru gościa lub użytkowników zewnętrznych.
• Wyklucz użytkowników — gdy organizacje obejmują i wykluczają użytkownika lub grupę, użytkownik lub grupa jest wykluczony z zasad, ponieważ akcja wykluczania zastępuje akcję dołączania w zasadach.
• Następujące opcje są dostępne do wykluczenia podczas tworzenia zasad dostępu warunkowego:
• Goście lub użytkownicy zewnętrzni
• Ten wybór zawiera kilka opcji, które mogą służyć do określania zasad dostępu warunkowego do określonych typów gości lub użytkowników zewnętrznych i określonych dzierżaw zawierających tych typów użytkowników. Istnieje kilka różnych typów gości lub użytkowników zewnętrznych, które można wybrać, a można dokonać wielu wyborów:
• Użytkownicy dostawcy usług, na przykład dostawca rozwiązań w chmurze (CSP)
• Dla wybranych typów użytkowników można określić co najmniej jedną dzierżawę lub określić wszystkie dzierżawy. Aby uzyskać więcej informacji, zobacz:
• środowisko interfejsu API programu Graph: interfejs API beta z nowymi informacjami o typie użytkownika zewnętrznego
• zasad dostępu warunkowego
• dostęp warunkowy użytkowników zewnętrznych

Tak. Niezależnie od posiadanego planu pomocy technicznej, najmniej uprzywilejowaną rolą dla użytkowników partnerów, aby móc tworzyć bilety pomocy technicznej dla swoich klientów, jest administratorem pomocy technicznej usługi.

Nie. Partner nie może obecnie zakończyć GDAP w stanie Zatwierdzenia oczekujące na. Wygaśnie w ciągu 90 dni, jeśli klient nie podejmie żadnych działań.

Dopiero po upływie 365 dni (czyszczenie) po zakończeniu lub wygaśnięciu relacji GDAP można ponownie użyć tej samej nazwy, aby utworzyć nową relację GDAP.

Tak. Partner może zarządzać swoimi klientami w różnych regionach bez tworzenia nowych dzierżaw partnerów na region klienta. Ma zastosowanie tylko do roli zarządzania klientami udostępnianej przez GDAP (Relacje administracyjne). Rola i możliwości transakcji są nadal ograniczone do autoryzowanych terytorium.

Nie. Dostawca usług nie może być częścią organizacji wielodostępnej, dlatego wzajemnie się wyklucza.

1. Upewnij się, że usługa GDAP jest prawidłowo skonfigurowana, w tym sposób udzielania uprawnień dla grup zabezpieczeń.
2. Upewnij się, że szczegółowe uprawnienia grupy zabezpieczeń są poprawne.
3. Aby uzyskać pomoc, zapoznaj się z często zadawanymi pytaniami dotyczącymi Security Copilot.

Aby uzyskać więcej informacji na temat interfejsów API i GDAP, zobacz dokumentację dla deweloperów centrum partnerskiego .

Tak. Zalecamy, aby partnerzy używali interfejsów API beta GDAP do środowiska produkcyjnego, a później przełączać się na interfejsy API w wersji 1, gdy staną się dostępne. Chociaż istnieje ostrzeżenie: "Korzystanie z tych interfejsów API w aplikacjach produkcyjnych nie jest obsługiwane", że ogólne wskazówki dotyczą żadnego interfejsu API beta w programie Graph i nie mają zastosowania do interfejsów API programu Graph w wersji beta GDAP.

Tak. Relacje GDAP można tworzyć przy użyciu interfejsów API, co umożliwia partnerom skalowanie tego procesu. Jednak tworzenie wielu relacji GDAP nie jest dostępne w Centrum partnerskim. Aby uzyskać informacje na temat interfejsów API i GDAP, zobacz dokumentację dla deweloperów centrum partnerskiego .

Interfejs API działa dla jednej grupy zabezpieczeń jednocześnie, ale można mapować wiele grup zabezpieczeń na wiele ról w Centrum partnerskim.

Wykonaj pojedyncze wywołania dla każdego zasobu. Podczas tworzenia pojedynczego żądania POST przekaż tylko jeden zasób i odpowiadające mu zakresy. Aby na przykład zażądać uprawnień zarówno dla https://graph.windows.net/Directory.AccessAsUser.All, jak i https://graph.microsoft.com/Organization.Read.All, wykonaj dwa różne żądania, po jednym dla każdego.

Użyj podanego linku, aby wyszukać nazwę zasobu: Sprawdź aplikacje firmy Microsoft w raportach logowania firmy Microsoft — Active Directory. Aby na przykład znaleźć identyfikator zasobu 000000003-0000-0000-c000-00000000000000 dla graph.microsoft.com:

Ten błąd występuje zwykle, gdy w filtrze zapytania jest używany nieprawidłowy identyfikator. Aby rozwiązać ten problem, upewnij się, że używasz właściwości enterpriseApplicationId z poprawnym identyfikatorem zasobu , a nie nazwą zasobu.

• Niepoprawne żądanie dla enterpriseApplicationIdnie używaj nazwy zasobu, takiej jak graph.microsoft.com.
• poprawne żądanie Zamiast tego w przypadku enterpriseApplicationIdużyj identyfikatora zasobu, takiego jak 00000003-0000-0000-c000-000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004444444; poprawne żądanie zamiast tego dla enterpriseApplicationIdużyj identyfikatora zasobu, takiego jak 000000000000000 0000

Na przykład wcześniej w graph.microsoft.com zasób wyraził zgodę tylko na zakres "profilu". Teraz musimy dodać profil i plik user.read również. Aby dodać nowe zakresy do wcześniej objętej zgodą aplikacji:

1. Użyj metody DELETE, aby odwołać istniejącą zgodę aplikacji z dzierżawy klienta.
2. Użyj metody POST, aby utworzyć nową zgodę aplikacji z dodatkowymi zakresami.

Połącz wymagane zakresy przy użyciu przecinka, po którym następuje spacja. Na przykład "scope": "profile, User.Read"

1. Upewnij się, że właściwości "displayName" i "applicationId" w treści żądania są dokładne i zgodne z aplikacją, którą próbujesz wyrazić w dzierżawie klienta.
2. Upewnij się, że używasz tej samej aplikacji do generowania tokenu dostępu, który próbujesz wyrazić zgodę na dzierżawę klienta. Na przykład: Jeśli identyfikator aplikacji to "12341234-1234-1234-12341234", oświadczenie "appId" w tokenie dostępu powinno również mieć wartość "12341234-1234-1234-1234-12341234".
3. Sprawdź, czy spełniony jest jeden z następujących warunków:

• Masz aktywny uprawnienia administratora delegowanego (DAP), a użytkownik jest również członkiem grupy zabezpieczeń Agentów administracyjnych w dzierżawie partnera.
• Masz aktywną relację z uprawnieniami administratora delegowanego (GDAP) z dzierżawą klienta z co najmniej jedną z następujących trzech ról GDAP i ukończono przypisanie dostępu:
  • Rola administratora globalnego, administratora aplikacji lub administratora aplikacji w chmurze.
  • Użytkownik partnera jest członkiem grupy zabezpieczeń określonej w przypisaniu dostępu.

• Aby zarządzać platformą Azure przy użyciu partycjonowania dostępu poszczególnych klientów (co jest zalecanym najlepszym rozwiązaniem), utwórz grupę zabezpieczeń (taką jak Azure Managers) i zagnieżdżać ją w obszarze Agenci administracyjni.
• Aby uzyskać dostęp do subskrypcji platformy Azure jako właściciel klienta, możesz przypisać dowolną wbudowaną rolę Microsoft Entra (na przykład czytelników katalogu , najmniej uprzywilejowaną rolę) do grupy zabezpieczeń Azure Managers. Aby uzyskać instrukcje konfigurowania usługi Azure GDAP, zobacz Obciążenia obsługiwane przez szczegółowe uprawnienia administratora delegowanego (GDAP).

Tak. Aby uzyskać informacje na temat ograniczania uprawnień administratora użytkownika przez przypisanie ról o najniższych uprawnieniach uprzywilejowanych w usłudze Microsoft Entra, zobacz Role o najniższych uprawnieniach według zadania w usłudze Microsoft Entra.

Zalecamy przypisanie roli administratora pomocy technicznej usługi Service. Aby dowiedzieć się więcej, zobacz Role o najniższych uprawnieniach według zadania w usłudze Microsoft Entra.

• Aby zmniejszyć różnicę między rolami firmy Microsoft entra dostępnymi w interfejsie API Centrum partnerskiego a interfejsem użytkownika, w lipcu 2024 r. dostępna jest lista dziewięciu ról w interfejsie użytkownika Centrum partnerskiego.
• W obszarze Współpraca:
  • Microsoft Edge Administrator
  • Administrator wizyt wirtualnych
  • Viva Goals Administrator
  • Viva Pulse Administrator
  • Yammer Administrator
• W obszarze Tożsamość:
  • Administrator zarządzania uprawnieniami
  • Administrator przepływów pracy cyklu życia
• W obszarze Inne:
  • Administrator znakowania organizacyjnego
  • Osoba zatwierdzająca komunikaty organizacyjne

Nie. Najmniej uprzywilejowaną rolą dla użytkowników partnerów, którzy mogą tworzyć bilety pomocy technicznej dla swojego klienta, jest administrator pomocy technicznej usługi . W związku z tym, aby móc tworzyć bilety pomocy technicznej dla klienta, użytkownik partnera musi należeć do grupy zabezpieczeń i przypisać go do tego klienta z rolą.

Aby uzyskać informacje o wszystkich rolach, zobacz wbudowane role firmy Microsoft Entra. Aby uzyskać informacje o obciążeniach, zobacz Obciążenia obsługiwane przez szczegółowe uprawnienia administratora delegowanego (GDAP).

W Centrum administracyjnym platformy Microsoft 365 jest używanych wiele ról. Aby uzyskać więcej informacji, zobacz Często używane role centrum administracyjnego platformy Microsoft 365.

Tak. Utwórz grupę zabezpieczeń, przypisz zatwierdzone role, a następnie przypisz użytkowników dzierżawy partnera do tej grupy zabezpieczeń.

Dostęp tylko do odczytu do subskrypcji klienta jest zapewniany przezrole czytelnika globalnego , czytelnika usługi Directory.

Zalecamy usunięcie agentów partnerskich z roli agenta administracyjnego i dodanie ich tylko do grupy zabezpieczeń GDAP. Dzięki temu mogą administrować usługami (na przykład żądaniami obsługi zarządzania usługami i rejestrowania), ale nie mogą kupować subskrypcji i zarządzać nimi (zmieniać ilości, anulować, planować zmiany itd.).

Grupy zabezpieczeń przypisane do relacji utracą dostęp do tego klienta. Dzieje się tak samo, jeśli klient zakończy relację języka DAP.

Tak. Usunięcie relacji GDAP z klientem nie kończy relacji odsprzedawcy partnerów z klientem. Partnerzy mogą nadal kupować produkty dla klienta i zarządzać budżetem platformy Azure oraz innymi powiązanymi działaniami.

Nie. Wszystkie role w relacji GDAP mają ten sam czas wygaśnięcia: czas trwania wybrany podczas tworzenia relacji.

Nie. Nie potrzebujesz GDAP do realizacji zamówień dla nowych i istniejących klientów. W celu realizacji zamówień klientów w Centrum partnerskim można nadal używać tego samego procesu.

Relacje GDAP są na klienta. Możesz mieć wiele relacji na klienta. Każda relacja GDAP może mieć różne role i używać różnych grup firmy Microsoft Entra w ramach dzierżawy CSP. W Centrum partnerskim przypisanie roli działa na poziomie relacji klient-GDAP. Jeśli chcesz przypisania roli multicustomer, możesz zautomatyzować korzystanie z interfejsów API.

Administratorzy gości GDAP nie mogą zarządzać własnymi informacjami o zabezpieczeniach w My Security-Info. Zamiast tego potrzebują pomocy administratora dzierżawy, w której są gośćmi w przypadku rejestracji, aktualizowania lub usuwania informacji zabezpieczających. Organizacje mogą skonfigurować zasady dostępu między dzierżawami w celu zaufania uwierzytelniania wieloskładnikowego z zaufanej dzierżawy CSP. W przeciwnym razie administratorzy gości GDAP są ograniczeni tylko do metod rejestrowanych przez administratora dzierżawy (czyli sms lub voice). Aby dowiedzieć się więcej, zobacz Zasady dostępu między dzierżawami.

Dopasuj do zasady przewodniej Zero Trust: Użyj dostępu do najniższych uprawnień:

• Zalecamy używanie roli o najniższych uprawnieniach przez zadania i zadania obciążenia obciążenia obsługiwane przez szczegółowe uprawnienia administratora delegowanego (GDAP) obsługiwane przez GDAP.
• Jeśli konieczne jest obejście znanych problemów, skontaktuj się z klientem, aby poprosić o przypisaną czas rolę administratora globalnego.
• Nie zaleca się zastąpienie roli administratora globalnego wszystkimi możliwymi rolami firmy Microsoft Entra.

Tak. W okresie przejściowym uprawnienia DAP i GDAP będą współistnieć, a uprawnienia GDAP mają pierwszeństwo przed uprawnieniami daP dla microsoft 365, Dynamics 365i obciążenia usługi Azure.

DAP i GDAP współistnieją w okresie przejściowym. Jednak ostatecznie GDAP zastępuje DAP, aby zapewnić bezpieczniejsze rozwiązanie dla naszych partnerów i klientów. Zalecamy jak najszybsze przeniesienie klientów do firmy GDAP w celu zapewnienia ciągłości działania.

Nie ma żadnych zmian w istniejącym przepływie relacji języka DAP, podczas gdy współistnieją GDAP i GDAP.

Usługa DAP jest obecnie udzielana podczas tworzenia nowej dzierżawy klienta. 25 września 2023 r. firma Microsoft nie udziela już programu DAP do tworzenia nowych klientów, a zamiast tego udziela domyślnej GDAP z określonymi rolami. Role domyślne różnią się w zależności od typu partnera, jak pokazano w poniższej tabeli:

Partnerzy mogą zaimplementować Privileged Identity Management (PIM) w grupie zabezpieczeń GDAP w dzierżawie partnera w celu podniesienia poziomu dostępu kilku użytkowników z wysokimi uprawnieniami, just in time (JIT), aby przyznać im role wysokiego poziomu uprawnień, takie jak administratorzy haseł z automatycznym usunięciem dostępu. Do stycznia 2023 r.wymagane było, aby każda uprzywilejowana grupa dostępu (była nazwa funkcji PIM dla grup) musiała znajdować się w grupie z możliwością przypisywania ról. To ograniczenie jest teraz usunięte. Biorąc pod uwagę tę zmianę, można włączyć ponad 500 grup na dzierżawy w usłudze PIM, ale tylko do 500 grup może być przypisywanych do ról. Streszczenie:

• Partnerzy mogą używać grup przypisywanych do ról i grup nieprzypisanych do ról w usłudze PIM. Ta opcja skutecznie usuwa limit 500 grup/tenant w usłudze PIM.
• W przypadku najnowszych aktualizacji dostępne są dwa sposoby dołączania grup do usługi PIM (UX-wise): z menu PIM lub z menu grup . Niezależnie od wybranego sposobu wynik netto jest taki sam.
  • Możliwość dołączania grup z możliwością przypisywania ról/nieprzypisania ról za pomocą menu PIM jest już dostępna.
  • Możliwość dołączania grup z możliwością przypisywania ról/nieprzypisania ról za pomocą menu Grupy jest już dostępna.
• Aby uzyskać więcej informacji, zobacz Privileged Identity Management (PIM) for Groups (wersja zapoznawcza) — Microsoft Entra.

GDAP jest ogólnie dostępna z obsługą wszystkich komercyjnych usług w chmurze firmy Microsoft (microsoft 365, Dynamics 365, Microsoft Azurei obciążenia platformy Microsoft Power Platform). Aby uzyskać więcej informacji o tym, jak dap i GDAP mogą współistnieć i jak GDAP ma pierwszeństwo, wyszukaj te często zadawane pytania dla Jak uprawnienia GDAP mają pierwszeństwo przed uprawnieniami DAP, podczas gdy DAP i GDAP współistnieją? pytanie.

Tę akcję można wykonać za pomocą interfejsów API.

Nie. Twoje zarobki PEC nie mają wpływu na przejście do GDAP. Nie ma żadnych zmian w pal z przejściem, zapewniając, że nadal zarabiasz PEC.

• Jeśli klient partnera ma tylko dap i DAP zostanie usunięty, pec nie zostanie utracony.
• Jeśli klient partnera ma daP i przechodzi do usługi GDAP dla platformy Microsoft 365 i platformy Azure jednocześnie, a platforma DAP zostanie usunięta, pec nie zostanie utracony.
• Jeśli klient partnera ma język DAP i przechodzi do usługi GDAP dla platformy Microsoft 365, ale zachowaj usługę Azure as-is (nie przechodzą do GDAP), a daP zostanie usunięty, pec nie zostanie utracony, ale dostęp do subskrypcji platformy Azure zostanie utracony.
• Jeśli rola RBAC zostanie usunięta, pec zostanie utracony, ale usunięcie GDAP nie spowoduje usunięcia kontroli dostępu opartej na rolach.

Gdy użytkownik jest częścią zarówno grupy zabezpieczeń GDAP, jak i grupy agentów administratora języka DAP i klient ma relacje DAP i GDAP, dostęp GDAP ma pierwszeństwo na poziomie partnera, klienta i obciążenia.

Jeśli na przykład użytkownik partnera zaloguje się do obciążenia i istnieje daP dla roli administratora globalnego i GDAP dla roli czytelnika globalnego, użytkownik partnera otrzymuje tylko uprawnienia czytelnika globalnego.

Jeśli istnieją trzech klientów z przypisaniami ról GDAP tylko do grupy zabezpieczeń GDAP (a nie agentów administracyjnych):

W poniższej tabeli opisano, co się stanie, gdy użytkownik zaloguje się do innej dzierżawy klienta.

Typy skojarzeń DAP i GDAP nie kwalifikują się do oznaczeń partnerów rozwiązań. aDisabling lub przejście z DAP do GDAP nie ma wpływu na osiągnięcie oznaczeń partnerów rozwiązań. Ponadto nie ma to wpływu na odnawianie starszych korzyści z kompetencji lub korzyści dla partnerów rozwiązań. Aby wyświetlić inne typy skojarzeń partnerów kwalifikujących się do oznaczenia Partner rozwiązań, zobacz Partner Center Solutions — oznaczenia partnerów.

Jeśli chodzi o relacje między usługami Azure Lighthouse i DAP/GDAP, pomyśl o nich jako o oddzielonych równoległych ścieżkach do zasobów platformy Azure. Zerwanie jednego nie powinno mieć wpływu na drugą.

• W scenariuszu usługi Azure Lighthouse użytkownicy z dzierżawy partnera nigdy nie logują się do dzierżawy klienta i nie mają żadnych uprawnień firmy Microsoft Entra w dzierżawie klienta. Ich przypisania ról RBAC platformy Azure są również przechowywane w dzierżawie partnera.
• W scenariuszu GDAP użytkownicy z dzierżawy partnera loguje się do dzierżawy klienta. Przypisanie roli RBAC platformy Azure do grupy agentów administracyjnych znajduje się również w dzierżawie klienta. Możesz zablokować ścieżkę GDAP (użytkownicy nie mogą już się zalogować), gdy ścieżka usługi Azure Lighthouse nie ma wpływu. Z drugiej strony, można zerwać relację Lighthouse (projekcja) bez wpływu na GDAP. Aby uzyskać więcej informacji, zobacz dokumentację Azure Lighthouse.

Dostawcy usług zarządzanych (MSP) zarejestrowani w programie Cloud Solution Provider (CSP) jako odsprzedawcy pośredni lub bezpośredniego rachunku partnerzy mogą teraz używać usługi Microsoft 365 Lighthouse do konfigurowania GDAP dla dowolnej dzierżawy klienta. Ponieważ istnieje kilka sposobów, w jaki partnerzy zarządzają już ich przejściem do GDAP, ten kreator umożliwia partnerom Lighthouse przyjęcie zaleceń dotyczących ról specyficznych dla ich potrzeb biznesowych. Umożliwia również im wdrażanie środków zabezpieczeń, takich jak dostęp just in time (JIT). Dostawcy usług zarządzanych mogą również tworzyć szablony GDAP za pośrednictwem usługi Lighthouse, aby łatwo zapisywać i ponownie stosować ustawienia, które umożliwiają dostęp klientów z najniższymi uprawnieniami. Aby uzyskać więcej informacji i wyświetlić pokaz, zobacz kreator instalacji Lighthouse GDAP. Deputowani mogą skonfigurować GDAP dla dowolnej dzierżawy klienta w lighthouse. Aby uzyskać dostęp do danych obciążenia klienta w usłudze Lighthouse, wymagana jest relacja GDAP lub DAP. Jeśli GDAP i DAP współistnieją w dzierżawie klienta, uprawnienia GDAP mają pierwszeństwo dla techników MSP w grupach zabezpieczeń z obsługą GDAP. Aby uzyskać więcej informacji na temat wymagań usługi Microsoft 365 Lighthouse, zobacz Requirements for Microsoft 365 Lighthouse.

Prawidłową sekwencją do naśladowania w tym scenariuszu jest:

1. Utwórz relację GDAP dla platformy Microsoft 365 i platformy Azure.
2. Przypisz role usługi Microsoft Entra do grup zabezpieczeń dla platformy Microsoft 365 i platformy Azure.
3. Skonfiguruj usługę GDAP, aby mieć pierwszeństwo przed usługą DAP.
4. Usuń język DAP.

Następująca sekwencja może spowodować utratę dostępu do subskrypcji platformy Azure:

1. Usuń język DAP. Niekoniecznie utracisz dostęp do subskrypcji platformy Azure, usuwając język DAP. Obecnie nie można jednak przeglądać katalogu klienta w celu wykonania żadnych przypisań ról RBAC platformy Azure (takich jak przypisywanie nowego użytkownika klienta jako współautora kontroli dostępu opartej na rolach subskrypcji).
2. Utwórz relację GDAP dla platformy Microsoft 365 i platformy Azure. Możesz utracić dostęp do subskrypcji platformy Azure w tym kroku zaraz po skonfigurowaniu aplikacji GDAP.
3. Przypisywanie ról usługi Microsoft Entra do grup zabezpieczeń dla platformy Microsoft 365 i platformy Azure

Po zakończeniu konfiguracji usługi Azure GDAP odzyskasz dostęp do subskrypcji platformy Azure.

Jeśli masz subskrypcje platformy Azure bez daP, którymi zarządzasz jako właściciel, podczas dodawania aplikacji GDAP dla platformy Microsoft 365 do tego klienta możesz utracić dostęp do subskrypcji platformy Azure. Aby uniknąć utraty dostępu, przenieś klienta do usługi Azure GDAP w tym samym czasie, że przenosisz klienta na platformę Microsoft 365 GDAP.

Nie. Relacje, po zaakceptowaniu, nie są wielokrotnego użytku.

Jeśli masz istniejącą relację odsprzedawcy z klientem, nadal musisz ustanowić relację GDAP, aby zarządzać subskrypcjami platformy Azure.

1. Utwórz grupę zabezpieczeń (na przykład Azure Managers) w usłudze Microsoft Entra.
2. Utwórz relację GDAP z rolą czytnika katalogów .
3. Ustaw grupę zabezpieczeń jako członka grupy agenta administracyjnego . Po wykonaniu tych kroków możesz zarządzać subskrypcją platformy Azure klienta za pomocą usługi AOBO. Nie można zarządzać subskrypcją za pomocą interfejsu wiersza polecenia/programu PowerShell.

Tak. Plan platformy Azure można utworzyć nawet wtedy, gdy nie ma relacji DAP ani GDAP z istniejącym odsprzedawcą. Jednak aby zarządzać subskrypcją, potrzebujesz języka DAP lub GDAP.

Ponieważ partnerzy przechodzą z DAP do GDAP, muszą upewnić się, że istnieją następujące elementy, aby zobaczyć szczegóły firmy:

• Aktywna relacja GDAP.
• Przypisane są dowolne z następujących ról firmy Microsoft Entra: Administrator globalny, Czytelnicy katalogów, Czytelnik globalny. Zapoznaj się z tematem udzielanie szczegółowych uprawnień do grup zabezpieczeń.

Gdy dostawca CSP loguje się do witryny Azure Portal klienta (portal.azure.come) przy użyciu poświadczeń dostawcy CSP i istnieje relacja GDAP, dostawca CSP zauważa, że jego nazwa użytkownika to "user_", po której następuje pewna liczba. Nie wyświetla rzeczywistej nazwy użytkownika, jak w języku DAP. Jest to zgodnie z projektem.

Partnerzy muszą jawnie przyznać szczegółowe uprawnienia do grup zabezpieczeń w domyślnym programie GDAP.
Od 10 października 2023 r. platforma DAP nie jest już dostępna z relacjami odsprzedawcy. Zaktualizowany link Relacja odsprzedawcy żądań jest dostępny w interfejsie użytkownika Centrum partnerskiego, a adres URL właściwości "/v1/customers/relationship requests" zwraca adres URL zaproszenia do wysłania do administratora dzierżawy klienta.

Tak, partnerzy muszą jawnie przyznać szczegółowe uprawnienia do grup zabezpieczeń w domyślnym GDAP do zarządzania klientem.

Partnerzy z relacją odsprzedawcy tylko bez języka DAP lub GDAP mogą tworzyć klientów, składać zamówienia i zarządzać nimi, pobierać klucze oprogramowania, zarządzać wystąpieniami zarezerwowanymi platformy Azure. Nie mogą wyświetlać szczegółów firmy klienta, nie mogą wyświetlać użytkowników ani przypisywać licencji do użytkowników, nie mogą rejestrować biletów w imieniu klientów i nie mogą uzyskiwać dostępu do centrów administracyjnych specyficznych dla produktu i administrować nimi (na przykład centrum administracyjne usługi Teams).

Aby partner lub CPV mógł uzyskiwać dostęp do dzierżawy klienta i zarządzać nią, jednostka usługi aplikacji musi być wyrażona w dzierżawie klienta. Gdy usługa DAP jest aktywna, musi dodać jednostkę usługi aplikacji do administratora agentów SG w dzierżawie partnera. W przypadku aplikacji GDAP partner musi upewnić się, że aplikacja jest wyrażana w dzierżawie klienta. Jeśli aplikacja korzysta z delegowanych uprawnień (aplikacji i użytkownika), a aktywna aplikacja GDAP istnieje z dowolną z trzech ról (administrator aplikacji w chmurze, administrator aplikacji, administrator globalny) można użyć interfejsu API zgody. Jeśli aplikacja korzysta tylko z uprawnień aplikacji, musi ona zostać ręcznie wyrażona na zgodę przez partnera lub klienta mającego dowolną z trzech ról (administrator aplikacji w chmurze, administrator aplikacji, administrator globalny), przy użyciu adresu URL zgody administratora w całej dzierżawie.

Jeśli zostanie wyświetlony następujący błąd:

"Nie możemy w tej chwili zweryfikować żądania "Utwórz nową relację GDAP". Należy poinformować, że połączenia anonimowe nie są dozwolone dla tej usługi. Jeśli uważasz, że ten komunikat został wyświetlony w błędzie, spróbuj ponownie wysłać żądanie. Wybierz, aby dowiedzieć się więcej o akcjach, które możesz wykonać. Jeśli problem będzie się powtarzać, skontaktuj się z pomocą techniczną i kodem komunikatu referencyjnego 715-123220 i identyfikatorem transakcji: identyfikator guid".

Zmień sposób nawiązywania połączenia z firmą Microsoft, aby umożliwić prawidłowe działanie usługi weryfikacji tożsamości. Pomaga to zapewnić, że Twoje konto nie zostało naruszone i jest zgodne z przepisami, z którymi firma Microsoft musi przestrzegać.

Czynności, które można wykonać:

• Wyczyść pamięć podręczną przeglądarki.
• Wyłącz zapobieganie śledzeniu w przeglądarce lub dodaj naszą witrynę do listy wyjątków/bezpiecznych.
• Wyłącz dowolny program wirtualnej sieci prywatnej (VPN) lub usługę, której możesz używać.
• Połącz się bezpośrednio z urządzenia lokalnego, a nie za pośrednictwem maszyny wirtualnej.

Jeśli po wykonaniu poprzednich kroków nadal nie możesz nawiązać połączenia, zalecamy skontaktowanie się z pomocą techniczną IT w celu sprawdzenia ustawień, aby sprawdzić, czy mogą one pomóc w zidentyfikowaniu przyczyn problemu. Czasami problem dotyczy ustawień sieci firmowych. Administrator IT musiałby rozwiązać ten problem, na przykład poprzez bezpieczną listę naszej witryny lub wprowadzenie innych zmian ustawień sieciowych.

• Ograniczony (rachunek bezpośredni): Nie można utworzyć nowych relacji GDAP (relacje administracyjne). Istniejące GDAPs i ich przypisania ról MOŻNA zaktualizować.
• Zawieszone (bezpośredni dostawca/dostawca pośredni/odsprzedawca pośredni): Nie można utworzyć nowej GDAP. Nie można zaktualizować istniejących elementów GDAPs i ich przypisań ról.
• Ograniczony (rachunek bezpośredni) + aktywny (odsprzedawca pośredni): nie można utworzyć nowego rachunku bezpośredniego z ograniczeniami GDAP (relacje administracyjne). Istniejące GDAPs i ich przypisania ról MOŻNA zaktualizować. Dla aktywnego odsprzedawcy pośredniego: można utworzyć nowy GDAP, istniejące GDAPs i ich przypisania ról MOŻNA zaktualizować. Gdy nie można utworzyć odłączonego nowego modułu GDAP, nie można zaktualizować istniejących przypisań ról GDAP i ich przypisań ról.

Tak. Bieżąca wersja aplikacji GDAP obsługuje wszystkie produkty: Microsoft 365, Dynamics 365, Microsoft Power Platformi Microsoft Azure.