Azure Stack 허브의 id 공급자 개요Overview of identity providers for Azure Stack Hub

Azure Stack 허브를 사용 하려면 Active Directory에서 id 공급자로 지원 되는 Azure Active Directory (Azure AD) 또는 Active Directory Federation Services (AD FS)가 필요 합니다.Azure Stack Hub requires Azure Active Directory (Azure AD) or Active Directory Federation Services (AD FS), backed by Active Directory as an identity provider. 공급자 선택은 Azure Stack 허브를 처음 배포할 때 수행 하는 일회성 결정입니다.The choice of a provider is a one-time decision that you make when you first deploy Azure Stack Hub. 이 문서의 개념 및 권한 부여 정보는 id 공급자 중에서 선택 하는 데 도움이 될 수 있습니다.The concepts and authorization details in this article can help you choose between identity providers.

Azure AD 또는 AD FS 중에서 선택 하는 것은 Azure Stack 허브를 배포 하는 모드에 따라 결정 됩니다.Your choice of either Azure AD or AD FS is determined by the mode in which you deploy Azure Stack Hub:

  • 연결 된 모드에서 배포 하는 경우 Azure AD 또는 AD FS을 사용할 수 있습니다.When you deploy it in a connected mode, you can use either Azure AD or AD FS.
  • 연결 되지 않은 모드로 배포 하는 경우 인터넷에 연결 하지 않고 AD FS만 지원 됩니다.When you deploy it in a disconnected mode, without a connection to the internet, only AD FS is supported.

Azure Stack 허브 환경에 따라 달라 지는 옵션에 대 한 자세한 내용은 다음 문서를 참조 하세요.For more information about your options, which depend on your Azure Stack Hub environment, see the following articles:

Id 공급자에 대 한 일반적인 개념Common concepts for identity providers

다음 섹션에서는 id 공급자와 Azure Stack 허브의 용도에 대 한 일반적인 개념을 설명 합니다.The next sections discuss common concepts about identity providers and their use in Azure Stack Hub.

Id 공급자에 대 한 용어

디렉터리 테 넌 트 및 조직Directory tenants and organizations

디렉터리는 사용자, 응용 프로그램, 그룹서비스사용자에 대 한 정보를 포함 하는 컨테이너입니다.A directory is a container that holds information about users, applications, groups, and service principals.

디렉터리 테 넌 트는 Microsoft 또는 사용자 소유의 회사와 같은 조직입니다.A directory tenant is an organization, such as Microsoft or your own company.

  • Azure AD는 다중 테넌트를 지원하며, 여러 조직을 각각의 자체 디렉터리에서 지원할 수 있습니다.Azure AD supports multiple tenants, and it can support multiple organizations, each in its own directory. Azure AD를 사용 하 고 여러 테 넌 트가 있는 경우 한 테 넌 트의 앱 및 사용자에 게 동일한 디렉터리의 다른 테 넌 트 액세스 권한을 부여할 수 있습니다.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는 단일 테 넌 트를 지원 하므로 단일 조직만 지원 합니다.AD FS supports only a single tenant and, therefore, only a single organization.

사용자 및 그룹Users and groups

사용자 계정 (id)은 사용자 ID와 암호를 사용 하 여 개인을 인증 하는 표준 계정입니다.User accounts (identities) are standard accounts that authenticate individuals by using a user ID and password. 그룹에는 사용자 또는 다른 그룹이 포함 될 수 있습니다.Groups can include users or other groups.

사용자 및 그룹을 만들고 관리 하는 방법은 사용 하는 id 솔루션에 따라 달라 집니다.How you create and manage users and groups depends on the identity solution you use.

Azure Stack 허브에서 사용자 계정:In Azure Stack Hub, user accounts:

  • 사용자 이름 @ 도메인 형식으로 생성 됩니다.Are created in the username@domain format. AD FS는 사용자 계정을 Active Directory 인스턴스에 매핑하고 AD FS는 형식의 사용을 지원 하지 않습니다 \<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을 사용 하도록 설정할 수 있습니다.Can be set up to use multi-factor authentication.
  • 는 처음 등록 하는 디렉터리 (조직의 디렉터리인 경우)로 제한 됩니다.Are restricted to the directory where they first register, which is their organization's directory.
  • 온-프레미스 디렉터리에서 가져올 수 있습니다.Can be imported from your on-premises directories. 자세한 내용은 Azure Active Directory를 사용 하 여 온-프레미스 디렉터리 통합을 참조 하세요.For more information, see Integrate your on-premises directories with Azure Active Directory.

조직의 사용자 포털에 로그인 할 때 https: / /portal.local.azurestack.external URL을 사용 합니다.When you sign in to your organization's user portal, you use the https://portal.local.azurestack.external URL. Azure Stack 허브를 등록 하는 데 사용 된 것과 다른 도메인에서 Azure Stack 허브 포털에 로그인 하는 경우 Azure Stack 허브를 등록 하는 데 사용 되는 도메인 이름을 포털 url에 추가 해야 합니다.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. 예를 들어 Azure Stack 허브가 fabrikam.onmicrosoft.com에 등록 되어 있고 사용자 계정이 로그인 한 경우 admin@contoso.com 사용자 포털에 로그인 하는 데 사용할 URL은 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.

게스트 사용자Guest users

게스트 사용자는 디렉터리의 리소스에 대 한 액세스 권한이 부여 된 다른 디렉터리 테 넌 트의 사용자 계정입니다.Guest users are user accounts from other directory tenants that have been granted access to resources in your directory. 게스트 사용자를 지원 하기 위해 Azure AD를 사용 하 고 다중 테 넌 트 지원을 사용 하도록 설정 합니다.To support guest users, you use Azure AD and enable support for multi-tenancy. 지원을 사용 하도록 설정 하면 디렉터리 테 넌 트의 리소스에 액세스 하도록 게스트 사용자를 초대할 수 있습니다. 그러면 외부 조직과 공동 작업을 수행할 수 있습니다.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.

게스트 사용자를 초대 하기 위해 클라우드 운영자와 사용자는 AZURE AD B2B 공동 작업을 사용할 수 있습니다.To invite guest users, cloud operators and users can use Azure AD B2B collaboration. 초대 받은 사용자는 디렉터리에서 문서, 리소스 및 앱에 액세스할 수 있으며 사용자는 자신의 리소스 및 데이터에 대 한 제어를 유지할 수 있습니다.Invited users get access to documents, resources, and apps from your directory, and you maintain control over your own resources and data.

게스트 사용자는 다른 조직의 디렉터리 테 넌 트에 로그인 할 수 있습니다.As a guest user, you can sign in to another organization's directory tenant. 이렇게 하려면 해당 조직의 디렉터리 이름을 포털 URL에 추가 합니다.To do so, you append that organization's directory name to the portal URL. 예를 들어 Contoso 조직에 속하고 Fabrikam 디렉터리에 로그인 하려는 경우 https:/portal.local.azurestack.external/fabrikam.onmicrosoft.com.를 사용 합니다. /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.

Apps

앱을 Azure AD 또는 AD FS에 등록 한 다음 조직의 사용자에 게 앱을 제공할 수 있습니다.You can register apps to Azure AD or AD FS, and then offer the apps to users in your organization.

앱은 다음과 같습니다.Apps include:

  • 웹 앱: 예를 들어 Azure Portal 및 Azure Resource Manager 있습니다.Web apps: Examples include the Azure portal and Azure Resource Manager. 웹 API 호출을 지원 합니다.They support Web API calls.
  • Native client: Azure PowerShell, Visual Studio 및 Azure CLI를 포함 합니다.Native client: Examples include Azure PowerShell, Visual Studio, and Azure CLI.

앱은 두 가지 유형의 테 넌 트를 지원할 수 있습니다.Apps can support two types of tenancy:

  • 단일 테 넌 트: 앱이 등록 된 디렉터리의 사용자 및 서비스만 지원 합니다.Single-tenant: Supports users and services only from the same directory where the app is registered.

    참고

    AD FS는 단일 디렉터리만 지원 하기 때문에 AD FS 토폴로지에서 만든 앱은 설계상 단일 테 넌 트 앱입니다.Because AD FS supports only a single directory, apps you create in an AD FS topology are, by design, single-tenant apps.

  • 다중 테 넌 트: 앱이 등록 된 디렉터리와 추가 테 넌 트 디렉터리의 사용자 및 서비스에서 사용할 수 있도록 지원 합니다.Multi-tenant: Supports use by users and services from both the directory where the app is registered and additional tenant directories. 다중 테 넌 트 앱을 사용 하면 다른 테 넌 트 디렉터리 (다른 Azure AD 테 넌 트)의 사용자가 앱에 로그인 할 수 있습니다.With multi-tenant apps, users of another tenant directory (another Azure AD tenant) can sign in to your app.

    다중 테 넌 트에 대 한 자세한 내용은 다중 테 넌 트 사용을 참조 하세요.For more information about multi-tenancy, see Enable multi-tenancy.

    다중 테 넌 트 앱을 개발 하는 방법에 대 한 자세한 내용은 다중 테 넌 트 앱을 참조 하세요.For more information about developing a multi-tenant app, see Multi-tenant apps.

앱을 등록 하는 경우 다음 두 개체를 만듭니다.When you register an app, you create two objects:

  • 응용 프로그램 개체: 모든 테 넌 트의 응용 프로그램에 대 한 전역 표현입니다.Application object: The global representation of the app across all tenants. 이 관계는 소프트웨어 앱과 일대일 이며 앱이 처음 등록 된 디렉터리에만 존재 합니다.This relationship is one-to-one with the software app and exists only in the directory where the app is first registered.

  • 서비스 주체 개체: 앱이 처음 등록 된 디렉터리에서 앱에 대해 만들어진 자격 증명입니다.Service principal object: A credential that's created for an app in the directory where the app is first registered. 또한 서비스 주체는 해당 앱이 사용 되는 각 추가 테 넌 트의 디렉터리에 생성 됩니다.A service principal is also created in the directory of each additional tenant where that app is used. 이 관계는 소프트웨어 앱에서 일대다 일 수 있습니다.This relationship can be one-to-many with the software app.

앱 및 서비스 주체 개체에 대해 자세히 알아보려면 Azure Active Directory의 응용 프로그램 및 서비스 주체 개체를 참조 하세요.To learn more about app and service principal objects, see Application and service principal objects in Azure Active Directory.

서비스 주체Service principals

서비스 주체는 Azure Stack 허브의 리소스에 대 한 액세스 권한을 부여 하는 앱 또는 서비스에 대 한 자격 증명 집합입니다.A service principal is a set of credentials for an app or service that grant access to resources in Azure Stack Hub. 서비스 주체를 사용 하는 경우 앱의 사용자 권한 으로부터 앱 사용 권한을 분리 합니다.The use of a service principal separates the app permissions from the permissions of the user of the app.

앱이 사용 되는 각 테 넌 트에 서비스 주체가 생성 됩니다.A service principal is created in each tenant where the app is used. 서비스 주체는 로그인에 대 한 id 및 해당 테 넌 트로 보호 되는 리소스 (예: 사용자)에 대 한 액세스를 설정 합니다.The service principal establishes an identity for sign-in and access to resources (such as users) that are secured by that tenant.

  • 단일 테 넌 트 앱에는 처음 만들어진 디렉터리에 있는 서비스 사용자가 한 개만 있습니다.A single-tenant app has only one service principal, which is in the directory where it's first created. 이 서비스 주체는 앱을 등록 하는 동안 만들어지고 동의 사용 됩니다.This service principal is created and consents to being used during registration of the app.
  • 다중 테 넌 트 웹 앱 또는 API에는 각 테 넌 트의 사용자가 앱 사용에 동의 하는 서비스 사용자가 있습니다.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.

서비스 사용자의 자격 증명은 Azure Portal 또는 인증서를 통해 생성 되는 키 일 수 있습니다.Credentials for service principals can be either a key that's generated through the Azure portal or a certificate. 인증서의 사용은 인증서가 키 보다 더 안전한 것으로 간주 되기 때문에 자동화에 적합 합니다.The use of a certificate is suited for automation because certificates are considered more secure than keys.

참고

Azure Stack Hub와 AD FS를 사용 하는 경우 관리자만 서비스 주체를 만들 수 있습니다.When you use AD FS with Azure Stack Hub, only the administrator can create service principals. AD FS를 사용 하는 경우 서비스 주체는 인증서가 필요 하며 권한 있는 끝점 (PEP)을 통해 생성 됩니다.With AD FS, service principals require certificates and are created through the privileged endpoint (PEP). 자세한 내용은 앱 id를 사용 하 여 리소스에 액세스를 참조 하세요.For more information, see Use an app identity to access resources.

Azure Stack Hub의 서비스 사용자에 대 한 자세한 내용은 서비스 주체 만들기를 참조 하세요.To learn about service principals for Azure Stack Hub, see Create service principals.

서비스Services

Id 공급자와 상호 작용 하는 Azure Stack 허브의 서비스는 id 공급자를 사용 하 여 앱으로 등록 됩니다.Services in Azure Stack Hub that interact with the identity provider are registered as apps with the identity provider. 앱과 마찬가지로 등록을 통해 서비스에서 id 시스템을 인증할 수 있습니다.Like apps, registration enables a service to authenticate with the identity system.

모든 Azure 서비스는 Openid connect Connect 프로토콜 및 JSON 웹 토큰 을 사용 하 여 해당 id를 설정 합니다.All Azure services use OpenID Connect protocols and JSON Web Tokens to establish their identity. Azure AD 및 AD FS는 지속적으로 프로토콜을 사용 하므로 ADAL ( Azure Active Directory Authentication Library )을 사용 하 여 온-프레미스 또는 Azure (연결 된 시나리오)를 인증할 수 있습니다.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을 사용 하 여 클라우드 및 온-프레미스 리소스 관리를 위해 Azure PowerShell 및 Azure CLI 같은 도구를 사용할 수도 있습니다.With ADAL, you can also use tools such as Azure PowerShell and Azure CLI for cross-cloud and on-premises resource management.

Id 및 id 시스템Identities and your identity system

Azure Stack 허브의 id에는 사용자 계정, 그룹 및 서비스 사용자가 포함 됩니다.Identities for Azure Stack Hub include user accounts, groups, and service principals.

Azure Stack 허브를 설치 하는 경우 몇 가지 기본 제공 앱 및 서비스가 자동으로 디렉터리 테 넌 트의 id 공급자에 등록 됩니다.When you install Azure Stack Hub, several built-in apps and services automatically register with your identity provider in the directory tenant. 등록 하는 일부 서비스는 관리에 사용 됩니다.Some services that register are used for administration. 사용자는 다른 서비스를 사용할 수 있습니다.Other services are available for users. 기본 등록에서는 둘 다 상호 작용할 수 있는 핵심 서비스 id와 나중에 추가 하는 id를 제공 합니다.The default registrations give core services identities that can interact both with each other and with identities that you add later.

다중 테 넌 트를 사용 하 여 Azure AD를 설정 하는 경우 일부 앱이 새 디렉터리로 전파 됩니다.If you set up Azure AD with multi-tenancy, some apps propagate to the new directories.

인증 및 권한 부여Authentication and authorization

앱 및 사용자에의 한 인증Authentication by apps and users

Azure Stack 허브 계층 간의 id

앱 및 사용자에 대 한 Azure Stack 허브의 아키텍처는 4 개의 계층으로 설명 됩니다.For apps and users, the architecture of Azure Stack Hub is described by four layers. 이러한 각 계층 간의 상호 작용은 서로 다른 유형의 인증을 사용할 수 있습니다.Interactions between each of these layers can use different types of authentication.

계층Layer 계층 간 인증Authentication between layers
관리자 포털 등의 도구 및 클라이언트Tools and clients, such as the administrator portal Azure Stack 허브에서 리소스를 액세스 하거나 수정 하기 위해 도구와 클라이언트는 JSON Web Token 를 사용 하 여 Azure Resource Manager에 대 한 호출을 수행 합니다.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의 유효성을 검사 하 고 발급 된 토큰의 클레임 을 관찰 하 여 사용자 또는 서비스 사용자가 Azure Stack 허브에서 갖는 권한 부여 수준을 예측 합니다.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 및 핵심 서비스Azure Resource Manager and its core services Azure Resource Manager는 리소스 공급자와 통신 하 여 사용자의 통신을 전송 합니다.Azure Resource Manager communicates with resource providers to transfer communication from users.
전송은 Azure Resource Manager 템플릿을통해 직접 명령적 호출 또는 선언적 호출을 사용 합니다.Transfers use direct imperative calls or declarative calls via Azure Resource Manager templates.
리소스 공급자Resource providers 리소스 공급자에 전달 되는 호출은 인증서 기반 인증을 사용 하 여 보호 됩니다.Calls passed to resource providers are secured with certificate-based authentication.
그런 다음 Azure Resource Manager 및 리소스 공급자는 API를 통해 통신을 유지 합니다.Azure Resource Manager and the resource provider then stay in communication through an API. Azure Resource Manager에서 수신 된 모든 호출에 대해 리소스 공급자는 해당 인증서를 사용 하 여 호출의 유효성을 검사 합니다.For every call that's received from Azure Resource Manager, the resource provider validates the call with that certificate.
인프라 및 비즈니스 논리Infrastructure and business logic 리소스 공급자는 선택한 인증 모드를 사용 하 여 비즈니스 논리 및 인프라와 통신 합니다.Resource providers communicate with business logic and infrastructure by using an authentication mode of their choice. Azure Stack Hub와 함께 제공 되는 기본 리소스 공급자는 Windows 인증을 사용 하 여이 통신을 보호 합니다.The default resource providers that ship with Azure Stack Hub use Windows Authentication to secure this communication.

인증에 필요한 정보

Azure Resource Manager 인증Authenticate to Azure Resource Manager

Id 공급자를 사용 하 여 인증 하 고 JSON Web Token 수신 하려면 다음 정보가 필요 합니다.To authenticate with the identity provider and receive a JSON Web Token, you must have the following information:

  1. Id 시스템 (기관)의 url: id 공급자에 연결할 수 있는 url입니다.URL for the identity system (Authority): The URL at which your identity provider can be reached. : https: / /login.windows.net.For example, https://login.windows.net.
  2. Azure Resource Manager에 대 한 앱 ID URI: id 공급자에 등록 된 Azure Resource Manager에 대 한 고유 식별자입니다.App ID URI for Azure Resource Manager: The unique identifier for Azure Resource Manager that's registered with your identity provider. 각 Azure Stack Hub 설치에 대해서도 고유 합니다.It's also unique to each Azure Stack Hub installation.
  3. 자격 증명: id 공급자를 사용 하 여 인증 하는 데 사용 하는 자격 증명입니다.Credentials: The credential you use to authenticate with the identity provider.
  4. Azure Resource Manager url: url은 Azure Resource Manager 서비스의 위치입니다.URL for Azure Resource Manager: The URL is the location of the Azure Resource Manager service. 예: https: / /management.azure.com 또는 https: / /management.local.azurestack.external.For example, https://management.azure.com or https://management.local.azurestack.external.

보안 주체 (클라이언트, 앱 또는 사용자)가 리소스에 액세스 하기 위해 인증을 요청 하는 경우 요청은 다음을 포함 해야 합니다.When a principal (a client, apps, or user) makes an authentication request to access a resource, the request must include:

  • 보안 주체의 자격 증명입니다.The principal's credentials.
  • 보안 주체가 액세스 하려는 리소스의 앱 ID URI입니다.The app ID URI of the resource that the principal wants to access.

Id 공급자가 자격 증명의 유효성을 검사 합니다.The credentials are validated by the identity provider. 또한 id 공급자는 앱 ID URI가 등록 된 앱에 대 한 것인지, 그리고 해당 리소스에 대 한 토큰을 가져올 수 있는 올바른 권한이 보안 주체에 있는지를 확인 합니다.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. 요청이 유효한 경우 JSON Web Token가 부여 됩니다.If the request is valid, a JSON Web Token is granted.

그런 다음 토큰은 Azure Resource Manager 요청 헤더를 전달 해야 합니다.The token must then pass in the header of a request to Azure Resource Manager. Azure Resource Manager 다음을 수행 합니다.Azure Resource Manager does the following, in no specific order:

  • 발급자 (iss) 클레임의 유효성을 검사 하 여 토큰이 올바른 id 공급자 인지 확인 합니다.Validates the issuer (iss) claim to confirm that the token is from the correct identity provider.
  • 대상 (aud) 클레임의 유효성을 검사 하 여 토큰이 Azure Resource Manager 발급 되었는지 확인 합니다.Validates the audience (aud) claim to confirm that the token was issued to Azure Resource Manager.
  • Openid connect를 통해 구성 된 인증서를 사용 하 여 JSON Web Token에 서명 하 고 Azure Resource Manager 하는 것으로 인식 되는지 확인 합니다.Validates that the JSON Web Token is signed with a certificate that's configured through OpenID and known to Azure Resource Manager.
  • 발급 된 at (iat) 및 만료 (exp) 클레임을 검토 하 여 토큰이 활성 상태이 고 허용할 수 있는지 확인 합니다.Review the issued at (iat) and expiration (exp) claims to confirm that the token is active and can be accepted.

모든 유효성 검사가 완료 되 면 Azure Resource Manager는 oid ( 개체 id ) 및 그룹 클레임을 사용 하 여 보안 주체가 액세스할 수 있는 리소스 목록을 만듭니다.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.

토큰 교환 프로토콜의 다이어그램

참고

배포 후 Azure Active Directory 전역 관리자 권한이 필요 하지 않습니다.After deployment, Azure Active Directory global administrator permission isn't required. 그러나 일부 작업에는 전역 관리자 자격 증명 (예: 리소스 공급자 설치 관리자 스크립트 또는 권한을 부여 해야 하는 새 기능)이 필요할 수 있습니다.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). 계정의 전역 관리자 권한을 일시적으로 다시 설정 기본 공급자 구독의소유자 인 별도의 전역 관리자 계정을 사용할 수 있습니다.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.

역할 기반 Access Control 사용Use Role-Based Access Control

Azure Stack 허브의 RBAC (역할 기반 Access Control)는 Microsoft Azure 구현과 일치 합니다.Role-Based Access Control (RBAC) in Azure Stack Hub is consistent with the implementation in Microsoft Azure. 사용자, 그룹 및 앱에 적절 한 RBAC 역할을 할당 하 여 리소스에 대 한 액세스를 관리할 수 있습니다.You can manage access to resources by assigning the appropriate RBAC role to users, groups, and apps. Azure Stack 허브에서 RBAC를 사용 하는 방법에 대 한 자세한 내용은 다음 문서를 참조 하세요.For information about how to use RBAC with Azure Stack Hub, see the following articles:

Azure PowerShell을 사용하여 인증Authenticate with Azure PowerShell

Azure PowerShell를 사용 하 여 Azure Stack 허브에 인증 하는 방법에 대 한 자세한 내용은 Azure Stack 허브 사용자의 PowerShell 환경 구성에서 찾을 수 있습니다.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 CLI 인증Authenticate with Azure CLI

Azure PowerShell를 사용 하 여 Azure Stack Hub로 인증 하는 방법에 대 한 자세한 내용은 Azure Stack Hub에 사용할 Azure CLI 설치 및 구성을 참조 하세요.For information about using Azure PowerShell to authenticate with Azure Stack Hub, see Install and configure Azure CLI for use with Azure Stack Hub.

다음 단계Next steps