Lock and unlock through WebUI

Maybe I am missing it but is there a way to Lock and Unlock clients through the WebUI?

There is no menu option when looking at the device list or an individual device, but you can do it using the ā€˜Contentā€™ app by deploy Lock and Unlock actions that are in BES Support.

For those of you using WebUI, do you give all of your operators access to the BES Support site for the systems they administrate?

It seems like this would be necessary if you use lock states at all, otherwise you would have to rely on an unlock action during a defined maintenance window to allow actions issued by non-master operators in sites that do not override the lock state to run.

This is obviously by design, and may even be good practice, Iā€™m just curious how people use WebUI in environments where lock states are used.

1 Like

I copied these two actions (lock and unlock) to a custom site and only allow them to apply these action to the members in there.

Would you want all of your WebUI users to be able to lock/unlock devices they manage? Which types of users need this capability vs waiting for their actions to run once the maintenance window is reached?

This didnā€™t work btwā€¦ seems it only works from the BESSupport site.

Just the specific devices they manage. We control what devices specific users can manage through roles and computer subscription to those roles.

By default, only fixlets and tasks from the ā€œBES Supportā€ site will execute on a Locked endpoint (so the ā€œUnlockā€ fixlet can be run from that site only).

Thereā€™s an option to use the BESAdminTool to enable one additional custom site to run fixlets/tasks on Locked endpoints. If you donā€™t want to give operators rights to the BES Support site you could define a custom site to host a copy of the lock/unlock fixlets in this way.

:edit: a bit of detail at Multiple Locked Client Site Exemptions?

I donā€™t use WebUI though so Iā€™m not sure how that affects things.

I saw that ā€œfeatureā€ but the problem is that we DO want to have the servers in this Site to be locked on a daily basis (because of the use of maint windows). Itā€™s when we want the end-user to change the maint window or apply a emergency patch/action that we want them to have the ability to unlock/lock as they seem fit.

As I see it, you could either give the operators access to BES Support so they can run the default lock/unlock fixlets, or create an additional custom site and configure it to be exempt from action locking.

The servers can be subscribed to multiple sites, and you could give these operators read-only access to ā€œMy Local Support Siteā€. You could add the lock/unlock fixlets there.

If the concern is that giving your operators access to BES Support gives them too much content, you could limit the content you make available in ā€œMy Local Support Siteā€.

Is there a use case there that Iā€™m missing?

Our biggest use case is wanting to allow certain operators, such as security specialists / incident response, to take actions outside of maintenance windows, while everyone else would obey the lock state.

However, we donā€™t want those same security specialists to perform client upgrades or change client settings, or almost any of the other fixlets in the BES Support site. We do have a custom site that is allowed to override the lock state of endpoints, but again, with the exception of a very few select admins we do not want security specialists (and other non-master operators) to access most of the content in that site.

Effectively, we are in a situation where it would be beneficial to have a way for a few different groups to have access to a very limited number of fixlets that can run at any time (i.e. override the lock state) without having access to the BES Support site or the one designated override site. Supporting multiple override sites would be the cleanest solution as we could have one Incident Response site and one Security Specialist site each with different fixlets that could run at any time.

Can you elaborate on what you mean when you say ā€œMy Local Support Siteā€

Are you referring to ā€œan additional custom site and configure it to be exempt from action lockingā€ from your previous paragraph?

If so, that is cumbersome, at least in our case, as we have three different use cases (BES admins, incident response team, security specialists) who should not have access to the same content all in one site where all endpoints are subscribed. We havenā€™t been able to come up with a good way to do this yet, so for now we are effectively limited to having non-master operators obeying the lock state (which, in many ways, is by design, of course).

Thatā€™s exactly what I meant by ā€œMy Local Support Siteā€ - a custom site likely populated with a small subset of whatā€™s available from BES Support.

It is a challenging problem to be sure; the rights delegation model just isnā€™t very granular.

I donā€™t know that there are any real drivers though to limit the number of sites. Having a dedicated, small site with action lock override set shouldnā€™t add much overhead to the clients. At least, it shouldnā€™t be any more overhead than adding an operator, since every operator account creates a new site as well.

1 Like

Ok, this makes sense. So you donā€™t really want lock/unlock capability since that would open up the endpoints to any operatorā€™s actions, but just additional lock exempt site/content filters. Allowing multiple lock exempt sites has been in our backlog for a while, so maybe we can get it bumped up a bit to make the cut.

1 Like

Gotcha, sorry I misunderstood your use case there.

That is spot on; allowing multiple custom sites to override the lock state is exactly what we would prefer to do.

Having to unlock the endpoint might still be feasible, but certainly less desirable from an operations perspective.

Sounds like some other OPs have the same issue as me. Thanks for jumping in an clarifying!

1 Like