What's different between IdM (Identity Manager) bundled with RHEL and Directory Server?
There's a monster piece of software now called IdM - or IPA - that does identity management. It's part of RHEL and there are docs describing what it does and how to install and set it up.
Great.
But there's also a separate subscription product called Directory Server. What's different? Directory Server costs a bunch of money every year, so it must offer a bunch more than IPA. So what does one have that the other doesn't have?
And then I saw some stuff at the April 2014 Summit suggesting that IPA with RHEL7 offers a whole bunch more than IPA with RHEL6. Looking over the docs - there's a whole book about Windows integration with IPA/RHEL7, while Windows integration is just a section of the RHEL6 IPA Guide. Does anyone have any info?
thanks
- Greg
Responses
I'm looking for the same answers. We pay all this money for Directory Services and Certificate Authority and IdM appears to cover both within the Enterprise Server Subscription. I've installed and configured IdM on a test domain and it appears to be working great. Also, the IdM services running on this server are: dirsrv [domian name], dirsrv PKI-IPA, Directory Services, KDC, DNS, CA Service, named, pki-ca. These are the same as the paid for Directory Services and Certificate Authority. Is there something lacking in IdM? The one thing I wish I could use with the IdM server is the redhat-idm-console that is used for Directory Services.
Thanks,
Will
Guru
2366 points
It's either compatibility with legacy Sun/iPlanet environments (big selling point for us, since we can replicate directly from our legacy environment to 389/RHDS,thus avoiding a massive enterprise-wide downtime for a bulk export/import (or delta re-sync)), or possibly scalability. I have no idea what scalability IPA advertises/supports, but we need LDAP servers that can reliably handle millions of queries per hour, with OUs that have 100's of thousands of objects; the RHDS code has been doing that since at least a decade before Red Hat bought it. IPA is an unknown (for us, at least).
OpenLDAP is an epic fail at the scale, reliability, and compatibility that we need; I honestly have no idea how IPA compares (but I'd love to hear from someone at Red Hat who knows more about IPA!)
After working with Red Hat Support to get IdM working correctly in my environment, I can tell you that one major difference between IdM and Directory Services is that the latter seems to actually work.
I've worked with support since mid-November of 2014 to deal with issues ranging from slow logins, crashing services, CPU spikes, failure to authenticate, failed replication and failed sudo control. So far, it hasn't seemed like any part of my IdM installation has been reliable.
Another difference I found is that IdM does not seem to do multi-master replication (or at least I haven't been able to find anything on it). RH Directory Services CAN do multi-master replication and I have not had ANY of the issues that I have been fighting with IdM on. I'm just about to roll back to RDS and get rid of IdM all togeter....good riddance, as far as I'm concerned.
Guru
6710 points
Dan,
Can you provide some details regarding your IdM installation? What version of IdM, which base OS? (RHEL7?) integration into AD? (which version?)
Not to try and troubleshoot, just interested in the combination you are using.
PixelDrift,
We've tried it on both RHEL6 and RHEL7. We were not tying it into AD and we were not using any of the DNS or NTP functionality. It's only job was going to be authentication and sudo management. Our environment was relatively small (maybe 30 users and no more than 50 servers).
Our first install was on RHEL6 with one master, and 3 replicas. We have 2 datacenters, so we had a master and a replica at one location and two replicas at the other location. Almost immediately, replication started failing first on one replica then on all replicas. Then, I couldn't get signed in to the Web UI and by the end of it the entire environment had completely crashed.
We rebuilt everything from the ground up on RHE7. No more issues with replication, but some systems would not authenticate, others would take a long time for authentication. Still other issues included failing to be able to use sudo. All of these issue were inconsistent. Some RHEL5 authenticated, but couldn't use sudo over LDAP. Some RHEL6 boxes couldn't authenticate at all. Others would hang during login for up to a full minute.
Then, after a month or so, the dirsrv service kept crashing and needed to be restarted. Since it never would generate a core, we couldn't delve further into what was wrong.
I've had a case with RH support open since 11/19 and I'm finally being forced to go back to Directory Services (which, for an implementation this small is WAY expensive...which was why we were trying IdM to begin with) because the environment was just never able to run reliably. I've heard that other places don't have these issues, but I don't know what they're doing differently. It seems to me, this was a pretty basic implementation, but it just wasn't reliable.
I am sorry to hear that you had a negative experience with IdM. IdM is not perfect though it is quite stable. Keep in mind that a lot of functionality and capabilities is added every release because these features are in high demand. Despite your experience we have a steadily growing number of deployments both as Red Hat customers and in the community. The best way to get a feel of IdM and underlaying technology FreeIPA from the first hand users is to ask a question on freeipa-users@redhat.com list.
IdM has multimaster replication based on the underlaying DS. It is quite well documented. It is a concern that you could not find it.
Now to the core of the differences between IdM and DS.
The core difference is the use case. IdM is a domain controller similar to AD but for Linux/UNIX. It is best for the internal identity namespace. DS is more for the external namespaces as an identity back end that would be used by your business applications. If you are developing an application that would be used by your customers, partners and other consumers then DS is better as it allows more flexibility and customization. IdM is also customizable but it has a set of rules one needs to follow since it is a domain controller and thus serves a specific purpose.
There are other differences but this one is the main.
I've seen references to multi-master replication, but every time I follow a link for it, it mentions multi-master and then describes just regular replica creation. I know that, unlike DS, the replicas are not read-only, which is a plus. But while I saw many references to multi-master replication, nothing actually showed how to do it because they all just referenced running ipa-replica-prepare, which does not create another master.
It does create another master. Why do you think it does not?
It cannot exist independently of the master and is created by the master using 'ipa-replica-prepare.'
I had wanted, in my above described environment, to have one master and one replica at each or our data center locations with a single over-the-wan replication agreement between two master IPA servers. This was not possible as ALL replicas needed to have replication agreements with the one master and replicas could only be created by the one master.
To me, that does not describe multi-master replication. I would describe this as single-master with read-write replicas.
You can create a replica using ipa-replica-prepare on any server. The only thing to keep in mind is the CA. The first server usually has the CA. If you create a replica that does not have CA and then use it to create another replica you would not be able to create that second replica with a CA.
You can also add and remove replication agreements with ipa-replica-manage and create the topology you need.
So for the setup you described you could have done it in a couple different ways:
a) Create first server in datacanter A
b) Create second server using ipa-replica-prepare on the first server + ipa-replica-install in datacanter A
c) Create first server using ipa-replica-prepare on the first server + ipa-replica-install in datacanter B
d) Create second server in B using ipa-replica-prepare on the first server in A + ipa-replica-install in datacanter B and then adjust replication agreements using ipa-replica-manage
--or--
d) Create second server in B using ipa-replica-prepare on the first server in the datacenter B + ipa-replica-install in datacanter B
Sorry, Greg....Not trying to hijack your thread. :-P Hopefully, the discussion is useful to you, though.
Yes unfortunately there is a general theme of not understanding why 2-way trust is not a problem. In a nutshell 2-way trust gives you cross authentication but it does not give you any authorization so any authenticated user from a trusted domain would not be able to access any resource due to lack of authorization until you explicitly give him such authorization.
I am not sure what problems you refer to. The replication is there and I explained how to accomplish what Dan wanted. It seems that when Dan tried there was some sort of mismatch between Dan's assumptions and how things are. May be we documented something in not that obvious way but it is hard to deduce from this conversation what we should do differently.
As for the problems. You can can look at freeipa-users list. People come to this list with questions and issues every day. Does that mean the project and product is not stable. I suggest you ask on the list as I am definitely biased and have a particular answer in my mind.
IdM consists of: DS, KDC, CA, DNS.
DNS is optional
CA is optional starting 7.0
DS and KDC are same on all replicas.
There are no roles in IdM yet (sort of, see below). Functionality is defined by the components you deployed. If you deployed DNS then you have it on that replica but not on the other. You can add or remove DNS part at any moment on any instance. The CA is much less flexible. If you deploy without CA you can;t have a CA anywhere. If you deployed the first instance with a CA then you can have CAs in some other replicas and not others based on your needs. There are corresponding commands to deal with CS topology.
The only thing that is not the same between the servers is:
- CRL generation; only one server by default the first one is responsible for CRL generation but there is a documented procedure to move it to some other instance.
- Certificate tracking and renewal; the tracking of the internal CA certificates happens on the first instance that you installed. There is a procedure and starting 7.1 some tools and more formal recommendations on how to move this responsibility around.
Other than that nodes are completely same functionality-wise.
Greg,
I do like the feature set the IdM has to offer, so I'm probably going to revisit this in the future. I'm not entirely sure what it might have been that was different about my environment than all the others. In any event, maybe later this year I can give it another try....though I'll be doing a great deal more testing before I jump on board the IPA train.
The best parts about it (for us, anyway) was how it managed sudo access and allowed for grouping hosts together. It's nice how you can get granular control over who can access which host(s) with which protocol(s).
In our case, we did no ties with AD or any other integration. It was just being used for authentication and sudo management. As I understand it, there are some updates to IdM coming in RHEL7.1 which I expect will be out any day now.
We'll see what happens and if I can get things running properly in the future, I'm happy to recant of my current dissatisfaction.
The difference in the products is detailed pretty clearly 'here': https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#comparing
(which starts with): "The closest relative to Identity Management is a standard LDAP directory like Red Hat Directory Server. However, they have a different purpose. The primary feature of an LDAP directory is its generality; it can be made to fit into a variety of applications. Identity Management, on the other hand, has a very specific purpose and fits a very specific application: it is not a general LDAP directory, it is not a back end, and it is not a general policy server. "
The version differences regarding AD integration can be seen on the Free IPA website, where they detail the functionality difference per version...
I have implemented a '7 server node multi master' IDM cluster (RHEL 6.7 using IDM's Free-IPA version 3.0.0) with 300+ 'client' systems. So far it has been functioning flawlessly for 9 months, with all 'human' account entries being removed from the 'local' passwd files such that all 'human' user authentication is performed 'centrally'.
You must be aware of the 'caveats' regarding what can be done/configured, as well as the 'fixes' needed to implement the product correctly (things the vendor will not mention, or always agree with). Any functionality you want to retain (i.e. NIS 'netgroups') may take some research and additional steps on your own part.
Once you figure out how IDM 'works', and have a plan on migrating your data, its ongoing usage is quite simple. I basically used a script to parse and load all of the unique "passwd" entries using the "ipa user*" CLI commands (300 user entries in 17 minutes).
Doing your homework to plan how you would implement/configure it is very important, including the 'grouping' of users and 'hosts', and 'glueing' them together (for login access) using the HBAC 'rules'. The 'feature' of 'groups' belonging to 'other groups' allow you to define 'master user groups' which define all of the abilities of the users you add to them (the 'master' group is referenced in the HBAC rule, and belongs to all the 'local' file/directory access groups required). Such that, removing a user from a 'master group', and adding them to a different one, changes their entire system access profile (and if your 'sudoers' configuration references the 'master' group, it changes their 'sudo' abilities as well).
The same process is performed for hosts, which if placed in specific 'host groups' (which are referenced in the same corresponding HBAC rule(s) as the user groups) again changes the login access abilities. If you have trouble realizing what affect this has, consider the process of 'terminating' a user, or decommissioning a system, which now just requires the removal of any 'group memberships' for the user/host, and the Web GUI or "ipa" CLI command to 'disable' the user account or 'unprovision' the host.
Its a great replacement for NIS implementations, and has many advantages over a 'bland' OpenLDAP configuration. BUT, you must know the product on your own, since there is no level of vendor support that will fully help you.
Guru
6827 points
This was pretty well discussed, but also see this link http://rhelblog.redhat.com/2015/06/01/identity-management-or-red-hat-directory-server-which-one-should-i-use/