We have odata connections in Excel that have been working fine for a long time but all of the sudden aren’t connecting. It’s a little fuzzy the sequence of events because they were working with basic auth, but then switched to Azure AD auth. However it works fine on my account with Azure but some other users get this error. It’s not a user permissions thing since it works for those users under basic auth. Ideas?
1 Like
Complete guess here but Azure AD uses a token that needs to be renewed every so often. If it works for you but not others I would suspect their tokens expired and they can’t (for some reason) be renewed.
2 Likes
Yeah I can’t do it either I get the same problem. Is because the Azure AD token needs to be signed with the Epicor client (which Excel isn’t going to do)
This should never work with Azure AD. Are you sure that “it works fine with your account” in Azure?
I just did a trace network trace while trying to connect and basically when the call is passed from Excel it sends a token but that token isn’t from the Epicor Client Application in Azure so it isn’t a valid “Epicor Token”
1 Like
Well I thought it was working on my account but maybe it still had basic credentials cached from a long time ago. But you’re right, if I force SSO then I get the same error on my account which is actually progress, now I can stop thinking its user-specific.
So there is no solution to this?
No there isn’t. In order to authentication with Azure AD you need to use an authorized client
When you setup Azure AD the first thing you did is go into your Azure portal and created an “App” which generated a Client ID and Secret and a bunch of other things. Which you then inserted into Azure AD Settings in Epicor
This tells Epicor that if they receive a token that has been signed with the Private Key matching the Client ID’s here
Then they have “proven” to have access to your Private Azure tenant and thus are “authorized” to use Epicor. Then they decode the Auzre token which includes your email address and use that to lookup the External Login that matches that in User Account Maintenance and then they generate an Epicor JWT which they use to authenticate any further requests.
That token lasts about 30 mins, after which they once again grab your Azure token and do this dance all over again. Excel doesn’t have a way for you to give it the Epicor “App” Client ID for it to authenticate instead Excel has its own “ID” to authenticate against Azure AD, however that ID doesn’t match the one that Epicor expects so the token it generates isn’t valid.
1 Like
Ok, makes sense but . . . not happy about it. So our choices are, don’t use odata, or allow basic auth to continue.
1 Like
Yes, but to be clear this isn’t an Epicor limitation. Excel is choosing to do their authentication with a hardcoded “Microsoft Only” client ID that you have no control over. If Epicor were to allow that ID to generate valid Epicor tokens then any bumm off the street with access to Excel and Azure could generate a “valid” authentication token that would let them get data out of your system
Granted they’d have to create an Azur ID with your matching email address but still a huge security problem. Excel should allow you (or at least your System ADmins) to set / reset their Client ID to be unique to you and your company then you could use the same as Epicor.
3 Likes