Why a single user is now getting the error "User is not allowed to update the ticket." when replying to an email from KACE Service Desk?

There is a user on Win 10 ver. 21H2, like the majority of our users, who opened a ticket via the KACE Help Desk ticket creation portal, but gets the error, "User is not allowed to update the ticket." whenever replying to tickets via Outlook 2019.  User also gets the error when trying to create a ticket via the KACE email address.  So, there is something wrong with the user being able to send an email to KACE.  This is the only user I am aware of in our environment that is experiencing this issue.

I've checked and compared user's account info with other accounts - no discernable account discrepancies.

I've confirmed user login credentials to be correct, so user is accessing the correct account.

0 Comments   [ + ] Show comments

Answers (6)

Posted by: bmcmillan 1 year ago
White Belt


Quest support helped me figure out a solution:

First Issue:  User cannot update own tickets.

This was resolved by deleting archived accounts for the same user (after moving all associated tickets from the archived account to the current active account).  Although, resolving the second issue below may have had a hand in resolving this as well.

Second Issue:  After archiving second active account for user, another would automatically be created in its place.

This was resolved by putting an email address in the email address field in AD.

Posted by: Hobbsy 1 year ago
Red Belt

It may be that the duplicate account is stopping it working, so all I can suggest is ensure the user only has a single account, if it still does not work then log a support ticket with Quest.

  • Agreed.. I run into this where ldap brought the account in but saml created a new one. This is my fault, I need to fix saml so the primary authentication field is the same as ldap. - barchetta 1 year ago
    • I archived the old second account, but user is still having the same error. Now a third account was auto generated, which is identical to the account I archived. I made sure the main account is in fact the main account by checking to see that account's associated tickets. Not sure what to do now. - bmcmillan 1 year ago
Posted by: barchetta 1 year ago
4th Degree Black Belt

Are you doing a ldap import from active directory?  go to settings:controlpanel:authentication. What check box is checked?

  • LDAP Authentication is selected. - bmcmillan 1 year ago
    • Ok what about saml? And what is the "primary key"? settings control panel SAML - barchetta 1 year ago
      • SAML is not being used. Nothing is set up. Must be from our AD. - bmcmillan 1 year ago
  • I guess it is time to open a ticket with quest. Dont delete any accounts and they should be able to tell you what is going on. - barchetta 1 year ago
    • Thank you for trying to assist me. Appreciate it! - bmcmillan 1 year ago
Posted by: Mark.johanns@cygnific.com 1 year ago
White Belt

We had a similar Case where this happens. 
For us only ticket owners are allowed to perform updates on the ticket. 
We seen that 2 different users on a 3 months different time period send a similar mail. 
Apparently the mail import linked those 2 mails to the same ticket which was already closed.
Since the second sender was not a owner of the ticket he got the error back.
We logged a ticket this week at quest since like this we lose tickets and are expecting that a new ticket to be logged. 

  • That is strange, but seems unlike my issue. My tickets are not getting lost or imported into other tickets. All of that is working well. It's just that one user suddenly is unable to update the tickets she opens via email reply. No problem creating them. - bmcmillan 1 year ago
Posted by: Hobbsy 1 year ago
Red Belt

Just checking the obvious, make sure you have the queue set to allow all users as submitters and that there are no labels used for ticket submitters?

  • Thank you, Hobbsy. I double-checked the queue settings and the checkbox was already checked next to allow all users as submitters. The only section that has a label in use is the Owner Label section. - bmcmillan 1 year ago
Posted by: Hobbsy 1 year ago
Red Belt

And when you say you have checked the user account, is that the user account imported into the SMA from AD?

  • Well, the best I can say is, "I believe so." I am coming in as a user of the KACE system post build. The area that I am referring to is in Settings > Users. It is here that I looked up the account. Like many other accounts, there are 2 accounts listed. One is not linked to any devices and the other is. The one that is, I have confirmed with the user, is the actual account she logged in with to open the initial ticket. - bmcmillan 1 year ago
    • SAML has a primary authentication field. What is happening is whatever your SAML is set to for primary is not matching ldaps. So ldap is creating a new account when it does not find a match. You have to resolve that which may mean you have to go to wherever you are doing your SAML app registration and modify the "claim"..

      EDIT: Wait ARE you using SAML? If you look at the top of the new user created it will tell you what it used to auth.

      EDIT again: Sorry it wont tell you what it used but it will tell you what the last import was.. so if yours says just ldap then you are just ldap, but if it has an entry for SAML then you are using saml. You may be doing both, importing from ldap to bring in all of your fields but then using SAML to auth. We do that.. when you do that you have to make sure like I said that the primary field matches. Im using Azure app registration and it is limited to the # of claims and can be a pain. - barchetta 1 year ago
      • I checked the new account created and also started creating a new account - neither indicate what is being used to auth. - bmcmillan 1 year ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ