Arkitektur for datagateway i det lokale miljø

  • Artikel
  • 4 minutter til læsning

Brugere i organisationen kan få adgang til data i det lokale miljø, som de allerede har adgangstilladelse til. Men før de pågældende brugere kan oprette forbindelse til den lokale datakilde, skal en gateway til det lokale miljø være installeret og konfigureret.

Gatewayen muliggør hurtigere og og mere sikker kommunikation bag kulissen. Denne kommunikation flyder fra en bruger i skyen til datakilden i det lokale miljø og derefter tilbage til skyen.

En administrator er som regel den, der installerer og konfigurerer en gateway. Disse handlinger kræver måske særlig viden om serverne i det lokale miljø eller tilladelser for serveradministratorer.

Denne artikel er ikke en trinvis vejledning i, hvordan du installerer og konfigurerer gatewayen. Denne vejledning finder du i Installere en datagateway i det lokale miljø. Denne artikel giver en nærmere forståelse af, hvordan gatewayen fungerer.

Sådan fungerer gatewayen

Relation mellem cloudtjenester, gateway og datakilder.

Lad os begynde med at se på, hvad der sker, når du interagerer med et element, der har forbindelse til en datakilde i det lokale miljø.

Bemærk

Afhængigt af cloudtjenesten skal du muligvis konfigurere en datakilde for gatewayen.

  1. Cloudtjenesten opretter en forespørgsel og de krypterede legitimationsoplysninger for datakilden i det lokale miljø. Forespørgslen og legitimationsoplysningerne sendes til gatewaykøen til behandling. Du kan finde flere oplysninger om kryptering af legitimationsoplysninger i Power BI ved at gå til Power BI-sikkerhedswhitepaper.
  2. Cloudtjenesten for gatewayen analyserer forespørgslen og sender anmodningen til Azure Service Bus-beskeder.
  3. Azure Service Bus sender de ventende anmodninger til gatewayen. Både gatewayen og Power BI-tjenesten er implementeret til kun at acceptere TLS 1.2-trafik.
  4. Gatewayen modtager forespørgslen, dekrypterer legitimationsoplysningerne og opretter forbindelse til en eller flere datakilder med disse legitimationsoplysninger.
  5. Gatewayen sender forespørgslen til datakilden for at blive kørt.
  6. Resultaterne sendes fra datakilden og tilbage til gatewayen og derefter til cloudtjenesten. Derefter kan tjenesten bruge resultaterne.

I trin 6 kan forespørgsler som Power BI-opdateringer og Azure Analysis Services-opdateringer returnere store mængder data. I forbindelse med sådanne forespørgsler lagres data midlertidigt på gatewaycomputeren. Denne datalagring fortsætter, indtil alle data er modtaget fra datakilden. Dataene sendes derefter tilbage til cloudtjenesten. Denne proces kaldes spooling. Vi anbefaler, at du bruger et SSD-drev (Solid State Drive) som spooling-lager.

Godkendelse til datakilder i det lokale miljø

Et gemt sæt legitimationsoplysninger bruges til at oprette forbindelse fra gatewayen til datakilder i det lokale miljø. Uafhængigt af brugeren anvender gatewayen anvender de gemte legitimationsoplysninger til at oprette forbindelse. Men der kan være godkendelsesundtagelser såsom DirectQuery og LiveConnect for Analysis Services i Power BI. Du kan finde flere oplysninger om kryptering af legitimationsoplysninger i Power BI ved at gå til Power BI-sikkerhedswhitepaper.

Logonkonto

Du kan logge på med en arbejdskonto eller en skolekonto. Denne konto er din organisationskonto. Hvis du har tilmeldt dig et tilbud på Office 365 og ikke har angivet din nuværende arbejdsmailadresse, kan kontonavnet se ud som nancy@contoso.onmicrosoft.com. En cloudtjeneste gemmer din konto i en lejer i Azure Active Directory (Azure AD). I de fleste tilfælde stemmer UPN-kontoen (User Principal Name) for din Azure AD-konto overens med mailadressen.

Azure Active Directory

Microsoft Cloud Services bruger Azure AD til at godkende brugere. Azure AD er den lejer, der indeholder brugernavne og sikkerhedsgrupper. Typisk er den mailadresse, som du bruger til logon, den samme som kontoens UPN. Du kan finde flere oplysninger om godkendelse i Power BI ved at gå til Power BI-sikkerhedswhitepaper.

Hvordan kan jeg se, hvad mit UPN er?

Du kender muligvis ikke dit UPN, og du er muligvis ikke domæneadministrator. Hvis du vil se UPN for din konto, skal du køre følgende kommando fra din arbejdsstation:whoami /upn.

Selvom resultatet ligner en mailadresse, er det dit UPN for din lokale domænekonto.

Synkronisere et Active Directory i det lokale miljø med Azure Active Directory

Du ønsker, at de enkelte Active Directory-konti i det lokale miljø skal stemme overens med en Azure AD-konto, da UPN for disse konti skal være det samme.

Cloudtjenesterne kender kun til konti i Azure AD. Det har ingen betydning, hvis du har tilføjet en konto i dit Active Directory i det lokale miljø. Hvis kontoen ikke findes i Azure AD, kan den ikke bruges.

Du kan sammenligne Active Directory-konti i det lokale miljø med Azure AD på flere måder.

  • Føje konti manuelt til Azure AD.

    Opret en konto på Azure-portalen eller i Microsoft 365 Administration. Kontroller, at kontonavnet stemmer overens med UPN for Active Directory-kontoen i det lokale miljø.

  • Brug værktøjet Azure Active Directory Connect til at synkronisere lokale konti med din Azure AD-lejer.

    Værktøjet Azure AD Connect indeholder funktioner til opsætning af katalogsynkronisering og godkendelse. Disse indstillinger omfatter synkronisering af adgangskode-hash, videregivelse til godkendelse og samling. Hvis du ikke er administrator af lejeren eller det lokal domæne, skal du kontakte it-administratoren for at få hjælp til konfigurationen af Azure AD Connect.

Azure AD Connect sikrer, at dit Azure AD UPN stemmer overens med UPN for dit lokale Active Directory. Denne sammenligning gør det lettere, hvis du bruger Analysis Services-liveforbindelser sammen med Power BI eller funktioner til enkeltlogon (SSO).

Bemærk

Når konti synkroniseres med værktøjet Azure AD Connect, oprettes der nye konti i din Azure AD-lejer.

Næste trin