Conditional Access is used to bring signals together to make decisions and enforce organizational policies, recently Microsoft had extended the capability of conditional access for reporting mode as well, You all might know how to put condition access in reporting mode.
The easiest way to monitor the impact of blocking legacy authentication without disrupting users is using Conditional Access report-only mode. Policies in report-only mode are evaluated at sign-in, but the grant controls are not enforced, so you can see who is using legacy authentication in real-time without blocking them. Let me show you how to create conditional access in reporting mode.
How to Create a Conditional Access Policy in Reporting Mode
Login to Azure Ad using URL:https://aad.portal.azure.com/ and under Manage section you can see Security tap on that and this will take you next page were you can create Conditional Access, you can even access conditional access form https://endpoint.microsoft.com/ as well
Identify Apps Using Basic Authentication with Conditional Access | Reports In AzureIdentify Apps Using Basic Authentication with Conditional Access | Reports In Azure
This will take you to the page to create Conditional Access under Protect there are some predefined policies, lets ignore those and create a new one by clicking New Policy.
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
Provide a Name for the policy to Identify it in the future, Select the Users or Group to be included or Select all users, Select the Applications, in this case, I had selected all the applications, in the condition, specify the client apps, we need to select.
Mobile apps and desktop clients
Exchange ActiveSync Clients and Other Clients
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
Make sure you select Report-only mode in Conditional access this will monitor the apps using Basic Authentication once its selected tap on Create to create the Conditional Access.
To determine how many users will be blocked by the policy we can use the new Conditional Access Insightsworkbook which is in Azure Logs and selecting the policy which had been created in Conditional Access this will help us to identify the users and applications details.
How to Fetch the report using Conditional Access Insights
Login to Azure Ad using URL:https://aad.portal.azure.com/ and under the Monitoring section, you can see Workbooks tap and select Conditional Access Insights.
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
Selecting Conditional Access Insights will take you to the next page, which will show the report regarding the conditional access which we had created, Select the Conditional Access Policy, Time rage Last 24 hours or 90 days as per the requirement and other filters as well. This will give Insights about the report and break down to understand what kind of Device state ( Azure Ad registered / Azure Ad Joined / Hybrid Joined ), Device Platform, and Client Apps.
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
Report Using Sign-In Logs in Workbook and using Azure Log Analytics
We can get a similar report using Azure Sign-In logs using Azure Workbook, Navigate to Workbook in Azure and select Sign-Ins before that we need to stream the sign into the workbook tab in the azure ad by Tapping new in the workbook.
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
Here you will see information about which client apps are being used in your organization.
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
You can get the report using Azure Log Analytics writing the query in Kusto Query Language (KQL), Create a new query in logs under Monitor, with the blow you can fetch application using Basic Authentication.
Signings | project UserDisplayName, ClientAppUsed | summarize count() by ClientAppUsed
Identify Apps Using Basic Authentication with Conditional Access | Reports In Azure
Run the query to fetch the report, you can write query as per the requirement.
In this article, I will explain how to identify users using Basic Authentication Microsoft 365 apps in your organization. What is Basic Authentication and why do we need to disable basic authentication? More details about Azure AD authentication is explained in the post.
Identify Clients Using Basic Authentication ( O365 )
Basic Authentication based on where credentials are the base64 encoding of id and password joined by a single colon: is similar like a username and password is provided every time for a request made by the client, that means the client will pass the user name and password with every request which makes easier for attackers to get the user’s credential and it is pron to Password spray attack because it uses a simple HTTP login method to get authenticated.
This is how the login looks like, very familiar right?
Basic Authentication Microsoft 365 Apps for Enterprise
How to Identify users using Basic Authentication Against Microsoft 365 services! yes, this is something interesting to check who and all are connecting to Microsoft 365 resource using basic authentication.
How to Identify Application using Basic authentication using Azure Sign Logs
Let’s use Azure ad sign Logs, what azure sign logs yes you heard it correct, you can use Azure ad sign-in Report to understand basic auth usage in your tenant. Let me explain this is steps.
Step 1: Sign in to the Azure AD portal, you can use the new portal https://aad.portal.azure.com, scroll down and you can see Sign-ins under Monitor
Basic Authentication Microsoft 365 Apps for Enterprise
Step 2: In the sign-in page, you can see Add filters option on the right page > Client app
Basic Authentication Microsoft 365 Apps for Enterprise
Step 3: Once the Client app is selected it will show none selected > tap on that this will provide a drop-down with the list of client apps and segregated as Modern Authentication Clients and Legacy authentication Clients. Select all the applications under legacy authentication clients.
Basic Authentication Microsoft 365 Apps for EnterpriseBasic Authentication Microsoft 365 Apps for EnterpriseBasic Authentication Microsoft 365 Apps for Enterprise
You can select on one of the records to see which Client app is being user in my example Mapi Over HTTP
Basic Authentication Microsoft 365 Apps for Enterprise
You can see all the Client apps using basic authentication > Tap on Download to so you will get the report handy. You should make sure you had selected the client app in the columns to display the app details in the report.
Basic Authentication Microsoft 365 Apps for Enterprise | Office 365 | Azure AD 23Basic Authentication Microsoft 365 Apps for Enterprise
Download Azure Signing Logs to Excel in JSON or CSV format
To download the sign-ins to JSON or CSV format, click on the Download button at the top of the Sign-ins page. If you filter the sign-ins by certain client apps, your download will be based on the filter selections you’ve made.
We recommend downloading to JSON because this format includes all the sign-in details, including user agent. The CSV format will only show the top-level information in each row of the sign-in logs.
Basic Authentication Microsoft 365 Apps for EnterpriseBasic Authentication Microsoft 365 Apps for Enterprise | Office 365 | Azure AD 24
Using the Microsoft Graph API to get sign-ins
If you need to download more than 250,000 sign-in records, you can do so using the audit logs API in Microsoft Graph. you can use the below queries to collect the logs from Microsoft Graph.
In this article, I would be explaining how to manage Android Devices using Intune, before that I will explain a little about Android Device Administration and Android Enterprise. Let’s check out the Android Enterprise Administration migration process using Intune.
My name is Anand, I been working mostly on MS technologies like O365 ( EXO, EOP), Intune, Azure AD, Windows 10, and I love exploring technologies, this is my first post in the HTMD community!
AndroidDevice Administration
Device Administration came into the picture since Android 2.2 and later considered a legacy management approach since Android’s managed device (device owner) and work profile (profile owner) modes were introduced in Android 5.0. Because device admin isn’t well suited to support today’s enterprise requirements, Some drawbacks about device administration
Difficult, error-prone enrolment.
Limited, inconsistent control.
A poor app management experience.
Permissions – management and abuse.
Android Enterprise
Android Enterprise is a Google-led initiative to enable the use of Android devices and apps in the workplace. The program offers APIs and other tools for developers to integrate support for Android into their enterprise mobility management (EMM) solutions. Some benefits of Enterprise administration
Consistent, reliable management
Flexible, simple & safe application management
Zero-day support for new features and functionality
Secure by default
A solid foundation on which to build
Android Enterprise (AE) offers a few things:
A reliable EMM experience, knowing when a configuration is pushed, all AE devices will support and execute the relevant requests.
A containerized work/life separation primarily aimed at BYOD referred to as a work profile.
A fully locked-down, managed mode for complete corporate ownership with no personal space, referred to as fully managed (previously work-managed).
A single-use mode (Android Kiosk, but on a fully managed device) for Kiosk-like applications, referred to as dedicated (previously COSU – Corporately Owned, Single Use).
A combined, COPE mode bringing together fully managed and work profile to provide a fully managed device with personal space (fully managed devices with work profiles).
Out of the box, zero-touch enrolment for Android 8.0 and above (or 7.0 for Pixel).
A managed Google Play portal offering an application store for work devices containing only explicitly approved applications.
Silent application installation without the need for a user-provided Google account on the device.
Managed configs, a way of deploying corporate settings to managed applications (think Exchange profiles, but configurable in Gmail directly. See below).
Mandatory device encryption.
OEMConfig, a means for OEMs to provide additional APIs over and above Android Enterprise easily managed directly through an EMM
BYOD devices can be set up with a work profile—a feature built into Android 5.1+ that allows work apps and data to be stored in a separate, self-contained space within a device. An employee can continue to use their device as normal, all their personal apps and data remain on the device’s primary profile ( Personal Profile )
In this case, the employee’s organization has full management control over a device’s work profile but has no visibility or access to a device’s personal profile. This distinct separation gives enterprises control over corporate data and security without compromising employee privacy.
Company-owned devices for Workers
Intune Android Enterprise
Left one fully managed device, and Right one is a fully managed device with a work profile. In both cases, the enterprise has full management control over the entire device.
There are two deployment options available for these types of company-owned devices: fully managed (Android 5.0+) and fully managed with a work profile (Android 8.0+).
Fully managed deployments are for company-owned devices that are used exclusively for work purposes. Organizations can enforce the full range of management policies on the entire device, including device-level policies that are unavailable to work profiles.
Fully managed devices with work profiles are for company-owned devices that are used for both work and personal purposes. The organization still manages the entire device. However, the separation of work data and apps into a work profile allows organizations to enforce two separate sets of policies. For example:
A stronger set of policies for the work profile that applies to all work apps and data.
A more lightweight set of policies for the personal profile that applies to the user’s personal apps and data.
Company-owned devices for dedicated use
Intune Android Enterprise – Migration Process
The left one is employee-facing scenarios, and the Right one is customer-facing scenarios. Dedicated devices (formerly called corporate-owned single-use, or COSU) are a subset of company-owned devices that serve a specific purpose.
Dedicated devices/Kiosks are typically locked to a single app or set of apps. Android 6.0+ offers granular control over a device’s lock screen, status bar, keyboard, and other key features, to prevent users from enabling other apps or performing other actions on dedicated devices.
Why we must move from Device Administration to Android Enterprise
In many cases, enterprises had demanded more security for android devices and those are not achieved by Device Administration Some of these are:
Separation of work data from personal data in mixed-use or BYOD deployments.
Distribution of business applications and management of their data through Google Play and managing the Google Accounts needed for this.
Locking devices into a kiosk to tailor them for specific application uses.
Certificate management to allow for access to PKI secured resources.
Establishment of per-app and per-profile VPNs to support remote enterprise applications while protecting privacy.
Deprecated policiesof Device Administration
With the release of Android 9.0, the following policies are marked as deprecated when invoked by a device admin, but the APIs otherwise continue to function.
USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD
Starting with the release of Android 10.0, the above-mentioned policies will throw a Security Exception when invoked by a device admin on apps targeting API level 29. Some applications use the device admin for consumer device administration, e.g. locking and wiping a lost device. The following policies will continue to be available to enable this:
USES_POLICY_WIPE_DATA
USES_POLICY_FORCE_LOCK
USES_POLICY_RESET_PASSWORD
How to Migrate Android Devices from Device Administration to Android Enterprise Administration (Intune)
Consider if the current environment is configured for device administration only and we need to move to Enterprise administration, Unfortunately, this process cannot be fully automated. Current Android managed devices needs to be re-enrolled before you can manage them via Android Enterprise
These are some of the use cases which can be taken under consideration if there is a migration plan date is set and compliance policy is set for Enterprise administration
and a compliance policy is set for Enterprise administration
Device enrollment status
Recommended action
Existing device is enrolled in device administration mode and upgradeable to Android Q or 10
Before upgrading the device to Android Q, migrate from device administration mode to Android Enterprise.
Existing device is enrolled in device administration mode. The device can’t upgrade to Android Q or 10
Device can remain in device administration mode. However, plan to move the device to Android Enterprise on device refresh.
Existing device is enrolled in device administration mode and is upgraded to Android Q or 10
Migrate from device administration mode to Android Enterprise before Google deprecates the APIs. A warning message for these devices appears in the Endpoint Management console of Intune
New device delivered with Android Q or 10 and enrolled in device administration mode.
Migrate from device administration mode to Android Enterprise before Google deprecates the APIs. A warning message for these devices appears in the Endpoint Management console of Intune
New device delivered with or upgradeable to Android Q or 10. The device isn’t enrolled.
Use Android Enterprise for any new devices.
New or existing device on Android Q gets enrolled in device administration mode after Google deprecates the APIs.
To avoid the impacts of deprecated Google APIs, it is recommended migrating to Android Enterprise before Google deprecates the APIs. After that date, enrollments of these devices will fail.
New or existing devices enrolled in MAM
No action needed. The deprecated Google APIs have no impact on devices in MAM
Prerequisites for Intune
Users must have Android device administrator enrolled devices with Android Company Portal version 5.0.4720.0 or later.
Set up Android work profile management by connecting your Intune tenant account to your Android Enterprise account.
Set Android Enterprise work profile enrollment for the group of users who are moving to the Android work profile.
Consider increasing your user device limits. When unenrolling devices from device administrator management, device records might not be immediately removed. To provide cushion during this period, you might need to increase device limit capacity so that the users can enroll in work profile management.
Configure Azure Active Directory device settings for the Maximum number of devices per user.
Adjust the Intune device limit restrictions by setting the Device limit.
Different Migration Strategies
Bulk / Cut Over migration: Migrate all existing devices to Enterprise Administration
Create a Compliance Policy in Intune which will make all the devices under device administration will be mark as complaint
Step1:
In the Microsoft Endpoint Manager admin center, select Devices and select Compliance policies to create a new policy. On the Create a policy page, set Platform to Android device administrator and tap on create
Android Enterprise Administration using Intune – Migration Process
Step 2:
Provide a Name for the Policy and tap on Create and in the Compliance settings page, in the Device Health section, set Block devices managed with device administrator to Yes > Next.
Android Enterprise Administration using Intune – Migration Process
Step 3:
Create a custom notification email for non-complaint devices by selecting send emails to end-user. Select the message template (I had explained how to create a message template in below) and tap next and provide the scope tags if there or assign this to the Respective Group, Users or devices according to the deployment plan
Android Enterprise Administration using Intune – Migration Process
In the email, you can include the URL below in your messages to users. The URL will launch the Android Company Portal to the Update device settings page. This page starts their flow to move to work profile management.
Enroll all Android Q or 10 devices to Enterprise administration keeping other devices in Device administration and later when devices are getting upgraded those will get enrolled to Enterprise administration
Step 1: Create a Pilot security group for testing the policies and profiles
The Android Enterprise Profiles / Policies are different from the current Device Admin (legacy) profiles. We need to create completely new policy sets for android enterprises and the policies and profiles need to be tested with the pilot users as this will give more control and won’t create any conflict
The Security group can be created according to the infrastructure if its Hybrid the create a security group on premises and if its only cloud creates the security group in Azure AD
Step 2: Configure the Profiles, Apps and Conditional Access
Second step is to create the new Profiles, Publish the Play Store Managed Apps, App Protection policies and Conditional Access policies in Intune and assigned the pilot group for these policies
Step 3: Configuring the Microsoft Intune Enrollment restrictions to restrict devices to enroll only with Enterprise administration
Create a device enrollment restriction for Android Enterprise users in enrollment restriction page
Step 1:
Navigate to Intune Portal > Select Enrollment Restrictions page > click on Create Restriction to create a new restriction > Device Type Restriction this will take you to create a new restriction
Android Enterprise Administration using Intune – Migration Process
Step 2:
Provide a name for the profile > in Platform Settings you need to block Android Device Administrator > change from Allow to Block
Android Enterprise Administration using Intune – Migration Process
Step 3:
Provide the Pilot Assignment Group in assignments > Review + Create to complete the creation of restriction.
Android Enterprise Administration using Intune – Migration Process
Additional Tips
The Device Restriction will have priority one, you can create Multiple restriction group as per the requirements to allow and block the Platforms.
Android Enterprise Administration using Intune – Migration Process
If we turn this around (block Android, Allow Android work profile), this would mean that every new Android device that enrolls with Microsoft Intune will automatically be enrolled with an Android Enterprise work profile. Because it’s recommended to test the new Android Enterprise configuration first for a selected group of test users, you can leave this as it is for now.
Users who are member of the Pilot / Test group and enroll their Android device with Microsoft Intune get an Android Enterprise work profile pushed.
Users who are NOT member of the Pilot / Test group will still get the old Device Admin profiles
Users in the Pilot / Test group that already have their Android devices enrolled with Microsoft Intune with the Device Admin profiles first needs to un-enroll and re-enroll to get the Android Enterprise work profile.
Conclusion
When Android Enterprise test phase is successful you change the All Users Restrictions profile to block Android and Allow Android work profile. You can also delete the Restriction profile created in Step 3 and the Security group created in Step 1.
After that, every new Android device that enrolls or re-enrolls with Microsoft Intune will then get the Android work profile pushed.
Flow chart to decide which AE Method fits for your organization
