Overzicht van id-providers voor Azure Stack Hub

Artikel
11/23/2024

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 deze implementeert in een verbonden modus, kunt u Microsoft Entra ID of AD FS gebruiken.
Wanneer u deze implementeert in een niet-verbonden modus, zonder 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:

Azure Stack Hub Development Kit: Identiteitsoverwegingen.
Geïntegreerde Azure Stack Hub-systemen: Beslissingen voor implementatieplanning voor geïntegreerde Azure Stack Hub-systemen.

Belangrijk

Azure AD Graph wordt afgeschaft en wordt buiten gebruik gesteld op 30 juni 2023. 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 heeft de mogelijkheid om meerdere organisaties in eigen directory's te ondersteunen. 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.

In Azure Stack Hub:

Worden gemaakt in de username@domain-indeling . Hoewel AD FS gebruikersaccounts toe wijst aan een Active Directory-exemplaar, biedt AD FS geen ondersteuning voor het gebruik van de indeling \<domain>\<alias> .
Kan worden ingesteld voor het gebruik van meervoudige verificatie.
Zijn beperkt tot de directory waar ze zich voor het eerst registreren. Dit is 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 zijn 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 aanmelden van het gebruikersaccount is admin@contoso.com, is de 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 directorytenants die toegang hebben gekregen tot resources in uw directory. Als u gastgebruikers wilt ondersteunen, gebruikt u Microsoft Entra ID en schakelt u ondersteuning in voor multitenancy. Wanneer ondersteuning is ingeschakeld, kunt u gastgebruikers uitnodigen voor toegang tot resources in uw adreslijsttenant, waardoor hun samenwerking met externe organisaties mogelijk is.

Om gastgebruikers, cloudoperators en gebruikers uit te nodigen, kunnen microsoft Entra B2B-samenwerking gebruiken. Uitgenodigde gebruikers krijgen toegang tot documenten, resources en apps uit 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 adreslijstnaam van die organisatie toe aan de portal-URL. Als u bijvoorbeeld deel uitmaakt van de Contoso-organisatie en u zich wilt aanmelden bij de directory fabrikam, 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 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: biedt alleen ondersteuning voor 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: biedt ondersteuning voor gebruik door gebruikers en services vanuit zowel de directory waarin 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 Multitenant-apps 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 in alle tenants. Deze relatie is een-op-een met de software-app en bestaat alleen in de map waarin de app voor het eerst is geregistreerd.
Service-principal-object: een referentie die wordt gemaakt voor een app in de map waarin de app voor het eerst wordt geregistreerd. Er wordt ook een service-principal gemaakt in de map van elke extra tenant waar 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. Met de service-principal wordt een identiteit vastgesteld 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 waar deze voor het eerst wordt gemaakt. Deze service-principal wordt gemaakt en toestemming gegeven voor 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 waarin een gebruiker van die tenant toestemming verleent voor het gebruik van de app.

Referenties voor service-principals kunnen een sleutel zijn die wordt gegenereerd via 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 gebruikt met Azure Stack Hub, kan alleen de beheerder service-principals maken. Met AD FS vereisen service-principals certificaten en worden gemaakt via het bevoegde eindpunt (PEP). Zie Een app-identiteit gebruiken voor toegang 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 met de id-provider. Net als bij apps kan een service worden geverifieerd 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 om on-premises of azure te verifiëren (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 directorytenant. Sommige services die worden geregistreerd, worden gebruikt voor beheer. Andere services zijn beschikbaar voor gebruikers. De standaardregistraties bieden kernservicesidentiteiten die met elkaar kunnen communiceren en met identiteiten die u later toevoegt.

Als u Microsoft Entra-id met meerdere tenants instelt, worden sommige apps doorgegeven aan de nieuwe directory's.

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 of wijziging van 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 te schatten dat de gebruiker of service-principal heeft in Azure Stack Hub.
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 in communicatie via een API. Voor elke aanroep die is 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 worden verzonden met Azure Stack Hub, gebruiken Windows-verificatie om deze communicatie te beveiligen.

Informatie die nodig is voor verificatie

Verifiëren bij Azure Resource Manager

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

URL voor het identiteitssysteem (instantie):de URL waarmee uw id-provider kan worden bereikt. Bijvoorbeeld: https://login.windows.net.
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.
Referenties: de referentie die u gebruikt voor verificatie bij de id-provider.
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 om toegang te krijgen 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 dat 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 de header van een aanvraag doorgeven aan Azure Resource Manager. Azure Resource Manager doet het volgende, in geen specifieke volgorde:

Valideert de verlener (iss) claim om te bevestigen dat het token afkomstig is van de juiste id-provider.
Valideert de claim van de doelgroep (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 bij Azure Resource Manager.
Controleer de uitgegeven claims op (iat) en vervaldatum (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 groepen claims om een lijst te maken met resources waartoe de principal toegang heeft.

Diagram van het tokenuitwisselingsprotocol

Op rollen gebaseerd toegangsbeheer gebruiken

Op rollen gebaseerd toegangsbeheer (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:

Aan de slag met op rollen gebaseerd toegangsbeheer in Azure Portal.
Gebruik op rollen gebaseerd toegangsbeheer om de toegang tot uw Azure-abonnementsbronnen te beheren.
Maak aangepaste rollen voor op rollen gebaseerd toegangsbeheer van Azure.
Op rollen gebaseerd toegangsbeheer beheren in 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 beoordelen 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, 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 use cases zijn al ingebouwd in uw Azure-omgeving om u te helpen aan de slag te gaan.

Notitie

Azure Policy wordt momenteel niet ondersteund in Azure Stack Hub.

Azure AD Graph

Microsoft Azure heeft de afschaffing van Azure AD Graph aangekondigd op 30 juni 2020 en de buitengebruikstellingsdatum van 30 juni 2023. Microsoft heeft klanten geïnformeerd via e-mail over deze wijziging. Zie het blog over afschaffing van Azure AD Graph-modules en 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 verder werken dan 30 juni 2023 om een soepele overgang te garanderen. De belangrijkste actie is 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 onboarding-gastmappen bijwerken.

Het merendeel van de migratie zelf wordt 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 toepassingsbeheerdersmachtigingen vereist in elke Microsoft Entra-directory die wordt gebruikt met uw Azure Stack Hub-omgevingen. Nadat het updatepakket met deze wijzigingen is geïnstalleerd, wordt er een waarschuwing weergegeven in de beheerportal waarmee u deze stap kunt 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 gebruikt als uw identiteitssysteem met Azure Stack Hub, hebben deze Graph-wijzigingen geen 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 van de update en communiceren we welk updatepakket vereist om de basismap en alle onboarded gastmappen bij te werken.

Delen via