On 2013-05-30 12:22, Ace Tunes wrote:
> That last paragraph meant nothing to me, sorry I am still studying. > > We have an online directory that pulls people's information, and I was informed that once we transition over people will not be able to appear individually listed in multiple departments. For example IUS and TSC would have to show up as one department in the online directory. I think I now know exactly what project you're working on, and where. That's not... exactly correct. More importantly, the concepts you're currently using in NDS no longer apply, so you're actually asking the wrong question. Start with the business requirement, and derive the technical requirement from it. NDS often has a very tall (i.e. many levels deep) hierarchical structure, which is not typically seen when using any other product, at least not within a single directory system. (Federated directory systems are common, however, and add at least one more layer of depth.) The ways you do things in NDS don't usually map well to other products. Large organizations are historically best served in AD by If the issue is that some users work in more than one department (e.g. half-time in each dept.), then there are multiple ways to solve the problem in AD. You can create multiple user accounts (bad option). You can create aliases [this is more or less what you do with NDS]. You can simply grant permissions directly to the user instead of relying on the hierarchy to assign permissions. Other, more complex, options exist. A much bigger problem for you is whether to continue using ZENWorks or not. If you want to keep using ZENWorks and all its companion products, you don't have much of a choice: use eDirectory. You're kind of stuck with it. If you're willing to look at ditching ZENWorks (and if you aren't using ZENWorks, why are you still using Novell?!?) then the range of choices opens up again. Much as I hate promulgating an all-MS solution, AD does work well for managing a mostly-heterogenous network consisting of Windows PCs. It scales well (much larger than any organization that exists in Canada today), and is well-understood and well-supported. It does require a re-think of how you do things; it does NOT emulate NDS very well, and trying to force that model on it is a recipe for failure. It's even reasonable to say that AD is multi-platform; Macs and UNIX boxen can join an AD domain nowadays without too much hassle. If my guess of where you're working is right, OpenDirectory would be a disaster. OpenLDAP would be a disaster (think hiring an additional three people on 5-year terms to make it integrate with everything). IPA (aka Directory 389, aka Netscape Directory Server) might work but you'd be force-fitting an randomly-shaped peg into a square hole. And then there's the last reason for recommending AD for mid-size (<20,000 users) deployments: training, resources, outside assistance... all readily available. I've implemented OpenLDAP, and the resources just aren't there. There's a handful of books, a handful of websites, a few dozen badly-obsolete HOWTOs, and a handful of consulting companies. And that's it. You have to be a Jedi to get it all setup and working and integrated: "Use The Source, Luke..." *sigh* I've implemented Netscape DS (now RedHat IPA) before, and although the resources are slightly better, they are even more obsolete. At least you can hire Red Hat :-). Perhaps we should be taking this off-list now... -Adam
_______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
