Managing Helpdesk Security
Filed under:
Helpdesk Solution
Security
Submitted by ribak on 18 September, 2006 - 15:25.
Want to support security at the incident level? Use Helpdesk Data Macros to ensure that only the assigned worker is able to modify an incident. This cool solution by Richard Baker works well with minimal cost and support overhead.
Two Data Macro functions can be leveraged to accomplish a number of useful tasks. In particular, the PREVIOUSITEM and CURRENT_WORKER Data Macros can be used to manage access and update rights to an incident.
In the simple example screen presented below, I have created a validation rule that performs the following prior to saving the incident:
- Check if the NT ID is "Null"
- If true, this worker ID is actually a Queue, so do not perform any additional checks and allow the incident to be updated.
- If false, display the error message and prevent the update from occurring.
- Helpdesk saves the NT ID of the worker who last updated the incident. Use logic to check if the current worker's NT ID matches the previous value for NT ID.
- If not true, display the error message and prevent the update from occurring.
- If true, allow the update to continue.
- Use the <Advanced Condition> option to add this condition to the rule.
- If the incident is assigned to a queue, you may want to add additional logic using the AEXQUERY Data Macro to determine if the worker belongs to the queue, if so, allow the update to continue.
- You may also want to add specific NT ID's to allow updates, such as the Helpdesk Supervisor, IT Director or other senior IT manager with access privileges to the Helpdesk system.
(9 votes)
- Login or register to post comments
- 3648 reads
- Printer-friendly version
What about viewing....
How could we modify this so that, for example, only support staff for XX department can see the tickets for XX department?
If support staff for another department even tries to view tickets for XX department they get an error?
Any answer to this?
This is something we are looking to do. We are going to add a group of "Power Users" as workers to the HD, but only want them to have access and ability to view their specific queue. They do not need to see any sensitive material in the rest of the HD.
Custom consoles seems to be the answer
We are in the beginning process of determining the correct route – basically a separate instance (database) for each company or single instance (combined database)
The end result of the customization will depend upon our business needs, operational processes, security and technical requirements, and our ability to support the solution.
We can create a separate “instance” and forward tickets between systems; there are simple methods to do this via email and more advanced methods using web service calls.
Separate databases could increase the complexity of the installation, however, and require additional hardware (servers). If additional hardware is needed, additional SQL licenses will be needed (expensive).
Some ideas on the pro’s of each approach:
Pros of separate instance
-Enable you to build a very specialized application
-Separate database, workflow
-Security and policies can separate for each instance
Pros of one instance and “custom consoles”
-Integration; workflows tend to be cross functional
-New employee process may require IT, facilities, security, HR, Finance, etc.
-Separate database would create more complexity for compound and complex workflows
-One database, combined reporting
-Simple ticket routing; do not need to cross servers
-Lower admin costs (User and worker administration, Altiris, SQL server, hardware, backups, patching, etc.)
Advantage of custom consoles:
We could create a “custom” console for each specific group with the following:
-Limit view to the certain fields (category, status, comments)
-You can “turn off” fields very simply in any console
-Limit the worker and queue field to only display specific queue and related workers
-You can limit the queries that display fields to specific values
-Limit access to the “custom” console to the specific group by Active Directory credential
-Create separate notifications for each specific group
-Create rules to ensure that the specific groups are not able to update tickets that they do not own
There is no limit to the number of consoles, so different consoles could be created for different business functions. Custom consoles create a framework for future expansion rather than just a single-instance addition.
Security Role instead of assigned Worker
How would I modify this so that instead of only allowing the assigned worker to edit, only workers in the same Security Role (in our case, Security Role = department) can edit?