The Locked Endpoint Pain

Can anyone think of a solution to drag me out of the brain pain that I’m giving myself please?

By default - all my endpoints are locked

I need to find a way to unlock them as part of a MAG and then lock them at the end again.

Here’s what I’ve tried.

  • Added the Unlock - Content - Lock to a custom site that I’ve OK’d in the masthead for bypassing the lock status. Ran the whole lot as a MAG & Baseline and it failed with LOCKED

I tried it in the same component group and also as separate component groups - still the same :frowning:

I’m now at the point where I’m just thinking

  • Run “Unlock” from BES Support as a single action
    • Wait for the action to complete
    • Close job
  • Deploy content as needed with the lock at the end
    • Wait for the action to complete
    • Close job

Surely there has to be a cleaner way of doing this and I’m missing or forgetting about it :frowning:

Are you deploying the Unlock Fixlet as part of a baseline?
According to the documentation:

Baseline components are not exempt from action locking because they can come from different sites.

So that could be the reason your action is failing. You may need to push as a single fixlet action.

If you are familiar with the REST API, you could push the unlock-lock fixlets from the BES support site, this will require more engineering and development from your side but may be the safest and more automated approach.

Another option and an old trick is to use a registry key on the windows computer where the console is running on and “bypass” the lock status.
I would be careful with this option as once enabled you will be able to push all type of content.

1 Like

Yeah, it’s all API driven - I’ve tried to do the unlock-content-lock process as part of a MAG and a Baseline - doing both from the API with XML but they still come back locked.

I’ve went down the route of creating a seperate job to unlock the endpoints at the start of the API call then the content and lock as a new job

It’s not ideal though :frowning:

The Maintenance Window Wizard might be helpful, as it allows you to lock and unlock clients on a regular schedule.

1 Like

Yeah - sadly can’t use that as it’s kinda weird scheduling :frowning:

Two suggestions I have but not 100% both are feasible - I generally stay away from Locking as it is extremely “black-and-white” and even stops BFI, CISA KEV, etc scanning which technically can be software compliance violation if audit is to come and find out. Anyway:

  • See if you can take out the locking/unlocking to be controlled with policies outside of even BIgFix if possible - for example, if you have ServiceNow DataFlows or some kind of similar CMDB integration, you can define a field in it of start/end time for maintenance and from there create a policy that has the relevance of MaintStart <= now <= MaintEnd, run the unlock; if MaintStart < MaintEnd < now OR now < MaintStart < MaintEnd, run the lock policy.
  • Alternatively, is you can write your own “locking” mechanism depending of what you are aiming to do with “Locking”. For example, we run pretty much everything with custom fixlets; even the external fixlets are generally in custom baselines and ran via those instead of directly. As such, I have built ourselves couple of settings:
    • “Lock Tag” - comma-separated string of kewords
    • “Lock Start Time” - when the lock is starting
    • “Lock Duration”
      And have standard relevance that checks whether machine is within in those custom lock window and in fact different fixlets/baselines have fifferent log tag settings, so that I can lock only certain type of deployments and not necessarily “everything”. Of course, it’s not ideal or 100% secure because even though we have tasks for locking/unlocking if someone is keen enough he can figure out the settings and have those edit directly (not something we can stop) but in all honesty, I’d rather have that than impactful locking that just stops everything indiscriminately.

Hope it gives an idea.

@FatScottishGuy
You want to allow content from a custom site to be actionable on Locked machine, right?
You don’t want to unlock the machine and may get unwanted actions

Not quite - a mix of External and Custom via the API

Just to make sure you looked on the BES.xsd - the element “SkipLockedConstraint”?

https://software.bigfix.com/download/bes/110/util/BES11.0.3.82.xsd

2 Likes

I tested this in my lab just a few days ago, creating the XML for a custom action (i.e no fixlet) then posting it via API. The action was able to override the lock state

If you haven’t already configured one, you can also create 1 custom site whose contents are exempt from the lockstate, much the same as actions deployed from fixlets in BES Support will override lock state.

You can create a custom site and subscribe computers to it then via the BESAdmin tool you edit your masthead and add the site URL to be the site that is exempt from locking.

4 Likes

Great stuff! @SLB BigFix – unlocking a world of infinite possibilities :blush:

1 Like

Yeah i had this set but the problem is that the content I want to run is all in a baseline and baselines can’t bypass the lock :frowning:

I’ve been chatting behind the scenes on the topic as there may be a ‘hidden’ way to handle this but I’m still working on investigating if it can be done or not given the way that we create the baselines and run the content.

When I have a solution (providing no one else finds on on here before me) I’ll let you all know :slight_smile:

This will only work if you run the content from the console which we can’t do with this one :frowning:

I’ve “unlisted” this topic so it won’t appear in the new threads list for anyone who’s not already watching it.

While I don’t consider the locking-exempt action process a security issue (and “locking” is not an actual security control on the endpoint), this is an area where operators can do more harm than good if they don’t fully understand the ramifications of locking and lock-exempt.

And, @FatScottishGuy, Baselines can be run with the lock-exempt MIMEField, you just can’t use a SourcedFixletAction to send the baseline. From API, you have to retrieve the Baseline Components and bundlte them into a MultiActionGroup specifically.

2 Likes

Thanks for sharing that info @JasonWalker . I do admit, lock state does create some challenges and I’m starting to think of using other means. We used it primarily to manage patch maintenance windows via our inhouse developed scheduling platform which works well for patch delivery but once you then start to leverage the platform for other activities that should run on most systems, locked or not, but also avoid at all costs from touching immutable systems, one can run into very difficult challenges. I have also found that unless you come up with a process to tag action that override lock state, you have no visibility of what actions will or will not run on a locked device. Luckily I found a SQL approach that can show all the lock override actions.

Agree there are some definite complexities there.

When I needed to patch regularly I’d send my Patch actions with their own custom constraint, similar to “Run only when…” “In Maintenance Window”… is True

That way my patching was locked for schedules but BFI scans and ad-hoc actions were not locked. For normal operators you could make the default Action Settings have a custom constraint like that (it changes their Default but they could still remove the constraint when they take the action if they need to).

Dealing with truly immutable systems is painful though.