Here’s my session from the RSA Cyber Security Conference in 2019 on Zero Trust. Enjoy!
Did you know Azure Active Directory can provide Single Sign-On (SSO) to G-Suite (Google Apps)? In this blog, we will explore how to set this up from both the Azure AD side and also the G-Suite side.
Once SSO is configured, consider creating policies for Conditional Access to govern how G-Suite is accessed (e.g. only from a managed device, specific network, monitor for threats of the credentials such as for sale on the dark web, etc). For more information on G-Suite and Azure AD integration for SSO, see Tutorial: Azure Active Directory integration with G Suite
Note: SSO for up to 10 apps comes with the free version of AzureAD. For additional capability, P1 or P2 may be required. See Azure Active Directory pricing for more information.
Also Important: Once SSO is enabled in G-Suite only Azure AD credentials will be authorized and all legacy credentials (i.e. G-Suite credentials) will not be authorized for sign-in. If the user is using a Windows 10 device that is AADJ, then they will not need to type in their password to access G-Suite, SSO from Win 10 will automatically be available.
Add G-Suite to Azure AD and configure it:
From within the Azure portal navigate to Azure Active Directory -> Enterprise Applications -> New Application and search for G Suite then click Add:
Once added, click Single Sign-on and click SAML
Edit the Basic SAML Configuration by clicking the pencil icon:
Configure using the following parameters:
Click Save. For User Attributes & Claims click the pencil icon:
Add a new claim:
Go back to the main SAML SSO configuration page, and download the base64 certificate for SAML Signing Certificate:
Copy the following URLs to a scratch pad, we’ll use these to configure G-Suite:
Setup G-Suite for SSO:
See this article for more information on configuring G-Suite for SSO. From within G-Suite navigate to Admin –> Security -> Setup SSO. Paste the URLs you copied in the last step, into the SSO configuration, upload the certificate you downloaded previously, check the box for use a domain specific issuer and then click Save:
Assign the user to G Suite
Back in the Azure portal, click Users & Groups from within the G-Suite Enterprise Application:
Add a new user to G-Suite:
Turn on Provisioning:
Click on Provisioning and go through the steps on the blade. Starting with changing Provisioning Mode to Automatic.
Then click Authorize and type in your G-Suite credentials to go through the authorization process. Grant consent:
Back in the Azure portal, click Save to save your provisioning configuration. Once saved, you can opt to enable automatic synchronization of identities from Azure AD to G-Suite by clicking On for Provisioning Status:
Side bar, I could configure self service for end-users!
Back in G-Suite, you will notice the assigned users will start to sync:
Time to test!
I’m going to navigate to http://mail.google.com/a/soseman.org:
Notice this will redirect to Azure Active Directory:
Notice it challenges me for multi-factor authentication!
And I respond to the challenge using my Apple Watch 🙂
Once authenticated, accept the terms and conditions:
Now, I’m logged in and ready to use G-Suite!
Browsing to myapps.microsoft.com – G-Suite is added to the launcher!
As you can see, configuring Single Sign On for G-Suite using Azure Active Directory is a rather easy and simple process – and probably can be completed within 15 minutes or less. Once configured, don’t forget using Azure AD Conditional Access to govern how G-Suite is accessed, such as requiring a managed device (mobile or PC), monitoring the credentials for being compromised (impossible travel, up for sale on dark web, coming from atypical locations,etc), requiring MFA, and more!
Do you have a business requirement to block the download of specific files or file types from OneDrive? What about detailed auditing to understand what files are downloaded or viewed? Well, today is your lucky day – because this is all possible with Microsoft security technology and takes minutes to create. I’m going to walk you through how to do this, and in return, make you look like an IT Rockstar to your organization!
Note: There are other methods to restrict those files from being synchronized using the OneDrive desktop client, we won’t cover those today however (but are accessible in the SharePoint Online Admin Portal)
IMPORTANT: Nothing is 100% secure and it’s all about defense in depth. If you want that extra ply in the tinfoil hat, I highly recommend protecting and encrypting those files with Azure Information Protection as that extra layer of protection.
Also, it’s important to note,the method below at the time of this writing is in public preview.
My organization, an engineering firm, designs buildings for their commercial and government clients. These design plans often contain additional documentation that are in the form of a .PDF and sometimes photos in the form of a .JPEG (or .jpg).
These .PDF and .JPEG files are highly confidential and thus we want to make sure they never leave OneDrive in Office 365 and can only be viewed in a web browser. In other words, we need to block the ability for an end-user to download these two file types from OneDrive. So, how do we do this?
Azure Active Directory Conditional Access and Microsoft Cloud App Security Conditional Access App Control to the rescue! These two products are part of Microsoft 365 E5 or EMS E5 or my new favorite: Microsoft 365 E3 + Identity & Threat Protection. The two products that make up this solution are Azure Active Directory and Microsoft Cloud App Security.
Let’s take a look at how to do this!
Step 1: Create a Azure AD Conditional Access Policy
From within the Azure portal -> Azure Active Directory -> Conditional Access -> New Policy I am going to create a new policy. First, give it a name, “OneDrive Block JPEG and PDF”. Next, assign it to specific users or groups of users. For testing purposes I’m assigning to Adele Vance (IMPORANT: Don’t lock yourself out! Careful planning is required when assigning to all users).
Next, add Office 365 SharePoint Online as the application to be applied to:
Under Session, select Use Conditional Access App Control, then click Done.
Next, click Enable policy to enable the policy and click Create.
Step 2: Launch OneDrive (via portal.office.com)
Wait 15 minutes for the new Conditional Access policy to propagate. Next, open a new browsing session (inprivate or on another computer) and logon as the test user that was just assigned to. In my case, I am going to sign in to portal.office.com in an in-private session as Adele. Browse to OneDrive in the Office portal and open a file in the web browser. Sign out of this web browsing session when done.
Step 3: Configure Microsoft Cloud App Security
We now need to configure Microsoft Cloud App Security (CAS) and create the appropriate policies.
To start, validate that OneDrive is a connected application by browsing to http://portal.cloudappsecurity.com and navigating to Investigate -> Connected Apps. Notice OneDrive for Business will be listed and connected: (Yes, you can also connect CAS to G-Suite, Box, and other apps!)
Next, click on Conditional Access App Control apps and OneDrive for Business will also be displayed:
Step 4: Create the Session Policy in Microsoft Cloud App Security
Next, we need to create the policy that will provide the session control when Adele uses OneDrive in the Office 365 Portal. To do this navigate to Control -> Policies, click New Policy and select Session Policy.
Let’s give the policy a name and description:
Next, under Session control type select Control file download (with DLP). Under Activity source and activity filters configure configure them per the screenshot below
Scroll down (leave content inspection blank and don’t check the box) and under Actions select Block. OPTIONAL: Configure user email notification or customize block message. When finished at the bottom of the page click Create.
Step 5: Test the User Experience
Now it’s time to test and validate this is the behavior we want. Open a new web browsing session and login as the test user. In my case, I’m going to login to portal.office365.com using Adele Vance’s account in an in-private browser session.
Once signed in, navigate to OneDrive in the Office 365 Portal. When you click on OneDrive, notice the splash page indicating this site is being monitored!
Also, notice the address of the site. It’s being proxied through CAS.MS indicating this session is being controlled by Cloud App Security:
Click Continue to Microsoft OneDrive for Business
Notice I have two files, a .PDF and a .JPEG in the OneDrive folder:
Hover the cursor over the PDF and click the ellipses, and select Download
Notice, the file download is blocked with a splash message indicating it’s blocked!
Now, I know what you’re wondering, “Matt what’s that file it wants to save?” When I open that file, it’s just a warning:
From here, within the Cloud App Security Portal, I can audit the activity and receive additional details around this attempt:
Additional alerting can be generated, with an email or SMS notification sent. Imagine having CAS send an email to your ticket system so you can be notified of this violation? What about sending to your SIEM? Endless possibilities.
As you can see, with a bit of an open mind and creativity, possibilities to build true security solutions that lead to a real business outcome, is entirely possible. The total time spent creating this solution was 10 minutes. Don’t forget to test (which obviously will add to the 10 minutes) all the scenarios for this. Questions? Let me know in the comments below!
Enjoy and help us make this world more secure! –Matt Soseman
One of the new trends in modern IT is consolidating your footprint of on-premises services you provide to the organization. For many organizations, moving those workloads to the cloud or leveraging existing cloud based services for a workload you used to do on-premises can save costs, and cut complexity out of your IT operational portfolio. The primary workload for many that is identity services such as Active Directory and to extend (or migrate) to either Azure Active Directory, Azure Active Directory Domain Services, or simply migrate your Active Directory Domain Controllers to Azure Infrastructure-as-a-Service (IaaS).
This blog will provide you a list of Microsoft resources that you may find useful in your journey of extending or moving Active Directory to the cloud. If you have comments/feedback or come across a resource that I don’t have listed below – please let me know in the comments section. Enjoy!
Starting out with Azure Active Directory:
- Understanding Office 365 identity and Azure Active Directory
- What is Azure Active Directory?
- Fundamentals of Azure identity management
- Microsoft hybrid identity solutions
- What’s the difference with Azure Active Directory free,basic,premium,P1,P2?
- Active Directory Federation Services in Azure
- Azure AD Connect: Design concepts
- Azure Active Directory Seamless Single Sign-On
- Azure AD Seamless Single Sign-On: GDPR compliance
- User sign-in with Azure Active Directory Pass-through Authentication
- Prerequisites for Azure AD Connect
- Azure Roadmap
Deploy a Azure Active Directory Proof of Concept:
- Azure Active Directory Proof of Concept Playbook: Introduction
- Azure Active Directory Proof of Concept Playbook Ingredients
- Azure Active Directory Proof of Concept Playbook: Implementation
- Azure Active Directory proof of concept playbook: Building blocks
Azure AD Connect (tool) and Hybrid:
- Integrate your on-premises directories with Azure Active Directory
- What is Azure AD Connect and federation
- Architecture Topologies for Azure AD Connect
- How to manage Azure AD Connect
- GDPR compliance and Azure AD Connect
- Implement password synchronization with Azure AD Connect sync
- Azure AD Connect sync: How to manage the Azure AD service account
- Hybrid Identity Required Ports and Protocols
- Azure Active Directory Hybrid Identity Design Considerations
- Define data protection strategy for your hybrid identity solution
- Manage access to resources with Azure Active Directory groups
- User Management
Azure AD Self Service Password Reset:
- Azure AD self-service password reset for the IT professional
- Self-service password reset in Azure AD deep dive
- How to successfully roll out self-service password reset
What about Azure Active Directory Domain Services? (ADDS running in Azure as a service):
- What is Azure Active Directory (AD) Domain Services?
- How to decide if Azure AD Domain Services is right for your use-case
- Deployment scenarios and use-cases
Deployment of Active Directory Domain Services (on-premises) in Azure IaaS (on virtual machines):
- Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines
- How to install a new Active Directory forest on an Azure virtual network
- Install a new Active Directory forest on an Azure virtual network
- Install a Replica Active Directory Domain Controller in Azure Virtual Networks
Azure Active Directory Join (instead of domain joined device):
- Introduction to device management in Azure Active Directory
- Usage scenarios and deployment considerations for Azure AD Join
- Set up Azure Active Directory registered Windows 10 devices
- How to configure hybrid Azure Active Directory joined devices
- Setting up on-premises conditional access by using Azure Active Directory device registration
- Join a new Windows 10 device with Azure AD during a first run
- Troubleshooting hybrid Azure Active Directory joined down-level devices
- Afraid of Windows 10 with Azure AD join? Try it out (part 1)
- Enterprise State Roaming overview (sync your device settings to the cloud!)
- Azure Active Directory best practices from around the world
- What’s new in Azure Active Directory Domain Services
- Windows devices in Azure Active Directory: Why should I care?
Azure Active Directory B2B:
- What is Azure AD B2B collaboration?
- How do Azure Active Directory admins add B2B collaboration users?
- How do information workers add B2B collaboration users?
- Multi-factor authentication for B2B collaboration users
Azure Active Directory Application Management:
- Managing Applications with Azure Active Directory
- Integrating Azure Active Directory with applications getting started guide
- Managing access to apps
- Develop line-of-business apps for Azure Active Directory
Manage Access to Azure:
- Manage access to Azure resources with Azure Active Directory
- Get started with Role-Based Access Control in the Azure portal
- Manage access to Azure management with conditional access
- Securing privileged access for hybrid and cloud deployments in Azure AD
- Manage emergency-access administrative accounts in Azure AD
- Azure AD access reviews
Securing your identities:
- Conditional access in Azure Active Directory
- Authenticating identities without passwords through Windows Hello for Business
- Get started with certificate-based authentication in Azure Active Directory
- Azure Active Directory Identity Protection
- Securing privileged access in Azure AD
And my favorite…
Maintaining governance over where company data is stored and how it is used, is a core priority for many IT professionals. In this mobile first world, with each user on average having 3+ devices and each with company data on them, ensuring that data is well protected can be a challenge. Giving users a choice of what device they want to use and how they want to use it to execute their job can be empowering – but we must protect the data that lives on those devices. This means ensuring that only compliant/approved devices, (and compliant/approved apps), can access that data. If that data were to be compromised (leaked, lost,stolen,etc) that could be devastating to an organization and place individual employees at risk.
A classic example is when an employee has a smartphone and would like to receive their company email on it. If they go to configure the built-in mail app with their email, how can you require the device to be enrolled into an MDM to be protected and require they use an approved email app? Well, Microsoft Intune and Azure Active Directory Conditional Access to the rescue! In this blog, you and I will take a journey on how to setup and configure this exact scenario and then test it to see what the end-user experience will look like.
I’m not going to cover Microsoft Intune or Azure AD Conditional Access in full technical detail. Please refer to the product documentation (links above) for more information.
Let’s start with understanding Conditional Access. At a high level, this allows me (IT) to provide you (the end user) with access to corporate resources based on a set of conditions and if you meet those conditions I’ll let you in. If you don’t meet those conditions, or perhaps meet only one or two, I will have additional steps for you to take before I unlock the front door and invite you in for dinner. You can best think of Conditional Access as an “If/Then” statement. For example, if you are coming from a device that is un-managed (and using an un-approved application), then allow access but require you to enroll the device in MDM (i.e. managed) and download the approved application for accessing email. Here’s a good graphical representation on how to think about this, at a high level (as you can see, this can be very powerful!):
Now that we have an understanding of Conditional Access, let’s configure it for this scenario. I’m going to create a new Conditional Access policy in Azure Active Directory from within the Azure portal:
Next I will scope it to all users:
Next, for Cloud Apps I will chose Office 365 Exchange Online:
Next, for Conditions I will choose device platforms and select all platforms:
For Grant I will choose grant access and check the box for require device to be marked as compliant and require approved client app. I’ll also check the radio button so that all controls are required. (For more information about what are approved client apps see this article).
Next I’ll enable the policy and click create:
I now need to configure the device compliance for Intune. I’m going to navigate to Device Compliance in the Intune blade:
I’m going to create a new policy that is targeted at just iOS:
IMPORTANT: If there’s other platforms you need to accommodate, you’ll need to create a new policy for each platform type (i.e. Windows, Mac, Android, etc).
For fun, block jail broken devices under device health:
And for more fun, require a passcode under system security:
Now the compliance policy has been created, I am going to assign it to all users:
Okay, let’s take a look at what the user experience is like for this scenario.
Let’s launch the native mail app on an iPad (iOS device):
Sign in with my corporate credentials:
Tap sign in:
When my company’s login page appears to finish the sign in process, enter my password:
What do we have here? …. Looks like Conditional Access kicked in! My device is not managed! But it does give me an option to Enroll!
IMPORTANT: To see the enrollment process, reference my other blog article Intune: MDM Enrollment Experience (complete device management)
Once the device is enrolled, with my policy it is also pulling down the Outlook app (well, the user is prompted to install it). When I launch the Outlook app….
Tap get started, and there’s my email profile!
NOTE: This does not require any configuration for the email profile to be automatically displayed.
And there’s my email!
Now what if I go back to the native mail app and try to use it? Well following the same process above where I type in my credentials and try to sign in again to the native mail app – Conditional Access will catch me red handed, and block me from using it:
Conclusion: As you can see, this is a very powerful feature and introduces automation into your device security strategy. Enjoy!
It’s amazing watching the adoption journey of Microsoft teams among organizations and how it is quickly becoming a mission critical tool. For me, it’s mission critical because of the collaboration and teamwork that’s occurring inside, and the data that is being stored is quickly becoming the heartbeat of many organizations and their project teams. There is one challenge however with storing proprietary and sensitive data in Microsoft Teams, as users are accessing the data using the Teams app on not just their PC or laptop, but mobile devices and other (even unmanaged) computers as they perform their job – if that data is leaked/spilled/exposed or compromised, it could put the organization at risk, and as IT Professionals we need to help protect against this risk.
Not to worry – Azure Active Directory Conditional Access to the rescue! Using AzureAD Conditional Access, we will ensure Microsoft Teams is only accessed on devices that are managed, whether they are Active Directory domain joined, Azure AD joined or managed by Intune. This is very easy and straight forward to setup, let’s take a look together.
Important: Conditional Access requires AzureAD Premium. I won’t be discussing licensing requirements in this blog post, please reference this article for more information.
In the Azure Portal, I am going to create a new AzureAD Conditional Access policy with the following configuration:
- Users and Groups: “All Users”
- Cloud apps: (Include) “Microsoft Teams”
Conditions: Client Apps -> Configure “Yes” -> Select Client Apps -> check “Browser” and “Mobile apps and desktop clients”
Access Controls: Grant Access -> Check “Require Domain Joined” and “Require device to be marked as compliant”
Important: If you check “Require device to be marked as compliant” you must create a device compliance policy in Intune. This will ensure devices such as iOS, Android, Windows, Mac that try to access Microsoft Teams using either the app, client or website must be Intune MDM enrolled (which requires an Intune subscription). If accessed from a Windows PC and is Active Directory domain joined or Azure AD joined, require MDM enrollment will not apply. Here’s what an example Device Compliance policy looks like in Intune:
Back to Conditional Access…
Enable Policy: “On”
Now the policy is created, let’s test this out. It should deny access to Microsoft Teams.
From a Windows PC that is unmanaged (not joined to Azure AD, Active Directory, or MDM enrolled):
From a Web browser:
Notice the error reads “Windows device is not in required device state: compliant”
From the Microsoft Teams Windows Desktop Application:
Next, from an iPad Pro (iOS) that is unmanaged (not MDM enrolled):
Notice it gives me the option to enroll in MDM (Intune), pretty cool!
This is a quick and easy way to ensure that users are using Microsoft Teams on managed devices, where IT can control the configuration of the device and ensure the device is healthy and compliant. What’s more is this policy can be reversed and disallow users from using the Teams web client if that becomes a requirement. For additional fun, check out Microsoft Teams: Manage it using Mobile Application Management (MAM) and Microsoft Teams: Restrict Usage with Azure AD Conditional Access
If you have questions or feedback, let me know in the comments below. Enjoy and have fun!
In this blog post I will discuss how to use Conditional Access in Azure Active Directory (Azure AD) to restrict how Microsoft Teams is accessed by employees. This blog post will cover how to configure Conditional Access, and what the experience is like for users.
What is Conditional Access? Conditional Access is a feature of Azure AD that enables organizations to define specific conditions for how users authenticate and gain access to applications and services. For more information, see the following resource Conditional access in Azure Active Directory. Note, Conditional Access requires Azure AD Premium P1 or above. For more information, see Azure Active Directory pricing (Note, a 30 day trial is also available).
The are many ways Conditional Access can be used. In this blog post, a fictitious company Contoso, would like to give their retail employees access to Microsoft Teams however they have requirements that must be met:
- Retail employees are paid hourly and work at a company retail store. When the employee leaves work and is “off the clock”, they are not allowed to access Microsoft Teams.
- When the employee leaves work, the app should not allow them to access data or services.
- When the employee returns to work, the app should allow them to access to all data and services within the app.
- These requirements will apply to all platforms where an employee can access Microsoft Teams (smartphone app, Windows, Mac, web browser, etc)
Based on these requirements and an understanding of the capabilities of Conditional Access, they came up with the following design and configuration:
- All retail employees will be assigned to a security group titled Retail Staff. The Conditional Access policy will only be applied to employees that are a member of this security group.
- The policy will only be applied to the Microsoft Teams append will include all platforms (Android, iOS, Windows Phone, Windows, Mac OS, etc.
- The policy will apply to any location (IP address), but, locations with trusted IPs will be excluded. Contoso will add their public IP subnet to the list of trusted IPs.
- The policy will apply to browser, mobile apps, and desktop clients.
- Sign in risk will not be configured.
- Access controls will be set to block. Require Multi-factor authentication, device compliance, etc will not be configured.
- Session control will not be configured.
Employees will connect to a guest Wi-Fi network while in the store.
Let’s get started on how to deploy this design.
First, assign Azure Active Directory Premium P1 licenses to users:
As mentioned previously Azure AD Premium P1 is required. For this scenario, I’m going to assign the license to my retail employee Megan:
Note: You’ll see that I’m using AzureAD Premium P2, this is because I’m using a few additional features such as Privileged Identity Management and Identity Protection that I will blog about in the future.
Add employees to the Retail Employees security group:
Next, I will add Megan to the Retail Employees security group I created. This will make it easy to manage the Conditional Access policy and assign users later:
Launch the Azure Active Directory admin center:
Conditional Access is configured in the Azure Active Directory admin center. To launch this portal, on the left side of the Office 365 Admin Portal expand Admin centers and click Azure AD:
Note: A shortcut is to browse to aad.portal.azure.com
In the Azure Active Directory admin center, on the left side click Azure Active Directory:
Next, scroll down and find the Security category and click Conditional Access:
Create Conditional Access Policy:
Next, click Create Policy:
On the New blade, we will give the policy a name of Microsoft Teams for Retail Employees. Then click Users and Groups:
In the Users and groups blade, under the Include tab select the radio button for Select users and groups then click Select. On the Select blade, browse to the security group Retail Employees and place a check next to it. Then click the Select button at the bottom:
Note: If any employees should be exempt from the policy (i.e. the store manager) then the Exclude tab can be used.
On the Users and groups blade click Done:
On the New blade click Cloud apps;
On the Cloud apps blade, under the Include tab click the radio button for Select apps then click Select. On the Select blade, find Microsoft Teams, place a check mark next to it then click Select. On the Cloud Apps blade click Done:
Back on the New blade, click Conditions. On the Conditions blade click Device platforms. On the Device platforms bade click Yes and select All platforms (including unsupported). Then click Done:
One the Conditions blade, click Locations. Click Yes and on the Include tab click Any Location then click the Exclude tab:
On the Exclude tab click the check box All trusted IPs then click the hyperlink Configure all trusted locations:
A new browser tab will launch, and you will be taken to the mult-factor authentication page. In the trusted ips box, type the IP address subnets of the public IP address of the retail store. In my example below, when the employee is in the retail store and connected to the guest Wi-Fi network it will use a public IP in the subnet of 184.108.40.206/14 to access Microsoft Teams in Office 365. By adding this subnet, this tells Conditional Access to exclude any authentication attempts coming from this subnet from the Conditional Access policy. Click Save at the bottom of the page and close the browser tab when finished:
Back in the Azure Active Directory admin center, click Done on the Locations blade:
On the Conditions blade click Client Apps. On the Client Apps blade click Yes. Click the radio button Select Client Apps and select Browser and Mobile apps and desktop clients. Then click Done. Then on the Conditions blade click Done.
Back on the New blade, under Access controls click Grant. On the Grant blade click the radio button for Block access then at the bottom click Select:
On the New blade click On to enable the policy then click Create to create the policy. Notice in the upper right corner a new toast notification will appear, indicating the policy is in the process of being enabled.
Close the Azure Active Directory admin center tab:
Test Conditional Access while on-network:
Now that the policy has been configured and enabled, let’s test to see if the policy takes effect for a retail employee. I am going to connect an iPhone to the Wi-Fi network at the retail store, and launch the Microsoft Teams app.
I will be successfully authenticated and the app will load:
At this point, I can now use Microsoft Teams when on-network while connected to corporate guest Wi-Fi at the retail store. I will sign-out of the app when finished:
When accessing using a desktop web browser when on-network:
Test Conditional Access while off-network:
Next, I will turn off Wi-Fi on the iPhone so that I am connected to the cellular network to simulate leaving the retail store and disconnecting from the corporate guest Wi-Fi network.
IMPORTANT: The app will automatically re-authenticate every 60 minutes. So, if an employee leaves the store at 5pm, they may still have access to the app until 6pm when it re-authenticates and the Conditional Access policy kicks in.At that point, when they open the app again, they will receive an error due to the policy. I’ll show that in just a moment.
While disconnected from the Wi-Fi network, I’m going to attempt to sign-in to the Microsoft Teams app:
Next, after tapping Sign in will be challenged to enter my password. So, I’ll type in my password and tap Sign in
The Conditional Access policy will kick in, and I am presented with the following message. Notice I cannot proceed with sign in:
When testing from the desktop web browser when off network:
User experience when app times out after 60 minutes:
When the app re-authenticates I will be challenged with an authentication prompt to re-enter my credentials:
Conclusion: Conditional Access is an effective way to enable access to resources after specific conditions have been met. In this scenario, we saw how this can be used to enable a retail employee to use Microsoft Teams while at work, but then not be allowed to use it after work. If you have questions, comments, or feedback on this blog post please don’t hesitate to post in the comments below. My top priority is to ensure the post is accurate and meets the needs of my readers. Enjoy! –Matt Soseman
P.S. Stay tuned for an additional blog post on using Intune Mobile Application Management (MAM) with Microsoft Teams.