Identity and Access Management – The Cart or The Horse?

In my experiences with identity and access management (IAM) projects, there is always a moment when you begin having a “Are we putting the cart before the horse?” conversation.  This is particularly the case when you are, in parallel, having a conversation about how to “enable” IAM in the environment by either redesigning your current implementation of Windows Server Active Directory, creating or modifying organization roles and their definitions, or some combination of both.  So where do you start and how will this impact the success of your project?

Step 1 – Identify the Real Problem

Through experience, I’ve learned the best starting place for an IAM project is not at the technology level, but rather at the business level.  Identify where the business is strugging as it relates to user identities provisioning, terminating, changing, and access.  Something I commonly hear from clients is: “We inconsistently provision accounts because the business cannot tell us what resources a user needs access to and at what level.  Do not even get us started about changes.  Removing a user from the environment? Ha, well, that happens quarterly (maybe) and is mostly manual.”

This conversation tells me that within the organization, there is a friction point with role definition and is where the project needs early focus and attention.  If roles are not defined, there is no way to logically categorize user. And no, I am not talking about mirroring an org chart and calling it “good”, but rather defining roles for the responsibilities employees have day-to-day.  If categorizes of users cannot be created, then the appropriate level of access cannot be applied and in turn no IAM solution on the market today can effectively automate account provisioning, termination, or changes. If that cannot happen, there is then no means of successfully auditing any of this process.

Start with a simple approach, something like this:

Build Your Team   Collaboration Roles
IAM Owner

Receives inputs
Active Directory Owner

Receives inputs
Business Owner

Definition of business roles, their responsibilities, and overlap
Application Owner

Definition of technical roles, their responsibilities, and overlap

Note: This effort should form the basis of a continuously leveraged framework in a lifecycle management effort for determining how to create or change a role and its definition.

Step 2 – Align Business Challenge with Technical Solution

Now that you’ve begun to define roles and responsibilities, you should start to map those roles into your Active Directory design or re-design.  This mapping should ideally happen in two specific places: 1) people groups and 2) access groups.  When Step 1 & 2 are combined, you have begun the process of developing and implementing a Role-Based Access Control model.  The general principles of this model are access rights are grouped by role name, and the use of resources is restricted to individuals authorized to assume the associated role.

For example, within a healthcare system, the role of clinician can include operations to perform diagnosis, prescribe medication, and order laboratory tests; and the role of student intern can be limited to gathering anonymous clinical information for studies happening in the same healthcare facility and within the same system.  The use of defined and governed roles to control access can be an effective means for developing and enforcing enterprise-specific security policies, and for streamlining the security management process.

Start with a simple approach, something like this:

Build Your Team   Collaboration Roles
IAM Owner

Receives inputs
Active Directory Owner

Maps business roles to AD groups and access; creates specific OU structure to accommodate IAM provisioning
Business Owner

Iterative changes to roles and responsibilities
Application Owner

Iterative changes to roles and responsibilities

Step 3 – Begin Implementing the IAM Solution

With our roles and responsibilities established and mapped into Active Directory, we have the required foundation to begin the implementation of our IAM solution.  A few things to note at this stage:

  1. Depending on the size and complexity of your organization, the effort to get to this stage in the project could be significant.
  2. You do not need to complete the definition and mapping of each role and responsibility to begin Step 3.
  3. Even when you get to this stage, you may still need to engage all the other project owners to continue to make iterative changes.
  4. You must define a source of truth.

Another area where I have seen my clients struggle when beginning the implementation portion is a failure to take a slow and methodical approach with realistic expectations.  There is a thought that overnight, an environment will be transformed from highly manual to highly automated.  That just is not very likely.  Instead, decide upfront to take steps that are more measured to first build adoption and eventual project success.

The most logical area to begin is to automate the provisioning of user accounts into your source of truth.  In this case, let us assume that will be Windows Server Active Directory. 

Start with a simple approach, something like this:

Build Your Team   Collaboration Roles
IAM Owner

IAM solution implementation, configuration, and testing
Active Directory Owner

Validation of provisioned objects
Business Owner

Iterative changes to roles and responsibilities
Application Owner

Iterative changes to roles and responsibilities

The general steps for this would be:

  • Implement your IAM solution
  • Implement and configure an IAM connector to a system such as a HRIS system.  These connectors will be usually what is referred to as with call-based (able to leverage an API function call) or file-based (leverages a text file to import data).
  • Select the account attributes you wish to “flow”, such as:
    • display name – makes user recognizable
    • managedBy – shows the owner of the user
    • department – tracks the user’s department
    • sAMAccountName – the NetBIOS name of a user
  • Through the IAM solutions connector management UI, configure how attributes map from the source system to the target system.
  • Configure how the systems will address conflict resolutions
  • Configure how often the systems will run the synchronization job
  • Provision a sub-set of accounts
  • Test:
    • Account was provisioned correctly into Windows Server Active Directory
    • Account has the proper attributes populated with the proper values
    • Account has the ability to login to the environment (the account password behavior works as configured)

Once you have successfully tested basic user account provisioning, the next steps should also be incremental and fundamental in nature:

  • Change control
  • Termination
  • Audit
  • Data or application access

If an IAM solution introduced into your environment is done with a mind of resolving a business challenge and conducted in a controlled manner with realistic expectations, you and your organization can avoid being like so many before you who have failed to successfully implement the solution.  Just remember to ask, “What is the horse and what is the cart?”  Still have a question?  Let us know by leaving a comment below or emailing me at eacee@westmonroepartners.com. We are here to help!

Your email address will not be published. Required fields are marked *

Phone: 312-602-4000
Email: marketing@westmonroepartners.com
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons