Managing Users in Azure AD

Once the users have been synchronized with Azure AD, they can be managed in the cloud directory in two ways: using Azure Active Directory PowerShell or on the Office 365 or Azure web portals. It is important to understand that Azure AD has two types of users: Users that only exist in the cloud and synchronized users. With the latter, Azure AD logically assumes that the actual database comes from the local AD and therefore only allows administrators to perform a few changes to the cloud users. If you need to make extensive modifications, you should perform these in the local AD and then synchronize the changes.

Administration is quite easy with PowerShell: Once the Azure AD PowerShell module is connected with Azure via Connect-MSOLService, you can request data. Get-MSOLUser provides an overview of all the users in the cloud. Here, MSOL stands for Microsoft Online. Things becomes more specific if you ask PowerShell for a specific user. The UserPrincipalName (UPN) serves as the identifier here. It is advisable to pipe the results to the Format-List Cmdlet (Figure 4). This outputs all attributes available for a user in Azure AD. Many of them are well known in the local Active Directory, such as the title, phone number or address:

# Get-MSOLUser -UserPrincipalName jennifer@frickellab.de | fl

Figure 4: The data for synchronized users are consistent with the data from the local AD.

The UserPrincipalName is the UPN that Azure AD recognizes. Recognition occurs if the UPN from the Windows AD matches a domain that has been verified in Azure AD. Otherwise, Azure AD selects the tenant name as the UPN for unrecognized UPNs which then look a bit like this: jennifer@frickellab.onmicrosoft.com. For automatic recognition of Windows Active Directory UPNs, it is thus essential that the domains for these UPNs be registered and verified in Azure AD; otherwise, users also have to log in to the Azure or Office 365 portals with the longer tenant names.

Single Sign-On

Single sign-on is a powerful tool for managing local and online accounts. As an example, I'll describe how to use Azure AD to enable a single sign-on for Dropbox and Twitter via Microsoft's services.

I'll show you how to set up the sign-on for the ADFS – and thus to Azure AD; this should be enough to access all online services. Controlling access to the cloud services using groups is, of course, central to this capability. Once access to external online services works, I will look at the security reports in Azure in more detail and try to find out more about the potential risks: This is a feature that Azure AD offers in the Premium version. Then, I will set up another authentication level for administrative users using Azure multifactor authentication.

Creating Groups in Azure AD

Azure AD draws on well-known and proven methods to grant access privileges and control permissions for applications: Groups. Whereas Windows Active Directory generally distinguishes between security groups and distribution groups, and then breaks these groups down into different scopes for local, global, and domain local purposes, Azure AD just has plain old groups. If the security groups are covered by the Azure AD synchronization scope, they are synchronized by Azure AD – including group memberships. Group membership means all Windows AD user accounts and other nested groups – as long as the members are also within the synchronization scope.

As with user accounts, Azure AD distinguishes between groups that have been created in the local AD and cloud-based groups. Even the same rules apply: Groups from the local Windows AD can only be changed by synchronization from the Windows AD. Cloud-based groups, however, can be managed from the Azure management portal and the Office 365 portal. The Groups option in the left-hand menu of the Office portal dashboard takes you to the overview of known groups. First, navigate to Active Directory in the left-hand menu of the Azure portal; then, select the correct directory and Groups in the top menu. The Azure management portal is currently the more useful approach for modifying groups: The user interface clearly shows which groups can be changed and where they come from (Figure 5).

Figure 5: Groups in Azure AD are best managed manually in the Azure Management Portal.

The groups are later used to access shared and federated applications in Azure AD. You will not typically want to share applications with individual users, but rather to groups. In this way, you can to control access via memberships. Depending on the corporate strategy and whether an identity management system is in place, you should consider whether you map application access control in Azure AD groups or Windows AD groups. I will be using specially created cloud groups in this example. The scenarios can similarly be implemented with groups from the local Windows AD – the difference lies in synchronization: Changes must be made in the Windows AD and then transferred to the cloud by AADSync, which may take some time.