Intune, Samsung Knox, and OEMConfig

I work with many organizations who are beginning to migrate from Android device admin enrollments to device owner (i.e. Android Enterprise). While migration to device owner requires a factory reset on the device, once enrolled with device owner, devices have a more standardized approach to management and consistency vs. the fragmented management experience device admin enrollments exhibit when multiple OEMs are being managed.

Realizing there was a need to standardize and secure devices beyond the device admin APIs, years back Samsung introduced Knox. Samsung Knox provides an additional set of security and management APIs built on top of Android and is included with many Samsung devices. EMMs, including Microsoft Intune, also took steps to integrate with Samsung Knox to provide a rich set of management capabilities where the device admin APIs didn’t cover (e.g. email profiles).

Google requires device OEMs wanting their devices to be Android Enterprise Recommended (AER) to meet certain requirements thus standardizing and provide consistency across the Android Enterprise device ecosystem.  However, Samsung Knox remains available and continues to provide security and management features, in some cases, beyond what Android Enterprise offers with their current set of APIs.  Although Android continues to update/add security and management features with every API version.

With Android device owner enrollments, Samsung and other OEMs support OEMConfig.  OEMConfig provides a set of OEM specific features EMMs can configure along with standard device settings.

What is OEMConfig?

“OEMConfig policies are a special type of device configuration policy very similar to app configuration policy. OEMConfig is a standard defined by the AppConfig community (opens another web site) that allows OEMs (original equipment manufacturers) and EMMs (enterprise mobility management) to build and support OEM-specific features in a standardized way. Historically, EMMs, such as Intune, manually build support for OEM-specific features after they’re introduced by the OEM. This approach leads to duplicated efforts and slow adoption.

With OEMConfig, an OEM creates a schema that defines OEM-specific management features. The OEM embeds the schema into an app, and then puts this app on Google Play. The EMM reads the schema from the app, and exposes the schema in the EMM administrator console. The console allows Intune administrators to configure the settings in the schema.

When the OEMConfig app is installed on a device, it can use the settings configured in the EMM administrator console to manage the device. Settings on the device are executed by the OEMConfig app, instead of an MDM agent built by the EMM.

When the OEM adds and improves management features, the OEM also updates the app in Google Play. As an administrator, you get these new features and updates (including fixes) without waiting for EMMs to include these updates.”

Source: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Although Samsung offers OEMConfig settings, some Samsung features/settings require a Samsung license, for more details please visit: https://www.samsungknox.com/en/blog/knox-platform-and-android-enterprise

Intune documention on OEMConfig may be found here: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Let’s get started with OEMConfig with Intune and a Samsung device

Samsung Knox Service Plugin

First, let’s add the Knox Service Plugin from the Managed Google Play store which is required to deploy OEMConfig policies to Samsung devices.

Assumptions: Intune is already connected to Managed Google Play, if it’s not you can find details on how to do this by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

We’ll do this by navigating to https://devicemanagement.microsoft.com -> Client apps -> Apps -> Add -> App type = “Managed Google Play” -> select Managed Google Play Approve

To learn more about Samsung OEMConfig settings, browse through the Knox Service Plugin (KSP) admin guide: https://docs.samsungknox.com/knox-service-plugin/admin-guide/welcome.htm

Creating an OEMConfig profile for Samsung in Intune

Navigate to Device configuration -> Profiles -> Create profile -> add a name -> Platform = Android Enterprise -> Profile type = OEMConfig

Associated app = Knox Service Plugin – this is the app added in the previous step.

Select OK after selecting Knox Service Plugin.

After selecting OK we’re taken to Settings where we’ll see a full page of JSON. Don’t be intimidated it’s straight forward once you understand the structure which are just key/value pairs.

Update: as of the Intune 1907 release there is now a configuration designer with a UI, so no need to edit JSON.

2019-07-30_10-28-52

Continue reading for additional details about these settings and details about JSON if you prefer to edit manually:

Either select all and copy or select Download JSON template and open in your favorite text editor.

There are a couple values I want to point out in the JSON:

I mentioned at the beginning some Knox features/settings may require an additional Samsung license, this is where the license key would be set:

We want to turn on the policies, do this by setting doPoliciesIsControlled to “true

Troubleshooting – everyone likes an easy method to troubleshoot a device and by setting verboseMode to “true” will enable you to view the policies deployed to the device via the Knox Service Plugin app. More on this later in the post.

There many settings that are controlled with OEMConfig, however for the purposes of this post I’m going to turn off face recognition and only allow fingerprint. Disable face recognition by setting doPasswordBioFace to “false“.

Note: blocking the ability to use Face unlock to unlock the phone doesn’t prevent the device user from adding their face recognition. They just won’t be able to log in with face recognition as password and fingerprint are allowed in the OEMConfig.

Once you’ve completed filling out the JSON, copy and paste into Intune where you originally copied the JSON from and select OK then Save.

Note: you don’t have to have every key/value in the profile present, feel free to delete key/values from the JSON, just make sure the formatting is correct.

Device view

Once the policy is targeted to device it should only be a few seconds or so before the policy gets pushed to the device through Google services.

We can check if the policy deployed by opening the Knox Service Plugin app and selecting “Configuration on yyyy/mm/dd” (e.g. “Configuration on 2019/07/08”)

Select the “Configuration results” dropdown and select “Policies received” and from here we see the same JSON that was deployed from Intune.

Look for the password policy in the JSON as shown below:

On the same Samsung device navigate to Settings -> Biometrics and security -> Face recognition -> enter your password if prompted and we see “Face unlock” is disabled.  Again, we can add face recognition, however we can’t use it to unlock the device, so it’s essentially benign.

Here’s a video of the process above:

C02937BC-C8ED-4E0A-A3B2-3915A014D37A

Use a QR code to point users to the Intune Company Portal app for enrollment

Use a QR code to point users to the Intune Company Portal app for enrollment

Quick post here, ever wonder how you can create a QR code that points to the Intune Company Portal in the iOS app store (or any app store), and paste it in an email and send it to your end users? Well it’s super easy to do. Simply search online for a QR code generator. Example: https://www.bing.com/search?q=qr%20code%20generator

When I searched for a QR code generator, a result came up inline of my search results and I pasted the URL that points to the Intune Company Portal in the Apple app store and it generated the QR code below.

If you’re interested, here’s the raw data behind the QR code:

Even better, the Intune Company Portal has 4.5 stars, hey that’s awesome!  Ok shameless plug, however it’s really cool to have such a high rating.

Anyway, theoretically you can do this for any app in an app store, whether they’re Microsoft Office apps, 3rd party apps, one of your published apps, etc.

To save you time, I generated QR codes that point to the Intune Company Portal (or enrollment URL in MacOS case) for all the platforms supported by Microsoft Intune:

iOS                                 Android

        

Windows Store            MacOS

        

Note: MacOS points to https://portal.manage.microsoft.com

Here’s an example email I manually created. Create your own by copying a QR code and generating your own custom emails using your corporate email application such as Outlook.  Your users will love it!  Plus it streamlines their enrollment process.

Here an example of using the built-in camera in iOS to scan the QR code.  As you can see it took me directly to the Intune Company Portal app in the Apple app store.

Intune_iOS_QRCode

 

If you’re intersted, for coporate owned devices Intune supports NFC, QR, and Zero Touch for Android Enterprise already, for more information please visit: https://docs.microsoft.com/en-us/intune/android-enroll

That’s it, I hope you find this valuable when directing your end users to enroll their devices with Microsoft Intune.

Intune, Azure AD, and Zscaler Private Access

Securing the perimeter has become increasingly difficult with more and more services moving to the cloud and users needing, no, expecting, access from their personal devices. The days of relying on the walls of a network to “trust” access are fading fast, and some would say they’re long gone. This is why organizations are using Microsoft technologies to build out zero trust networks where they rely on device and user claims to evaluate access to resource both on and off network. As I’ve written about in the past, security comes in layers, and zero trust encompasses many layers of security behind the scenes.

Over the past few years, Microsoft has worked with many security and management vendors to integrate with Microsoft Intune and other solutions in EMS such as Azure Active Directory.

The following list is just an example of the many technology partnerships Microsoft has in place today.

To keep up to date with Microsoft security partners please visit: https://www.microsoft.com/en-us/enterprise-mobility-security/microsoft-intune?rtc=1

For this month’s post I’ll focus on Intune, Azure Active Directory, as well as a Microsoft security partner, Zscaler, particularly Zscaler Private Access and its integration with Azure AD and Intune.

What is Zscaler Private Access?

According to Christopher Hines, Head of Product Marketing at Zscaler:

“The Zscaler Private Access (ZPA) service provides users with seamless and secure access to private applications without placing them on the network and without exposing apps to the internet. Allowing enterprises to embrace a software-defined perimeter that supports all private apps and environments.”

More details about Zscaler may be found by visiting: : https://help.zscaler.com/zpa/getting-started/what-zscaler-private-access

Before we get started, I want to give special thanks to the following individuals I collaborated with for this post:

    • Tyler Castaldo – Microsoft Program Manager – Intune
    • David Creedy – Senior Product Manager – Web Security
    • Christopher Hines – Head of Product Marketing – ZPA and Zscaler App

Let’s get started

Zscaler SSO Setup

First, we need to set up Zscaler with Azure so we can provide SSO as users access the app. Once the user accesses the the Zscaler App on their device, they’ll be passed through to Azure AD for sign-on.

Setting up Zscaler Private Access (ZPA) requires a few steps so I won’t go through them, however the steps are well documented here: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/zscalerprivateaccess-tutorial

In addition, Zscaler has also created their own documentation that may be referenced as well:

Adding Zscaler App to Intune for deployment

For this post I focus on iOS and Android. However, Zscaler is also supported on macOS and Windows 10 (more details at the bottom of this post).

After SSO is set up with Zscaler and Azure AD, we now need to add the Zscaler App to Intune for deployment.

Navigate to portal.azure.com or devicemanagement.microsoft.com and select “Client apps -> Apps”

Select “Add” then App Type and from the dropdown select iOS. Search for Zscaler and select “Zscaler App” as shown below. Add the app and assign it to a group for deployment.

For Android, repeat the steps above, however for the “App type” select “Android“. Use Managed Google Play in the console to search for Zscaler, then add and assign the app to a group for deployment.

Note: if you haven’t set up Managed Google Play with Intune yet, you will find details steps on how to do so by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

When performing a search for “Zscaler” under apps in Intune you should see both assigned apps.

Configuring the Zscaler App using a VPN policy for iOS and app config for Android

Configuring Zscaler Private Access for iOS in Intune is straightforward as Intune has the settings available directly in the Intune adming portal UI as shown below.

Note: the “Organization’s cloud name” is case sensitive and FQDN and key/value pairs are optional, for more details please visit: https://docs.microsoft.com/en-us/intune/vpn-settings-ios#base-vpn-settings.

Select how the VPN will be launched:

Configure additional settings your organization requires to provide access to applications bridged by Zscaler:

For Android, we need to create an app configuration policy and assign it to the Zscaler App we added earlier.

https://docs.microsoft.com/en-us/intune/app-configuration-policies-use-android

Create an app configuration policy by navigating to “Client apps -> App configuration policies”

Select “Add”, provide the policy a name and from the “Device enrollment type” drop-down select “Android”.

Under “Associated app” select the Zscaler App added earlier.

Under “Configuration settings” select “Use configuration designer” from the drop-down and select all the options provided. Select ok to begin configuring the values.

Configure the values based on how your Zscaler environment is configured. In my case, my Zscaler environment is set up in Azure so I utilized the cloud name for the service in Azure as well as the domain my users log into. For username, I selected variable and chose “Partial UPN”.

Once all the settings are configured select “Ok” to complete the setup.

Note: you’ll notice the “deviceToken” value is set to “DummyValue”. This value isn’t needed when Azure AD is used as the identity provider (IdP), however it is needed in the profile, so just add it and type in whatever you like for the value. Also, please note the “Organization’s cloud name” is case sensitive.

After you’re finished with the app config policy, be sure to assign it to the same group you assigned the Zscaler App to.

Client experience

On first launch, the Zscaler App on iOS and/or Android it will redirect to sign-on using Azure AD, however subsequent launches of the Zscaler App will sign-in automatically.

Azure AD Conditional Access

To prevent access to an application Zscaler Private Access is securing access for, we need to create an Azure AD conditional access policy. The Azure AD Conditional Access policy will ensure the device and/or user meets compliance policies (e.g. Intune) before allowing access.

Navigate the Azure Active Directory in the Azure portal and select “Conditional Access”

Provide a name for the policy and under Cloud app add “Zscaler Private Access” and add the Zscaler cloud app used to access resources, i.e. the organization cloud name that points to the app we added earlier. The cloud app I utilize is called Zscaler ZSCloud as shown below.

Select the device platforms to target the Azure AD CA policy, since I’m focusing on iOS and Android in this post, I select iOS and Android from the devices platforms list.

Now grant access if the device is marked as compliant by Intune, enable the policy and save.

Note: additional conditions and access controls may be checked if needed.

If the device is compliant with Intune compliance policies, Zscaler will connect the user to the application. If the device isn’t compliant, Azure AD Conditional Access will block access to the application Zscaler provides access until the compliance issue is remediated.

Note: currently there is an issue with Conditional Access and Android Enterprise where the device is treated as not enrolled.  Zscaler is working through this and we’ll provide an update as soon as the issue is resolved.

Let’s see this in action

I’m testing with my Android device enrolled with Intune under Android Enterprise Device Owner as a fully managed device. The Zscaler Private Access (ZPA) App and ZPA App configuration is automatically deployed.

Intune_Zscaler.gif

Conclusion

In summary we learned how to set up Zscaler with Azure and provide SSO using Azure Active Directory. We also learned how to set up Zscaler Private Access App configuration and app deployment with Microsoft Intune. Finally, we learned how to set up an Azure Active Directory Conditional Access policy to further secure application access with Zscaler based on Intune device compliance.

I hope this post helps you and your organization further secure corporate applications, devices, users, and resources using Microsoft Intune, Azure Active Directory, and Zscaler Private Access. If you’re a Zscaler customer today, go out and give these steps a try.

Appendix

Information on setting up Zscaler for Windows and MacOS

Android + Intune = Android management

When I speak with organizations who are considering Android devices there’s usually the question of, “which management option should we choose?”. The answer to the question requires a clear understanding of the scenarios the organization would like to bring under management such as personal devices or corporate devices or even purpose-built devices (e.g. inventory scanners, digital signage, etc.).

There are many different versions of Android from many different OEMs and choosing and supporting each version can be challenging. However, as I’ll discuss later in this post, Android enterprise aims to address OEM fragmentation while providing a variety of management options. Fortunately, Microsoft Intune will address various Android management methods available today including those offered with Android enterprise, so let’s look at how Android management is accomplished with Intune.

The table below walks through each available Android device management scenario, how Microsoft Intune supports it, as well as items to evaluate when considering each option.

Device Management Type Enrollment Type Intune Management
Android Device Admin
Considered legacy administration, the Android device administration API has provided APIs to manage the Android device since Android 2.2. The issue with device admin is there are only so many management APIs available, the user experience is challenging, and according to Google, device admin will be depreciated in 2019. With Android Q, device admin will not be available at all.Device Admin requires an Android device to be enrolled via an MDM and requires various administrator permissions during certain enrollment scenarios. As such, device admin offers insufficient privacy for BYOD, insufficient management capabilities for corporate owned devices, and a poor user experience all around. In addition, device admin is less secure than Android enterprise and device admin is not ideal for an environment requiring minimal or no touch enrollment.To learn more about device admin deprecation please visit: https://developers.google.com/android/work/device-admin-deprecation
Intune supports devices enrolled with device admin on Android 4.4+

To enroll a device to Intune using device admin please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-android

In addition, Intune App Protection policies are supported with device admin (or without enrollment): https://docs.microsoft.com/en-us/intune/app-protection-policy

For BYOD, Intune App Protection policies are a great choice as the policies protect the corporate data at the app layer without requiring the user to enroll their device.

Samsung KNOX Standard
With Samsung devices, Samsung added their own management APIs which expands the management capabilities for devices enrolled with device admin.  An example is managing the email profile for the native email app on a Samsung device.KNOX is only available with certain Samsung devices so utilizing other OEM devices would require device admin or Android enterprise.Note: Samsung has announced the unification of KNOX and Android enterprise. More details may be found here: https://www.samsungknox.com/en/blog/android-enterprise-and-samsung-knox-your-questions-answered-hereSamsung also offers KNOX Mobile Enrollment (KME) which allows for automatic enrollment of devices even after a reset. KME is supported starting with Android 2.4 and KME is beneficial for mass enrollment of devices without having to touch each one. Devices may be manually and/or added through a carrier to an MDM. After which, users will experience a streamlined enrollment process which removes the touch points required by device admin.KNOX Mobile Enrollment is only available with Samsung devices so if no touch enrollment is needed for other device OEMs, Android enterprise may be an option.To learn more about KNOX Mobile Enrollment please visit: https://www.samsung.com/us/business/solutions/samsung-knox/mobile-security-solutions/knox-mobile-enrollment/
Intune supports KNOX standard without additional licensing for KNOX. However, KNOX also requires Device Admin enrollment as well. Once a device is enrolled with an MDM the end user will also see prompts about KNOX after which both device admin and KNOX policies may be deployed to the device. KNOX Mobile Enrollment streamlines the enrollment process by enrolling the device automatically.

To learn more about enrolling a device that supports Samsung KNOX with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll#end-user-experience-when-enrolling-a-samsung-knox-device

In addition, Intune App Protection policies are supported with Samsung KNOX: https://docs.microsoft.com/en-us/intune/app-protection-policy

Intune supports KME and to learn more about setting up KME with Intune please visit: https://docs.microsoft.com/en-us/intune/android-samsung-knox-mobile-enroll

In addition, Intune App Protection policies are supported with devices enrolled with KME: https://docs.microsoft.com/en-us/intune/app-protection-policy

Up to this this point we’ve reviewed traditional management methods available on Android as well as enrolling and managing Android devices with Intune. However, if you’ve noticed, there seems to be a theme throughout and it’s around Android enterprise. It appears all paths are leading to Android enterprise so let’s learn about what Android enterprise is and how Intune will assist with managing devices enrolled using Android enterprise.

Android enterprise

There are two primary modes of management under Android enterprise (AE). Work profiles for BYOD and Device Owner for corporate owned devices.  More details on Android Enterprise device ownership please visit: https://developers.google.com/android/work/requirements 

Android enterprise
Android enterprise (AE) offers a variety of management scenarios for certified devices providing more robust management APIs over device admin. Although Android enterprise is supported on Android 5.0+, Google recommends 6.0 or later.Once a device is enrolled in an MDM such as Intune, Android enterprise has the concept of a work profile (formerly Android for Work) that separates or containerizes corporate applications and data on a personal device. The managed profile contains corporate data and allows only applications within the work profile to access the data within while leaving personal data separate. To learn more about work profiles please visit: https://support.google.com/work/android/answer/6191949?hl=enIn addition to work profiles, Android enterprise offers Device Owner mode where corporate owned devices are enrolled with an MDM and managed based on the purpose their intended for. To learn more about Android enterprise management for company-owned devices please visit: https://www.android.com/enterprise/management/To provision the device owner mode the device must be factory reset, unfortunately there are no migration paths to device owner mode from device admin. The provisioning process may be driven by NFC, QR code, or zero-touch. Previous versions of Android such as 5.0 and 5.1 can use an activation code to begin the enrollment process.For more details about device provisioning please visit: https://developers.google.com/android/work/prov-devicesTo learn more about AE management scenarios please visit: https://www.android.com/enterprise/management/Note: as stated previously, moving from device admin to Android enterprise requires a factory reset. Consider the ramifications of already deployed devices to end users and in the workplace before beginning a migration. A strategy of enrolling new devices with device owner while continuing to manage existing devices enrolled with device admin may be an option. Through attrition, devices will onboard using Android enterprise. As mentioned earlier, with Android Q, device admin will not be an option.
Intune supports Android enterprise purpose-built device management including single-use and work profiles which aligns with many organizational use cases.

Details on how to configure Intune to and manage devices supporting Android enterprise are below.

Management of Android enterprise managed profiles and other details may be found here: https://docs.microsoft.com/en-us/intune/android-enterprise-overview

Connect Intune to Android enterprise:

https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

Android enterprise single-use (Kiosk) devices Intune enrollment: https://docs.microsoft.com/en-us/intune/android-kiosk-enroll

In addition, Intune App Protection policies are supported with Android enterprise: https://docs.microsoft.com/en-us/intune/app-protection-policy

Applications, including LOB apps are published through managed Google play.

Selecting an enrollment option

Choosing an enrollment option really depends on the scenario and what your business requires. For example, if your devices require minimal or no touch enrollment you may consider KNOX Mobile Enrollment and/or Android enterprise. Since Android enterprise appears to be OEM agnostic, if the plan is to have various device OEMs deployed, devices supporting Android enterprise may be an option. However, if devices are used for kiosk, digital signage, ticket printing, inventory scanning, Android enterprise would be something to investigate as well. If devices are personal devices (BYOD), I recommend looking at Intune App Protection for unenrolled devices and/or Work Profiles. Lastly, before selection consider the short- and long-term ramifications of one option over another.

That’s it! We’ve reviewed the options available for Android enrollment and Intune, documentation on how to enroll Android devices, and the future of Android management through Android enterprise.

Intune app protection diagnostics and managed browser bookmarks

 

Many of the organizations I work with have deployed or are deploying Microsoft Intune to manage devices as well as applications. Microsoft Intune offers application protection (aka Mobile Application Management (MAM)) where policies manage applications. Application protection may be used with or without MDM enrollment. If you already have an MDM solution, Intune application protection may be utilized alongside of any MDM provider.

To learn more about Intune app protection please visit: https://docs.microsoft.com/en-us/intune/app-protection-policy

For those already utilizing Intune app protection, there’s a diagnostic feature available within the Intune managed browser for iOS allowing users to view and send diagnostic logs to their support team and/or Microsoft support.

For more details on the Intune diagnostic console please visit: https://blogs.technet.microsoft.com/intunesupport/2017/11/10/support-tip-new-intune-diagnostic-console-for-log-submission-in-the-intune-managed-browser/

 

Let’s look at Intune Mobile App Protection (MAM) diagnostics

Requirements

  • Microsoft Intune
  • Intune app protection policy assigned to users
  • Intune managed browser
  • Apple iOS device

 

Intune App Protection Policies

I won’t go into details about how to configure an app protect policy as there’s plenty of documentation available.  To learn more about creating app protection policies please visit: https://docs.microsoft.com/en-us/intune/app-protection-policies

If devices are enrolled with Intune simply deploy the Intune managed browser to iOS devices.  For devices that are not enrolled with Intune, have users download the Intune managed browser from the Apple app store: https://itunes.apple.com/us/app/intune-managed-browser/id943264951?mt=8 

 

Use Intune managed browser to troubleshoot app protection

Open in the Intune managed browser on the iOS device where applications are protected by Intune app protection policies.  In the navigation space type in: about:intunehelp and search.  You’ll be taken to Intune Diagnostics page where you can begin your investigation:

Later in this post I’ll show you how to create a bookmark for your users to access Intune Diagnostics.

Review the device information and select “View Intune App Status”:

image

 

Select an application that is protected, in my case I’ve selected Outlook and I’m able to see diagnostic info about the app and the policies settings that are deployed to it:

image

 

Configure the Intune managed browser with a bookmark that takes users straight to the Intune diagnostic screen

Navigate to the Intune admin portal via portal.azure.com and select Intune.  Next select Mobile apps, App configuration policies, and Add:

image

 

  1. In the General tab, give the policy a name
  2. In the Targeted apps tab, select Managed Browser
  3. In the Configuration tab, add the following:
  4. Assign the configuration to users

Under Name

com.microsoft.intune.mam.managedbrowser.bookmarks

Under Value

Bing|https://www.bing.com||Intune Diagnostic|about:intunehelp

Note: Bing is optional, take it out if you don’t want to add it.

Once configuration is complete, assign the configuration to users.

 

image

 

After the policy syncs with the app (usually a few minutes or so), open the Intune managed browser and select bookmarks and your bookmarks will be populated as shown below:

image

 

That’s it, we looked at troubleshooting Intune app protection and adding a bookmark for your users to easily access it.

Azure AD B2B…how to work with partners and subsidiaries

 

Azure AD Business-to-Business or Azure B2B is a topic of interest among nearly every organization I speak with. Today many organizations either have a 3rd party IDPs (identity providers) or ADFS deployed and federate with their business partners. Federation establishes a trust whereby providing two-way or one-way access to company resources and applications.

However, with the abundance of SaaS applications that now drive many business functions and processes, companies require a method to allow business partners access to those applications as well.

For example, business partner visibility into inventory management systems, CRM, marketing, O365, and even HR applications is necessary to ease the flow of the business partnerships and allow for collaboration on projects.

Fortunately, Azure Active Directory offers what is called Azure AD B2B where users from an external organization may be invited to access applications of the company who invited them. Another use for Azure B2B is working with subsidiaries or mergers/acquisitions to provide company wide access to resources.

To learn more about Azure AD B2B please visit: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-what-is-azure-ad-b2b

 

Inviting external users to Azure AD

There are a few options that may be utilized when inviting a user to your Azure AD tenant:

  1. Azure AD admin portal
  2. PowerShell – single invite or bulk upload
  3. Microsoft Graph


Azure AD admin portal invitation process

  1. Navigate to portal.azure.com as the admin for the tenant you’d like to invite the external user to.
  2. Locate Azure Active Directory and select User and Groups
  3. Select All users
  4. Select New guest user as shown below
  5. Fill in the email address of the user you’re inviting, add a personalized message if necessary and select Invite. From there, the invited user will receive a mail that I display later in this post.

image

 

PowerShell single user invitation process

Using PowerShell to invite an external user is self-explanatory. However, open PowerShell, sign on as an administrator to Azure AD and make the necessary changes to the script below and execute.

New-AzureADMSInvitation -InvitedUserEmailAddress “scranz@berntoso.com” -InviteRedirectUrl https://myapps.microsoft.com -InvitedUserDisplayName ‘Sara Cranz’ -InvitedUserMessageInfo $messageInfo -InvitedUserType member -SendInvitationMessage $true

 

image


PowerShell invitation process – Bulk upload

If a bulk user invitation process is desired, users and email addresses may be pasted into a .csv file and used for upload.

Example .csv file

clip_image004

More details about bulk upload here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-code-samples

Note: make sure the .csv is in proper format or the script will fail.

clip_image005


Guest user invitation redemption process

Once the user(s) receive an invitation mail, they’ll see something similar to the image below. The user will then select “Get Started” from the email to begin the invitation redemption process.

image


Dynamic Groups

Once external users exist in a tenant, dynamic group memberships may be used to automatically assign users to group, for example, any user with @contoso.com may be dynamically assigned to Group A. Group A can also be assigned to SaaS applications or assigned to SharePoint Online/OneDrive sites, so as soon as a user is assigned to a group they’ll have immediate access to the app(s) assigned to it.

Dynamic group membership eases the management process of adding and removing users to applications. Simply assign a group to the application permission and use dynamic group rules to automatically assign and remove users. You can even use attributes such as employeeId, mail, or companyName as attributes to look for, however there are many more attributes to choose from and depending where the users originates from, you may want to get creative.  Finally, for applications that support provisioning, guest users may be automatically provisioned and provisioned to SaaS applications which provides full user lifecycle management.

For more details about Azure AD Dynamic Groups please visit: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-dynamic-membership-azure-portal


Azure AD B2B Licensing

Certain Azure AD B2B scenarios have licensing implications and the following site addresses licensing scenario best: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-licensing

For example, even though users may have the role of guest or member, depending on where they originated from, additional licensing may be needed. For example, if a user is invited that is from a subsidiary, Azure AD Premium would be required for that user, however if the user was invited from an external partner, they may be covered under the Azure AD B2B license.

Refer to the link above to make sure you have a clear understanding of which licenses are required and when.


April 2018 update

Allow or block invitations to Azure AD B2B users from specific organizations: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-allow-deny-list 


Pay close attention to the following please:

If invited users already have an existing O365 or Azure AD tenant for their own or MSA will not need to go through the invitation process, however tall users will presented with consent (see May 2018 update below).  After which, the external user that belongs to the partner tenant can now add users can from their tenant, and those users will not need to go through the invite redemption process either.  This is only true if there are only Azure AD tenants or MSA in play.

However, if users are external to Azure AD (e.g. gmail.com, AD on prem, or another email address) the first user added to the tenant can invite other users, however those users still need to go through the redemption and consent processes as there are no accounts for those users that exist in an Azure AD tenant of their own.

In summary, any user that doesn’t already have an Azure AD tenant for their org or MSA and is invited to Azure AD, still needs to go through the invitation redemption process.


May 2018 update:

Exciting improvements to the B2B collaboration experience: https://cloudblogs.microsoft.com/enterprisemobility/2018/05/14/exciting-improvements-to-the-b2b-collaboration-experience/

 

image


Guest user invitation redemption process – continued

Because I invited a user that is not part of an existing Azure AD tenant, they’ll need to run through the account setup process as shown below. If the user already resides in an Azure AD tenant of their own, they would simply sign on and access application assigned to them.

image

 

Here the user associates a password with their account (under the covers a new Azure AD tenant is created for berntoso.com and users are added to it).

image

 

The user will receive a verification code in their inbox they’ll need to use to finish.

image

 

Once the verification code is verified the account is created in the Azure AD tenant:

image

 

Once the redemption process is completed they’re taken to the URL that was provided in the invitation process the administrator performed (e.g. myapps.microsoft.com) and the user now has access to SaaS applications in your tenant as shown below.  Send users links to SharePoint Online, Dynamics, Power BI, OneDrive, etc. for direct access to those applications.

image

 

User details

By navigating to Azure AD and locating the user we see the following:

Does the user have to be a member? No, they can be a guest as well and still be able to invite users from their tenant.

image

 

Application/Group Assignments

Dynamic groups may also be utilized to automatically add users to a group or groups as well as a group may be assigned to integrated SaaS applications to provide SSO or even provisioning. For example, I have a dynamic group assigned to OneDrive and configured to automatically add any user with the @berntoso.com mail address:

image

 

Any user that has the @berntoso.com email address is automatically assigned to the “Berntoso User Group” which is already associated with a SaaS application.

image

 

To modify what type of permissions guest users, have within your Azure AD tenant navigate to Azure Active Directory and select “User settings”. There we see external user settings as shown in the image below.

For more details, please visit: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-delegate-invitations

image


Converting the user type, i.e. Guest/Member

Although this is optional and really not recommended, however users may be converted from guest to members and vice versa using the “UserType” attribute (although they’re one in the same and typically only changed for identification purposes, e.g. external user vs. subsidiary user). If guest permissions are limited, see image above, you may want to designate certain users as members, so they can add and/or invite users.

Add the user as a member type instead of a guest. If the user is already a guest, you can promote users to member using the following PS command:

Set-MsolUser -UserPrincipalName user_contoso.com#EXT#@contoso.com -UserType Member

For additional details about user properties and UserType scenarios please visit: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-user-properties


Azure AD B2B custom admin and self-service portal

By utilizing Microsoft Graph, organization may create their own Azure B2B admin and self-service portals. For example, the invitation redemption process may be customized to have the user fill out additional fields such as company name, city, state, phone, etc. Those fields will be populated in the corresponding fields in Azure AD for the user. In addition, users must agree to your terms of service before requesting access.  The options for the self-service portal are endless and may be developed to meet your organizations requirements.

 

The sample admin portal provides the ability to add different partner domains as shown below:

image

 

Users who request access via the self-service portal can either be auto approved or added to an a queue for approval as shown below. Admins will then approve or deny the user access.

image

 

For each of the partner domains, additional settings may be added as shown below. I my example below, I auto approve users who sign in with @berntoso.com, users are added as members (not guests), and they’re automatically assigned to groups (dynamic groups may be used instead of group assignments) the admin experience customizable by you and a developer.

image

 

For more details on creating and customizing an Azure B2B admin and self-service portals, including downloading a sample portal please visit: https://github.com/Azure/active-directory-dotnet-graphapi-b2bportal-web

 

Additional developer resources

Create Invitation: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/invitation_post

Invitation Manager: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/invitation

Azure Active Directory B2B collaboration API and customization: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-api

Delegate invitations for Azure Active Directory B2B collaboration: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-b2b-delegate-invitations

 

Conclusion

We covered a lot of details about Azure AD B2B, whether you’re looking to invite business partners or employees from subsidiaries, Azure AD has your collaboration scenarios covered.

Azure AD + 3rd party MFA = Azure AD Custom Controls

 

During Microsoft Ignite there were lots of announcements across a variety of Microsoft offerings including Azure Active Directory.

An interesting feature was released in preview called Custom Controls. Custom Controls allow integration of 3rd party security solutions and in this case, 3rd party multi-factor authentication providers.

I speak with many organizations throughout the year and although many of them are utilizing Azure Active Directory MFA, there are some that either require or prefer to utilize their investment in their current MFA solution.  So the question I’m often asked is, “does Azure AD support 3rd party MFA?”, we’ll I’m happy to say, yes it does.

By utilizing Azure Active Directory Conditional Access and Custom Controls, organizations can integrate their 3rd party MFA solution directly into the access controls to challenge access so customer, SaaS, and app published through Azure AD Application Proxy.


Requirements

  • Azure Active Directory Premium
  • 3rd party MFA solution such as Duo, RSA, and/or Trusona


Creating a custom control

To create a custom control, navigate to portal.azure.com and select Azure Active Directory

Select Conditional Access and then “Custom controls”

clip_image001

 

Next select “New custom control” at the top of the page

clip_image002

 

We’re now asked to paste in JSON for the control. This information provides the details about the 3rd party MFA provider. For example, I have DUO configured and my JSON is below:

Please review instructions your 3rd party MFA provider has published on how to access the JSON to integration with Azure AD.

 

clip_image004

 

Once the custom control for the 3rd party MFA is added, go back to the conditional access policies and create a policy to that will utilize the custom control.

Under Conditional Access select policies and “New policy”:

clip_image005

 

I configured a conditional access policy to use Duo with my Intranet app that is published through the Azure AD Application Proxy. Now I could have simply checked Azure MFA, however the purpose of this post is to demonstrate 3rd party MFA integration.

clip_image006

 

Let’s see it in action

AzureADandDuo

 

To learn more about Custom Controls please see: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-controls#custom-controls