Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Basic security 1

Status
Not open for further replies.

drakkar

MIS
Apr 4, 2002
20
US
Does anyone have a document on how to secure a Netware 6.5 server within NDS?

It's been a long time since my 5.x training, but I'm pretty sure that I don't want to have users or groups given Supervisor rights on the server object itself. I had to remove a LabAdmins group from a server.

Basically, I'm going through my NDS tree and trying to identify areas that need to be cleaned up or secured.

I just can't remember what the basic rights are for the SYS volume. I know public is pretty much read only for everyone. Also, the rest of sys should be restricted to admin access. Am I missing anything?

Thanks,
Chris
 
I allow all users read and filescan in the PUBLIC folder only. The rest of SYS is Tree Operator or higher.



"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 
You can go to your remote manager ( reports / Log Files --> View Security Report. It's not going to tell you everything, but it will point out some obvious problems. That's where I would start.

There are numerous different approaches you can take for good security, some of them are more practical than others depending on your existing configuration. For example..

- Put users into containers outside of the server container, make sure the user container is parallel to the server container, not underneath it. This will prevent users from automatically inheriting default permissions. It forces users to ONLY have access to what you have specifically granted. This applies to NDS and File System permissions.

- Make sure non-admin users do not have security equivalency to Admin users or other users that have admin priviledges.

- You probably have NO reason whatsover to manually assign ANY regular user ANY NDS permission. The only thing you should be assigning MOST users is File System permission, ie File Trustee Assignments to specific folders for which they need access.

- Keep all user data, applications, home drives off of the SYS: volume. Do not assign anyone permissions to ANY SYS: volume folder or subdirectory. Do not put shared files in SYS:public. Put them on a different volume.

- Implement the Universal Password and create policies to enforce strong passwords and regular password changes. Universal Passwords provide MUCH more security than traditional NDS password can provide.

- Only grant file system rights specifically to the directory where they are needed. Do not give everyone full access to any volume. Very restrictive permissions up high in the file system. More generous permissions in subfolders where users need access.

- Never assign file system permissions to individual users. You should use Containers when possible (company wide or global) or groups the permissions only apply to certain people. Managing permissions by individual user is a nightmare.

Marvin Huffaker, MCNE
 
marvhuffaker said:
Do not assign anyone permissions to ANY SYS: volume folder
By default, Netware grants users read and filescan rights to SYS:public. Without those rights users cannot use the Utilities pointed to by the Netware client (copy, send msg, salvage, purge, etc.).



"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 
You may have read that wrong (or I didn't really explain it very well).. Besides any default permissions that are already assigned, don't add any additional permissions. That's what I meant to say anyway.. There are several folders in addition to SYS:pUBLIC that may require certain permissions, or have them assigned by default. I typically don't remove those permissions unless I have a specific reason to not want them there.

I rarely use those tools from the client that you mention, so I'm not 100% sure that they actually use anything out of Public. I thought they were workstation based. Again, I could be wrong.



Marvin Huffaker, MCNE
 
Hey thanks guys!!!

Sorry for the confusion on 5.x. That's what I last had training with Novell. I'm currently working on 6.5 with the latest workstation client.

Someone had set "GOD" rights for the LabAdmins on the servers themselves. I was pretty sure that's a big NO NO!!

We also have a programming company that is adamanant about putting their application the sys volume. At least that's where it's always been and the programmer has built in logic to always look to the F: (you can't imagine the fit I had when I found that out).

Any way, I'm going to be reviewing all the rights over our Winter break and hopefully be able to come up with a new security design.

Thanks again,

Chris Fink
 
Your "F:" drive can be mapped to any logical space... No reason it has to point to the SYS volume. Ours point to the user's home directory.

By default, the SYS volume is just big enough to hold the Netware files and a couple of SPs. Unless you created the SYS volume (and pool) much larger than default you're going to run out of space quickly (with very ugly consequences).



"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 
Lawnboy,

Yes, I know I can point F: to anything. Unfortunately, before I started in this position, this programmer had hard coded his programs. Now, I have a programming back ground and that also is not a good thing to do. However, when I asked about moving it off the sys volume, I met resistance from him, and since that office relys upon the application, there's not much I can do until we decide to get rid of the application.

Concerning the space, I was not the one who initially set it up. I was going to say that the size of the program and data is not that much, but I just checked and it' about 1.5 GB.

Guess there's another issue that needs resolving ...

Thanks again guys!!
 
I move apps off SYS volume all the time. Pretty much anytime I do a migration, move, or upgrade, I move non-netware apps off of SYS and just remap it. Nobody knows any differece. And since you really don't need mapped drives to SYS: anymore, nobody misses anything. Also have to transfer trustee assignments.

FYI the F: and Z: drive get mapped as part of the Default login script. This script cannot be changed, it can only be prevented from running. It runs automatically if there is no User login script defined for whoever is logging in. This is most likely the reason why everything was assigned to F:

You absolutely do not want to have to define an individual login script for each user, so instead, you add this line to your container script:

NO_DEFAULT

This will tell the client to NOT process default login scripts no matter what.


Marvin Huffaker, MCNE
 
Thanks Marv,

I really appreciate the feedback!!!

Chris
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top