Office 365 Policies via PowerShell

Because of the Internet connectivity of Office 365, companies can't control the locations from which users can access Office 365 services; that is, users who have the right to use Office 365 services can do so from anywhere. However, from Active Directory Federation Services 2.0 (ADFS 2.0) onward, companies have the option to create Client Access Policies. You can use these policies to determine from which locations users are allowed to connect. In such a scenario, users authenticate themselves using ADFS rather than the Office 365 web interface. They then forward the login to the cloud.

Microsoft provides the free Client Access Policy Builder [6] so that these policies can be created and implemented as easily as possible. The Client Access Policy Builder automatically creates policies and settings for most scenarios. The Client Access Policy Builder is a PowerShell script with a graphical interface. You can display this interface by double-clicking the PS1 file. However, you can also implement policies without this tool. Microsoft provides the corresponding instructions in TechNet [7].

Put simply, using the script, you just need to define that all external access to Office 365 should be disabled and that the cloud solution should only allow connections from within the company. Additionally, Client Access Policy Builder can also place web-based applications such as Outlook Web App and SharePoint Online on the exceptions list. The policies and IP addresses are configured using the graphical interface mentioned above, which is started from the script. You just need to select the appropriate option for the scenario that you want to use.

If you want to block all remote access to Office 365, you can specify IP address ranges from which users should have access to the blocked services. However, if VPN clients access Office 365 via an Internet connection, they are of course classified as internal clients. All settings can be adjusted afterward and undone again. You can use the PowerShell script for this or make settings manually. You need to copy the Client Access Policy Builder script to your primary ADFS server. If you use Windows Server 2012 R2, you need to make an adjustment for the script to work. To do this, open the script either in the editor or the PowerShell ISE. Search for the following line in the script:

If (($OSVersion.Major -eq 6) -and ($OSVersion.Minor -eq 2))

It is near the top of the script. Replace the -eq parameter with -ge so that Windows Server 2012 R2 is detected. If you don't make this change, an error message will appear in the graphical user interface, and you won't be able to set any rules.

Now start the script via the context menu. If everything is configured correctly, no error message will appear in the bottom section and the Create Rules for Claim Types option is active. You should now be able to work using the tool. The further procedure for disabling functions and IP ranges can be found in the tool's documentation.

Protecting Power BI

Microsoft offers an extension for Office 365 in the form of Power BI for Office 365 [8], which you can use to connect business intelligence applications (Figure 5). The biggest advantage of BI is the quick introduction to business intelligence, because everything companies need to evaluate their data can be operated via the cloud. Users can save the reports in SharePoint Online. The data is exchanged between your network and Power BI via a gateway that connects to a piece of agent software on the company servers.

Figure 5: Office 365 Power BI can be integrated directly into the Office 365 web interface and infrastructure.

In the settings of each data source, you can specify whether reports that use the data from this source can be stored in SharePoint Online or can only be stored locally on the network. By default, new data sources are set so that storage in the cloud is allowed. You can also determine in the data sources settings whether they may be searched using Power Query. This function is disabled by default. You can also determine in the settings for the data sources which tables and views should be available from the connected databases. Of course, you can specify for each data source in Power BI who is allowed to use them. You can set the necessary approvals by connecting the data source or at any time in their settings.

Besides setting authorizations for using data sources, it is also possible to delegate the management of Power BI and the integration of other data sources to another user in Office 365. Microsoft provides Role Management for this purpose. You can set global administrators here – that is, admins that have extensive rights in Office 365 Power BI – or group administrators. The group administrators are only allowed to manage the data sources and gateways that are assigned to this group; they're not allowed to adjust any other settings in Power BI.

Additionally, you can define users in the role management | data steward group who can certify queries with Power Query. If you work using DirSync, a tool for data synchronization between Active Directory and Azure Active Directory, you can control user logins via domain accounts. You can find the relevant settings in the Settings/General area. Microsoft explains what to do on a help page about this subject [9].

Conclusions

Office in the cloud is attractive for many companies because it provides them with flexible collaboration that is easy to set up. The integration with the local environment is no longer a problem, but such an extensive platform that is accessible from anywhere should be safeguarded accordingly. By just activating a few settings, you can determine which users are allowed to use which services from which locations, encrypt email, and set up multifactor authentication. Furthermore, you can see statistics about spam and malware, ensuring a good level of security – even if the data is unencrypted with the cloud provider.