Paul Jones - Microsoft Corporation

Microsoft Intune Device Categories

Paul Jones (MSFT) — Wed, 10 Jan 2018 21:00:32 GMT

Microsoft Intune Device Categories

In this blog post, I am going to cover how to use Device Categories in Microsoft Intune. Device Categories can help with managing devices using Microsoft Intune and Azure Active Directory. This post will build upon my last two blog post on Dynamic Groups - https://blogs.technet.microsoft.com/pauljones/2017/08/28/dynamic-group-membership-in-azure-active-directory-part-1/ I will document (with screen shots) the following steps:

Create Categories in Microsoft Intune
Create Dynamic Groups based on the Categories
Deploy Policies and Apps to Dynamic Groups

Create Categories in Microsoft Intune Console (Azure Portal)

The first step is to create Categories in the Intune Console (Azure Portal). Launch Azure Portal - https://portal.azure.com and navigate to the Intune Blade. Once in the Intune Console, navigate to Device Enrollment and select Device Categories. Click + Create, enter a Name for the Category, then click on the Create button at the bottom of the page. In the screen shot below, it shows where I created 4 different Categories: Virtual Machines, iOS Devices, Android Devices and Physical Machines. I will focus on managing Windows 10 Virtual Machines in this post. Now that we have the Device Categories created in the Portal, we will now move create a Dynamic Group using Azure Active Directory.

Create Dynamic Groups based on Device Category

From the Azure Portal, select the Azure Active Directory blade - choose Users and Groups - select All Groups. This will list all the current Security and Office Groups. At the top of the blade, click + New Group to create a New Group. Enter a Name - I used Windows 10 Virtual Machines for this example. Choose Membership Type - Dynamic Device and finally select Dynamic Device Members - Add dynamic query. Now it is time to add the dynamic membership rule - Under Add Devices Where select the following: deviceCategory Equals then type in Virtual Machines. With those 2 steps: Create Device Category, then Create Dynamic Group, we will now be able to deploy Apps and Polices to devices based on Categories. Now the final step is to deploy Apps and Policies to Dynamic Group.

Deploy Apps and Policies based on Device Category

I will not document the steps to create a Configuration Profile, but I will share a screen shot where I deployed Device Configuration Profile (Windows Defender Firewall) to the Dynamic Group (Windows 10 Virtual Machines) which is based on the Device Category (Virtual Machines). The next screen shot will display deploying an Application (Azure Information Protection) to the same Dynamic Group (Windows 10 Virtual Machines). This concludes my blog post on using Device Categories with Microsoft Intune and Azure Active Directory to help better manage devices.

Dynamic Group Membership in Azure Active Directory (Part 2)

Paul Jones (MSFT) — Tue, 29 Aug 2017 15:58:52 GMT

Dynamic Group Membership in Azure Active Directory (Part 2)

In Part 1 of this series, I covered Creating and Assigning Licenses and Applications to a Dynamic User Group - https://blogs.technet.microsoft.com/pauljones/2017/08/28/dynamic-group-membership-in-azure-active-directory-part-1/. For Part 2 of the series, I will cover Creating Dynamic Device Groups. One of my favorite new features in Azure Active Directory is Dynamic Group Membership. In these blog posts, I will describe the different types of Dynamic Groups that you can create, then assign these Groups (User and Device) to Applications and Licenses. If a user or device satisfies a rule on a group, they are added as a member of that group. If they no longer satisfy the rule, they are removed. I will step through the process in this blog on creating a Dynamic Device Group: The following options are available for Membership Type:

Assigned
Dynamic Device
Dynamic User

For this blog, I will create Dynamic Groups for the following: iOS Devices (iPad and iPhone), Android Devices and Windows Devices. For each one, I selected Dynamic Device under Membership Type. For my dynamic query, I selected the following: Add devices where: deviceOSType equals Android Now, all Devices in Azure Active Directory that are Android Devices will automatically be added to this group. I choose deviceOSType, but you can choose any of the attributes that are registered with each device. I used Azure AD Graph Explorer to view the Device information:

Goto https://graphexplorer.azurewebsites.net/
Login with Tenant Account
Run the following query https://graph.windows.net/myorganization/devices
Results:

"deviceId": "37d6b344-0234-469f-967f-98c975e8d355", "deviceMetadata": null, "deviceObjectVersion": 2, "deviceOSType": "Android", "deviceOSVersion": "6.0.1", "devicePhysicalIds": [], "deviceTrustType": "Workplace", "dirSyncEnabled": null, "displayName": "samsungSM-G900M", "isCompliant": null, "isManaged": null, "lastDirSyncTime": null

The information displayed will depend on if the device is Azure AD Joined, Workplace Joined, Intune MDM, etc...

Another way to find this information is to use PowerShell Command Get-MsolDevice. In this example, I pulled information on a Windows 10 Device.

PS C:\Users\Mike\Desktop>Install-Module MSOnline

PS C:\Users\Mike\Desktop> Connect-MSOLService PS C:\Users\Mike\Desktop> Get-MsolDevice

cmdlet Get-MsolDevice at command pipeline position 1 Supply values for the following parameters: Name: W10A

Enabled : True ObjectId : e815d501-0806-43f2-a725-62823638010c DeviceId : 008d51f8-7fc0-4e8e-95b7-7d0c35a015f1 DisplayName : W10A DeviceObjectVersion : 2 DeviceOsType : Windows DeviceOsVersion : 10.0.15063.540 DeviceTrustType : Azure AD Joined DeviceTrustLevel : Compliant DevicePhysicalIds : {} ApproximateLastLogonTimestamp : 8/17/2017 6:36:22 PM AlternativeSecurityIds : DirSyncEnabled : LastDirSyncTime : RegisteredOwners : {Paul@XXXXXXX.onmicrosoft.com} GraphDeviceObject : Microsoft.Azure.ActiveDirectory.GraphClient.Device

This is the full list of all possible device attributes that can be used:

accountEnabled displayName deviceOSType deviceOSVersion deviceCategory deviceManufacturer deviceModel deviceOwnership domainName enrollmentProfileName isRooted managementType organizationalUnit deviceId objectId

You can also use multiple attributes and operators:

(device.deviceOSType -eq "iPad") -or (device.deviceOSType -eq "iPhone") - this will include all iOS Devices (pictured below)
(device.deviceOSType -eq "Windows") - this will include all Windows devices
(device.deviceOSType -eq "Android") -and (device.deviceOSVersion -eq "6.0.1") - this will include all Android devices running version 6.0.1
(device.deviceOSType -eq "Android") -and (device.isRooted -eq true) - this will include all Android devices that are Rooted

Now that we have created Dynamic Groups, we can use these groups with Azure Active Directory, Intune and Application Deployments. You can create a dynamic group for devices or users, but you cannot create a rule that contains both user and device objects. Device membership rules can only reference immediate attributes of device objects in the directory.

Dynamic Group Membership in Azure Active Directory (Part 1)

Paul Jones (MSFT) — Mon, 28 Aug 2017 16:45:58 GMT

Dynamic Group Membership in Azure Active Directory (Part 1)

In Part 1 of this series, I will cover Creating and Assigning Licenses and Applications to a Dynamic User Group in this blog post. One of my favorite new features in Azure Active Directory is Dynamic Group Membership. In these blog posts, I will describe the different types of Dynamic Groups that you can create, then assign these Groups to Applications and Licenses. If a user or device satisfies a rule on a group, they are added as a member of that group. If they no longer satisfy the rule, they are removed. This is very useful for dynamically provisioning Users into the proper group where they will automatically get the assigned Licenses and Applications based on attributes. Example: A Sales Person gets a new role in the Marketing Department... once that persons title, department or company attribute is changed, they will automatically be removed from the Sales Group(s) and the associated Licenses and Applications, then automatically join to the Marketing Group(s) based on title, department or company and be assigned appropriate Marketing Licenses and Applications. I will first create a Dynamic User Group: I selected Bedrock Users to go along with the Flintstones theme. The following options are available for Membership Type:

Assigned
Dynamic Device
Dynamic User

I for this section, I selected Dynamic User under Membership Type. For my dynamic query, I selected the following: Add users where: city equals Bedrock Now, all users (Local Active Directory and Azure Active Directory) who have City defined as Bedrock will automatically be added to this group. I choose the city attribute, but you could choose many different attributes, including 16 custom attributes. In another demo, I created an attribute on my local Active Directory called LSU Fan, configured Azure AD Connect to sync that attribute, then gave certain applications access to Users if they had a Yes value. Some of the popular attributes are the following:

Company Name
Department
Title
User Type
City
State
Postal Code
Office Name

I used Equals in my Bedrock Users Group, but you are able to use any of the following supported expression rule operators: Here is a screen shot of Fred Flintstone User Profile showing where Bedrock is defined in City attribute: Now, all the Flintstones and Rubbles are members of the Dynamic Group. Now that my group is dynamically populated, I can assign Licenses and Applications to the group. In the caption below, I assigned Enterprise Mobility + Security E5 License to the Bedrock Users Group. In the screen shot below, I assigned Bedrock Users access to the Box Enterprise Application: Now, any User that is created or modified and has Bedrock listed under City will automatically get Enterprise Mobility + Security E5 License and access to Box Enterprise Application. You can also create a group containing all direct reports of a manager. When the manager's direct reports change in the future, the group's membership will be adjusted automatically. For the rule to work, make sure the Manager ID property is set correctly on users in your tenant. You can check the current value for a user on their Profile tab. Under Dynamic membership rules, I created an Advanced rule - Direct Reports for "65ebb1eb-7bf9-49f7-9750-ae1e04471a1a" - now, all of Fred Flintstones Direct Reports will automatically be added to this group. If someone switches Managers, they will automatically be removed from this Group. Fred Flintstones Object ID is 65ebb1eb-7bf9-49f7-9750-ae1e04471a1a and Barney Rubble has his Manager ID populated with Fred's Object ID. This can be set on Local Active Directory using Active Directory Users and Computers: User - Organization Tab - Manager Name. Then the Manager ID will be populated in Azure with the next AD Connect Sync. If this is a cloud only account, then Manager ID will have to be populated manually. Direct Reports is not listed as an attribute in the drop list but does work and is supported - https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-dynamic-membership-azure-portal The Dynamic Group feature is an Azure Active Directory Premium feature which is included with Enterprise Mobility + Security Suite and Microsoft 365 Suite. You can create a dynamic group for devices or users, but you cannot create a rule that contains both user and device objects. This is the conclusion of Part 1 of 2 Blog Posts on Dynamic Group Membership in Azure Active Directory. Next, I will create Part 2 to cover creating Dynamic Device Groups and using Advanced Dynamic Membership Rules - https://blogs.technet.microsoft.com/pauljones/2017/08/29/dynamic-group-membership-in-azure-active-directory-part-2/. Thank You, Paul Jones

Implementing Conditional Access with Exchange Online (updated using Azure Portal)

Paul Jones (MSFT) — Wed, 28 Dec 2016 02:25:04 GMT

Implementing Conditional Access with Exchange Online (updated using Azure Portal) I am updating this blog post using the new Conditional Access features in the Azure Portal. The new portal is accessed from https://portal.azure.com. I will demo using Exchange Online; however, these same steps can be used with all other Software as a Service applications in Azure. Conditional Access will check the following: User / Risk Application Location Device / Device State After checking the appropriate conditions, a decision will be made to either Allow, Block or require Multi-factor Authentication (MFA). If the User Account or a Risky Sign-On is detected, then we can force a password change or force Multi-factor Authentication. I will go through this process using my Windows 10 Virtual Machine. However, this will apply to not only Windows, but iOS and Android. Step 1: Accessing Exchange Online I will now go through the steps to access Exchange Online from a web browser. I go to https://outlook.office.com and authenticate: After authenticating I now have access to my email. Step 2: Enable Location Based Rules In this step, I will check who the User is and Based on the Users Location will require MFA, Allow or Block access to Exchange Online. I have 3 different options:

Require multi-factor authentication
Require multi-factor authentication when not on Trusted IPs (aka Work)
Block access when not at work

For this step, I will choose Block access when not at work. Open the Azure Portal from https://portal.azure.com and select Azure Active Directory. Then select Conditional Access and click Add to create a Location Based Policy. In the Name field I entered: Exchange - Block when not at work. Under Assignments, I selected All Users from Users and Groups. Then from Cloud apps, under the Include Tab, I chose Select Apps and then only selected Office 365 Exchange Online. As you can notice from the list, you can pick other Applications to add to this policy. Next I will select the Conditions to apply. I want this policy to apply to All Devices, so I will not configure any Device Platforms. Next, select Locations and under Configure select Yes and under Include tab, choose All locations. Then choose Exclude tab and select All Trusted IPs. This configuration will block all devices that are not on a Trusted IP. Finally, for Controls, select Block access. Now, all Users will have access Blocked when trying to connect from a non Trusted IP address. This completes the creation and deployment of the policy to Block Access from devices that are not on a Trusted IP. This is a screen shot that a user will receive when trying to access Exchange Online from a non Trusted IP Address: PAJ

Implementing Conditional Access with Exchange Online

Paul Jones (MSFT) — Tue, 29 Nov 2016 20:28:39 GMT

Please see updated post using new Azure Portal - https://blogs.technet.microsoft.com/pauljones/2016/12/27/implementing-con…e-online-updated/ In this Blog Post, I will step through the process to enable the different features of Conditional Access for Office 365 Exchange Online. However, these same steps can be used with other Software as a Service applications in Azure. Conditional Access will check the following:

User / Risk

Application

Location

Device / Device State

After checking the appropriate conditions, a decision will be made to either Allow, Block or require Multi-factor Authentication (MFA). I will go through this process using my Windows 10 Virtual Machine. However, this will apply to not only Windows, but iOS and Android. Step 1: Accessing Exchange Online I will now go through the steps to access Exchange Online from a web browser. I go to https://outlook.office.com and authenticate After authenticating I now have access to my email. Step 2: Enable Location Based Rules In this step, I will check who the User is and Based on the Users Location will require MFA, Allow or Block access to Exchange Online. I have 3 different options:

Require multi-factor authentication
Require multi-factor authentication when not at work
Block access when not at work

For this step, I will choose Block access when not at work. Go to https://manage.windowsazure.com and choose your Domain Name then Applications then Office 365 Exchange Online. Once inside Office 365 Exchange Online, go to Configure and Click ON next to Enable Access Rules under multi-factor authentication and location based access rules. Then select Block access when not at work. Now when I try to access https://outlook.office.com from outside of work, I will get Blocked from the Access Rule and the following explanation will be posted. Step 3: Enable Device Based Access Rules Follow the same steps to Configure Exchange Online, a little further down, Select ON for Enable Access Rules under Device Based Access Rules. Then select either All devices or Only selected devices must be compliant, other devices will be allowed access. For this demo, I just chose Windows and select Windows devices are compliant when domain joined or marked as compliant. Now when I go to https://outlook.office.com I will get the following message stating that the device must be domain joined compliant: Now I have stepped through the process for enabling Conditional Access for Exchange Online. Conditional Access was given or denied based on the following steps:

Who is the User?
Where is the User Located?
Which Application is the User trying to Access?
Which Device is the User using?
Is that Device Compliant (domain joined or marked as Compliant via Microsoft Intune)?

However, just remember that this can be used for any of the other Azure Applications. Conditional Access is a feature of Azure Active Directory Premium and utilizes Microsoft Intune for Mobile Device Management.

Microsoft Cloud App Security - Threat Detection

Paul Jones (MSFT) — Tue, 13 Sep 2016 21:19:38 GMT

Cloud App Security provides threat protection for your cloud applications that’s enhanced with vast Microsoft threat intelligence and research. Identify high-risk usage, security incidents, and detect abnormal user behavior to prevent threats. Cloud App Security helps you to stay ahead of attackers. You can identify anomalies in your cloud usage that may be indicative of a data breach. Cloud App Security advanced machine learning heuristics learn how each user interacts with each SaaS application and, through behavioral analysis, assesses the risks in each transaction. This includes simultaneous logins from two countries, the sudden download of terabytes of data, or multiple failed login attempts that may signify a brute force attack. In this blog post, I will show how to identify and report on Users logging on from Risky IP Addresses outside of the United States. From the Cloud App Security Console, Select Investigate and choose Activity Log. For the full blog post, please visit my team site - https://blogs.technet.microsoft.com/scdsec/2016/09/13/cloud-app-security-threat-protection/

Microsoft Cloud App Security - Part 1

Paul Jones (MSFT) — Mon, 22 Aug 2016 18:15:38 GMT

Microsoft Cloud App Security (CAS) – https://www.microsoft.com/en-us/cloud-platform/cloud-app-security Part 1: Credit Card Numbers In this blog post, I am going to cover how to setup alerts and enforce Data Loss Prevention when a file containing credit card number is detected in a sanctioned cloud app. A sanctioned app is a cloud application that has been approved in the Cloud App Security console. You can read the entire blog post from here - https://blogs.technet.microsoft.com/scdsec/2016/08/22/microsoft-cloud-app-security-part-1-credit-card-numbers/ Thanks, Paul

How to setup Azure SQL Integrated Authentication

Paul Jones (MSFT) — Mon, 08 Feb 2016 08:19:14 GMT

How to setup Azure SQL Integrated Authentication

Error: “Could not discover endpoint for Integrate Windows Authentication” when attempting Active Directory Integrated Authentication

Details of error message:

Failed to authenticate the user NT Authority\Anonymous Logon in Active Directory (Authentication=ActiveDirectoryIntegrated).

Error code 0xCAA90022; state 10

Could not discover endpoint for Integrate Windows Authentication. Check your ADFS settings. It should support Integrate Widows Authentication for WS-Trust 1.3. (Microsoft SQL Server, Error: 0)

Image:

Caused: Caused when attempting “Active Directory Integrated Authentication” from the SQL Management Studio using ADALSQL with default ADFS Settings.

Reason: By default, ADFS does not enable Integrated Windows Authentication for WS-Trust 1.3, as shown below:

Solution: Enable Integrated Windows Authentication for WS-Trust 1.3 for the Transport Security Mode and if desired, enable for Proxy access, as shown below:

Upon enabling the setting you can log into SQL Azure, using Active Directory Integrated Authentication, and verify that, if your account has permissions, you can access SQL Azure without an id or password.

How to publish an internal web application using Microsoft Azure

Paul Jones (MSFT) — Wed, 22 Jul 2015 14:16:00 GMT

How to publish an internal web application using Microsoft Azure

In this blog post, I will detailed the steps on how to publish an internal web application using Microsoft Azure. I will publish an internal Self Service Portal for MBAM (Microsoft BitLocker Administration and Management). This Portal is used to generate BitLocker Recovery Key if you are locked out of Windows by BitLocker.

Step 1: Enable Application Proxy on your directory

Select your Directory, then select Configure. Scroll down and click on Enabled

Step 2: Establish connectivity with the network

From your internal server, select Download and install the Application Proxy Connector on your network. Select Download now.

Run the install and follow the wizard. I installed Application Proxy Connector on my MBAM Web Server, but it is not required to be installed on the same server. Once the install completes successfully, you are ready to Add an Application.

Step 3: Add an Application

Login to Microsoft Azure - https://manage.windowsazure.com. Select your Directory (mine is called Oakbourne Enterprises), then click on Applications button at the top of the page.

Select Add at the bottom of the Application page. Select Publish an application that will be accessible from outside your network.

Name: MBAM Self Service Portal

Internal URL: http://mbam.contoso.org/selfservice

Preauthentication Method: Azure Active Directory

Step 5: Assign Users

From your list of Applications, select your application, then click on Users and Groups. Select appropriate Users and/or Groups for the application to show up in the user's application list.

Note: This only affects application visibility.

Step 6: Configure Application SPN

Note: The Application Proxy and Web Site are on the same server - MBAM.contoso.org

Select Configure at the top of the page, scroll down near the bottom of the page and enter Internal Application SPN: http/mbam.contoso.org (it is not a typo that I used http/servername).

If a HTTP SPN is not already configured for server, it will have to be set using SETSPN command. To check and set if necessary, follow these commands from your webserver:

This will list all registered SPN for this server. SETSPN -L (enter server name) - example: setspn -l mbam

You should see a line containing HOST/MBAM.contoso.org - If not, proceed to Add a SPN.

If a HTTP SPN is not set, follow this command to create one:

SETSPN -S HTTP/ServerName Servername - example: setspn -s http/mbam mbam

Step 7: Configure Server Delegation

Launch Active Directory Users and Computers - find your Server, open Properties and select Delegation tab. Select Trust this computer for delegation to specified services only. Then select Use any authentication protocol, finally click Add button. Select your server, choose http mbam.contoso.org.

Finally, logon to Azure AD Portal to launch your Application - https://myapps.microsoft.com. Click on MBAM Self Service icon to launch.

Note the differences between the URLs

External Azure: https://mbamselfserviceportal-oakbourne.msappproxy.net/selfservice

Internal Network: http://mbam.contoso.org/selfservice

Advanced Customization of ADFS for Cloud Usage (Part 4 of 4)

Paul Jones (MSFT) — Tue, 26 May 2015 08:58:00 GMT

Advanced Customization of ADFS for Cloud Usage Written by Kevin Saye This is part 4 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page	Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.
Part 2 – Using Cloud or on Premises MFA	What changes happen in the claims and how to control where MFA takes place.
Part 3 – User Certificates	Enabling enrollment and usage of user certificates for ADFS.
Part 4 – Expired passwords and locked out accounts	How to detect and address users with expired passwords or locked out accounts.

Part 4 – Expired passwords and locked out accounts Expired Passwords are a part of life. For corporate users, they often log in using Windows, and Windows will give them (by default) a 14 day warning. ADFS, because it is exposed to the hostile internet, is not so friendly by default. Windows Server 2012 R2 ADFS addresses passwords that expired, as show below: ADFS, for security reasons, does not address account lockout, as shown below:
Because this error message above can be for many reasons or could be a brute force attack, addressing this error can vary based on company policy. If you want to enable the end user to reset their password using Azure Active Directory Premium’s Reset Password (https://passwordreset.microsoftonline.com) we can notify or automatically redirect the user to the reset site. Using JavaScript, we can detect the “errorText” is not null and take action. My example below ask the user if they need help resetting their password and will redirect them to the Reset Password Site. You can modify as you see fit.
The HTML I used to set this up is included below: The PowerShell command to configure this is: Set-AdfsGlobalWebContent -SignInPageDescriptionText ""