Administered Computers not reflecting change in operator role

It appears that we have encountered a situation where computers don’t seem to be acknowledging that an operator’s permissions have been removed, and I’m trying to figure out if it’s an “us” thing or a design problem. Here’s the scenario:

  1. Operator was subscribed to 100,000+ computers through a role role membership where the role was assigned to the site
  2. Operator was removed from all roles, and placed in to a single new role that is assigned only to 20 clients, but has create action and create content set to “yes” through that role
  3. When looking at the operator’s object in the BigFix console under the “Administered Computers(##)” tab, that operator still sees 12,000+ computers.
  4. Most of those 12,000 computers are reporting in and are confirmed functional
  5. When that operator takes an action against one of the computer objects listed under “Administered Computers” that the operator should no longer derive management rights to, they are able to take that action successfully.

We have in the past discussed the options of deleting the operator object to flush their site, and deleting the computer object from the database to force a “reset” of that object’s subscriptions. Both of those solutions are problematic and here’s why:

  1. We had a change in site subscription relevance a while back that briefly (like an hour) caused an unknown number of operators to gain management rights to an unknown number of computers. To be sure we address all potential management scope violations, we would have to essentially delete all operator accounts (we have over 200 operators - and yes we’re aware that 200+ operators is bad), or at the very least try to find a way to identify and report on what operators have management of machines they shouldn’t.
  2. We have operators who have inappropriate management of over 10,000+ computers, and we have no way currently of identifying which operators have inappropriate management rights to which computer objects, meaning we would potentially have to remove all computers (or at least all high-value computers).

Neither of these two options are very good. So a couple of questions that come to mind are:

  1. Can we not send SOME sort of action to clients that would force them to re-evaluate which operators are able to manage them based on CURRENT role assignments/subscriptions (or whatever IBM calls it) without forcing the client to do a full reset?
  2. Is this a BigFix problem or an “us” problem? The reason I ask this is because at this point it would appear to me that we have to assume that ANY operator in BigFix has the potential to send actions to systems that they wouldn’t normally have any management or oversight to. This seems like a pretty fundamental flaw. I understand that the console was designed with an additive permission model but fundamentally, if an operator’s permissions are explicitly removed, they should be removed. There does not appear to be any logic that I can come up with that would make this situation something any customer would ever want for any reason at all. Also, I can’t come up with any logic that actually causes this situation (i.e. we’re not applying some goofy relevance that says “don’t reconsider management delegation” that we would’ve applied to ourselves, thereby shooting ourselves in the feet) which leads me to wonder if it’s a malfunction in our environment and not a design element.

Related: Managed computers by operator

I hope to take a closer look at this soon and get back to you.

So, to answer the question we’re using groups to define how the role is assigned for the most part. Most (if not all) of the machines that are lingering in the operator’s list of managed computers are not new machines. Is your statement about not applying after the 10th time based on the few places “active count of action <= 10)” is found in the fxf files?

I have a customer with the same type of issue was there any resolution to this problem?