As predicted in one of my earlier posts, more and more customers are starting to seriously evaluate and move off of third party Active Directory integration solutions. They want to use or at least consider leveraging identity management technologies available in Red Hat Enterprise Linux.
In the calls and face to face meetings as well as during customer presentations at Red Hat Customer Convergence events, Red Hat Summit, Defence in Depth and other conferences I get a lot of questions about such migration. As it is becoming a common theme, I decided to consolidate some of the thoughts, ideas, and best practices on the matter in a single blog post.
Why do organizations consider migration?
There are several crucial factors that lead people to the path of migration. They fall into the following categories:
One of main technical reasons customers start to consider a different solution is because the solution they use stops to meet their technical needs. This usually happens when customers outgrow the solution they use. Inadvertently they start to push the technical limits of their deployment. The stress reveals architectural limitations as well as puts extra pressure on other aspects of the deployment like performance, scalability and manageability.
In general this is a natural progression when more modern solutions take into the account limitations and pitfalls of the earlier attempts and make things temporarily better until they are in turn replaced by the next generation of technologies.
Every customer’s identity management landscape is unique. However, we see some patterns again and again.
In some cases the whole identity management space is significantly controlled and influenced by the Active Directory side of the house. In other cases there is a clear organizational divide between Active Directory folks and the Linux team. One of the main attractions of the identity management technologies in Red Hat Enterprise Linux is the ability to provide a clear separation of responsibilities between the two parts of the organization.
This works really well in the cases where there are two teams, but it does not 100% resonate with Active Directory centric deployments where one team mostly from Windows side drives the whole deployment. I talked about this in some of my earlier blogs. Here I would just mention that migration from a third party solution is a good time to consider how you structure the organization to enable growth of your business for the next decade.
Identity Management technologies are included with Red Hat Enterprise Linux and are covered by the platform subscription. There is no extra cost.
Third party solutions are priced per client. If you have ten thousand clients and each costs at least $50 per year you have a half million cost right there. This money can be better spent elsewhere, for example on building a better support of the line of business requirements and moving to a more agile (develop-deploy) IT model.
In many cases, business drives the need for a change. Current infrastructure just does not scale enough to meet the needs of the modern enterprise. If every payload you create in cloud requires a separate entitlement from a third party, it is quite cumbersome.
How long would you be able to deal with such arrangement before your IT processes reach the limits and start to fall behind the needs of the ever evolving business models? Keeping your environment lean and removing any obstacles would allow it to keep up with the challenging requirements of today and pave the way into tomorrow.
So the move is imminent but slow. Identity management is part of the core fabric that can’t be disrupted without a major impact on the whole organization. It must be made taking a lot of precautions and factoring in all sorts of different considerations. It needs to be a well planned move. It might be that you are not yet ready, but it might very well be that we are not ready yet for you with the solutions we offer. Well, let us work together to make sure what we offer would better suit your needs. Comments and suggestions are always welcome!
What options do I have?
Red Hat Enterprise Linux offers two main types of Active directory integration: direct where Linux systems are directly connected to Active Directory and indirect when we recommend deploying an Identity Management server as a gateway between your Active Directory and Linux/UNIX environments. These solutions are well covered in other blogs in this series. Here it is important to mention that indirect solution is the one that we recommend for migration from the third party solutions. The reason is that it much better addresses technical, organizational, economic and business drivers described above. But as I mentioned, it does not fit all and direct integration is still a good option for some of the situations.
How would I get there?
Let’s take a look at strategies to migrate from third party to Red Hat Enterprise Linux’s Identity Management (IdM).
Getting from a third party solution to a direct integration solution
The main component of Linux that provides direct integration is System Security Services Daemon (SSSD). The strategy would be to start deploying SSSD for your new payloads and cycling away your old payloads that leverage third party solution over time.
SSSD has a lot of capabilities but there are several challenges that you might face in this migration. If you only manage authentication, access control, and identity information — and your POSIX data is in Active Directory — SSSD will be a sufficient option.
However if you also manage sudo or SSH, or need to have sophisticated mapping of the POSIX identities for different subsets of clients, the direct integration solution is not sufficient. Also Red Hat, as well as Microsoft, does not provide means to manage POSIX data in Active Directory using Microsoft Management Console (MMC).
There is a web interface in Active Directory where after manual configuration POSIX attributes can be exposed, but it is unclear whether this would meet your management workflows and requirements. Bottom line is that direct integration is not a one-to-one replacement of what you have with the third party solution. This is why an indirect integration using Identity Management in Red Hat Enterprise Linux server is better and is a recommended option.
Getting from a third party solution to an indirect integration solution
In this case we are talking about deploying IdM in Red Hat Enterprise Linux as a replacement of your third party solution. It is an architectural change. There are several important differences that come with this change.
- Identity Management server is a domain controller for Linux/UNIX environments. It is a combination of Kerberos, LDAP, PKI and DNS components some of which are optional (PKI, DNS). The solution assumes that you transition your Linux infrastructure into this domain and connect this Linux domain to the Active Directory via a cross-forest trust. With the trust in place users from Active Directory would be able to access resources and systems managed in Linux domain but all the policies for such users will be managed in IdM. POSIX data can come from Active Directory but it can also be overridden in IdM via a feature called ID Views.
- With the introduction of the domains, the challenges related to DNS names come into play. This has been discussed in details on one of my earlier blogs.
- Another important difference is that with the introduction of domains and trusts you would need to start using fully qualified domain names for users meaning that instead of user “foo” you will have to type “email@example.com”. In some cases this is quite a challenge. It is a known hassle and there are some ideas how this can be addressed so hopefully you will see some improvements in this area down the road.
With the variety of vendors you might migrate from, variety of features that you would want to implement, and different constraints you have in the current environment it is so far very hard to determine any specific patterns and provide effective tools to help with migration.
If you want to perform migration yourself the following outline would help you with your effort:
- Understand current environment, including architecture, and paying attention to numbers of users and systems. Note operating systems and versions. See how they are distributed around different datacenters. Record workflows that your users follow when they interact with your Linux systems as well as resources and applications running on them.
- Formulate your goals, and make sure you clearly understand the reasons why you want to migrate. I hope that some information in this article will be helpful. Spell out the criteria which a final solution must satisfy. Make sure to factor in your growth. Projects take time and requirements change. You want to avoid getting into the situation when by the time you finish the migration your architecture does not scale to the needs of the business.
- Become familiar with a solution you consider to migrate to. If you are interested in a Red Hat solution please contact your Technical Account Manager or sales representative. If you do not have either, open a support case with Red Hat support requesting some consulting about Red Hat IdM solution. If you are not a Red Hat customer yet, you might start by dropping a comment here or sending an email to a community mailing list firstname.lastname@example.org. IdM is based in the FreeIPA community project so resources available on the FreeIPA web site might be of a value for you. Finally, there are a lot of shows and conferences where this technology is presented and promoted. You might want to consider attending one of those and get your questions answered first hand.
- Once you know where you are, where you want to be and you are familiar with the offering you can make a decision whether the solution Red Hat offers would meet your short and long term needs. If it does the next step will be to build the architecture using the solution.
- Defining architecture includes but not limited to understanding your DNS setup, firewalls, layout of data centers and mapping of servers to those datacenters as well defining replication topology and which components should be running on which servers. This requires a lot of knowledge and understanding of the details of the solution. The best way to gain this knowledge is to run a POC deployment in your lab mimicking a real world environment as much as possible. Once you are comfortable with it you will be able to draft an implementation plan.
- Implementation plan would be a set of step by step actions that would move you from where you are to where you want to be. The important part of such plan is that each action should be concise and atomic. That would reduce the amount of disruption to your current environment that needs to continue function while you are preparing for the switch.
As you can see, migration is not a walk in the park. It is complex and hard. It requires a good coordination of internal teams and deep knowledge of the tools. In some cases it is hard to do it on your own. In these situations Red Hat can help. Again, talk to your TAM or sales representative about how Red Hat can help in your effort.
Such migration projects render tools and scripts that would benefit others. If you are interested in sharing your work and getting some of the tools and ideas benefit others, you can contribute them to the common repository.
The best way to start contributing would be to get engaged on email@example.com list and people there will help you with the next steps. By sharing your solutions you not only help others, but also help the FreeIPA project to better understand your challenges and for Red Hat to work with FreeIPA developer community to provide a better set of tools that would improve manageability and thus make your life easier.
Let us work together and make this migration path as smooth as possible.