General discussion

Locked

Password container rights

By Q2Ggirl ·
How can I make a user a trustee of a container to change password for all users without allowing them to change the password for Admin since Admin is a user in the container?

Do I have to make a group and add all users except for Admin?

This conversation is currently closed to new comments.

5 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Password container rights

by BudTheGrey In reply to Password container rights

Maybe you can grant the user supervisor rights to the container, then use an IRF to remove the right from the Admin object. I'm not sure; you might not be able to filter the supervisor right.

A more elegant solution is to move Admin user out of that container. This might mean having to use contextful login for the admin user ".admin.org", but that's no big deal.

I find that the best tree design, especially if you are assigning managers of the various containers, is to have the admin be the only user at the top of the tree in the O= container, then create OU subcontainers and put all other users where appropriate.

HTH

Collapse -

Password container rights

by Q2Ggirl In reply to Password container rights

The question was auto-closed by TechRepublic

Collapse -

Password container rights

by Erekose MCNE In reply to Password container rights

You don't mention if this admin is a container admin or the tree Admin. If it is a container admin you can create an organization role that has the necessary rights to do things for all the users but the admin by filtering and changing the inheritance path. Remember trustees rights overule all other. If it is just a container admin, You should make it a trustee of the container and that container only. Do not use the security equivalence. Otherwise if they delete that account and you are security equivalent,you will lose your rights to that OU and they can cut you off from the tree. Make explicit assignments for both you and the container admin and the org role. That way the only thing they can do if they do change it will not effect you as long as they are not setting up IRFs. As long as you have a higher admin right(trustee of the root) then you can go back and change it at your leisure. That way you have the role in the future if someone else replaces that person, etc.
If it is the tree admin and you have a small one container tree then by all means move it out of there!! That is really bad design. A flat tree is never good and should be avoided. A change to the admin like that and a malicious user and you will have an unmanageable tree and then be calling Novell for the tool to recreate the admin account if they delete it and you are set as security equivalent to a deleted account. This is a typical mistake made by new admins. Read some Novell consulting guidelines on their website or pickup a book on the subject. These are the things you learn through experience.

Collapse -

Password container rights

by Q2Ggirl In reply to Password container rights

The question was auto-closed by TechRepublic

Collapse -

Password container rights

by Q2Ggirl In reply to Password container rights

This question was auto closed due to inactivity

Back to Networks Forum
5 total posts (Page 1 of 1)  

Related Discussions

Related Forums