Osman Posted February 7, 2024 Posted February 7, 2024 Afternoon All, A bit of a weird one. The Azure Import for users has been working happily for some time now. However, over the last month or two the process is falling on the Scheduled Task and the content of the log file is: 2024/02/07 14:08:15 [MESSAGE] ---- Azure Import Utility v4.1.1 ---- 2024/02/07 14:08:15 [MESSAGE] Flag - config goAzure2HUserImport 2024/02/07 14:08:15 [MESSAGE] Flag - logprefix 2024/02/07 14:08:15 [MESSAGE] Flag - dryrun false 2024/02/07 14:08:15 [MESSAGE] Flag - instanceid 2024/02/07 14:08:15 [MESSAGE] Flag - apitimeout 60 2024/02/07 14:08:15 [MESSAGE] Flag - workers 1 2024/02/07 14:08:15 [MESSAGE] Flag - forcerun true 2024/02/07 14:08:15 [WARN] Current version 4.1.1 (patch) is greater than the latest release version on Github 4.2.0 2024/02/07 14:08:15 [MESSAGE] Loading KeySafe Authentication Data: 13 However, if I run this directly from the command line, which in essence is exactly the same thing, it works without issue. Any ideas? Thanks Osman
Steve Giller Posted February 7, 2024 Posted February 7, 2024 15 minutes ago, Osman said: However, if I run this directly from the command line Is the scheduled task running in the context of your Windows account?
Osman Posted February 7, 2024 Author Posted February 7, 2024 Hi Steve, No, it is running as a Service Account created explicitly for this task. From the perspective of setup of the Scheduled Task, nothing has changed. Thanks
SamS Posted February 7, 2024 Posted February 7, 2024 @Osman, The authentication details (Instance ID & API Key) is stored in the import.cfg file that is created/stored with the .exe. Only the WINDOWS account which CREATED the import.cfg has access to the details it contains! IF you are running the .exe in YOUR account and all works, then that would explain why the Service Account can't get the info out. Use "Run As..." or "runas" with the service account to set up the import.cfg which the Service Account will use (under the Task Scheduler)
Osman Posted February 7, 2024 Author Posted February 7, 2024 Hi Sam, Apologies if I didn't clarify. Both the Scheduled Task and the manual running of the import are both being conducted in the context of the service account. Thanks Osman
SamS Posted February 7, 2024 Posted February 7, 2024 @Osman then I frankly don't know what the issue might be. From the error message it appears that your import utility is not self-updating (because your version seems newer than what is on github) - you could try the new 4.2.0 exe and see whether that works (not that I can see anything in that particular release which would make a difference in this particular issue).
Osman Posted February 8, 2024 Author Posted February 8, 2024 Hi Sam, I suspect the version check logic is broken, as I am reasonably certain 4.1.1 is an older version than 4.2.o, or at least it should be. Will give 4.2.0 a go and will report back. Thanks Osman
Osman Posted February 8, 2024 Author Posted February 8, 2024 Have downloaded 4.2.0 and given it a go, log file now looks like this: 2024/02/08 09:09:53 [WARN] Current version 4.2.0 (patch) is greater than or equal to the latest release version on Github 4.2.0 2024/02/08 09:09:53 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. Thanks
Osman Posted February 13, 2024 Author Posted February 13, 2024 Afternoon All, Any further thoughts on this as it has consistently failed again for the last week and only manual triggering has worked? Thanks Osman
Osman Posted February 26, 2024 Author Posted February 26, 2024 Afternoon All, I am still seeing the same error as posted on the 8th February and I am having to continue to manually run the script, any thoughts? Thanks Osman
Osman Posted March 4, 2024 Author Posted March 4, 2024 Morning All, I am now having to run this manually on a daily basis, some assistance with the error owuld be appreciated. Thanks Osman
Steve Giller Posted March 4, 2024 Posted March 4, 2024 @Osman That error is specific to the scenario we have described above. I can only recommend that you delete the credentials that have been saved and perform the First Run process once more with the Windows User Account that is specified in the Run As entry on the Scheduled Task.
Osman Posted March 4, 2024 Author Posted March 4, 2024 Hi Steve, Which scenario, do you mean: Quote The authentication details (Instance ID & API Key) is stored in the import.cfg file that is created/stored with the .exe. Only the WINDOWS account which CREATED the import.cfg has access to the details it contains! IF you are running the .exe in YOUR account and all works, then that would explain why the Service Account can't get the info out. Use "Run As..." or "runas" with the service account to set up the import.cfg which the Service Account will use (under the Task Scheduler) That was from SamS' response of the 7th Feb? If so, I already clarified that both the Scheduled Task and the manual execution of the import are being performed by the exact same account. Thanks Osman
Steve Giller Posted March 4, 2024 Posted March 4, 2024 The Documentation is very clear on this specific error and as far as I am aware can only occur when the Accounts do not match. To rule out any issues with the configuration file we are recommending deleting this and re-authenticating with the First Run steps as per the troubleshooting notes: Quote This error can occur for either of the below states and can be resolved by either running the import as the same session user and on the same computer that the original import authentication took place, or by resetting the encrypted credentials
Osman Posted March 12, 2024 Author Posted March 12, 2024 Hi Steve, But neither of the conditions in the Documentation: When the user who runs the import is not the same user who first ran the import; When the import is run on a different computer from the one that originally performed the authentication details encryption. Is true in my case, as I have stated at least twice already. It is the same device and using the same user that originally processed it. Also, this does not explain why running the import manually using the command prompt works? Anyway, I will do as suggested. We have three other imports that are also run for other types of user, what impact will it have on those, as they are all running through a schedules task? Thanks Osman
Osman Posted March 14, 2024 Author Posted March 14, 2024 Hi Steve, Did exactly as suggested and it has actually made things worse, I got an error on recreation of the import.cfg of: [ERROR] Error Loading KeySafe Authentication: The API key being used does not have permission to access this keysafe record This has not only broken the User import, but it has also broken all other imports we had setup. Any suggestions? Thanks Osman
Osman Posted March 18, 2024 Author Posted March 18, 2024 Looks like I am back to square one, the underlying cause of the error on my last post was that there were missing rules in the API Key. I am still getting the following error: 2024/03/18 09:05:16 [WARN] Current version 4.2.0 (patch) is greater than or equal to the latest release version on Github 4.2.0 2024/03/18 09:05:16 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. Having been through the Azure Import documentation again, there is a suggestion that the executable should be in the profile folder of the user that undertook the first run, tested this on the offchance that it would make a difference, still getting the error above. I still don't understand how running from the command line works without issue, but fails as part of a Scheduled Task.
Osman Posted March 18, 2024 Author Posted March 18, 2024 OK, decided to try one more thing. Recreated the import.cfg after adding the API Rules, it is now working through the Task Scheduler. Thanks Osman
Osman Posted April 29, 2024 Author Posted April 29, 2024 Spoke too soon, it worked once and hasn't since. I bit the bullet and completely recreated the Scheduled Task, it is still failing with the exact same error shown above, see latest below: 2024/04/29 08:38:28 [MESSAGE] You're running the latest version of this utility: 4.2.1 2024/04/29 08:38:28 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. The import still runs without issue from the Command Prompt, any ideas?
SamS Posted May 16, 2024 Posted May 16, 2024 Hi @Osman, That error means that the account which is running the utility doesn't match the account for which the import.cfg was created. This is often the case where the Windows Task Scheduler is set up to run the utility in the context of a dedicated service account, but testing has been done with a (different) regular user account. In this case you have likely tested against your own account and have the scheduled task run with the service account. Either run the scheduled task under your account (so you can see it working) or, assuming you have the details for the service account, remove the import.cfg and run the utility under the service account (to enter the instance ID and API key again) after which the scheduled task should work.
Osman Posted May 17, 2024 Author Posted May 17, 2024 Hi SamS, Thank you for the response, however. you will see from the thread that this is not the case. What you have suggested has already been done. In fact you made the same suggestion as above on the 7th February and I explained on multiple occasions that the account that is running the Scheduled Task and is signed into the server to run it manually are the same account. I could not verify that the Import.cfg was created by the account, as it was created before my time, so I recreated it as advised and I am still seeing the same error: 2024/05/16 03:00:01 [MESSAGE] You're running the latest version of this utility: 4.2.1 2024/05/16 03:00:01 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. Or at least it was, until today. Today I got: 2024/05/17 03:00:05 [MESSAGE] Successfully updated to version: 4.2.2 2024/05/17 03:00:05 [MESSAGE] Release notes: **Fixed** * Issue where utility would halt the current import in the event that the Entra ID user column being used to match users with was null * Issue where, when using a column other than UserID to perform user matching, the utility would attempt to add roles unnecessarily * Removed unused and deprected code 2024/05/17 03:00:05 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. This is clearly a one-off notification of fixes to the app, as a subsequent manual triggering of the Scheduled Task returns: 2024/05/17 07:57:55 [MESSAGE] You're running the latest version of this utility: 4.2.2 2024/05/17 07:57:55 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. As soon as I run it from the command line, it works. I am doing nothing special, I am neither elevating nor running the cmd prompt as a different user, it is all the same service account context. Thanks Osman
Osman Posted May 17, 2024 Author Posted May 17, 2024 Hi Steve, Was pretty sure that this value was already set, but checked anyway and it is set and is correct. The key thing is that the Task is not timing out, it is terminating after about 10 seconds with the error previously posted. Thanks Osman
Osman Posted August 27, 2024 Author Posted August 27, 2024 Morning All, As it has been a few months since our last interaction, I thought I would drop another message to see if anyone had anyone had any further insights into the issue? Thanks Osman
Steve Giller Posted August 27, 2024 Posted August 27, 2024 What happens if you set the scheduled task to run under your Windows Credentials?
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now