---------------------------------------------------------------------- NOV-NDS5.DOC -- 19971107 -- Email thread on NetWare Directory Services ---------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Wed, 9 Apr 1997 15:43:49 -0400 From: Debbie Becker Subject: Re: Netware 4.1 Security >I am running 9 Novell 4.1 servers over a WAN with container >administrators in each state. How can I check users security, >i.e. who has supervisor access etc. at both the NDS and file levels. > >I am aware of a utility that came with Netware 3 called SECURITY. >I don't have a copy of this and am not sure if it would be of any >use if I did have it. I would assume it would only work within a >bindery context and wouldn't know about NDS rights. > >I have used RIGHTS /S /T from the [root] context. Is this the only way? >or is there a another? I use RIGHTS VOLUMENAME: /T /S to get trustee assignments for all directories/files on a volume. Usually port this off to a file for easier evaluation. For NDS rights, I CX to the [Root] of the tree and type: NLIST * SHOW ACL This will show you the Access Control List (a.k.a. Object Trustees List) for all objects in the [Root] context ([Root], Country, Organization) with trustees and all Object and Property rights granted shown. I then run this for any object I want to check trustees for (i.e., NLIST "ORGANIZATIONAL UNIT" SHOW ACL /S). Usually run it for Organizational Units and Server objects. (Sometimes for volumes as well, since people seem to feel that granting NDS rights to volume objects will somehow translate into file system rights). Last thing I do is to run NLIST USER SHOW "SECURITY EQUAL TO" /S for a listing of all security equivalences (groups, org.roles, other users, servers, etc.) ------------------------------ Date: Sun, 13 Apr 1997 23:09:16 +0200 From: "Arthur B." Subject: Re: help with 672 NDS error >We are unable to see a server (PRESCONT) from another server (RYDDI). >PRESCONT has the master replica of a child partition (CONTRALORIA), but >the PRESCONT server can see the RYDDI server but it shows a 672 error. >In RYDDI server (partition ROOT). > * Unattended full repair: >This option always has errors, and they are "Illegal attribute for >external object". External object at it again... Besides the "Novell FAQ", Novell has this file called DSDOCxxx. You can FTP this from the Novell site. It has insight information for you. Because you have several problems I would advice following the instructions that are in DSDOC. It will probarly boil down to this: Make *sure* time synchronization is OK on every server. Make use of Partition Manager to pinpoint the replica that is most up to date. Back it up. Make sure it's errorfree. Back it up not overwriting the former backup. You might want to use DSMAINT for this. Check and repair external addresses. Send all objects to all replica's. If some replica fails do the 'check and repair external addresses' routine on that specific server also. If that fails repair the DS and try again. Be careful when the master replica has errors and a read/write replica has not and/or is more up-to-date (speaking hours not minutes here). Do one replica/server at a time. Put time between your actions (let the synchronization processes die out first). If you see a replica that is days behind in synchronization status then, ONLY if you have this option, delete it and recreate from scratch by making use of your other (read/write or master) replica's. When you're errorfree, replica synchronized and time synchronized again decide about making use of recommended Novell patches. If you can't follow what I'm saying then please consider consulting a local specialist or spend $200 on a Novell tech call. ------------------------------ Date: Mon, 14 Apr 1997 21:03:59 -0400 From: Greg Small Subject: Re: SECURITY_EQUALS Bindery Property & NW 3.12 >"This user's SECURITY_EQUALS property has group stored >beyond the maximum of 32, so the group is not considered when >determining Security Equivalences, Trustee Directory, and FIle >rights. The group membership is ineffective and should be deleted." There is a 3rd party utility called OVER32.ZIP which I have used to determine who was near, at or over 32 entries in the table. I believe this will also allow some kind of bindery change to make the entries over 32 work as expected. If you cannot find it EMAIL me at gsmall@spar.ca tomorrow and I'll ship it off to you. IMPORTANT NOTE -- FOR THOSE USING NW 4.1 and PROBABLY 4.11 -- the equivalent problem shows up when either 57, 58 or 59 entries (I forget exactly which) are reached. I only used to see the OVER32 in 3.1 and now the "over5?" in 4.1 when I was testing a lot of new apps and had all sorts of groups enabled. The users never reached this limitation -- that Novell obviosuly never expected ANYONE to reach. ------------------------------ Date: Wed, 16 Apr 1997 14:01:52 -0400 From: "Brien K. Meehan" Subject: Re: Admin User Corrupted >My NW4.11 server crashed during a Backup Exec backup. Upon rebooting >the NDS system was out of whack, I ran DSREPAIR and all is fine >*except* that user ADMIN is now an "Unknown" object (as opposed to >being a user object), I cannot login as ADMIN, unfortunatly I did not >grant another user supervisor equivelency so when I run netadmin.exe >as a regular user I don't have the privilege of deleting and >re-creating the Admin object. I can login as SUPERVISOR in bindery mode, >but I can't run netadmin.exe without NDS login. There is no utility (as far as I understand) for adding Admin-like rights to an object in a tree. If there is one with rights to [Root], you need to call Novell, and ask their expert hackers to add or fix the Admin account, using their special magical tools. For future reference, making an object security-eqivalent to Admin wouldn't fix the problem, because if Admin goes away, the other account becomes security-equivalent to no one! You need another account with rights to [Root], not just equivalence, to cover that base. --------- Date: Wed, 16 Apr 1997 14:33:01 -0600 From: Steve Miller Subject: Re: Admin User Corrupted >My NW4.11 server crashed during a Backup Exec backup. Upon rebooting >the NDS system was out of whack, I ran DSREPAIR and all is fine >*except* that user ADMIN is now an "Unknown" object (as opposed to >being a user object), I cannot login as ADMIN, unfortunatly I did not >grant another user supervisor equivelency so when I run netadmin.exe >as a regular user I don't have the privilage of deleteing and >re-creating the Admin object. I can login as SUPERVISOR in bindery >mode, but I can't run netadmin.exe without NDS login. There is a third party utility called MakeSU to make a new Admin object from the console. This utility is licensed to your tree. A demo and more info at at: ftp://ftp.netcent.com/makesu.zip. I have not tried this program, but I like the other utilities put out by this company, DreamLAN Network Consulting. ˙They make a toolkit (called NDS Toolkit) that includes this utility or you can buy it by itself. The last I knew the entire toolkit only cost $500 to $600. I think the MakeSU utility by itself might only be $100, and the guy at DreamLAN can probably mail it to you. Thats how we got our DSLogin utility from them. ------------------------------ Date: Sun, 20 Apr 1997 18:47:40 -0400 From: Debbie Becker Subject: Re: Remove NDS, corrupt ADMIN >The install utility (NW411) has an option to remove NDS from the >server. Unfortunatly, before it will allow me to remove NDS it asks >for the ADMIN password, my ADMIN account is corrupt and unavailable. > >If I unload NDS (unload nds.nlm) and login as supervisor, in bindery >mode, could I not delete some files at yhe DOS prompt, the NDS files? >Is there a way? I could then reinstall NDS and voila, I would have an >ADMIN account again. Try loading INSTALL as follows: LOAD INSTALL -DSREMOVE This allows you to "force" the process, even when you get to situations like you've described. After having told you that you have to login as ADMIN (and you fail to do so), you'll get a "Would you like to continue anyway?" type of message. ------------------------------ Date: Mon, 21 Apr 1997 14:27:41 +0100 From: Richard Letts Subject: Re: Compromise of a single NDS server >Is it true that in Netware v.4.x, if a single server is compromised the >whole NDS network could be compromised? To ellaborate: > >Say I get a rconsole password for a single 4.x server >Can I create/access accounts on other servers in the tree (using commonly >available hacking utilities like setpwd.nlm or burglar.nlm) No, not the whole tree, but you would be able to modify the password for any account that server held a RW/master Areplica for in the same way as you can any account on a NW3.x server you have the passoerd for. On our servers the rconsole passord bear not relationship to the ADMIN or SUPERVISOR passwords, gaining rconsole access to the server leaves the monitor lock-screen hurdle [we leave our console locked by default, even in the machine room]. Security requires thought, not questions. /please/ no knee-jerkreactions here. NT security is worse. I don't doubt for a moment you're an IS Security Auditor -- your question was simplistic; I know the kind since I'm getting atleast one dumb questionaire a week from our Auditors on network security. ------------------------------ Date: Tue, 22 Apr 1997 10:31:22 -0400 From: "Brien K. Meehan" Subject: Re: ? Admin password >Does anyone know how to recover an ADMIN password >on a Novell 4.1 network; without reloading. I'm assuming the problem is that you don't have an object with Supervisor rights to [Root], right? There are two things you can do: 1) Call Novell's technical support, and they can dial in to your network and create an object with rights to [Root]. $200, quality work. 2) Have a look at http://ourworld.compuserve.com/homepages/dreamlan/toolkit.htm. "NDS Toolkit" is produced by DreamLAN Consulting Ltd. (The president of this company is Peter Kuo, author of one of my "must have" books, "NDS Troubleshooting.") There's a utility called MakeSU that creates a user object as described. I tried the demo (after the last time someone asked this), and it really does create an object with Supervisor rights to the [Root]. But, the Demo assigns the object a password and doesn't tell you what it is, so it's essentially non-functional. ------------------------------ Date: Tue, 22 Apr 1997 16:17:43 -0400 From: "Brien K. Meehan" Subject: Re: NDS Merge Question >When you perform a NDS merge my understanding is that there can be no >objects at the root level at either tree, correct? ... of the same name, correct. >After the merge all >containers that were below the root in each tree now reside side by >side under the single root. My question is...Do I need to wory about >any of the objects within the seperate containers, i.e. duplicate >account names, group names, etc? [snip] Think about it in terms of "Distinguished Names." Duplicate distinguished names can't exist anywhere in the tree. For example, if I have an Organization named "Sales" just under the root, I can't have another organization called "Sales" just under the root - they'd both be "O=Sales" by their distinguished names. Now, if I had an organization unit called Humans, and another called Cats, I could have objects in both O's with the same name. It makes sense, because their Distinguished Names would be different. E.g. CN=Felix.OU=Humans.O=Lifeforms CN=Felix.OU=Cats.O=Lifeforms So, the objects have the same, but their "real names," their distinguished names, are different. ------------------------------ Date: Wed, 23 Apr 1997 11:29:31 +1200 From: "Baird, John" Subject: splitting up large student OU's >I currently have an organizational unit with about 4500 student ID's. >While it seems to work ok for the most part, some of our performance >problems are undoubtedly caused by the large number of objects in the OU. >I am planning to split the OU into sub-containers but would like to see >what others are doing in similar situations. We have 4 servers handling >the 4500 users, so my initial thought was to create a separate OU for >each server an put 1/4 of the objects in each OU. This would result in >somthing like username.server1.student.acadia. If we did this approach I >would use some easy scheme to determine which server the student was >located on, although undoubtedly there would be confusion. Alternatively >I could avoid a server-centric OU design and set up several OU's based on >last name. This might produce something like username.abc.student.acadia >and username.def.student.acadia and so on. I would have to assign home >directories to the OU's to try to keep things as uniform as possible. >While this approach avoids assigning a specific server to a student >(which perhaps makes things a bit more flexible), it doesn't really avoid >the confusion. > >What schemes are other people coming up with? I'm leaning to the server >centric design but that's probably because I'm still thinking in >simpler bindery-based terms. The best solution is a single OU like I have >now, but unfortunately that doesn't appear to be an option. We grappled with this problem late last year when planning for upgrading our two student servers from NW 3.11 to 4.11. Under 3.11 we had students with surnames beginning A-L on one server and M-Z on the other giving a roughly 50-50 split. The total student usercodes is ~5000. What we have done under 4.11 is retain this approach but to use two containers per server, so the students are in ae.ug.lu, fl.ug.lu, mq.ug.lu or rz.ug.lu depending on the first letter of their surname (and hence username), where ae.ug.lu contains those students whose usernames begin with 'a' through 'e'. Students in the first two containers have their home and mail directories on one server, students in the 2nd two, have them on the other. To date, we have not encountered any problems with this scheme. --------- Date: Wed, 23 Apr 1997 12:54:32 -0400 From: Doug Wilkinson Subject: Re: splitting up large student OU's We are using something similar to what you suggest. Our accounts are divided into 26 OUs based on the first letter of their login name. We have about 14000 accounts setup this way and it is working ok so far. Keeping 26 partitions and three replicas of each isn't that big of a deal as one might think. Of course, the day we have to repair a serious NDS problem may show us otherwise. It may be overkill, but it makes it simple for the users. Everything is on a LAN, no WANs or slow links here (luckily). I'm sure that making fewer divisions would be just as easy. DSREPAIR doesn't take long to run (about 5 mins) but the only time we have run it is if a server abends, and not because of some problem with NDS itself. To deal with the multiple OUs, programmers here wrote a front end for Windows/DOS and Macintosh workstations to automatically append the x.users to the login name so the user doesn't have to know what container they are in (not that it would take a genius to figure it out :-). User creation is done through UIMPORT from an external database. Breaking users up by server wasn't a consideration for us due to the number of divisions we needed and also because the idea of using server names seems so anti-NDS. Using container names based on the user's name was at least the lesser of two evils. --------- Date: Thu, 24 Apr 1997 13:28:42 +1200 From: "Baird, John" Subject: Re: splitting up large student OU's >students randomly set in containers. (What if 50% of the students are >named janssen?) With 5000 students you are not going to get much change from year to year in the alphabetic distribution of surnames. We debated at length how to divvy the students between servers when we changed from one student server to two. We looked at doing it by course or faculty but because many of the papers making extensive use of computers are common to more than one course there was no obvious way of doing this. One advantage we saw in doing it by course was that if a particular server went down, then either all or none of the students in a lab class would be affected. However, our server downtime last year during teaching time was less than half a day per server and most of that was due to the 35 minute startup time. With 4.11, startup time is no more than 5 mins. In the absence of any obvious way of dividing the students between servers, we chose to do it alphabetically so that given a username we would know immediately what server they were on. In deciding to use A-L and M-Z which gave close to a 50-50 split, I checked this against the number of pages for each in the local phone book and it matched pretty well. There has been some drift so the distribution is not as close to 50-50 as it once was, mainly due to greater numbers of Asian students, many of whose names begin with 'C'. --------- Date: Thu, 24 Apr 1997 02:47:41 +0100 From: Philip Zelazowski Subject: splitting up large student OU's >I currently have an organizational unit with about 4500 student ID's. >While it seems to work ok for the most part, some of our performance >problems are undoubtedly caused by the large number of objects in the > OU. >I am planning to split the OU into sub-containers but would like to see >what others are doing in similar situations. We have 4 servers handling >the 4500 users, so my initial thought was to create a separate OU for >each server an put 1/4 of the objects in each OU. This would result in >somthing like username.server1.student.acadia. If we did this approach > I would use some easy scheme to determine which server the student was >located on, although undoubtedly there would be confusion. > Alternatively I could avoid a server-centric OU design and set up >several OU's based on last name. This might produce something like > username.abc.student.acadia >and username.def.student.acadia and so on. I would have to assign home >directories to the OU's to try to keep things as uniform as possible. >While this approach avoids assigning a specific server to a student >(which perhaps makes things a bit more flexible), it doesn't really >avoid the confusion. I've got only 1500 students at my school, but still a handful with a throughput of some 500 a year. With this figure in mind I designed my NDS over four geographic sites, the degree course, the year a student graduates. The year containers are further grouped using groups to demonstrate what kind of degree, ie 2yr_BA, 3yr_BA, MA. The starting context for each site is the same, the organization itself - the school name .o=ccad (Chelsea College of Art & Design.) The student has learned the syntax for their rather long login name like this: myname.year I finish.what I do.where I do it from - smithj.98.public_art.limegrove They use the same login name at any machine from any of the four sites scattered over west London, the system login scripts are duplicated throughout the year containers (which contain the students) and will map the student's data, email, preferences drives to the student's local site server, while mapping operating system and applications drives and machine specific files from the server local to the login. The file structure is much simpler, the volumes are aliased as system, applications, data, where system and applications are mapped to the server local to the login and data mapped to the student's home server. During login, the original context is changed to a container called resources where all the aliases live with user friendly names to print devices, volumes and so on. There's a resources container hanging off each site container. The data volumes are organised (from the point of view of the student) as data:students\year\login_name. Though there is a huge amount of work in preparing just one account, the NDS and file system is so sweet and easy to maintain that it it worth it. The advantages from my point of view is that it is very easy to train people up to login and use the network and resources. Dealing with the throughput on the NDS is very simple - you add new year containers for the new input, you delete old year containers as they leave you! The same with the file system - you delete a year, you add a year. Once the user object is created then my interest in the NDS is purely and quite literally year in, year out. However, the complexity of the NDS reflects not only logical organisation from an administrative but also from a communications point of view. Using the free 1st Mail that comes with netware it is very easy to email a class of students specifically, ie 3yr_BA_grp.99.fine_art.manresa_rd. This makes life easy for tutors and administrators within the school. General email is handled differently. I use netscape and a pop server for each operating system, with the pop servers all converging on one set of email directories in the data volume local to the user's home site. There is added name space support on this volume so different operating systems can read and write the same set of files. This makes for a totally uniform email platform across all operating systems that is simple to use, works perfectly, free and looks good. (We use netscape for nearly everything cyber.) Emailing is simply addressed to login_name of the recipient if local, or an ordinary email address out of the college. Email in is to login_name@chelsea... This extra feature almost doubles the time it takes to create a user account with the creation of individual email directories, updating of pop server ini and mail policy files, individual sig files and addition of certain individual rights at the user object level. All in all the NDS and file system structure are very easy to maintain a steady throughput of students. The server load across sites is evenly balanced - small site, small server; big site, big server. The only problem was it took half an hour to build an account manually. I wrote a suite of basic programs centred around the netware uimport utility. Information in via a form is fullname, login_name, degree, year of graduation. Every 9 seconds a perfectly formed user object with all the files and directories and rights and personalised ini files is created. I am further automating this process so that it becomes part of enrollment so that a) information needs to be typed in only once, and b) it's out of my hair. --------- Date: Thu, 24 Apr 1997 15:58:50 EST From: "joe_flowers@ncsu.edu" Subject: Re: splitting up large student OU's We have ~14,500 student accounts here in our tree. Many many more expected. Currently, the accounts are held on 3 NW 4.10 servers with a little home directory space and WinPmail (NDS mode). Some NDS partitions have been created (16 so far) in this structure to help reduce slow-ups due to NDS synchronization. Since we're expecting the ~14,500 to eventually turn into ~60,000, we create student accounts like, for example, Joseph Lynn Flowers, .jlflower.j.f.student (which implies 26x26 containers) Corresponding email address is jlflower@email.chass.ncsu.edu. (I had to create another "helper" program for Mercury, to keep Mercury from bogging down the servers when it was doing searches for user objects in the .student structure. This problem blind-sided me.) We divide up home directory locations (volumes) based on the first letter in the student's last name versus student population distributions and volume sizes. We use the "#include .f.student" line for the "j.f.student" login script and the "#include .student" for the ".f.student" login script. Also, MAP ROOT U:=%HOME_DIRECTORY for home directory mappings. I also wrote a WIN95 GUI program to handle the logins in our student labs, so the students only have to type in the "jlflower" portion of their login name. (The login program "searches" the tree for the "jlflower" object and passes Login Script processing on to CLIENT32). If this program is not used, the .jlflower.j.f.student structure is fairly intuitive for the user or lab assistant to figure out. We create accounts from student class registration data, UIMPORT, and a simple homegrown "coupling" program. We delete accounts (based on the Last Login Date) using the JRB Utilities. ------------------------------ Date: Wed, 23 Apr 1997 14:49:21 +0100 From: Richard Letts Subject: Re: NDS Merge Question >When you perform a NDS merge my understanding is that there can be no >objects at the root level at either tree, correct? After the merge all >containers that were below the root in each tree now reside side by >side under the single root. My question is...Do I need to wory about >any of the objects within the seperate containers, i.e. duplicate >account names, group names, etc? For example, with the trees being >seperate user John Doe has one account, JDOE, in each tree. After the >merge he will still have two accounts, but they will be in different >containers and therefore possess different contexts, so there should >not be a problem correct? I guess I need someone to confirm my logic >on this? All the documentation I can dig up only mentions not having >objects in the root. It is vague on the concept of duplicate object >names. if you merge o=salford tree=salford with o=eccles tree=eccles we ended up with: o=salford tree=salford o=eccles if the 'o' had been the same we would have had problems. the probkem we had was with the contents of the partitions: ou=..... o=salford merging with cn=....2000 users.. o=eccles the merge of the root partitions generates a root partition which is the union of the merged pertitions, ie suddenly we had 2000 user obejcts in the root partition... a bad thing. make your root partition as small as posible before you merge (don't delete objects from it, just split the sub-tees from the root) ------------------------------ Date: Sun, 4 May 1997 16:03:24 +1200 From: "Baird, John" Subject: Re: accessing user properties in login script >I am trying to some different properties in the login script. The >Location field in NWADMIN can be accessed as %L in a script, but I cannot >find a way to access the Department field. The SETNAME JRB utility can be >used to set the property using the name %Depart, but that does not seem >to work in a script. It appears that the field is not available... Many of the field names used in nwadmin/netadmin do not correspond directly to the attribute names. Here is a list of mismatches that come to mind: Attribute name Nwadmin field name CN Login name (the first value in CN) Other name (2nd value in CN) Surname Last name OU Department SA Street address Physical Delivery Ofice Name City S State or Province L Locality ------------------------------ Date: Sun, 4 May 1997 16:20:30 +1200 From: "Baird, John" Subject: Re: replcation causing problems with account setups >I am trying to use UIMPORT to create accounts, but most of the time when >I run the program, I get errors similar to this: > >F:\>p:uimport student.ctl student.dat >Import context: student.acadia > Creating user 999900T.sz > Adding User > Generating key pair >**** Updating 999900T.sz **** >| >UIMPORT-4.26-991: An error occurred in NWDSMapNameToID. This may mean >that the skulker has not put object 999900T on server AXE1 yet. Error >code: FDA7. | UIMPORT-4.26-991: An error occurred in NWDSModifyObject. >Error code: FD9B. > User: .999900T.sz.student.acadia > Attribute: Profile > Value: .SSTUDENT.profile.acadia >*** Done > >I have a good idea that the problem is caused by the fact that uimport >has created the user in one partition and then when it goes to set other >information for the user, it retrieves a partially replicated account >from another partition. Is there anyway, aside from destroying the 2 >redundant copies of replica, to force all uimport requests to a >particular partition? As you suspect, the problem arises because Uimport is sending requests to different servers. The object creation request has gone to server A, uimport is almost certainly then creating the user's home directory on server B, and the error FDA7 reported by NWDSMapNameToID will occur when Uimport is obtaining the user's ID on server B for purposes of creating a trustee assignment. Server B has not yet received an update from server A announcing the new user. Error FD9B is reporting a similar problem i.e. a request was sent to server B asking for an attribute value to be added, and the attribute value was the new object name e.g. Uimport is trying to add the new user to a group. I dont know of any solution for Uimport. Its only recently that the SDK has contained any mechanism for ensuring that NDS requests are sent to a particular server, and the odds are that noone has gotten around to updating Uimport to use this facility. However, as we have discussed off line, JRButils creatobj now uses this facility. --------- Date: Sun, 4 May 1997 12:19:02 EST From: "joe_flowers@ncsu.edu" Subject: Re: replcation causing problems with account setups I'm curious. If you make sure you are authenticated to Server A and Server B while logged in with complete "Admin" rights over both servers, does this make any difference. We use UIMPORT here alot, but I always make sure I'm authenticated to all the relevant servers first. I haven't seen your error before. Is there a "timeout" count for UIMPORT retries that can be increased ? ------------------------------ Date: Mon, 5 May 1997 15:59:24 -0400 From: "Brien K. Meehan" Subject: Supervisor Rights >Objects in the O & OU of the tree show no supervisory rights to the >objects and no inherited rights abnormalities, until you get to the first >directory on the volume, any volume. > >At this point, the inherited rights filters show supervisor checked & >grey. [This is not how I configured the network.] Every user has >supervisor rights on every directory on the server. > >How can I remove the supervisor rights? Don't panic. You're confusing things a bit. IRF's are not effective rights. Also, object IRF's are not the same as volume IRF's. On volumes, you can't filter out Supervisor rights, the way you can on containers. That's why it's greyed out - you can't turn it off. This is completely normal. This is the way you want it. You don't want anyone to be able to filter out Supervisor rights to the file system, right? Now, figure out if your users really have supervisor rights. Use that "effective rights" button that's all over NWAdmin. If they have rights, it's because they've been assigned. Who are the trustees of the volume? What are their rights? Does someone have Supervisor to the root? Does the volume's own container have it? Maybe "Everyone"? No? Maybe it's a security equivalence thing. Who is equivalent to each trustee of the root? Who is equivalent to each container above the volume? Check effective rights, and the existing trustees. You will either find where the rights are coming from, or find that they're not really assigned. ------------------------------ Date: Fri, 9 May 1997 13:33:26 -0600 From: Joe Doupnik Subject: Re: NDS tree surgery >I've got an annoying NDS problem that I've been researching with no >success. I taught a NetWare 4.x class and created a container where >students could run amok with full rights. Now I've got several >containers with an IRF that blocks everything except Browse. This >makes cleanup "challenging" since there's no way to delete the >containers or the objects therein. I've checked and the accounts >used to create the containers are locked out as well. > >If there's a next time, I'll bring up a disposable tree for students >to frolick in. For now, I just want to lop off a branch of my NDS tree. ---------- Here's an object (sic) lesson for your students and staff: always create a safe administrative account on each server so that you can always get in and override anything others have done. Do not use "equivalent to." Here's another: never put play servers in the same NDS domain as production equipment. And the corrollary is never trust a server which has been tinkered with by less than expert hands: clean the drives and make fresh installations. Joe D. ------------------------------ Date: Tue, 13 May 1997 12:56:50 +0100 From: "David W. Hanson" Subject: Re: NDS tree surgery >Joe, could you describe how you can create an account that can't be locked >out of an OU? I'm probably missing something, but it seems that if anyone has >the ability to create a container there's an opportunity for everyone to be >locked out of it via an ill-conceived IRF. No one had access to system files >or configuration, or privs to do anything outside of their pen. There's full >control from [Root] down to where the IRF was created. This is what the >problem part of the tree looks like: I guess the key is to not grant any user objects supervisor rights to their own object, if I read the DynaText correctly. It is not obvious however. Maybe Debbie Becker can add some clarification... Here is what the DynaText says about object IRFs and Supervisor rights: Blocking the Supervisor Object Right The IRF of an object and its properties can block the Supervisor object right. This allows distributed management of the Directory tree. However, NetWare utilities don't allow you to block the Supervisor object right unless an object, including itself, is already granted the Supervisor right to that object. This helps to prevent cutting off Supervisor-level access to a part of the Directory tree. WARNING: Any object can be assigned as a trustee to an object, including to itself. But unless the trustee assignment is a User object, blocking the Supervisor object right with the IRF still cuts off that object from future control because you can only log in as a User object. Because the Supervisor right to objects and properties can be blocked, you should also grant a trustee all other rights. For example, don't grant only the Supervisor right. Even though that right allows or implies all rights to an object, if the Supervisor right is blocked, the trustee is left with no rights. Instead, grant all rights to the trustees, so that if Supervisor is blocked by an IRF, the trustee still has Browse, Rename, Create, and Delete rights. To change the IRF of an object, you must have at least the Write property right to the ACL property of that object. As with previous versions of NetWare, the Supervisor right cannot be blocked in the file system. A trustee who has the Supervisor right in the root directory of a volume has the Supervisor right to the entire volume, and it cannot be blocked with an IRF. --------- Date: Tue, 13 May 1997 08:17:45 -0400 From: "Benninger, Paul (WS)" Subject: Re: NDS tree surgery >Joe, could you describe how you can create an account that can't be locked >out of an OU? I'm probably missing something, but it seems that if anyone >has the ability to create a container there's an opportunity for everyone >to be locked out of it via an ill-conceived IRF. In the Novell on-line docs, there's a full, detailed description of how to create an account such as this. I think if you do a search for Workgroup Manager (I'm not 100% sure on the exact search string, but I think that is it) it will explain what rights to give to the "manager," how to keep him from blocking your rights, etc. It works, we used to use it in a former life, and we're addressing the issue in the current life. ------------------------------ Date: Tue, 27 May 1997 11:36:46 -0700 From: "Steven W. Smith" Subject: Re: NDS tree surgery On 5/9/97 I asked the list how to go about deleting a portion of the NDS tree where administration had been blocked by an IRF. Now that everything's fixed I'd like to summarize what I learned from it. 1, The only way to fix it: Call Novell. They dial in with PC-Anywhere (or equiv.) and edit the DS database with a magic utility (DSDUMP). They can either create a user object in the context with Supervisor privs, or delete the offending objects (OUs, users, etc). To avoid it, don't grant S priv. 2, Removing all replicas of a partition will render it unavailable, but will not make it disappear (even after 'NDS external reference life span' has elapsed). Also see TID 2906066. 3, DSREPAIR advanced options "Destroy the selected replica on this server" and "Remove this server from the replica ring" are dangerous. The preferred course is to use PARTMGR for such manipulations. "Remove this server..." can lead to servers disagreeing about what a replica ring should look like, which can cause synchronization problems. If "Subordinate Reference" replicas annoy you, too bad, learn to ignore them. 4, An option I considered for fixing the synchronization problem was to remove NDS from the problem server then re-install, allows the replica(s) to be recreated from the Master's definition. According to the tech I spoke to this would have lead to the loss of trustee assignments on the server's volumes. The original message with a couple of notes follows. Thanks to all who responded, hope this helps someone. // > I've got an annoying NDS problem that I've been researching with no >success. I taught a NetWare 4.x class and created a container where students >could run amok with full privs. Now I've got several containers with an >IRF that blocks everything except Browse. This makes cleanup "challenging" >since there's no way to delete the containers or the objects therein. I've >checked and the accounts used to create the containers are locked out as well. > > If there's a next time, I'll bring up a disposable tree for students to >frolick in. For now, I just want to lop off a branch of my NDS tree. One >idea I'm considering is making the parent OU of the locked containers a new >partition, then removing any/all replicas of the new partition. > See #2 above. The disposable tree is the way to go, unless you can teach someone to be an admin without giving them Supervisor rights (debateable). Thanks to David Hanson for info on S right and IRFs. > Another (less likely) option might be to try and restore (from backup) a >"pre-quiz2" version of the parent container. My feeling is that this won't >work, but I haven't tried it. I tried it. It didn't work and prompted a nasty sync problem and an annoying, hung BackupExec job. :-O ------------------------------ Date: Wed, 28 May 1997 18:25:29 -0400 From: Bob Becker Subject: Re: NDS tree surgery >Joe, could you describe how you can create an account that can't be locked >out of an OU? Let's say you want to create an administrative user (SubAdmin) for the Mktg container. 1) Create user object SubAdmin. 2) Make SubAdmin a trustee of the Mktg container and grant [BCDR] object rights and [RCWA] All Properties. Make a Selected Properties rights assignment to the container's Object Trustee List (ACL) of [RC]. 3) Make Admin a trustee of the Mktg container and grant [SBCDR] object rights and [SRCWA] All Properties. If you want to play it safe, grant Admin a Selected Properties rights assignment to the container's Object Trustee List (ACL) as well - [SRCWA], although this is redundant. 4) Make Admin a trustee of SubAdmin and grant [SBCDR] object rights and [SRCWA] All Properties. Again, if you want to play it safe, grant Admin a Selected Properties rights assignment to SubAdmin's Object Trustee List (ACL) as well - [SRCWA]. 5) Make SubAdmin a trustee of him/herself and grant [B] object right and [RC] All Properties. Make sure that his/her Effective Rights to his/her own Object Trustees List (ACL) is [RC]. 6) As an additional safeguard, I usually make Admin Security Equal to SubAdmin and to any server objects that are in the Mktg container. (Servers have [S] object right to themselves, so being security equal to them means that you have [S] object right -- and Supervisor file system access.) If a SubAdmin user has been set up in such a way as to allow them to cut you out of the tree, you can also try putting the container into bindery context and logging in as Supervisor or Admin and changing the SubAdmin's password to gain access. ------------------------------ Date: Wed, 28 May 1997 18:25:33 -0400 From: Bob Becker Subject: Re: NDS Names/Name Lengths/LONG Names >Our question is: how much additional overhead is caused by using >longer names for objects (up to 32 characters, I believe.) I'd be most concerned with length of the distinguished name -- I believe that the maximum length name is 256 (255?) characters. I've also seen posts on various utilities that choke when they run into a name that's over a set size (which seems to vary by utility, but is considerably less than 256 characters). ------------------------------ Date: Wed, 28 May 1997 18:25:35 -0400 From: Bob Becker Subject: Re: Position of NT Domain object in NDS >"Rule of thumb: Place the NT Domain (or Workgroup) object in >the same context that you want to create NDS accounts." > >This seems ok by the simple example that was included but I can't find >any information for how to do find an organisation that would have an >NDS-layout as below, i.e where users can be found in different contexts. >Will the Novell Administrator for NT function with this type of NDS-design >or where is the hook? According to the Novell 555 course liaison (who's spent a lot of time working with the product), this should be no problem. The NDS objects to be synched can be in multiple containers in the tree. The NT objects that you bring into the tree will be in the same container as the Domain object. ------------------------------ Date: Thu, 29 May 1997 13:02:14 -0400 From: Debbie Becker Subject: Re: Resetting users passwords on NW 4.11 >>>Is there any way to grant some assistant administrators the rights to >>>reset users passwords without givieng them all rights to other user >>>objects? > >>If you go this route, would recommend *not* giving the right at the >>container level, as you will have to give it to All Properties, which >>will allow full access to any and all properties of all objects from >>that point down (and will also give them the Supervisor file system >>right on all volumes of any servers in the path!) > >If you give the rights at the container level, you can remove all but >browse object rights which will disallow creation, deletion, moves, etc. >of NDS objects. We were specifically talking Property rights here -- I'd only give Object rights to people with full administrative functionality. >Additionally, if you remove all but [CR] on the selected property >BINDERY PROPERTY, it will disallow reassigning directory space >restrictions, rights to files and directories, and other file-type >functions. However, your assistant administrator will still be able to >do other things within individual accounts besides resetting passwords, >like resetting intruder lockouts, and adjusting all of the password >restriction parameters. Giving the Write right to All Properties at the container level effect *all* objects in the container and will be inheirited further down the tree. The [CR] Selected Properties assignment to a container will affect *only* that container (not its objects or subcontainers). Changing the Selected Property right for the container's Bindery Property has no effect on rights on servers in the container and the subsequent rights to the file system -- with Write to All Properties, the admin asst. still has full rights to the servers in the container (and this translates into the Supervisor right on the file system, the ability to create volume restrictions, etc.) It's a misconception that you have to have the Supervisor object right to a server object in order to get this right -- you need no more than the Write right to the server's Object Trustee List (ACL). You can get it from Supervisor object right because this gives you Supervisor to All Properties, which gives you the ability to Write to All Properties (including the ACL). What's even scarier is that you don't even have to use that Write right to make yourself a trustee and grant yourself additional rights -- the second you have the right, you also get file system access if there are servers in the container. I still don't like giving anybody the Write right to All Properties at a container unless I want them to have full access to the properties of every object from that point down -- fine for full admin folks, not so good for help desk personnel. Not just talking theory here -- have worked extensively with it -- done lots of troubleshooting on it for clients. Probably one of the most common issues I see in the field concerns inappropriate NDS rights assignments leading to file system access. ------------------------------ Date: Fri, 30 May 1997 20:59:54 +0200 From: "Arthur B." Subject: Re: Moving a server >We currently have two servers in an NDS tree called PCS. The primary >file server, PCS, handles file serving, backup operations, CDRom >sharing. The other server, PHSWEB1, is a web server (WS30), IPX/IP >gateway server, and and email server (Mercury). That's how things were >when I came on seen. My coworker and I are in the process of >redesigning the network. My part of this is to redo the servers. The >main server was 4.10, with the web server running 4.11. I have created >a new main server with a tree called PCS_TREE, and a server name of >PHSFILE1. Now I want to be able to take PHSWEB1, which is currently in >the tree PCS, and put it into the tree PCS_TREE without having to >backup the machine and reinstall Novell. Merging the trees is the way to go. Check out info on DSMERGE. ------------------------------ Date: Sat, 31 May 1997 15:50:45 -0400 From: Debbie Becker Subject: Re: Resetting users passwords on NW 4.11 >All I'll say is: try it first. I've done it here as a solution to a >similar problem. We set up a specific container for the help desk >people, made that container a trustee of the managed container(s), >and turned off all but read and compare on the bindery property >(in addition to the settings in my previous message, which were >pretty much right out of Novell's online docs minus the object props.), >and they cannot modify user space restrictions, or rights to files and >directories for the people in the managed containers. Been there, done that (but tested it again just to make sure Novell hadn't changed anything on me recently--it's been known to happen! ). Created ADMIN container and made it trustee to INTERMEDIA (my Organization, and where my server object resides). Gave ADMIN container Browse object right and Read, Compare, Write and Add Self for All Properties. Made a Selected Propeties rights assignment to INTERMEDIA's Bindery Property of Read and Compare only. Logged in as a user object in the ADMIN container and did the following: * Removed a user's rights to his home directory. * Created a new directory on the root of the SYS: volume and restricted its size. * Restricted the amount of space that a user could access on the SYS: volume. * Gave a user rights to the SYS:SYSTEM directory and removed all rights in the IRF. * Tested all of the above (logging in as users affected and seeing what the effects were). All changes made to the file system were in effect. This has been my experience consistently, working on many different systems. Do you, perhaps have IRFs up on your servers blocking those inherited All Properties rights (and, thus, access to the file system)? ------------------------------ Date: Mon, 2 Jun 1997 22:32:54 -0400 From: Pierre Marceau Subject: Re: Lost Admin user in NDS >We just had our ADMIN user deleted in the tree of a 4.11 server and >the three of us who had rights that were equivalent have lost them >and now only have the rights of the group EVERYONE. This happened to me a little while back my solution was to use the INSTALL.NLM -DSREMOVE option. The install.nlm has an option to remove directory services, however as you select this option it ask's for the admin password to continue, as Homer would say, "DOIGHT!" So what you have to do is "load install -dsremove" now when you get to the spot where it asks for the admin account and password simply press ESC and presto NDS is gone. Now you can install NDS and you will have an admin account again. Rebuild your tree manually, you should have noted the names and locations of any users, print servers and other NDS objects so as to rebuild them as effortlessly as posible. I was able to restore my TREE from my NDS compliant tape backup. Remember your system login script is embedded in the DS database so print it before you remove NDS. Learn from this lesson, it's not good enough to be Admin Equivelent. When you get your tree back go to the highest level, look at the rights assigned to the Admin user, assign the same rights to another user, ADMIN2 for example. Good Luck, hope your tree is not too big! ------------------------------ Date: Mon, 9 Jun 1997 00:52:12 -0700 From: "Philip J. Koenig" Subject: Re: Removing CDROM volumes from NDS? Martin C. Mueller replied: >>After installing NW 4.x, the volume name of the install disk (ie >>NW_411 or somesuch) gets inserted as a volume object in NDS. Even >>after removing and purging the CD from the server list (and unloading >>CDROM.NLM) the volume object remains in NDS. >> >>So this "phantom volume" continues to be listed as part of the server >>in NDS, causing "not available" errors in NWadmin etc. Is it safe to >>just delete these objects? I rarely mount CD's but would like to >>know if it's normal to have to manually delete the volume object >>everytime I mount a CD and finish with it. > >A volume gets an NDS-object only if someone explicitly does it, eg. via >INSTALL.NLM, option "Upgrade mounted volumes into the Directory". >Particularily mounting a CD doesn't do it. Deleting a Volume ID is >uncritical, only thing to remember is, that there may be pointers to it >from within other NDS objects (print queue volumes, of course not >applicable to a CD) or login scripts (map commands in NDS-syntax). Fabulous, yours was the most informative answer so far. Certainly this gets done during Netware install then, I may have not understood the implications of the abovementioned question during install. ------------------------------ Date: Tue, 10 Jun 1997 15:07:32 +1000 From: Mark Cramer Subject: Re: How to force DS to connect to another server >We have found that after a server has been down, it can take over two >hours for NDS to synchronise. The problem appears to be the failure of >a server to establish a connection to another for exchange of updates. >After a reboot of server A this morning, server A established connections to >other servers within a few minutes. Other servers with the exception of server >B re-established connections to server A. Server A was successfully sending >updates to server B, but server B because it had failed to log into server A >was unable to send updates to server A and was reporting -625 errors. The >problem resolved itself after a couple of hours when server B finally logged >into server A. Maybe what happened is that server B recognised A was online and >tried to log in while SYS was still mounting, failed, and then didn't try again >for a couple of hours, whereas the other servers succeeded on the first >attempt. > >Is there a DSREPAIR or DSTRACE option to force a server to attempt a >connection to another? The 'set dstrace=*u' command seemed like a >possibility but didn't do the job. Hi John, you did do the Set Dstrace=*u on server B? to tell it server A was back up. I've never seen this not produce the "Established communication with server A" message, unless there are comms problems between (and independent of) the servers themselves. Do you get any message on server B's console when you try the set dstrace=*u, after A comes back up? I normally do a set dstrace=*u then *h on the server holding the master replica, when a r/w replica comes back up. --------- Date: Tue, 10 Jun 1997 11:18:31 -500 From: Jon Dustin Subject: Re: How to force DS to connect to another server [continuing the above thread] If I am feeling impatient, I will use DSREPAIR to 'force' the servers to see each other. I use ADVANCED OPTIONS, SERVERS KNOWN TO THIS DATABASE, and press ENTER on one of the servers. From there you can choose an option REPAIR ALL NETWORK ADDRESSES or REPAIR SELECTED SERVER'S ADDRESS. You will have to perform this task in both directions, so that the servers will login to each other. Then schedule an immediate synchronization and all should be well. --------- Date: Wed, 11 Jun 1997 16:35:49 +1200 From: "Baird, John" Subject: Re: How to force DS to connect to another server [JRB, replying to both of the above replies in one message...] >If I am feeling impatient, I will use DSREPAIR to 'force' the servers >to see each other. I use ADVANCED OPTIONS, SERVERS KNOWN TO THIS >DATABASE, and press ENTER on one of the servers. From there you can >choose an option REPAIR ALL NETWORK ADDRESSES or REPAIR SELECTED >SERVER'S ADDRESS. > >You will have to perform this task in both directions, so that the >servers will login to each other. Then schedule an immediate >synchronization and all should be well. I am sure I tried that and it failed with either another -625, or -119 which we were getting on some occasions. The server was listed as down. I had the opportunity to try again this morning when the server was listed as up, but -625 errors were being reported by DSTRACE, and it worked. Is that consistent with your experience? >Hi John, you did do the Set Dstrace=*u on server B? to tell it server A was >back up. I've never seen this not produce the "Established communication with >server A" message, unless there are comms problems between (and independent >of) the servers themselves. > >Do you get any message on server B's console when you try the set dstrace=*u, >after A comes back up? > >I normally do a set dstrace=*u then *h on the server holding the master >replica, when a r/w replica comes back up. Using dstrace=*u on server B did not appear to have any effect, and it did not produce any messages on the console, possibly because B regarded A as being down, despite the fact that A was logged into B and happily sending updates. This raises the question of what causes NDS on one server to decide that another server is 'up'. Does this occur when it establishes a connection to that server, or is 'up' status a prerequisite for it to attempt establishment of a connection. While DS on server B considered server A to be down, there were no problems for a client logged into B making a bindery connection to A, or with an NDS login to B authenticating to A. The problem seemed to be limited to server B not establishing a connection to A for transfer of updates. --------- Date: Wed, 11 Jun 1997 09:36:55 +0100 From: "David W. Hanson" Subject: Re: How to force DS to connect to another server >>>We have found that after a server has been down, it can take over two >>>hours for NDS to synchronise. The problem appears to be the failure of >>>a server to establish a connection to another for exchange of updates. I have had success with using DSREPAIR, Advanced Options, Repair local database. I know it sounds a little drastic, but it did seem to force synchronization... ------------------------------ Date: Tue, 10 Jun 1997 11:56:01 -0600 From: Joe Doupnik Subject: Re: new epoch >Can someone define EPOCH for me? ----- I could suggest a dictionary. You know, that thick book which is more than a spelling checker. It's related to the word era, based on time. As an example, this the era when folks don't configure their mailers properly and thus send unwanted gibberish attachments to email messages (hint). Epoch is the time base of the system. NDS keeps messages in order by timestamp, and needs to so that an old message is recognized as having likely inaccurate information compared to recent messages and hence should be discarded. Using DSREPAIR to "declare a new epoch" means in practice to stop, wait for the declarer to say The time a the tone will be ..., and then let servers progress from that point forward. Those servers ahead of the time hack are obliged to forget and then relearn information based on the announced time. One does not want to "declare" frequently because it is a serious disruption to NDS synchronization activities, but when we need it we really need it. The common mistake on epoch things is let a server get days or years ahead of the tree. Oh boy, that's serious stuff. Ditto in the other direction. So we always check the time when rebooting a server and only after that check do we let the machine start server.exe. The smarter the system manager the more often time/dates are set wildly wrong, an observed situation based on not wanting to follow directions. Joe D. --------- Date: Wed, 11 Jun 1997 00:19:33 +0200 From: "Arthur B." Subject: Re: new epoch >Can someone define EPOCH for me? You mean to say that the help screen doesn't tell you enough? When the cursor is at 'repair time stamps and declare a new epoch', press F1. Check out page 2 out of a total of 5. ------------------------------ Date: Wed, 18 Jun 1997 09:58:33 -0400 From: Debbie Becker Subject: Re: for the NDS expert >Unlike supervisor, Admin is just another user with rights assigned to >all objects. It gets it's file and directory rights from having the >supervisor right to the volume objects. Wrong. Supervisor object right to volume objects gives you zip. It's being an NDS trustee of the *server* object with any combination of rights that will give you the Write Property right to the Object Trustees list (ACL) -- including Supervisor object, Supervisor All Properties, Read/Write All Properties, Write All Properties -- that gives you Supervisor file system right on *all* volumes attached to that server. --------- Date: Wed, 18 Jun 1997 21:21:52 -0400 From: Debbie Becker Subject: Re: for the NDS expert [Above msg text deleted] >So, what will the S right to the Vol object do for you? I thought the >reason Admin had rights to all files and directories was because he >had S right to [Root], so S right to a server, so S right to a Vol, >so S right to all files & dirs. You're saying the S right to the >server gives S right to files & dirs, so what does the S right to the >Vol do for rights to files & dirs. As you (Debbie) say above, zip? > >Do you have any further info on why this is? > >This thread started with a question of not being able to access the >"Trustees of the object" option for a file or dir. While writing my >answer, which was originally the same as most others - check for >IRFs- it dawned on me that files & dirs are not NDS Objects at all. >This is the answer the original poster was looking for (he told me >via private e-mail). But, that process shed a lot of light for me on >how everything ties together. I'm looking for a little more >enlightenment on why S right to a Vol doesn't provide S rights to the >file structure. I don't have a clue as to why Novell set it up this way (aside from confusing the heck out of people and making a living for some of us). I can see the original need for Supervisor object right to the server giving the user Supervisor file system right for all volumes -- the Supervisor object right assigned Admin (the original user in the tree) to the [Root] is inherited down the tree and allows Admin the rights (through this inheritance) to setup the file system on all volumes on the brand new (first) server in the tree. Guess they thought this was more efficient than using volume objects (although the volume object is a more *intuitive* link into the file system in my mind -- took me a long time to get to the point where I could keep that straight!) You can certainly give file system rights to the volume using the volume object -- but you have to use the Object, Details option and click on the "Trustees of the Root Directory" volume and add trustees with their *file system* rights here. I also wish that Novell had given different names to different types of rights -- I find it's very difficult students to keep them separated. It's confusing to have Supervisor object right, Supervisor property right and Supervisor file system right -- not to mention Read and Write for properties and file system (but that's another issue altogether....) ------------------------------ Date: Fri, 25 Jul 1997 12:36:05 -0400 From: "Brien K. Meehan" Subject: Re: Schema extensions... Fear and loathing? David Harris wrote: >When NetWare 4.0 came out, it was originally a no-no to extend the NDS >schema, because: > >1: Modifications to base schema classes (like "User") could not be >removed without a complete reinstallation. > >2: Trees/servers could not be merged when any of the candidates had had >modifications made to its schema. > >In a lot of ways, this seemed to defeat the whole point of NDS, but when >I was originally writing the NDS support for Pegasus Mail, people made it >very, very clear to me that I should not consider modifying the schema. >As a result I had to develop techniques that were inherently more awkward >than straight schema modifications. > >As far as I am aware, problem (2) may have been resolved with NetWare >4.11, but problem (1) may still exist. I believe problem (1) is fixed by later versions of DSREPAIR, which provides the opportunity to "Rebuild operational schema" in the "Repair local database" section. I'm under the impression it plops a schema definition into the tree, and repairs the database so that no objects have "illegal" attributes, effectively un-modifying your schema extensions. ... and (2) is also solved by later versions of DSREPAIR, which allow you to import schemata from other servers into yours. >What do people feel about software that modifies the schema now? Is there >still a resistance to it? It depends. If it's a server administration utility or augmentation, I think it's appropriate. I've seen other utilities that extend the schema for no good reason at all, or to do things that could be done more effectively using a file. I was evaluating a utility (I can't remember what it was now) that created a "(Utility) License" class, without even asking me! I was, let's just say, annoyed. I like to be INFORMED of any schema modifications that 3rd party software is going to do - there was no documentation about this change! I called the company and asked what modifications it made (at the time there was no easy way to find out), and couldn't get an answer. I removed the software, and vowed never to use anything from that company again. I wish I could remember who it was now... ... so if you're going to modify the schema, please be up front about it. And provide snap-ins to manipulate objects of your new classes. ------------------------------ Date: Wed, 30 Jul 1997 08:28:12 +0100 From: "Erik Bos, AMC afd. PC-LAN" Subject: (Fwd) NDS Object tracking >I have been wondering if there is a way to look at the properties of >an NDS object such as you could see who created it, when it was >created, when the object was last modified, etc. Kind of like the >File and Directory attributes that you can see through FILER. I >have not been able to find this functionality within the utilitities >that I currently have. Can someone point me in the right direction? There is a utility called Onsite Admin, you can download it from Novell.Com , with this utility you can get all info in a NDS object in one shot. It works great! ------------------------------ Date: Thu, 31 Jul 1997 10:27:30 +0100 From: "Richard Letts, Salford Univ." Subject: NDS design issue... >I have a major problem. > >Our situation: 300+ INW411 servers throughout South Africa. 300 >Individual trees for each server. >For instance Server name : PTA1 (Pretoria) > Tree name: PTA-1 > >We have to merge them now, but I've found that the organizations don't >merge, only the trees. > > [HQ] >[1] [2] [3] [4] [5] [6] [7] [8] [9] (9 Provinces) >Between 15 and 50 sites under each province. Cisco 2500 >and 4000 router network. > >What type of structure should we implement in NDS? I was thinking about >one tree, one O for each province and HQ, and OU's for each site. Each >site may have up to 5 servers, but most of them only one. We have 9 >provincial network controllers, and a couple of techies at HQ. Any >problems with my proposed setup? Any better ideas? I'd love some, coz >planning NDS is still a bit fuzzy to me... What speed links between the sites? what network topology? NDS design rules 1. Make the top of your tree geographic 2. Only locate replicas where they can talk to each other over fast links (eg in a region) 3. Keep [root] and any partitions replicated over WAN links small Timesync Establish timesync between ALL of the servers in your tree now, using configured lists and time-provider groups within each province with a primary reference server in the HQ and primary servers in each province, and each province's servers getting their time from within their province Timesync is really important to NDS stability, and there is nothing to prevent servers from different trees sharing the same timsync now. Pre-merge changes On each server make [root] as small as possible ideally nothing in it (ie only the one OU, and split that OU into a separate partition, even if it's only on one server)! move the users if you have to. when you merge trees all servers holding [root] in the original trees will hold [root] of the merged tree! if root contains 100 users then all your root servers have to replicate all 100 users during the merge process! Import the remote schemas into the central tree as soon as possible; in that way you'll get the schema's synced beforehand. Go slowly. NDS works best when you take your time. It might be better to merge the trees within each province separately if you trust the network controllers out there, or for you to have a check-list. then you merge the provincial tree with the HQ tree. Again... Go slowly. NDS works best when you take your time. ------------------------------ Date: Thu, 31 Jul 1997 23:36:35 +0200 From: "Arthur B." Subject: Re: NDS Tree Design >Our situation: >300+ INW411 servers throughout South Africa. 300 Individual trees >for each server. >For instance Server name : PTA1 (Pretoria) > Tree name: PTA-1 > >We have to merge them now, but I've found that the organizations >don't merge, only the trees. Well, seeing the possible problems you could implant in a wrongly choosen tree and distribution design may I suggest you make yourself a specialist on this issue first? Meaning get hold of good books, buy technical info if need be, browse the Internet and surround yourself with a few spare fileservers and routers and test and learn until you know NDS inside out. Then think up a design. Test it in a test environment. Let others shoot at it and test it out. Deploy it in small nearby areas and keep on testing. Then make it a reality for everybody. I'm saying this not to give an easy answer but asking the listgroup for tips is one thing. Overseeing the current, nearby and future problems is something that only your group can be expected to handle. As with all admins your network is unique in the world. With its own specific problems. Politics, strange router connections, outages, different software (IOS!) versions, security issues, local admins with their own views, powerusers that mean well, virii, etc. Not only does the final design need to be able to handle all of these aspects. Think of the future too. What kind of modifications are you expecting in the future? How are you going to handle upgrading NDS? What if some side demands additional schemas? How are you going to insure that all sites keep the same time? Any side that goes down for several days every now and then? Some areas that have constant troubles with the phone lines? Any political issues (our tree should be named: "I'll show them who has power for bypassing me" if you know what I mean) to be expected? What if NT Server pops up? Are routers filtering too much? Do you cut out the link to a side that breaches security (eg you find out they are hooked up to Internet without hardware firewall)? How do you handle failing primary servers and router lines? How do you handle loss of key personel? Etc. IOW designing a tree is one thing. Keeping it running with as less problems and downtime as possible is something else. Simply because things that have nothing to do with the design itself may pop up and interfere with it. One tip concerning political issues. At some point in time your perfectly designed tree will be attacked by someone that only has power but lacks any sort of skills and know-how. It would help your argument then if you can say (within 5 minutes! So prepare) that the requested modification can be made at the cost of: 3.7 hours 100% downtime for an estimated number of 1721 people and 83 hours of reduced performance, possible corruption (so need to do it all again) and sudden broken disconnections, etc., etc. for an estimated number of 8973 people. Furthermore an increase of 14% in administrational costs because of double work, etc., etc. Estimated extra costs for the first year: $314.500. And you need a temporary increase of 5 persons at the helpdesk to handle the expected increase in support calls ofcourse. Letting people sign contracts will not be enough to stop them from complaining, protecting their kingdom or simply showing off. Also be prepared to answer why you didn't use NT Server. Technical statements alone will probably not be enough. As I see it the workload will be mostly consumed by politics and handling human emotions (if people see that their known and trusted world is changing because of some outsider they are going to respond in all sorts of ways) and less because of technical issues during the first year. After a while they will have learned to life with it. But perhaps by then you're are looking towards something else ;) It helps if you involve people in your doings. Talk with them, don't send only memo's. It does cost extra time in the short run. It saves a bundle in the long run. And because you talk with them and involve them everything will be easier in the long run. All in all you've a very interesting project ahead of you. Almost wish I could be part of it. --------- Date: Thu, 31 Jul 1997 21:45:45 -0600 From: Joe Doupnik Subject: Re: NDS Tree Design >Well, seeing the possible problems you could implant in a wrongly choosen tree >and distribution design may I suggest you make yourself a specialist on this >issue first? >I'm saying this not to give an easy answer but asking the listgroup for tips is >one thing. >Overseeing the current, nearby and future problems is something that only your >group can be expected to handle. >As with all admins your network is unique in the world. With its own specific >problems. Politics, strange router connections, outages, different software >(IOS!) versions, security issues, local admins with their own views, powerusers >that mean well, virii, etc. >One tip concerning political issues. At some point in time your perfectly >designed tree will be attacked by someone that only has power but lacks any >sort of skills and know-how. It would help your argument then if you can say >(within 5 minutes! So prepare) that the requested modification can be made at >the cost of: 3.7 hours 100% downtime for an estimated number of 1721 people and >83 hours of reduced performance, possible corruption (so need to do it all >again) and sudden broken disconnections, etc., etc. for an estimated number of >8973 people. Furthermore an increase of 14% in administrational costs because >of double work, etc., etc. Estimated extra costs for the first year: $314.500. >And you need a temporary increase of 5 persons at the helpdesk to handle the >expected increase in support calls ofcourse. Letting people sign contracts will >not be enough to stop them from complaining, protecting their kingdom or simply >showing off. --------- Boy, the above paragraph needs to be written in Red phospher! Let me restate the problem in other terms for emphasis. It is very easy to fall into a fearsome trap of being technically excellent and lose touch with the serviced population, our customers. When that happens the customers can become unhappy and may have to resort to brute force in lieu of cogent discussion because they feel inadequate talking with experts. Then the brute force needs countering, but none is permitted, etc. I happen to have fallen to this trap recently and life is very difficult indeed. There are two ways out of it. One is to ensure folks are aware of and integrated into the strategic decision making process as well as local improvements. That's far from easy, but it is essential. Those folks then are at least aware of limitations and are able to approach matters incrementally with a basic idea of what is going on. They then are not your natural enemies/barbarians_at_the_gate. The name for this is "working together", from Boeing's experience. The second way is to not argue from opinion but instead let the data speak for you. In this case data is most often the costs of providing the wanted service. Costs include management fees. These approaches have a correllary problem of avoiding network design and management by mob rule or by bullies. To avoid that "snag" there must be mutual trust between the networking folks and the customers, and it's up to the former to develop that trust. See the first way as a method to achieve this trust. Last week I devoted part of a formal presentation to a large audience of top system managers on just this topic. I happen to be living the story. These problems are exceptionally difficult to deal with, and require both significant effort and much careful thought. Once in confrontation mode things are bad, believe me. Let me add two aphorisms I used as illustration: 1. Beware the experts for they develop tunnel vision, by me last December. Apply it to yourself first, as I did to myself. Experts also include the self-appointed variety regardless of real knowledge. 2. The problem with communication is the assumption that it has occurred, from the book "Twenty-First-Century Jet" by Karl Sabbach. This is by the Boeing engineer heading the B-777 project where this effect occurred with a vengence. >Also be prepared to answer why you didn't use NT Server. >Technical statements alone will probably not be enough. This is too true. Again, explain the management costs to maintain an NT server environment, and the things one can no longer do readily. In other words, better mousetraps most often do not sell themselves. >As I see it the workload will be mostly consumed by politics and handling human >emotions (if people see that their known and trusted world is changing because >of some outsider they are going to respond in all sorts of ways) and less >because of technical issues during the first year. After a while they will have >learned to life with it. But perhaps by then you're are looking towards >something else ;) > >It helps if you involve people in your doings. Talk with them, don't send only >memo's. It does cost extra time in the short run. It saves a bundle in the long >run. And because you talk with them and involve them everything will be easier >in the long run. Again, Arthur is right on target. There is no substitute for going to much trouble for face to face meetings; it's the personal touch. The idea is you are interested enough to go to that trouble, as a person, and while you are there treat the customers as intelligent people. I'll wager that the great majority of computer shops do not go to their customers and keep them involved, and that the more technically adept the shop the more likely that major trouble will occur. Joe D. --------- Date: Fri, 1 Aug 1997 10:19:10 +0100 From: Joe Harrison Subject: Re: NDS Tree Design... I can't say how much I agree with what Joe D. and Arthur have said on this subject, it's vital to CYA politically as well as the technical issues. Can I just add that Cheyenne do a utility named DS Standard that seems to be technically respected; this is an NDS modeling tool and in theory you can build the entire thing in simulation before committing to the real deal. You can get an crippleware evaluation copy from them, I'll be giving it a try myself later this week in fact. Cheyenne don't seem to have a South African contact number but if interested try e-mailing them at sales@cheyenne.com ------------------------------ Date: Sun, 3 Aug 1997 23:41:10 -0400 From: Debbie Becker Subject: Re: NDS design question >>[ROOT} and have a value of NET so that a user would see the their name >>as user.xxx.wcpss.net Is there a way to put this in? > >Sure, you could create an OU with that name. But just for this >purpose to create an OU seems a bit odd... Except for the fact that you can't place an OU under the [Root] ... Presently, using Novell's utilities, there doesn't seem to be a way to place any object under the [Root] except for a Country or Organization (and, as you noted, the Country object naming is restricted to the 2-character codes in keeping with the X.500 naming standards). There *is* an object type called Locale, which seems to completely circumvent the usual restrictions on placement. The only time I've ever implemented it was playing around on a test install, when I created a server context something like OU=container.L=place.OU=another.L=again.O=organization.L=location.C=US.L=somewhere Perhaps a third-party utility (DSStandard?) would allow you to create this container under the [Root] -- you could then move the Organization under this. Keep in mind that all distinguished names for all objects in your tree will change after you make the move. If you're running Windows/DOS, check Novell's documentation on the use of NCUPDATE to make the transition a little easier... ------------------------------ Date: Wed, 13 Aug 1997 14:49:34 +1200 From: "Baird, John" Subject: Re: Check Equivalent To Me >In Directory Services section of Servman there is SET parameter >wich is: "Check Equivalent To Me". What exactly is this parameter >and how I can use it ? The "Equivalent To Me" attribute was introduced in NW 4.10 and forms a backlink for security equivalences. If A is security equivalent to B, then A's "Security Equals" attribute contain's B's name and B's "Equivalent To Me" attribute contains A's name. I suspect what this parameter is controlling is whether this attribute should be checked when determining a user's rights at authentication. Normally checking the user's "Security Equals" attribute should be adequate, but maybe there are situations where a name can be added to an object's "Equivalent To me" attribute, without the other object's "Security Equals" attribute being updated. ------------------------------ Date: Thu, 11 Sep 1997 10:37:01 -0600 From: Joe Doupnik Subject: Re: Subordinate Reference >What are Subordinate reference replicas. It is nothing more than a pointer to lower down in the tree. It indicates how to get down there. Replicas automatically have pointers, superior references if one were to be precise, up the tree. Joe D. --------- Date: Thu, 11 Sep 1997 13:04:18 -0500 From: Paul Burrer Subject: Re: Subordinate Reference Subordinate replicas are placed on servers where a copy (Master, Read/Write, Read -although I never use read onlys-) of a parent partition is, and a child is not. --------- Date: Thu, 11 Sep 1997 12:12:28 -0600 From: Barbara Lewis Subject: Re: Subordinate Reference A subordinate reference is created under the conditions described below. It is usually referred to as a pointer, but it is slightly more than that. (Not much, though.) It has a complete copy of all the information for the partition root object of it's partition. One of the things that makes a partition root object special is that it has a few hidden properties, one being a list of all servers that have a replica of the partition. The subordinate reference replica uses that information to make it the pointer to the complete partition information. ------------------------------ Date: Mon, 27 Oct 1997 11:51:09 +0200 From: Mike Glassman - Admin Subject: General Info The following files can be used to check your NDS (for those of us who have NW4.1x). Dsmaint in two versions - DS410x.exe for Nw4.10, Ds411x.exe for Intranetware (note you can use the Install.Nlm to perform the same operations as Dsmaint.Nlm under Intranetware). Search for files at http://support.novell.com Scantree.exe - a Dos based utility for scanning the tree of your NDS. Search for it as SCANDS.EXE at http://support.novell.com - Note that this utility is NOT supported by the Novell Tech Services so use with care. Usage -> SCANTREE /d > filename Dsdiag.NLM - Diagnoses the NDS. This program is still in Beta, so preferably use on a non operational server in your tree. Refer to TID 2928396 for info on where to download this file. ------------------------------ Date: Mon, 27 Oct 1997 22:33:12 +0100 From: "Arthur B." Subject: Re: recreating deleted Admin object >Well, I'm sorry to have to be the bearer of bad tidings, but unless you >had another user object with rights to the [Root] as per the Admin user, >you have no recourse but to re-install NDS on your server. You have several options left still. First use DSMAINT to make a snapshot of your NDS so you have something to restore if below options fail. 1. LOAD A:\DSMAINT 2. Prepare server for hardware upgrade 3. Restore The whole procedure takes about a minute and leaves a special file in SYS:SYSTEM containing the snapshot. Second. Secure all your backup tapes. Right now they are worth gold. Option 1. Call Novell for about $200. If you didn't use DSREPAIR too much Novell still can re-instate your automaticly made backup of NDS (from the last time you run DSREPAIR) that still should have a valid ADMIN account. Perhaps they will even use the file DSMAINT makes to make the recovered NDS up-to-date. Perhaps Novell can do even more. BTW each of your three servers can contain such a backup NDS. No worry if only one server was DSREPAIRed too much. Option 2. Another option is to scout the Internet for hacktools. Be sure to find one that works with NDS not Bindery. Hacktools have no warranty whatsoever. Use at own risk etc. etc. Option 3. See if you can still use your SMS compliaint backup program to restore only NDS. Some of these programs simply add NDS records to the current records. It'll leave a mess to clean up but at least you'll have your Admin account back. Access your backup programm by logging in as the Bindery SUPERVISOR if need be. Option 4. As suggested: re-install NDS and restore from backup tapes. Practise this on testservers and/or less important servers before tackling the main server. --------- Date: Tue, 28 Oct 1997 09:48:44 +1300 From: "Baird, John" Subject: Re: "Re-create" (default) Admin object >What happend was the user Admin (default enterprise NDS administrator) was >accidentally deleted. And now we don't have other users in the tree to >perform the NDS administrative tasks. What I want is to "re-create" the >user Admin and assign all NDS administrative rights to this Admin user. I >know that I have to reinstall the server. I will take this as the last >resort. Until then I am seeking help from any kind person. >For your info the Novell software we are using is IntranetWare 4.11. DreamLAN Consulting have a program which can solve your problem. Here is a message from Steve Miller posted to this a few months back giving the relevant info. >>My NW4.11 server crashed during a Backup Exec backup. Upon >>rebooting >>the NDS system was out of whack, I ran DSREPAIR and all is fine >>*except* that user ADMIN is now an "Unknown" object (as opposed to >>being a user object), I cannot login as ADMIN, unfortunatly I did not >>grant another user supervisor equivelency so when I run netadmin.exe >>as a regular user I don't have the privilage of deleteing and >>re-creating the Admin object. >> >>I can login as SUPERVISOR in bindery mode, but I can't run >>netadmin.exe without NDS login. > >There is a third party utility called MakeSU to make a new Admin object >from the console. This utility is licensed to your tree. To see a demo and >for more information, get ftp://ftp.netcent.com/makesu.zip. I have not tried >this program, but I like the other utilities put out by this company, >DreamLAN Network Consulting. They make a toolkit (called NDS Toolkit) >that includes this utility or you can buy it by itself. The last I knew the >entire toolkit only cost $500 to $600. I think the MakeSU utility by itself >might only be $100, and the guy at DreamLAN can probably mail it to you. >Thats how we got our DSLogin utility from them. > >Steve Miller >stevem@ftj.com ------------------------------ Date: Tue, 28 Oct 1997 12:45:39 -0700 From: Tim Madden Subject: Re: INW 4.11 -- reinserting server into tree >Please help. I haven't been able to find this scenario on in the >Novell TIDs. Here's the story. We have a INW 4.11 server that failed >and we thought it would need to be replaced. We removed it from the >replica ring and NDS. Now the server is repaired. It has a >read/write replica that thinks it is still part of our tree. The >master replica thinks the server doesn't exist. How would we get >this server back into our tree? Can we safely connect it to our >network and let it sink with the other replicas and then recreate >the server object in NDS? Why not just remove DS with install.nlm and then reinstall into the existing tree? Partitions and replicas can be re-established once it's safely reinstalled. Your tree *is* okay with out the server, correct? --------- Date: Tue, 28 Oct 1997 12:03:41 -0800 From: "David H. Wentworth" Subject: Re: INW 4.11 -- reinserting server into tree We tried removing DS with install.nlm and got error -625, cannot remove directory services. I looked up "-625" in DSDOC2 and got "Explanation: This error indicates the inability to communicate across the network either between a client and a server or between two servers." So it seems we can't remove DS as long as the server is isolated from the servers it thinks it should be talking to. Our tree is fine (in sync) without the server. ------------------------------ Date: Wed, 29 Oct 1997 12:09:07 +0800 From: Leonard Holling Subject: Re: Novell Replication Services >While evaluating Novell Replication Services, I have run into a very big >snag. Here is the situation. Most of our company's production data and >applications are being held on the SYS: volume. As you may know, >Volume-to-Volume replication of the SYS: volume is not supported in NRS. >The only replication that we are able to use through NRS is >Volume-to-Directory. This method does not suit our structure very well as >it replicates the whole directory structure from the Master server to the >target directory on the Replica server. What I would like to know is if >there is any way possible to have NRS perform Volme-to-Volume replication >on the SYS: volume or some kind of work-around that would make >Volume-to-Directory replication behave like Volume-to-Volume replication, >i.e. replicate one directory on the master server to the same directory on >the replica server without the rest of the directory structure. Any insight >or solution to this dilemma would be greatly appreciated. There is a way. You could download the next beta of NRS and this does support the SYS: Volume replication. The filename is NRSEXTB3.EXE available from Novell on their web site. ------------------------------ Date: Thu, 30 Oct 1997 16:23:13 GMT+1 From: Steinar Kleven Subject: New management tool. A free management tool for NDS and NW 4.x servers based on perl is available at http://www.ahs.hist.no/distr/NDSm/. It's written as an extension to perl, and it tested with Standard release of Perl running on a NT 4.0 ws. If you get bored of waiting for a LDAP enabled script program you can fetch this extension. There is NO charge, NO images and NO promotions on the NDSm pages. This is offered to the users of Novell NOS just to make life a bit easier. ------------------------------ Date: Fri, 7 Nov 1997 11:20:06 +0200 From: Mike Glassman - Admin Subject: NW4.1 Printing Without refering to your question about guest access to your print queues, I'd like to take a sec (or two) and refer to the object called [Public]. (not to teach you, but to use your q as a pointer to an explanation). *This is where one would normally put up a HUGE red light wish flashes with sirens and a voice screaming DANGER* [Public] as everyone knows, is not to be equated with the old lovable group we call EVERYONE, excepting in one issue, and that is that EVERYONE of the OBJECTS gets something from [Public]. That's it. [Public] as an object (I like to call it a floating object since it isn't viewable as an actuall object in the NDS tree), is used primarily for pre Authentication stages. This of course means, that the reason users can see the LOGIN directory is due to [Public] having the rights to view and execute (files not people) there. This right is given to users/objects/clients BEFORE actually being authenticated to the tree. If this is the case, what would happen if I gave, say, the C right to [Public] on my server object, or my tree etc ? View the issue as far as [Public] is concerned as - that is a Dangerous object to play around with. If I make a mistake, I am [in deep doodoo] This is for everyone interested, not only for Bill, as I know from teaching this subject (ok, so you've all found me out, I'm a minor CNI), that users/sys admins think that using [Public] is a great way to give rights and not have to worry about it again......WRONG. --------- Date: Fri, 7 Nov 1997 19:09:45 -0500 From: Debbie Becker Subject: Re: NW4.1 Printing Actually not quite as big a problem as it appears -- at least in NW4.1x, [Public]'s rights are limited prior to login. You can assign rights in various places in your file system, NDS, etc., but prior to login, you only have access to those rights for the LOGIN directory. That said, I always recommend that folks use [Root] if they really want to give rights to *everyone* in the tree. Novell has changed the way [Public] works in the past and I prefer not to be caught by surprise (and with too many rights available) if they should do so again! ------------------------------