Automatyczne zarządzanie tożsamościami

Automatyczne zarządzanie tożsamościami umożliwia bezproblemowe dodawanie użytkowników, jednostek usługi i grup z Microsoft Entra ID do Azure Databricks. Po włączeniu automatycznego zarządzania tożsamościami można bezpośrednio wyszukiwać użytkowników, jednostki usługi i grupy w federowanych obszarach roboczych tożsamości oraz dodawać je do obszaru roboczego. Azure Databricks używa usługi Microsoft Entra ID jako autorytatywnego źródła danych, więc wszelkie zmiany w członkostwie w grupach są uwzględniane w usłudze Azure Databricks.

Automatyczne zarządzanie tożsamościami jest domyślnie włączone dla kont utworzonych po 1 sierpnia 2025 r.

Użytkownicy mogą również udostępniać pulpity nawigacyjne dowolnym użytkownikom, jednostce usługi lub grupie u dostawcy tożsamości. Po udostępnieniu zasobów ci użytkownicy, jednostki usługi i członkowie grup są automatycznie dodawani do konta Azure Databricks podczas logowania. Nie są one dodawane jako członkowie do obszaru roboczego, w ramach którego znajduje się pulpit nawigacyjny. Użytkownicy, którzy nie mają dostępu do obszaru roboczego, otrzymują dostęp do kopii tylko widoku pulpitu nawigacyjnego opublikowanego przy użyciu udostępnionych uprawnień do danych. Aby uzyskać więcej informacji na temat udostępniania pulpitu nawigacyjnego, zobacz Udostępnianie pulpitu nawigacyjnego.

Aprowizowanie typu just in time (JIT) jest zawsze włączone po włączeniu automatycznego zarządzania tożsamościami i nie można go wyłączyć. Nowi użytkownicy są automatycznie aprowizowani w Azure Databricks podczas pierwszego logowania. Zobacz Automatyczne prowizjonowanie użytkowników (JIT).

Automatyczne zarządzanie tożsamościami nie jest obsługiwane w federacyjnych obszarach roboczych bez tożsamości. Aby uzyskać więcej informacji na temat federacji tożsamości, zobacz Federacja tożsamości.

Stan użytkownika, jednostki usługi i grupy

Po włączeniu automatycznego zarządzania tożsamościami użytkownicy, jednostki usługi i grupy z identyfikatora Entra firmy Microsoft są widoczne w konsoli konta i na stronie ustawień administratora obszaru roboczego. Ich stan odzwierciedla ich aktywność i stan między identyfikatorem Entra firmy Microsoft i usługą Azure Databricks:

Etykieta statusu Aktywne: usunięto z [IdP] zawiera nazwę dostawcy tożsamości. Na przykład Aktywne: usunięte z entraID.

Tożsamości zarządzane za pomocą automatycznego zarządzania tożsamościami są wyświetlane jako zewnętrzne w usłudze Azure Databricks. Nie można zaktualizować tożsamości zewnętrznych przy użyciu interfejsu użytkownika usługi Azure Databricks.

Udostępnianie i przypisywanie uprawnień

Po włączeniu automatycznego zarządzania tożsamościami można wybrać użytkowników i jednostki usługi z Microsoft Entra ID podczas udostępniania lub przypisywania uprawnień w Azure Databricks.

W przypadku grup zachowanie udostępniania różni się od typu zasobu:

• Zasoby na poziomie konta: grupy są dostępne podczas udostępniania lub nadawania uprawnień do zasobów na poziomie konta, takich jak Databricks Apps, obiekty Unity Catalog, panele AI/BI, agenci Genie i przypisywanie obszarów roboczych.
• Zasoby na poziomie obszaru roboczego: aby udostępniać zasoby na poziomie obszaru roboczego (takie jak notesy, zadania, magazyny SQL, alerty i pliki), administratorzy obszaru roboczego muszą najpierw dodać grupę do obszaru roboczego.

Automatyczne zarządzanie tożsamościami kontra udostępnianie SCIM

Po włączeniu automatycznego zarządzania tożsamościami wszyscy użytkownicy, grupy i przynależności do grup są synchronizowani od dostawcy tożsamości do usługi Azure Databricks, dzięki czemu aprowizacja SCIM nie jest konieczna. Jeśli aprowizacja SCIM będzie działać równolegle, program SCIM będzie nadal zarządzać tożsamościami dodanymi przy użyciu aprowizacji SCIM. Nie zarządza tożsamościami, które nie zostały dodane przy użyciu aprowizacji SCIM.

Aprowizowanie rozwiązania SCIM wymaga roli Administratora aplikacji w chmurze i oddzielnej aplikacji Microsoft Entra ID.

Azure Databricks zaleca korzystanie z automatycznego zarządzania tożsamościami. W poniższej tabeli porównaliśmy funkcje automatycznego zarządzania tożsamościami z funkcjami aprowizacji SCIM.

identyfikator zewnętrzny Azure Databricks i identyfikator obiektu Microsoft Entra ID

Usługa Azure Databricks używa identyfikatora Microsoft Entra ID ObjectId jako łącznika autorytatywnego do synchronizowania tożsamości i członkostwa w grupach, a następnie automatycznie aktualizuje pole externalId tak, aby było zgodne z ObjectId w dziennym cyklicznym przepływie. Databricks zaleca, aby nie mieszać metod aprowizacji. Dodanie tej samej tożsamości poprzez automatyczne zarządzanie tożsamościami i aprowizację SCIM powoduje zduplikowane wpisy i konflikty uprawnień. Użyj automatycznego zarządzania tożsamościami jako pojedyncze źródło prawdy, odzwierciedlając członkostwo w grupach Microsoft Entra ID.

Te zduplikowane tożsamości można scalić, podając identyfikator zewnętrzny w usłudze Azure Databricks. Użyj interfejsu API Account Users, Account Service Principals lub Account Groups, aby zaktualizować podmiot w celu dodania identyfikatora Microsoft Entra ID objectId w polu externalId. Aby znaleźć podmioty, które externalId nie odpowiadają Microsoft Entra ID, uruchom raport gotowości automatycznego zarządzania tożsamością.

Ponieważ externalId może aktualizować w czasie, Azure Databricks zdecydowanie zaleca, aby nie używać niestandardowych przepływów pracy, które zależą od pola externalId.

Jak automatyczne zarządzanie tożsamością dopasowuje tożsamości

Gdy automatyczne zarządzanie tożsamością synchronizuje tożsamość, dopasowuje ją do właściwego użytkownika, dostawcy usługi lub grupy w Twoim dostawcy tożsamości. Informacje, które Azure Databricks wykorzystuje do znalezienia dopasowania, zależą od sposobu wywołania synchronizacji.

Dopasowywanie podczas logowania

Gdy użytkownik loguje się przez single logon, Azure Databricks otrzymuje token od dostawcy tożsamości, odczytuje nazwę użytkownika z tokena i dopasowuje użytkownika logującego się do użytkownika konta Azure Databricks pod tą nazwą.

Token logowania Microsoft Entra ID zawiera również identyfikator obiektu użytkownika oraz identyfikator tenanta. Azure Databricks rejestruje identyfikator obiektu dla użytkownika konta jako jego externalId i używa go jako wiążącego odwołania, gdy synchronizacja jest oparta na identyfikatorze zewnętrznym, na przykład w interfejsie API tożsamości zewnętrznych lub podczas dodawania użytkownika z konsoli konta. Jednak podczas logowania to nazwa użytkownika w tokenie pozwala ustalić użytkownika.

Dopasowywanie według nazwy użytkownika

Niektóre przepływy identyfikują użytkownika za pomocą nazwy użytkownika Azure Databricks zamiast zewnętrznego ID, na przykład tworząc lub odświeżając kontekst uprawnień lub uwierzytelnianie osobistego tokena dostępu. Te przepływy nie zawierają tokenu Microsoft Entra ID lub zawierają token bez pełnych danych. Azure Databricks wyszukuje w usłudze Microsoft Entra ID użytkownika, którego główna nazwa użytkownika (UPN) lub adres e-mail jest równa nazwie użytkownika Azure Databricks, i preferuje dopasowanie na podstawie UPN zamiast dopasowania na podstawie adresu e-mail. Następnie aktualizuje dane użytkownika konta, przypisując mu zewnętrzne identyfikatory z dopasowanej tożsamości.

Na przykład jeśli użytkownik Azure Databricks ma nazwę użytkownika alice@contoso.com, Azure Databricks najpierw wyszukuje użytkownika Microsoft Entra ID o nazwie UPN alice@contoso.com. Jeśli nie znaleziono pasującego identyfikatora UPN, system szuka użytkownika, którego adres e-mail to alice@contoso.com.

Dopasowywanie podczas ustalania i tworzenia użytkowników

Gdy udostępniasz obiekt tożsamości Microsoft Entra ID, której nie ma jeszcze w Azure Databricks, lub gdy wywoływany jest interfejs API użytkownika zewnętrznego, Azure Databricks dopasowuje istniejącego użytkownika Azure Databricks na podstawie jego identyfikatora zewnętrznego. Jeśli nie zostanie dopasowany żaden użytkownik, Azure Databricks tworzy go just-in-time i ustawia nazwę użytkownika na podstawie sposobu, w jaki użytkownik jest zdefiniowany w Microsoft Entra ID:

• Użytkownicy utworzeni w Twojej dzierżawie: Azure Databricks używa nazwy UPN jako nazwy użytkownika. Na przykład użytkownik Microsoft Entra ID z identyfikatorem UPN bob@contoso.com staje się użytkownikiem Azure Databricks o nazwie użytkownika bob@contoso.com.
• Użytkownicy zaproszeni lub zsynchronizowani przez współpracę B2B (goście): Azure Databricks preferuje e-mail jako nazwę użytkownika i wraca do UPN, gdy obiekt gości nie ma adresu e-mail. Na przykład gość, którego identyfikator UPN to carol_fabrikam.com#EXT#@contoso.onmicrosoft.com, a adres e-mail to carol@fabrikam.com, staje się użytkownikiem usługi Azure Databricks o nazwie użytkownika carol@fabrikam.com.

Sprawy, których automatyczne zarządzanie tożsamością nie potrafi rozwiązać

Niektóre konfiguracje dostawcy tożsamości uniemożliwiają usłudze Azure Databricks niezawodne dopasowanie właściwego użytkownika. Skonfiguruj swoją tożsamość, aby uniknąć następujących przypadków.

Wielu użytkowników ma ten sam adres e-mail

Jeśli więcej niż jeden użytkownik Microsoft Entra ID ma e-mail odpowiadający nazwie użytkownika Azure Databricks, a żaden z nich nie ma pasującego UPN, Azure Databricks nie jest w stanie określić, którego użytkownika zamierzasz. Łączy jednego z nich bez gwarancji kolejności, więc może synchronizować niewłaściwego użytkownika, a synchronizacje mogą z czasem przełączać się między dopasowanymi użytkownikami.

Na przykład użytkownik usługi Azure Databricks ma nazwę użytkownika dana@contoso.com. W Microsoft Entra ID dwóch użytkowników posiada adres e-maildana@contoso.com: konto członkowskie, którego UPN to d.lee@fabrikam.com, oraz konto gościnne, którego UPN to dana_contoso.com#EXT#@fabrikam.onmicrosoft.com. Nazwa użytkownika pasuje do adresu e-mail obu użytkowników, ale nie pasuje do żadnego z UPN, więc Azure Databricks nie może ich odróżnić i dopasowuje jednego z nich dowolnie.

Aby uniknąć takiego przypadku, upewnij się, że UPN zamierzonego użytkownika Microsoft Entra ID jest równy nazwie użytkownika Azure Databricks i nie trzymaj wielu obiektów Microsoft Entra ID, które dzielą e-mail.

Nazwa użytkownika pochodzi od innego tenanta

Użytkownik gościnny może zalogować się przy użyciu tokenu zawierającego nazwę użytkownika z jego macierzystej dzierżawy, podczas gdy obiekt gościa w Twojej dzierżawie nie ma ani nazwy UPN, ani adresu e-mail równego tej nazwie użytkownika. Podczas logowania to nadal działa, ponieważ token nosi nazwę użytkownika domowego tenanta, a Azure Databricks dopasowuje użytkownika konta według niej. Przepływ, który dopasowuje użytkownika na podstawie nazwy użytkownika Azure Databricks, na przykład podczas odświeżania sesji, następnie wyszukuje w Microsoft Entra ID użytkownika, którego nazwa UPN lub adres e-mail jest równy tej nazwie użytkownika, i nie może znaleźć obiektu gościa do zsynchronizowania. Z kolei przepływ, który dopasowuje użytkownika na podstawie identyfikatora zewnętrznego, na przykład podczas rozpoznawania lub udostępniania za pośrednictwem interfejsu external identities API lub konsoli konta, może zamiast tego utworzyć drugiego użytkownika Azure Databricks, który współdzieli identyfikator zewnętrzny gościa, czego należy unikać.

Na przykład użytkownik Azure Databricks ma nazwę erin@fabrikam.comużytkownika , przeniesioną z jego domowego dzierżawcy. W Twoim tenantze obiekt gościa ma UPN erin_fabrikam.com#EXT#@contoso.onmicrosoft.com i nie ma pasującego e-maila. Podczas logowania nazwa użytkownika w tokenie jest równa erin@fabrikam.com, więc Azure Databricks dopasowuje użytkownika na podstawie nazwy użytkownika. Ale w przepływie bez tokenu Azure Databricks wyszukuje UPN lub adres e-mail równy erin@fabrikam.com, ale nie znajduje żadnego użytkownika.

Aby uniknąć tej sytuacji, upewnij się, że adres e-mail obiektu gościa jest taki sam jak nazwa użytkownika Azure Databricks oraz że ten adres e-mail jest unikalny w obrębie dzierżawy, aby nie powodował konfliktu z innym obiektem Microsoft Entra ID.

Jak działa synchronizacja członkostwa w grupie

Gdy włączone jest automatyczne zarządzanie tożsamościami, Azure Databricks odświeża informacje o członkostwie użytkowników w grupach na podstawie danych od dostawcy tożsamości podczas działań wywołujących kontrole uwierzytelniania i autoryzacji, na przykład logowania w przeglądarce, uwierzytelniania za pomocą tokenu lub uruchamiania zadań. Dzięki temu uprawnienia oparte na grupach w Azure Databricks pozostają zsynchronizowane ze zmianami wprowadzonych u dostawcy tożsamości.

Gdy Azure Databricks odświeża członkostwo w grupach, pobiera przejściowe (zagnieżdżone) członkostwa w grupach od dostawcy tożsamości. Oznacza to, że jeśli użytkownik jest członkiem grupy A, a grupa A jest członkiem grupy B, usługa Azure Databricks rozpoznaje użytkownika jako członka obu grup. Usługa Azure Databricks pobiera tylko członkostwa dla grup, które zostały dodane do usługi Azure Databricks. Nie synchronizuje ani nie rekonstruuje pełnej hierarchii grup nadrzędnych od dostawcy tożsamości.

Usługa Azure Databricks odświeża członkostwa w grupach według różnych harmonogramów w zależności od działania:

• Logowania w przeglądarce: Członkostwa w grupach są synchronizowane, jeśli od ostatniej synchronizacji minęło ponad 5 minut.
• Inne działania (na przykład uwierzytelnianie tokenów lub uruchamianie zadań): Azure Databricks odświeża członkostwa grupowe na podstawie tego, jak dawno nastąpiła ostatnia synchronizacja:
  • Mniej niż 10 minut: Nie następuje odświeżenie.
  • 10 do 40 minut: Azure Databricks uruchamia asynchroniczne odświeżanie w tle. Żądanie wywołujące odświeżenie może nadal korzystać z poprzednich członkostw w grupach. Odświeżone członkostwo dotyczy kolejnych wniosków.
  • Ponad 40 minut: Azure Databricks odświeża członkostwa grupowe przed zakończeniem żądania.

Zagnieżdżone grupy i jednostki usługi

Po włączeniu automatycznego zarządzania tożsamością członkowie zagnieżdżonych grup dziedziczą uprawnienia z przydzielonych grup. Uprawnienia przypisane do grupy nadrzędnej mają zastosowanie do wszystkich użytkowników i jednostek usługi należących do grupy, w tym tych dodanych bezpośrednio do grupy i tych, którzy należą do zagnieżdżonych członkostw w grupach. Jednak zagnieżdżone grupy i jednostki usługi w grupie nie są automatycznie przywoływane na koncie, z wyjątkiem udostępniania pulpitu nawigacyjnego.

Widoczność zagnieżdżonej grupy

Zagnieżdżone grupy są widoczne w usłudze Azure Databricks. Rozważ grupę podrzędną, Group-C która jest członkiem grupy nadrzędnej, Group-P. W przypadku dodania Group-P do obszaru roboczego wszystkie tożsamości w Group-P i Group-C mają dostęp do tego obszaru roboczego. W interfejsach użytkownika administratora konta i administratora obszaru roboczego, Group-C pojawia się jako członek na stronie szczegółów Group-P członków grupy. Na stronie szczegółów grupy pojawia się tylko pierwszy poziom zagnieżdżania.

Zagadnienia dotyczące grup zagnieżdżonych

• Dostęp do obszaru roboczego: grupy zagnieżdżone i jednostki usługi nie muszą być bezpośrednio dodawane do obszaru roboczego, aby uzyskać dostęp. Jeśli grupa nadrzędna zostanie dodana do obszaru roboczego, wszyscy członkowie tej grupy będą mogli uzyskać dostęp do obszaru roboczego.
• Zasoby na poziomie konta: grupy są dostępne podczas udostępniania lub nadawania uprawnień do zasobów na poziomie konta, takich jak Databricks Apps, obiekty Unity Catalog, panele AI/BI, agenci Genie i przypisywanie obszarów roboczych.
• Limity grup kont i głównych jednostek usługi: zagnieżdżone grupy i główne jednostki usługi, które nie są bezpośrednio przypisane dla konta, nie są uwzględniane w przypadku limitów grup kont. Tylko grupy, które są wyraźnie przydzielone do konta, wliczają się do limitów.

Na przykład w identyfikatorze Entra firmy Microsoft masz następującą strukturę grupy:

• Marketing-All (grupa nadrzędna)
  • Marketing-US (grupa podrzędna)
  • Marketing-EU (grupa podrzędna)
  • Marketing-APAC (grupa podrzędna)

Jeśli administrator obszaru roboczego dodaje Marketing-All do swojego obszaru roboczego:

• Udzielono dostępu: wszyscy członkowie Marketing-All i wszystkie jej grupy podrzędne (Marketing-US, Marketing-EU, Marketing-APAC) mogą uzyskiwać dostęp do obszaru roboczego. Na przykład użytkownicy i jednostki usługi w programie Marketing-APAC mogą uwierzytelniać się i używać obszaru roboczego.
• Aprowizowanie konta: tylko Marketing-All jest aprowizowane do konta Azure Databricks i uwzględnia limity grupy kont. Grupy podrzędne nie są wliczane do limitów, chyba że jawnie je aprowizujesz.
• Zasoby na poziomie konta: Marketing-All i wszystkie jego grupy podrzędne (Marketing-US, Marketing-EU, Marketing-APAC) są dostępne podczas udostępniania lub przypisywania uprawnień do zasobów na poziomie konta, takich jak pulpity nawigacyjne i obiekty w katalogu Unity.

Włączanie automatycznego zarządzania tożsamościami

Automatyczne zarządzanie tożsamościami jest domyślnie włączone dla kont utworzonych po 1 sierpnia 2025 r. Administratorzy kont mogą włączyć automatyczne zarządzanie tożsamościami w konsoli konta.

1. Jako administrator konta zaloguj się do konsoli konta.

2. Na pasku bocznym kliknij pozycję Zabezpieczenia.

3. W zakładce ustawień dostawcy tożsamości , w sekcji Zarządzanie tożsamością, należy przełączyć Automatyczne zarządzanie tożsamością na Włączone.

   Wprowadzenie zmian trwa od pięciu do dziesięciu minut.

Po aktywowaniu konta, aby dodawać i usuwać użytkowników, nazwy główne usług i grupy u dostawcy tożsamości, postępuj zgodnie z poniższymi instrukcjami:

• Dodawanie użytkowników do konta
• Dodawanie jednostek usługi do konta
• Dodawanie grup do konta

Aby przeprowadzić migrację z aprowizacji SCIM, zobacz Migrowanie do automatycznego zarządzania tożsamościami przy użyciu Microsoft Entra ID.

Wyłączanie automatycznego zarządzania tożsamościami

Gdy automatyczne zarządzanie tożsamościami jest wyłączone:

• Użytkownicy i jednostki usługi pozostają: zachowują dostęp, ale nie są już synchronizowani z dostawcą tożsamości. Po wyłączeniu automatycznego zarządzania tożsamościami można ręcznie usunąć lub dezaktywować użytkowników i jednostki usługi w konsoli konta.
• Grupy tracą członkostwo: grupy pozostają w usłudze Azure Databricks, ale wszyscy członkowie grupy zostaną usunięci.
• Brak synchronizacji z dostawcą tożsamości: zmiany w dostawcy tożsamości (takie jak usunięcia użytkowników lub aktualizacje grupy) nie są odzwierciedlane w Azure Databricks.
• Brak dziedziczenia uprawnień: Użytkownicy zarządzani przez automatyczne zarządzanie tożsamościami nie mogą dziedziczyć uprawnień z grup nadrzędnych. Dotyczy to zagnieżdżonych modeli uprawnień opartych na grupach.

Jeśli planujesz wyłączyć automatyczne zarządzanie tożsamościami, Databricks zaleca wcześniejsze skonfigurowanie aprowizacji SCIM jako zabezpieczenia. Program SCIM może następnie przejąć synchronizację tożsamości i grup.

1. Jako administrator konta zaloguj się do konsoli konta.
2. Na pasku bocznym kliknij pozycję Zabezpieczenia.
3. W zakładce ustawień dostawcy tożsamości , w sekcji Zarządzanie tożsamością, należy przełączyć Automatyczne zarządzanie tożsamością na Wyłączone.

Odmowa dostępu tożsamości do konta

Lista podmiotów zablokowanych w dostępie do konta określa, które tożsamości u dostawcy tożsamości mogą uzyskiwać dostęp do konta Azure Databricks. Administratorzy kont mogą dodawać określonych użytkowników, grup lub jednostek usługi do listy odmowy, aby zablokować dostęp. Przynależność do listy odmów ma charakter przechodni: jeśli dodasz grupę do listy odmów, odmowa obejmie również wszystkich jej członków, w tym członków grup zagnieżdżonych.

Instrukcje dotyczące konfiguracji i pełny opis działania listy blokowanych znajdziesz w artykule Odmów tożsamościom dostępu do swojego konta.

Kontroluj, które grupy są widoczne na Twoim koncie

Domyślnie każda grupa z Twojego dostawcy tożsamości jest widoczna w wyszukiwarce katalogów i selektorach grup Azure Databricks. Filtry widoczności grup pozwalają administratorom kont decydować, które grupy są widoczne, tak aby tylko te grupy, na które zezwolono, pojawiały się w wyszukiwarce i mogły być dodawane do polityk. Podczas gdy lista blokowanych blokuje dostęp, filtry widoczności grupowej kontrolują wykrywalność. Provisioning i logowanie pozostają bez zmian.

Aby uzyskać instrukcje konfiguracyjne i pełny opis zachowania filtrów, zobacz Kontroluj, które grupy są widoczne na Twoim koncie.

Audyt zdarzeń automatycznego zarządzania tożsamościami

Po włączeniu automatycznego zarządzania tożsamościami można używać dzienników inspekcji do śledzenia operacji tożsamości wykonywanych przez proces automatycznego zarządzania tożsamościami.

Tagi dziennika inspekcji dotyczące zdarzeń automatycznego zarządzania tożsamością

Automatyczne zarządzanie tożsamościami używa istniejących zdarzeń dziennika inspekcji, ale dodaje tagi do identyfikowania operacji wykonywanych automatycznie przez proces synchronizacji tożsamości:

• endpoint: "autoUserCreation" — wskazuje, że zdarzenie zostało wyemitowane z procesu automatycznego zarządzania tożsamościami. Ten tag pojawia się w operacjach użytkownika (add, activateUser, deactivateUser, updateUser), operacjach grupy (createGroup, updateGroup, removeGroup) oraz operacjach członkostwa w grupach (addPrincipalToGroup, removePrincipalFromGroup).
• groupMembershipType: "IdentityProvider" — pojawia się w operacjach członkostwa w grupach (addPrincipalToGroup, removePrincipalFromGroup), aby wskazać, że członkostwo w grupie zostało zsynchronizowane z dostawcą tożsamości.

Wykonywanie zapytań o zdarzenia inspekcji automatycznego zarządzania tożsamościami

Możesz wykonywać zapytania względem tabeli system.access.audit, aby śledzić automatyczne operacje zarządzania tożsamością. Przykład:

Śledzenie logowań użytkowników:

SELECT
  DISTINCT user_identity.email
FROM
  system.access.audit
WHERE
  action_name = "aadBrowserLogin"

Śledź użytkowników utworzonych przez automatyczne zarządzanie tożsamościami:

SELECT
  request_params.targetUserName,
  event_time
FROM
  system.access.audit
WHERE
  action_name = "add"
  AND request_params.endpoint = "autoUserCreation"

Śledzenie członkostwa w grupach zsynchronizowanych z dostawcą tożsamości:

SELECT
  request_params.targetGroupName,
  request_params.targetUserName,
  event_time
FROM
  system.access.audit
WHERE
  action_name IN ("addPrincipalToGroup", "removePrincipalFromGroup")
  AND request_params.groupMembershipType = "IdentityProvider"

Aby uzyskać więcej informacji na temat tabeli system.access.audit, zobacz odniesienie do tabeli systemu dzienników inspekcji .

Znane zachowania i ograniczenia

W tej sekcji opisano zachowania, które mogą nie być natychmiast oczywiste podczas pracy z automatycznym zarządzaniem tożsamościami.