Overzicht van id-providers voor Azure Stack Hub

  • Artikel

Azure Stack Hub vereist Microsoft Entra id of Active Directory Federation Services (AD FS), ondersteund door Active Directory als id-provider. De keuze van een provider is een eenmalige beslissing die u neemt wanneer u Azure Stack Hub voor het eerst implementeert. De concepten en autorisatiedetails in dit artikel kunnen u helpen bij het kiezen tussen id-providers.

Uw keuze voor Microsoft Entra-id of AD FS wordt bepaald door de modus waarin u Azure Stack Hub implementeert:

  • Wanneer u het in een verbonden modus implementeert, kunt u Microsoft Entra-id of AD FS gebruiken.
  • Wanneer u het implementeert in een niet-verbonden modus, zonder een verbinding met internet, wordt alleen AD FS ondersteund.

Zie de volgende artikelen voor meer informatie over uw opties, die afhankelijk zijn van uw Azure Stack Hub-omgeving:

Belangrijk

Azure AD Graph wordt afgeschaft en wordt op 30 juni 2023 buiten gebruik gesteld. Zie deze sectie voor meer informatie.

Algemene concepten voor id-providers

In de volgende secties worden algemene concepten besproken over id-providers en het gebruik ervan in Azure Stack Hub.

Terminologie voor id-providers

Directory-tenants en -organisaties

Een map is een container met informatie over gebruikers, toepassingen, groepen en service-principals.

Een directorytenant is een organisatie, zoals Microsoft of uw eigen bedrijf.

  • Microsoft Entra id ondersteunt meerdere tenants en kan meerdere organisaties ondersteunen, elk in een eigen directory. Als u Microsoft Entra-id gebruikt en meerdere tenants hebt, kunt u apps en gebruikers van de ene tenant toegang verlenen tot andere tenants van dezelfde directory.
  • AD FS ondersteunt slechts één tenant en dus slechts één organisatie.

Gebruikers en groepen

Gebruikersaccounts (identiteiten) zijn standaardaccounts die personen verifiëren met behulp van een gebruikers-id en wachtwoord. Groepen kunnen gebruikers of andere groepen bevatten.

Hoe u gebruikers en groepen maakt en beheert, is afhankelijk van de identiteitsoplossing die u gebruikt.

Gebruikersaccounts in Azure Stack Hub:

  • Worden gemaakt in de username@domain-indeling . Hoewel AD FS gebruikersaccounts aan een Active Directory-exemplaar toe wijst, biedt AD FS geen ondersteuning voor het gebruik van de indeling \<domein>\<alias> .
  • Kan worden ingesteld voor het gebruik van meervoudige verificatie.
  • Zijn beperkt tot de map waar ze zich het eerst registreren, de adreslijst van hun organisatie.
  • Kan worden geïmporteerd uit uw on-premises mappen. Zie Uw on-premises mappen integreren met Microsoft Entra-id voor meer informatie.

Wanneer u zich aanmeldt bij de gebruikersportal van uw organisatie, gebruikt u de https://portal.local.azurestack.external URL. Wanneer u zich aanmeldt bij de Azure Stack Hub-portal vanuit andere domeinen dan de domeinen die worden gebruikt om Azure Stack Hub te registreren, moet de domeinnaam die wordt gebruikt om Azure Stack Hub te registreren, worden toegevoegd aan de portal-URL. Als Azure Stack Hub bijvoorbeeld is geregistreerd bij fabrikam.onmicrosoft.com en het gebruikersaccount dat zich aanmeldt, is admin@contoso.comde URL die moet worden gebruikt om u aan te melden bij de gebruikersportal: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Gastgebruikers

Gastgebruikers zijn gebruikersaccounts van andere directory-tenants die toegang hebben gekregen tot resources in uw directory. Als u gastgebruikers wilt ondersteunen, gebruikt u Microsoft Entra-id en schakelt u ondersteuning voor meerdere tenants in. Wanneer ondersteuning is ingeschakeld, kunt u gastgebruikers uitnodigen voor toegang tot resources in uw directorytenant, waardoor hun samenwerking met externe organisaties mogelijk is.

Als u gastgebruikers wilt uitnodigen, kunnen cloudoperators en gebruikers Microsoft Entra B2B-samenwerking gebruiken. Uitgenodigde gebruikers krijgen toegang tot documenten, resources en apps vanuit uw directory en u behoudt de controle over uw eigen resources en gegevens.

Als gastgebruiker kunt u zich aanmelden bij de directorytenant van een andere organisatie. Hiervoor voegt u de mapnaam van die organisatie toe aan de portal-URL. Als u bijvoorbeeld deel uitmaakt van de contoso-organisatie en u zich wilt aanmelden bij de Fabrikam-directory, gebruikt u https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Apps

U kunt apps registreren bij Microsoft Entra-id of AD FS en de apps vervolgens aanbieden aan gebruikers in uw organisatie.

Apps zijn onder andere:

  • Web-apps: voorbeelden zijn de Azure Portal en Azure Resource Manager. Ze ondersteunen web-API-aanroepen.
  • Systeemeigen client: voorbeelden zijn Azure PowerShell, Visual Studio en Azure CLI.

Apps kunnen twee soorten tenancy ondersteunen:

  • Eén tenant: ondersteunt alleen gebruikers en services uit dezelfde map waarin de app is geregistreerd.

    Notitie

    Omdat AD FS slechts één map ondersteunt, zijn apps die u in een AD FS-topologie maakt, standaard apps met één tenant.

  • Meerdere tenants: ondersteunt het gebruik door gebruikers en services van zowel de map waar de app is geregistreerd als aanvullende tenantmappen. Met apps met meerdere tenants kunnen gebruikers van een andere tenantmap (een andere Microsoft Entra tenant) zich aanmelden bij uw app.

    Zie Multitenancy inschakelen voor meer informatie over multitenancy.

    Zie Apps met meerdere tenants voor meer informatie over het ontwikkelen van een app met meerdere tenants.

Wanneer u een app registreert, maakt u twee objecten:

  • Toepassingsobject: de globale weergave van de app voor alle tenants. Deze relatie is een-op-een met de software-app en bestaat alleen in de map waar de app voor het eerst is geregistreerd.

  • Service-principalobject: een referentie die wordt gemaakt voor een app in de map waarin de app voor het eerst is geregistreerd. Er wordt ook een service-principal gemaakt in de map van elke extra tenant waarin die app wordt gebruikt. Deze relatie kan een-op-veel zijn met de software-app.

Zie Toepassings- en service-principalobjecten in Microsoft Entra-id voor meer informatie over app- en service-principalobjecten.

Service-principals

Een service-principal is een set referenties voor een app of service die toegang verleent tot resources in Azure Stack Hub. Het gebruik van een service-principal scheidt de app-machtigingen van de machtigingen van de gebruiker van de app.

Er wordt een service-principal gemaakt in elke tenant waarin de app wordt gebruikt. De service-principal stelt een identiteit vast voor aanmelding en toegang tot resources (zoals gebruikers) die door die tenant worden beveiligd.

  • Een app met één tenant heeft slechts één service-principal, die zich in de map bevindt waarin deze voor het eerst wordt gemaakt. Deze service-principal wordt gemaakt en stemt in met het gebruik tijdens de registratie van de app.
  • Een web-app of API met meerdere tenants heeft een service-principal die wordt gemaakt in elke tenant waarbij een gebruiker van die tenant toestemming krijgt voor het gebruik van de app.

Referenties voor service-principals kunnen een sleutel zijn die wordt gegenereerd via de Azure Portal of een certificaat. Het gebruik van een certificaat is geschikt voor automatisering omdat certificaten als veiliger worden beschouwd dan sleutels.

Notitie

Wanneer u AD FS met Azure Stack Hub gebruikt, kan alleen de beheerder service-principals maken. Met AD FS zijn voor service-principals certificaten vereist en worden deze gemaakt via het bevoegde eindpunt (PEP). Zie Een app-identiteit gebruiken om toegang te krijgen tot resources voor meer informatie.

Zie Service-principals maken voor meer informatie over service-principals voor Azure Stack Hub.

Services

Services in Azure Stack Hub die communiceren met de id-provider, worden geregistreerd als apps bij de id-provider. Net als bij apps stelt registratie een service in staat om zich te verifiëren met het identiteitssysteem.

Alle Azure-services maken gebruik van OpenID Connect-protocollen en JSON-webtokens om hun identiteit vast te stellen. Omdat Microsoft Entra-id en AD FS consistent protocollen gebruiken, kunt u de Microsoft Authentication Library (MSAL) gebruiken om een beveiligingstoken te verkrijgen voor verificatie on-premises of bij Azure (in een verbonden scenario). Met MSAL kunt u ook hulpprogramma's zoals Azure PowerShell en Azure CLI gebruiken voor cloud- en on-premises resourcebeheer.

Identiteiten en uw identiteitssysteem

Identiteiten voor Azure Stack Hub omvatten gebruikersaccounts, groepen en service-principals.

Wanneer u Azure Stack Hub installeert, worden verschillende ingebouwde apps en services automatisch geregistreerd bij uw id-provider in de maptenant. Sommige services die worden geregistreerd, worden gebruikt voor beheer. Andere services zijn beschikbaar voor gebruikers. De standaardregistraties bieden kernservice-identiteiten die zowel met elkaar kunnen communiceren als met identiteiten die u later toevoegt.

Als u Microsoft Entra-id instelt met multitenancy, worden sommige apps doorgegeven aan de nieuwe mappen.

Verificatie en autorisatie

Verificatie door apps en gebruikers

Identiteit tussen lagen van Azure Stack Hub

Voor apps en gebruikers wordt de architectuur van Azure Stack Hub beschreven door vier lagen. Interacties tussen elk van deze lagen kunnen verschillende typen verificatie gebruiken.

Laag Verificatie tussen lagen
Hulpprogramma's en clients, zoals de beheerdersportal Voor toegang tot een resource in Azure Stack Hub gebruiken hulpprogramma's en clients een JSON-webtoken om een aanroep naar Azure Resource Manager te plaatsen.
Azure Resource Manager valideert het JSON-webtoken en bekijkt de claims in het uitgegeven token om het autorisatieniveau van de gebruiker of service-principal in Azure Stack Hub te schatten.
Azure Resource Manager en de belangrijkste services Azure Resource Manager communiceert met resourceproviders om communicatie van gebruikers over te dragen.
Overdrachten maken gebruik van directe imperatieve aanroepen of declaratieve aanroepen via Azure Resource Manager-sjablonen.
Resourceproviders Aanroepen die worden doorgegeven aan resourceproviders, worden beveiligd met verificatie op basis van certificaten.
Azure Resource Manager en de resourceprovider blijven vervolgens communiceren via een API. Voor elke aanroep die wordt ontvangen van Azure Resource Manager, valideert de resourceprovider de aanroep met dat certificaat.
Infrastructuur en bedrijfslogica Resourceproviders communiceren met bedrijfslogica en infrastructuur met behulp van een verificatiemodus van hun keuze. De standaardresourceproviders die met Azure Stack Hub worden geleverd, gebruiken Windows-verificatie om deze communicatie te beveiligen.

Informatie die nodig is voor verificatie

Verifiëren bij Azure Resource Manager

Als u zich wilt verifiëren bij de id-provider en een JSON-webtoken wilt ontvangen, moet u over de volgende informatie beschikken:

  1. URL voor het identiteitssysteem (instantie): de URL waarop uw id-provider bereikbaar is. Bijvoorbeeld https://login.windows.net.
  2. App-id-URI voor Azure Resource Manager: de unieke id voor Azure Resource Manager die is geregistreerd bij uw id-provider. Het is ook uniek voor elke Azure Stack Hub-installatie.
  3. Referenties: de referentie die u gebruikt om te verifiëren bij de id-provider.
  4. URL voor Azure Resource Manager: de URL is de locatie van de Azure Resource Manager-service. Bijvoorbeeld https://management.azure.com of https://management.local.azurestack.external.

Wanneer een principal (een client, apps of gebruiker) een verificatieaanvraag indient voor toegang tot een resource, moet de aanvraag het volgende omvatten:

  • De referenties van de principal.
  • De app-id-URI van de resource waartoe de principal toegang wil hebben.

De referenties worden gevalideerd door de id-provider. De id-provider valideert ook dat de app-id-URI voor een geregistreerde app is en of de principal de juiste bevoegdheden heeft om een token voor die resource te verkrijgen. Als de aanvraag geldig is, wordt een JSON-webtoken verleend.

Het token moet vervolgens in de header van een aanvraag worden doorgegeven aan Azure Resource Manager. Azure Resource Manager doet het volgende, in geen specifieke volgorde:

  • Valideert de claim van de verlener (iss) om te bevestigen dat het token afkomstig is van de juiste id-provider.
  • Valideert de doelgroepclaim (aud) om te bevestigen dat het token is uitgegeven aan Azure Resource Manager.
  • Valideert of het JSON-webtoken is ondertekend met een certificaat dat is geconfigureerd via OpenID en bekend is bij Azure Resource Manager.
  • Controleer de uitgegeven op (iat) en vervaldatumclaims (exp) om te bevestigen dat het token actief is en kan worden geaccepteerd.

Wanneer alle validaties zijn voltooid, gebruikt Azure Resource Manager de object-id (oid) en de groepsclaims om een lijst met resources te maken waartoe de principal toegang heeft.

Diagram van het tokenuitwisselingsprotocol

Notitie

Na de implementatie is Microsoft Entra globale beheerdersmachtiging niet vereist. Voor sommige bewerkingen zijn echter mogelijk de referenties van de globale beheerder vereist (bijvoorbeeld een installatiescript voor een resourceprovider of een nieuwe functie waarvoor een machtiging moet worden verleend). U kunt de globale beheerdersmachtigingen van het account tijdelijk opnieuw instellen of een afzonderlijk globaal beheerdersaccount gebruiken dat eigenaar is van het standaardproviderabonnement.

Gebruik Role-Based Access Control

Role-Based Access Control (RBAC) in Azure Stack Hub is consistent met de implementatie in Microsoft Azure. U kunt de toegang tot resources beheren door de juiste RBAC-rol toe te wijzen aan gebruikers, groepen en apps. Zie de volgende artikelen voor informatie over het gebruik van RBAC met Azure Stack Hub:

Verifiëren met Azure PowerShell

Meer informatie over het gebruik van Azure PowerShell voor verificatie met Azure Stack Hub vindt u in De PowerShell-omgeving van de Azure Stack Hub-gebruiker configureren.

Verifiëren met Azure CLI

Zie Azure CLI installeren en configureren voor gebruik met Azure Stack Hub voor informatie over het gebruik van Azure PowerShell voor verificatie met Azure Stack Hub.

Azure Policy

Azure Policy helpt bij het afdwingen van organisatiestandaarden en het evalueren van naleving op schaal. Via het nalevingsdashboard biedt het een geaggregeerde weergave om de algehele status van de omgeving te evalueren, met de mogelijkheid om in te zoomen op granulariteit per resource en per beleid. Hiermee kunt u ook zorgen voor compliance van uw resources via bulkherstel voor bestaande resources en automatisch herstel voor nieuwe resources.

Veelvoorkomende use-cases voor Azure Policy zijn onder andere het implementeren van governance voor consistentie van resources, naleving van de regelgeving, beveiliging, kosten en beheer. Beleidsdefinities voor deze veelvoorkomende gebruiksvoorbeelden zijn al ingebouwd in uw Azure-omgeving om u op weg te helpen.

Notitie

Azure Policy wordt momenteel niet ondersteund in Azure Stack Hub.

Azure AD Graph

Microsoft Azure heeft aangekondigd dat Azure AD Graph op 30 juni 2020 wordt afgeschaft en op 30 juni 2023 buiten gebruik wordt gesteld. Microsoft heeft klanten via e-mail geïnformeerd over deze wijziging. Zie de blog over het buiten gebruik stellen van Azure AD Graph en de afschaffing van Powershell-modules voor meer informatie.

In de volgende sectie wordt beschreven hoe deze afschaffing van invloed is op Azure Stack Hub.

Het Azure Stack Hub-team werkt nauw samen met het Azure Graph-team om ervoor te zorgen dat uw systemen na 30 juni 2023 blijven werken, indien nodig, om een soepele overgang te garanderen. De belangrijkste actie is om ervoor te zorgen dat u voldoet aan het servicebeleid van Azure Stack Hub. Klanten ontvangen een waarschuwing in de beheerdersportal van Azure Stack Hub en moeten de basismap en alle onboarded gastmappen bijwerken.

Het grootste deel van de migratie zelf zal worden uitgevoerd door de geïntegreerde systeemupdate-ervaring; er is een handmatige stap vereist voor klanten om nieuwe machtigingen te verlenen aan deze toepassingen. Hiervoor zijn globale beheerdersmachtigingen vereist in elke Microsoft Entra directory die wordt gebruikt met uw Azure Stack Hub-omgevingen. Nadat de installatie van het updatepakket met deze wijzigingen is voltooid, wordt er een waarschuwing weergegeven in de beheerportal met de opdracht om deze stap te voltooien met behulp van de gebruikersinterface voor meerdere tenants of PowerShell-scripts. Dit is dezelfde bewerking die u uitvoert bij het onboarden van extra directory's of resourceproviders. Zie Multitenancy configureren in Azure Stack Hub voor meer informatie.

Als u AD FS als uw identiteitssysteem gebruikt met Azure Stack Hub, hebben deze Graph-wijzigingen niet rechtstreeks invloed op uw systeem. De nieuwste versies van hulpprogramma's, zoals Azure CLI, Azure PowerShell, enzovoort, vereisen echter de nieuwe Graph API's en ze werken niet. Zorg ervoor dat u alleen de versies van deze hulpprogramma's gebruikt die expliciet worden ondersteund met uw opgegeven Azure Stack Hub-build.

Naast de waarschuwing in de beheerportal communiceren we wijzigingen via de releaseopmerkingen bij de update en communiceren we voor welk updatepakket de basismap en alle onboarded gastmappen moeten worden bijgewerkt.

Volgende stappen