/build/static/layout/Breadcrumb_cap_w.png

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 2 years ago
White Belt
2

UPDATE

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 2 years ago
Red Belt
0

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.


Comments:
  • 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 2 years 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 2 years ago
Posted by: barchetta 2 years ago
4th Degree Black Belt
0

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


Comments:
  • LDAP Authentication is selected. - bmcmillan 2 years ago
    • Ok what about saml? And what is the "primary key"? settings control panel SAML - barchetta 2 years ago
      • SAML is not being used. Nothing is set up. Must be from our AD. - bmcmillan 2 years 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 2 years ago
    • Thank you for trying to assist me. Appreciate it! - bmcmillan 2 years ago
Posted by: Mark.johanns@cygnific.com 2 years ago
White Belt
0

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. 


Comments:
  • 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 2 years ago
Posted by: Hobbsy 2 years ago
Red Belt
0

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?


Comments:
  • 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 2 years ago
Posted by: Hobbsy 2 years ago
Red Belt
0

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


Comments:
  • 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 2 years 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 2 years ago
      • I checked the new account created and also started creating a new account - neither indicate what is being used to auth. - bmcmillan 2 years ago
 
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