Directory Server as drop-in replacement for AD

Latest response

Would be nice to see Red Hat Directory Server as a drop-in replacement for Active Directory.  There are several challenges to overcome in this respect, but there are now very many organisations that have consolidated on a single authentication method - Active Directory.  Historically it has been several steps ahead of RHDS and other LDAP implementations.


The challenge is to improve these areas enough and implement the required functionallity to provide RHDS as a drop-in replacement.  Removing AD from organisations would be a huge publicity boost for Red Hat.  Windows desktops would remain, but be oblivious to their new master.


Samba and RHDS has been used for a while as a replacement for some Active Directory environments.

Here's a link to a solid (but older) paper:

Are there specific features you are looking for that are not currently being provided?

I'm not the AD admin so I can't answer.  I'm not actively trying to replace AD installations with RHDS either, but I've been asked if it's possible in the past.


What customers seem to be looking for is a straight drop-in replacement for AD.  Not something that manages a *similar* job after a good deal of tweaking at both ends.  Not something that needs various tools installed on Windows clients in order to connect.  But something that could be installed directly on top of the AD servers and (with the appropriate database export/import) nobody would notice the difference.  All printers would work, all shares would work, all authentication would work.  And everything would work in exactly the same way as before.


This may not be here just yet, but more questions seem to be getting asked more these days in the enterprise.

Honest question, how much AD have you done?  It has many pain points and limitations.

With FreeIPA being integrated to RHEL 6.2 (beta so far), there is another option.  There is an intersection of functionallity between FreeIPA and RHDS, but each has it's own specialist areas.


Would it be an option to grow RHDS to include the extra functionallity of FreeIPA.  This would mean RHDS becoming a super-set of FreeIPA.  Ideally, that set would include enough functionallity to allow full trust relationships between Active Directory and RHDS.  Even to the point of being able to remove AD servers completely?

This comment is dated, so I am now removing it.

Unfortunately arguing that product X is technically better than product Y is a moot point in this case.  I am in agreement that AD is not the best product in the field.


The overwhelming majority of corporate voters, however, have already voted AD.  It's no longer a question of whether AD was a good enough product.  I'm not asking for RHDS to be limited to reproducing exactly AD's functionallity.


Aiming to replace AD with something that doesn't do what AD does is just not going to cut it in the vast majority of cases.  In my view, the first step has to be to embrace AD and then extend.  Sound familiar?  It's a method which has been shown to work - very well as it happens.


Coming up with something that is different (albeit a technically superior alternative) and trying to argue the technical case, is like banging your head off a brick wall.






Duncan --


Just because AD is in a corporation doesn't mean iPlanet/RHDS/389 is not also in it.  In fact, many corporations still use "regular LDAP" to solve the real, integration issues with AD.


E.g., as I said prior, if AD schema doesn't match between forests, then you have to use something like Microsoft LDS.  Most enterprises would rather just run a full LDAP.


Furthermore, AD does not handle UNIX/Linux well at all.  At the most it provides legacy NIS with psuedo-RFC2307 compatible stores in AD.  To do more, you have to either do all sorts of manual operations (e.g., keytab files), or purchase third party solutions.


So understand where 389/RHDS comes from, and what it's trying to solve.  It's trying to solve LDAP needs that pre-date AD's creation, and corporate adoption of AOL-Netscape iPlanet solutions prior.


And also understand why there are separate, open source projects in Samba4 and IPA (aka Enterprise Identity Mangement).  Samba4 is the AD replacement.  IPA is the "canned" UNIX/Linux counter-part.  IPAv3 is adding extensive AD interoperability via Samba4.


However, there is no "single product" that solves the problem for corporations.  AD cannot manage UNIX/Linux well at all, only Windows.  In fact, most Windows architects and engineers don't even design AD correctly for Windows networks, much less are dumbfounded with UNIX/Linux clients.


Your entire view is based on the fact that AD manages non-Windows.  It was never designed to, and the few things it does are entirely inadequate (even many 3rd party applications do little more than what SSSD does now in Fedora/EL).  If you had exposure to trying to manage UNIX/Linux with AD, especially without any 3rd party add-ons, you would know this.


-- Bryan, MCSE/MCITP (2000-2008)


P.S.  There is nothing more frustrating than when I'm trying to explain to "Windows architects" that I need them to at least populate the RFC2307 fields so I have UNIX/Linux attributes.  In most cases they don't understand why their SIDs/ACEs and other things "don't just work with Samba."  Most are _poor_ Windows architects that I have to solve their AD design issues for.