Problem

A Forum reader recently asked:

"In the days of iManager 1.2.2, if you logged in the iManager as a normal user you saw nothing unless specifically granted roles and tasks (as far as I remember).

I tried logging into the above version of iManager (2.6) as a normal user and was shocked to see that the default mode is 'unrestricted access'. This appears to enable any user to browse all the roles and tasks, only not change anything. I have an issue with this as there are certain data that ordinary users should not readily have access to, like the specifics of our password policy config in 'password policies', or indeed browsing other users attributes in 'modify user', to name but a couple.

The term 'unrestricted access' would imply all sorts of powers and is an unfortunate term. I am unhappy that this is the default state in the modern iManager world and that it looks like turning on RBS, with all its complexities is the only way of restricting this info. Surely action should only have to be taken to reveal info from the default state (as in the old iManager world?), not the other way round."

And here's the response from Aaron Burgemeister ...

Solution

iManager, without RBS, does not restrict a user from getting into the roles/tasks as far as eDirectory rights will permit. The nature of iManager (and all of the management tools) is that rights are all granted via eDirectory. Without this setting, if you wanted to have iManager on two servers you'd need to make sure each instance of
iManager knew that admin was indeed an admin separately - and that would be a bit of a nightmare to administer. On the positive side of things, as it is curerntly implemented, a normal user cannot do anything in the tree they could not do otherwise by virtue of just being in iManager. Sure, they can see what roles/tasks are there - but you control those anyway by adding or removing plugins from iManager. Also, restricting access to iManager could be enforced, should you choose, by blocking address ranges. Auditing iManager is also possible so you can see who is getting on there.

With all this said, I don't grasp why knowing the password policy's rules is a horrible thing. If a user who cannot access iManager wants to see their password policy's rules, they just need to change their password via an NMAS-enabled client and they'll be shown what their password must comply to. That's obviously a good thing, so they don't try using 'password' over and over when they need 10 characters and something numeric. Also, the clients that do these password changes need to be able to see these same rules, so they can limit a user's password-set attempts or at least show the rules as they are stated. Having all of this information hidden for the sake of "security" falls into the "security by obscurity" realm of protection, which has been shown to be an invalid way to protect resources (see a list of windows cracks and exploits for evidence).

Now eDirectory has always had some attributes set to be [Public Read] in schema which means that, barring an IRF, that attribute can be read. These can be removed, but you definitely should test things first. Some cases make sense for removing this schema flag, and others are overkill - but customers have, in the past, successfully removed this flag and kept running. Doing so requires some modifications to the way things are done. For example, contextless login needs rights to do a contextless login search for a user's context; be sure those are available to an LDAP proxy user. It can still work just fine with the necessary provisions.

In the case of the Password Policies, the [Public] user is explicitly given rights to the Password Policies container under Security, and those Read/Compare rights are inheritable. You could remove those, but I would expect it will cause problems when others try to change passwords, unless you somehow assign the necessary rights out again. No matter what happens on the client side with accessing these attributes, the server will not allow an invalid password to be used. So, removing these without testing first could leave your users trying to set invalid passwords over and over and could lead to Helpdesk calls.

If you really want to hide all the information in eDirectory, iManager isn't the way you'll need to do it - but changing rights is. Doing so will take some time, and the benefits may still be limited. Even if you implement RBS in your environment, there's no (effective, fool-proof) way to prevent your users from using Mobile iManager in Unrestricted Mode. In this case, they still cannot do anything without rights, but they'll see the roles/tasks you had otherwise blocked on the server versions of iManager.