Identity and Rights Management in CSP model - Part 2

[アーティクル]
06/05/2017

The CSP program is currently rolling out at scale and many service providers are embarking on the journey to provide management infrastructure services for their customers. In addition to the first article about Identity in CSP, we will show more tricks from the field.

While the scale is rapidly increasing the ask for operational optimization increases as well for these managed service providers as they have to integrate these newly acquired environments under their existing tools and provide same levels of service management as they used to provide within their on-premises environments.

The objective of this post is to provide a set of guidance that will help CSP partners, offering managed services, to optimize their operations by reducing the surface and impact of human errors or in other words: Identity Management and RBAC in the world of a CSP managed services provider

The goal is to increase the level of control, insight and automation, which will lead to staff optimization and a higher level of services provided by the Cloud Solution Provider.

Reducing the surface and impact of human errors

When the operational organization of a service provider is growing due to the increasing number of environments to manage, the need of a more restrict control of this operational organization grows accordingly. The growth can be from within a single region or even across multiple regions spread over multiple time zones.

With this growing organization, the impact and likelihood of possible human errors must be controlled. There are obvious reasons these days not to provide everybody, whom has slightly something to do with operations, with administrator privileges by default within these environments.

To limit the impact of these, intentionally or not, human errors, it is essential to limit the impact surface. The approach is by addressing this within the following areas:

Definition of the operational organization structure. A clear definition on the different roles within a manage service provider organization;
Implementation and enablement of granular role base access control assigned to the operational roles within the managed services provider organization managing the customer CSP provisioned Azure subscriptions;
Privileged Access Management through Just in Time (JIT) and Just Enough Administration (JEA) capabilities towards the operational roles within the managed services provider organization;
Multifactor Authentication towards the operational roles within the managed services provider organization to address to risk of compromised accounts.

Within the landscape of a managed services Cloud Solution Provider the reach goes often rapidly beyond that of a single region. This introduces extra complexities. Within the CSP program each region results into a partner contract, with about the current 15 regions this could scale into a 15 partner contracts for a single Cloud Solution Provider if he is servicing customers with subsidiaries and/or subscriptions in each region. A partner contract is linked to a contract specific Azure Active Directory (AAD), this has a unique domain name by default along the lines of contoso.onmicrosoft.com, but the partner can also add his own domain name to this AAD such as contoso.com. The latter can only be done once for a specific domain name. With multiple partner contracts Cloud Solution Provider often resorts in domain names as contoso.eu, contoso.us, contoso.jp etc.

The complexities occur when the managed services provider has a support organization managing the CSP provisioned Azure subscription within those different regions. This means a single person will have multiple accounts within the different regions, with obviously each account a password by itself: helpdeskuser@consoso.eu, helpdeskuser@contoso.us etc. Typical identity or single sign solutions such as single authentication source, federation and/or trusts to address these kinds of complexities within a typical enterprise environment are not possible within and/or between CSP partner contracts (different Azure AD instances). In this whitepaper, we attempt to address these complexities, which put a significant burden on the scalability and the operational effort towards a managed services provider, in consideration and has defined an approach to address these as well.

The CSP operational organization structure

The following diagram illustrates the typical operational roles within a managed services provider organization. Although the intention of this diagram was not to provide an all-inclusive organization layout, the roles as such are utilized within the different concepts as discussed in this post.

Within this landscape of the CSP Operational Organization there are two areas where operational activities are conducted:

CSP - This area is concentrated around customer management (especially onboarding), subscription management and invoicing;
Azure - This area is concentrated around the CSP provisioned Azure subscriptions where the managed service provider managed the provisioned Azure infrastructure where the actual workloads are placed. The management of the workloads itself (Application Area) is out of scope of this post.

The following roles are identified:

Area	Role	Description
Service Delivery
	Architect	Accountable for supporting customer with their hybrid cloud architecture and cloud adoption to consume published managed services. Uses principles that creates the cloud environment. Works with customers to determine roadmap for supporting cloud technologies. Works with customers in architecting solutions to make managed services available as well as to technically onboard customers on to the managed services
	Service Manager	Accountable for service delivery towards the different customers. Primary contact point for Service Consumer organization. Manages and communicates Service Description towards customers. Manages and communicates Service Level Agreement (as part of the Service Description) and monitors service levels. Monitors and communicates pay-per-use costs to customers. Entry point for information and non-standard requests.
Service Operations
	Platform Engineers	Responsible for building out cloud platform services infrastructure towards shared services Responsible for building out cloud platform services infrastructure towards customers within the managed services environments Responsible for building out on premise platform infrastructure and hybrid concepts with adoption of cloud platform services infrastructure Overall responsible for expanding capacity within cloud hosted managed services
Management and Support
	Support	Customer (partner) initial contact point for service related incidents, requests or queries Creates tickets within customer support system Follows up on ticket logged within customer support system for 1st level of support
	Change and Incident Management	Manages logged tickets and incident resolution within customer support system for 2nd and 3rd level of support Creates and manages CP/Azure/O365 Service Requests. Manages logging and delivery of change request
Contract Management Roles
	Billing and Invoicing	Responsible for validating customer information, financials, and contract details. Creates customer within CSP portal Assigns subscriptions to customer Invoice management towards customer for consumed services
	Sales	Responsible for selling and upselling managed services Drive consumption
	Finance	Overall financial accountability Auditing on cost, consumption versus invoicing

The technical roles

From a technical perspective, there different environment within the Cloud Solution Provider environment that determines the capability that will be assigned these operational roles are specified in previous chapter. These environments are:

CSP Partner Center - This portal and exposed API's are concentrated around customer and subscription management;
Azure Active Directory - Each partner contact and each customer has an Azure Active Directory instance. User accounts and groups within these instances can have technical roles assigned within the CSP provisioned Azure Subscriptions;
CSP Provisioned Azure Subscriptions - Each customer has one or more CSP Provisioned Azure Subscriptions.

Each of these environments have a certain collection of roles, role that can be assigned to a user object or group object. The role assignment determined the capabilities the user object will have within that environment. The following chapters specifies the different out of the box roles within each area.

CSP Partner Center - Customer and Subscription Management

Role	What you can do	What you can not do
Admin Agent	Customer management Subscription management Service health and service requests for customers Request delegated admin privileges View pricing and offers Billing Admin on behalf of Register a value-added reseller	User management Service requests for Partner Center
Sales Agent	Customer management Subscription management View support tickets Request a relationship Manage customer leads View the customer agreement Register a value-added reseller	Create support tickets for services or Partner Center Resolve support tickets View service health View pricing and offers Billing Admin on behalf of
Helpdesk Agent	Search for and view a customer Edit customer details Service health and service requests Admin on behalf of	View partner profiles Create a new customer listing Edit customer billing info Subscription management Request a relationship Manage customer leads View pricing and offers View the customer agreement Billing Register a value-added reseller

Azure Active Directory - Directory Services

Role	Description
AdHoc License Administrator	Allows access manage AdHoc license.
Application Administrator	Application Administrator role has access to perform common application management related tasks.
Application Developer	Application Developer role has ability to create single-tenant applications.
Application Proxy Service Administrator	Application Proxy Service Administrator has full access in the Application Proxy Service.
Billing Administrator	Billing Administrator has access to perform common billing related tasks.
Company Administrator	Company Administrator role has full access to perform any operation in the company scope.
Compliance Administrator	Compliance administrator.
CRM Service Administrator	CRM Service Administrator has full access in the CRM Service.
Customer LockBox Access Approver	Customer LockBox Access Approver has approval access to user data requests.
Device Administrators	Device Administrators
Device Join	Device Join
Device Managers	Allows access to read and edit device properties.
Device Users	Device Users
Directory Readers	Allows access to various read only tasks in the directory.
Directory Synchronization Accounts	Directory Synchronization Accounts
Directory Writers	Allows access read tasks and a subset of write tasks in the directory.
Email Verified User Creator	Allows creation of new email verified users.
Exchange Service Administrator	Exchange Service Administrator.
Guest Inviter	Guest Inviter has access to invite guest users.
Helpdesk Administrator	Helpdesk Administrator has access to perform common helpdesk related tasks.
Intune Service Administrator	Intune Service Administrator has full access in the Intune Service.
Lync Service Administrator	Lync Service Administrator.
Mailbox Administrator	Allows access and management of users mailboxes.
Partner Tier1 Support	Allows ability to perform tier1 support tasks.
Partner Tier2 Support	Allows ability to perform tier2 support tasks.
Power BI Service Administrator	Full access in the Power BI Service.
Privileged Role Administrator	Privileged Role Administrator has access to perform common role management related tasks.
Security Administrator	Security Administrator allows ability to read and manage security configuration and reports.
Security Reader	Security Reader allows ability to read security information and reports.
Service Support Administrator	Service Support Administrator has access to perform common support tasks.
SharePoint Service Administrator	SharePoint Service Administrator.
User	Every user is implicitly considered to be a member of the User Role.
User Account Administrator	User Account Administrator has access to perform common user management related tasks.
Workplace Device Join	Workplace Device Join

Azure Subscription Standard Roles

Role	Description
API Management Service Contributor	API Management Service Contributor
API Management Service Operator Role	Can manage service but not the APIs
API Management Service Reader Role	API Management Service Reader Role
Application Insights Component Contributor	Can manage Application Insights components
Automation Operator	Automation Operators are able to start, stop, suspend, and resume jobs
Backup Contributor	Lets you manage backup service, but can't create vaults and give access to others
Backup Operator	Lets you manage backup services, except removal of backup, vault creation and giving access to others
Backup Reader	Can view backup services, but can't make changes
BizTalk Contributor	Lets you manage BizTalk services, but not access to them.
CDN Endpoint Contributor	Can manage CDN endpoints, but can not grant access to other users.
CDN Endpoint Reader	Can view CDN endpoints, but can not make changes.
CDN Profile Contributor	Can manage CDN profiles and their endpoints, but can not grant access to other users.
CDN Profile Reader	Can view CDN profiles and their endpoints, but can not make changes.
Classic Network Contributor	Lets you manage classic networks, but not access to them.
Classic Storage Account Contributor	Lets you manage classic storage accounts, but not access to them.
Classic Virtual Machine Contributor	Lets you manage classic virtual machines, but not access to them, and not the virtual network or storage account they are connected to.
ClearDB MySQL DB Contributor	Lets you manage ClearDB MySQL databases, but not access to them.
Contributor	Lets you manage everything except access to resources.
Data Factory Contributor	Create and manage data factories, as well as child resources within them.
Data Lake Analytics Developer	Lets you submit, monitor, and manage your own jobs but not create or delete Data Lake Analytics accounts.
DevTest Labs User	Lets you connect, start, restart, and shutdown your virtual machines in your Azure DevTest Labs.
DNS Zone Contributor	Lets you manage DNS zones and record sets in Azure DNS, but does not let you control who has access to them.
DocumentDB Account Contributor	Lets you manage DocumentDB accounts, but not access to them.
Intelligent Systems Account Contributor	Lets you manage Intelligent Systems accounts, but not access to them.
Key Vault Contributor	Lets you manage key vaults, but not access to them.
Logic App Contributor	Lets you manage logic app, but not access to them.
Logic App Operator	Lets you read, enable and disable logic app.
Monitoring Contributor Service Role	Can read all monitoring data and update monitoring settings.
Monitoring Reader Service Role	Can read all monitoring data.
Network Contributor	Lets you manage networks, but not access to them.
New Relic APM Account Contributor	Lets you manage New Relic Application Performance Management accounts and applications, but not access to them.
Owner	Lets you manage everything, including access to resources.
Reader	Lets you view everything, but not make any changes.
Redis Cache Contributor	Lets you manage Redis caches, but not access to them.
Scheduler Job Collections Contributor	Lets you manage Scheduler job collections, but not access to them.
Search Service Contributor	Lets you manage Search services, but not access to them.
Security Manager	Lets you manage security components, security policies and virtual machines
SQL DB Contributor	Lets you manage SQL databases, but not access to them. Also, you can't manage their security-related policies or their parent SQL servers.
SQL Security Manager	Lets you manage the security-related policies of SQL servers and databases, but not access to them.
SQL Server Contributor	Lets you manage SQL servers and databases, but not access to them, and not their security -related policies.
Storage Account Contributor	Lets you manage storage accounts, but not access to them.
Traffic Manager Contributor	Lets you manage Traffic Manager profiles, but does not let you control who has access to them.
User Access Administrator	Lets you manage user access to Azure resources.
Virtual Machine Contributor	Lets you manage virtual machines, but not access to them, and not the virtual network or storage account they are connected to.
Web Plan Contributor	Lets you manage the web plans for websites, but not access to them.
Website Contributor	Lets you manage websites (not web plans), but not access to them.

Mapping the organizational roles to the technical roles.

To reduce the surface and impact of human errors a fine-grained mapping is to be applied, a mapping from organization roles to technical roles, a foundational planning activity. Later in this post the technical implementation is provided.

The organization role definition as well as the mapping of those roles into certain technical roles is organization specific, therefor only a sample of such a mapping is provide for illustrative purposes only. This post is accompanied by mapping template.

Implementation granular role based access control

This chapter describes implementation of a more granular role based access control (RBAC) for a managed services cloud service provider within CSP provisioned Azure subscriptions. While building up the concept through a staged approach, the overall solution towards RBAC within the CSP provisioned Azure subscription is fully automated.

The concept

The concept is based on adding accounts from the service provider partner AD as external account to the tenant or customer AD and assign certain roles to these accounts within the CSP provisioned Azure subscription. Obviously, as with any management around users, an approach based on groups is more favorable than one managing single user objects.

The concept as positioned here only applies to the customers that are contracts to the partner contract of the CSP provider. The same CSP provider can have multiple partner contracts, unique for each region. It is not possible to assign partner Azure AD users as external user to a customer Azure AD within another region. The creation of the external user is necessary since itâ€™s not possible to create any form of trust or federation between two Azure Active Directories.

To ease the automation of this the used group names are prefixed if a prefix of choice to make these groups easy identifiable. This automation process would create synchronize the members of these 'special' groups into similar named 'special' groups into all customer Azure AD as external users. Roles within the CSP provisioned Azure subscriptions are assigned to these 'special' groups. Based on the group membership the external user, which is basically a user within the partner AD, will receive the role capabilities.

Once the partner (CSP Provider) Azure AD user has been assigned as external user within the customer or tenant Azure AD, the customer or tenant Azure AD will show up within the Azure Portal of the user.

The group synchronization and role assignment automation

Automation of account creation and role assigned is essential, especially when a CSP partner has a significant number of customers with CSP provisioned Azure subscriptions. The automation takes place within the following areas:

The automation approach as part of this post is based on two PowerShell scripts that will run within the Azure Automation environment of the CSP Partner: Group Synchronization script and Role Synchronization script.

The "Guest Inviter"?

To allow an automation account to invite external users into the customer Azure AD it needs to hold the role of "Guest Inviter"? within the customer Azure AD. To obtain this privilege, the following steps are required:

Create automation account as an external user within the customer Azure AD with userType of 'Global Admin'.
Utilize the AzureADPreview PowerShell module which can be downloaded from: https://www.powershellgallery.com/packages/AzureADPreview. Follow the instructions do download and import the module.
Connect to the Tenant Azure AD with a partner AD 'Admin Agent' account and assign the external user representation of the automation account the role of "Guest Inviter"? within the customer's Azure AD.

Connect-AzureAD -TenantID -Credential <admin agent>$user = Get-AzureADUser -SearchString "<the automation account DisplayName>"$InviterRole = Get-AzureADDirectoryRoleTemplate | Where-Object {$_.DisplayName -eq "Guest Inviter"}$Role = New-Object Microsoft.Open.AzureAD.Model.DirectoryRole$Role.RoleTemplateId = $InviterRole.ObjectIdEnable-AzureADDirectoryRole -DirectoryRole $Role$Role = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "Guest Inviter"}Add-AzureADDirectoryRoleMember -ObjectId $Role.ObjectId -RefObjectId $user.ObjectId

With this the automation account received the capability to invite users to the customer Azure AD, through:

New-AzureADMSInvitation -InvitedUserDisplayName "John Joe" -InvitedUserEmailAddress "jj@provider.com" -InviteRedirectUrl "https://www.microsoft.com"

The Group Synchronization

The group synchronization script can either be run manually by the CSP partner or through Azure Automation within a subscription of the CSP partner.

The synchronization script synchronizes "special/for this purpose created" group and group members into the customers Azure Ads. For the sake of completeness, the script will ensure there are no external users within the customer Azure AD that are not member of the groups being synchronized.

The flow of the script is as follow:

Connect-AzureAD as the automation account to the Partner AD
Build up whitelist of external accounts that can exist in customer AAD
Get All prefixed groups Groups
Get All Group members and build up lookup table (=partner AD user)
Get All Contracts and for each contract
1. Connect-AzureAD to Tenant AD with sync account
2. Sync External Users
  1. Verify if external user exists in partner AD, if not remove from tenant AD (exclude whitelist members)
  2. Verify if partner AD user exists in tenant AD, if not than create invitation
3. Sync Groups
  1. Verify tenant Groups, if not in partner AD than remove group
  2. Verify partner Groups, if not in tenant AD than create group
4. Sync Group Members
  1. Verify tenant Group Members against partner Group Members within lookup table, if not exist remove object from the group
  2. Build up tenant group/group members lookup table
  3. Verify partner Group Members against tenant Group Member within lookup table, if not exist add object to the group

A PowerShell script implementing the group synchronization as outlined can be found in a GitHub repository located here.

The Role Synchronization

The role synchronization can either be run manually by the CSP partner or through Azure Automation within a subscription of the CSP partner.

The role synchronization script has two purposes:

the creation and synchronization of custom roles;
the synchronization of role assignments to groups.

The script will contain definitions towards which group to assign as to which role as well as the capabilities of a custom role. There are many different ways to make these kind of definitions, the approach taken is provided only as a sample approach.

The script will first ensure the existence and synchronization of custom the custom role as per the following flow

Format: (ProviderPrefix_RoleName:RoleScope )
1. _MyProvider-VM Contributor:Microsoft.Compute/virtualMachines/*
2. _MyProvider-Support Contributor:Microsoft.Support/*
Get All Role Templates
1. Remove custom role with provider prefix from role templates
2. If custom role does not exist, add custom role

Once the custom roles are created and synchronized the role assigned takes place as per the following flow:

Definition of group-role assignments, for example:
1. _mymsp-Operator group have the assigned the following roles: "Virtual Machine Contributor"?, "Storage Account Contributor"?, "Network Contributor"?
2. _mymsp-Helpdesk group have the assigned the following role: "Reader"?
Connect-AzureAD as admin agent account on Partner AD
Get All Contracts and for each contract
1. Get All Azure Subscriptions and for each subscription
  1. Verify within the Azure Subscription Role Assignments that there are no role assignments to groups prefixed with "_mymsp-" other than the above. If there is, remove the group from the role assignment.
  2. Ensure the assignment of Azure subscription Roles to the groups as defined above

A PowerShell script implementing the role synchronization as outlined can be found in a GitHub repository located here.

Configuration Azure Automation Account

The following figure illustrates the configuration of the Azure Automation environment to run a PowerShell script.

The major steps are:

Deployment of the AD Preview module into Azure Automation environment of CSP partner
Create the Azure Automation Account
Create Runbook with PowerShell script
Define the variables within the Azure Automation Account
Define the credentials within the Azure Automation Account

Synchronization partner on-premise AD into partner Azure AD

To not to have to create all account within the partner Azure AD(s) manually, the partner on premise AD could be synchronized with the partner Azure AD that is connected to his CSP contract by utilizing either Azure AD Connect or a third-party AD synchronization tool.

Though this integration pattern user account with their identity information as well as password will be synchronized into the partner Azure AD. If a user account gets deleted on premise, it will be delete within the partner Azure AD. The external accounts within the tenant Azure AD initially still exist but will be removed by the group synchronization script. Password changes on-premise will be synchronized into the Azure AD.

It is a good practice to put the administrative operations accounts as well as the "special" prefixed groups in to a dedicated organizational unit within the on premise AD and limit the objects to sync to that particular organization unit.

In case the partner domain name has not been registered with the partner Azure AD, the synchronized userPrincipalName will receive the partner Azure AD default suffix such as userabc@myprovider.onmicrosoft.com as within this sample. In that scenario the users that would perform the managed services towards the customer CSP provisioned Azure subscription would log in with userabc@myprovider.onmicrosoft.com userPrincipalname into Azure with the same password of their on-premise userabc@myprovider.com account.

The following diagram provides an overview on the configuration of the AD connect as well as the different object created within the partner Azure AD.

Synchronization partner on-premise AD into multiple partner Azure AD

CSP partners operating within multiple regions will face the challenge that a domain name is can only be registered with one Azure AD. It is not possible to register the on-premise domain name with multiple Azure AD that are connected to the CSP partner contract to create a single name space for the users aligned with the domain name used on premise.

Therefor while creating the partner Azure AD default domain names, the names need to be chosen carefully to ease the administration of multiple CSP contracts by the same resources in a later stage. The table below is provided as a sample:

On premise domain	CSP Target region	CSP partner AD Domain
contoso.com	Europe	contosoeu.onmicrosoft.con
	United States	contosous.onmicrosoft.com
	Japan	contosojp.onmicrosoft.com
	...	...

As an example: A user with an account as user1@contoso.com would login to the azure portal as user1@contosoeu.onmicrosoft.com to administer the CSP provisioned azure subscriptions that are provisioned under the CSP europe contract. The abbreviations such as eu, us, jp etc. are freely chosen.

Microsoft Azure AD Connect tool has only the capability to connect to a single Azure AD, there are tools available that are capable to support multiple Azure AD out of a single on-premise Directory Service, the so-called multitenant AD synchronization tools. In case of Azure AD connect tool this would mean a dedicated instance per partner CSP contract (= Azure AD). Given the expected burden on the operational organization it might be worth evaluating those multitenant AD synchronization tools, although they likely come with a cost.

Within this scenario, the synchronization will take place only from on premise to partner Azure AD, as such the different AD connect will point to the same OU within the on-premise AD. Pointing multiple AD Connect instances to a single OU is not a formally support configuration.

This bring us to the following full solution diagram:

Azure Multifactor Authentication

Two-step verification is a method of authentication that requires more than one verification method and adds a critical second layer of security to user sign-ins and transactions. It works by requiring any two or more of the following verification methods:

Something you know (typically a password)
Something you have (a trusted device that is not easily duplicated, like a phone)
Something you are (biometrics)

Azure Multi-Factor Authentication (MFA) is Microsoft's two-step verification solution. Azure MFA helps safeguard access to data and applications while meeting user demand for a simple sign-in process. It delivers strong authentication via a range of verification methods, including phone call, text message, or mobile app verification.

For those users providing managed services out of the context of a managed services cloud service provider it's an increase to the service level, confidence and trust to and of the receiving customer. It indicates the managed service provider has implemented the right measures to authenticate and preserve access to the users that will provide these managed services within the customer environments.

Enabling multi factor authentication within the CSP partner environment required the following activities:

Enable Azure AD Premium on the partner Azure AD, which comes with a cost
Each partner Azure AD has its own MFA information
MFA enablement is on a per user base where phone number and email address can be prefilled within the partner Azure AD (per partner AD)
Once the user is enabled for MFA, next logon will setup MFA for the user (per partner AD)
No actions are required within the customer Azure AD or CSP provisioned Azure subscriptions.

Privileged Access Management

Privileged Access Management (PAM) is a solution that helps organizations restrict privileged access within an existing Active Directory environment. Privileged Access Management isolate the use of privileged accounts to reduce the risk of those credentials being stolen

A real concern for enterprises today is resource access within an Active Directory environment. Particularly troubling is news about vulnerabilities, unauthorized privilege escalations, and other types of unauthorized access including pass-the-hash, pass-the-ticket, spear phishing, and Kerberos compromises.

Today, it's too easy for attackers to obtain Domain Admins account credentials, and it's too hard to discover these attacks after the fact. The goal of PAM is to reduce opportunities for malicious users to get access, while increasing your control and awareness of the environment.

PAM makes it harder for attackers to penetrate a network and obtain privileged account access. PAM adds protection to privileged groups that control access across a range of domain-joined computers and applications on those computers. It also adds more monitoring, more visibility, and more fine-grained controls so that organizations can see who their privileged administrators are and what are they doing. PAM gives organizations more insight into how administrative accounts are used in the environment.

PAM builds on the principle of just-in-time administration, which relates to just enough administration (JEA). In JEA, an administrator decides that users with a certain privilege can perform a certain task. Every time an eligible user needs to perform that task, they enable that permission. The permissions expire after a specified time period, so that a malicious user can't steal the access.

PAM is an instance of Privileged Identity Management (PIM) that is implemented using Microsoft Identity Manager (MIM).

The combination of on-premise to Azure AD synchronization, the group and role synchronization, and by setting up a structure of different "special" groups aligned with higher and lower privileged roles within the CSP provisioned Azure subscription PAM is accomplished with a managed service CSP partner environment.

Comments

Anonymous
July 06, 2017
Great whitepaper Robert! This will really help us!I've tried to follow this guide but running into the following problem:I can create external users in the tenants directory (direct or via the guest invitor) and assign them roles (Global admin, exchange admin,...). Using accounts from the csp partner directory as external users is also possible. When I assign the helpdesk agent role (in CSP) the user can enter the tenants admin portals via the direct links in the partnercenter.But the additional assigned rights in the tenant won't take effect - the user is still an helpdesk agent.Do you have any idea what's my problem?

次の方法で共有