Continuing the Identity Discussion

Introduction

Identities are the cornerstone of any cloud service or application, including IaaS, PaaS, and SaaS services. As a result, the starting point for any organisation moving to the cloud should be its identity strategy. In the Zero Trust model, identity also forms the strategy’s first pillar and forms the basis for the other components of Zero Trust.

It is worth noting that in the context of this article, identities refer to anything in the estate that requires authentication and authorisation to access resources, including users, service accounts, devices & applications. For ease, I will be referring primarily to user-based identities in this article unless otherwise stated.

Hybrid or Cloud Identities

Choosing between cloud or hybrid identities is moot for most organisations, as they will have an extensive on-premises Active Directory or similar setup, which they want to maintain when leveraging cloud solutions. The primary reason for this is that (assuming implemented, and I did work on a client several years ago who had made a conscious decision not to synchronise their user accounts) the usernames and passwords for the user will be the same for on-premises applications as those in the cloud. This provides a benefit in management and security. Still, most notably (probably), it makes user adoption so much easier to achieve as users do not need separate identities applications/services that can be configured to leverage Entra (i.e. Single Sign On or SSO).

The on-premises Active Directory must be synchronised to implement a hybrid identity strategy. This involves the deployment, configuration and implementation of Entra Connect (formally Azure AD Connect, https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect ); this is a tool which, in effect, creates and maintains a copy of the on-premises identity, password (via password hash), group membership and other information, such as manager, department etc.

I am not going to drill down into Entra Connect here. Still, there is one area I thought I would highlight here, is that in my experience, there are a lot of organisations that do not manage their employee information, such as manager, department, location, etc., in Active Directory typically, this is in an HR system or some other System of Record application. I am not suggesting anything incorrect in this approach; however, one area I have seen cause user friction is around this type of data, as M365 and Entra use this information in a variety of ways, and if this is missing or incorrect, it can negatively impact user sentiment and experience. As a result, I would strongly suggest that organisations have a plan for how to get employee information into AD or Entra so that it can be leveraged effectively (See the RBAC section for more details)

There are some scenarios where having a cloud-only identity can make sense; for example, you may want administrators, service principals or devices only to have a cloud instance of their account. You could operate with a cloud-only identity for organisations, starting with a greenfield approach. This assumes that organisations can operate using cloud-only applications and services. Even in this case, consideration should be given to scenarios where an on-premises solution may need to be added to the estate.

Authentication vs Authorisation

One of the key concepts of zero trust is the never trust, always validate. As a result, a lot of emphasis is placed on authentication and authorisation, as this is undoubtedly one of the ways that this principle is enforced.

It is essential to understand that there is a big difference between authentication and authorisation, even though I have seen the terms used interchangeably. Authentication refers to proving who the user is, and authorisation refers to the “permissions” provided to the user. Suppose I go back to the example I gave in part 1 of an office building (https://www.linkedin.com/pulse/understanding-zero-trust-microsoft-cloud-part-1-richard-hogan-cbyee/) the first time you go to the office, you will typically need to identify yourself (i.e. Authentication); this may be by providing your passport, driver’s license or some other form of identification, at which point they may give you a fob or keycard which allows you access to parts of the building i.e. authorisation. In this scenario, you will (probably) only need to authenticate on that first day; every time, henceforward, when you present your keycard, you are re-asserting your authorisation to access that location or resource.

Thumbnail Image Cartoon style image showing someone being denied entry to an office building using a key card, with automatic gates and some people being allowed through, with a sign saying 'Access Denied'

Multi-Factor Authentication

The example above is sort of an instance of Multi-Factor Authentication (MFA), in that it requires something that you know (i.e. your name, location of the office, role or other pertinent information) and something you have, i.e. your passport, driver’s license etc. MFA in terms of the authentication process is similar, just instead of your name it will be a username of some description with the second factor being an action that you would need to perform, like receive an SMS, use an authentication app, or a YubiKey or similar.

Please see the previous article for a somewhat more in-depth explanation of MFA.

RBAC (Role Based Access Controls)

When I started in IT, it seemed to be popular to manage permissions individually, i.e. if you wanted to share access to a file share, you would add the user account and set the permissions individually for that account. The same was quite often valid for IT administration permissions.

However, at an enterprise scale, it is unsustainable, especially from a central IT capability to manage user access and permissions on a user-by-user basis. Enter RBAC, or Role Based Access Controls. The idea with RBAC is that users tend to have distinct roles within an organisation, both IT administration/operations and end users. The assumption is that anyone who performs the role of an Exchange Admin would require the same permissions as each other; this can be extrapolated out to include business users; for example, salespeople would all need access to the CRM, the document library where PowerPoints are stored etc.

Entra ID manages this in two ways: a suite of pre-defined roles relating to the operation aspects of the underlying service, e.g. Exchange Administrator, Global Administrator and User Administrator. These roles have a default level of permissions associated with them, and you can assign users to these roles either directly or via groups (more below). You can create new roles and configure the permissions if required. Users (or, better still, groups) can be assigned to these roles and would inherit the necessary permissions set at the role level.

A Group is a collection of users who share a similar role, requirement, location or some other property; for example, you may create a group called salespeople and add all the organisation’s salespeople to this group. You can then manage the permissions for the users as a whole instead of individually. Groups can also be added to the roles described above. IT Admins would only need to manage the group instead of the ‘X’ number of individual users, simplifying management and theoretically improving security.

The above describes a static Group, i.e. users are added manually (via scripts, 3^rd party apps, etc.). However, there is a more powerful way to manage how users are added or removed from a group natively in Entra ID; this is by using Dynamic groups. A Dynamic group allows Entra to add and remove users based on a user property automatically; this is one reason why having more user information in Active Directory and, therefore, in Entra ID is beneficial.

For example, if we used the department field in AD, we could pivot on that field and create a rule that states that if a user has a Dept = “Sales,” that user should be a member of the corresponding Sales security group, the same logic works in reverse, so if a user moves roles and no longer has the sales dept tagged in AD, then they would be removed from that group automatically.

Access Reviews

Now we have groups that contain users, we must understand how to manage the lifecycle of group memberships. One of the most significant issues around permissions management for organisations is stale permissions, i.e. permissions that are no longer required but have been left assigned to the user. This typically results in a user having more permissions than is necessary for their roles. This is a risk, both in terms of inadvertent activity and potentially opens up the risk for malicious internal and external threats.

One way to mitigate this risk is to implement Privileged Identity Management and Privileged Access Management tools and policies (i.e. PIM & PAM, which I will cover in the following article), but a straightforward way of allowing the users or their managers to self-certify continuing access, is by using Access Reviews within Entra.

An access review is, in effect, a workflow that can be configured to run one or multiple times. It sends a request to either the member of the group, the group owner or the members manager to confirm whether they still need access to the group and the underlying resources. The recipients then have the option of continuing or revoking their access, which is a great way to mitigate permission sprawl, without adding additional overhead onto the IT teams.

It is a little old now, but I did create a video and a blog post which goes into much more detail around this subject and can be found here https://themicrosoftcloudblog.com/2022/08/23/azure-ad-access-packages/

In the next article, I will explore the options and strategies around developing a PIM/PAM capability in Entra

Listen to the Podcast

For more content like the above, please check out our new Podcast, Cloudy with a Chance of Insights, published every other Friday on YouTube, Spotify and most podcast platforms.