Like other object types in ReportServer, users and groups are organized hierarchically in trees. The user tree can include the following object types.
New objects will be created in the user tree via the context menu of the folder node. When clicking on an object in the tree, the right part of the screen will display the properties of this object. The configurable properties vary with the object type.
The name and description fields are available for organisational units. Their name is displayed in the tree, the description field can include additional notes or comments. We will go into more detail explaining the tabs Permission management and User variables in the respective sections.
User objects will hold the personal data of the user. Beside the personal form of address, first and last name, they include the user name, e-mail address and, if applicable, the password. If a password has been manually entered in the Administration interface, it does not need to be changed by the user on the next login. The usual procedure to reset a password or set a password for the first time is to ''activate'' the user using the Activate button in the menu bar. A one-time password is then sent by e-mail to the user's email address. The user will then be prompted to enter a new password when logging in for the first time.
The guidelines regulating the generation of new passwords, or to which the password chosen by the user has to comply, can by adapted via the configuration of the PasswordPolicy. For further information on PasswordPolicy as well as on the various authentication procedures supported by ReportServer we refer to the configuration guide.
The section ''Account blocking'' allows to inhibit individual users from accessing the system. The block can be set either manually or automatically by setting a certain expiration date. Accounts which have been blocked automatically, e.g. by exceeding the permissible number of login attempts, are unblocked and reactivated here.
User groups are mainly used in connection with the permission management, and therefore, they will be discussed in detail under this issue. Groups provide the possibility to summarize users who are not located in the same branch of the user tree, and to treat them equally when assigning rights. Beside the name and description fields, the user group configuration page has three fields to manage the group members. In the Direct Members field, individual users can be added to the group. The field Members (via groups) allows to add all members of another group to this group. The effect is identical, as if the members of the subgroup had been added manually and individually to the group. The field Members (via organisational units) eventually enables to add entire branches of the user tree to a group. Here as well it is to be interpreted that all users given in the branch are direct members of the group.
Generic rights control access to global components and functions of ReportServer. Examples include the permission to log in to the system or to access the Administration section.
In addition to generic rights, object-related rights can be assigned. These permissions apply to ReportServer objects that are organized in tree-based structures, such as datasources, reports, or users. Unlike generic rights, object-related permissions support inheritance, which can significantly reduce administrative effort when managing large or complex permission hierarchies.
In ReportServer, permissions are managed using Access Control Lists (ACLs) and Access Control Entries (ACEs). An ACL exists for every object whose access can be restricted, including reports, datasources, folders, and other tree-based objects, as well as for each generic permission. Each ACL consists of a set of ACEs, where each ACE defines the following information:
When evaluating whether a user has a specific permission, ReportServer processes the associated Access Control Entries (ACEs) sequentially in the order in which they are defined.
For each ACE, ReportServer checks whether it applies to the user by evaluating the folk: if the folk is a group, the system checks whether the user is a member of that group; if the folk is an organizational unit, it is verified whether the user belongs to the corresponding subtree; if the folk is an individual user, the identities are compared directly.
If an ACE applies, its access type determines whether the permission is granted or denied. The first matching ACE is decisive. This means that the order of the ACEs is relevant. This means that if an earlier ACE denies a permission, the permission is denied even if a later ACE would grant the same permission. If no ACE applies to the user, the permission is not granted.
Consider the following example of an ACL consisting of three ACEs: the first denies read and write permissions to members of group A; the second grants read permission to members of group B; the third grants write permission to members of group C.
group A deny read write group B allow read group C allow write
To test if a user has the write right, ReportServer would first test whether the user is in group A. If so the right is denied and no more checks are performed. In case the user is not in group A, ReportServer would move to check the second ACE to find that it doesn't say anything about the read right. It then goes to the third ACE and tests if the user is in group C. If so, the right is granted. If the user is not in group C, the right is denied as it has not been explicitly granted. This also means, that any user which is not in group B or C would not have any rights on that particular object.
Also let us stress that ACEs are inspected in the order they are defined. This means if we change the above ACL to
group A deny read write group B allow read group C allow write group A allow read write
then still, any user that is in group A would not be granted read or write rights, since the check would stop after the first ACE.
Generic rights are configured in the Permission management module located in the Administration module. Here, the second column holds an entry for each generic permission, for example, there is an entry for every ReportServer section for which access can be controlled via generic rights. For each of these entries a single Access Control List is filed, the entries included in this list control the access to the respective function.
To manage the existing permissions, or to add new ones use the buttons Add/Remove. The configuration dialogue for this ACE will open by double clicking on an entry to edit its properties.
To edit generic rights (or object related rights, for that matter), beside the respective rights for the Generic Permission Management section, you require the permission "grant rights (g)" each for the object to which you want to assign permissions. In addition, you must own all the rights yourself that you want to assign.
In the following we discuss the various generic permissions. Note that the target is necessary for checking generic permissions with the haspermission terminal command described in Section 20.26. haspermission.
In addition to generic rights, permissions can be assigned at a fine-grained level to individual objects, such as reports, datasources, or users. For this purpose, object-related permissions also use Access Control Lists (ACLs).
Object-related permissions are managed directly on the respective object. For example, to manage the permissions of a report, navigate to the Report Management module and open the report. The permission management view is accessible via the tab.
Besides the ACE fields that are also available for generic rights, you can take advantage of the hierarchical structure of objects for object related rights. That is, you can decide if an ACE only applies to the object, whether it is inherited by all its descendants, or whether it applies to the current object and is inherited by all descendants.
Object rights can be assigned in the areas Reportmanager, Dashboard Library, Datasources, File System, and User management. In general, the right to read (r) allows users to see (resp. select) the object, the right to write (w) allows to make changes and the right to delete (d) allows users to remove the object. The execute (x) right controls whether a user can execute a report (resp. ReportServer Script). Note that it is not necessary to have read rights to execute. Finally, the grant rights (g) right gives a user the permission to grant rights to other users. Note that users can only grant rights that they themselves hold. Furthermore, they must have read rights for the folk (user, organisational unit or group) to whom they want to grant the right.
To check if a user holds an object related right, ReportServer first checks all ACEs that are assigned at the object in question and which apply to that object. If a decision cannot be made, ReportServer goes on to the parent object and there checks all ACEs which are marked to be inherited by descendants. This process is continued until a decision can be made or the root node has been processed. By default rights ar not granted. We consider the following example:
Object A
+--- Object B
+------ Object CIf a user is given read access for a folder (or any other object) but does not have read access for one of the parents of that object, then ReportServer will display the object as a virtual root in the topmost level.