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.

Dodaj grupę MS Entra ID z obszaru roboczego

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.

Uwaga / Notatka

Dzięki włączonej funkcji podglądu Listy Atrybutów Tożsamości, automatyczne zarządzanie tożsamością synchronizuje także stały zestaw atrybutów tożsamości, takich jak title, department, i costCenter, od dostawcy tożsamości do użytkowników konta Azure Databricks. Te atrybuty są w wersji beta. Więcej informacji można znaleźć w sekcji Atrybuty 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:

Status Meaning
Nieaktywne: brak użycia W przypadku użytkowników i jednostek usługi: tożsamość dostawcy tożsamości, który jeszcze nie zalogował się do Azure Databricks.
W przypadku grup: grupa nie została dodana do obszaru roboczego.
Aktywne Tożsamość jest aktywna w usłudze Azure Databricks.
Aktywne: usunięte z [IdP] Był wcześniej aktywny w Azure Databricks i został usunięty u dostawcy tożsamości. Usługa Azure Databricks automatycznie dezaktywuje tych użytkowników podczas następnej synchronizacji tożsamości. Nie można zalogować się ani uwierzytelnić w interfejsach API.
Dezaktywowany Tożsamość została dezaktywowana u dostawcy tożsamości lub została automatycznie dezaktywowana przez Azure Databricks po usunięciu jej u dostawcy tożsamości. Nie można zalogować się ani uwierzytelnić w interfejsach API.
Odmówiony Tożsamość została dodana do listy blokad dostępu do konta. Azure Databricks ustawia tożsamość jako nieaktywną. Nie można się zalogować, użyć osobistych tokenów dostępu lub wyświetlić się w oknach dialogowych udostępniania. Zobacz Odmowa dostępu tożsamości do konta.

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

Wskazówka

Zgodnie z najlepszymi praktykami w zakresie bezpieczeństwa Databricks zaleca unieważnienie tokenów dostępu osobistego dla użytkowników Dezaktywowanych i Aktywnych: usuniętych z [IdP]. Gdy użytkownicy zostaną usunięci z dostawcy tożsamości, Azure Databricks automatycznie dezaktywuje swoje konta, ale nie odwołuje automatycznie tokenów.

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.

Features Automatyczne zarządzanie tożsamościami Udostępnianie SCIM
Synchronizowanie użytkowników ✓ ✓
Grupy synchronizacji ✓ ✓
(Tylko bezpośredni członkowie)
Synchronizowanie zagnieżdżonych grup ✓
Synchronizuj obiekty usługowe ✓
Dostępne domyślnie w usłudze Azure Databricks ✓
Współpracuje ze wszystkimi wersjami Microsoft Entra ID ✓
Dostępne bez uprawnień administratora Microsoft Entra ID ✓
Wymaga federacji tożsamości ✓

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.

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 Twojego dostawcy tożsamości. Gdy token zawiera identyfikator obiektu użytkownika, usługa Azure Databricks dopasowuje na podstawie identyfikatora obiektu, który jest stabilnym, unikalnym identyfikatorem. To najbardziej trafne dopasowanie.

Token logowania Microsoft Entra ID zawiera identyfikator obiektu, identyfikator tenanta, członkostwa w grupach oraz nazwę użytkownika, dzięki czemu logowanie zgadza się z identyfikatorem obiektu.

Dopasowywanie według nazwy użytkownika

Niektóre przepływy nie obejmują tokenu logowania, na przykład tworzenie lub odświeżanie kontekstu uprawnień, uwierzytelnianie za pomocą osobistego tokenu dostępu, działania w konsoli konta oraz synchronizacja tożsamości w tle. W tych przepływach Azure Databricks dopasowuje na podstawie nazwy użytkownika Azure Databricks. Przeszukuje usługę Microsoft Entra ID w poszukiwaniu użytkownika, którego główna nazwa użytkownika (UPN) lub adres e-mail jest równa nazwie użytkownika w Azure Databricks, i nadaje priorytet dopasowaniu UPN względem dopasowania adresu e-mail.

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óra nie istnieje jeszcze w usłudze Azure Databricks, lub gdy wywoływany jest interfejs API Resolve User (resolveByExternalId), usługa Azure Databricks najpierw próbuje dopasować istniejącego użytkownika Azure Databricks na podstawie nazwy UPN lub adresu e-mail. 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ż dopasowywanie na podstawie tokenu identyfikuje użytkownika na podstawie identyfikatora obiektu, a nie nazwy użytkownika. Przepływy zamiast tego dopasowują się na podstawie nazwy użytkownika w Azure Databricks, bez użycia tokenu, więc nie mogą znaleźć obiektu gościa do zsynchronizowania, a rozpoznawanie lub udostępnianie może spowodować utworzenie użytkownika Azure Databricks z nieoczekiwaną nazwą użytkownika.

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. Logowanie oparte na tokenie identyfikuje tego użytkownika według identyfikatora obiektu, ale ponieważ ani nazwa UPN, ani adres e-mail nie jest równe erin@fabrikam.com, dopasowywanie na podstawie nazwy użytkownika nie znajduje żadnego użytkownika.

Aby uniknąć takiego przypadku, upewnij się, że adres e-mail obiektu gościa jest równy nazwie użytkownika Azure Databricks.

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. Na karcie Aprowizacja użytkowników przełącz opcję Automatyczne zarządzanie tożsamościami na włączone.

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

Włączono automatyczne zarządzanie tożsamościami na koncie.

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:

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. Na karcie Aprowizacja użytkowników przełącz opcję Automatyczne zarządzanie tożsamościami 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 jest przechodnia — jeśli dodasz grupę do listy odmów, odmową zostaną objęci również wszyscy jej członkowie, w tym członkowie 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.

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.

Tworzenie grup i przypisywanie przestrzeni roboczej

Gdy funkcja automatycznego zarządzania tożsamościami synchronizuje grupy z dostawcy tożsamości, są one automatycznie tworzone na poziomie konta. Te zdarzenia są wyświetlane w dziennikach inspekcji jako createGroup operacje oznaczone tagiem endpoint: "autoUserCreation". Tworzenie grup na poziomie konta jest automatyczne, ale przypisanie obszaru roboczego jest osobnym krokiem ręcznym. Członkowie zsynchronizowanej grupy uzyskują dostęp do obszaru roboczego dopiero po przypisaniu grupy do obszaru roboczego przez administratora konta. Automatyczne zarządzanie tożsamościami steruje członkostwem w grupie, a administrator kontroluje dostęp do obszaru roboczego.

Synchronizacja nazw grup nie jest proaktywna

Zmiana nazwy grupy u dostawcy tożsamości nie powoduje natychmiastowej aktualizacji nazwy grupy w Azure Databricks. Nazwa grupy jest synchronizowana tylko wtedy, gdy administrator konta otworzy stronę szczegółów grupy w konsoli konta. Do tego czasu grupa zachowuje swoją poprzednią nazwę w usłudze Azure Databricks.

Automatyczne zarządzanie tożsamością nie usuwa członkostw synchronizowanych przez SCIM

Automatyczne zarządzanie tożsamościami nie usuwa członkostwa w grupach, które zostały pierwotnie zsynchronizowane przy użyciu aprowizacji SCIM. Jest to zamierzone, aby uniknąć przerwania istniejących zadań i uprawnień, które zależą od tych członkostw. Aby usunąć nieaktualne członkostwa zsynchronizowane za pomocą interfejsu SCIM, użyj API SCIM , aby ręcznie je wyczyścić.

Aprowizowanie jednostki usługi przy pierwszym użyciu

Dodanie grupy zawierającej jednostki usługi do usługi Azure Databricks nie powoduje aprowizacji tych jednostek usługi. Usługa Azure Databricks aprowizuje jednostki usługi tylko w przypadku pierwszego użycia, takich jak uwierzytelnianie tokenu lub wykonywanie zadania. Dopóki główny element usługi nie uwierzytelnia się ani nie uruchamia zadania, nie jest wyświetlany w Azure Databricks.

Katalogi Entra ID między dzierżawcami nie są obsługiwane

Automatyczne zarządzanie tożsamościami nie obsługuje katalogów Microsoft Entra ID między dzierżawami. Jeśli potrzebujesz zarządzania tożsamościami między dzierżawami, skonfiguruj aprowizację SCIM za pomocą aplikacji Microsoft Entra B2B collaboration.

Zagnieżdżone grupy i jednostki usługi za pośrednictwem interfejsu API i Terraform

Zagnieżdżone grupy i jednostki usług, które nie są bezpośrednio aprowizowane na koncie usługi Azure Databricks, są widoczne w interfejsie użytkownika konsoli konta, ale nie można ich pobrać ani zarządzać za pomocą interfejsów API usługi Databricks ani narzędzia Terraform. Aby zarządzać nimi programowo, jawnie przypisać je do konta.

Uprawnienia są przenoszone podczas migracji ze SCIM do automatycznego zarządzania tożsamościami

Podczas migracji z aprowizacji rozwiązania SCIM do automatycznego zarządzania tożsamościami grupy pozostają tymi samymi wewnętrznymi obiektami usługi Azure Databricks. Uprawnienia katalogu Unity, przypisania obszaru roboczego i inne ustawienia są przenoszone automatycznie. Nie utracisz żadnych uprawnień podczas migracji.

  • Last updated on