Jump to content

Osman

Hornbill Users
  • Posts

    66
  • Joined

  • Last visited

Posts posted by Osman

  1. 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

  2. Afternoon All,

    A bit of extra help needed. When trying to run the SlideShow using the Service Account, we get the following error:

    image.png.74b8200c4c6f51aac87dbe5d255962b3.png

    This is certainly a permissions issue, so what I wanted to do was create a custom Role purely for being able to play the SlideShow. I have tried a few variations out, but the only way to consistently get it to work is by assigning it an administrative role. Any guidance as to what the settings should be as, again, we need to restrict this account as much as possible as it is on a screen that is persistently unlocked.

    Thanks

    Osman

  3. Morning All,

    Has there been any further movement on the possibility of allowing a basic user to access a slideshow? Simple use case, Service Desk area has a wall board that display stats, we are using a domain service account to log on, seems a waste of a license to use an Agent User account to achieve this as well as a bit of a security risk to have a constantly on and signed in device to have Agent access.

    Thanks

    Osman

    • Like 1
  4. 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?

  5. 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.

  6. 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

  7. 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

  8. 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

  9. Hi Steve,

    Within a Incident or Service Request, under the Details node, there is the option at the bottom to preview the generating email. There used to be, on a previous instance of the UI, a Back button to return to the ticket, this seems to have dissapeared.

    Thanks

    Osman

  10. Hi Gerry,

    I am not sure that I would say bypass it altogether, I am thinking more that we would have either:

    - A url that uses SSO without choice of direct login that we would be able to publish internally;

    - The sign in page has a detection method that can see that the browser is signed in with a valid SSO account and sign straight in without displaying the options. We have other SAAS systems that are capable of doing this, our room booking system for example.

    Thanks

    Osman

  11. Morning All,

    I am reasonably certain that this has been asked for before, I just can't find it in the community. When we access our SSO url, in a browser that has an active, signed in session, we are always presented with the Single Sign-On/Direct Login options. Is there any way to adjust this so that the system detects the signed in status of the browser and immediately provides access? This is more of an issue for Basic users accessing the portal. 

    Thanks

    Osman

×
×
  • Create New...