It’s easy to see why enterprises are gravitating toward a hybrid identity management model that promises the best of both worlds—a little bit in the cloud, and a little bit on-premises. In an Active Directory-centric environment, leveraging the cloud means integrating with Azure Active Directory.
Azure Active Directory (AAD), after all, is designed with an eye toward SaaS applications, providing single sign-on and access control. As cloud adoption increases, the ability to manage both on-premises and cloud access is becoming a business necessity. Leveraging AAD alongside Active Directory (AD) helps make hybrid identity management a reality.
As with anything in IT, however, the adage of look-before-you-leap still applies.
Related reading
Monumental change with moving to the cloud
Moving any part of an IT operation to the cloud requires an adjustment. User authentication is no different. From a conceptual standpoint, organizations need to consider three critical issues.
1. A new authentication model
After 20 years of managing identity one way, adding AAD to the mix will be a critical adjustment. Going from using only on-premises AD to extending to cloud authentication requires a different mindset and approach. In AAD, there are no organizational units or forests, and no group policy objects. Concepts (and battle scars) about how to secure the identities in AD no longer apply in AAD.
Many administrators start out believing that securing AAD is similar to securing AD, which is not the case. And you might already be using AAD without thinking much about it. If your organization is leveraging any Microsoft cloud services, such as Office 365, then AAD is already being used in the background. AAD is also leveraged heavily to connect to other non-Microsoft SaaS applications, such as Salesforce. All these factors introduce new considerations and choices. For example, should you keep AD and AAD separate or merge them using Azure AD Connect? Many new concepts need to be understood so you can make these decisions while keeping information systems secure.
2. The extension of the perimeter
Once an organization embraces the cloud, the notion of the traditional network perimeter ceases to exist. For IT administrators who have spent the last two decades running AD on-premises, this notion is a tremendous adjustment. In a hybrid identity environment, organizations now must be prepared to guard against an endless array of possible entry points.
3. Radical changes to the permission model
Moving to AAD also drastically changes the permissions model organizations need to secure. On-premises, it is fairly easy to control who has physical access to domain controllers, and overall management entry points are well-defined and documented. In a hybrid AD environment, identities are also now stored in the cloud, vulnerable to exploitation by anyone who has access to the internet. Suddenly, administrators are dealing with an inherently open model for initial access connections, which—when coupled with the larger number of services, roles, and permissions required—has a significant impact on risk.
Microsoft has actively tried to provide educational materials to prepare businesses for the changes caused by AAD adoption. However, many IT organizations are still failing to fully appreciate the implications of hybrid identity management. As more companies take a hybrid approach, attackers have expanded their modus operandi accordingly.
In September 2020, researchers at Mandiant (FireEye) noted they had seen an increase of incidents involving Microsoft 365 and Azure Active Directory, mostly tied to phishing emails attempting to entice victims into entering their Office 365 credentials into a phishing site. Mandiant researchers also observed attackers using a PowerShell module called AADInternals, which enables attackers to move from the on-premises environment to AAD, create backdoors, steal passwords, and take other malicious actions. These threats will continue to grow with the exponential growth of interest in Azure and Office 365.
Permissions, permissions, permissions
By far, of the three subjects mentioned above, the biggest security risk is caused by the changes to the permissions model. There are a huge number of services that are available when organizations move to a hybrid identity environment. Instead of a well-defined set of administrative groups in Active Directory, you now have roles in Azure AD, which will be unfamiliar. You can see this list of roles here. Each role has a lengthy list of assigned permissions. It is hard to understand the permissions assigned to each role just from the description, but many have a high level of access that isn’t apparent.
Also, linking any SaaS service to AAD, which is probably why you added AAD to the mix, adds permission models that need to be managed. Microsoft Teams, for example, uses SharePoint integration at the back end. With the wrong configurations, adding a guest to Teams might create a situation where this new user now has access to files stored on SharePoint for Teams. Folks might not be aware that these files are now available to guest users who were added to their channel only for a quick chat. In addition, the ability to add Apps in Teams effectively extends the permission model to these third-party tools. This is just one example of the matrix of complex issues for each service managed via AAD.
In fact, keeping track of the permissions of third-party apps is critical and is an area that is undermanaged in most AAD implementations. These permission requests will trigger a one-time-only pop-up that lists the permissions the app needs. These lists can be lengthy and should be reviewed carefully before acceptance, but rarely are.
Organizations also might face these two new scenarios related to permissions that need to be understood in a security context:
- Third-party tools that pull data from Azure AD and store it in their own database. For example, an application registered in Azure AD that allows for a CRM system to read user profiles or has other read permissions effectively has the ability to retrieve and store data for itself. Once the data is taken from Azure AD, it sits in an external database, leaving the organization to rely on the security framework of the third-party tool.
- Third-party tools with write access that can make changes within their tool. In this case, the required authentication to make changes in the tenant is moved from Azure AD to whatever controls the third-party tool has. A user might be able to log into the tool without multifactor authentication because it does not support single sign-on (SSO), operating instead with the application acting as the permission proxy that does the action on their behalf without some of the checks that would normally be required.
IT organizations should strongly consider restricting who can approve applications or, at the very least, have clear guidance on what permissions should be considered appropriate. Taking a hybrid identity approach requires dealing with a much broader permission model. To do so effectively, organizations must establish strong governance of what apps are going to be turned on and what access rights they will get.
Understand the risk of hybrid identity management
Whether authentication is handled in the cloud, on-premises, or both, putting security first is always a must. While managing identity in a hybrid environment might seem as simple as joining a Windows device to AAD, failing to account for changes to the risk landscape opens the door to issues that can cause headaches in the future. Knowledge is always your first line of defense, but the amount of documentation needed to fully understand security in AAD is daunting. Native or third-party tools that automate that understanding and reduce the complexity of security will help lower security risk during and after the rollout of your hybrid environment.
