Problem with SE 5.3 active quota & advanced reporting

[Stepan_Fikr]

Case scenario based on the customer environment:

18 servers with MS Windows Server 2003 EE (no SP1) clustered (MSCS and some EMC Geo-Clusters) environment where is implemented StorageExec 5.3 (SE) with Enterprise Administration Options and Advanced Reporting Options. All prerequisites for extending AD schema and configuring SE for a clustered environment were fulfilled. Installation passed under special account with domain admin rights. Services aka FileScreen Server and Quota Advisor Server runs account with domain admin rights. There are about 1400 users with home directories and special directories dedicated for each company Department with high amount of users.

Due to customer internal security policy only a user is owner of its HOME directory where has full control rights and any other account could not be set up for this folder. And here is stumbling-block. SE can't apply the active quota on the home directory only passive is used without appropriate right permission (LIST). Enhanced reporting from such affected directories doesn't work too (requires READ right). I know about some notice mentioned in administration guide regarding to rights on directories but customer security policy is set that way.

So, when I summarize it, in fact there are two technical problems:

A) Active quota requires LIST permission for account setting Quotas – what is a security Leak. This is not as bad as next problem with reporting, because LIST permission do not allow real access to sensitive data and is required only for Administrator setting this quota – and it should be trustworthy person… Real problem is with philosophy of Quota management. From our point of view Quota management software must be tool of restriction and it is not Veritas SE, if user can easily elude it removing permission prom ACL!

B) Worse situation in security point of view is with enhanced Reporting. For running ad-hock reports (wanted by all Department Managers) we have to grant them READ permission for all users and departments’ data, what cannot be done because of security policy. Fact is, that strong reporting capabilities were one of major arguments for choosing SE – but it is now unusable!



What we can't understand is why typical backup software from various vendor (such as Backup Exec) is able to list in console and backup objects without any ACL rights to them (calling specialized API for Backups using Privilege Backup and Restore files – funny is that it have to be granted for SE services too) and SE isn't able to use the same nature.

Next idea is, why quota solutions integrated in Windows 2003 (what we think is OEM “light version” of Veritas SE) works well without special LIST permissions on data, but Full and paid version have this limitation?



So our questions are:

· 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?

· How can I forced active quoting to users data if they can easily disable it removing rights prom ACL?

· Why this nice reporting feature must have READ permission – no applicable in real secure environment?

· Is there any possibility how to fill our customer requirements via SE based on previously mentioned information?

· Or it is already functionality of SE and we are only not able to configure it well?

[Svein_Olsen]

Hello!

I totally agree with you.
Anyone have some answers or solutions on this.

SEOlsen

[P_H]

Stepan,

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.