I’m posting this question in the WebUI forum as it touches a situation that will restrict our usage of WebUI.
Would it be possible to either have more than 1 custom site defined as exempt from client lock state or, if not, would it be possible to increase the WebUI restrictions via role permissions so that you can grant access to content on both site and a secondary criteria, eg fixlet category? We’re using the client lock state to prevent business critical systems from running actions outside of controlled maintenance windows and we then have a custom site that we include as exempt from lock restriction in our masthead. Our custom site contains numerous fixlets as some actions do need to run on locked machines. We are very interested in using WebUI to delegate certain tasks to personal that have no Bigfix experience but as we have at least 2 separate groups that need to run actions on locked machines, we cannot allow them both access to all content in our current lock state exempt custom site. Preferably we would like to have separate custom sites for these groups so the fixlets they have access to are all contained in 1 central location and access gained role permissions, then have 2 or possibly more custom sites with very limited content available that can be deployed and executed on locked clients.
And to add to the discussion; we have investigated the possibility of using site subscriptions instead of lock states to ensure machines are not relevant for content that should not run, but this then eliminates a very key feature of the entire platform, namely visibility.
As an example:
Business critical systems for groups A and B are both subscribed to the relevant Patches for OS site, and while in a locked state no content can run on machines in these groups.
We want to give operators from both group A and B access through WebUI to change the lock state on machines subscribed to their respective operator sites so that they can choose when to run content manually without having to either physically touch their endpoints or remotely script something outside of BigFix. Since their operator sites are not in the exempt custom site for our installation, however, they are unable to perform this relatively simple task.
We also do not want to give said operators access to the currently exempt custom site as said site contains several fixlets they should not be able to run.
Without the ability for multiple sites to override the lockstate on a system we run into the issue of having to engineer other solutions; it’s possible to circumvent this problem by using registry keys that local endpoint admins can change which will then trigger an unlock, but that requires access to the system which is either difficult or impractical.
As per the above, the best approach for my use would be to allow multiple sites to override the lockstate. If this is not possible, then another option would be to allow operators access to the Unlock actions in BES Support through WebUI (as long as that doesn’t require master operator access). Another possible option might be to allow certain fixlets with specific categories to be available across sites, though this is mostly speculation on my part as I’m not sure how the backend infrastructure works.
Ultimately, the current implementation of WebUI unfortunately doesn’t quite meet our needs as we’d like to delegate access to more junior operators, but the inability to change the lockstate of a machine without being a member of the currently excluded custom site significantly restricts our ability to do so effectively.
Rob & Martin, thank you for the feature request. We have started discussions around the role based permissions model which can be used to address these requests. We will reach out to you to learn more and would love to get your feedback on the design we have in mind. Keep the feature requests coming!