Protecting ADMIN User 1

[gillis]

I'm the network admin for a modest-sized LAN using NW6. My assistant is very capable and trustworthy so I've granted increasing authority for those times when I'm out of town and he may need to "administer".

My question: Is there a way to grant him sufficient admin authority to take care of most needs WITHOUT granting the authority to change the Admin password - which, in effect, grants him the rights to eliminate ME or lock me out. It seems with Netware you're either a user with certain access rights or an Admin - nothing in between. Does Netware address authority based on security "levels" and I'm just not seeing how it's done?

Thanks for any tips!

 

[Provogeek]

This is actually a flaw in the Domain security model, not NDS. With Domains you either give an admin all rights to administer users just so they can change passwords, or you give none. Same goes with printer and groups and servers. All or none, it a pain to deal with in most cases. With NDS, you can grant specific rights to specific objects. In your case you want to give your assistant specific admin rights to either a an O or OUs in your tree. Do not give him admin rights to ROOT (it will keep him/her from adding servers to the tree in your absence, always protect root). If you can get away with just giving this assistant rights to just an OU, then your job is easier. Just grant this person all admin rights to the OU's this person needs to manage. You admin user sits under the top level O right under root. You assistant will not have admin rights to the O, so your assistant will not be able to muck anything up with the admin user. If you have to give your assistant admin rights to he top O in your tree, then only grant specific admin right properties.


This TID summarizes the O properties rights you can assign.

http://support.novell.com/cgi-bin/search/searchtid.cgi?/2913785.htm

You can also do a search on

http://support.novell.com

using the key words OBJECT RIGHTS. Quite a few TIDs come up that tell you how to grant object property rights for specific tasks.
Brent Schmidt CNE,Network +
Senior Network Engineer
Keep IT Simple

http://www.kiscc.com

 

[gillis]

Brent, thanks much for the insight. I understand the concept; however, at the moment ALL objects are directly under the O(rganization) level. It was originally setup that way. If I create a couple of OU's now under the root O, what problems might I encounter in moving existing user, printer, etc... objects from the root to a position under a newly created OU - as it probably should have been in the beginning?

Thanks again for your help,

Jerry Giles

 

[Provogeek]

Reorganizing the tree could be a good thing, it could also be a bad thing. It really depends on the size of your user base and how much work you want to have. It is something that should have been done from the beginning. Sounds like not much planning went into the implementation of the tree. A flat tree only works well in small companies. Once you get to a large tree that goes over a WAN, using anything under NDS85 will cause a huge amount of sync problems, even with NDS85 and up, you will still have sync problems if you have a flat tree. Your local channel partner will be able to better assit
you in redesigning your tree.


To start a move like this, start with just the users. Organize them acording to your companies organization role chart, or geographicl locations. When you move the users into their new OU, use the option to create an alias in the old location. This will allow for functionality until you get to the users workstation to change their login context. If you have contextless login setup already, you won't need to worry about this, but if you don't, have fun.

If you have not already setup NDPS, then don't move the printers. Move them as you get to NDPS. If you move the printers while you still use queue based printing, then you will need to reconfigure the print server on each printer.

Until you get more familure with the security objects, leave server objects alone (this includes SAS, SSL, KMO, License, LDAP, LSP, and volume objects). Your local channel partner can help you those (it's cheaper to hire a channel partner on a contract basis than it is to hire Novell NTS to fix a fubar, this include time waisted). Brent Schmidt CNE,Network +
Senior Network Engineer
Keep IT Simple

http://www.kiscc.com

 

[gillis]

We probably have what you call a flat tree due to our small size. I'm servicing approx. 75 users; so reorganizing may not be that difficult. I'll try to do some homework and planning before tackling it.

Thanks again,

Jerry Giles

 

[Provogeek]

Check this program out;

http://dsdesigner.hypermart.net/

It's not very expencive and can help your design go much better since you will be able to look at what your doing before you actually do it. Brent Schmidt CNE,Network +
Senior Network Engineer
Keep IT Simple

http://www.kiscc.com

 

[DSanbeg]

You can also create a "stealth" admin user. If you can't see it you can't delete it. If you need info on how to do this let me know.

 

[hoondy]

The other alternative is to look at Novell's iManager software. We have recently installed iManager 1.5 on one of our Netware 6 boxes. We can then set up Role Based Administration, which allows us to assign particular sets of tasks to a particular user or group. I was initally put off when using iManager 1.2.1 but 1.5 seems to be a lot better. Still room for improvement but quite a powerful product nevertheless.

Adam

 

[gillis]

Thanks everyone for your suggestions and comments. I'll take it all into consideration. Unfortunately, iManager is not operational yet (whole different story) so that isn't an option right now. Thanks again, JG

 

[hoondy]

iManager can be a real pain to get working. A pain I unfortunately know it only too well. Post here again when you revisit iManager if you are having trouble getting it running. I'm now very familiar with it's quirks and may be able to help.

Regards
Adam