Why you need Active Roles, even if you have IGA

Here are two scenarios I come across frequently, with customers of all sizes, in all industries, when discussing One Identity Active Roles:

1. “We have an IGA solution. It already manages our Active Directory just fine. Why do I need this?”
2. “We don't have an IGA solution yet but would like to implement one in the next X months/years. Wouldn't we just be repeating ourselves if we implement this now?”

These situations come from customers on all points of the "Identity Security Maturity" spectrum. Those who have nothing in place or some things in place or an entire stack of fully implemented solutions in every category. Although all of them have different needs, pain points and solution gaps, as long as they have Active Directory (AD), they all need an AD Management solution like Active Roles.

Before discussing the benefits Active Roles provides that Identity Governance & Administration (IGA) solutions can't, it helps to highlight what each of these solutions is designed to do, what they typically do and where they overlap.

IGA Solution Overview

IGA solutions, like One Identity Manager, aim to fully govern the identities within your organization. This includes all accounts, entitlements, permissions, etc., across your entire on-premises and cloud infrastructure. These identities typically include employees, contractors and others who need access to any number of corporate systems. Often, this extends to vendors and other third parties, and sometimes service identities, customers and more. The picturesque end goal is to build a consolidated, unified source for all identities that have access to anything within your organization by correlating data from source systems, like an HRIS or ERP, and by automatically controlling the access they have to all possible target systems, like AD, email, on-premises and cloud applications.

IGA solutions offer a broad spectrum of capabilities, and anyone who's implemented one knows that it's not just a project to implement these features, but an ongoing journey.

Common Features of an IGA Solution

• User Lifecycle Management (ULM): Automated provisioning of user access to all target systems within your environment, access changes within those systems stemming from requests or role changes and deprovisioning of access to those systems
• Role-Based Access Controls (RBAC): ULM processes are commonly driven in part by roles granted automatically to identities based on attributes like their job title, department or location
• Self-Service Access Requests: End users or their managers can request appropriate access to target systems or applications needed to do their job, usually with an approval process
• Access Management for Administrators: System admins and owners can manage who has access (and how and when) to the systems or applications that they are responsible for
• Attestations (a.k.a Certifications): System owners, managers and others can be required to perform regular, or ad-hoc, campaigns to ensure that only the right people have the right access to the right systems at the right time
• Segregation/Separation of Duties: Policies enforce the access identities have across all managed target systems so that no inappropriate access is possible, outside of exceptions that are configured, approved, logged and auditable
• Reporting & Auditing: Custom reporting features and audit portals allow the necessary people to ensure that all access is correct and/or to validate how and why someone may have inappropriate or otherwise non-compliant access across all target systems

In summary, IGA solutions are identity centric. They keep track of a person. This person was created directly or came from some other source system. This person has access to one or more target systems, and within those, they have entitlements. The entitlements they have in those systems are managed automatically via RBAC rules based on data from the source system or from that access being requested, and is kept in check by system owners and managers testifying to that access regularly. When that person is no longer with the company, all their access is removed.

IGA solutions, generally, treat Active Directory just like any other target system. However, Active Directory is much more than just an application that employees need access to.

AD Management Overview (Active Roles)

Active Roles, on the other hand, aims to be your "Swiss Army Knife" for securing access to and performing day-to-day operations in AD. And, whenever I say "AD," that includes Exchange, Azure AD and Microsoft 365. While IGA solutions focus on identities or people, Active Roles focuses on directory objects (e.g., user accounts, groups, OUs, mailboxes, computers, etc.).

At the core of Active Roles is its delegation model, which acts somewhat like a proxy or a firewall in front of AD, providing fine-grained access controls to enforce a true least privilege access model for all users and administrators. Think of this as Privileged Access Management (PAM) for AD and Azure AD. Taking advantage of this and other features in the toolset further allows you to:

• Enforce data standards to ensure that your objects and their attributes align with your requirements
• Automatically organize objects into virtual containers based on queries or group memberships, and delegate access to those objects
• Manually or automatically clean up unused and non-compliant objects
• Simplify Help Desk processes and shift responsibilities from Help Desk staff to system owners and managers
• Automate the management of directory objects and much more

In short, they're designed around two entirely different paradigms, and each have distinct features. However, the slight functional overlap is what often brings about confusion.

The Functional Overlap

There are three key functions that both IGA solutions and Active Roles can perform, to varying degrees, in AD and Azure AD:

1. User Lifecycle Management
2. Role-Based Access Controls (RBAC)
3. Administrative Access

When an IGA solution is in place, or is planned for implementation, best practices dictate that it be the driver of these functions for your employees. So, to reiterate, why would you still need Active Roles? Let's return to the two questions from the beginning of the article and discuss how it fits into both scenarios.

AD-Centric Identity

“We don't have an IGA solution yet but would like to implement one in the next X months/years. Wouldn't we just be repeating ourselves if we implement this now?”

This approach is typically for organizations that are new or not very mature in their identity strategy, and for whom AD is the primary source of user access. In this scenario, Active Roles provides User Lifecycle Management capabilities to provision, update and deprovision AD accounts for your user identities.

User Lifecycle Management

For those that have a reliable HR system or another accurate employee data source, this process can be entirely automated with the Active Roles Synchronization Service. For those that don't, users can be managed semi-automatically via the Active Roles web interface. You can delegate appropriate access to those with the authority to create, update and deprovision user accounts and streamline the process by auto-generating certain attributes, restricting certain fields (like department or title) to a pre-defined list of options or automating additional provisioning tasks with workflows. So, even if manual provisioning is required, the entire process can be delegated and streamlined.

Role-Based Access Controls

Active Roles can automatically assign access to AD groups via dynamic group membership. This membership is calculated based on a query you configure and is updated automatically whenever a user's relevant attributes are changed.

Administrative Access

By "Administrative Access," I mean delegating responsibility to people within your organization to manage some degree of operations on users or objects. Active Roles is designed around its delegation model for AD, which allows you to grant permissions to people like HR, Help Desk staff and system owners to manage the users, groups or other objects they are responsible for.

Summary

For an AD-centric organization, Active Roles is a simpler, more lightweight approach to quickly get started with building an identity strategy when compared to the more laborious process of implementing IGA. It gets you from a state of little-to-no identity management into a state where you have automated lifecycle processes, clean and accurate user data, roles defined for users based on their attributes and a clear idea on who needs access to manage these users.

As your organization matures and your needs expand to include IGA capabilities, you already have a clear model in place to jumpstart that project. Or, in the case of One Identity Manager, the direct integration with Active Roles can utilize much of what you've already built, allowing you to focus your implementation on other target systems.

Meanwhile, Active Roles is still utilized for the other functionality it offers that is either not possible in your IGA solution or not rational to do with IGA.

IGA for Identities, Active Roles for Everything Else AD

“We have an IGA solution. It already manages our Active Directory just fine. Why do I need this?”

For organizations that already have an IGA solution, or otherwise don’t need to manage the lifecycle of user AD accounts, the premise is this:

IGA covers your employees, contractors, vendors, etc. It creates their AD accounts with the appropriate access, updates their access upon role changes, access requests and attestations and deprovisions their account upon termination. However, managing AD requires much more than managing employee user accounts.

AD Management Questions to Consider

• Who’s responsible for and how are they currently managing the following: organizational units, groups, mailboxes, service accounts, computers, contacts, etc.?
• Is everything structured in a way that makes sense for your business requirements?
• Does access to AD objects follow a least privilege model? Remember, by default, everyone in your organization has full read access to the directory
• Do all your other AD objects follow the standard practices that you've defined within your organization? Here are a few basic examples:
  • Service Accounts
    • All begin with SVC_
    • Have an owner, description and department assigned
    • Are set to “Password Never Expires”
    • Have a “Service Type” attribute set that is either “Server, Database, Application or Other,” and have a computer object assigned to the “Server” attribute if “Service Type” is set to “Server”
  • Computers
    • Are linked either to a user (for workstations) or an owner (for servers)
    • Have a “Cost Center” attribute that’s restricted based on a list populated by a data feed
    • Have an "Eligible for Refresh Date" attribute, which is auto-calculated based on the date they were created, and eligible computers are automatically available in a custom container where IT staff can see them
  • AD Groups
    • Have a primary and secondary owner who have the ability to manage attributes of that group and its memberships
    • Require approvals if anyone besides the owner changes the group memberships
    • Have an “Applications” attribute to denote which apps they grant access to
  • Are you tracking unused objects and risky permissions and either automatically remediating those or delegating restricted access to manually remove them? For example:
    • A team of three people has access to all computer objects that have not logged on in more than 90 days. They can read all properties, disable the object, change the owner and check/uncheck an "exception" that requires approval from an IT admin before they are removed from the list
    • Changes to domain admins, enterprise admins and other privileged groups require multi-step approval and trigger notifications to administrators. This membership is evaluated regularly and, where possible, access is granted via more fine-grained permissions
    • Deprovisioned groups and user accounts, including service accounts, are automatically deleted after a retention period. Disabled objects that are not scheduled for deletion are regularly checked and remediated appropriately

Summary

Active Roles enables you to delegate access to any user to make only the changes they need to in AD, streamlines the day-to-day management of AD and provides capabilities that native AD tools and IGA solutions don't offer.

Could you build some of this in an IGA solution to meet your requirements? Sure, most IGA solutions are endlessly customizable. However, the effort involved would be extensive, the user experience would be more complicated and lacking and extending it to adapt to future requirements would be daunting. IGA solutions are simply not designed for directory management the way Active Roles is.

To stick with the "Swiss Army Knife" analogy: you can consider both IGA and Active Roles as multitools, but with different tools available. They both have a screwdriver, scissors and a file. However, IGA has a serrated knife and a bottle opener, while Active Roles has a straight blade and a can opener. Sure, you could use IGA's serrated knife to open a can, but it's going to be tedious, and you'll probably cut yourself a few times. The same applies the other way around. The straight blade could probably open a bottle, but I'm not going to try that when I have a bottle opener.

Learn More

Find out how One Identity Active Roles and IGA can help you optimize your AD environment.