Removing Rights for NDS and File System
Novell Cool Solutions: Tip
By Niclas Ekstedt
Digg This -
Posted: 28 Jun 2006
A Forum reader asked the following question:
"Here is my general NDS tree setup:
O=xxxxxxxxxxxx OU = state containers OU = site containers
In general, each site container holds 1 Novell 6.5 SP5 server. For this example, the state container is HW, and there are 15 site containers below the HW state container.
The HW IT group has always managed the HW state container, with full rights to the HW NDS structure and the servers' file systems. There is a requirement now to remove all NDS and File System rights to just one site container - 'HC' - within the HW state container from the HW IT group. HW IT does give certain rights to the HW container so that they will flow down, so we need the flow to not happen at the HC container. Also, RBS Roles have been given to a particular NDS group at the HW state level for the RBS Scope.
There are IDs higher in the tree at the Corporate level that we can give explicit assignments to, if it involves an IRM modification.
What is the easiest way to block the HW IT people from having any access to this one site container within the state container, as well as the HC container's Novell server's file system and RBS system?"
And here's the reply from Niklas Ekstedt ...
IRF's are used to block inheritance of rights. The problem is that it blocks rights from being inherited for anyone, not just a particular trustee. Thus, you can't say that an IRF should only be used for the group HW IT Group, as the IRF will prevent anyone having rights above from inherit them down.
I think the best option here is to actually create a new trustee below, assigning it zero rights (or a minimum of rights). A new trustee assignment made further down in the tree will take precedence. However, the new trustee must be made to be the same object as above. Picture this:
O=ACME Trustee=UserA.NYC.ACME, BCD|Trustee=UserB.LAX.ACME, CD |-OU=NYC | |_OU=IT | |_CN=ServerA | |-OU=LAX |_CN=ServerB
In the above example, UserA will inherit Browse, Create and Delete rights to the whole subtree below O=ACME. Meanwhile, UserB will inherit Create and Delete rights to the whole subtree.
Now suppose that UserA shouldn't be allowed to create and delete objects below OU=LAX.O=ACME. But UserB should still be allowed to do this. Given the above setup, we cannot place an IRF on OU=LAX.O=ACME and block the Create and Delete right, as this will also block UserB's rights. Instead we can create a new trustee assignment for UserA and assign only the Browse rights, as the user should still be able to Browse the subtreebelow OU=LAX.O=ACME. The example below illustrates this.
O=ACME Trustee=UserA.NYC.ACME, BCD|Trustee=UserB.LAX.ACME, CD |-OU=NYC | |_OU=IT | |_CN=ServerA | |-OU=LAX Trustee=UserA.NYC.ACME, B |_CN=ServerB
The same also goes for file system rights.
Remember that rights in Novell are additive, so if rights are given to both containers, groups and maybe even to objects, it could be hard to restrict rights with a single assignment. Be sure to check the effective rights to actually see what right a user has at the given context/directory. And use rights.exe (for file system rights) to trace back where the rights actually come from.
As far as iManager goes, you can just limit change the scope of where these users are to be able to fulfill its roles and tasks.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com