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

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.

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

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/

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.

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

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

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:

1. Goto https://graphexplorer.azurewebsites.net/
2. Login with Tenant Account
3. Run the following query https://graph.windows.net/myorganization/devices
4. 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> 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.

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.