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:


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 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



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:


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.


  • 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:

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, 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.


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 and search for Azure Active Directory.  Drill down into Azure Active Directory and select “App Registrations”


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):


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: 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.


Stage 4 – Log in as the B2B user to

Test my published URL outside of Azure AD if you’d like to see if it works or not: 

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





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.

Microsoft Intune – Mobile Application Management (MAM) standalone

Have you ever been asked the question “…after I enroll my device, what happens to the personal data on my device if I leave the company?” Sound familiar? I’ve heard this many times when I speak with organizations and in the past the answer was “we have the right to delete everything on your device, so you better back it up…” and so on. Not all employees are comfortable with this approach because wiping a device means personal data such as photos, emails, text messages, game data, and so on may be deleted. Especially if company policies restrict devices from saving data to cloud storage services.

Some Mobile Device Management (MDM) vendors have gone as far as building their own applications to segregate email and data, however not all of these MDM vendors specialize in developing and maintaining email and productivity apps and as a consequence those apps may leave a security hole you didn’t anticipate. If you’ve standardized on or your users prefer the use of productivity apps from Microsoft such as Microsoft Outlook app, OneNote, OneDrive, and so on, unfortunately 3rd party MDM vendors cannot apply policies nor do they have control over Microsoft Office apps whereas Microsoft does.

The good news is, managing the device and applying Mobile Application Management (MAM) policies to applications is built into Microsoft Intune, so from the time devices are enrolled, once deployed, MAM policies will begin to flow to MAM enabled applications such as Microsoft Office apps.

Additionally, if organizations want to maintain their current Mobile Devices Management (MDM) solution and use Intune to only apply MAM policies to applications, with the recent release of Mobile Application Management (MAM) standalone service, companies are able to do just that!

Scenarios to consider when planning your MDM and MAM strategy:

  • Microsoft Intune MAM Only with no MDM at all = Yes
  • 3rd party MDM + Microsoft Intune MAM Only = Yes
  • Microsoft Intune for full MDM/MAM = Yes

For a list of Microsoft Intune MAM supported apps please visit:

Walk-Through of Microsoft Intune MAM standalone (w/o MDM)

The following demonstrates the new Microsoft Intune MAM standalone enrollment process without MDM:

Azure Portal experience

Log into

Select “New” and search for Microsoft Intune


Locate Microsoft Intune (Intune (preview)):


Right click on Intune and select “Pin to dashboard”


Intune mobile application management tile will be pinned to the Azure Portal dashboard:


Select the Intune tile to be taken to the management blade (slide out pages are called blades in the new Azure Portal):


The first thing we need to do is create a MAM policy, we can select either iOS or Android. Do this by selecting App Policy, then Add a Policy from the next blade:


Fill in the necessary information and select “Apps”. Select the apps you’d like to apply MAM policies to and then select “Select” at the bottom of the blade.

Note: not all MAM enabled apps are available yet for MAM standalone. If you need to apply MAM policies to additional applications that support MAM policies, consider enrolling devices with Microsoft Intune and rolling out MAM policies from there.


Next we need to configure the setting for the policy. Do this by selecting “Settings”. This is where we can configure MAM policies such as blocking data from being copied or stored outside of MAM managed applications (e.g. prevent cut, copy, and paste outside of Word). When finished, select “OK” at the bottom of the blade.


Select “Create” at the bottom of “Add a policy” blade to create the policy. Once the policy is created, we’re ready to deploy it to users.

Note: Microsoft Intune MAM standalone is deployed to users not devices.

Lastly, we need to target users to deploy the policy to. Do this by selecting “User groups” from the policy blade. Find the group you’d like to add, press “Select” at the bottom of the User group blade (not shown in image):

Note: at this time, only groups can be selected. Best practice is to place the users who will need MAM policies applied into a MAM only group.


That’s all that needs to be done to create and deploy Microsoft Intune MAM only policies.

iOS/Android experience

Now that the MAM policies are created and deployed, let’s walk through how the policy is applied. For this demonstration, I’m using an iOS device and the Word app, however the Android experience is similar.

Find and download Microsoft Word from the iTunes store (if you need to deploy app, consider enrolling devices with Microsoft Intune). Once Word is downloaded, select the Word app and add the account where the user is a member of the Azure AD group added to the MAM policy. Once the user is logged in they’ll receive an alert similar to the image below. Select “OK” to close the app after 5 minutes or “Close” to close immediately. What is happening behind the scenes is the Microsoft Intune standalone MAM policy is being applied and needs to restart the Word app.


Once users re-launch the Word app, they’ll see the following:


To test the MAM policy, create a new Word doc and save it to the corporate O365 account (mine is the top account named


If the policy is set to require a PIN, your users will be asked to enter a pin at this point:

clip_image026 clip_image028

After the PIN is configured, name and save the doc to the corporate OneDrive account:


This concludes the walk-through of Microsoft Intune Mobile Application Management standalone.

Stay tuned for additional updates via the Microsoft Intune Blog:

Microsoft Intune and Apple Mac Management

The Microsoft Intune team recently announced the ability to enroll and manage the Apple Mac. I’m happy to say that the feature has been deployed as part of the recent Intune release. Today’s post will focus on Mac enrollment and management via Intune.

For details you can read more about the update and what management features are offered for Mac here: &


  • A Mac running OS X 10.9 or later
  • An Intune Subscription
  • User(s) assigned an Intune license so they can enroll



Let’s get started

On the Mac navigate to

Log in with an Azure Active Directory (Azure AD) user credential (someone who also has an Intune license assigned):


Notice the customization of the login page, this can all be changed via Azure Active Directory in the Azure portal.


Select “This device is either not enrolled or the Company Portal can’t identify it.”

Note: if you cancel out of the enrollment and go back later and don’t see the option to enroll, clear browsing history and close down Safari then reopen Safari, login, and the option should show up again.


Select “ENROLL” to begin the Intune enrollment process.


Select “Install” to install the Intune management profile.


Select “Show Profile” to view more about the profile being installed and select “Install” to continue with the installation. Depending on your settings you may be promoted to type in your Mac account password.


Another install prompt may appear, select “Show Profile” again to show the new information and rights being deployed. When finished reviewing, select “Continue” and “Install”.


Once the profiles are installed you’ll see a screen similar to the following:



After installation is complete, the enrollment windows in Safari will remain open. Go ahead and close those out and refresh the page that has “My Devices” on it. After the reload is complete, the Mac will show up with a check box.




Select the Mac to view whether or not it’s in compliance:


Once Mac’s are enrolled they’ll download and apply policies whether created before or after enrollment.


Intune Mac Policies

Policies available for Mac in this release are as follows (more info:

To set up a new Mac policy navigate to select Intune –> Device configuration –> Profiles –> Create profile



Select the type of Profile you’d like to deploy:

Overview of Mac OS X configuration policies with Intune:



Note: for custom configuration you’ll need to utilize download and utilize Apple Configurator on a Mac: 


Classic Intune Portal


In addition to the policies above Intune will track and report on Hardware and Software:



Need to deploy apps and go beyond Intune Mac management features?  Have a look at Mac management with System Center Configuration Manager (SCCM).

Need to manage devices beyond Mac? Intune will manage Android, iOS, Windows Phone, and Windows as well. Read more here:

Keep an eye out for new Intune updates here:

Microsoft Advanced Threat Analytics

Tracking down security vulnerabilities has always been a game of cat and mouse. Certain safeguards can be put in place to prevent security vulnerabilities such as blocking firewall ports, requiring multi-factor authentication and so on. Granted, no system can capture every single security vulnerability, however if a layered security approach is taken, there’s a better chance of catching security vulnerabilities and threats.

There’s also those deep vulnerabilities you’ve only read about but don’t have the necessary tools in place to capture or even check if they are occurring inside your network. Did you know that the average time attackers stay in a network before detection is over 200 days? If that is the case, then there is a lot to worry about including stolen passwords, confidential company data, customer data, and much more.

We’ve all seen the news where highly visible companies are compromised where credit card and customer information is stolen, and worse yet, published online. Have you been one of those affected? If not, what if it happened to the company you worked for? Would you be affected then? My guess is probably, one way or another.

What if you had a solution that was simple to deploy and began learning about your environment within minutes? Look no further, Microsoft Advanced Thread Analytics has a lot to offer, even with your existing security systems in place.

What is Microsoft Advanced Threat Analytics (ATA)?

Microsoft ATA is an on-premises solution that begins by learning about your environment, analyzing behaviors, and alerting on anomalous activity, attacks, and threats. Microsoft ATA will also integrate with existing SIEM’s.

How does ATA work?

Microsoft ATA works by capturing network traffic from domain controllers and by using machine learning, learns about behaviors within your network and alerts on abnormal behaviors.

There are four steps ATA takes: 

  1. Analyze – analyzes all Active Directory traffic as well as SIEM events.
  2. Detect – looks for anomalies and known security attacks and issues.
  3. Learn – leans about users and user behavior, devices, and resources then builds a graph mapping common behaviors.
  4. Alert – ATA raises alerts on suspicious activities and provides a timeline of activities of who, what, where, and when.

What types of issues are alerted by ATA?

ATA detects the following:

  • Abnormal user behavior: e.g. Anomalous logins, Password sharing, Lateral movement.
  • Malicious attacks: e.g. Pass-The-Ticket, Pass-The-Hash, Golden Ticket, Bruteforce attacks, remote execution, a much more.
  • Known security issues and risks: e.g. Broken Trust, Weak Protocols, Known protocol vulnerabilities.

What do alerts look like?

The following are a few example of actual alerts:

Reconnaissance Using DNS


Massive Object Deletion (from Active Directory)


Sensitive Credentials Exposed


Pass-The-Ticket Attack


What about architecture?

The architecture of ATA is very simple. It consists of a “Central Server” and one or more “Gateway Servers”.  Both can be deployed to VMs or physical machines. Again, ATA is currently an on premises solution.

  • Central Server: Central admin console (http) and the database (MongoDB).
  • Gateway Server(s): Destination for port mirrored network traffic from domain controllers.

Additionally, ATA uses self-signed certificates to communicate securely from the Gateway Server to the Central Server. Lastly, port mirroring is required from your domain controllers (source) to the Gateway Server(s) (destination).

For example, it took me about 10 minutes to set up, end-to-end, in my environment where I have two domain controllers.

Links to deployment information is under Additional Resource below.

The following is a sample architecture of ATA:


Download and try ATA today, because having more information about attacks, threats, and behaviors across your network is better than guessing.

Additional Resources

Learn more here:

Additional ATA resources such as release notes, deployment guides, operational guides , FAQ’s and more are located here: