Microsoft is providing 30 day trial environments for Office 365 and for Azure. These trials can be used to setup a test and development environment by following the step-by-step guides from MS. If you are intending to start using those environments, then these Test Lab Guides can be very usefull way to get familiar on what is available and how it really works.
This test environment setup can also be very usefull for persons working with security, both for competence buildup and for testing the security features and different setups. (30 days trial limit can be very tight, and it might be better first to install only the O365 environment, and extend that one for another 30 days, and only then continue with the Azure environment. ie. follow first the O365 test/dev guides, and then after 30 days repeat the test/dev guides and include Azure in the setup…)
In the beginning it is a little confusing, as the MS guides do not show the overall big picture before starting. This might be partly because the environments are being slightly changed all the time. The picture below is trying to show that in the O365-Azre test/dev environment, there are 3 different Active Directories involved.
- Azure AD for O365
- This AD will contain both cloud userids (O365) and CORP userids (from simulated contoso.com, from virtual AD)
- (note, the userid that was used to subscribe the trial is not in this AD)
- Azure AD Free
- This AD will contain the userid that was used to subscribe the trial (newmeail2)
- Virtual AD (IaaS)
- to maintain the users in the CORP domain
The different portal structure between O365 and Azure can cause confusion. The picture below is trying to show the different portals used to administrate these environments. In Azure, one portal is used, but in O365 the main Admin portal is used as jump board to access other portals… (I would assume this to change in the future).
Please note that it is possible to login to Azure portal with the O365 userid. This is because Azure is providing the Azure AD function from Azure to the O365.
BTW, after trial period, it is possible to continue this test/dev environment and pay for the services without loosing the data from trial.
In Office 365 Admin portal, all what is needed, is there. However, the implementation is done the way that different sub-menus are actually only jump boards to other portals.
For example, Security and Compliance is a separate portal.
When it comes to Roles, then the issue becomes quite complex in the beginning. In the MS approach, security related roles like Security Administrator and Security Reader do not have access to security related configuration within diffrent services, but they only have access to central alerts, classification and policies configurations. I have not yet been able to identify a suitable reader role that could have read-only access to security related configuration in Exhange, Sharepoint, Yammer etc. It seems that this would need a customized role configuration. (Note that in the azure environment, one can have a Reader role for a subscription which can see all data as read-only (“Reader”, not “Security Reader”).
The screenshot below shows how Azure portal looks like after the setup with AD Connect is ready. In order to reduce the costs, it is good practise to stop the VMs when they are not needed.
In Azure portal, the Security Center is build into the portal and is not a separate portal like in Office 365.
All in all, these test lab guides are good way to get started. And there is a lot of information sources available for different tasks and goals. However, the information is still quite scattered, and it can be a challenge to obtain the big picture of the overall security architecture, posture or available settings, best practises and features. Not to mention that certain features require additional licenses. But that is the same with any complex environment, right? That is where security persons are needed to provide some guidance