Is there a method to determine which ACC API key is used by a particular agent?

dougw
Tera Expert

I have 3 'organizations,' each with a different ACC API key, with agents that connect to the same MID Server.  I am looking for a way to determine which Agents are with which organization and as far as I can tell the only solid way to figure that out is to see which API key they use.

 

For clarity, I don't need to actually decrypt the API key.

 

I have no tags I can use, I cannot filter by IP address due to overlapping subnets, there's no naming convention I can reliably work off of, and looking at the installation package isn't going to help - I have to get the information from the instance somehow.

 

Any thoughts?

7 REPLIES 7

anand-bhosle
Tera Guru

Hi @dougw ,

 

If i am not wrong, the out-of-the-box "ecc_agent" schema only tracks the handshake certificate (public_key), not the original API key. May be extending "ecc_agent" table and capturing the handshake payload, you create the link and the report on?
The system table "mid_webserver_api_key_credentials" is the one table you will find ACC key's but it has no related to "ecc_agent" table though.

 

Yep, already looked at mid_webserver_api_key_credentials.

 

I have to wonder - when an ACC API key expires, or is about to expire and new keys are being pushed out, how do folks know which agents are using the old key and which are using the new key?  I have an enormous environment, dozens of business units, and rotating API keys isn't going to happen overnight, or even in a single week.

True. @dougw 

Out of the box, ServiceNow doesn’t track “which ACC API key” each agent is currently using—only the encrypted certificate [public_key] on the ECC Agent record. To safely rotate keys over days or weeks, {what I think, would work} you need to explicitly capture each agent’s handshake and tie it back to the API key record.



When an ACC agent (re)connects, it writes an ECC Queue record whose payload includes the API key ID used. runninga a Business Rule on the ecc_agent table to parse that handshake, and by storing the key reference...!

I'm not sure I'd use a business rule for that - not that it doesn't sound like a good idea, I just have something else in mind for now - but I am, in fact, looking at the ecc queue already.  Thank you for confirming that's where I should be looking!!

 

If that table plays out for me I'll mark your reply as a solution.

 

/You beat some SNC buddies lol, they were stumped