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 need not 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. 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.
ReportServer principally distinguishes between two types of permissions. Generic rights are called those permissions which regulate the access to components or functions of ReportServer. Examples for generic rights are the basic right to login to the system, or to access the Admin section.
Beside the generic rights, object related rights can additionally be assigned. They always refer to ReportServer objects organized in tree based data structures such as datasources, reports, users, etc. Unlike generic rights, for the definition of object rights the inheritance of rights can be applied which can considerably reduce the administrative effort when dealing with large and complex user structures.
In ReportServer rights are assigned in form of Access Control Lists (ACL) and Access Control Entries (ACE). An ACL exists for each object for which the access is to be restricted that is an ACL exists for every report, datasource, folder,etc., but also for every generic right. An ACL then consists of a list of ACEs that hold the following information:
To test if a user has been granted a certain right ReportServer checks for each ACE (in the order they are defined) if the ACE applies to the user, i.e., if the user is part of the folk (i.e., if the folk is a group it is checked if the user is a member in this group, if the folk is an organisational unit, it is checked if the user is part of that sub-tree and if the folk is a user it is tested if the users are the same). If an ACE matches, the access type defines whether the right is granter or denied. This means, that even if an ACE later in the ACL grants a right, but an earlier one denies it, the right is not granted. If no ACE matches then the right is not granted. Consider the following example ACL consisting of three ACEs. The first denies the read and write right for members of group A. The second grants the read right to members of group B and the third grants the write right 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, it would first test weather 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.
Besides generic rights, rights can be assigned at a fine granular level down to specific objects (such as, reports, datasources, users, etc.). For such object related rights also ACLs are used. The management of object related rights can be found at the object in question, that is for a report, go to the report management module and access the report. The permission management view can be accessed 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.