Automatisch identiteitsbeheer

Met automatisch identiteitsbeheer kunt u naadloos gebruikers, service-principals en groepen uit Microsoft Entra ID toevoegen aan Azure Databricks. Wanneer automatisch identiteitsbeheer is ingeschakeld, kunt u rechtstreeks zoeken in gefedereerde identiteitswerkruimten voor gebruikers, service-principals en groepen en deze toevoegen aan uw werkruimte. Azure Databricks gebruikt Microsoft Entra ID als bron van record, zodat wijzigingen in groepslidmaatschappen in Azure Databricks worden gerespecteerd.

Automatisch identiteitsbeheer is standaard ingeschakeld voor accounts die zijn gemaakt na 1 augustus 2025.

Gebruikers kunnen ook dashboards delen met elke gebruiker, service-principal of groep in uw id-provider. Wanneer deze gebruikers, service-principals en leden van groepen worden gedeeld, worden ze automatisch toegevoegd aan het Azure Databricks-account bij aanmelding. Ze worden niet toegevoegd als leden aan de werkruimte waarin het dashboard zich bevindt. Gebruikers die geen toegang hebben tot de werkruimte, krijgen toegang tot een alleen-lezenkopie van een dashboard dat is gepubliceerd met machtigingen voor gedeelde gegevens. Zie Een dashboard delen voor meer informatie over het delen van dashboards.

Just-In-Time-inrichting (JIT) wordt altijd ingeschakeld wanneer automatisch identiteitsbeheer is ingeschakeld en u kunt het niet uitschakelen. Nieuwe gebruikers worden automatisch ingericht in Azure Databricks bij de eerste aanmelding. Zie Automatisch gebruikers inrichten (JIT).

Automatisch identiteitsbeheer wordt niet ondersteund in niet-identiteitsfedereerde werkruimten. Zie Identiteitsfederatie voor meer informatie over identiteitsfederatie.

Statussen van gebruikers, service-principals en groepen

Wanneer automatisch identiteitsbeheer is ingeschakeld, zijn gebruikers, service-principals en groepen van Microsoft Entra-id zichtbaar in de accountconsole en op de pagina met werkruimtebeheerdersinstellingen. Hun status weerspiegelt hun activiteit en status tussen Microsoft Entra ID en Azure Databricks:

Het statuslabel Actief: verwijderd uit [IdP] bevat de naam van uw id-provider. Bijvoorbeeld Actief: verwijderd uit EntraID.

Identiteiten die worden beheerd met behulp van automatisch identiteitsbeheer, worden weergegeven als Extern in Azure Databricks. Externe identiteiten kunnen niet worden bijgewerkt met behulp van de Gebruikersinterface van Azure Databricks.

Machtigingen delen en toewijzen

Wanneer automatisch identiteitsbeheer is ingeschakeld, kunt u gebruikers en service-principals selecteren uit Microsoft Entra ID wanneer u machtigingen deelt of toewijst in Azure Databricks.

Voor groepen verschilt het gedrag van delen per assettype:

• Assets op accountniveau: groepen zijn beschikbaar wanneer u machtigingen deelt of toewijst aan assets op accountniveau, zoals Databricks-apps, Unity Catalog-objecten, AI/BI-dashboards, Genie Agents en werkruimtetoewijzing.
• Assets op werkruimteniveau: Als u assets op werkruimteniveau wilt delen (zoals notebooks, taken, SQL-magazijnen, waarschuwingen en bestanden) met groepen, moeten werkruimtebeheerders de groep eerst rechtstreeks toevoegen aan de werkruimte.

Automatisch identiteitsbeheer versus SCIM-inrichting

Wanneer automatisch identiteitsbeheer is ingeschakeld, worden alle gebruikers, groepen en groepslidmaatschappen van uw id-provider gesynchroniseerd met Azure Databricks zodat SCIM-inrichting niet nodig is. Als u SCIM-inrichting parallel blijft uitvoeren, blijft SCIM identiteiten beheren die zijn toegevoegd met behulp van SCIM-inrichting. Er worden geen identiteiten beheerd die niet zijn toegevoegd met SCIM-inrichting.

SciM-inrichting vereist de rol Cloudtoepassingsbeheerder en een afzonderlijke Microsoft Entra ID-toepassing.

Azure Databricks raadt het gebruik van automatisch identiteitsbeheer aan. In de onderstaande tabel worden functies van automatisch identiteitsbeheer vergeleken met de functies van SCIM-inrichting.

Azure Databricks-externe ID en Microsoft Entra ID-object-id

Azure Databricks gebruikt de Microsoft Entra-id ObjectId als gezaghebbende koppeling voor het synchroniseren van identiteiten en groepslidmaatschappen en werkt het veld automatisch bij zodat het externalId overeenkomt met de ObjectId in een dagelijkse terugkerende stroom. Databricks raadt af om inrichtingsmethoden te combineren. Als u dezelfde identiteit toevoegt via zowel automatisch identiteitsbeheer als SCIM-inrichting, worden dubbele vermeldingen en machtigingsconflicten veroorzaakt. Gebruik automatisch identiteitsbeheer als de enige bron van waarheid, met groepslidmaatschappen die Microsoft Entra-id spiegelen.

U kunt deze dubbele identiteiten samenvoegen door hun externe id op te geven in Azure Databricks. Gebruik de API accountgebruikers, accountservice-principals of accountgroepen om de principal bij te werken om hun Microsoft Entra-id objectId toe te voegen in het externalId veld.

Omdat de externalId na verloop van tijd kan worden bijgewerkt, raadt Azure Databricks ten zeerste af om geen aangepaste werkstromen te gebruiken die afhankelijk zijn van het veld externalId.

Hoe geautomatiseerd identiteitsbeheer identiteiten koppelt

Wanneer automatisch identiteitsbeheer een identiteit synchroniseert, wordt die identiteit gekoppeld aan de juiste gebruiker, dienstprincipal of groep in uw identiteitsprovider. De informatie die Azure Databricks gebruikt om de match te vinden, hangt af van hoe de synchronisatie wordt geactiveerd.

Verificatie tijdens het inloggen

Wanneer een gebruiker inlogt via single sign-on, ontvangt Azure Databricks een token van je identiteitsprovider. Wanneer het token de object-ID van de gebruiker bevat, komt Azure Databricks overeen met de object-ID, die een stabiele, unieke identificatie is. Dit is de meest betrouwbare match.

Het Microsoft Entra ID-aanmeldtoken bevat de object-ID, tenant-ID, groepslidmaatschappen en gebruikersnaam, zodat de aanmelding overeenkomt met de object-ID.

Matchen op gebruikersnaam

Sommige flows bevatten geen inlogtoken, zoals het aanmaken of verversen van een machtigingscontext, authenticatie van persoonlijke toegangstokens, accountconsole-acties en achtergrondidentiteitssynchronisatie. In deze flows komt Azure Databricks overeen met de gebruikersnaam van Azure Databricks. Het zoekt in Microsoft Entra ID naar een gebruiker wiens gebruikersnaam (UPN) of e-mailadres gelijk is aan de gebruikersnaam van Azure Databricks, en geeft de voorkeur aan een UPN-match boven een e-mailmatch.

Als bijvoorbeeld een Azure Databricks-gebruiker de gebruikersnaam alice@contoso.comheeft, zoekt Azure Databricks eerst naar een Microsoft Entra ID-gebruiker met het UPN alice@contoso.com. Als geen UPN overeenkomt, zoekt het naar een gebruiker wiens e-mailadres .alice@contoso.com

Matchen bij het oplossen en aanmaken van gebruikers

Wanneer je een object deelt met een Microsoft Entra ID-identiteit die nog niet in Azure Databricks staat, of wanneer de Resolve User API (resolveByExternalId) wordt aangeroepen, probeert Azure Databricks eerst een bestaande Azure Databricks-gebruiker te matchen via UPN of e-mail. Als er geen overeenkomende gebruiker is, maakt Azure Databricks er just-in-time een aan en stelt het de gebruikersnaam in op basis van hoe de gebruiker in Microsoft Entra ID is opgenomen:

• Gebruikers die in jouw tenant zijn aangemaakt: Azure Databricks gebruikt het UPN als gebruikersnaam. Bijvoorbeeld, een Microsoft Entra ID-gebruiker met de UPN bob@contoso.com wordt een Azure Databricks-gebruiker met de gebruikersnaam bob@contoso.com.
• Gebruikers uitgenodigd of gesynchroniseerd via B2B-samenwerking (gasten): Azure Databricks geeft de voorkeur aan e-mail als gebruikersnaam en valt terug op de UPN wanneer het gastobject geen e-mail heeft. Bijvoorbeeld, een gast wiens UPN is carol_fabrikam.com#EXT#@contoso.onmicrosoft.com en wiens e-mail dat iscarol@fabrikam.com, wordt een Azure Databricks-gebruiker met de gebruikersnaam carol@fabrikam.com.

Zaken die automatisch identiteitsbeheer niet kan oplossen

Sommige configuraties van identiteitsproviders voorkomen dat Azure Databricks betrouwbaar aansluiten bij de beoogde gebruiker. Stel je identiteit in om de volgende gevallen te vermijden.

Meerdere gebruikers matchen hetzelfde e-mailadres

Als meer dan één Microsoft Entra ID-gebruiker een e-mailadres heeft dat gelijk is aan de gebruikersnaam van Azure Databricks, en geen van hen een overeenkomend UPN heeft, kan Azure Databricks niet bepalen welke gebruiker je bedoelt. Het matcht één van hen zonder gegarandeerde volgorde, dus het kan de verkeerde gebruiker synchroniseren, en synchronisaties kunnen na verloop van tijd wisselen tussen de gekoppelde gebruikers.

Bijvoorbeeld, een Azure Databricks-gebruiker heeft de gebruikersnaam dana@contoso.com. In Microsoft Entra ID hebben twee gebruikers het e-mailadresdana@contoso.com: een lidaccount met UPN , d.lee@fabrikam.comen een gastaccount met UPN dana_contoso.com#EXT#@fabrikam.onmicrosoft.com. De gebruikersnaam komt overeen met het e-mailadres van beide gebruikers, maar komt niet overeen met een van beide UPN, dus Azure Databricks kan ze niet uit elkaar houden en komt willekeurig overeen met één van hen.

Om dit geval te voorkomen, zorg ervoor dat het UPN van de bedoelde Microsoft Entra ID-gebruiker overeenkomt met de gebruikersnaam van Azure Databricks, en bewaar niet meerdere Microsoft Entra ID-objecten die een e-mail delen.

De gebruikersnaam komt van een andere tenant

Een gastgebruiker kan inloggen met een token dat een gebruikersnaam van hun thuistenant draagt, terwijl het gastobject in jouw tenant noch een UPN noch een e-mailadres heeft dat gelijk is aan die gebruikersnaam. Bij het inloggen werkt dit nog steeds, omdat token-gebaseerde matching de gebruiker oplost op basis van de object-ID in plaats van de gebruikersnaam. Flows zonder token komen in plaats daarvan overeen met de Azure Databricks-gebruikersnaam, waardoor ze het gastobject niet kunnen vinden om te synchroniseren, en het omzetten of delen kan een Azure Databricks-gebruiker met een onverwachte gebruikersnaam aanmaken.

Bijvoorbeeld, een Azure Databricks-gebruiker heeft de gebruikersnaam erin@fabrikam.com, afkomstig van de thuistenant van de gebruiker. In je tenant heeft het gastobject het UPN erin_fabrikam.com#EXT#@contoso.onmicrosoft.com en geen bijpassende e-mail. Een token-gebaseerde aanmelding lost deze gebruiker op via object-ID, maar omdat noch het UPN noch het e-mailadres gelijk zijn erin@fabrikam.com, vindt gebruikersnaam-gebaseerde matching geen gebruiker.

Om dit geval te voorkomen, zorg ervoor dat het e-mailadres van het gastobject gelijk is aan de gebruikersnaam van Azure Databricks.

Hoe synchronisatie van groepslidmaatschap werkt

Wanneer automatisch identiteitsbeheer is ingeschakeld, vernieuwt Azure Databricks lidmaatschappen van gebruikersgroepen van uw id-provider tijdens activiteiten die verificatie en autorisatiecontroles activeren, bijvoorbeeld browseraanmelding, tokenverificatie of taakuitvoeringen. Dit zorgt ervoor dat machtigingen op basis van groepen in Azure Databricks gesynchroniseerd blijven met wijzigingen die zijn aangebracht in uw id-provider.

Wanneer Azure Databricks groepslidmaatschappen vernieuwt, worden transitieve (geneste) groepslidmaatschappen van uw id-provider opgehaald. Dit betekent dat als een gebruiker lid is van Groep A en Groep A lid is van Groep B, Azure Databricks de gebruiker herkent als lid van beide groepen. Azure Databricks haalt alleen lidmaatschappen op voor groepen die zijn toegevoegd aan Azure Databricks. De volledige bovenliggende groepshiërarchie van uw id-provider wordt niet gesynchroniseerd of gereconstrueerd.

Azure Databricks vernieuwt groepslidmaatschappen volgens verschillende planningen, afhankelijk van de activiteit:

• Browserlogins: Groepslidmaatschappen synchroniseren als er meer dan 5 minuten zijn verstreken sinds de laatste synchronisatie.
• Andere activiteiten (bijvoorbeeld tokenauthenticatie of het uitvoeren van taken): Azure Databricks verfrist groepslidmaatschappen op basis van hoe lang geleden de laatste synchronisatie heeft plaatsgevonden:
  • Minder dan 10 minuten: Er vindt geen verversing plaats.
  • 10 tot 40 minuten: Azure Databricks activeert een asynchrone verversing op de achtergrond. Het verzoek dat de verversing activeert, kan nog steeds de vorige groepslidmaatschappen gebruiken. De vernieuwde lidmaatschappen zijn van toepassing op volgende aanvragen.
  • Meer dan 40 minuten: Azure Databricks verst groepslidmaatschappen voordat het verzoek wordt afgerond.

Geneste groepen en serviceprincipals

Wanneer automatisch identiteitsbeheer is ingeschakeld, nemen leden van geneste groepen machtigingen over van ingerichte groepen. Machtigingen die zijn toegewezen aan een bovenliggende groep, zijn van toepassing op alle gebruikers en service-principals die deel uitmaken van de groep, inclusief degenen die rechtstreeks aan de groep zijn toegevoegd en degenen die deel uitmaken via geneste groepslidmaatschappen. Geneste groepen en service-principals in een groep kunnen echter niet automatisch worden gerefereerd in het account, behalve voor het delen van dashboards.

Zichtbaarheid van geneste groepen

Geneste groepen zijn zichtbaar in Azure Databricks. Overweeg een onderliggende groep, Group-C, die lid is van een bovenliggende groep, Group-P. Als u toevoegt Group-P aan een werkruimte, hebben alle identiteiten in beide Group-P en Group-C toegang tot de werkruimte. In de gebruikersinterfaces van de accountbeheerder en werkruimtebeheerder verschijnt Group-C als lid binnen Group-P op de detailpagina van groepsleden. Alleen het eerste nestniveau wordt weergegeven op de pagina met groepsdetails.

Overwegingen voor geneste groepen

• Toegang tot werkruimte: Geneste groepen en service-principals hoeven niet direct aan een werkruimte toegevoegd te worden om toegang te verkrijgen. Als een oudergroep wordt toegevoegd aan een werkruimte, hebben alle leden van die groep toegang tot de werkruimte.
• Assets op accountniveau: groepen zijn beschikbaar wanneer u machtigingen deelt of toewijst aan assets op accountniveau, zoals Databricks-apps, Unity Catalog-objecten, AI/BI-dashboards, Genie Agents en werkruimtetoewijzing.
• Limieten voor accountgroepen en service-principals: Geneste groepen en service-principals die niet rechtstreeks zijn ingericht voor het account, tellen niet mee voor limieten voor accountgroepen. Alleen groepen die expliciet zijn ingericht voor het account, tellen mee voor de limieten.

In Microsoft Entra-id hebt u bijvoorbeeld de volgende groepsstructuur:

• Marketing-All (bovenliggende groep)
  • Marketing-US (subgroep)
  • Marketing-EU (subgroep)
  • Marketing-APAC (subgroep)

Als een werkruimtebeheerder toevoegt Marketing-All aan de werkruimte:

• Toegang verleend: alle leden van Marketing-All en alle onderliggende groepen (Marketing-US, Marketing-EU, Marketing-APAC) hebben toegang tot de werkruimte. Gebruikers en service-principals in Marketing-APAC kunnen bijvoorbeeld de werkruimte verifiëren en gebruiken.
• Accountinrichting: Alleen Marketing-All wordt ingericht voor het Azure Databricks-account en telt mee voor limieten voor accountgroepen. De onderliggende groepen tellen niet mee voor limieten, tenzij u ze expliciet inricht.
• Assets op accountniveau: Marketing-All en alle onderliggende groepen (Marketing-US, Marketing-EU, Marketing-APAC) zijn beschikbaar wanneer u machtigingen deelt of toewijst aan assets op accountniveau, zoals dashboards en objecten in Unity Catalog.

Automatisch identiteitsbeheer inschakelen

Automatisch identiteitsbeheer is standaard ingeschakeld voor accounts die zijn gemaakt na 1 augustus 2025. Accountbeheerders kunnen automatisch identiteitsbeheer inschakelen in de accountconsole.

1. Meld u als accountbeheerder aan bij de accountconsole.

2. Klik in de zijbalk op Beveiliging.

3. Schakel op het tabblad Gebruikersinrichtingautomatisch identiteitsbeheer in op Ingeschakeld.

   Het duurt vijf tot tien minuten voordat wijzigingen van kracht worden.

Nadat uw account is ingeschakeld, volgt u de onderstaande instructies om gebruikers, service-principals en groepen toe te voegen en te verwijderen uit uw id-provider:

• Gebruikers toevoegen aan uw account
• Service-principals toevoegen aan uw account
• Groepen toevoegen aan uw account

Zie Migreren naar automatisch identiteitsbeheer met Microsoft Entra ID als u wilt migreren van SCIM-inrichting.

Automatisch identiteitsbeheer uitschakelen

Wanneer automatisch identiteitsbeheer is uitgeschakeld:

• Gebruikers en service-principals blijven behouden: ze behouden de toegang, maar worden niet meer gesynchroniseerd met uw id-provider. U kunt gebruikers en service-principals handmatig verwijderen of deactiveren in de accountconsole nadat u automatisch identiteitsbeheer hebt uitgeschakeld.
• Groepen verliezen lidmaatschap: Groepen blijven aanwezig in Azure Databricks, maar alle groepsleden worden verwijderd.
• Geen synchronisatie met de id-provider: wijzigingen in uw id-provider (zoals verwijderingen van gebruikers of groepsupdates) worden niet doorgevoerd in Azure Databricks.
• Geen overname van machtigingen: gebruikers die worden beheerd door automatisch identiteitsbeheer kunnen geen machtigingen overnemen van bovenliggende groepen. Dit is van invloed op geneste autorisatiemodellen op basis van groepen.

Als u van plan bent het automatische identiteitsbeheer uit te schakelen, raadt Databricks aan om SCIM-provisioning vooraf in te stellen als een back-up. SCIM kan vervolgens identiteits- en groepssynchronisatie overnemen.

1. Meld u als accountbeheerder aan bij de accountconsole.
2. Klik in de zijbalk op Beveiliging.
3. Schakel op het tabblad Gebruikersinrichtingautomatisch identiteitsbeheer in op Uitgeschakeld.

Identiteiten toegang tot uw account weigeren

De blokkeringslijst voor accounttoegang bepaalt welke identiteiten van uw identiteitsprovider toegang hebben tot uw Azure Databricks-account. Accountbeheerders kunnen specifieke gebruikers, groepen of service-principals toevoegen aan de denylist om hun toegang te blokkeren. Denylist-lidmaatschap is transitief. Als u een groep weigert, worden alle leden, inclusief leden in geneste groepen, ook geweigerd.

Zie Identiteiten toegang tot uw account weigeren voor configuratie-instructies en een volledige beschrijving van het gedrag van de denylist.

Gebeurtenissen voor automatisch identiteitsbeheer controleren

Wanneer automatisch identiteitsbeheer is ingeschakeld, kunt u auditlogboeken gebruiken om identiteitsbewerkingen bij te houden die worden uitgevoerd door het automatische identiteitsbeheerproces.

Auditlogboektags voor automatische identiteitsbeheergebeurtenissen

Automatisch identiteitsbeheer maakt gebruik van bestaande controlelogboekgebeurtenissen, maar voegt tags toe om bewerkingen te identificeren die automatisch worden uitgevoerd door het identiteitssynchronisatieproces:

• eindpunt: 'autoUserCreation': geeft aan dat de gebeurtenis is verzonden vanuit het proces voor automatisch identiteitsbeheer. Deze tag wordt weergegeven bij gebruikersbewerkingen (add, activateUser, deactivateUser, updateUser), groepsbewerkingen (createGroup, updateGroup, removeGroup), en groepslidmaatschapsbewerkingen (addPrincipalToGroup, removePrincipalFromGroup).
• groupMembershipType: "IdentityProvider" - Wordt weergegeven bij bewerkingen voor groepslidmaatschap (addPrincipalToGroup, removePrincipalFromGroup) om aan te geven dat het groepslidmaatschap is gesynchroniseerd van uw id-provider.

Controlegebeurtenissen voor automatisch identiteitsbeheer opvragen

U kunt een query uitvoeren op de system.access.audit tabel om automatische bewerkingen voor identiteitsbeheer bij te houden. Voorbeeld:

Gebruikersaanmelding bijhouden:

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

Gebruikers bijhouden die via automatisch identiteitsbeheer zijn aangemaakt:

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

Groepslidmaatschappen bijhouden die zijn gesynchroniseerd vanaf uw id-provider:

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

Zie voor meer informatie over de tabel de referentie naar de systeemtabel Auditlogboek .

Bekend gedrag en beperkingen

In deze sectie worden de gedragingen beschreven die mogelijk niet direct duidelijk zijn bij het werken met automatisch identiteitsbeheer.