How to Avoid the Complexities of Traditional M&A with Okta
In today’s competitive environment, we often see companies expand their market share via mergers & acquisitions. A clear vision for planning identity and access management during an M&A transaction is critical to ensure success. However, the technical challenges that come with a standard M&A project – things like domain consolidation, identifying group policies and permissions, and assigning applications, all increase the complexity of the project. In this post, we’ll discuss how Okta can ease the technical challenges that come with an M&A project by offering a simple, easy to administer cloud IAM solution that extends across your enterprise.
Say goodbye to forest trusts
In a standard M&A project, one of the first deployment steps you’ll consider is domain consolidation – are you going to create a brand new Active Directory forest, create trusts between existing forests, or migrate users from the acquired organization into an existing Active Directory forest? The problem with domain consolidation is that it’s slow and complex, and often, users don’t get access to applications in a timely fashion. In the simplest of use cases, the parent company will have one domain, and the acquired company will have one domain. However, more frequently, both the parent and acquired company have multiple domains, already adding more complexity to the project. Fortunately, Okta makes domain consolidation easy – just use the Okta Active Directory agent, connect it to your Okta org, and start importing users.
In the video above, notice that within minutes, we were able to connect two separate, untrusted Active Directory environments to the same Okta org, and import users from those directories into Okta. Notice that when we import users, we can auto-confirm the import, or manually import users. When that’s complete, users from both directories are active in Okta, and they can use their existing Active Directory username and password to authenticate into Okta. And, this works with other LDAP v3 directories too, not just Active Directory. Aside from importing these users into Okta, you can also use Okta to push all of these users into a brand new Active Directory environment if necessary.
Simplify user attribute management
Okta’s expression language allows you to reference, transform, and combine attributes before storing those attributes to a user’s profile, or before passing those attributes to an application in Okta. For example, we commonly see use cases in which an end user’s User Principal Name in Active Directory ends with something like ‘@corp.local’, or ‘@region.corp.local.’ However, these types of domain suffixes are not externally routable, and therefore cannot be used as an end user’s email address. This is where Okta simplifies things – rather than making changes to your Active Directory environment, you can use Okta’s expression language to automate the UPN of a user when they are imported to Okta.
In the video above, notice that end users that have a User Principal Name ending in ‘@atkobiz.local’ automatically have their username associated with the ‘@atkobiz.com’ domain, which can then also be used as their email address.
Day One Application Assignment
A traditional M&A project involves much more than just domain consolidation. Administrators also need to think about how users will retain access to their applications during the M&A project. Using Okta, administrators can easily assign users to applications based on the existing groups they have in Active Directory. This avoids the prolonged process of having to reassign users to new OUs and Security Groups before they get access to applications.
In the video above, we have users from both the AtkoDemo forest and the AtkoBiz forest – we can assign users from groups in each of these forests to applications like Salesforce or Office 365 easily, without having to create new groups in Okta.
And what about when users need access to an application that has not yet been assigned to them?
In the video above, the end user request access to a new application – Dropbox. An application admin in Okta will then receive that notification, so that the end user can access Dropbox from their dashboard.
Secure, Seamless Access
Now that your Okta admins can administer objects in the Okta org and end users can access applications, you need to determine how to secure access for both admins and end users. In any standard M&A, the parent company and the acquired company very likely have different security requirements and security products. One example is multi-factor authentication. The parent company might use Yubico as their MFA solution, while the acquired company does not yet have a multifactor authentication solution. Using Okta, customers can choose from a variety of multifactor authentication solutions, and assign policies as appropriate in Okta. We can also enable application level sign on policies, which allow you to secure access to your more sensitive corporate applications.
As an end user, you’ll see an MFA prompt when logging into Okta. If you have not yet enrolled into Okta’s multifactor authentication, you will be prompted to do so on the next login.
Notice that an admin can easily enable a variety of multifactor authentication factors and policies – each one of these factors can be applied to a separate set of administrators or end users.
And security policies for administrators that need to access Okta?
Notice that we have a variety of built-in administrative roles that can be assigned to designated Okta administrators.
Visibility into your organization
Once your Okta org has been up and running for some time, you’ll need to determine which applications your end users are using, and who has access to those apps. In case of an application audit, Okta can help to determine application access via built-in reporting capabilities. Okta’s syslog gives you insight into login activity across the organization. And, the Syslog capabilities can be extended to work with 3rd party SIEM and analytics tools.
Notice the Application Usage and Application Audit reports. The Rogue Accounts report is helpful to locate accounts which were created directly in an application without being assigned the application in Okta.
As you can see, Okta for M&A is a significantly more streamlined solution than what we see in a traditional M&A project. Usually, an M&A project will involve AD domain consolidations, migrations, and creating new forests worked well in the past, but IT now requires a more efficient method to complete and M&A project. We ultimately want to ensure a great end user experience, and that is where a cloud IAM solution like Okta comes into the picture. With Okta, you can choose to keep the directory investments you already have, or, choose to use Okta UD as your source of truth.
To find out how Okta has helped organizations like Broadcom through M&A, download this white paper. To get started with Okta, choose your free trial here.
