Possible to blacklist agent connectivity to a system from within AWA?

[Eric Felker]

As long as network connectivity is possible, any agent that reaches out to an AWA system is allowed access and consumes a license. Is it possible to black list agents by IP or hostname or agent object name from the Automic side, that would prohibit an agent from successfully connecting to a system? Is there a way to do this to large groups of agents at a time (ideally not by writing Java code using API, although I figure that would be possible).

We are looking to reign in old agents that have a habit of coming back online because of Service Manager configuration, and would likely be easier to do centrally (if possible) than going out to the many remote hosts.

Thx-
Eric

[Pete Wirfs]

I wonder if withdrawing authentication is a permanent way to disconnect an agent, or if it just renews the next chance it gets?

https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/12.3/Automic%20Automation%20Guides/help.htm#_Common/Security/Security_Hardening_WithdrawAuthAgents.htm

------------------------------
Pete
------------------------------

[Alain Moisy]

I can see a few options possible :

1 - List all agents that needs to be stopped (a variable object) then have an event that regularly checks if those agents are active. If yes, stop them.
This is not solving the problem permanently, just try to avoid use of more licence than necessary.

2 - Define a net area specific for those agents to be able to select them easily with an SQLI variable and same as above, as soon as they are activated, stop them.

3 - Use the command line of the Service Manager to modify the automatic start of the agent when the service manager starts  (ucybsmcl -c SET_DATA AutoStart 0 ....) . This will modify the *.smc file on the target machine to avoid an automatic start of the agent when the service manager is started. It doesn't prohibit a manual action or a command line action to start the agent but it can reduce the number of unwanted start of agents. Use option 1 or 2 to stop manually started agents or those who would have been missed in the modification process ....

Now the best would be to remove the service manager if you do not want to have an agent running on the target ever.

Regards.

Alain

[Carsten Schmitz]

​We know that problem.

For us, a third party is in charge of installing agents, and if they install a gazillion agents with a script that has a faulty loop, or change the agent name arround a lot, that possibly*) takes up many licenses - eventhough the agents are never allowed to run any jobs, being not authorized in client 0 by the admin.

I say possibly because it did count as using a license in the old UI when there was still a license counter. On the other hand, I have been told by Automic that the license report tool that some (not all) of us have to use only counts agents if they executed at least one job, so agents that never were authorized by the admin would not consume licenses by that way of thinking. It's really not well designed or very clear in my view.

If you subscribe to the former way of thinking, yes, every agent that connects eats a license and a disgruntled employee with packet sniffer/replay skills can screw over your licensing audits.

I don't think the admin can truly fully prevent this, at least I have, fwiw, not found a good way.

You could run an SQL statement (SQL variable or some such) that finds agents without permissions (they come without R/W/X permissions in client 0, and thus while eating licenses, can't execute anything). You can look at table HACL, it has the read/write/execute flags (one or zero), and you need to join it against OH for all OH objects of OH_TYPE='HOST'. Then you can periodically delete those rogue agents (see what I did there?) from client 0.

Ultimately though, I think this is more of a legal issue. Hence, I suggest talk to your key account manager, get assurances on how precisely your licenses are meassured, and ideally have them clarify that a license is only consumed once the agent actually gets authorized (R/W/X permissions in client 0) by the admin. That way, you are safe and that's the way it should have been done from the start.

Hth,

[Carsten Schmitz]

Oh, I just thought of one other way:

You could of course block the CP ports on your​ engine machine (iptables, Windows firewall, some such) and only open up ports for any new agents you want to have connecting :)

[Eric Felker]

Thank you for all the thoughtful replies. While I was hoping there was simply a toggle somewhere to "disable" an agent on the platform side, you've provided some other ideas for us to think about. Potentially revoking network access via iptables was one idea we'd considered, but felt heavy handed if there was another way. But that may ultimately be the route we take. Ideally we'll end up going with a solution that stops the connection and license consumption out right, rather than reactively looking for agents to disconnect at regular intervals.

Thanks!
Eric

[Carsten Schmitz]

Hey Eric,

You're welcome, thanks for the response.

Best,
Carsten​