Azure Stack Hub için kimlik sağlayıcılarına genel bakışOverview of identity providers for Azure Stack Hub

Azure Stack hub, bir kimlik sağlayıcısı olarak Active Directory tarafından desteklenen Azure Active Directory (Azure AD) veya Active Directory Federasyon Hizmetleri (AD FS) (AD FS) gerektirir.Azure Stack Hub requires Azure Active Directory (Azure AD) or Active Directory Federation Services (AD FS), backed by Active Directory as an identity provider. Sağlayıcı seçimi, Azure Stack hub 'ını ilk dağıtırken yaptığınız tek seferlik bir karardır.The choice of a provider is a one-time decision that you make when you first deploy Azure Stack Hub. Bu makaledeki kavramlar ve yetkilendirme ayrıntıları, kimlik sağlayıcıları arasında seçim yapmanıza yardımcı olabilir.The concepts and authorization details in this article can help you choose between identity providers.

Azure AD veya AD FS seçiminiz Azure Stack hub 'ı dağıttığınız moda göre belirlenir:Your choice of either Azure AD or AD FS is determined by the mode in which you deploy Azure Stack Hub:

  • Bunu bağlı bir modda dağıttığınızda Azure AD 'yi veya AD FS kullanabilirsiniz.When you deploy it in a connected mode, you can use either Azure AD or AD FS.
  • Bunu, internet bağlantısı olmadan bağlantısı kesik modda dağıtırken yalnızca AD FS desteklenir.When you deploy it in a disconnected mode, without a connection to the internet, only AD FS is supported.

Azure Stack hub ortamınıza bağlı olan seçenekleriniz hakkında daha fazla bilgi için aşağıdaki makalelere bakın:For more information about your options, which depend on your Azure Stack Hub environment, see the following articles:

Kimlik sağlayıcıları için ortak kavramlarCommon concepts for identity providers

Sonraki bölümlerde kimlik sağlayıcıları ve Azure Stack hub 'daki kullanımları hakkında genel kavramlar ele alınmaktadır.The next sections discuss common concepts about identity providers and their use in Azure Stack Hub.

Kimlik sağlayıcıları için terminoloji

Dizin kiracılar ve kuruluşlarDirectory tenants and organizations

Dizin, Kullanıcılar, uygulamalar, gruplarve hizmet sorumlularıhakkında bilgi tutan bir kapsayıcıdır.A directory is a container that holds information about users, applications, groups, and service principals.

Dizin kiracısı, Microsoft veya kendi şirketiniz gibi bir kuruluştur.A directory tenant is an organization, such as Microsoft or your own company.

  • Azure AD birden çok kiracıyı destekler ve her biri kendi dizininde yer alan birden çok kuruluşu destekleyebilir.Azure AD supports multiple tenants, and it can support multiple organizations, each in its own directory. Azure AD kullanırsanız ve birden çok kiracıya sahipseniz, tek bir kiracının aynı dizindeki diğer kiracılara erişmesini ve kullanıcılara izin verebilirsiniz.If you use Azure AD and have multiple tenants, you can grant apps and users from one tenant access to other tenants of that same directory.
  • AD FS yalnızca tek bir kiracıyı ve bu nedenle yalnızca tek bir kuruluşu destekler.AD FS supports only a single tenant and, therefore, only a single organization.

Kullanıcılar ve gruplarUsers and groups

Kullanıcı hesapları (kimlikler), bir kullanıcı KIMLIĞI ve parola kullanarak kişilerin kimliğini doğrulayan standart hesaplardır.User accounts (identities) are standard accounts that authenticate individuals by using a user ID and password. Gruplar, kullanıcıları veya diğer grupları içerebilir.Groups can include users or other groups.

Kullanıcıları ve grupları oluşturma ve yönetme, kullandığınız kimlik çözümüne bağlıdır.How you create and manage users and groups depends on the identity solution you use.

Azure Stack hub 'ında Kullanıcı hesapları:In Azure Stack Hub, user accounts:

  • , Kullanıcı adı @ etki alanı biçiminde oluşturulur.Are created in the username@domain format. AD FS, Kullanıcı hesaplarını Active Directory bir örneğe eşler, ancak AD FS biçimin kullanımını desteklemez \<domain>\<alias> .Although AD FS maps user accounts to an Active Directory instance, AD FS doesn't support the use of the \<domain>\<alias> format.
  • Multi-Factor Authentication kullanmak üzere ayarlanabilir.Can be set up to use multi-factor authentication.
  • , Kuruluşun dizini olan, ilk kaydoldukları dizinle kısıtlıdır.Are restricted to the directory where they first register, which is their organization's directory.
  • , Şirket içi dizininizden içeri aktarılabilir.Can be imported from your on-premises directories. Daha fazla bilgi için bkz. Şirket içi dizinlerinizi Azure Active Directory tümleştirme.For more information, see Integrate your on-premises directories with Azure Active Directory.

Kuruluşunuzun Kullanıcı portalında oturum açtığınızda, https: / /Portal.Local.azurestack.external URL 'sini kullanırsınız.When you sign in to your organization's user portal, you use the https://portal.local.azurestack.external URL. Azure Stack hub 'ı kaydettirmek için kullanılandan farklı etki alanlarından Azure Stack hub portalında oturum açarken, Azure Stack hub 'ı kaydettirmek için kullanılan etki alanı adının Portal URL 'sine eklenmesi gerekir.When signing into the Azure Stack Hub portal from domains other than the one used to register Azure Stack Hub, the domain name used to register Azure Stack Hub must be appended to the portal url. Örneğin, Azure Stack hub, fabrikam.onmicrosoft.com ile kaydedilmişse ve Kullanıcı hesabı oturum açma işlemi ise, admin@contoso.com Kullanıcı portalında oturum açmak için kullanılacak URL şöyle olacaktır: https: / /Portal.Local.azurestack.external/fabrikam.onmicrosoft.com.For example, if Azure Stack Hub has been registered with fabrikam.onmicrosoft.com and the user account logging in is admin@contoso.com, the URL to use to log into the user portal would be: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Konuk kullanıcılarGuest users

Konuk kullanıcılar, diğer dizin kiracılarından, dizininizdeki kaynaklara erişim izni verilen kullanıcı hesaplarıdır.Guest users are user accounts from other directory tenants that have been granted access to resources in your directory. Konuk kullanıcıları desteklemek için Azure AD 'yi kullanır ve çok kiracılı desteği etkinleştirebilirsiniz.To support guest users, you use Azure AD and enable support for multi-tenancy. Destek etkinleştirildiğinde, Konuk kullanıcıları Dizin kiracınızdaki kaynaklara erişmek için davet edebilirsiniz; bu da, dışarıdaki kuruluşların işbirliği yapmasına olanak sağlar.When support is enabled, you can invite guest users to access resources in your directory tenant, which in turn enables their collaboration with outside organizations.

Konuk kullanıcıları davet etmek için, bulut İşletmenleri ve kullanıcılar Azure AD B2B işbirliğinikullanabilir.To invite guest users, cloud operators and users can use Azure AD B2B collaboration. Davet edilen kullanıcılar, dizininizdeki belgelere, kaynaklara ve uygulamalara erişim sağlar ve kendi kaynaklarınız ve verileriniz üzerinde denetim sahibi olursunuz.Invited users get access to documents, resources, and apps from your directory, and you maintain control over your own resources and data.

Konuk Kullanıcı olarak, başka bir kuruluşun Dizin kiracısında oturum açabilirsiniz.As a guest user, you can sign in to another organization's directory tenant. Bunu yapmak için, söz konusu kuruluşun dizin adını Portal URL 'sine ekleyin.To do so, you append that organization's directory name to the portal URL. Örneğin, contoso kuruluşuna aitseniz ve Fabrikam dizininde oturum açmak istiyorsanız https:/Portal.Local.azurestack.external/fabrikam.onmicrosoft.com. kullanın. /For example, if you belong to the Contoso organization and want to sign in to the Fabrikam directory, you use https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

UygulamalarApps

Uygulamaları Azure AD 'ye veya AD FS kaydedebilir ve sonra uygulamaları kuruluşunuzdaki kullanıcılara sunabilirsiniz.You can register apps to Azure AD or AD FS, and then offer the apps to users in your organization.

Uygulamalar şunlardır:Apps include:

  • Web Apps: örnek Azure portal ve Azure Resource Manager içerir.Web apps: Examples include the Azure portal and Azure Resource Manager. Web API çağrılarını destekler.They support Web API calls.
  • Yerel istemci: Örnekler Azure PowerShell, Visual Studio ve Azure CLI içerir.Native client: Examples include Azure PowerShell, Visual Studio, and Azure CLI.

Uygulamalar iki tür kiracı destekleyebilir:Apps can support two types of tenancy:

  • Tek kiracılı: yalnızca uygulamanın kaydedildiği dizindeki kullanıcıları ve hizmetleri destekler.Single-tenant: Supports users and services only from the same directory where the app is registered.

    Not

    AD FS yalnızca tek bir dizini desteklediğinden, bir AD FS topolojide oluşturduğunuz uygulamalar tasarım, tek kiracılı uygulamalar ile yapılır.Because AD FS supports only a single directory, apps you create in an AD FS topology are, by design, single-tenant apps.

  • Çok kiracılı: uygulamanın kaydedildiği ve ek kiracı dizinlerinin her ikisi de kullanıcıların ve hizmetlerin kullanımını destekler.Multi-tenant: Supports use by users and services from both the directory where the app is registered and additional tenant directories. Çok kiracılı uygulamalarla, başka bir kiracı dizininin kullanıcıları (başka bir Azure AD kiracısı) uygulamanızda oturum açabilir.With multi-tenant apps, users of another tenant directory (another Azure AD tenant) can sign in to your app.

    Çoklu kiracı hakkında daha fazla bilgi için bkz. Çoklu kirayı etkinleştirme.For more information about multi-tenancy, see Enable multi-tenancy.

    Çok kiracılı bir uygulama geliştirme hakkında daha fazla bilgi için bkz. çok kiracılı uygulamalar.For more information about developing a multi-tenant app, see Multi-tenant apps.

Bir uygulamayı kaydettiğinizde iki nesne oluşturursunuz:When you register an app, you create two objects:

  • Uygulama nesnesi: tüm kiracılar genelinde uygulamanın genel temsili.Application object: The global representation of the app across all tenants. Bu ilişki, yazılım uygulamasıyla bire bir ve yalnızca uygulamanın ilk kaydedildiği dizinde bulunur.This relationship is one-to-one with the software app and exists only in the directory where the app is first registered.

  • Hizmet sorumlusu nesnesi: uygulamanın ilk kaydedildiği dizindeki bir uygulama için oluşturulan kimlik bilgileri.Service principal object: A credential that's created for an app in the directory where the app is first registered. Bir hizmet sorumlusu, uygulamanın kullanıldığı her Ek kiracının dizininde de oluşturulur.A service principal is also created in the directory of each additional tenant where that app is used. Bu ilişki, yazılım uygulaması ile bire çok olabilir.This relationship can be one-to-many with the software app.

Uygulama ve hizmet sorumlusu nesneleri hakkında daha fazla bilgi edinmek için Azure Active Directory Içindeki uygulama ve hizmet sorumlusu nesneleribölümüne bakın.To learn more about app and service principal objects, see Application and service principal objects in Azure Active Directory.

Hizmet sorumlularıService principals

Hizmet sorumlusu, Azure Stack hub 'daki kaynaklara erişim izni veren bir uygulama veya hizmet için bir kimlik bilgileri kümesidir.A service principal is a set of credentials for an app or service that grant access to resources in Azure Stack Hub. Hizmet sorumlusu kullanımı, uygulama izinlerini uygulamanın kullanıcısının izinleriyle ayırır.The use of a service principal separates the app permissions from the permissions of the user of the app.

Uygulamanın kullanıldığı her kiracıda bir hizmet sorumlusu oluşturulur.A service principal is created in each tenant where the app is used. Hizmet sorumlusu, oturum açma için bir kimlik ve bu kiracı tarafından güvenliği sağlanmış kaynaklara (kullanıcılar gibi) erişim sağlar.The service principal establishes an identity for sign-in and access to resources (such as users) that are secured by that tenant.

  • Tek kiracılı bir uygulamanın, ilk oluşturulduğu dizinde olan yalnızca bir hizmet sorumlusu vardır.A single-tenant app has only one service principal, which is in the directory where it's first created. Bu hizmet sorumlusu, uygulamanın kaydı sırasında kullanılmak üzere oluşturulur ve kullanılır.This service principal is created and consents to being used during registration of the app.
  • Çok kiracılı bir Web uygulamasının veya API 'sinin, bu kiracıdan gelen bir kullanıcının uygulama kullanımıyla ilgili olduğu her bir kiracıda oluşturulmuş bir hizmet sorumlusu vardır.A multi-tenant web app or API has a service principal that's created in each tenant where a user from that tenant consents to the use of the app.

Hizmet sorumluları için kimlik bilgileri, Azure portal veya sertifikayla oluşturulmuş bir anahtar olabilir.Credentials for service principals can be either a key that's generated through the Azure portal or a certificate. Sertifikalar anahtarlara göre daha güvenli olarak kabul edildiğinden, bir sertifika kullanımı otomasyon için uygundur.The use of a certificate is suited for automation because certificates are considered more secure than keys.

Not

Azure Stack hub ile AD FS kullandığınızda yalnızca yönetici hizmet sorumluları oluşturabilir.When you use AD FS with Azure Stack Hub, only the administrator can create service principals. AD FS, hizmet sorumluları sertifika gerektirir ve ayrıcalıklı uç nokta (PEP) üzerinden oluşturulur.With AD FS, service principals require certificates and are created through the privileged endpoint (PEP). Daha fazla bilgi için bkz. kaynaklara erişmek için uygulama kimliği kullanma.For more information, see Use an app identity to access resources.

Azure Stack Hub için hizmet sorumluları hakkında bilgi edinmek için bkz. hizmet sorumluları oluşturma.To learn about service principals for Azure Stack Hub, see Create service principals.

HizmetlerServices

Kimlik sağlayıcısıyla etkileşime geçen Azure Stack hub 'daki hizmetler, kimlik sağlayıcısı ile uygulama olarak kaydedilir.Services in Azure Stack Hub that interact with the identity provider are registered as apps with the identity provider. Uygulamalar gibi, kayıt, bir hizmetin kimlik sistemiyle kimlik doğrulamasını sağlar.Like apps, registration enables a service to authenticate with the identity system.

Tüm Azure Hizmetleri, kimliğini oluşturmak için OpenID Connect protokollerini ve JSON Web belirteçlerini kullanır.All Azure services use OpenID Connect protocols and JSON Web Tokens to establish their identity. Azure AD ve AD FS protokolleri sürekli olarak kullandığından, şirket içinde veya Azure 'da (bağlı bir senaryoda) kimlik doğrulaması yapmak için Azure Active Directory kimlik doğrulama kitaplığı 'nı (ADAL) kullanabilirsiniz.Because Azure AD and AD FS use protocols consistently, you can use Azure Active Directory Authentication Library (ADAL) to authenticate on-premises or to Azure (in a connected scenario). ADAL ile, platformlar arası ve şirket içi kaynak yönetimi için Azure PowerShell ve Azure CLı gibi araçları da kullanabilirsiniz.With ADAL, you can also use tools such as Azure PowerShell and Azure CLI for cross-cloud and on-premises resource management.

Kimlikler ve kimlik sisteminizIdentities and your identity system

Azure Stack Hub için kimlikler Kullanıcı hesaplarını, grupları ve hizmet sorumlularını içerir.Identities for Azure Stack Hub include user accounts, groups, and service principals.

Azure Stack hub 'ı yüklediğinizde, çeşitli yerleşik uygulamalar ve hizmetler otomatik olarak dizin kiracısında kimlik sağlayıcınızla kayıt kaydeder.When you install Azure Stack Hub, several built-in apps and services automatically register with your identity provider in the directory tenant. Kayıt yapan bazı hizmetler yönetim için kullanılır.Some services that register are used for administration. Kullanıcılar için diğer hizmetler kullanılabilir.Other services are available for users. Varsayılan kayıtlar, hem birbirleriyle hem de daha sonra eklediğiniz kimliklerle etkileşime girebilen çekirdek hizmet kimliklerini sağlar.The default registrations give core services identities that can interact both with each other and with identities that you add later.

Azure AD 'yi çok kiracılı bir şekilde ayarlarsanız, bazı uygulamalar yeni dizinlere yayılır.If you set up Azure AD with multi-tenancy, some apps propagate to the new directories.

Kimlik doğrulaması ve yetkilendirmeAuthentication and authorization

Uygulamalar ve kullanıcılar tarafından kimlik doğrulamasıAuthentication by apps and users

Azure Stack Hub katmanları arasındaki kimlik

Uygulamalar ve kullanıcılar için Azure Stack hub 'ın mimarisi dört katmanda açıklanmıştır.For apps and users, the architecture of Azure Stack Hub is described by four layers. Bu katmanların her biri arasındaki etkileşimler farklı kimlik doğrulama türlerini kullanabilir.Interactions between each of these layers can use different types of authentication.

KatmanLayer Katmanlar arasında kimlik doğrulamasıAuthentication between layers
Yönetici portalı gibi araçlar ve istemcilerTools and clients, such as the administrator portal Azure Stack hub 'daki bir kaynağa erişmek veya bu kaynağı değiştirmek için, Araçlar ve istemciler Azure Resource Manager çağrısı koymak için bir JSON Web Token kullanır.To access or modify a resource in Azure Stack Hub, tools and clients use a JSON Web Token to place a call to Azure Resource Manager.
Azure Resource Manager, JSON Web Token doğrular ve Kullanıcı veya hizmet sorumlusu Azure Stack hub 'ında yetkilendirme düzeyini tahmin etmek için verilen belirteçteki taleplere bakar.Azure Resource Manager validates the JSON Web Token and peeks at the claims in the issued token to estimate the level of authorization that user or service principal has in Azure Stack Hub.
Azure Resource Manager ve Çekirdek HizmetleriAzure Resource Manager and its core services Azure Resource Manager, kullanıcılardan iletişim aktarmaya yönelik kaynak sağlayıcılarla iletişim kurar.Azure Resource Manager communicates with resource providers to transfer communication from users.
Aktarımlar doğrudan zorunlu çağrılar veya Azure Resource Manager şablonlararacılığıyla bildirime dayalı çağrılar kullanır.Transfers use direct imperative calls or declarative calls via Azure Resource Manager templates.
Kaynak sağlayıcılarıResource providers Kaynak sağlayıcılarına geçirilen çağrılar sertifika tabanlı kimlik doğrulamasıyla korunmaktadır.Calls passed to resource providers are secured with certificate-based authentication.
Azure Resource Manager ve kaynak sağlayıcı, bir API aracılığıyla iletişim içinde kalır.Azure Resource Manager and the resource provider then stay in communication through an API. Azure Resource Manager alınan her çağrı için, kaynak sağlayıcısı bu sertifikayla olan çağrıyı doğrular.For every call that's received from Azure Resource Manager, the resource provider validates the call with that certificate.
Altyapı ve iş mantığıInfrastructure and business logic Kaynak sağlayıcıları, tercih ettikleri bir kimlik doğrulama modu kullanarak iş mantığı ve altyapıyla iletişim kurar.Resource providers communicate with business logic and infrastructure by using an authentication mode of their choice. Azure Stack hub ile birlikte gelen varsayılan kaynak sağlayıcıları, bu iletişimin güvenliğini sağlamak için Windows kimlik doğrulamasını kullanır.The default resource providers that ship with Azure Stack Hub use Windows Authentication to secure this communication.

Kimlik doğrulaması için gereken bilgiler

Azure Resource Manager kimlik doğrulamasıAuthenticate to Azure Resource Manager

Kimlik sağlayıcısıyla kimlik doğrulaması yapmak ve bir JSON Web Token almak için aşağıdaki bilgilere sahip olmanız gerekir:To authenticate with the identity provider and receive a JSON Web Token, you must have the following information:

  1. Kimlik sistemi (Authority) URL 'si: kimlik sağlayıcınızda erişilebileceği URL.URL for the identity system (Authority): The URL at which your identity provider can be reached. Örneğin, https: / /login.Windows.net.For example, https://login.windows.net.
  2. Azure Resource Manager Için uygulama kimliği URI 'si: kimlik sağlayıcınızda kayıtlı Azure Resource Manager için benzersiz tanımlayıcı.App ID URI for Azure Resource Manager: The unique identifier for Azure Resource Manager that's registered with your identity provider. Her Azure Stack hub yüklemesi için de benzersizdir.It's also unique to each Azure Stack Hub installation.
  3. Kimlik bilgileri: kimlik sağlayıcısı ile kimlik doğrulamak için kullandığınız kimlik bilgileri.Credentials: The credential you use to authenticate with the identity provider.
  4. Azure Resource Manager URL 'si: url, Azure Resource Manager hizmetinin konumudur.URL for Azure Resource Manager: The URL is the location of the Azure Resource Manager service. Örneğin, https: / /Management.Azure.com veya https: / /Management.Local.azurestack.external.For example, https://management.azure.com or https://management.local.azurestack.external.

Bir asıl (istemci, uygulama veya Kullanıcı) bir kaynağa erişmek için kimlik doğrulama isteği yaptığında, istek şunları içermelidir:When a principal (a client, apps, or user) makes an authentication request to access a resource, the request must include:

  • Sorumlu kimlik bilgileri.The principal's credentials.
  • Sorumlunun erişmek istediği kaynağın uygulama KIMLIĞI URI 'SI.The app ID URI of the resource that the principal wants to access.

Kimlik bilgileri kimlik sağlayıcısı tarafından onaylanır.The credentials are validated by the identity provider. Kimlik sağlayıcısı aynı zamanda uygulama KIMLIĞI URI 'sinin kayıtlı bir uygulama için olduğunu ve sorumlunun bu kaynak için bir belirteç elde etmek için doğru ayrıcalıklara sahip olduğunu doğrular.The identity provider also validates that the app ID URI is for a registered app, and that the principal has the correct privileges to obtain a token for that resource. İstek geçerliyse, bir JSON Web Token verilir.If the request is valid, a JSON Web Token is granted.

Belirtecin daha sonra Azure Resource Manager için bir isteğin üstbilgisine geçmesi gerekir.The token must then pass in the header of a request to Azure Resource Manager. Azure Resource Manager, belirli bir sıraya göre aşağıdakileri yapar:Azure Resource Manager does the following, in no specific order:

  • Belirtecin doğru kimlik sağlayıcısından olduğunu onaylamak için veren (ISS) talebini doğrular.Validates the issuer (iss) claim to confirm that the token is from the correct identity provider.
  • Belirtecin Azure Resource Manager için verildiğini onaylamak için hedef kitle (AUD) talebini doğrular.Validates the audience (aud) claim to confirm that the token was issued to Azure Resource Manager.
  • JSON Web Token, OpenID aracılığıyla yapılandırılan ve Azure Resource Manager bilinen bir sertifikayla imzalandığını doğrular.Validates that the JSON Web Token is signed with a certificate that's configured through OpenID and known to Azure Resource Manager.
  • Belirtecin etkin olduğunu ve kabul edilebilir olduğunu onaylamak için çıkarılan (iat) ve süre sonu (Exp) taleplerini gözden geçirin.Review the issued at (iat) and expiration (exp) claims to confirm that the token is active and can be accepted.

Tüm doğrulamalar tamamlandığında, Azure Resource Manager, nesne kimliği (OID) ve gruplar taleplerini, sorumlunun erişebileceği kaynakların bir listesini oluşturmak için kullanır.When all validations are complete, Azure Resource Manager uses the object id (oid) and the groups claims to make a list of resources that the principal can access.

Belirteç değişim protokolünün diyagramı

Not

Dağıtımdan sonra, Azure Active Directory genel yönetici izni gerekli değildir.After deployment, Azure Active Directory global administrator permission isn't required. Ancak bazı işlemler, genel yönetici kimlik bilgileri (örneğin, bir kaynak sağlayıcısı yükleyicisi betiği veya izin verilmesini gerektiren yeni bir özellik) gerektirebilir.However, some operations may require the global admin credentials (for example, a resource provider installer script or a new feature requiring a permission to be granted). Hesabın genel yönetici izinlerini geçici olarak yeniden belirleyebilir veya varsayılan sağlayıcı aboneliğininsahibi olan ayrı bir genel yönetici hesabı kullanabilirsiniz.You can either temporarily re-instate the account's global admin permissions or use a separate global admin account that's an owner of the default provider subscription.

Rol tabanlı Access Control kullanmaUse Role-Based Access Control

Azure Stack hub 'ındaki rol tabanlı Access Control (RBAC), Microsoft Azure uygulamasıyla tutarlıdır.Role-Based Access Control (RBAC) in Azure Stack Hub is consistent with the implementation in Microsoft Azure. Kullanıcılara, gruplara ve uygulamalara uygun RBAC rolünü atayarak kaynaklara erişimi yönetebilirsiniz.You can manage access to resources by assigning the appropriate RBAC role to users, groups, and apps. Azure Stack hub ile RBAC kullanma hakkında daha fazla bilgi için aşağıdaki makalelere bakın:For information about how to use RBAC with Azure Stack Hub, see the following articles:

Azure PowerShell ile kimlik doğrulamasıAuthenticate with Azure PowerShell

Azure Stack hub ile kimlik doğrulamak için Azure PowerShell kullanma hakkındaki ayrıntılar , Azure Stack hub kullanıcısının PowerShell ortamını yapılandırmaadresinde bulunabilir.Details about using Azure PowerShell to authenticate with Azure Stack Hub can be found at Configure the Azure Stack Hub user's PowerShell environment.

Azure CLı ile kimlik doğrulamaAuthenticate with Azure CLI

Azure Stack hub ile kimlik doğrulamak için Azure PowerShell kullanma hakkında daha fazla bilgi için bkz. Azure CLI 'yi Azure Stack hub ile kullanmak üzere yükleyip yapılandırma.For information about using Azure PowerShell to authenticate with Azure Stack Hub, see Install and configure Azure CLI for use with Azure Stack Hub.

Sonraki adımlarNext steps