A Forum reader recently asked:
"Can a anyone tell me how eDirectory is better than RDBMS and Active Directory?"
And here are the responses from Aaron Burgemeister, Jim Henderson, and Edward van der Maas ...
It's better than MAD; check the online information. It's scalable, cross-platform, with full LDAP v3 support, and proven for fifteen years now.
eDirectory was shown years ago to scale to one billion objects, which I have never heard even approached by other directory implementations. Partitioning/replication
is simple and implemented by default with eDirectory, while others usually involve a fair bit of hacking and using little-known features just to get it to work. MAD does replication, but it replicates the entire domain everywhere, which isn't very efficient.
A directory is neither "better" nor "worse" than any database. eDirectory has an RDBMS (FLAIM - FLexible Adaptable Information Management database engine ) built into it. But at the lowest levels, it is
a directory and behaves like one (FLAIM is for
performance boosts, as I recall). Directories are meant for certain tasks while databases are meant for others. Directories rarely go over a few million "objects" while a table of a few million rows in a database isn't even pushing a small implementation that hard. Databases
are good at certain things and stink at others, and directories are the same. It depends on your needs.
To add to Aaron's response with regards to FLAIM - FLAIM is not like a traditional RDBMS; structure-wise, it's more like XML than what you'd expect to find in a traditional RDBMS. It uses a hierarchical tagged structure.
FLAIM itself is now released under the GPL and is available from forge.novell.com. It was originally developed to represent hierarchical data on a massive scale - the story is that it was initially developed and used for genealogical research and data storage.
From a design standpoint, FLAIM is designed specifically to store the types of data stored in a directory service; it is relational, using referential information to maintain integrity in the data store. So, for
example, when you add a user to a group, the user is not referenced by a string value (which could change), but rather by an object ID, so changes to the referenced object do not disrupt the relationship between the two
eDirectory uses FLAIM as the back-end data store, and adds to it a caching mechanism that provides outstanding performance in most applications of the service. This provides scalability into at least hundreds of millions of objects. It has a flexible and extensible object
class and attribute schema, and it can store virtually any type of data. (However, not all data types are appropriate to be stored - rapidly/frequently changing data, for example, is a bad type of data to put into any directory).
I can speak to Active Directory because I have history in working with it as well (last experience was with the version that came with Server 2000, so this might be a little outdated). Active Directory uses a traditional
RDBMS on the backend, similar to Microsoft Exchange's (at the time I worked with it, it was the same engine, but now it may have changed - though I don't believe it has). AD was an evolutionary development of the Exchange user data store, so I've been told.
The AD I worked with was significantly slower than the comparable eDirectory versions available at the time - mass change of object rights used to be a problem (though I understand that has been addressed), and in the initial releases, there were problems with data integrity getting
messed up, particularly with multi-valued attributes. Those issues, I'm told, have been addressed.
One of the biggest problems I encountered in using AD was limitations in the administrative tool (MMC) - the user and groups plugin for MMC could only handle listing 10,000 user objects in the group member assignment dialogue; there is/was a place to adjust the display of objects in the MMC interface, but it didn't apply to the dialog in question.
The forest I worked with had a domain that was expected to exceed 20,000 objects. By comparison, I've worked with eDirectory trees with millions of objects and the administrative interfaces coped with that number of objects perfectly fine. The older tools were slower; I personally find the newer tools provide a much better experience.
One of the biggest issues I had with AD, though, had to do with its dependency on DNS. The environment I worked in used BIND (various versions), which Microsoft's DNS service interacted with in bad ways on occasion. There was in particular an issue with MSDNS' glue records getting whacked, and that broke the integration. AD Integrated DNS is the way Microsoft recommended/recommends AD be implemented, but that was not feasible given the infrastructure and requirements.
Also, you need to be sure nothing external updates your DNS records, because once the DNS records are incorrect, AD is unable to replicate the corrected changes out because the DNS records are inconsistent between domain controllers. I do not believe this issue has been addressed (because it was something of a one-off situation)
Just a little background and in the spirit of full disclosure: I was the eDirectory ATT instructor for Novell for nearly 2 years, and currently have been employed by Novell for 5 years. I co-authored a couple of books with Peter Kuo on NDS and eDirectory troubleshooting, and am a
former support forums SysOp. I started working with NDS with NetWare 4.0 and use the current versions on systems in my own lab (which I maintain, though I've moved into a program management role now). I'm well-versed on the internals of eDirectory, and moderately versed on Windows 2000's version of AD, having met with engineers and product folks at Microsoft on a couple of occasions and having worked extensively with a couple of senior consultants at Microsoft on a very large deployment project for AD. I was the technical lead on that project until I took a position with Novell.
Edward van der Maas
I don't necessarily want to say that eDirectory is better then AD, but I can tell you some differences.
You can't partition in AD. If you want to partition, you create another domain in a forest. If you create another replica in AD, it basically means an entire copy of the domain. With Windows Server 2007 (I believe, I could be wrong here) something is being introduced called an
application partition. I got it explained and it didn't sound very pretty but that is my opinion, it might work quite well. You never know.
AD has things called global catalogs. These are servers that have a copy of all security principles in a domain. Security principles are computers, users and groups. A user always has to authenticate against a global catalog.
In AD, a container (OU) isn't a security principle. This means that you can't associate anything directly to a container; instead, you have to create a group per container and make all objects (or just users, whatever you are after) members of this group.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.