Over the last few weeks, we have looked at how a good Identity and Access Management (IDAM) solution can help to bolster your cyber security stance and improve user productivity, but this is not the only benefit IDAM solutions can deliver for an organisation.
Market-leading IDAM solutions can also help Enterprise customers solve the challenges that a legacy multi Active Directory (AD) forest infrastructure can cause, in terms of interoperability and when you want to run the entire Enterprise though a major transition, such as migrating to Office 365.
This can be an incredibly complicated scenario for some organisations, so today’s blog is really a whistle-stop tour of the high-level business issues rather than a technical deep dive.
The Multi-Forest World
If there is one universal truth about our existence, it’s that things are always changing. This is as true for businesses as it is for anyone else. Organisations across the planet are starting up, growing and merging on a daily basis.
Quite often, the plan for a new organisation at start up is not the plan a year or two after inception. A new small business may start up as a standalone entity, become successful and merge with another larger organisation. A successful business may spin up a subsidiary, at the time it may be strategically sound planning to run this as a separate entity to enable separate management and control, or to enable future mobility around a multinational group. A successful business in a particular industry area may be on a fierce merger and acquisitions trail, and buy up technology, skills or market share from other organisations.
In the public sector currently, there is a significant amount of consolidation happening where organisations are realising that centralising platforms from previous standalone departments is a route to improved collaboration and connectivity, as well as cost savings.
When any of these organisations come together, the typical first step from a technology merger perspective is for the lead entity to assume overall control and management of the existing entities Active Directory structure as is. The long-term plan will often be to consolidate the directories at some point. However, there are a lot of challenges to overcome before this happens and as a result, most organisations will look at some simple strategies to enable these legacy AD structures to co-exist, such as federation, which we will look at in a little more detail later in this blog.
Unless there is a specific business requirement to maintain a level of segregation between the entities, merging all users onto a central identity platform is the sensible business choice. This way, all users natively have access to all people and other resources, the admin management overhead is lower, and if the Active Directories are hosted on-premise, there will be a reduction in infrastructure, support and power costs as a result.
Challenges in Merging Active Directories
There are a host of challenges in merging the Active Directories of two organisations or subsidiaries, and those challenges grow exponentially when you are talking about three, four or more legacy Active Directory instances.
Firstly, there are likely to be differences in the structure and composition in the attributes of users in each of the legacy AD forests. For instance, one company may include a unique employee identifier such as a payroll number or employee number in their directory under a specific attribute. The other organisation may not have done this or may have included the information in a separate attribute field. If both Active Directories have been well maintained and managed, this can often be resolved through some simple scripting, but in practice, there will often be inconsistencies in every Active Directory. There will be users with missing information, information in the wrong fields where users Active Directory information has been populated manually, (we covered challenges with provisioning in a previous blog), or where changes in processes have occurred over time.
Pulling two or more disparate Active Directory instances together requires a lot of careful planning, detailed auditing of current data and a multi-step programme of amendments and cleansing before you can even get to the migration stage.
Typically, most organisations will be looking to gain some cohesion from the merger of these AD forests by rationalising the email addresses in the overall corporate convention. If XYZ Corp is acquired by Example Inc, the desire of the organisation is likely to be that everyone at XYZ Corp gets an Example Inc email address. For the vast majority of users this works fine, but there will be some elements that require much more work to rationalise.
For instance, each organisation might have a group mailbox for HR, payroll, IT and customer services, or other similar organisational functions. In some cases, these resources may be merging, and a single email group with all of the users contained within it may be sufficient. In other cases, there may need to be some planning to have disparate and identifiable separate email groups for specific teams.
There is also the random human name element to consider. In any merging of organisations, you run the risk of having two people with the same name, which means that a simple migration of the user is going to cause a duplication. Dealing with this technically is fairly simple, but it does cause some issues with automating processes and opens up an HR issue in terms of how you deal with the duplication. People can get upset about changes to their display name or underlying email address in some circumstances, so the human element of the changes need to be handled very sensitively.
There can also be additional challenges around organisations that use a lot of contractors, where they have to provide short to medium term identities, but the data they have is not consistent with a full-time employee. Sometimes, these contractors become full-time employees and that can exacerbate all of the issues above.
Finally, the hardest part of any AD migration is unravelling the applications in use in a business. For a smaller company this is a fairly easy task, as there will be mostly off the shelf applications in use. For larger companies and government departments, there are normally tens of ‘standard applications’ which can be tested easily and quickly but there are often hundreds of small and custom applications lurking in the environment that IT probably don’t have knowledge of. Some of these applications might be considered ‘key’ for only a handful of users but this means that if the application hasn’t been tested and remediated it may break during a user migration and those users generally turn out to be quite senior (and noisy) – which is how they got the application into use in the first place.
Basically, getting a list of applications is the first challenge. Figuring out which ones will and won’t break during a migration can be a never-ending task; it is usually for this reason that a lot of AD migrations never start, and why those that do start rarely finish on time (or ever).
To federate, to trust, or neither?
While none of the challenges above are particularly earth-shattering, they involve a lot of time, planning and resources to resolve, and as a result a lot of organisations choose not to tackle them at all, at least in the short to medium term.
A simple strategy then, is to establish trusts between the AD forests to enable the required level of interoperability without having to wade into the sticky mess of merging into one AD instance. The AD trust will enable interoperability between the different organisations, which will solve some of the high-level business challenges without much technical input or time spent worrying about breaking applications on day one.
The other option for ‘modern’ applications can be to establish Federation between the environments. Where you want to keep segregation or AD trusts aren’t viable (such as no physical networking in place), you can look at using services such as Active Directory Federation Services to establish application level ‘relying party trusts’ if the applications support one of the modern authentication protocols (WS-Fed, SAML, OAuth etc.). Applications such as SharePoint support this and it can be a simple approach to give access to single applications instead of binding the IT environments tightly together with AD trusts.
If the merger driving this activity is a well-known brand acquiring another well-known brand and keeping the disparate brand identities is one of the requirements, then Trusts or Federation can actually be the best way of progressing. There can be some technical challenges to overcome in terms of how to establish trusts or federation, as well as how to enforce standardised IT/user policies across all environment (without 3rd party tools), but again all of these issues are manageable if you throw enough staff at the problem.
However, if the requirements of the organisation are to consolidate the users email addresses into one brand or to save money by sharing applications and business functions (like finance and HR), then this isn’t really the option you want to pursue. In a merger where a strong brand has acquired a lesser known competitor to gain market share rather than any unique selling proposition, part of the rebranding is likely to require changing that entities identity to match the leading brand, which means changing their email addresses. In this instance an AD trust or Federation may be accepted as an interim measure, but consolidation will still need to happen at some point to simplify email and business systems and to make the savings that any merger envisages.
There is a reasonable amount of work involved in federating AD forests, and one of the problems that rolls over with this is the lack of centralised management and consistency of identity. None of the core challenges that exist in standardising identity attributes will be fixed by doing this, so that work still needs to be completed and without a huge cost attached. Assuming the AD forests are still being managed independently, it is likely that these mismatch issues will continue to grow over time. They could even get worse if the IT administration function is combined and admins from XYZ Corp start creating identities in Example Inc’s AD or vice versa and there are minimal controls and checks in place.
From a security standpoint, multiple AD forests widen your footprint and possible attack vectors, so minimising these makes the task of securing and managing security around user identities much more manageable. Also, as you adopt more cloud-based solutions, the cost and complication of enabling services like Single Sign On for users, (the benefits of this are covered in our previous blog: How to stop your users taking you to the data apocalypse – part 1), will increase as you will have to configure each platform independently to support this capability.
If the overriding imperative is to migrate all users into one Active Directory with one organisation-wide email address convention, then the work on standardising identities and removing duplicates is the pre-requisite, but by no means the whole game.
Users AD identities are the driving force behind at least email, but in most modern businesses there will be a further slew of productivity-based applications whose access and licensing are also tied to it. Making sure that the migration doesn’t impact the user’s ability to be productive is critical from a bottom line perspective, but also to ensure that the customers of the service don’t experience any significant disruptions.
In practice, there are a number of ways that user migration can be managed. Depending on the complexity, there are a number of 3rd party tools on the marketplace that can support this activity and provide continuity of services while the migration process is active. Typically, there will be a period of dual running where a user exists in both identity structures, so making sure that the rest of the business can still access Calendar information and the users can still see resource or room availability is critical to a successful migration strategy.
Post-migration, testing and remediation followed by decommissioning of the legacy architecture can be done at the organisation’s leisure, albeit in the world of GDPR there is now more of an imperative to get this done quickly and decisively.
There are a number of compelling events that might be a driver for an organisation to want to consolidate all of their users from multiple AD forests into one single identity platform.
Adoption of any new significant technology could be one of these drivers. Adopting a new service desk solution for the organisation might be one of these, where there are financial or operational challenges thrown up by the requirement to support access to or management of multiple AD instances.
One of the best (or worst, depending on your point of view), examples of this is when organisations want to move into Office 365. Office 365 requires all users to have an Azure AD identity, so if you want to have everyone on a single, secure Office 365 tenancy for maximal operational efficiencies, all of those ID issues caused by the legacy AD forests need to be tackled before you can migrate.
Fast Track Migrations
One other challenge around this, even if you have consistent identity attributes, is the physical process of the migration, especially if you want to use Microsoft’s Fast Track service to complete the migration. Fast Track typically uses Azure Active Directory Connect (AADC) to migrate users from their legacy Active Directory instances into Azure AD. This is a great tool, but it has a number of tolerances that cannot be breached including ID sync times. This can be a significant challenge for organisations with federated Active Directories, particularly where there is a top-level domain with several sub domains below it, the response times can be a blocker to utilising this service. This leaves a number of organisations in a position where the only real option is to pay for 3rd party tooling and support to complete the migration.
There is another way…
Another key area where an Identity and Access Management solution can help organisations is by mitigating some or all of these issues, but it should be noted that this area is where there is a lot of differentiation between the IDAM solutions in the current marketplace.
In most cases, a good Identity and Access Management solution can help organisations with Multiple AD Forests by centralising the management of user identities. Using an IDAM platform to manage the creation of all identities using an agreed set of standard attributes and policies can help an organisation to make sure that, moving forward, all identities are built to a set standard and consistency. The platform should also enable your IT admins to look at legacy identities and make changes to bring them all into alignment in a controlled and consistent way. By centralising the AD management functions, you can start to gain a first round of savings through automation of account creations across all environments, especially if you can hook the IAM solution up to the HR systems (diverse or centralised).
Some IDAM solutions may enable you to make these remedial changes to legacy identities en masse using scripts and policies, which is particularly useful if you have got a lot of users to remediate, helping you to gain a standard set of attributes as the first step towards a full consolidation.
A few solutions may be able to help with the migration of users into a single AD instance and the sync issues that you might encounter if you are looking at a migration into a platform like Office 365.
Aurora, from Core, can tackle all of these issues, and we have an exceptional track record of helping large, complicated organisations in the private and public sector permanently resolve these problems. The Aurora platform can be used by your existing IT admin teams as the tool to enable them to remediate AD issues, using fixed policies to ensure consistency of identities for new users, or remediated ones. If you don’t have the resources to complete this activity in your desired timescales, our experts at Core can step in, complete all of the remediation for you, and support you through the migration process.
In terms of any migrations, Aurora can provide that single management layer, enabling you to see the entire estate of Active Directories and allowing admins to manage a lot of the activities from one portal with a full audit trail of activity. Aurora has also been used by a number of our customers as a way of avoiding the challenges with ID sync times from the source domains, enabling customers to gain that free Microsoft Fast Track user migration through being able to deploy AADC in scenarios that otherwise wouldn’t be supported (mixed multi single domain forests and Exchange resources forest environments for instance).
Our previous blogs on IDAM tackle the challenges and benefits of other activities relating to Identity and Access Management, which combined with how IDAM solutions can support managing complex legacy AD infrastructures, should enable any organisation to build a picture of why a good solution will deliver structural cost savings to your business.
We have a range of models for supporting customers through these challenges, so if you have these issues within your business, please get in touch with us and we can work with you to understand your specific challenges and explore the right options to resolve it.
Identity and Access Management is a key technology for Core, so look out for more blogs on this subject throughout 2018. Other future blogs will look at Core’s involvement with the Crown Commercial Service G-Cloud framework agreement as it comes around to its tenth iteration.