Part 12: How to Deliver IAM Solutions While Keeping Everyone Sane

Stepping on rakes: the ultimate extreme sport

Part 0: What Modern Identity Management Solutions Should Look Like?

Part 1: The Datastore

Part 2: Connectors

Part 3: The Sync Engine

Part 4: The Workflow Engine

Part 5: The Customers and What to deploy?

Part 6: Engineering challenges - Connectors

Part 7: Consulting challenges – Why do most RBAC / ABAC Deployments Fail?

Part 8: IAM People Management challenges

Part 9: The Unspoken Realities of Identity Management

Part 10: Confessions of a Former Hacker: From Script Kiddie to Identity Management Advocate

Part 11: What Are the Gaps in Current Identity Management Solutions?

Part 12: How to Deliver IAM Solutions While Keeping Everyone Sane

Part 13: Identity Management in the era of AI and LLMs

Part 14: Future Trends in Identity Management for 2025-2030

The Human Element in IAM: Why Methodology and Frameworks Define Success

After more than two decades of delivering Identity and Access Management (IAM) projects, one truth stands out: the success of any IAM engagement hinges on a single, critical factor – a consultant. Not just a role, but a person. A human being. While tools and platforms are important early in your career, seasoned professionals know that with enough experience and creativity, any project could be delivered using something as simple as PowerShell scripts.

This realization shifts the focus from tools and technologies to the processes and frameworks that guide IAM projects. Let’s move beyond the well-trodden "best practices" and delve into the key elements that foster collaboration, maintain accountability, and ensure smooth delivery without the finger-pointing or frustration that can derail a project.

Why Frameworks Matter

The purpose of this article is to emphasize that solution frameworks and delivery methodologies are not just bureaucratic necessities – they are the backbone of successful IAM projects. Having spent over a decade at Microsoft, I’ve seen firsthand the power of the Microsoft Solutions Framework (MSF). Over the years, it has evolved to support both waterfall and agile approaches, making it a versatile tool for project delivery.

However, this article isn’t about MSF specifically. There’s already a wealth of documentation available on it. Instead, we’ll focus on the undocumented insights and often-overlooked principles that can make or break an IAM project. While the structure of this article won’t perfectly align with MSF’s delivery phases, the lessons here are applicable across various frameworks.

Key Takeaway: Follow the Methodology – Don’t Cut Corners

Every framework exists for a reason, and ignoring its steps is an invitation to trouble. Cutting corners may save time in the short term, but it often leads to costly mistakes. Picture a field of rakes – skipping steps in the methodology is like walking blindly through that field. Every skipped step is another rake waiting to hit you in the face.

IAM projects are inherently complex, involving numerous stakeholders, systems, and processes. Methodologies provide the structure needed to navigate this complexity, ensuring that nothing is overlooked and that each phase is executed with purpose. When teams stick to the framework, they reduce risks, improve communication, and foster trust among stakeholders.

The Importance of the Presale Phase in IAM Engagements

Most Identity and Access Management (IAM) engagements begin with a crucial presale phase. This stage sets the foundation for the entire project, making it essential to approach it with thorough preparation and strategy. While cold-call sales are often unwelcome, the absence of a Request for Information (RFI) or Request for Proposal (RFP) doesn’t mean you’re out of options. Instead, take the initiative to research your client and their industry. Financial institutions, healthcare organizations, and other sectors tend to face distinct, recurring challenges – knowing these beforehand can give you a significant edge.

If you have a repository of previous engagements or similar projects, leverage it. Drawing from past successes can inform your approach and demonstrate your expertise.

The Value of In-Person Presales

While virtual meetings have become commonplace, there’s no substitute for in-person presales when it comes to enterprise-level IAM projects. These face-to-face interactions allow you to gauge your client’s corporate culture, observe their preferences, and better understand their needs. From dress codes to meeting room setups, these subtle details can reveal much about their IT maturity and organizational approach.

For instance, the choice between high-end brands like Brioni and casual wear like Lululemon might hint at their formality levels and the tone they expect in status reports. Similarly, the presence of cutting-edge hardware versus outdated systems can indicate their willingness to innovate. Even informal settings, such as a lunch meeting, can provide valuable insights into the client’s real challenges – often more than a structured online session ever could.

If your resources allow, meet your client in person. It’s an investment that pays dividends in building trust and understanding.

What to Bring to a Presale Event

Preparation is key to a successful presale. Beyond standard materials like printouts, success stories, <sarcasm> and The Magic Quadrant depicting you in the top right corner,</sarcasm> ensure you bring:

·?????? A Live Demo: A functional lab or test tenant that simulates systems similar to the client’s environment. Avoid pre-recorded videos; a live demo builds confidence in your capabilities.

·?????? Standard Project Plan, Schedule, and Pricing: A sample that outlines what the client can expect.

·?????? ROI and TCO Calculators: These tools help quantify the value of your solution.

·?????? Licensing Guide: Clear information on licensing requirements and options.

·?????? Roadmap: A strategic outline of the solution’s future development.

·?????? Assessment Questionnaire: A tool to gather detailed information about the client’s environment and requirements.

Explaining Methodology and Engagement Models

Take time to explain your delivery methodology. For example, Microsoft Solutions Framework (MSF) emphasizes phases like Envision, Plan, Build, Stabilize, and Deploy. Discuss roles, responsibilities, and the effort required from both sides, including setting up test and development environments. Address engagement models such as fixed-fee versus time-and-material (T&M) approaches, highlighting the risks of scope creep and budget mismanagement.

The main goal at this point is to ensure your customer doesn’t run away in panic after seeing the initial pricing.

It’s also important to clarify the distribution of effort in IAM projects. Typically:

·?????? 60% Planning and Documentation

·?????? 30% Building

·?????? 10% Operating the Solution

While some clients might opt for a one-person consultant to save costs, remind them of the risks. Who will maintain the solution if that individual becomes unavailable? Discuss the advantages of a phased approach, starting with:

·?????? Basic FTE Workflows (Joiners, Movers, Leavers)

·?????? Vendor Management (Contractors and guests)

·?????? Service Accounts and Non-Human Identities

·?????? Group and Role Management

·?????? Secrets Management

·?????? Governance (Access Reviews, Segregation of Duties, etc.)

·?????? Resource Mining

Managing Client Expectations

Presale is also the time to set expectations. For fixed-fee projects, emphasize that changes beyond the agreed scope will require a change request and additional costs. For T&M projects, address common misconceptions, such as the belief that they’re always cheaper or concerns about inflated hours. Transparency about your approach – whether fixed-fee or T&M – builds trust.

IAM projects are complex and require significant expertise. Clients must understand that they’re not just paying for labor but for years of experience and the ability to deliver a robust solution efficiently.

Reaching a Preliminary Agreement

Finally, aim to establish a preliminary agreement on the engagement scope. This ensures alignment between both parties and sets the stage for a successful partnership.

The presale phase is not just about selling a solution – it’s about building a relationship, understanding the client’s needs, and setting the foundation for a successful IAM engagement.

Onsite workshop

An optional but highly valuable activity during this phase could be an onsite workshop. Alternatively, you may need to conduct an envisioning workshop during the Envision phase. The main question is: who will pay for this workshop – the sales team or the customer? Such a workshop helps the customer better understand the proposed solution or product and respond to the assessment questionnaire more accurately.

Envision

Many customers struggle to complete assessment questionnaires and often require assistance. If your budget permits, consider hosting an onsite envisioning workshop lasting no more than two weeks. During this workshop, you can demonstrate your product to individual teams and collect their responses to a consistent set of questions. Key stakeholders to interview include:

·?????? The Sponsor or Business Owner

·?????? IT Operations / IT Infrastructure / DevOps Engineers

·?????? Service Desk / Help Desk Teams

·?????? HR Operations

·?????? Legal and Compliance Representatives

·?????? Procurement Teams

Don’t be surprised to receive vastly different answers to questions like, “What is the most important goal of this project?” or wildly varying estimates for user counts, workflows, or process definitions. This is a common occurrence. For instance, IT might report “50k users,” HR might say “25k full-time employees and several guests,” and the Business Owner might claim “20k seats.” What accounts for the remaining 25k users? Often, these include orphaned accounts, service accounts, service principals, contacts, computers, telecom equipment accounts, or even conference room accounts.

Sending out questionnaires via email and collecting responses without further engagement is a recipe for disaster. Trust me, it happens every time.

Once you’ve gathered and analyzed the responses, weighted them appropriately, and clarified the project requirements, your primary goal is to populate the Scope of Engagement section in your Statement of Work (SoW). This section should explicitly list the scenarios to be implemented, identity types, data sources, the number of objects to be managed, a list of roles and responsibilities, timelines, licensing considerations, and acceptance criteria. Being thorough here helps avoid potential conflicts later.

Addressing Data Quality Challenges

One of the most challenging roles to assign is the Data Quality Manager. This person is responsible for validating data feeds, such as those extracted from HR systems. It’s not uncommon to encounter discrepancies. For instance:

·?????? The employee start date shown in the HR system GUI might differ from what’s extracted via SQL views or JSON feeds. The GUI might display the initial hiring date, while the feed shows the start date for the current position.

·?????? Names can differ, such as Legal Name vs. Preferred Name.

·?????? Job titles may vary, such as PCN Position Name vs. Address Book Title.

·?????? Managerial relationships might diverge between Organizational Structure and Functional Structure.

These discrepancies underscore the importance of assigning someone to ensure data quality.

Vision and Scope Document

While the SoW outlines what needs to be built, the Vision and Scope Document provides a broader perspective, detailing the "what," "why," and "how." This document typically includes:

Problem Statement: Explains what problem you’re solving and why.

Vision: Proposes how the solution should be implemented, often breaking a multi-year project into manageable phases. Each phase is defined by its scope and expected outcomes.

Requirements: Collected during the assessment workshop, categorized as:

·?????? Business Requirements

·?????? User Requirements

·?????? Operational Requirements

·?????? System Requirements

·?????? Security Requirements

·?????? Solution Qualification Requirements

Other Sections:

·?????? Scope of Project

·?????? Acceptance Criteria

·?????? Operational Criteria (including performance metrics)

·?????? Architectural Design Strategy

·?????? Customer and User Profiles

·?????? Project Management Strategy

·?????? Assumptions

Phase 0 – Pilot Project

In some cases, it’s beneficial to propose a Phase 0 – Pilot Project, which is a short, limited-scope engagement to demonstrate the product’s capabilities. This phase is often customer-sponsored and serves as a proof of concept. Interestingly, some pilot projects have been so effective that they remained in production without significant updates for years.

Plan Phase: Setting the Foundation for Success

The primary outcome of the Plan phase is an approved Conceptual Architecture document and fully prepared development (DEV) and testing (TEST) environments. While the Conceptual Architecture document is extensive and detailed – it serves as the backbone of any successful engagement. Here’s an example of how such a document might be structured:

Having a library of these documents tailored to specific industries or scenarios accounts for 50% of the success of any engagement.

Detailed Design: The Challenge of Premature Detailing

While the Microsoft Solutions Framework (MSF) suggests authoring a Detailed Design document during this phase, it’s often impractical to define all attribute flows, synchronization rules, workflows, and configurations before building the solution. Attempting to do so prematurely often results in gaps or inaccuracies.

Setting Up DEV and TEST Environments

A critical task in this phase is the creation of dedicated and disconnected DEV and TEST environments. Only a handful of consultants possess the expertise to deliver Identity Management solutions directly into production without a safety net, and even they wouldn’t recommend it. A misconfigured synchronization rule could wreak havoc, such as disabling all production accounts – a risk no one should take.

Challenges in Modern Cloud-Centric Environments

In today’s cloud-first world, replicating a production environment for DEV or TEST is no longer straightforward. Gone are the days of simply restoring an Active Directory Domain Services (AD DS) backup into an isolated environment. Challenges include:

·?????? Cloning Entra ID (Azure AD) tenants or simulating the Azure Graph API.

·?????? Simulating cloud-based HR platforms that lack test tenants.

While these tasks are complex, they are achievable – and the expertise to do so is invaluable.

Simulating Data Sources and Targets

With a properly assigned Data Quality Manager, you can simulate nearly any data flow:

·?????? Entra ID Tenants: Use a demo tenant populated with representative data.

·?????? AD DS: Simulate with AD Lightweight Directory Services (AD LDS).

·?????? REST/JSON API Web Services: Build a simple custom web service using .NET Identity Framework and custom JSON converters.

However, certain performance-related issues remain challenging to simulate, including:

·?????? Throttling due to excessive requests.

·?????? Broken or incomplete JSON responses.

·?????? Authentication issues, such as multi-factor authentication (MFA) requirements for service principals.

·?????? Proxy and DNS misconfigurations.

·?????? PKI misconfigurations

The more effort invested in creating a production-like test environment, the fewer issues you’re likely to encounter during deployment.

Migration and Deployment Strategies

Another critical decision in this phase is how to manage the migration of solution configurations from DEV to TEST and from TEST to PROD. This involves defining:

·?????? Change validation processes.

·?????? Change Approval workflows.

·?????? Deployment strategies.

Establishing these processes early ensures smoother transitions and minimizes disruptions during deployment.

Build Phase

The Build phase is often seen as the simplest and most monotonous part of the project, but it is crucial for laying the foundation of a successful Identity and Access Management (IAM) solution. At this stage, you are building a solution that must eventually pass acceptance criteria – criteria that are yet to be fully defined and may evolve as the project progresses.

Here are key aspects to consider during the Build phase, especially when working with modern cloud-based solutions:

·?????? Ability to Pause Individual Connectors: Implementing a feature that allows you to pause individual connectors can be crucial for troubleshooting and managing integration failures without affecting the entire system.

·?????? Safeguards Against Large Data Changes: Set up safeguards to stop connectors when incoming changes exceed a certain threshold – such as when changes surpass 50% of records or deletions exceed 10%. This helps prevent potential data integrity issues or system failures caused by a source data failure.

·?????? Preview Changes Before Processing: It’s important to have the ability to preview changes for an individual object that has been imported but not yet processed. This ensures you can assess the impact of changes before they are committed to the system.

·?????? Data Dumping for Validation: Establish a method for dumping raw data from specific connectors. This allows you to compare the actual data received against what was expected, ensuring data accuracy before processing.

·?????? Staging Changes for Export: Set up a staging area where all changes are queued for export. This gives you the opportunity to examine them before they are sent to the target system, ensuring that no errors or unexpected issues occur.

·?????? Avoid Using the Target Directory as the Metaverse: It’s essential not to use your target directory as your metaverse. This practice can lead to complications and problems that are difficult to resolve.

·?????? Plan Initial Data Load: Pay special attention to planning your initial data load. If you’re working with limited compute resources, be mindful of the potential for system overload when processing millions of changes at once.

·?????? Retroactive Policy Application: Verify whether you can apply policies retroactively after they have been enabled. This ensures that you can enforce policies across existing data if necessary.

·?????? Tie Policies and Workflows to Scenarios: Make sure that your policies and workflows are aligned with the specific scenarios that your solution is designed to address. This ensures consistency and relevance in the solution’s operation.

·?????? Naming Conventions for All Components: Establish clear naming conventions for all moving parts of the solution – synchronization rules, policies, workflows, sets, UI configurations, and schema updates. Consistent naming improves readability and maintainability.

·?????? Disaster Recovery and Business Continuity Planning: Prepare for the worst-case scenarios by planning for disaster recovery and business continuity. This ensures that your IAM solution can continue to function and recover from unexpected disruptions.

By the end of the Build phase, you should have a working solution in your DEV environment, along with a clear plan for migrating it to the TEST environment. From a documentation perspective, you should prepare a draft of the Detailed Design document, outlining all configuration artifacts, explaining what each policy, workflow, or synchronization rule does, and how to deactivate or modify them if needed. This document will serve as a reference throughout the rest of the project.

Stabilize

The primary goal of the Stabilize phase is to validate that the solution is functioning as designed. To achieve this, you should begin by preparing the following documents:

·?????? Test Plan and Acceptance Criteria / Checklist

·?????? Deployment / Implementation Guide

·?????? Operations Guide

·?????? Detailed Design Document

While this phase may seem straightforward, the key to success lies in having a comprehensive test plan – <sarcasm> ideally one that spans over 500 pages </sarcasm>. This plan should not only cover the scenarios outlined in your Statement of Work (SoW) or Architecture Document but also include edge cases and extreme situations that could potentially disrupt the system. These scenarios might include:

·?????? Connectors being unexpectedly shut down during import or export

·?????? An unusually high volume of ‘bad data’ being received

·?????? Databases or target systems becoming unavailable

·?????? Intermittent connectivity issues

·?????? Users interacting with the system in ways that weren't anticipated (e.g., pressing all available buttons, ignoring error messages, entering random data)

·?????? Restoring data source databases or target systems to previous versions

·?????? Expiring service accounts

·?????? License validation failures

·?????? System administrators inadvertently revoking permissions from service accounts used in the solution

Once the solution is ready for deployment, it’s crucial to run the Test Plan in the customer’s TEST environment. This is a critical step to ensure that all stakeholders, including HR and Help Desk teams, are familiar with the solution’s operational aspects. It’s particularly important for HR Operations to understand scenarios like when they might inadvertently reuse a candidate’s record (e.g., Jane Doe, who never started) for a new employee (e.g., John Doe, who just started but hasn’t been fully onboarded yet). Ensuring that these teams are aware of the potential consequences of such actions will help avoid costly mistakes down the line.

Initial Data Load

By now, I hope you're working with a robust, state-machine-driven product rather than a fire-and-forget, stateless solution. If not, be warned – rakes are waiting.

In an ideal scenario, follow this process:

·?????? Turn off all policies and workflows – You don’t want to trigger 50,000 welcome emails or any other unintended actions.

·?????? Import data from all connected sources, but do not process it yet.

·?????? Project HR and human-related data into your metaverse. Nothing should happen because policies and workflows are disabled. At this stage, check for records that weren’t projected, such as employees who left 10 years ago but weren’t filtered out during import.

·?????? Join imported identities with HR data. This will create a list of “disconnectors” – records that didn’t match any human identity. Some of these may be legitimate secondary accounts, service accounts, or contacts, but you’ll also find “diggers” – accounts that have been around for years without being noticed. <sarcasm> Fortunately, you’ve already planned for unmanaged accounts: disable them and wait for their true owner to raise a concern </sarcasm>.

·?????? Project non-human identities into the metaverse: computers, service accounts, application security principals, groups, etc.

·?????? Convert groups that need to be dynamic into dynamic groups.

·?????? With policies and workflows still off, the only changes staged for export will be direct flows from one data source to another. Export this list into a report and have your Data Quality Manager review and approve it. You'll likely see numerous updates to names, job titles, phone numbers, and more. If you notice a change from "Jane Doe, VP" to "John Doe, janitor," it’s often a sign of an incorrect join, not a demotion.

·?????? Once you're satisfied with the report and no harm is anticipated, export data to all connected systems while keeping all JML policies and workflows off. This minimizes the number of changes that will need to be reviewed in the next step.

·?????? Now, you're ready to turn on policies one by one (keeping notifications off). For example, enable a policy that blocks users on long-term unpaid leave. Let the workflows run their course – marking users as disabled despite their working status. Then, review the changes staged for export while keeping your connectors stopped. Once your Data Quality Manager approves these changes, proceed to the next policy.

·?????? With connectors still stopped, execute the first Test Plan run, assisting the customer and exporting affected objects one by one.

It’s likely that some unwanted or unexpected changes will be staged for export, especially since your test data and environment may not match exactly what’s in production. Additionally, your policies, workflows, and synchronization rules may not cover all edge cases. This is why control over connectors and the synchronization process is critical. Without it, rakes are waiting.

Deploy

From a business perspective, the primary goal during the deployment phase is to ensure that the customer is equipped with the necessary documentation to independently operate the solution moving forward. In addition to the standard documentation artifacts recommended by the Microsoft Solutions Framework (MSF), there's one crucial step that can make all the difference: allowing the customer to execute the Test Plan on their own, without any involvement from you or your team. This is the ultimate indicator that the engagement is transitioning into the post-engagement phase, and it's time to start planning a celebratory dinner.

However, the reality is often different. Many customers not only expect a warranty period but also request a fixed number of "support hours" – pre-paid hours to address any questions or issues that might arise after the solution is deployed. This is where the Time-and-Materials (T&M) approach can reveal its shortcomings. The consultant who initially delivered the solution may no longer be available, possibly working on another project. According to the contract, you are still obligated to provide support, but the question remains: will the available resource truly be able to assist? It’s a rhetorical question, as the answer is often unclear.

With a fixed-fee project, however, you have the advantage of booking a concrete amount of hours and defining the duration for supporting the customer during the early stages of their IAM solution's operation. <sarcasm> And when I say "early stages," I mean years. </sarcasm> The support you provide during this period is critical to ensuring that the solution remains effective and the customer feels confident in its ongoing use.

Why Are We Forced to Dance in a Dark Ballroom Full of Rakes Blindfolded?

The answer is the same reason we face feature gaps in cloud identity management solutions: The world has changed, and it seems no one is building products for developers or consultants anymore. Instead, everyone is focused on offering a subscription to a simplified cloud service because that's become the trend. Even the role of the Project Manager (PjM) has evolved from a technically skilled person to someone who simply asks for status updates with a "customer is waiting" mindset.

When a product is built by developers for developers, and the PM has real-world field experience, the product often benefits from a range of small tools developed by the community to address feature gaps. For example, in the case of FIM/MIM, several tools have been created:

·?????? GitHub - GreyCorbel/SIDCloner: Demonstrates how to populate SID History on security principals migrated cross AD forest from PowerShell session

·?????? GitHub - microsoft/MIMConfigDocumenter: MIM configuration documenter is a tool to generate documentation of a MIM synchronization or service installation.

·?????? Home · microsoft/MIMWAL Wiki · GitHub

·?????? GitHub - pieceofsummer/FIMDelta: Helper utility to selectively apply changes between developer and production FIM2010 servers

·?????? Lithnet AutoSync for Microsoft Identity Manager: A tool for automating synchronization tasks.

However, it is very unlikely that we will see similar tools developed for cloud solutions. This is because, with cloud-based platforms, you often don't have access to the underlying databases, internal APIs, and other essential resources. As a result, you're often forced to rely on "turnkey" solutions that may not fully meet your needs. More on this in Part 11.

What About Managed Identity Management Services?

I actually like the idea of a company offering a "standard" but slightly customized identity management solution for small and mid-sized businesses. Here are a few thoughts on this:

·?????? Amazon doesn’t seem particularly interested in this business, as they don’t have productivity tools to offer. I imagine they’d prefer to partner with a mono-vendor to secure access to their resources, in some way.

·?????? Google has its own productivity suite, but I’m not aware of any internal tools they could use to offer such a service. While operating a third-party solution is possible, it would feel a bit odd for them.

·?????? Microsoft has great offerings targeting infrastructure, virtual desktops, and monitoring, which could make them a strong contender in this space. Impossible is nothing ? Adidas.

·?????? All IdM vendors – the probability of this happening is low, in my opinion. Identity management is all about trust, which requires operators with the proper clearance and citizenship. This could become too costly and not scalable in the long run.

·?????? Top 5 consulting companies – this is definitely doable. They can afford to be platform-agnostic. If they strike the right balance between sales, pricing, and maintaining trust, while avoiding the need to outsource operations to offshore teams, they could succeed. The best part is that they would be in a position to demand missing features from vendor A, and even threaten to migrate their clients to solutions from vendor B if their concerns are ignored.

How Do I Learn All This? Is There a Book?

Learning all this is relatively straightforward, though it often involves stepping on rakes for 25 years, gaining experience, and knowing what to expect. Find a partner to explore newer rakes models together, and treat each other's wounds along the way.

Previous: Part 11: What Are the Gaps in Current Identity Management Solutions?

Next: Part 13: Identity Management in the era of AI and LLMs