To homepage To homepage
Solved

application Id isn't changing after new settings

brian.wijnings
Rank
Badge

I have made a new app registration in Azure for TimeXtender. 

Provide the rights exactlly as the old app registration but the secret is expired.

Error in TX : AADSTS7000222: The provided client secret keys for app 'OLD_APP_ID' are expired.

I filled in the datasource and global enviorment the NEW_APP_ID but the error still is there. 

Restarted the ODX server, removed the pipelines but still same issue. 

How can i force that it will use the new application ID becaused I changed it on the places it is used. (Also with the new secret ofcourse)

icon

Best answer by Christian Hauggaard 8 June 2023, 14:01

View original

11 replies

Christian Hauggaard
Rank
Userlevel 6
Badge +5

Hi @brian.wijnings which data source are you using? Are you using OAuth authentication? If so please try to authorize OAuth again in the data source

 

brian.wijnings
Rank
Badge

Thanks for your reply. 

It was the: 

And the: 

Saw the app Id is working now only now a 403(Response status code does not indicate success

message and checked the security from following article on datalake and ADF: 

https://legacysupport.timextender.com/hc/en-us/articles/360029359431

If you have any suggestions they are welcome. 

 

Christian Hauggaard
Rank
Userlevel 6
Badge +5

Thanks for confirming. If you compare the old app registration and the new one, are there any differences between the two? What was the reason for creating a new app registration?

Do you have the data lake permission for the app registration API permissions? Have you given the app owner access to the ADF resource?

 

brian.wijnings
Rank
Badge

No no difference, the owner is set to a different user and I'm not able to adjust it. that is why we create a new one. (Future this will be a group instead of a person ;) ) 

Rights are the same on Datalake :

 

Both owner on the datalake

On ADF:

They are contributor both, as stated in https://legacysupport.timextender.com/hc/en-us/articles/360029359431

No API permissions have been set in Both Apps. 

 

 

Christian Hauggaard
Rank
Userlevel 6
Badge +5

Ok thanks for confirming. Which version of TimeXtender are you using?

brian.wijnings
Rank
Badge

We are using TX version 20.10.24.64 at the moment!

Christian Hauggaard
Rank
Userlevel 6
Badge +5

OK. I managed to reproduce the issue for editing the ODX ADLS storage. It seems it is due to the ACL on the existing container. The solution is to navigate to the container being used for ODX storage and then select manage ACL for this container.

Then add a principal for the new app registration 

Finally, check Read, Write and Execute for the new principal and click Save.

 

brian.wijnings
Rank
Badge

Thanks Christian, This was preventing the connection indeed! 

 

brian.wijnings
Rank
Badge

@Christian Hauggaard  maybe to soon The datalake connection can be tested now. 

Syncing with the 

Still not working.. get the forbidden error again. 

Maybe this takes a while but can you think of somthing else ? 

 

Christian Hauggaard
Rank
Userlevel 6
Badge +5

@brian.wijnings Can you please share the full error message? Is it the same as before i.e. “403(Response status code does not indicate success”? Have you tried synchronizing the data source? Does it fail on synchronize or transfer?

I am unable to reproduce this error, however I am using a newer version of TimeXtender (20.10.42), and therefore a newer version of the Azure Data Factory - SQL Server provider. 

In order to troubleshoot further, if you create a new data source does it work then?

brian.wijnings
Rank
Badge

I have managed to get access to the 'old’ app registration. This was my fix. 

The ACL on the datalake container was the first part but also below you have to change it. 

I found out that the security of an app registration has a hudge impact to change. 

For now I fixed it with the old app registration. 

Thanks for your help so far. 

 

Creating an new datasource i didn't try, is also a big enviorment and the ODX is for Production and Development as well. But good suggestion,

And yes it fails on sync and transfer with the same error I think this is just the ACL or security that is somewhere set to the old app registration instead of the new, I found out that even on folder level it is different than on container level.. 

Again thanks for now!

Reply


Terms and ConditionsCookie settings