Identities and roles in a Microsoft Azure AD environment can be provisioned very easily thanks to the Office 365 Connector App for UCS. Users can get an easy single sign-on access to Office 365 resources while maintaining control over the information conveyed about each identity.
Moreover, in a UCS environment, precise permissions are often defined to control the visibility of user properties within an organization. Especially in large environments it is necessary that not every user “sees” every other user. For example, the data protection requirements at schools are implemented by UCS@school: The school authorities can administer user accounts centrally across all schools, but users only “see” each other within their own school. In a single Azure AD, such a separation is generally not provided, but the creation of several Azure AD or tenants is expected.
In this article I am going to explain how you can implement such separate setups with UCS for Azure AD more easily and how the scenarios are structured since the last update of the Office 365 Connector App.
Initial Situation
UCS is often used as an identity management tool for large environments. Therefore, users and authorizations of several companies, branches, educational institutions or other groups are connected under one umbrella. At the same time different group memberships and thus different rights are maintained. The Identity Management Azure AD, part of Office 365, on the other hand, does not support complex authorization scenarios. All registered users have full read access to Azure AD (the only exception being the significantly restricted guest access). This feature differentiates itself clearly from the previous on premises Windows Active Directory access control.
If you want to set up differentiated authorization scenarios, the operation of several Azure AD must be implemented as separate user databases, which can be assigned to so-called tenants. Since it is irrelevant for the implementation of UCS whether the different Azure ADs are configured in one or more Azure Tenants, the following always refers to “Azure AD” or “Multi Azure AD”. The term “Multi Tenant”, which is often used in IT for the separation into clients, often refers to the functionality that is implemented by splitting the user accounts over several Azure AD In order to avoid misunderstandings with the tenants of Azure, I will not use the term in the following.
The Challenge of Single Sign On
In UCS environments a Single-Sign-On (SSO), technically implemented using the SAML protocol, is the normal way to authenticate to Office 365 or other services connected to Azure AD. For this purpose, a so-called SAML Identity Provider (IDP) is provided with UCS, which is configured in Azure as the authentication source. For this purpose, among other things, the URL of the IDP, i.e. the address to which the user’s web browser is referred when logging in to enter the password, is stored in Azure AD.
When implementing SAML SSO in Azure AD, Microsoft decided to restrict the configuration of this URL for security reasons: a SAML IDP can only be assigned to exactly one Azure AD – a second Azure AD cannot use it. However, this restriction is in contradiction to the requirements described above: we just want to introduce multiple Azure AD for data separation and at the same time allow SSO with UCS. In order to find a feasible way for users and administrators of a UCS system, it was necessary to circumvent these requirements within the SAML IDP of UCS. For this reason, the development department decided that the IDP in UCS could be made accessible via aliases under additional URLs, which could then be configured in an Azure AD.
Implementation
We have extended the Office 365 Connector in UCS with App Version 3 so that multiple Azure AD can be set up and then selected in the Management Console for the users and groups to be synchronized. Directly after installation, a first “Default” Azure AD is prepared for this purpose, which you can configure interactively using the wizard in the UCS web interface. As an administrator, you will be guided step-by-step through the configuration of both the synchronization with Azure AD and the Single Sign-On via SAML. If users or groups in UCS are activated for synchronization with O365, they are synchronized to this first Azure AD by default. Up to this point there is no significant change compared to the previous connector.
If another Azure AD is supposed to be set up, you can prepare it on the UCS system with a simple command. To do this, you give the additional Azure AD a descriptive name in the UCS, which is later displayed in the Web interface when assigning it to users and groups. The interactive wizard in the Web interface is also prepared for the configuration of this Azure AD connection.
To complete the configuration, it is still necessary to provide an additional URL for the IDP due to the Microsoft specifications for the integration of the SAML IDP described earlier. In larger environments it is common to run the SAML IDP on one or more systems unlike than the O365 Connector which runs on a different system. Since UCS 4.4 Errata 358 “aliases” can be registered on these systems, from which additional URLs for accessing the SAML IDP are generated. It is recommended to use the same naming scheme here as for naming the Azure AD connections.
In the configuration accompanied by the O365 Wizard, these elements are then reassembled. The additional Azure AD is provided with identities by the connector and a unique SAML IDP URL is assigned. You can configure which users have access to which Azure AD via the UCS web interface afterwards.
End User
For the user this complexity remains hidden. Access to O365 is protected by the SAML SSO. The different Azure AD or SAML URLs are completely transparent to the user. The user has the familiar comfort of single sign-on. Integration with the login process at workstations in the UCS domain even eliminates the need to log in to the web browser again.
Each user is assigned an individual login (“User Principal Name”) in Office 365 or Azure AD. This can lead to confusion among users if several Azure ADs have been activated and the login is started directly on the Microsoft login pages. To avoid users having to remember the login and URL of the Azure AD, it is recommended to link them directly to the Univention Portal. Users will then only see the resources they have access to and can start directly without entering Azure AD specific logins thanks to Single-Sign-On.
The separation of user groups into their own Azure AD or own Azure Tenants is now easily possible thanks to the innovations in the Office 365 Connector with UCS, while at the same time being easy for end users to use.
Documentation of the facility:
Use UCS Core Edition for Free!
Download now
Using Linux since 1999, Ingo Steuwer started working at Univention in 2004. As Head of Product Management he focusses on the further development of UCS.
