Novell is now a part of Micro Focus

Chisholm Institute - NDS Design

Novell Cool Solutions: Trench
By Dave Banen

Digg This - Slashdot This

Posted: 8 Oct 2003

Going back before the incarnation of Chisholm Institute as it is today, the 7 campuses were previously under the umbrella's of three completely separate educational institutes in the south eastern region of Melbourne. Whilst merging the institutes and therefore the three separate NDS environments together gave us a working tree, it was by no means practical.

The layout was basically an OU for each campus and under each of those lived server objects, printers etc. In turn, under each campus OU were sub OU's for staff, students, and workstations. This basically meant staff accounts were scattered amongst 8 or so different containers, which made administration a hassle - and it was becoming more and more troublesome as staff tend to move from one campus to another.

Then we introduced individual NDS and NIMS accounts for all students (instead of generic lab accounts), and the time came for a complete re-think of our tree design.

The infrastructure?
All campuses have full WAN connectivity, the main sites traversing 34 MB ATM's. In the last 2 years also saw the introduction of a SAN solution, so all file storage for staff and students resides centrally at our main data centre rather than scattered across multiple campuses (as it was previously). At present all student data is served by a single NW6 server (also running NIMS), and all staff data is served by a 3 node NetWare 6 Cluster. There is a single NW6 server at each campus to serve NDPS, DHCP and for storage of ZENworks snapshots so that *.fil files are not fetched across the WAN. In addition to these servers, Groupwise servers, some database apps, DNS, etc make up a total of 20 NetWare 6 boxes across the network for approx 3000 workstations. ZENworks 4 is used and relied on extensively, as is the case in most educational environments.

The resulting design?
The good thing about the existing layout was that we could retain it, and just add to it rather than blow away and start from scratch. I decided on the following structure, each of the top level OU's is partitioned off.

[ROOT] Org
OU - Applications
      CN - All ZENworks apps live here
OU - Campus1
      CN - Server objects
      CN - NDPS Manager / Broker
      CN - DHCP subnet objects
      OU - Printers
             CN - All NDPS printer objects for Campus1
OU - Campus2, Campus3, etc etc.
      .as above for each campus
OU - Services
      OU - Slp scope (named SLP scope)
      CN - DNZ zones
      CN - 2 x Slp DA's
OU - Staff
      CN - Group objects
      CN - All staff objects (approx 1400)
      OU - Workstations
             CN - Staff workstations
OU - Students
      CN - Group objects
      CN - All student objects (approx 20,000)
      OU - Workstations
               CN - Student workstations
      OU - A couple of other sub OU's for some generic Library, Prac Firm, Shortcourse accounts

The above design resulted in a much more managable tree. The students container is quite large, so yes, ConsoleOne / NWadmin take a while to open it - however, once open, it's not a problem. As we all know, browsing ConsoleOne is slow at the best of times, so we've found the best way to navigate to a user object is using the Find feature - as browsing a container of 20,000 user objects is a nightmare in C1. (However it's much easier in NWadmin, which is what I do most of my student user maintenance in).

I have also recently blown away the SLP v1 unscoped configuration and created a named SLP v2 scope with just two DA's servicing the entire network. This is working beautifully with no issues at all, and is considerably easier to maintain than an unscoped configuration with DA's all over the network.

Part of the project was also to create a "Helpdesk" NDS group to allow Helpdesk to maintain user accounts, NDPS printers (Creation, maintenance, etc) and various other tasks - without helpdesk staff having 'admin' accounts. The new design made this easy with just a few trustee rights. We've given the Helpdesk full rights to the Printer OU's, and the staff & student OU's - this saved on having to manually give them rights to individual object properties, because the only objects in those containers are printers and users, so supervisor rights to those containers is perfectly acceptable. Naturally I have moved the half dozen users with full admin or [root] privileges up in the tree to directly under [root] so that the Helpdesk staff do not have the ability to reset an admin account password. I also gave Helpdesk CREATE & ACCESS CONTROL permissions on the top level USERS folder where home directories are stored so that they can create new NDS accounts without actually having any read permissions on the users' home directories (an attempt to stop snooping eyes!) Ofcourse this isn't fool proof, but it's good enough for our purposes.

Having all user accounts under just two containers (one for staff, one for students) also makes login scripts so much easier - we've gone from having 8 login scripts to just 2. It also means drive mappings are now standardised across all sites. Network permissions are also greatly simplified. The benefits of this design over the previous are quite obvious - management of user accounts is now an absolute breeze in comparison!

The future?
DirXML! At present student accounts are created by quite a mixture of technologies that I have bound together using VB. Ultimately the import occurs using command line ICE and LDIF files, the home directories & quotas are set using JRB. Presently, staff accounts are created & expired manually, with no interaction between IT&T and the HR department. The new design lends itself to a much more uniform identity management strategy, so when DirXML is integrated with other systems such as HR and Student Records, hopefully the NDS side of things will be relatively straightforward.

For any more information, please feel free to e-mail me at

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates