Adding User Names And Passwords

Posted on 2004-09-07
Last Modified: 2008-03-03
This question will probably be answered in a flash. I come from a MS background and was asked to help a small law office with NetWare administration. I said sure figuring that I would be able to pick things up quickly. Oops. Now I need to know how to add users and give them rights. I would be fine simply giving admin rights to everyone at first then figure out how to pare down their individual rights. What I really need to know how to do is add a user name and password so new users can log in to the mostly MS network. This is a NetWare 5 server BTW.
Question by:roman411
  • 4
LVL 34

Expert Comment

ID: 11998147
I *strongly* suggest that you do NOT give admin rights to the users and then try to figure out how to pare them down, especially when the client environment is such an insecure thing as Windoze. One virus/trojan on the network and the next thing you know you have to re-install the NetWare environment because you don't know if the public-access utilities on the server have been compromised. It is IMPORTANT that you do this right the first time; I've lost count of the number of times I've heard people say "We just want to do it this way real quick, we'll go back and fix it right later" and either they never get back to it, or they break something else when they "fix" it and have to fix that, or they try and can't figger out how to change things without breaking something else. We NetWare admins prefer doing it right the first time.

More in a moment.
LVL 34

Expert Comment

ID: 11998230
Sorry, just wanted to get that info to you, and not be delayed by the rest of this.

OK, I understand you're a primarily-Windows guy, and you're at a client who uses a NetWare v5.1 network. Thank you for mentioning the version - so many people don't bother, and that leads to a lot of guessing.

The client machines ARE using the Novell Client 32 for Windows, right? Do NOT use the Micro$oft Client for NetWare Networks - it is *deliberately crippled* crapware. If you don't already have it, get the latest Client 32 from -->

And deploy it to the workstations. Since you're in a NetWare v5.1 environment, I'm going to *assume* (since you didn't say) it was installed using the defaults, and so it uses TCP/IP, and not IPX. When installing Client 32, do a CUSTOM install, and select TCP/IP only (do not include IPX) and select the NDS/NetWare 4 or later environment. I'm also going to *assume* that SLP is correctly configured in the NetWare environment - thus the workstations will be able to easily find the NetWare servers. If you don't use it, omit Novell Modular Authentication Services (NMAS, kinda like "PAM for NetWare") from the client installs.

OK, now that we have the environment established, we'll deal with creating users next. Let me know if any of my assumptions are wrong.

Author Comment

ID: 11998388
So far, spot on.
LVL 34

Expert Comment

ID: 11998484
In the NDS on v5.1 environment, users are created using the ConsoleOne tool. This is an integrated management tool that can manage many different aspects of the NDS and NetWare environment (MMC is crudely similar - MMC is just a shell, tho, that calls a buncha different programs, whereas ConsoleOne provides an integrated whole). You can also use ConsoleOne's predecessor, NWADMIN.

ConsoleOne is found at SYS:PUBLIC\MGMT\CONSOLEONE\1.2\BIN\CONSOLEONE.EXE. However, I suggest that you do NOT run it from the server. Copy that subdir and all its contents (including its subdirs) to a local drive and execute it from there. It will be much faster.

Alternatively, you can use SYS:PUBLIC\WIN32\NWADMN32.EXE. It differs from ConsoleOne in that it is a native Windoze app (ConsoleOne is written in Java) and therefore runs faster. However, I think you will find the ConsoleOne interface more similar to what you are used to (being a Windoze guy) and therefore easier to navigate.

Mind you, I have no idea about what Support Packs have been installed on the NetWare servers, nor have you mentioned any other applications in the environment (such as GroupWise, for example) that would require their own management Snap-Ins, or if those management Snap-Ins have been placed on the server from which you're drawing ConsoleOne (or NWADMN32), or if those hypothetical Snap-Ins are available on both ConsoleOne (or NWADMN32). I'm making a lot of assumptions here, you're the one in the position to tell me if what I'm saying does not jibe with the environment. You definitely want to use the tool that best fits the environment. Both tools are part of the standard load in the environment you've described.

OK, so I'm going to move forward assuming you're using ConsoleOne.

You must be logged into the NetWare environment using an account that has administration privledges. While there is an "admin" account created by default that has the necessary privledges, it may have been deleted/changed - unlike Windoze, the name/existence of the default administration account is not fixed - hackers trying to get into Windoze always have 1/2 of the credentials; in the NetWare environment, its a lot less certain for them. Anyway, you must be logged into the network with an account that has the proper credentials.

And you MUST be logged in on a workstation using Client 32 - the M$ client deliberately does not support the necessary APIs for administering the NetWare environment. In later versions of NetWare, Novell introduced the the iManager web-based management interface, but that's not available on this version of NetWare (v5.1 *is* still supported, but not everything has been back-ported).
LVL 34

Accepted Solution

PsiCop earned 500 total points
ID: 11998924
I write file locations as VOLUME:DIRECTORY\SUBDIR\FILENAME because that is unambiguous - a drive letter (F:) could point to anywhere.

OK, so with ConsoleOne, logged in as a privledged account. Let's get started.

Expand the NDS Tree icon in ConsoleOne. The various OUs of the NDS Tree will be displayed. Browse to the Context where you wish to create the user objects. (Unlike AD, NDS is an actual 3-dimensional/hierarchical database, and it not a flat namespace) Best practice is that you NOT place user objects in the same context as the NetWare servers. They should go elsewhere in the NDS tree. In a small environment, creating a context for user objects is not inappropriate.

Once you're in the context where you wish to place the user objects, click the "New User" button on the toolbar (or select File - New - User). Exactly what you see at this point does depend on the specifics of the NetWare environment and what Snap-Ins, if any, have been added to ConsoleOne's default set. At a minimum, you'll be asked to provide a user ID, the person's last name/surname, and asked if you want to use a template to create the user. If you've got just a few users to create, it may not be worth your time to use a template, especially if they are not all fairly similar. If you have a bunch to create, it may behoove you to use a Template or Templates (select File - New - Object and pick Template from the resultant list of object types). You can also create the user's Home Directory, I think.

Back to the New User dialog, check the Define additional properties... box and then click OK. The user object will be created in the context you selected, and then you'll be taken directly to the Properties page for the object you just created. You can now do things like add the user to GroupW or Organizational Roles, assign them specific filesystem rights, enter complete identification information (first name, middle initial, address, phone #, etc.), define a Home Directory for them (using a Template allows you to set many of these things by default when the user account is created).

Note that you can use MANY NDS objects to assign rights - unlike AD, you are NOT limited to Users and Groups as security principals. You can assign rights to the OU in which you create the users, and all users in that OU "inherit" those rights (and lose them if the account is moved out of the OU - yes, you can move objects around fairly easily in NDS, unlike AD). This is useful to assign rights you want all users to have. Note that there exists, by default, an EVERYONE Group that has some very basic rights to server filesystems. I can't recall if ConsoleOne (C1) puts users in that Group by default - you can add them, or have the Template do it.

I don't know enuf about your environment to giev you more specific information than this. Ordinarily, you should *not* need to assign the user accounts additional NDS rights. The defaults will be quite sufficient (a little permissive, even).

Filesystems (the Volumes on the NetWare servers) are a different matter. Hopefully, your NetWare environment was set up using some very basic "Best Practices" - chief among them, the creation of more than one Volume and the placing of user data/applications on a Volume or Volumes other than SYS:. If this is not the case, then I strongly urge you to look at re-engineering your NetWare environment. Failing that, use MAP to create the illusion that there are two different Volumes (one for the NetWare OS and system files, the other for user data/programs) by telling the users to use a different drive letter to access user data. This will help insulate the users from disruption when the environment is rebuilt the way it should have been built to begin with.

In a "Best Practices" environment, users should *never* be given additional permissions, beyond the default, on the SYS: Volume. That Volume should be reserved for the NetWare NOS, system files, NDS and public utilities. If GroupWise or another E-Mail system is in use, then the mailstore should not be kept on the SYS: Volume. Print Queues should not be placed on the SYS: Volume. Running the SYS: Volume out of space is a Very Bad Thing (tm) and users should never be given the ability to do that (yet another reason not to hand out admin-level privs and then try to pare them back).

In the filesystem directories where users DO need access, you generally hand out two kinds. Note that filesystem permissions in the NetWare environment are very granular. By comparison, the Windoze filesystem permissions are a crude subset. There are 8 filesystem permissions:

R - Read; ability to read existing files
W - Write; ability to write to *existing* files (but not create new ones)
E - Erase; ability to erase/delete an existing file
C - Create; ability to create new files and write to them (once closed, they cannot be read/written without the R and W permissions)
M - Modify; ability to modify the directory structure (add/remove subdirs)
F - Filescan; ability to see a listing of the directory
A - Access control; ability to grant rights, that the user has, to other users
S - Supervisor; deity-level control, cannot be blocked (similar to Full Control in Windoze, just not as clumsy)

These are generally expressed in the following notation: [SRWECMFA]

The two kinds of access most often handed out are "Read-Only" and "Read/Write". "Read-Only" access generally consists of the [ R    F ] permissions. This is sufficient for the user to see the files in a subdir and read their contents, but not write to them. "Read/Write" access generally consists of the [ RWECMF ] permissions. This gives the user pretty much carte blanche in the directory.

Remember that rights "flow downhill" in the NetWare environment. Unlike Windoze, you do NOT have to manually make a rights assignment apply to subdirs. It happens automatically. You can use an Inherited Rights Filter (IRF) to stop rights from flowing downhill if you wish.

I specifically caution you to NOT give the Supervisor permission to Jane or Joe Average User. They do not need it. It is dangerous in their hands.

You can create Groups and assign filesystem rights to the Groups. Users put in the Groups then get those rights. The same is true of Organizational Roles (the main difference between the two is that you can test for Group membership in a login script, you cannot test for Org Role membership). And OUs. And Drive Mapping objects. And Server objects. You must examine the environment and determine what methods work best - NetWare will support you (rather than force you to do things only one way).

Note that users cannot see a subdir to which they do not have permissions. So if you have SERVER1/DATA:ACCNTS-PAYABLE and Jane has permissions in there, but Bob does not, then Bob cannot even see that the directory ACCNTS-PAYABLE exists. This is much more secure than Windoze, where Bob could see that it exists and then have a target.

Its hard for me to get more specific than this. Do you need any clarifications? Do you have a specific scenario that is giving you problems?

Featured Post

Revamp Your Training Process

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Netware 6.5 sp7 vs edir 8.8.8 4 880
GroupWise 6.5.7 Webaccess not load (Page Fault) 5 802
Publishing Office 2010 in Windows 2008 R2 RDS 4 753
Virus Scan Novell File Shares 8 256
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. This article shows how to create one of these functions to write directly to Azure Table Storage.
Read our guide on how to survive being on-call.
Email security requires an ever evolving service that stays up to date with counter-evolving threats. The Email Laundry perform Research and Development to ensure their email security service evolves faster than cyber criminals. We apply our Threat…
A short tutorial showing how to set up an email signature in Outlook on the Web (previously known as OWA). For free email signatures designs, visit If you want to manage em…

713 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question