Database Reference
In-Depth Information
How it works...
The recipe shows how to modify an existing report to take advantage of the role-based se-
curity model available and applied to the default SCCM reports.
The custom reports you create do not automatically inherit the role-based model. The ex-
planation of each section of the recipe is as follows:
•
Get the report user SID as a parameter
: This first section provides the steps to
capture the user's logon token as a dynamic parameter at the time the report is run.
This requires an SSRS assembly that you can define in the report properties.
•
Create the Configuration Manager administrative users dataset
: The second
part of the recipe builds a dataset (query) that retrieves the details of the adminis-
trative users in the database. This information is what defines the user access to ob-
jects in SCCM as defined in the role-based security. The function uses the user
token and converts it into the SCCM admin value as the
USERSIDs
value. The
USERSIDs
value is what is expected in the final part of the recipe when you con-
vert the datasets to use the role-based views. The final part of this second section
provides you with the steps to save the role-based parameters and the admin data-
sets using the option to publish report parts.
•
Change the report datasets to role-based ones
: The final section of the recipe
modifies the datasets you use to retrieve the report data to use the role-based func-
tion (
fn_rbac
). You can change the leading
V
in the view name to
fn_rbac
,
and
(@UserSIDs)
is the parameter that the function expects; you will add this to
the end of the view you reference in the datasets.
The default reports leverage the
fn_rbac
views and also define the prerequisites of
fn_rbac
by creating the parameters and the admin dataset. This recipe ensures that you
have a process to apply the SCCM role-based security to your reports, based on how you
have the delegation and scope applied to administrative users.
