replace microsoft AD with RHEL version
Helo,
I'm in the process of creating a small environment and we need to use AD but, I'm trying my best to prevent from using Microsoft due to the license cost. I want to be able to a RHEL version of this but, I do not know where to start? Can someone point me in the right direction? Can I replace AD infrastructure completely with RHEL ?
Responses
Jonathan,
I am intrigued to know how much you plan on saving with licensing costs. How many sockets is the hardware you are installing the server on? Is it physical/virtual?
In answer to your question, you can replace AD infrastructure completely with RHEL. Which version on RHEL do you plan on using 6/7?
Jonathan,
It is pretty vague...
What requirements from the AD server do you want to replicate?
Do you have Exchange?
Do you have Windows workstations that need to authenticate?
Do you need group policy capabilities?
Do you need to provide Directory Services / DNS?
Are you using file sharing in the network?
Depending on how many of the above components are required, I don't see the license cost of Windows (considering price of Server 2012R2 Essentials) being a major reason to avoid looking at it as an option.
If you are a complete RHEL/Linux environment and only want features such as DNS/Directory services then I think RHEL would be the perfect fit.
I would need to better understand the goal or the objective. And what I mean is: what are you trying to do actually do? What services are you trying to provide? RHEL is very capable, but in my opinion it cannot simply replace AD (or not easily anyhow). Which is why I am curious which features/functions of AD are you hoping to provide (or emulate) using RHEL?
I probably could have worded my question/response a bit differently.
Emulating portions of AD on Linux are fairly easy, and other parts - not so much. Using AD for it's intended purpose and only where you need it, then augmenting the other services with RHEL is a great strategy. We are just trying to help you avoid some of the lessons we learned by trying the same thing ;-)
Agreed. IdM is likely a good direction to go.
If I was to build out a new environment with the goals jonahan has mentioned (thus far), I would look at deploying a minimal AD infrastructure and then use IdM to integrate my Linux environment.
https://access.redhat.com/products/Identity_Management
Jonathan - I also should mention that this would probably be a good discussion to have with your Red Hat account reps. I know that the technical rep on my account LOVES having these types of conversations to help determine what our goals are and which products are a good fit. Another helpful aspect is hearing about the roadmap and what direction the products are going.
James,
Perhaps you can help me answer my niggling IdM question.
What are the major selling points for adding IdM into the mix in an existing AD environment?
ie. why configure
RHEL Server -> RHEL IdM -> MS AD
over
RHEL Server -> MS AD
What additional benefits does the IdM server provide considering the amount of integration provided by SSSD with MS AD? I understand it provides a shim which adds a level of control in the upgrade process (ie. if Windows upgrade breaks, only single point of interaction to fix), but are the benefits worth the additional 'moving part' in the configuration?
Are people using it for privilege separation in an environment where the Windows/Linux admins don't get along? or Linux admins aren't given access to MS AD?
Is there a major selling point I am missing? :)
Anyone else have feedback on their reasons for going the IdM route?
I think the IdM was more relevant a few years ago (when Winbind and Kerberos, etc.. seemed a lot more difficult) and AD was not extensible nor Linux-aware (i.e. GECOS not being "a thing" in AD and to bring any awareness required those add-ons to AD). Also prior to Puppet and the like become as mainstream now.
However, I think some of the benefits:
* you can use AD for basic user management (password, etc..) but IdM then adds functionality like defining the home dir, netgroups, sudoers, etc... (again you can do most of that with Puppet, etc..)
* caching of credentials and environment segregation - You can limit the tree/forest exposure. You can also reduce the load/dependency on AD - although.. I imagine you'd have to REALLY be hammering on an AD system to tax it.
* DNS integration - this item can be both a benefit and a hindrance, I suppose.
* I believe auditing/logging becomes more straight-forward as you can now query IdM for information, rather than whatever AD might provide.
* as for privilege separation that you mentioned, I'm sure that topic is fairly common. But I look at it a different way that Linux has to manage the user/groups/etc... much differently than AD - and then trying to manage Linux file perms from Windows... HA! ;-)
So, from my perspective, if I have a dependency on AD in any capacity and I have to manage some type of "passthru" mechanism (be it simple LDAP-passthru or something like IdM) I figure I would use IdM and extend the capability of what it provides as a centralized management solution.
There are certainly drawbacks with IdM (depending on your environment), I believe it still requires the AD "plugin" to distribute information when needed (who knows what happens to that plugin/shim when you update Windows?) And from what I have seen you need a separate DNS domain (or you need to point Windows servers to the AD directory and the Linux servers to the IdM directory) which is necessary when the host does the SRV lookup for the domain for the _ldap hosts.
All that said - I am far from proficient with IdM - so, you're better off asking someone else ;-) But, freeIPA is a vibrant project
Thanks for that James,
The first two points are solved with the Microsoft AD IMU plugin. This gives you an additional 'Unix Attributes' tab for user and group objects in Active Directory which lets you configure UID/GID/Home Directory/Shell all from within the Active Directory interface. If you are using these attributes from AD (ie. not generating them) it also limits the objects presented on the Linux servers (ie. users without posix attributes aren't shown/exposed on the Linux servers). In saying that, I have been in environments where administrators are reluctant to install the plugin (even though it's provided by Microsoft!).
As for DNS integration, can you provide more detail? Does the IdM DNS server forward to the AD server? or does it replicate the AD DNS zones? In this configuration, how do Windows servers pointing at AD for DNS receive DNS information for Linux hosts if they are only registered on the Linux IdM DNS?
Thanks again.
I don't like having sssd authenticate from our AD forest directly, because as far as I'm aware, the added attributes don't do nearly enough for authentication control; with IdM I can allow specific groups/users to authenticate to individual hosts or groups easily. Now I know there are ways to accomplish this with some LDAP-fu with the way sssd authenticates, but the combination of IdM and sssd make it very straightforward.
You can also set up your IdM cluster as an AD trust (and vice versa) to allow authentication via IdM from your AD forest.
As for DNS: It's actually inverse from that when you set it up, you can set your MS DNS as forwarders, so that bind on your IdM servers act as replicators for your existing DNS servers.
Stephen,
Interested to know what you are using the authentication restriction for. With direct AD this can be achieved by configuring group membership requirements on the host in the SSSD configuration (sssd.conf) and managing user memberships to groups (or roles in RBAC configuration) as you would in normal AD (from the same single interface).
ie. You must be a member of group X to login to the production Linux servers. You must be a member of group Y to sudo on the production Linux servers.
Is this what you are referring to?
Sort of. IdM takes care of that on the back end; you do not have to edit the sssd.conf file (and then restart sssd) if things change as far as say, allowable groups to login change.
In your setup, if sssd is configured to allow members of "linux-users" group to log in and "linux-admins" to sudo, then if it changes to "unix-users" and "unix-admins", you'd have to restart sssd; with IdM you simply configure the changes on the IdM cluster, and there's no touch to a client machine.
You do not need any plugins any more. Please check the trust based setup. It is available starting FreeIPA 3.3. The new version coming in RHEL7.1 is even more powerful. Check my blogs too.
http://rhelblog.redhat.com/2015/01/22/closing-the-integration-gap/
http://rhelblog.redhat.com/2015/02/19/overview-of-indirect-active-directory-integration-using-identity-management-idm/
More trust related info:
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
"You do not need any plugins any more."
If you are referring to the plugin to sync between IdM and AD, this is definitely good news for IdM implementations.
I notice both integration methods are mentioned in the linked article:
"The above listed benefits are significant in cases where a company deploying a solution has a dedicated Linux management group. This is usually the case with big enterprises. In smaller environments, where there may be no such group, running a separate server might be overhead so starting with direct integration using SSSD or even employing a third party solution (if advanced functionality is a requirement), is definitely an option."
In this context, what does Red Hat classify as a 'big enterprise'? ie. at what scale would Red Hat recommend IdM over direct?
It is really customer specific but roughly somewhere between 30-50 systems you will start to rationalize the value and the cost savings of the central solution like IdM.
Unfortunately I feel it the hang-ups I have experienced were not necessarily 100% "technology-based" and were more "gut-feel" (i.e. "we are not going to run some Linux plugin on our Domain Controllers") - and, in fairness, I recall some of the responses when folks heard that Microsoft was contributing to the Linux kernel ;-)
Thanks for this update!!
To answer the original question the vision is: you use IdM for Linux environment and if you needed to manage some Windows machines we are working on making Samba 4 a viable option for this setup. There are two parts that are missing: Samba 4 needs to be compiled with MIT Kerberos because this is the preferred Kerberos implementation we use and Samba 4 needs to support trusts with FreeIPA. We are working on both.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
