Some answers to your questions:
· Why it is required to have LIST permission on all data for set and run Active quotas? Why it is not working like any other backup or quota management software?
The SE services account should be a member of the local machine or domain administrators group as specified in the SE Admin guide. In the context of an administrator all pertinent rights will be present. SE has always had this minimum requirement.
Unlike other quota or backup software, StorageExec uses Realtime quota management. This requires that when the quota is introduced, that a handle can be made on the file area for the initial scan. Once the initial scan is made, monitoring is done through the file I/O system. The permission should be retained to facilitate management of the quota.
Basically, StorageExec is the only quota management software that can do realtime, therefore it will operate differently than any other software on the market.
· How can I forced active quoting to users data if they can easily disable it removing rights prom ACL?
As long as the SE services account is a local machine or domain administrator then users cant prevent SE from enforcing space quotas.
Even if the customer can remove the ACL, they can not remove the quota. Once set, the quota will still operate due to the fact it is I/O driver based. If the user removes the ACL, it will just prevent modification of the quota management policy, not enforcement.
· Why this nice reporting feature must have READ permission – no applicable in real secure environment?
Read should only be needed on reports where USER information is wanted, LIST should be sufficient otherwise. The reason again being that the permissions are needed, for example, to actually list the size of a file, READ is needed to get the owner of the file. This is essentially security, a user should not be able to bypass the set NTFS policies with a reporting tool. Also, the permissions should relate only to the logged in user, not to the service accounts.
· Is there any possibility how to fill our customer requirements via SE based on previously mentioned information?
If they can�t allow the SE services account to be a local machine administrator or domain administrator in the case of the EAO option then SE is not the product for them. If they can meet the requirements then SE will do the job adequately.
· Or it is already functionality of SE and we are only not able to configure it well?
It is to the degree that SE is a storage management utility and should be installed as and utilized by administrators. And from a reporting point of view, to provide non-administrators with a 'view' on a personal or group share, then the NTFS list permission is a minimum requirement as it would be illogical to circumvent the established security with a reporting tool.