Edit

Share via

To identity and beyond—One architect's viewpoint

  • Article

In this article, Alex Shteynberg, Principal Technical Architect at Microsoft, discusses top design strategies for enterprise organizations adopting Microsoft 365 and other Microsoft cloud services.

About the author

Alex Shteynberg photo.

I'm a Principal Technical Architect at the New York Microsoft Technology Center. I mostly work with large customers and complex requirements. My viewpoint and opinions are based on these interactions and might not apply to every situation. However, in my experience, if we can help customers with the most complex challenges, we can help all customers.

I typically work with 100+ customers each year. While every organization has unique characteristics, it's interesting to see trends and commonalities. For example, one trend is cross-industry interest for many customers. After all, a bank branch can also be a coffee shop and a community center.

In my role, I focus on helping customers arrive at the best technical solution to address their unique set of business goals. Officially, I focus on Identity, Security, Privacy, and Compliance. I love the fact that these touch everything we do. It gives me an opportunity to be involved with most projects. This activity keeps me busy and enjoying this role.

I live in New York City (the best!) and really enjoy the diversity of its culture, food, and people (not traffic). I love to travel when I can and hope to see most of the world in my lifetime. I'm currently researching a trip to Africa to learn about wildlife.

Guiding principles

  • Simple is often better: You can do (almost) anything with technology, but it doesn't mean you should. Especially in the security space, many customers overengineer solutions. I like this video from Google's Stripe conference to underscore this point.
  • People, process, technology: Design for people to enhance process, not tech first. There are no "perfect" solutions. We need to balance various risk factors and decisions that might be different for each business. Too many customers design an approach that their users later avoid.
  • Focus on 'why' first and 'how' later: Be the annoying 7-yr old kid with a million questions. We can't arrive at the right answer if we don't know the right questions to ask. Lots of customers make assumptions on how things need to work instead of defining the business problem. There are always multiple paths that can be taken.
  • Long tail of past best practices: Recognize that best practices are changing at light speed. If you looked at Microsoft Entra more than three months ago, you're likely out of date. Everything here's subject to change after publication. "Best" option today might not be the same six months from now.

Baseline concepts

Don't skip this section. I often find that I must step-back to these articles, even for customers who have been using cloud services for years. Alas, language isn't a precise tool. We often use the same word to mean different concepts or different words to mean the same concept. I often use the following diagram to establish some baseline terminology and "hierarchy model."

Illustration of tenant, subscription, service, and data.

When you learn to swim, it's better to start in the pool and not in the middle of the ocean. I'm not trying to be technically accurate with this diagram. It's a model to discuss some basic concepts.

In the diagram:

  • Tenant = an instance of Microsoft Entra ID. It's at the "top" of a hierarchy, or Level 1 in the diagram. We can consider this level to be the "boundary" where everything else occurs (Microsoft Entra B2B aside). All Microsoft enterprise cloud services are part of one of these tenants. Consumer services are separate. "Tenant" appears in documentation as Microsoft 365 tenant, Azure tenant, WVD tenant, and so on. I often find these variations cause confusion for customers.
  • Services/subscriptions, Level 2 in the diagram, belong to one and only one tenant. Most SaaS services are 1:1 and can't move without migration. Azure is different, you can move billing and/or a subscription to another tenant. There are many customers that need to move Azure subscriptions. This scenario has various implications. Objects that exist outside of the subscription don't move. For example, role-based access control (Azure RBAC), Microsoft Entra objects (groups, apps, policies, etc.), and some services (Azure Key Vault, Data Bricks, etc.). Don't migrate services without a good business need. Some scripts that can be helpful for migration are shared on GitHub.
  • A given service usually has some sort of "sublevel" boundary, or Level 3 (L3). This boundary is useful to understand for segregation of security, policies, governance, and so on. Unfortunately, there's no uniform name that I know of. Some examples names for L3 are: Azure Subscription = resource; Dynamics 365 CE = instance; Power BI = workspace; Power Apps = environment; and so on.
  • Level 4 is where the actual data lives. This 'data plane' is a complex article. Some services are using Microsoft Entra ID for RBAC, others aren't. I'll discuss it a bit when we get to delegation articles.

Some other concepts that I find many customers (and Microsoft employees) are confused about or have questions about include the following issues:

  • Anyone can create many tenants at no cost. You don't need a service provisioned within it. I have dozens. Each Tenant name is unique in Microsoft's worldwide cloud service (in other words, no two tenants can have the same name). They're all in the format of TenantName.onmicrosoft.com. There are also processes that create Tenants automatically (unmanaged tenants). For example, this result can happen when a user signs up for an enterprise service with an email domain that doesn't exist in any other tenant.
  • In a managed tenant, many DNS domains can be registered in it. This result doesn't change the original tenant name. There's currently no easy way to rename a tenant (other than migration). Although the tenant name is technically not critical these days, some people might feel limited by this reality.
  • You should reserve a tenant name for your organization even if you aren't yet planning to deploy any services. Otherwise somebody can take it from you and there's no simple process to take it back (same problem as DNS names). I hear this way too often from customers. What your tenant name should be is a debate article as well.
  • If you own DNS namespace, you should add all of these namespaces to your tenants. Otherwise one could create an unmanaged tenant with this name, which then causes disruption to make it managed.
  • A DNS namespace (for example, contoso.com) can belong to one and only one Tenant. This requirement has implications for various scenarios (for example, sharing an email domain during a merger or acquisition, and so on). There's a way to register a DNS sub (such as div.contoso.com) in a different tenant, but that should be avoided. By registering a top-level domain name, all subdomains are assumed to belong to the same tenant. In multi-tenant scenarios (as explained next) I would normally recommend using another top-level domain name (such as contoso.ch or ch-contoso.com).
  • Who should "own" a tenant? I often see customers that don't know who currently owns their tenant. This lack of knowledge is a significant red flag. Call Microsoft support ASAP. Just as problematic is when a service owner (often an Exchange administrator) is designated to manage a tenant. The tenant contains all services that you might want in the future. The tenant owner should be a group that can make decision for enablement of all cloud services in an organization. Another problem is when a tenant owner group is asked to manage all services. This method doesn't scale for large organizations.
  • There's no concept of a sub/super tenant. For some reason, this myth keeps repeating itself. This concept applies to Azure Active Directory B2C tenants as well. I hear too many times, "My B2C environment is in my XYZ Tenant," or "How do I move my Azure tenant into my Microsoft 365 tenant?"
  • This document mostly focuses on the commercial worldwide cloud, because that's what most customers are using. It sometimes useful to know about sovereign clouds. Sovereign clouds have other implications to discuss which are out of scope for this discussion.

Baseline identity articles

There's much documentation about Microsoft's identity platform – Microsoft Entra ID. For people who are just starting, it often feels overwhelming. Even after you learn about it, keeping up with constant innovation and change can be challenging. In my customer interactions, I often find myself serving as "translator" between business goals and "Good, Better, Best" approaches to address these concerns (and human "cliff notes" for these articles). There's rarely a perfect answer and the "right" decision is a balance of various risk factors. Up next are some of the common questions and confusion areas I tend to discuss with customers.

Provisioning

Microsoft Entra ID doesn't solve for lack of governance in your identity world! Identity governance should be a critical element independent of any cloud decisions. Governance requirements change over time, which is why it's a program and not a tool.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) vs. something else (third party or custom)? Save yourself problems now and in the future and go with Microsoft Entra Connect. There are all kinds of smarts in this tool to address peculiar customer configurations and ongoing innovations.

Some edge cases that might drive towards a more complex architecture:

  • I have multiple AD forests without network connectivity between them. There's a new option called Cloud Provisioning.
  • I don't have Active Directory, nor do I want to install it. Microsoft Entra Connect can be configures to sync from LDAP (partner might be required).
  • I need to provision the same objects to multiple tenants. This scenario isn't technically supported but depends on definition of "same."

Should I customize default synchronization rules (filter objects, change attributes, alternate login ID, and so on)? Avoid it! An identity platform is only as valuable as the services that use it. While you can do all kinds of nutty configurations, to answer this question you need to look at the effect on applications. If you filter mail-enabled objects, then the GAL for online services is incomplete; if the application relies on specific attributes, filtering on these attributes has unpredictable effects; and so on. It's not an identity team decision.

XYZ SaaS supports Just-in-Time (JIT) provisioning, why are you requiring me to synchronize? See the previous paragraph. Many applications need "profile" information for functionality. You can't have a GAL if all mail-enabled objects aren't available. Same applies to user provisioning in applications integrated with Microsoft Entra ID.

Authentication

Password hash sync (PHS) vs. pass-through authentication (PTA) vs. federation.

Usually there's a passionate debate around federation. Simpler is usually better and therefore use PHS unless you have a good reason not to. It's also possible to configure different authentication methods for different DNS domains in the same tenant.

Some customers enable federation + PHS mainly for:

I often walk customers through client authentication flow to clarify some misconceptions. The result looks like the following picture, which isn't as good as the interactive process of getting there.

Example whiteboard conversation.

This type of whiteboard drawing illustrates where security policies are applied within the flow of an authentication request. In this example, policies enforced through Active Directory Federation Service (AD FS) are applied to the first service request, but not subsequent service requests. This behavior is at least one reason to move security controls to the cloud as much as possible.

We've been chasing the dream of single sign-on (SSO) for as long as I can remember. Some customers believe they can achieve single sign-on by choosing the "right" federation (STS) provider. Microsoft Entra ID can help significantly to enable SSO capabilities, but no STS is magical. There are too many "legacy" authentication methods that are still used for critical applications. Extending Microsoft Entra ID with partner solutions can address many of these scenarios. SSO is a strategy and a journey. You can't get there without moving towards standards for applications. Related to this article is a journey to passwordless authentication, which also doesn't have a magical answer.

Multifactor authentication (MFA) is essential today (here for more). Add to it user behavior analytics and you have a solution that prevents most common cyber-attacks. Even consumer services are moving to require MFA. Yet, I still meet with many customers who don't want to move to modern authentication approaches. The biggest argument I hear is that it impacts users and legacy applications. Sometimes a good kick might help customers move along - Exchange Online announced changes. Lots of Microsoft Entra reports are now available to help customers with this transition.

Authorization

Per Wikipedia, "to authorize" is to define an access policy. Many people look at it as the ability to define access controls to an object (file, service, and so on). In the current world of cyber threats, this concept is rapidly evolving to a dynamic policy that can react to various threat vectors and quickly adjust access controls in response to them. For example, if I access my bank account from an unusual location, I get extra confirmation steps. To approach this reality, we need to consider not just the policy itself but the ecosystem of threat detection and signal correlation methodologies.

The policy engine of Microsoft Entra ID is implemented using Conditional Access policies. This system depends on information from other threat detection systems to make dynamic decisions. A simple view would be something like the following illustration:

Policy engine in Microsoft Entra ID.

Combining all these signals together allows for dynamic policies like these:

  • If a threat is detected on your device, your access to data is reduced to web only without the ability to download.
  • If you're downloading an unusually high volume of data, anything you download is encrypted and restricted.
  • If you access a service from an unmanaged device, you're be blocked from highly sensitive data but allowed to access nonrestricted data without the ability to copy it to another location.

If you agree with this expanded definition of authorization, then you need to implement additional solutions. Which solutions you implement depends on how dynamic you want the policy to be and which threats you want to prioritize. Some examples of such systems are:

In addition to Microsoft Entra ID, various services and applications have their own specific authorization models. Some of these models are discussed later in the delegation section.

Audit

Microsoft Entra ID has detailed audit and reporting capabilities. However, these reports are typically not the only source of information needed to make security decisions. See more discussion on this subject in the delegation section.

There's no Exchange

Don't Panic! Exchange isn't being deprecated (or SharePoint, and so on). It's still a core service. What I mean is, for quite some time now, technology providers have been transitioning user experiences (UX) to encompass components of multiple services. In Microsoft 365, a simple example is "modern attachments" where attachments to email are stored in SharePoint Online or OneDrive.

Attaching a file to an email.

Looking at the Outlook client you can see many services that are "connected" as part of this experience, not just Exchange. Examples include Microsoft Entra ID, Microsoft Search, Apps, Profile, compliance, and Microsoft 365 groups.

Outlook interface with callouts.

Read about Microsoft Fluid Framework for preview of upcoming capabilities. In preview now, I can read and reply to Teams conversations directly in Outlook. In fact, the Teams client is one of the more prominent examples of this strategy.

Overall, it's becoming harder to draw a clear line between Microsoft 365 and other services in Microsoft clouds. I view it as a great benefit to customers since they can benefit from total innovation across everything we do even if they use one component. Pretty cool and has far reaching implications for many customers.

Today, I find many customer IT groups are structured around "products." It's logical for an on-premises world since you need an expert for each specific product. However, I'm happy that I don't have to debug an Active Directory or Exchange database ever again as these services have moved to the cloud. Automation (which the cloud basically is) removes certain repetitive manual jobs (look what happened to factories). However, these tasks are replaced with more complex requirements to understand cross-services interaction, effect, business needs, and so on. If you're willing to learn, there are great opportunities enabled by cloud transformation. Before jumping into technology, I often talk to customers about managing change in IT skills and team structures.

To all SharePoint fan-people and developers, please stop asking "How can I do XYZ in SharePoint Online?" Use Power Automate (or Flow) for workflow, it's a much more powerful platform. Use Azure Bot Framework to create a better UX for your 500-K item list. Start using Microsoft Graph instead of CSOM. Microsoft Teams includes SharePoint but also a world more. There are many other examples I can list. There's a vast and wonderful universe out there. Open the door and start exploring.

The other common effect is in the compliance area. This cross-services approach seems to completely confuse many compliance policies. I keep seeing organizations that state, "I need to journal all email communications to an eDiscovery system." What does this statement really mean when email is no longer just email but a window into other services? Microsoft 365 has a comprehensive approach for compliance, but changing people and processes are often much more difficult than technology.

There are many other people and process implications. In my opinion, this factor is a critical and under-discussed area. Perhaps more in another article.

Tenant structure options

Single tenant vs. multi-tenant

In general, most customers should have only one production tenant. There are many reasons why multiple tenants are challenging (give it a Bing search) or read this whitepaper. At the same time, many enterprise customers I work with have another (small) tenant for IT learning, testing, and experimentation. Cross-tenant Azure access is made easier with Azure Lighthouse. Microsoft 365 and many other SaaS services have limits for cross-tenant scenarios. There's a lot to consider in Microsoft Entra B2B scenarios.

Many customers end-up with multiple production tenants after a merger and acquisition (M&A) and want to consolidate. Today that's not simple and would require Microsoft Consulting Services (MCS) or a partner plus third-party software. There's ongoing engineering work to address various scenarios with multi-tenant customers in the future.

Some customers choose to go with more than one tenant. This should be a careful decision and almost always business reason driven! Some examples include the following reasons:

  • A holding type company structure where easy collaboration between different entities isn't required and there's strong administrative and other isolation needs.
  • After an acquisition, a business decision is made to keep two entities separate.
  • Simulation of a customer's environment that doesn't change the customer's production environment.
  • Development of software for customers.

In these multi-tenant scenarios, customers often want to keep some configuration the same across tenants, or report on configuration changes and drifts. This often means moving from manual changes to configuration as code. Microsoft Premiere support offers a workshop for these types of requirements based on this public IP: https://Microsoft365dsc.com.

Multi-Geo

To Multi-Geo or not to Multi-Geo. That is the question. With Microsoft 365 Multi-Geo, you can provision and store data at rest in the geo locations you choose to meet data residency requirements. There are many misconceptions about this capability. Keep the following points in mind:

  • It doesn't to provide performance benefits. It could make performance worse if the network design isn't correct. Get devices "close" to the Microsoft network, not necessarily to your data.
  • It's not a solution for GDPR compliance. GDPR doesn't focus on data sovereignty or storage locations. There are other compliance frameworks for data sovereignty or storage locations.
  • It doesn't solve delegation of administration (see below) or information barriers.
  • It isn't the same as multi-tenant and requires more user provisioning workflows.
  • It doesn't move your tenant (your Microsoft Entra ID) to another geography.

Delegation of administration

In most large organizations, separation of duties and role-based access control (RBAC) is a necessary reality. I'm going to apologize ahead of time. This activity isn't as simple as some customers want it to be. Customer, legal, compliance, and other requirements are different and sometimes conflicting around the world. Simplicity and flexibility are often on opposite sides of each other. Don't get me wrong, we can do a better job at this goal. There have been (and will be) significant improvements over time. Visit your local Microsoft Technology Center to work out the model that fits your business requirements without reading 379,230 docs! Here, I focus on what you should think about and not why it's this way. Coming up are five different areas to plan for and some of the common questions I encounter.

Microsoft Entra ID and Microsoft 365 admin centers

There's a long and growing list of built-in roles. Each role consists of a list of role permissions grouped together to allow specific actions to be performed. You can see these permissions in the "Description" tab inside each role. Alternatively, you can see a more human readable version of these permissions in the Microsoft 365 Admin Center. The definitions for built-in roles can't be modified. I generally, group these roles into three categories:

  • Global administrator: This "all powerful" role should be highly protected just like you would in other systems. Typical recommendations include: no permanent assignment and use Microsoft Entra Privileged Identity Management (PIM); strong authentication; and so on. Interestingly, this role doesn't give you access to everything by default. Typically, I see confusion about compliance access and Azure access, discussed later. However, this role can always assign access to other services in the tenant.
  • Specific service admins: Some services (Exchange, SharePoint, Power BI, and so on) consume high-level administration roles from Microsoft Entra ID. This behavior isn't consistent across all services and there are more service-specific roles discussed later.
  • Functional: There's a long (and growing) list of roles focused on specific operations (guest inviter, and so on). Periodically, more of these roles are added based on customer needs.

It's not possible to delegate everything (although the gap is decreasing), which means the Global admin role would need to be used sometimes. Configuration-as-code and automation should be considered instead of people membership of this role.

Note: The Microsoft 365 admin center has a more user-friendly interface but has subset of capabilities compared to the Microsoft Entra admin experience. Both portals use the same Microsoft Entra roles, so changes are occurring in the same place. Tip: if you want an identity-management focused admin UI without all the Azure clutter, use https://aad.portal.azure.com.

What's in the name? Don't make assumptions from the name of the role. Language isn't a precise tool. The goal should be to define operations that need to be delegated before looking at what roles are needed. Adding somebody to the "Security Reader" role doesn't make them see security settings across everything.

The ability to create custom roles is a common question. This capability is limited in Microsoft Entra today (as explained later), but will grow in capabilities over time. I think of these custom roles as applicable to functions in Microsoft Entra ID and might not span "down" the hierarchy model (as previously discussed). Whenever I deal with "custom," I tend to go back to my principal of "simple is better."

Another common question is ability to scope roles to a subset of a directory. One example is something like "Helpdesk Administrator for users in EU only." Administrative Units are intended to address this scenario. As previously described, I think of these scopes as applicable to functions in Microsoft Entra ID and might not span "down." Certain roles don't make sense to scope (global admins, service admins, and so on).

Today, all these roles require direct membership (or dynamic assignment if you use Microsoft Entra PIM). This means customers must manage these role directly in Microsoft Entra ID, and these roles can't be based on a security group membership. I'm not a fan of creating scripts to manage these roles as it would need to run with elevated rights. I generally recommend API integration with process systems like ServiceNow or using partner governance tools like Saviynt. There's engineering work going on to address this issue over time.

I mentioned Microsoft Entra PIM a few times. There's a corresponding Microsoft Identity Manager (MIM) Privileged Access Management (PAM) solution for on-premises controls. You might also want to look at Privileged Access Workstations (PAWs) and Microsoft Entra ID Governance. There are various third-party tools as well, which can enable just-in-time, just-enough, and dynamic role elevation. This capability is usually part of a larger discussion for securing an environment.

Sometimes scenarios call for adding an external user to a role (see the previous multi-tenant section). This outcome works fine. Microsoft Entra B2B is another large and fun article to walk customers through, perhaps in another article.

Microsoft Defender XDR and Microsoft 365 Purview compliance portals

Email & Collaboration roles in the Microsoft Defender portal and *Role groups for Microsoft Purview solutions in the Microsoft 365 Purview compliance portal are a collection of "role groups", which are separate and distinct from Microsoft Entra roles. This can be confusing because some of these role groups have the same name as Microsoft Entra roles (for example, Security Reader), yet they can have different membership. I prefer the use of Microsoft Entra roles. Each role group consists of one or more "roles" (see what I mean about reusing the same word?) and have members from Microsoft Entra ID, which are email enabled objects. Also, you can create a role group with the same name as a role, which might or might not contain that role (avoid this confusion).

In a sense, these permissions are an evolution of the Exchange role groups model. However, Exchange Online has its own role group management interface. Some role groups in Exchange Online are locked and managed from Microsoft Entra ID or the Microsoft Defender XDR and Microsoft 365 Purview compliance portals, but others might have the same or similar names and are managed in Exchange Online (adding to the confusion). I recommend you avoid using the Exchange Online user interface unless you need scopes for Exchange management.

You can't create custom roles. Roles are defined by services created by Microsoft and continue to grow as new services are introduced. This behavior is similar in concept to roles defined by applications in Microsoft Entra ID. When new services are enabled, often new role groups need to be created in order to grant or delegate access to these (for example, insider risk management.

These role groups also require direct membership and can't contain Microsoft Entra groups. Unfortunately, today these role groups aren't supported by Microsoft Entra PIM. Like Microsoft Entra roles, I tend to recommend management of these role groups through APIs or a partner governance product like Saviynt, or others.

Microsoft Defender portal and Microsoft 365 Purview compliance portal roles span Microsoft 365 and you can't scope these role groups to a subset of the environment (like you can with administrative units in Microsoft Entra ID). Many customers ask how they can subdelegate. For example, "create a DLP policy only for EU users." Today, if you have rights to a specific function in the Microsoft Defender XDR and Microsoft 365 Purview compliance portals, you have rights to everything covered by this function in the tenant. However, many policies have capabilities to target a subset of the environment (for example, "make these labels available only to these users"). Proper governance and communication are a key component to avoid conflicts. Some customers choose to implement a "configuration as code" approach to address subdelegation in the Microsoft Defender XDR and Microsoft 365 Purview compliance portals. Some specific services support subdelegation (see the next section).

Service Specific

As stated earlier, many customers are looking to achieve a more granular delegation model. A common example: "Manage XYZ service only for Division X users and locations" (or some other dimension). The ability to do this depends on each service and isn't consistent across services and capabilities. In-addition, each service might have a separate and unique RBAC model. Instead of discussing all of these models (which would take forever), I'm adding relevant links for each service. This list isn't complete, but it can get you started.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (../compliance/index.yml)
    • Permission Filtering - (../compliance/index.yml)
    • Compliance Boundaries - (../compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) - (../compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (../enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Note

This link is to the root of documentation. There are multiple types of services with variations in the admin/delegation model.

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      Note

      there are multiple types with variations in the admin/delegation models.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      Note: data platform security and delegation (which Power BI is a component) is a complex area.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender for Endpoint - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (../security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • Information barriers - (../compliance/information-barriers.md)

Activity Logs

Microsoft 365 has a unified audit log. It's a very detailed log, but don't read too much into the name. It might not contain everything you want or need for your security and compliance needs. Also, some customers are very interested in Audit (Premium).

Examples of Microsoft 365 logs that are accessed through other APIs include the following features:

It's important to first identify all log sources needed for a security and compliance program. Also note that different logs have different on-line retention limits.

From the admin delegation perspective, most Microsoft 365 activity logs don't have a built-in RBAC model. If you have permission to see a log, then you can see everything in it. A common example of a customer requirement is: "I want to be able to query activity only for EU users" (or some other dimension). To achieve this requirement, we need to transfer logs to another service. In the Microsoft cloud, we recommend transferring it to either Microsoft Sentinel or Log Analytics.

High level diagram:

diagram of log sources for a security and compliance program.

The diagram represents built-in capabilities to send logs to Event Hubs and/or Azure Storage and/or Azure Log Analytics. Not all systems include this out-of-the-box yet. But there are other approaches to send these logs to the same repository. For example, see Protecting your Teams with Microsoft Sentinel.

Combining all the logs into one storage location includes added benefit, such as cross-correlations, custom retention times, augmenting with data needed to support RBAC model, and so on. Once data is in this storage system, you can create a Power BI dashboard (or another type of visualization) with an appropriate RBAC model.

Logs don't have to be directed to one place only. It might also be beneficial to integrate Microsoft 365 Logs with Microsoft Defender for Cloud Apps or a custom RBAC model in Power BI. Different repositories have different benefits and audiences.

It's worth mentioning that there's a rich built-in analytics system for security, threats, vulnerabilities, and so on in a service called Microsoft Defender XDR.

Many large customers want to transfer this log data to a third-party system (for example, SIEM). There are different approaches for this result, but in-general Azure Event Hubs and Graph are good starting points.

Azure

I'm often asked if there's a way to separate high-privilege roles between Microsoft Entra ID, Azure, and SaaS (ex.: Global Administrator for Microsoft 365 but not Azure). Not really. Multi-tenant architecture is needed if complete administrative separation is required, but that adds significant complexity (as discussed earlier). All these services are part of the same security/identity boundary (as shown in the hierarchy model).

It's important to understand relationships between various services in the same tenant. I'm working with many customers that are building business solutions that span Azure, Microsoft 365, and Power Platform (and often also on-premises and third-party cloud services). One common example:

  1. I want to collaborate on a set of documents/images/etc (Microsoft 365)
  2. Send each one of them through an approval process (Power Platform)
  3. After all components are approved, assemble these items into a unified deliverable(s) (Azure) Microsoft Graph API is your best friend here. Not impossible, but significantly more complex to design a solution spanning multiple tenants.

Azure Role-Based Access Control (RBAC) enables fine-grained access management for Azure. Using RBAC, you can manage access to resources by granting users the fewest permissions needed to perform their jobs. Details are out of scope for this document, but for more information on RBAC, see What is role-based access control (RBAC) in Azure? RBAC is important but only part of the governance considerations for Azure. Cloud Adoption Framework is a great starting point to learn more. I like how my friend, Andres Ravinet, walks customers step by step through various components to decide on the approach. High-level view for various elements (not as good as the process to get to actual customer model) is something like this:

High-level view of Azure components for delegated administration.

As you can see from above picture, many other services should be considered as part of the design (ex.: Azure Policies, Azure Blueprints, Management Groups, and so on).

Conclusion

This article started as a short summary, ended-up longer than I expected. I hope you're now ready to venture into a deep see of creating delegation model for your organization. This conversation is very common with customers. There's no one model that works for everyone. Waiting for a few planned improvements from Microsoft engineering before documenting common patterns we see across customers. In the meantime, you can work with your Microsoft account team to arrange a visit to the nearest Microsoft Technology Center. See you there!