One of the biggest trends in the Information Technology space for 2023 is a heightened focus on security. Each year, attackers develop new techniques and more sophisticated patterns. There are a lot of 3^rd party tools on the market that can protect workstations, servers, one cloud type, etc. Microsoft’s Defender suite of products offers something for almost all parts of an organization, and one unified suite to monitor threats, especially for Cloud Assets. Microsoft has created a “Secure Score,” a weighted score based on security best practices. This article will cover the parts that make up Microsoft Defender for Cloud and highlight their key features.

Defender for Cloud

Defender for Cloud allows the import of any number of company subscriptions in Azure and includes a Cloud Posture Assessment of all assets within it. It will then provide security recommendations as well as compliance with major control accreditations such as SOC-2. Remediating the recommendations then leads to a resultant Secure Score per subscription and overall. These recommendations often provide easy steps to remediation and can help secure the whole environment.

Most organizations in today’s modern landscape have a presence in more than one of the major clouds. Defender for Cloud also allows you to import AWS Instances and GCP Projects.  You can then can get the same sort of recommendations for either of these clouds to tighten security. Defender also offers a way to view common attack patterns and ways to prevent them. We can monitor it all from here!

Defender for Servers

Now that our clouds themselves are protected, how about the servers themselves? Defender for Servers is an add-on plan that deploys a defender agent to servers in the cloud environment and monitors them with real-time protection. We are also able to generate Vulnerability Reports and Recommendations using a built-in Qualys Scanner! These recommendations get integrated into the main list for the cloud and will be based on OS type. Yes, Defender can run on Windows or Linux VM and provide Linux vulnerabilities as well! 

Defender for Containers

Most modern application teams are designing their apps as microservices in containers.  Defender for Containers allows us to provide protection to Kubernetes Clusters in Azure Kubernetes Service (AKS) or on-premises. The same real-time protection for nodes and clusters and vulnerability assessments for images stored in Azure Container Registry (ACR) and running on AKS. Defender can also find misconfigurations in Kubernetes clusters and provide steps to fix them. 

Defender for Other Azure Services

Defender for Cloud doesn’t stop there, though!  We also can protect and assess hosted Databases and App Services. One of the biggest security items I find most customers not using is Azure Key Vault, which is a secure place to store certificates and application secrets. Defender is also able to protect this for security enhancements. Storage plans allow the securing of storage accounts, which can protect all data within. Finally, we are able to Secure Resource Manager operations, to ensure internal assets are created securely and properly each time!

Conclusion

With the recent move to the cloud, most organizations find themselves in a position where they have multiple Azure subscriptions, and possibly multiple cloud footprints. In the modern landscape, a company relies more on keeping its data safe than ever before. Most 3^rd party solutions work great for one area or one major cloud provider. Microsoft Defender for Cloud and associated features allow security and visibility into the entire environment, no matter where assets lie.

Introduction

I honestly can’t remember the last time I met with a prospective client where they didn’t bring up Automation or the term DevOps in the conversation. Both terms have become the popular buzzwords in the IT Industry over the last 5 years. It doesn’t take long for the technologies that are prevalent in this space to come up such as Ansible or Terraform. Everyone understands the basic definition of automation as having the machines do the process of building or modifying objects. But how can this be applied to an organization successfully? Let’s dive into the Automation and DevOps space and see how Azure DevOps can benefit in this endeavor. Let’s unleash our inner DevOps ninja!!!

What is DevOps?

As stated earlier, most people in the IT space are familiar with the term “DevOps”; but what does it really mean?  DevOps is often defined as the tools that make up its common solution patterns; but it is not the tools themselves, but the manner of their use. DevOps is an organization’s cultural mindset and methodology which is achieved by collaboration.

Automation Journey

Alright, so now you’re ready to get out there and automate your infrastructure in a week and go full DevOps with Infrastructure as Code and CI/DIC Pipelines, right?! Wrong!! As awesome as automation is, just like with anything, it takes time to implement organizational change. As discussed earlier, DevOps is a culture and a mindset, one of the biggest pitfalls I have seen organizations fall into, is just going all out on automation; without having a broader strategy or standardization. This leads to the creation of “technical debt”; which is defined as the “debt” incurred by IT teams by exploring the more expeditious solution to the problem, without regard to the efforts it will take to maintain the solution in the grand strategy.

An example of technical debt would be this scenario. At a large organization, they acquire another company. Because the deal signed by the business requires the integration to take place within a 30-day period, the infrastructure team forklifts all their OneDrive data, file shares, users, etc. into one big share, not following the standards of the acquiring organization. They plan to sort things into their infrastructure “later on”. The problem with this is all those users must now be treated differently than the standard users, which leads to all their issues going to the team that performed the acquisition.  

The point of the story is that we must make operational decisions today that will not adversely affect us in the future. Automation efforts must begin by outlining all the objectives, developing processes and standards, and deploying out incrementally along an automation journey. There are levels and steps along this journey; I recommend starting with Imperative Automation tools to begin with, which you probably even already use these!

Now, let’s get started on our Automation Journey. 

Imperative Automation

Our Automation Journey begins at the first stop, Imperative Automation. Imperative automation tools all involve the user defining and mapping out all the steps along the process and the task to be executed. Examples of these would be PowerShell scripts, bash scripts, cli commands, etc. (I mentioned these would be familiar!) These tools are good for one-off tasks but are heavily prone to user error. It can also take a long time to develop scripts in this manner and oftentimes requires specific knowledge about the technology. This means making one for a lot of different tasks individually, which doesn’t scale extremely well. But it’s a start! 

Declarative Automation 

Moving down the line, the next stop along our journey will be Declarative Automation. These tools allow us to describe the infrastructure and objects we want, and the tools themselves will build them. Oftentimes, these tools do not require knowledge of all the steps needed to complete the tasks themselves. Examples of Declarative Automation would be PowerShell Desired State Configuration, F5 Declarative Onboarding, etc. This usually involves a process of “pushing” a configuration from a template that then builds the configuration directly. In the pull model, a base configuration exists, and other sources “pull” from this and makes the configuration of the objects the same as the base configuration files. 

An example of the Push Model for PowerShell DSC:

The Pull Model:

Mutable vs Immutable Infrastructure 

Most people think of their infrastructure as a static platform they use to run apps or other functions within their environment. This is the classic definition of mutable infrastructure, which means static servers or platforms that are configured to stay in place indefinitely. There are obvious disadvantages to this model. In the event of a disaster event or other such malfunction may happen, it will then require an entire copy of the primary infrastructure in a highly available scenario. This model also lends itself easily to configuration drift, which means servers can fall behind on updates or may have been missed in some sort of manual task.

Immutable infrastructure is the opposite of this. It is dynamic, meaning that the infrastructure exists as code (IAC), and the actual platform can be deployed anywhere that code will execute. This methodology and workflow obfuscate the service layers to the point that only data matters. This can make any organization agile and quite “dangerous” indeed! 

Development Practices Lead to Evolution

IAC is the highest level of automation, but what does this mean exactly?  Let’s start by looking at where the concept of Infrastructure as code originated. IAC is based on Software Development Methodology, drawing a parallel Infrastructure workflow using coding best practices. The first of which is called the waterfall method and involves progress from one task to the next sequentially.

However, this proved to be inefficient, so a group of practices was created to be more flexible and lightweight, this is called Agile Methodology. These methods place a heavy focus on the product, flexibility, and collaboration within and between teams.  An example of this would be Scrum; in this Development Methodology, the primary focus is the team being able to adapt to changes in the project itself and from the client. This process usually involves a daily meeting where the team discusses their current work streams and if they are being blocked on progress and is usually facilitated by a Scrum Master.

These concepts lead to such success, Infrastructure teams began to put this process in place for deploying infrastructure. This means that all parts of infrastructure such as virtual machines, storage accounts, virtual networks, F5 load-balancers, etc. will exist as objects within a module, within a hierarchy.  Inside of an application, we see different blocks of code that correspond to functions and processes that make up how the application works:

Version Control

Let’s pause for a moment along our journey and talk about one of the pillars of IAC and good coding practices in general.  Versioning is a process where once code becomes production, it should not be altered directly as this may cause unforeseen issues.  So, when we want to make changes we pull a copy of the production down to our machine, give it a version number, make the desired changes, and finally make a pull request to have it checked back in once validated. There are many advantages to this practice as it makes changes easy to roll back and easy to review before implementation. The most common tool for this is Git, which is Open Source. It’s also important to have a safe, shared space where code is stored, this is referred to as a Repository. 

Alright now back to our journey, let’s check out Infrastructure as Code in action using one of the most popular tools!

Infrastructure as Code in Action

Terraform is a good example of this; in terraform we create .tf files and use HCL (Hashicorp Command Language) to create code that will represent actual objects and services we wish to create. The idea is to create code that is modular, we do not want to create one big file, but break it up between logical segments and smaller chunks. This is important because this code is our infrastructure, so when we modify it, our infrastructure is immutable, so objects may be created or destroyed. We can also create different. tfvars files to represent different environments or some other logical breakdown. Here is an example of how terraform works and some terraform code that builds an Azure Load-Balancer:

5 Principles of Infrastructure as Code

 

1. Systems must be easily rebuilt: It should be possible to rebuild any element of the infrastructure with very little effort 

2. Systems are Immutable: All resources should be easily created, destroyed, replaced, resized, moved, etc. 

3. Consistency is Key: all object types should be identical in configuration by function, with changes for Ips, hostnames, etc 

4. All Processes Should be Idempotent: Any action carried out in the environment should be repeatable and have the exact same results (with the obvious configuration differences) 

5. Design is Dynamic – A system and the design should be able to be easily and quickly changed 

Configuration Drift 

Most organizations that deploy servers statically have issues eventually with what is called Configuration Drift. An example of this would be if there was an issue with IIS running on a web server to fix a specific problem, it is not applied to other servers. Another example would be if IIS is manually configured by 3 different people on 3 different servers, in 3 different ways. The issue with these variations is they have not been captured and cannot be applied towards the standardization of the environment. It also involves technical debt, especially if none of the variations are documented. This is known as having a “drift” in the configuration across the environment, which leads to huge amounts of technical debt down the road, as well as a barrier to automation. 

Server Lifecycle Management for Configuration Management 

The Lifecycle of a Server: 

The best solution pattern to manage servers involves eliminating as much variance as possible.  We achieve this by first creating a base configuration or template that will be applied to all servers created using the process.  The next step is to then create sub-templates based on configuration sets, such as a web server or database server, that include the required configurations for servers in that role. This allows some flexibility, yet still maintains a consistent configuration.   

What is a CI/CID Pipeline? 

This is another term that’s been thrown around a lot in the last couple of years. But what is it and what does it mean? Let’s get into it… 

Continuous Integration 

Let’s break it down and start with the CI part and work through it. Continuous Integration is the process of integrating code changes from multiple sources into a single shared repository or project. This practice has become the best practice for software development as it touches on all the pillars of DevOps we discussed earlier, especially collaboration between teams.  Working out of one shared location has the benefits of making it way easier to detect and fix bugs, avoiding duplication of effort, reducing systemic risk, and version control.  Though it is not required, there is usually automated testing involved in this process as well.  An example of this might be a shared Azure Repository in a shared project in Azure DevOps. 

Continuous Delivery 

The CID or Continuous Delivery portion of our definition involves the entire process from start to finish.  This revolves around the principle of being able to make code changes to an application or infrastructure reliably and at any time. (Yes, this means pushing to Production, ideally the more times a day the better!). This is achieved by implementing Continuous Integration, the CID part cannot exist without the CI portion. There are many ways to achieve this, but they mostly revolve around deploying the code changes to a development environment after the build stage has completed, having automated tests that validate the deployment, then having a build artifact that has been validated. Every change is built, tested, and pushed to non-production, before going into the production environment. 

Pipeline – Putting it all together 

Alright, so now we know what CI/CID practices are, but how does the pipeline come into play? Basically, a pipeline will take advantage of the Shared project or repository used in Continuous Integration. This project or repository is used to deploy the code changes into a new build, deploy the build to non-prod, do automated testing, create the validated build artifact, then proceed onto the production changes. The pipeline comprises the technology portion and all the automated steps that take place during the process.  Popular platforms for this are Azure DevOps Pipelines or Ansible Tower Job Workflow templates. 

Orchestration – Automating those Automations 

 Now that we have automated our processes, created all our Infrastructure as code, and got our CI/CID Pipelines in place, where do we go from here?!  The answer is we scale it up even more! How we accomplish it is by creating self-service options for users or clients that run our automation in a logical order to gather a result. We could for instance have our ticketing system include form fields. The form fields could then be pushed to Ansible Tower, which would kick off a job workflow template using these variables.  Say this one was to build a new domain controller in Azure.  The server would be created in the dev tenant first, then have the configuration added using Powershell DSC module with Ansible, joined to the domain, and promoted to a dc. Once this is created, automated tests begin to verify replication is occurring properly, DNS is resolving from the new dc, and it is advertising properly.  This is then cataloged as a validated build artifact and the process begins the same tasks in the production environment.  Once the tests validate the Production dc is built and functioning properly, the last step closes the ticket and sends an email to the user containing the name and IP of the new validated domain controller. 

Stay tuned for Part 2 coming soon! Follow us for more information on our Microsoft Azure & Microsoft 365 Services!

Azure Active Directory Domain Services (AAD DS) is a cloud directory service offering from Microsoft Technologies. A Directory Service is a database that stores object information used for Identity and Access Management (IAM). Administrators and Users use this information to verify identity and access level to resources within the organization. IAM sources integrate with other applications and services, providing things like Single-Sign-On (SSO). In this article, we will discuss the Identity and Access Management Solutions from Microsoft and how these new solutions can help an organization:

• Cut Costs, manage less infrastructure, and decrease overall footprint
• Increase Efficiency
• Run legacy applications in the Azure Cloud that can’t use modern authentication methods
• So much more!

Active Directory

Active Directory Domain Services (AD DS) was released in 1999 alongside the Windows Server 2000 Edition and changed the Identity and Access Management Landscape for decades to come. The service is deployed by creating a Domain Namespace and promoting servers to be Domain Controllers. These Domain Controllers (DCs) replicate the Directory of objects, within the domain, between each device. Active Directory uses DNS/DHCP and Lightweight Directory Access Protocol (LDAP/LDAPS) to provide authentication and hostname resolution. It’s possible to run these Domain Controllers as either physical or virtualized servers. Group Policy manages servers and users by applying rules directly to users, security groups, or computers. Here is a typical reference architecture for Active Directory Domain Services (AD DS):

We can see from the diagram that Active Directory Domain Services requires a lot of infrastructure to run effectively. System Administrators must manually manage the Domain Controllers themselves and perform updates. Active Directory does not provide services like SAML or OAuth out of the box; it requires Active Directory Federated Services (ADFS) to achieve Single-Sign-on (SSO) and these other features. ADFS also requires additional server overhead and manual federation with applications and external services. 

Here is An Active Directory Domain Services Deployment with Active Directory Federated Services:

For more detailed information on Active Directory Domain Services, check out Active Directory Domain Services Overview

–

Azure Active Directory and Microsoft 365

A little less than a decade later, Microsoft released the Azure Cloud and Azure Active Directory on October 27^th, 2008. Azure Active Directory (AAD) is a Cloud-Based identity and mobile device management service that provides user account and authentication services for applications and external services. Azure Active Directory can also provide SAML and Oauth authentication capabilities for an organization from the Azure Identity Provider (IDP). Though no servers are required to run Azure AD, it does have limitations such as no Lightweight Directory Access Protocol (LDAP/LDAPS) and no traditional group policy with conditional access in place. Manage machines and users with Conditional Access Policies in the Azure Portal.

Here is a reference diagram on Azure Active Directory: 

But would this mean an organization with Active Directory would have to start from scratch in Azure Active Directory?!

Of course not!!

–

Hybrid Identity with Azure Ad Connect

With the popularity of cloud computing, most organizations find themselves in a situation where they have applications both on-premises and in the cloud. Managing users in multiple areas is very complicated and could easily cause many issues. Hybrid Identity is the solution developed by Microsoft to handle these challenges; this creates a common user identity for authentication to all resources, regardless of location. 

It is possible to utilize the current Active Directory; sync it to Azure Ad using Azure Ad Connect. Azure Ad Connect is an application that runs on-premises on a server that provides synchronization to Azure AD. This application also monitors the health of the synchronization through Azure Ad Connect Health monitoring.

There are three main types of Hybrid Identity between Active Directory Domain Services and Azure Active Directory:

1. Password Hash Synchronization: In this scenario, users’ password hashes are synced from Active Directory to Azure Active Directory as in the example:
2. Pass-Through Authentication: In this model, users authenticate with the use of a Pass-Through Authentication Agent in Azure, which then authenticates them to On-Premises Active Directory Domain Services as in this example:

• Federation with Azure Active Directory: Federation is a collection of domains that have established trust, in this case, establishing trust with Azure Active Directory. This method involves using Active Directory Federated Services (ADFS), and all user authentication occurs on-premises.

Azure Active Directory Domain Services:

Azure Active Directory Domain Services is a cloud-based Identity and Access Management solution from Microsoft. In this solution, the Domain Controllers are created, patched, etc., by Microsoft as part of a managed domain experience. Azure Active Directory is synced one way from Azure Active Directory. Azure Active Directory Domain Services provides a subset of Active Directory features for organizations, which lowers management and design complexity. 

These features include:

• LDAP/LDAPS Endpoint
• Domain Join
• Group Policy
• Kerberos/NTLM Authentication

Here’s an example of a Cloud-Only Infrastructure:

And here is one for a hybrid deployment:

Azure Active Directory Domain Services Pricing:

Azure Active Directory Domain Services prices according to the table; for more information, browse to Pricing

Identity and Access Management in the Modern Age

In modern times, technology can provide an organization with the strategic advantages they need to be successful. There has been a recent shift to a more significant number of the workforce working remotely in recent years. Many organizations have expanded their resources to the cloud during this time and are looking for remote solutions that fit their use case. Users need essential features such as Single-Sign-On (SSO) for their applications to work efficiently. It’s also crucial to evaluate the management overhead of the Identity and Access Solution for Information Technology teams within an organization, especially with moving to the cloud. Microsoft’s suite of Identity and Access Solution tools can help an organization gain that competitive advantage in the marketplace in the Modern Age.

Azure Virtual Desktop is a cloud-based Virtual Desktop Infrastructure (VDI) solution from Microsoft Technologies. It allows organizations to quickly deploy and secure Virtual Desktops for user consumption. This solution can help organizations become more efficient and cut the physical costs of infrastructure, as well as the labor required for management. As the workforce has shifted to remote work in recent years, Azure Virtual Desktop has become one of the leading solutions. This article will detail how Azure Virtual Desktop can help an organization transform its business into the future of remote work.

What is Virtual Desktop Infrastructure (VDI)?

Virtual Desktop Infrastructure or VDI provides a means of allowing remote access to either specific applications or a whole virtual desktop experience. For many years, the only way to deploy this solution was on-premises, with all physical machines at most often more than one datacenter. This evolved with technology to allow virtual servers that made up the infrastructure. In more recent years, it’s become possible to have an entirely cloud-based or hybrid model. Let’s look at what some of these architectures might look like and what makes up the modern on-premises and cloud-based VDI solutions.

Remote Desktop Services (on-premises) & Citrix

With traditional on-premises VDI, the two main competitors in the VDI space have been Microsoft Remote Desktop Services (RDS) and Citrix. For the purposes of this article, we will be focusing on Remote Desktop Services. Running an on-premises Remote Desktop Services Solution requires the following components at a minimum:

We can see from the minimum requirements there are a lot of servers! Then, for instance, say that your organization requires separate collections for specific departments due to the nature of their line of business; that will be more groups of servers. Then there’s the matter of optimizing the user experience. This usually involves a multi-tiered storage system and User-Profile Disks, which involve even more infrastructure and costs. It’s also essential to secure the deployment, perhaps by adding F5 BIG-IPs into the mix to segregate the internal users from the external users, such as in this example:

Things can quickly get quite steep cost-wise and resource-wise in the most robust on-premise virtualized environments.

Is there a more efficient, cost-effective solution?

Windows Virtual Desktop is now Azure Virtual Desktop

Recently Microsoft rebranded Windows Virtual Desktop to Azure Virtual Desktop. But the name change really isn’t the big improvement here. Azure Virtual Desktop is an Azure Cloud based Application and Desktop Virtualization Service or cloud-based VDI solution. This is a platform-as-a-service (PaaS) offering, which means that administrators don’t have to maintain any Connection Brokers, Gateway servers, etc. One of the best features is that most organizations already have most of the licensing; more on that later!

Azure Virtual Desktop Requirements

The following items are required for Azure Virtual Desktop:

1. Azure Active Directory
2. Active Directory Synced to AAD or Azure Active Directory Domain Services (optional but either is recommended over Azure AD only)
3. Users must be sourced from the same AD or AAD DS in the same tenant, AVD does not support B2B or MSA accounts
4. Host machines must be joined to AD, AAD, or AAD DS
5. Connectivity from the Azure Virtual Desktop subnets and the authentication source

Azure Virtual Desktop Components

Azure Virtual Desktop is made up of 4 main components:

1. Host Pools – Pools of Azure Virtual Machines that run as Remote Desktop Services Session Hosts, running the Azure Virtual Desktop Agent.  These are the only Virtual Machines that must be maintained and administered for the deployment. There are two types of Host Pools
   1. Personal – each host is given to an individual user; these would be considered persistent
   2. Pooled – session hosts can accept connections from any user authorized to an app group in the pool, these would be considered nonpersistent
2. Application Groups – logical grouping of applications installed on session hosts in the host pool There are two types of App Groups:
   1. RemoteApp – where users access RemoteApps individually that are published to the App Group
   2. Desktop – users access a full desktop
3. Workspaces – A workspace is a logical grouping of application groups in Azure Virtual Desktop
4. User Profile Storage – This is needed for Pooled host pools to retain user state. Learn more about User Profile Containers and Storage

FSLogix User Profile Containers

Here is one example reference architecture from Microsoft that includes Active Directory and Storage:

Azure Virtual Desktop Pricing

Alright, at this point, the reader must be asking themselves, “This sounds great, but….how much is this all going to cost?”

Azure Virtual Desktop usage is charged in several places:

1. Licenses are required to run Windows 10/11 multi-session but are included with any Microsoft 365 E3 or E5 subscription.  If your organization already has one, then you’re already set here!
2. Session Host Instances follow the same usage pricing as all Instances, by their hourly uptime
3. It’s possible to save big here by reserving the instances upfront for 1 to 3 years.

Azure Virtual Desktop Cost Calculator

Check out the Pricing Calculator to get an estimate of what it would take to run this solution for your organization.

Azure Virtual Desktop Experience Estimator

Another tool Microsoft offers is the Azure Virtual Desktop Experience Estimator

This tool will allow engineers to estimate the user experience when connecting to Azure Virtual Desktop.

Future of Remote Work

In today’s fast-paced work environment, organizations with the edge in technology have the edge in the marketplace. Being able to adapt to changes in the workforce and market trends are the cornerstones of organizational success. With the recent shift to remote working, more strain has been placed on IT teams to deliver secure, convenient solutions to end-users. In the past, this involved running, maintaining, and administrating a whole lot of infrastructure.

Providing these services and solutions has never been easier than with the development of Cloud-Based Virtual Desktop Infrastructure (VDI).

Azure Virtual Desktop may possibly be the future of remote work.

Secure Collaboration with Other Organizations – Enable Guest Screen Sharing & Control

It is essential to have a convenient means of collaboration with other organizations in today’s modern workplace. In recent years, the workflow has shifted to a remote model to ensure security and efficient administration. Most organizations already utilizing the Microsoft suite of technologies turn to Microsoft Teams to handle this workload.

Even if you’ve got Microsoft Teams set up in your organization, you may still have questions, especially once guests are added. What are the options to collaborate with guest and external users in Microsoft Teams? How does an organization set this up in the most efficient manner? If you’ve used Microsoft Teams you may have run into the inability to share your screen and or control someone else’s screen – Why can’t I share my screen in Microsoft Teams?

This article will cover the setup of Guest User Collaboration in Microsoft Teams, which will allow your participants to share their screens as well as control yours if you approve the request.

Azure Active Directory External Collaboration Settings 

Allowing guest users to collaborate with an organization requires setup in a few places:

1. The organization subscription must have at least Azure Premium P1 Licensing for Azure Active Directory 

1. For more information on Azure AD features check out Azure Active Directory Licensing 

2. For more information on Enterprise Licensing check out Compare Microsoft 365 Enterprise Plans 

2. Microsoft 365 guest sharing’s highest level of permissions are B2B External Collaboration in Azure Active Directory 

1. Log into the Azure Portal  

2. Browse to Azure Active Directory and Select “External Identities” 

3. On the next External Identities | Overview Screen select External Collaboration Settings 

4. From the External Collaboration Settings, set your organization settings for Guest User Access as required 

Guest Access Reviews in Azure Active Directory 

With all access to Azure Active Directory, it is possible to set up Access Reviews globally for all guest users (with Azure Ad Premium P2). These reviews can allow administrators, sponsors, or guests to govern who currently has guest access to the organization. It is also possible to set these reviews up for Directory Roles and in many different Identity Governance Scenarios. Please see Manage guest Access with Azure AD access reviews for more information on various scenarios.

Microsoft 365 Groups guest settings 

Microsoft Teams requires Microsoft 365 groups for guest membership management. Enable Groups Guest Settings to allow guest users in Microsoft 365 groups. 

1. Browse to the Microsoft 365 Admin Center 

2. Expand the Settings Tab and Select Org Settings 

3. Browse down the options and find Microsoft 365 Groups; select it 

4. On the Blade that appears select the box next to the first option 

5. Select the 2^nd option based on organizational requirements 

Sharepoint organization level sharing settings 

Content in Microsoft 365 is all stored in Sharepoint. Sharing at the Sharepoint Level is required to enable content sharing with guests in Microsoft Teams. 

1. Browse to the Microsoft 365 Admin Center and Select Sharepoint 

2. Expand the Policies Tab and select Sharing 

3. From set your External Sharing Permissive levels, it must be at least Existing Guests to allow Guests to collaborate 

4. Note: It is possible to provide more granular restrictions for Guest and external sharing in Sharepoint and Onedrive 

1. For more information check out Sharepoint: External Sharing Overview 

Allow Guest User Access in Teams 

The other prerequisite to allow Guest User Access in Microsoft Teams is to turn it on globally in the tenant 

1. Browse to the  Teams Admin Center 

2. Expand the Users Tab and select Guest Access 

3. Set the Allow Guest Access in Teams to On 

4. Adjust the other settings as needed by organizational requirements 

Allowing Guest Users to Request Control by Global-Org Wide Policy 

The first and easiest method to enable this functionality is to allow Guest Users to Request/Give Control by a Global-Org Wide Policy: 

1. Browse to the Teams Admin Center and log in 
2. Expand the tab for Meetings and Select Meeting Policies:

3. On this page select Global (Org-Wide Default): 

4. Find the Section for Content Sharing and the Setting “Allow an external participant to give or request control”, switch this to on 

5. Now all guest users in the organization should have access to Request/Give Control in Screen-sharing 

For more information, check out Microsoft Teams Guest Setup  

Allowing Guest Users to Request Control by Teams Policy for Guest Users 

If we want to be more granular about controlling this feature for guest users, we can do so by assigning the policy at the team level: 

1. Browse to the Teams Admin Center and log in 

2. Expand the Teams Tab and Select Manage teams 

3. From here select +Add, give the new team a name and select apply 

4. Then select the team just created and click +Add.  On the blade that opens, search for and select guest users to add to the team, then select apply 

5. Now expand the Meetings Tab and Select Meeting Policies 

6. Click +Add, give the policy a name, browse to the Content Sharing Section and turn on Allow an External Participant to give or request control. Set other organizationally required settings and select save 

7. Finally select the Group Policy Assignment tab, +Add Group, Select the team and policy created earlier and select apply 

Note: It is possible to manage this new teams group membership via Azure Portal, Microsoft 365 Admin Center, or in the Teams Admin Center 

Guest Users vs External Users (Federation) 

In this article, we have discussed collaboration in Microsoft Teams through Guest User Access. However, there is a second means of collaboration—this uses External users and Federation. Microsoft defines the difference as the following: 

• External access - A type of federation that allows users to find, call, and chat with people in other organizations. These people cannot be added to teams unless they are invited as guests. 
• Guest access - Guest access allows you to invite people from outside your organization to join a team. Invited people get a guest account in Azure Active Directory. 

As far as Federation, there are three methods: 

1. Open Federation – this allows all organizations to find your organizational users and teams 

2. Allow Specific Domains: Negative Model allowing Specific Domains 

3. Block Specific Domains: Positive model, disallow specific domains 

Since external access does not allow access to Microsoft Teams resources, it is only recommended in specific scenarios, as it allows an entire domain instead of just single users. For more information, check out Use guest access and external access to collaborate with people outside your organization.

If you need expert assistance with Microsoft Teams—LiftCloud offers enterprise-class Microsoft Azure & Microsoft 365 Professional Services / Consulting and options for emergency support through our Always-On program. Our engineers combine extensive experience in the application delivery and security space with broad expertise in the Linux and open-source community.