How Power BI implements user authentication
Enhanced security options
Security, like many features in Power BI, leverages other infrastructure components in the Office 365 and Azure platforms. In the case of Office 365, including Power BI, security is implemented using Azure Active Directory (AAD), which is a web-scale Platform as a Service (PaaS) in Azure. Azure Active Directory is built on the foundations of Microsoft Active Directory, which is used for identity access management in organizations the world over. One of the primary benefits of AAD is that it can be seamlessly integrated with an organization’s on-premises implementation providing a single set of user credentials for both on-premises and cloud applications.
The primary goal of AAD is to ensure users can be productive whenever and wherever they are while still ensuring that the organization’s assets, including its data, are secure. The AAD tenant is created as part of the Office 365 tenant creation process and is the engine behind actions like creating users. AAD comes with many features, and like Power BI enhanced enterprise-grade features, these are available through the purchase of higher tiers of the product.
Editions of Azure Active Directory
Azure Active Directory is available in four different editions with each edition having additional features on top of the previous version.
Free: When signing up for Power BI without any other services, your AAD tenant will use the free edition of Azure Active Directory. This free tier supports all the core features required of an authentication service. In addition to the comprehensive identity management, the free edition also supports Two-Factor Authentication also known as 2FA, as well as Azure AD Connect Sync allows active directory to be synchronized with a compatible version on the on-premises version allowing you to use a single login for both on-premise networks and the cloud.
Azure AD for Office 365: This edition was designed especially for uses of Office 365 products and is only available if your organization has purchased an E1, E3, E4, E5, or F1 subscription. In addition to all the benefits of the free edition, Azure AD for Office 365 also includes custom branding on the login screen, an SLA on the availability of the AAD service of 99.9%, and support for two-way synchronization of AAD and on-premise active directory.
Premium P1: The P1 Premium edition is required if your organization has more complex security requirements such as Conditional Access. Conditional access allows the creation of rules-driven authentication processes that can be used to enforce organizational access policies. An example of such a policy includes requiring users not on the corporate network to use Two-Factor Authentication before gaining access to corporate applications.
Premium P2: The P2 Premium edition of AAD contains advanced features such as Vulnerabilities and Risky Accounts Detection and Risk-Based Conditional Access policies which make use of machine learning to provide proactive threat detection.
P1 or P2 Premium plans can be purchased in several ways, including through your Microsoft account representative, the Open Volume Licensing Program, Cloud Solutions Provider, and through the Office 365 admin portal.
To see a full comparison of all editions of Azure Active Directory, go to https://azure.microsoft.com/en-us/pricing/details/active-directory/.
Creating a new user
In a large organization, the job of creating users would not usually be assigned to the Power BI. Such tasks are sent to a security team that manages the organization’s Active Directory infrastructure. In small organizations or organizations who only use Power BI and not any of the other Office 365 or Azure services, it may be required. Users can be added to the organization’s directory using a variety tools including the Office 365 admin portal, the Azure Active Directory portal, and the PowerShell automation cmdlets discussed in Chaper 15. To add a user to Azure Active Directory, the administrator needs to be part of either the Global administrators or User administrator roles.
Adding a new user using the Azure portal
We discuss some of these options in the following.
Required settings
User Name: Each user in Azure Active Directory is assigned a unique user name.
Domain Name: Each active directory tenant can host multiple domains.
Password: A secret known only by the user used for authentication.
Optional settings
First and Last Name: The first and last names of the user will make it easier to identify the user.
Groups: This will add the user account to any existing groups; this can also include any classic workspaces that automatically create groups.
Roles: Any roles that the user should be added to; this could include the Global admin or Power BI admin role.
Block sign in: This option will allow you to prevent the user from signing in if for some reason you needed to disable the account.
Assigning licenses
Once the user has been created, they would then need to have a Power BI license assigned to them. This could be a Free or Pro Power BI license depending on the license type.
The user would be able to sign up for a free trail license; this will revert back to a free license after the trial period has ended.
Assigning a Power BI Pro license to a user in the Office 365 portal
External user access
A common requirement for organizations is to allow external users to access reports. Traditionally this has been achieved in one of two ways. An account can be created within the organization’s AAD tenant. However, this can create a lot of extra objects in AAD that need to be managed, and can also result in greater costs as additional subscriptions may be required. Second and a common misconception which has been spoken about previously but warrants revisiting is the use of the Publish to web (public) feature. When this feature is used, the report is made available without security. This initially meets the requirement to share reports outside of the organization, but there is no mechanism in place to stop people outside of the organization from accessing this content. Microsoft has taken a number of steps over the last few years to limit misuse of Publish to web, including the ability to turn the feature off, which is now also the default tenant setting.
To better support the sharing with external users requirement, Azure Active Directory allows guest accounts to be added. Guest accounts are user accounts that are created in other organizations’ AAD tenants but are given access permission to the tenant. This level of sharing is also known as Business-to-Business B2B sharing.
Before external accounts can be used in Power BI, they first need to be added to the AAD. This needs to be done by a global or security administrator. When adding an external account, AAD will send an invitation to the external user. This means that the user does need to provide a valid email address. The external user is then required to complete the signup for this external account. Once the external account has been created, that user can then be added to Power BI in the same way that local accounts are.
When guests accounts are granted access to a tenant that is not their home tenant, they will only be able to gain access to the correct Power BI portal by using a direct link.
Branding
Language: The language used for the sign-in page can be changed from the default English language. This does not change any of the language settings of various applications and applies to the sign-in screen only.
Sign-in page background: An image can be configured as the background image for the sign-in screen. This image, no larger than 1920 x 1080, will appear on the login screen; using a similar background image as that used on the corporate intranet can help enhance that standard look and feel.
Banner logo: The banner logo, no greater than 60x280, is usually the organization’s logo. Again this helps provide a consistent look and feel.
Sign-in page text: Custom text, up to a length of 265 characters, can be provided; this text could be a disclaimer or a link to a corporate help desk.
Multi-Factor Authentication
Microsoft Authenticator app
OATH Hardware token
SMS
Voicemail
Multi-factor authentication can be made compulsory for all users in the organization or can be used as part of AAD conditional Access.
Conditional Access
Conditional Access policies are if-then statements in which the organization can build a set of authentication flows to enforce organizational policies and ensure that the correct access controls are put in place. Conditional Access is only available through the P1 and P2 AAD premium editions or Microsoft 365 Business Licenses.
Conditional Access works by taking in several inputs known as signals and then making a decision on whether they accept, deny, or challenge the authenticating user.
Signal
User or group membership: Policies can be set up so that they apply to certain users or groups; a typical example of this may be to apply a different conditional access policy to external users.
IP location: IP location can be used in a number of authentication scenarios. Examples of such include determining if the authentication request is coming from the corporate network. IP location also is used to determine if the authentication is coming from certain geographies. A simple policy may be to deny authentication requests from countries that your organization does not have a presence in.
Device: Organizational policies can also be created to prevent users from connecting to the service using devices that do not meet a set of requirements. These requirements could specify that the user be joined to the domain or that they comply with some minimum set of criteria, such as having BitLocker installed.
Application: It is also possible to use the application as a signal; this could be used to drive a policy in which certain applications are only available while the user is on the origination network. Such a policy could be used to limit admin access to users who are on the corporate network.
Decision
Deny: A simple decision can be made to deny the authentication attempt; an example of such a policy may be to deny all incoming authentication requests from known "Hacking hotspots" or denying access to users who are or are not part of certain AD groups.
Challenge: Certain signals can trigger the need for additional authentication challenges. An example of this may be requiring users to use multi-factor authentication if the user is part of an administrative role.
Grant: The authentication request is approved, and the user is given access to the application.
Real-time and calculated risk detection
Integration with Azure AD Identity Protection allows Conditional Access to identify risky sign-in behavior. When risky behavior is identified, AAD can force users to perform extra security checks, force them to change their password, or even disable the account until an administrator can take action.
Microsoft Cloud App Security
Microsoft Cloud App Security allows organizations to create Conditional Access policies using real-time session controls. This can help ensure that Power BI analytics are kept secure and give administrators the ability to monitor in real-time the activities of users.
Suspicious share: Detects when a report is shared with an unusual external user; this can be combined with sensitivity labels to detect when users attempt to share with users outside of the organization.
Mass share of reports: Microsoft Cloud App Security can also be used to detect occurrences of several reports being shared in a short amount of time; this may be a sign of a compromised account.
Summary
Azure Active Directory provides several configurable options to enhance the security position of the organization and thereby Power BI itself. Using Conditional Access fine-grained policies can be enabled, allowing the organization’s user to work both safely and productively.
Call to action
Consider enabling Two-Factor Authentication (2FA) for added security.
Use guests accounts to enable external access rather than creating a separate account.
Set up Conditional Access for enhanced user security.