Highlighted
2 Bronze

Unable to retrieve the secret key for the specified user while using EsuApiLib

Jump to solution

I am trying to connect to our Atmos host, but I am always receiving:

EsuApiLib.EsuException: Unable to retrieve the secret key for the specified user.

I'm pretty confident I'm setting up my connection correctly by specifying subtenant id / uid.  For example, from my screens below:

SubtenantMgtPage.png

My code would be (tried both ports 80 and 443, same result):

  var api = new EsuApiLib.Rest.EsuRestApi("myUrl", 80, "MySubtenantID/MyUID", "mySharedSecret");

I confirmed that the correct headers are being sent, using Fiddler:

FiddlerLoginFail.png

Any ideas why my token ID would not be accepted?

Labels (1)
0 Kudos
Reply
1 Solution

Accepted Solutions
Highlighted
3 Argentum

Re: Unable to retrieve the secret key for the specified user while using EsuApiLib

Jump to solution

At a high level, yes, it looks like you're doing everything correctly.

This error message is very explicit and means that Atmos asked the LockBox whether it had a key for your subtenantid/uid and it said no (user does not exist).  A couple things to try:

1) Double check subtenantID and UID.  They are case sensitive.

2) Regenerate secret and try again.

3) If you have multiple tenants, make sure your tenant is assigned to the access node(s) you're hitting.  In this case, the response said that you connected to stlatmos-is1-001.

4) I've also seen this happen when customers have multiple environments (e.g. PROD / TEST / DEV) and accidentally connect to the incorrect environment.

If none of those help, you should open a support ticket to troubleshoot any issues with the subtenant and/or lockbox.

View solution in original post

0 Kudos
Reply
4 Replies
Highlighted
3 Argentum

Re: Unable to retrieve the secret key for the specified user while using EsuApiLib

Jump to solution

At a high level, yes, it looks like you're doing everything correctly.

This error message is very explicit and means that Atmos asked the LockBox whether it had a key for your subtenantid/uid and it said no (user does not exist).  A couple things to try:

1) Double check subtenantID and UID.  They are case sensitive.

2) Regenerate secret and try again.

3) If you have multiple tenants, make sure your tenant is assigned to the access node(s) you're hitting.  In this case, the response said that you connected to stlatmos-is1-001.

4) I've also seen this happen when customers have multiple environments (e.g. PROD / TEST / DEV) and accidentally connect to the incorrect environment.

If none of those help, you should open a support ticket to troubleshoot any issues with the subtenant and/or lockbox.

View solution in original post

0 Kudos
Reply
Highlighted
2 Bronze

Re: Unable to retrieve the secret key for the specified user while using EsuApiLib

Jump to solution

I've checked over subtenant ID and UID, and can't find any issues there.  I've copied-and-pasted them straight from the subtenant page displayed above on the admin portal, but still no luck.

I just tried regenerating the secret, but that didn't help in my case.

We are just setting up Atmos here, and I believe we only have the one node.  Connecting to stlamos-is1-001 should be correct.  That is the same url to which I can connect to the admin page.

For the fourth item, how would I check if we had multiple environments?  Could there be multiple environment setup on the same host url?

0 Kudos
Reply
Highlighted
3 Argentum

Re: Unable to retrieve the secret key for the specified user while using EsuApiLib

Jump to solution

No, you generally could not have multiple environments on one URL unless you had a misconfigured load balancer.

At this point, it seems you're doing everything correctly so something must be wrong with the Atmos installation.  I would contact support for further troubleshooting.

0 Kudos
Reply
Highlighted
2 Bronze

Re: Unable to retrieve the secret key for the specified user while using EsuApiLib

Jump to solution

Working with our local host administrator, I uncovered some more detail.  It looks like the 3rd point from your response was our issue.  We had 4 nodes setup, and although I could access the Tenant Administration Console for my tenant from 001, it was setup connected only to 003 and 004.

That detail was not visible through the Tenant Administration Console (to which I have a logon) but only through the System Administration Console (to which I did not have a logon).

So, my connection worked when I explicitly pointed the host to 003 or 004.  Now our next issue will be coming up with a single load balancing URL so the host nodes are transparent to the consuming app.

Thanks!

Reply