Tree Design for Universities
Novell Cool Solutions: Trench
Digg This -
Posted: 28 Oct 2003
Tree Design is a fascinating combination of art and science. There are many variables to consider, depending on your environment, infrastructure, staffing, etc. However, there are some things that work better than others in specific settings. For example, this is one university's proposed tree design, and comments about it. If you have any helpful comments to add, or if you have other suggestions for tree design that works particularly well in a university campus setting, please let us know and we'll post them here and send you a t-shirt for your trouble.
"Question: Since our users are mobile, where should our users' accounts be placed in our tree for optimal login/authentication purposes and to reduce any WAN traffic?"
I am seeking some advice on designing our NDS Tree. We are in the planning stages of upgrading our NW5x servers to NW6x. We would like to redesign the tree to improve upon the existing design and correct previous flaws. Here are our design considerations:
Our university has over 12,000 users (students, faculty and staff), 2 main campus locations and 8 different buildings with computer classrooms and labs that we manage. Our students need the flexibility to login from workstations at either campus and building/classroom.
After reading up on NDS/eDirectory design recommendations here is my question: since our users are mobile, where should our users' accounts be placed in our tree for optimal login/authentication purposes and to reduce any WAN traffic?
Here is our conceptual design thus far. I would appreciate any feedback and comments on whether this design is feasible or needs to have some design changes.
..university - Organization
..campus1.university - Org Unit 1
..campus2.university - Org Unit 2
..users.university - Org Unit 3
..building1.campus1.university - Org Unit 1 Org Unit 1
..building2.campus1.university - Org Unit 1 Org Unit 2
..building3.campus1.university - Org Unit 1 Org Unit 3
..building1.campus2.university - Org Unit 2 Org Unit 1
..building2.campus2.university - Org Unit 2 Org Unit 2
..building3.campus2.university - Org Unit 2 Org Unit 3
..users.university - Org Unit 3 (Container for all 12k user accounts)
Comments and Feedback
- Niclas E.
- David W. Sandlin
- Greg Pott
- Andrew Price
- Dennis Smith
- Scott Fitzhugh
- David Ruwoldt NEW
- Joe Zitnik NEW
- Dave Hindley NEW
This design should work. There are a couple of things to think about though. Having all users in once container may make it difficult to assign rights/ trustees. If all users will have the same right/trustees then it's fine, but if not you would have to declare rights/trustees to groups. Depending on how many rights/trustees you have to set, you may end up with a lot of groups. This is also true for associations, for example with application objects. If all users will have the same set of applications then it's fine, if not you must again use groups.
Check out the Q&A about Tree Design for more ideas
Another thing to think about is that having a container that contains very many objects is difficult to navigate with tools such as NWAdmin, C1 and iManager. As you would have to scroll through a large amount of objects. Also remember that NWAdmin can't even be used to deal with this large amount of objects in a container.
We have about 17,000 accounts in our tree (students, staff) and previously we had ours designed with user objects underneath campus OU's. This was obviously a nightmare once users started swapping frequently between our 7 campuses.
I have re-designed our tree in pretty much exactly the same way you have. There are campus OU's that contain the server objects, printers, etc for that campus, but all staff objects are in .staff.org and all students in ..students.org
Yes, the containers are large (especially students), but this causes little problem. Once ConsoleOne has the container open, it's quite quick to navigate -- NWadmin is much faster for general user admin. In ConsoleOne, the easiest way to quickly jump to a user object is do a FIND rather than browse the tree. I also replicate those partitions out to the local campuses to try and alleviate authentication across the WAN.
All our data sits on a SAN at one central site, so all drive mappings (except the location of our ZEN apps, that's mapped locally) happen across the WAN (32mb microwave).
Most rights are set to the top level students.org container, with a few child containers for particular generic accounts (library, trade areas, etc) and a couple of groups. I will be creating group objects for the students' course codes next year so we can assign rights to individual courses (in particular assign applications to courses).. I do all this via exports from our student records and LDIF). Naturally with staff, all rights are set via an abundance of group objects. It's so much easier now having all the groups and user accounts in one single container -- it was completely unmanageable having them spread out.
This tree should work well. Placing the users in an OU at the top-level will eliminate any walking UP the tree to access resources. The major drawback is that there will be a lot of tree walking happening at the top level of the tree. The WAN bandwidth concerns and authentication performance can be addressed via partitioning and replication. Create a partition for the users OU and place a replica at both campuses. Most likely there will be replicas of all partitions at both campuses anyway to provide fault tolerance.
Although the structure within users.university is not elaborated on (and following on from Niclas E), I would consider at least an additional OU for each type of user identified in the original request. i.e. students, faculty and staff.
I find this approach provides an extra level of security (or peace of mind) when assigning users rights and access to confidential or sensitive resources. Mistakes sometimes are made, but a user is much less likely to be created in the wrong container than incorrectly made a member of a certain group. This particularly applies when there are a great many users and groups (12000+) in one OU.
Niclas E. is right. I think it is essential to subdivide the .users.university into additional OU's. In my existing tree I have users distributed into two primary OU's.
The .staff OU is further subdivided into departmental OU's...
- .adm.staff.university (Administration)
- .maint.staff.university (Maintenance)
- .fac.staff.university (Faculty)
- .fin.staff.university (Finance & Business)
and on and on.
You could consider dividing the students by their courses of study as well, since you have so many, such as:
- .cs.student.university (Computer Science)
- .law.student.university (Law and Justice)
After all, how many students switch majors over the course of their studies? ;)
Something that might be considered to reduce the WAN traffic and speed up login times for the students, is to use filtered replicas. By using filtered replicas you can replicate just the student users between all sites which would give the students a local replica to log into instead of having to go across the WAN.
Another thing to think about is SLP. You should be using configured DAs at each campus for the servers and clients. This will help speed up the browsing of servers and files not to mention also help with login times. Also by using a DA you are now down to using unicast instead of multicast broadcasting from clients, servers and services. This is real easy to do, if the computers are using DHCP.
Great general design!
I'd augment it with extending the schema to hold the students' classes (probably with the official class number, since they are a standard length for each class at most universities), which can be populated via DirXML tied to the registration system. Once this is done, then use dynamic groups that are based on these class numbers.
Assigning file system rights to these various groups will cut down on a lot of administration headaches because the rights will automatically be given to users when they have been confirmed to be registered for a class. Since a majority of the classes are taught every semester and are also taught by the same professors, few file system changes (new directories, file copies, rights, etc.) will have to be done each semester. Hope this helps!
The design is all right and should work. I would do it a little differently.
Run a separate tree and use DirXML to sync accounts.
You could further break this up if you use an ID with a trailing number,
The number would be the last digit in the numerical ID. The ID should come from an ERP such as PeopleSoft or SAP etc. This unique ID can then be used for all accounts on all electronic resources. The ID should be unique for all staff and students forever. This means that when someone leaves you can remove all access for that account from all electronic resources. This heads down the SIM (Secure Identity Management) route, where every user is securely managed against every electronic resource the University has. Note you should make sure that the ID starts with a letter as some systems do not cope with an all-numerical account name.
We use the ID from PeopleSoft (EmpID), so my account is (for example) a1234567 which is my EmpID 1234567 with an "a" in front. This is my unique ID that I deal with the University's electronic resources with.
I would place a replica on each container. This way if something goes wrong with that replica and Novell tells you to XK2 your server, the amount of replication that will be required to place individual partitions back on the server is limited. While replacing all partitions will take time, the traffic for an individual partition will not be so great and will not affect the LAN/WAN as much.
You can assign rights to files and directories via groups or dynamic groups ideally. The big difference between groups and dynamic groups is speed verses flexibility. A group is fast as all the user information is already there. However you have to manually manage the group or use DirXML or scripts to update the group regularly. Dynamic groups can be a bit slower as they are built on the fly to check if the object has rights, but you do not have to administer them directly once you have set them up. You do have to administer the attribute that is used to form the dynamic group. So you have just shifted your management. If you can automate the updating of the attribute that is used for the dynamic group then this becomes a good way to do things.
So you have your servers in
You would also place your printers, etc., in these containers. You would place the groups/dynamic groups in these containers as well.
With this design you will get a lot of walking to the root and back. If
you make sure that you have the
and all sub partitions replicated for both campuses then things should be OK. You should make sure that you have at least two replicas of .users.university and sub partitions at both campuses. Again if you need to XK2 a server at either campus then this will save a lot of pain later on.
You will want at least 32 Mb or better between your campuses.
- Place your scope name in the .slp_scope.university replica
- Place a copy of the replica on each DA (Note one DA should be the master of the root and the other DA should have a read/write of root, also both DA's should be primary time servers)
- Place a DA on the end of each WAN link.
- Set the sys:\etc\slp.cfg so that it points to the other DA's for all other servers. Each DA should also point to the other DA.
- Set two primary time servers and all others as secondaries
- One Primary should be the master of the root
- The other Primary should have a read/write of root and be on the other side of the WAN link. You should have a primary at each site separated by the WAN link.
I think that is about it.
As a side note I would be interested in speaking to Dave who uses a SAN. We are having terrible trouble with our NetWare servers connected to our SAN.
If you have any questions you may contact David at firstname.lastname@example.org
I'm a little puzzled, as I think this is making things a little over-complicated. I work at a school with 15,000 students and about 500 administrator accounts. We have three campuses linked over either ATM or T1s. With the limitations on objects in a replica all but gone, we condensed our tree design. The amount of information sent during eDir syncs has also decreased greatly, so the traffic associated with eDir has gone way down.
We currently have an Organization with 1 OU for Academic and 1 OU for administrators. Tree walking is almost non-existent. We also have an OU for BorderManager objects (replica requirements). I have no problem browsing the ACS container with C1 or NWAdmin. We recently had our tree design evaluated by Novell Consulting, and they loved it.
We also have a campus with two locations. Five buildings at Location 1, and one building 30 miles away at Location 2. We have 14,000 students in our tree. The tree itself is setup as:
Under each location ou we have:
Each academic is then setup as:
Faculty are placed in the tree based on the campus they teach at most often, and students are placed in the tree based on the campus where they officially enroll. Placing students at the campus where they have the most courses keeps them close to their home directories. We are linked by 2 T1's, so we try to control the traffic on WAN as much as possible. We try to avoid as much as possible having students access their home directories over the WAN.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com