Azure AD Geolocation by sign-in activity using Power BI

 

If you’re an Office 365 customer or even an Azure customer then you’re probably familiar with Azure Active Directory (or Azure AD).  Azure AD is the core identity provider that the majority of Microsoft services rely on for authentication.  For today’s post I thought it would be interesting to pull sign-in activity into Power BI and show how simple it is to display a dashboard of geolocated sign-ins by user and device.

 

Assumptions

The user creating Power BI reports has an Azure AD Premium and Power BI licenses assigned

Note, if a new user account was recently created, I recommend waiting a day for the sign-in data to fully populate otherwise no sign-in data will be present.  Check the Azure AD Premium admin portal for sign-in activity for the user periodically.  Once the sign-in data is present, refresh the Power BI dataset connection to pull it into Power BI.  More details here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-faq

 

First we’ll need to sign into Power BI and pull in the Azure AD Activity Logs Content Pack.  Do this in Power BI by selecting Get Data, Services (Get), then search for Azure.  Select Azure Active Directory Activity Logs (Preview) from the search results and provide your Azure AD domain name and then select next.

Once the Azure Active Directory Activity Logs (Preview) content is added we can begin to create a dashboard.  From the Power BI UI find the “Azure Active Directory Activity Logs” under Dataset and select it.  Under “Visualizations” select Map and under “Fields” expand “Signin Activity” and select City, Country, Name, and Total Signins.  Without any further modifications your map should look similar to the following:

 

image

 

Feel free to play around with the data to get the information you find most interesting or better yet, what your security team will find most interesting.  Hover over the data circles to display additional information about the data point.

 

Now a map of sign-ins may be all that is required, however I went a step further and created two slicers to drill in on certain data points.  To add slicers, select the Slicer image from under Visualizations from under Fields expand “Unique Users” and then select “Details.Name”.

 

image

 

To add another slicer, repeat the process from above, only instead of expanding Unique Users, expand “Signin Activity” and then select “Device Information”

image

 

Adding slicers enables me to check mark interesting information and drill down on that specific data point.  Pulling it all together the final dashboard looks like the following:

image

 

If I want to hone in on a specific data point, all I need to do is select either a data point under one of the slicers as shown in the gif below:

AADSigninPowerBI

 

Update
Add a slicer for date and time to show time based sign-in activity:

2017-03-30

This was just a simple method of creating a Power BI report that show’s a lot of rich data points that may help you understand where your users are logging in across the globe from what browser or device.  In addition, use the Azure AD Premium to create conditional access policies to protect user identities, corporate information, and block malicious devices, apps, and browsers from unsecure locations.

Azure Active Directory + O365 Conditional Access Scenarios Explained

Hi everyone, with all the cross integration between Azure Active Directory and Office 365 it time to explain these conditional access in detail.  While Office 365 offers a level of controls by service, Azure Active Directory and Microsoft Intune can come over the top of those services an provide further controls or leverage conditional access controls configured already in O365. 

Let’s dive into a few of these scenarios.

 

Device/App based conditional access with Microsoft Intune

Microsoft Intune offers various levels of conditional access based on device and app state.  Conditional access policies may be set on whether or not a device is enrolled with Intune (i.e. MDM) or if the designated application is being used to access email (e.g. Outlook app vs. native email apps).  Additional controls of may be applied based on what type of app is allowed to access the service be that a web browser or a native application.  There are even application policies that may be applied to a mobile app to further control where data is moved, saved, etc. (i.e. Intune Mobile Application Management).

There are a wealth of conditional access controls available within Intune that may be used to protect company information from leaking.  The device based controls go beyond O365 services to 3rd party mobile apps, customer apps, on premises web apps, and 3rd party SaaS applications.

Intune also has integration with a number of 3rd party security and mobile defense partners such as Lookout, Citrix, Cisco ISE, and Skycure

 

O365 per app Conditional Access

One of many Azure Active Directory (Azure AD) differentiators from other identity providers (idps) is Azure AD can carve up O365 and apply Conditional Access (CA) policies on a service by service basis.  For example, a CA policy such as requiring Multi-Factor Authentication (MFA) can be applied to Exchange Online while leaving SharePoint Online without a CA policy (e.g. not prompt for MFA or allow a certain device type to access).  Azure AD can also apply conditional access policies on a per app basis for 3rd party SaaS apps and internal web apps via Azure AD Application Proxy.


SharePoint Online limited access

This is a new feature currently in preview, however it’s a form of Conditional Access.  Coupled with Azure AD Conditional Access policies, SharePoint Online access may be granted to browser based sessions with additional service/app restrictions configured through SharePoint Online.  For example, if the policies are configured in both services, and an end user attempts to access SharePoint Online on a device that isn’t enrolled with Microsoft Intune and/or SharePoint Online site is viewed as an unsecured device, the user will only have read only access.  In addition, download, print, and sync may be blocked as well.  This type of policy allows users to continue to be productive regardless of what type of device or browser being utilized.  Note: SharePoint on-prem is not supported.

The following is an example from my environment using Tor browser.  The user will receive a notification at the top of the SharePoint Online Page when accessed from an unsecured device or browser and block downloading and printing of content.  In addition a conditional access policy in Azure AD can be set to block access completely if needed.

clip_image001

 

OneDrive for Business and Mobile Application Management (MAM) in service features

A number of new device based access settings have been deployed directly to the OneDrive for Business (OD4B) service.  One of those is Mobile Application Management (MAM).  To utilize the MAM settings within OD4B an Intune license is required.  The MAM settings also are one in the same as those in Intune which means that if they’re enabled in OD4B they’ll show up in Intune and vice versa.  However, MAM settings in Intune will override those set in OD4B admin portal.

clip_image002

 

In summary, these features are all market differentiators and allow O365 and SPE or EMS customers to create unique sign-on and device based access scenarios on a per app basis across O365, 3rd party SaaS apps, and on-premises web applications.

 

When utilizing Office 365 I encourage everyone to consider the Enterprise Mobility and Security offering.

Azure AD Security – Protect Those Accounts, Services, and Audit Access!

Everyday I’m asked questions about Enterprise Mobility + Security as well as other Microsoft services. I’m also asked how we can provide single-sign on to SaaS and on-premises applications using Azure AD Premium. What surprises me though is how few organizations ask me about providing additional protection layers to protect accounts as well as the services themselves from credentials that have been compromised (unless I bring the topic up).  However, not a day goes by where I’m not asked about second factor authentication (i.e. Multi-Factor Authentication). Although MFA is extremely important and I highly recommend turning it on and testing within your organization, there are other important security mechanisms that can be turned on as well.

As you may have heard, identity is the new control plane, meaning protection starts at the account.

Azure AD Identity Protection

Do you have cloud only accounts or are you synchronizing your Active Directory accounts to Azure AD (e.g. O365, Dynamics CRM, etc.)? If you’re using O365 then you are, regardless of what identity provider you’re using. Azure AD Identity Protection can help you secure those identity today.

In a previous post I walked through setting up and implementing Azure AD Identity Protection, however below is a video where in the first half I log in as a user using a Tor browser and I’m able to access the service without challenge. In the second half, I turn on identity protection and when I attempt to sign on using a Tor browser, I’m challenged with multi-factor. A simple sign-on policy can protect you and your users from irregular sign-on activity and stolen credentials.

 

Azure AD Identity Protection Demo

Azure AD Privileged Identity Management (PIM)

Protecting the account itself is in my opinion non-negotiable and if you’re using Azure, O365, Dynamics CRM, Intune, or any other Microsoft services that leverage Azure AD, I highly recommend turning on Azure AD Identity Protection. However, what about protecting access to the service itself? You can by using Azure AD Privileged Identity Management.

What is Azure AD Privileged Identity Management?

Organizations want to minimize the number of people who have access to secure information or resources, because that reduces the chance of a malicious user getting that access. However, users still need to carry out privileged operations in Azure, Office 365, or SaaS apps. Organizations give users privileged access in Azure AD without monitoring what those users are doing with their admin privileges. Azure AD Privileged Identity Management helps to resolve this risk.

Azure AD Privileged Identity Management helps you:

  • See which users are Azure AD administrators
  • Enable on-demand, “just in time” administrative access to Microsoft Online Services like Office 365 and Intune
  • Get reports about administrator access history and changes in administrator assignments
  • Get alerts about access to a privileged role

Azure AD Privileged Identity Management can manage the built-in Azure AD organizational roles, including:

  • Global Administrator
  • Billing Administrator
  • Service Administrator
  • User Administrator
  • Password Administrator

Source

However, those are not the only roles available, did you know Exchange Online, Skype for Business, Intune, and many other roles are available as well? Which means global admins can protect access to elevated admin permissions and require admins to request access as well as provide additional info before their credentials are elevated.

More details about additional roles available in Azure AD PIM here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-privileged-identity-management-roles

The following video steps through a user elevating permissions to access the admin console for Skype for Business using Azure AD Privileged Identity Management. The user is only allowed one hour to accomplish their task (global admin can adjust the policy to span 1 to 72 hours if needed per role), once the one hour is up, the user would need to go through the process again to elevate their account permissions.

Azure AD PIM Demo

Reporting

Reporting on identity and access is critical as well. It’s important to have systems in place to protect identities and services, however it’s equally important to have insight as to who’s accessing the services, from where, from what, how, and when. Last week the Azure AD team announced an Azure AD content pack for Power BI.

Here are a few reports from a fresh environment I’ve created:

image

image

image

For more details on how to get started with Azure AD and the Power BI content pack please visit: https://powerbi.microsoft.com/en-us/blog/azure-active-directory-meets-power-bi/preview/

I encourage everyone to start protecting your identities and services today. There’s always going to be risk, why not reduce the risk by implementing safeguards to prevent unchallenged access.

Azure AD Identity Protection

With all the news about cyber-attacks and data leakage and stolen credentials, it’s important that a multilayered security approach is in place no matter how small or large the organization. Even as individuals, implementing a multilayered security approach for our personal accounts is beneficial (e.g. two-factor authentication).

I’ve posted in the past about Microsoft Advanced Threat Analytics (ATA) and Cloud App Security and how both solutions provide insight, alerts, and governance across on premises and cloud applications. Identities are the new control plane and securing them beyond just a password is a priority among many organizations I work with. If an identity is stolen, the person or even company is at risk for losing precious personal info and intellectual property which can have devastating financial implications that are difficult to recover from.

What keeps me up at night is that my customers may be at risk for leaked identities and other security vulnerabilities, so I do my best every day to educate them about threats and solutions Microsoft provides to assist with detection and remediation of these types of vulnerabilities and attacks.

Now I understand that there is no single fix or silver bullet to prevent attacks from happening. Security is typically implemented in a layered approach which is why Microsoft has invested significantly in multiple security oriented organizations over the past few years as well as ramped up their own solutions. See details here: https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-products

In my opinion, every organization should assume compromise, whether it’s a legitimate employee accessing information they shouldn’t by accident or a hacker that’s been sitting quietly monitoring network traffic for clear text passwords or by using a user name password acquired by social engineering. No matter what the scenario, it’s important to be notified of such occurrences. In my previous posts you’ll find Microsoft ATA and Cloud App Security look for user and entity behavior analytics (UEBA) as well allow for direct API access into well know services such as Office 365, Salesforce, Box, and so on. But what happens when credentials are leaked? How do you know when a user signs in from another part of the globe if it’s really them?

To combat against stolen credentials, Microsoft has released a solution called Azure AD Identity Protection that will assist with protecting user identities from being utilized in an unsecure manner. Based on the risk level, Azure AD Identity Protection will take appropriate action (based on a risk profile) such as requiring a user the change their password or by forcing multi-factor authentication.

First we need to define the types of risks events Azure AD Identity Protection detects today:

Leaked credentials Typically, when a breach occurs, credentials are sold or accessed on the dark web and used in attempt to access services.
Impossible travel to atypical locations Multiple sign-in’s from different locations across the globe.
Sign-ins from infected devices Device infected with malware that communicate with a bot server.
Sign-ins from anonymous IP addresses Typically done by proxying, for example using Tor browser.
Sign-ins from IP addresses with suspicious activity IPs which a high number of failed sign-in attempts occurred.
Sign-ins from unfamiliar locations Uses past sign-in locations to determine unfamiliar location.
Lockout events (not in public preview)

Read more about risk events here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection-risk-events-types/

Setting the risk detection levels

Now that we have an understanding of the type of risks detected, we need to set the risk level. Risk levels can be set as High, Medium, or Low.

There are two types of risk levels, User risk and Sign-in risk:

  • User risk indicates the likelihood that the user’s identity has been compromised.
  • Sign-in risk indicates the likelihood that someone other than the account owner is attempting to sign-on using the identity.

To set the risk detection levels navigate to https://portal.azure.com and sign-in with your administrator credentials (you have MFA enabled for all Azure admins right? 🙂 ).

Quick Tip: To further protect azure administrator accounts further see Privileged Identity Management.

To add Azure AD Identity Protection, select “New” on the left hand navigation bar, then type in “identity” then select “Azure AD Identity Protection” from the search results.

clip_image001

clip_image003

This will open a new blade, select “Create” at the bottom of the blade:

clip_image004

On the next blade, select “Create” again:

clip_image005

Once created you’ll see the following blade:

clip_image007

From here we’ll need to configure Azure AD Identity Protection so the service can start detection. Under “CONFIGURE” on the left hand side, select “User risk policy”. There are multiple options on the new blade to configure, mainly what users the policy will assigned to, the risk condition (High, Medium, Low), controls (require MFA or password change or both), and enforcing the policy by turning on or off.

Note: I recommend starting with a small subset of users to learn more about the user experience when an account is at risk.

clip_image008

For example, in my environment I have my user risk policy configured as follows:

Users

clip_image009

Conditions

clip_image011

Controls

clip_image012

Note: My sign-in risk policy is identical to my user risk policy.

For MFA, I require my users to register for MFA.

Analyzing the results

As the service begins to monitor it will begin to detect risks as shown below. I used a Tor browser to kick off events because the Tor browser will proxy through different parts of the globe. So it will simulate impossible travel and so on.

clip_image014

When I investigate by selecting the options below “INVESTIGATE” is see I have a couple users at risk and users that I’ve remediated. For these particular users who are flagged for risk, I can allow them through if I think their sign on is legitimate.

clip_image016

Here are the risk events that Azure AD Identity Protection has found:

clip_image018

Here are the Vulnerabilities Azure AD Identity Protection has found:

clip_image020

Clearly I need to go in and remove a few administrators from my demo environment, however with Azure AD Identity Protection, I’m made aware of these issues and vulnerabilities and I can take action.

End user experience

When an end user signs into Office 365 using a Tor browser they’ll have the following experience:

clip_image022

Select “More details”

clip_image024

Here is shows additional details about the app, device, and user:

clip_image026

Accessing Azure AD Identity Protection via Microsoft Graph API

For those who are interested in pulling the raw data out to import into their SIEM or BI you’ll want to look at the APIs for Azure AD Identity protection in Microsoft Graph: https://blogs.technet.microsoft.com/enterprisemobility/2016/08/02/apis-for-azuread-identity-protection-are-now-available-in-the-microsoft-graph/

Here I log into my MSOL account via PowerShell:

clip_image028

Then I ran a PowerShell script (example) to list all the risk events as shown below:

clip_image030

For a more readable format you can change the formatting of the raw output:

clip_image032

 

Or group by “location” for example…and so on:

clip_image002

To learn more about Azure AD Identity Protection, please visit: https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection/

Microsoft Cloud App Security

 

Have you ever wondered what is going on within the SaaS services your organization is using?

Are you curious about what unsanctioned SaaS apps employees may be storing company data in?

Do you want to know where and when sensitive data is stored in the cloud?

Do you want to know who’s accessing sensitive data in the cloud?

 

If you’re like me, those questions are top of mine when create a new cloud subscription and giving up control is sometimes difficult to do.  However, with Microsoft Cloud App Security you don’t have to give up control or visibility into SaaS based services anymore.

 

What is Cloud App Security?

Microsoft Cloud App Security is a comprehensive service that provides deeper visibility, comprehensive controls, and improved protection for your cloud applications. Cloud App Security is designed to help you extend the visibility, auditing, and control you have on-premises to your cloud applications.

Cloud App Security is a critical component of the Microsoft Cloud Security stack. It is a comprehensive solution that helps organizations take full advantage of the promise of cloud applications while maintaining control with improved visibility into activity. It also increases protection of critical data across cloud applications. With tools to help uncover Shadow IT, assess risk, enforce policies, investigate activities and stop threats, organizations can safely move to the cloud while maintaining control of critical data.

Source: https://technet.microsoft.com/en-US/library/mt489024(TechNet.10).aspx

 

The architecture of Cloud App Security is shown in the image below:

clip_image001

Image Source: https://technet.microsoft.com/en-US/library/mt489024(TechNet.10).aspx

 

Getting started with Cloud App Security

In the past, setting up security solutions required hardware and software, firewall configuration, etc. All things that require time and money to implement. However, with Cloud App Security setting it up is straight forward. Simply logon or start a trial of Office 365 and enable a trial of Cloud App Security from the O365 admin tenant.

More details here: https://technet.microsoft.com/en-us/library/mt657569.aspx

 

Using Cloud App Security

Once the Cloud App Security subscription is live, login to the admin portal and get a feel for the interface.

A fresh Cloud App Security interface won’t have any data in it, however mine does, as shown below:

image

The dashboard provides an overview of activities, alerts, and violations. Select any of the items to drill down for more information. On the left we see apps that are sanctioned and threat detections (I’ll cover this later in the post).

 

Application Discovery

Most organizations I speak with want to know who’s using what cloud applications and how much corporate data is being stored in sanctioned and unsanctioned cloud applications. Cloud App Security offers a method to manually or automatically (via log collectors), import traffic logs from network devices. By ingesting traffic logs into Cloud App Security you’ll gain visibility of cloud application and data usage.

See a list of supported network devices here: https://technet.microsoft.com/en-US/library/mt489024(TechNet.10).aspx

Here’s an example of what Cloud App Security found when I uploaded a network log file:

SNAGHTML1f1eafcd

Based on the log file, Cloud App Security discovered 512 applications in use across the organization with only 7 of these sanctioned by the admin within Cloud App Security. In other words, 98% of the cloud applications discovered are unsanctioned applications. Let’s see how many of those applications are risky.

Notice on the left the term “Score”, the lower the score the riskier the application. So if an application has a score of 1 it’s potentially bad, but if it has a score of 10, the app is general well known, and marked as safer.  The scoring takes the information provide in the application and averages it.

Also, by looking at the results I can see that there are two cloud storage providers in use, OneDrive and Box. So as a company, a decision will need to made on what cloud storage provider to standardize on, then monitor usage in Cloud App Security over a period of time to make sure users are moving to the sanctioned cloud storage provider.

image

 

Looking at a risky application we see the following information. Compare a risky application with that of an application that have a higher score. Note that with the riskier application, little is known about the vendor and this application clearly does not meet any compliance regulations. However, if you find something to be incorrect, the setting and scoring can be manually changed.

image

 

What about off network devices?

If you’re interested in agent based application discovery that is integrated with Azure Active Directory, please visit: http://social.technet.microsoft.com/wiki/contents/articles/30962.getting-started-with-cloud-app-discovery.aspx – completely separate from Cloud App Discovery at this time.

 

Application Integration via API

Cloud App Security offers several applications that monitored and accessed via a direct API. For example, Office 365 and Salesforce.com have API integration directly with Cloud App Security (and there many more apps that have API integration as well, see https://technet.microsoft.com/en-us/library/mt657563.aspx).

The advantage of having direct API integration is gaining visibility and control over the service. Do you recall at the beginning of this post I stated that I don’t like to give up control much? Cloud App Security gives control back.

For example, I have Salesforce.com configured with SSO using Azure Active Directory (Azure AD). I also do what’s called user provisioning into Salesforce.com with Azure AD, so as users are created in my on-premises AD environment, they are synchronized up to Azure AD. If there is the attribute of “Sales” in the “department” field of the AD user object, those users are automatically added to a Salesforce corporate group I created in Azure AD (this is called dynamic group membership). Once users land in that particular group they’re automatically provisioned into Salesforce.com. However, I still like to know when users are provisioned and de-provisioned from my SaaS services (e.g. Salesforce.com). In Cloud App Security I configured a policy that tracks account activity in Salesforce.com.

 

Let’s take a look at policies in Cloud App Security

From the Cloud App Security admin portal, at the top select Control and Policies from the dropdown menu:

image

In my environment I’ve configured a few policies as shown below:

image

 

To create a policy, select “Create policy” in blue and select the type of policy you’d like to create:

Let take a moment to learn about the types of polices in the list before creating a new policy:

Activity Policy

Activity policies allow you to enforce a wide range of automated processes leveraging the app provider’s APIs. These policies enable you to monitor specific activities carried out by various users, or follow unexpectedly high rates of a certain type of activity.

Anomaly detection policy
Anomaly detection policies enable you to look for unusual activities on your cloud based on the risk factors you set here to alert you when something happens that is different from either the baseline of your organization or from the user’s regular activity.

App discovery policy
App discovery policies enable you to set alerts that notify you when new apps are detected within your organization.

Cloud Discovery anomaly detection policy
Cloud Discovery anomaly detection policies look at the logs you use for discovering cloud apps and search for unusual occurrences. For example, when a user who never used Dropbox before suddenly uploads 600 GB to Dropbox, or when there are a lot more transactions than usual on a particular app.

File policy
File policies enable you to scan your cloud apps for specified files or file types (shared, shared with external domains), data (proprietary information, PII, credit card information, etc.) and apply governance actions to the files (governance actions are cloud-app specific).

image

 

For the purposes of tracking Salesforce.com account activity I chose “Activity policy” from the menu. Within the policy creation page, I configured a number of fields as shown below. Basically the policy says, I want to be alerted when users are added to Salesforce.com. This helps me keep track of who’s using the service without having to log into Salesforce.com or Azure AD to find out. It’s a simple policy, but effective and gets me the info I need.

image

Because this is a fresh policy there is the option at the top to select from a pre-canned list of policy templates or create your own templates as shown below:

clip_image018

More details here: https://technet.microsoft.com/library/mt657556.aspx

 

Once a user is created in Salesforce.com an alert is generated that looks like the following:

Note: “Joe Sales” was created via Azure AD automatic account provisioning into Salesforce.com

image

 

Let’s take a look at a File Policy for DLP

I have files stored in O365 (i.e. SharePoint Online/OneDrive). My policy looks for credit card numbers and alerts me when it finds them. I can also configure the policy to take action automatically such as when it finds credit card numbers in files, remove permissions, quarantine the user who’s accessing them, and so on. If necessary, you can use regular expressions within policies as well. Here, I just use the canned “credit card number” expression and it works well.

image

When the policy combs through the files in the services configured (i.e. services that have direct API integration with Cloud App Security, in this case OneDrive) they’ll trigger alerts based on what it finds as shown below:

image

Let’s dig into the alert and see what it came up with:

image

Based on the screenshot above, Microsoft Cloud App Security used the DLP policy I configured to find the file with credit card numbers I planted in OneDrive. As an admin, I can take manual action or configure automated actions as shown previously during the file policy creation step.

Here’s what manual actions you can take if you need to investigate further:

image

 

Those are just a couple examples of application discovery, data loss prevention (DLP), policy creation and enforcement within Microsoft Cloud App Security. Find out what your business requires and configure policies based on those guidelines.

 

To learn more about Microsoft Cloud App Security please visit: http://www.microsoft.com/en-us/server-cloud/products/cloud-app-security/

Microsoft Windows Store for Business and Azure AD Join

With Windows 10 available, many organizations are considering upgrading. There are a lot of reasons to consider upgrading to Windows 10 and if you’re interested in learning more please visit: https://technet.microsoft.com/en-us/library/dn986867(v=vs.85).aspx

If you’re interested in learning more about the Windows 10 Roadmap for Business please visit: https://www.microsoft.com/en-us/WindowsForBusiness/windows-roadmap 

First I’ll walk through the registration of a Windows 10 device with Azure Active Directory (Azure AD), then I’ll walk through setting up WS4B.  After, I’ll access the Windows Store from a Windows 10 device where the private business store resides.

During the setup process, users will have the choice (if you’re not deploying using MDT or System Center Configuration Manager for auto deployment) to choose how they’ll authenticate. They can either perform a traditional domain join or join Azure AD.

To learn more about the differences between domain join and Azure AD join please visit: https://blogs.technet.microsoft.com/ad/2016/02/17/azure-ad-domain-join-windows-10/

If your devices are Azure AD joined and you maintain an AD forest on premises, then you’ll be interested in learning more about how to writeback the device objects to Active Directory on premises.

For more information on writing back device info to Active Directory please visit: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-feature-device-writeback/

There’s also the ability to have Windows devices automatically register with Azure AD as they’re domain joined.  Links about automatic device registration across the various Windows OS versions are below:

 

Joining a Windows 10 Device to Azure Active Directory

One of the advantages to joining devices to Azure AD is single sign-on (SSO) benefits. In traditional domain joined environments typically this is provided by way of a federated identity provider (e.g. Active Directory Federation Services or ADFS). However, when devices are joined directly with Azure AD the direct benefit is SSO to cloud applications such as Office 365 and other SaaS based applications that have a federated trust directly with Azure AD.

Let’s walk through how to join a device to Azure AD. The following walks through the OOBE experience, however devices that are already set up can be joined as well.

Note: if the device is already domain joined, refer to the links above for device writeback and registration.

Install Windows 10 and after Windows 10 has completed the setup process, select “Join Azure AD”

clip_image002

Type in a user name and password (make sure the user is licensed for Intune or EMS via the O365 admin portal). Select “Sign in” to enroll the device with Azure AD:

clip_image004

clip_image006

clip_image008

clip_image010 clip_image012

Once registration is complete I’m asked to set up a PIN:

clip_image014

PIN setup process

clip_image016

There are three methods to verify your identity via Multi-Factor Authentication. Select the method that best suits your needs. I chose to use the Mobile App.

clip_image018

Download or open the Azure Authenticator app on iOS, Android, or Windows Phone and scan the QR code or use the code provided:

clip_image020

Because I used the mobile app, Azure Authenticator has now registered the account:

clip_image021

Back on the Windows 10 device, once the QR code is scanned or entered and register with the Azure Authenticator app, the Next button lights up. Select Next.

clip_image023

Select how you’d like to authenticate; I chose to receive a notification on my phone (via the Azure Authenticator app):

clip_image025

clip_image027

On my phone, I select “Verify” to complete the process:

clip_image028

Lastly I need to select a country and enter my phone number and select Next:

clip_image030

Now I’m asked to provide a PIN:

clip_image032

After a pin is entered I’m logged into the device under the Azure AD credentials I registered with:

clip_image034

To prove I’m logged in as and Azure AD registered user, I open a command prompt and type in “whoami” without quotes:

clip_image035

On the backend, my device auto registers with Microsoft Intune for mobile device and application management. Intune will also deploy the policies I’ve configured such as configuring Windows Update, Windows Defender, Enterprise Data Protection, OS Upgrade, and so on.

For example, the following are the Windows Defender settings from the same device I registered, as you can see the settings are grayed out; that’s because my Intune policy was deployed to the device:

clip_image037

What about group policies?

If the device is enrolled and managed by Intune, I recommend sticking with Intune policies. However, if there are group policies that your organization already uses, then the more restrictive policy will always take precedence (either Intune or GP). The Intune admin console will point any conflicts out as well.

 

Windows Store for Business

What is Windows Store for Business?

With the new Windows Store for Business, organizations can make volume purchases of Windows apps. The Store for Business provides app purchases based on organizational identity, flexible distribution options, and the ability to reclaim or re-use licenses. Organizations can also use the Store for Business to create a private store for their employees that includes apps from the Store, as well private Line-of-Business (LOB) apps.

Source and more info: https://technet.microsoft.com/itpro/windows/whats-new/windows-store-for-business-overview

Now that I have my Windows 10 device registered with Azure AD (and enrolled with Intune), let’s take a look at the Windows Store for Business.

Navigate to: http://www.microsoft.com/en-us/business-store and either sign up or sign in with your organizational account.

clip_image039

clip_image041

 

The first thing I do is connect WS4B to Microsoft Intune. To connect the services, select Settings and then Management Tools:

clip_image043

Select “Add a management tool”

clip_image045

Search for Microsoft Intune and select Microsoft Intune from the list:

clip_image046

Microsoft Intune will be added and activated:

clip_image048

Adding Applications

Select “Shop” in WS4B to view and add applications. This is very similar to a volume purchase program (VPP):

clip_image050

Select an app to add, in my case I selected Foxit MobilePDF. Then select “Get the app” – other apps have online and offline options that you can select as well.

clip_image052

The distribute screen will open and we have a few options to select from as shown below. I selected to assign the app to people, in this case all FTE group I created in O365. Once you’ve selected an option select “Confirm” to add the app to the WS4B inventory.

clip_image053

clip_image054

Now I’m taken to the WS4B inventory page where all of the apps added may be seen and modified. Select an app to see who it’s been assigned to.

clip_image056

 

Intune Volume Purchase Program (VPP)

Let’s move over the Intune admin portal to view the VPP apps added by WS4B. After I log into Intune I select APPS then Volume-Purchased Apps. Here’s a brief list of some of the apps that came over from WS4B:

image

 

Windows Store for Business on the Windows Client

Let’s now look at where to access applications in the private store. To view the published apps search for or open the Windows Store on a Windows 10 machine (I’m using the device joined with Azure AD). From there you’ll see a list of tabs and on the far right there’s a new tab for WS4B as shown below:

 

clip_image060

 

In my environment I select “Contoso cbcloudmobility” and see the following apps I’ve published so far:

image

 

When I select Sway, I’m provided an option to install:

clip_image064

 

If you’re wondering if LOB apps can be published, the answer is yes. From the WD4B portal select “Manage” and then “New LOB Apps” from there you can go to the LOB Publishers page to invite publishers.

More details here: https://technet.microsoft.com/library/mt606952%28v=vs.85%29.aspx

clip_image066

 

This concludes the walk-through of registering a Windows 10 device with Azure AD and publishing applications via the Windows Store for Business. Try it out to see how it would work for your organization.

Invite external users to access Publically Shared URLs via Power BI using Azure AD

November 2017 update: Azure AD B2B now supports Power BI.  More details here: https://docs.microsoft.com/en-us/power-bi/service-admin-azure-ad-b2b

 

With the rapid adoption of Azure Active Directory (Azure AD) and services surrounding Azure AD, we’re seeing more and more customers interested in publishing SaaS apps as well as custom apps to employees, consultants, and business partners.  One of the challenges of granting application access to users is provisioning/maintaining infrastructure, user management, and what technologies to utilize long term.

Azure Active Directory has a feature called the Access Panel (or myapps.microsoft.com). The panel accessible by employees and business partners who have accounts within Azure AD (think of this as a potential extranet replacement).  Accounts in Azure AD may live in the cloud, synced from on premises identity providers (i.e. using Azure AD Connect), or by inviting users via Azure AD B2B (business-to-business).

Azure AD Access Panel

2017-01-18_11-39-57

 

We’re also seeing rapid adoption of Microsoft Power BI. Power BI takes all that data you have and transforms it into dashboard visuals and/or reports and can be shared out via a link. For more information about Power BI please visit: https://powerbi.microsoft.com/en-us/

 

In this post, I’ll walk through how to publish an app that points to a published URL from Power BI and assign external users to a Power BI URL using the “Publish to Web” option.

Requirements

  • Azure Subscription with an Azure AD tenant
  • Power BI subscription – free version works fine for static access to publically shared URLs

Azure AD  does not support publishing the Power BI app to external users, however virtually any web URL can be assigned to external users that includes a publically generated URL of a report in Power BI.

Please refer to the licensing information regarding the sharing of Power BI content: https://powerbi.microsoft.com/en-us/documentation/powerbi-service-share-unshare-dashboard/#licensing-requirements-for-sharing

For this post I take a URL generated using the Power BI sharing feature (alternatively, sharing from Power BI with users accomplishes the same thing) and create an app using the same URL in Azure AD.  I then invite users to access the public URL via an app added to Azure AD.  Access may vary depending on the Power BI features utilized and user licensing.  Please test all scenarios before moving forward with deployment.

 

Let’s get started

Stage 1 – Invite external users to Azure AD

Inviting external users using Azure AD is a quick process. Log into portal.azure.com, locate Azure Active Directory and add a user.


Stage 2 – Log into Power BI using credentials from the same Azure AD tenant where the B2B users reside. Find the report you’d like to share and select File and then Publish to web at the top.  This will provide a URL that is accessible to anyone on the web.  If you’d like secure access to Power BI content please refer to licensing Power BI.

2017-01-18_10-47-30

You may be asking, why don’t I just share the public URL via email and move on?  I could, however what I’m demonstrating is how to publish a URL using Azure AD that points to a publicly shared Power BI URL.  Instead of relying on users to keep track of external links, they can log in to the access panel and select the Apps that point to published URLs as well as access other applications you’ve granted them access to (e.g. SharePoint Online, Salesforce, Concur, Workday, etc.)

Note: Azure AD supports user provisioning with select applications (e.g. Workday, Salesforce, Service Now, etc.).  When a user is added to Azure AD, groups can be configured to dynamically look for attributes in the user’s account (e.g. department = Finance) and automatically add them to a group.  That group can be assigned to an app as well.  User provisioning into SaaS apps can occur thereafter if the apps are configured to do inbound provisioning (i.e. create an account in the SaaS apps identity directory). Dynamic membership for groups cuts back on the management of accounts because account provisioning and de-provisioning happens automatically.

Stage 3 – Add an application to Azure AD the points to a URL and assign to users:

Log into the portal.azure.com and search for Azure Active Directory.  Drill down into Azure Active Directory and select “App Registrations”

2017-01-18_10-58-37

From the blade that opens to the right, select Add and fill in the details about the app/URL you’re adding.  The URL I used is the URL from Power BI that was created to publicly share content (again anyone can access this content so be sure no confidential data is exposed):

2017-01-18_11-14-42

Save the app and if needed access it again to change settings such as the logo and so on.

Today the new Azure Portal does not support assigning users to custom apps so we need to access the classic Azure Console to assign access to external users:

Log into the classic Azure Portal: http://manage.windowsazure.com and navigate the Active Directory on the left had side.

 

 

 

Select the application and select “USERS AND GROUPS”. Add users or groups that you want to have access to the application (i.e. Power BI report). For demonstration purposes, I added a B2B user.

Note: for a more automated of adding users to applications, refer to the dynamic group membership discussed in a previous note above.

2017-01-18_11-19-36

Stage 4 – Log in as the B2B user to http://myapps.microsoft.com

Test my published URL outside of Azure AD if you’d like to see if it works or not: https://app.powerbi.com/view?r=eyJrIjoiMzdhMGJiOWMtODc2Mi00NzJjLWFkMDQtMjZhNWVjMjA1MmY1IiwidCI6IjUyNTY4MmZkLTFhZTctNDg0Ny04Mjc1LTJlNDQ4OTBmYWU4ZSIsImMiOjN9 

Select the app that is attached to the published public URL and we’re taken to the report via a single sign-on process:

2017-01-18_11-40-55

 

2017-01-18_11-42-18

 

That’s it, we’ve published a Publicly shared static URL from Power BI report via an Azure AD app to an external user using Azure AD B2B in just a few steps.