Skip to main content

ServiceNow's Key Management Framework - Resource Exchange Requests explained

Toby Comer

Again, I found myself confused at some of the documentation that ServiceNow had provided. Am I that dumb? Is it that bad? Honestly, probably a little bit of both.

While previously it was regarding the Oracle Cloud HCM - ServiceNow Integration Hub Spoke, this time it was the Key Management Framework. A customer had issues authenticating with their other tools after a clone down process, and we were on the hook to figure it out. ServiceNow Support had suggested running a Resource Exchange Request, and that's where we had most of our issues.

What is a Resource Exchange Request?

Since each instance uses a different encryption context, the data from Production can't be read by Dev or Test, until the Keys are exchanged from Prod (Source) to Dev or Test (Target).

If your instances are using the KMF, then you'll need to run this after each clone, if its not run automatically (based on the glide_encryption.auto_key_exchange.enabled property).

The steps in this article are missing some pertinent details, so this is my attempt to add some clarity.

Roles

  • You need the "sn_kmf.cryptographic_manager" role in order to see the links the left hand nav
    • You can't give yourself the "sn_kmf.cryptographic_manager" role unless you have the "sn_kmf.admin" role.
      • You can't give yourself the "sn_kmf.admin" role unless you have the "security_admin" role.
        • Once you have the "security_admin" role, you need to click on the "Key Management Administration" LHN link to bring you to this role assignment page
Key Management Administration in ServiceNow

Yes, even if you start off with security_admin, you still need to log in and out two more times.

Creating the Request (in the target instance)

  • Exchange Frequency: Choose ad-hoc
  • Crypto Specifications
    • We had 36 different ones. You can select them all on this one request form, but you do have to select them all individually.
    • Once you're done, use this client-side snippet so you can keep the values for another instance
      • copy(g_form.getValue("u_crypto_specification_list"))
  • Do NOT right-click save. I couldn't figure out why these weren't sending until getting on the phone with ServiceNow Support. When you are creating these records you HAVE to click "Submit Request".
  • Once the request is submitted, individual requests will be created for each specific Crypto Specifications.

Approving the Request (in the source instance)

  • If there are a lot of requests, it may take some time for them to show up in the source instance.
    • Some Crypto specifications won't be found in the source instance, and that's ok. Those won't need to be approved. Here you'll only focus on the ones that are "Pending Approval'.
    • Out of the 36 that we requested, only 15 were found in the source instance.
  • You'll need to approve each individual crypto specification.
  • Similarly, when you approve the request you need to change the Status to "Request Approved" manually, and then click "Update Request". DO NOT click Update.

Confirming the Request (in the target instance)

  • Once a request is approved in the source instance, you should see the request in the target instance also move to a status of Request Approved with a few minutes.
  • Out of the 15 requests that were approved, we had one request that gave a status of "Error on Local Instance". But when we re-requested it again, it was able to be sent and approved successfully.

Other Options

If a key exchange isn't a viable option for you or your customer, then you can also have the option it rekey during the clone instead. Read more here.