IT Monkey:   


Formal Cireson Support (phone, email, and web) is not included with the free Self-Service Portal – Community app. For trouble shooting assistance, take advantage of the Cireson Community to find answers to your questions. However, if you’d like to purchase a Support Package to access more formal Cireson Support (phone, email, and web), please contact us today to learn more on the pricing options.

End Users unable to submit new Service Requests

Afternoon all,

I've been banging my head on what appears to be a permissions issue that I cant quite sort out.

I've created an end user role for and assigned one Catalog Group containing a handful of offerings. When users hit the portal, they are able to see these offerings. However, after filling out the request offering and submitting, a 'Failed - UnauthorizedAccess' box pops up repeatedly. If I use the same test user and hit the built in Microsoft portal, they are able to submit this request just fine. If I use an Administrator to submit the same Service Request, all is well.



The error I see within the portal server's logs, certainly suggest that there's permissions missing, but I can't for the life of me sort out what is missing, particularly since this appears to be limited to only end user roles and only through the Cireson portal.

An exception was thrown while processing ProcessDiscoveryData for session ID uuid:0169317e-23db-4be6-8cee-5513a4b3f797;id=17.
 Exception message: The user DOMAIN\USERAccount does not have sufficient permission to perform the operation.
 Full Exception: Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user DOMAIN\USERAccount does not have sufficient permission to perform the operation.
   at Microsoft.EnterpriseManagement.Mom.DiscoveryDatabaseAccess.ManagementStoreAuthorization.Authorize(DiscoveryDataInstance discoveryDataInstance, IAuthorizationService authService, Boolean useProcessContext, WindowsIdentity identity, DatabaseConnection databaseConnection)
   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler.AuthorizeEntityObjects(DatabaseConnection databaseConnection, Guid discoverySourceId, IContext context, IList`1 packets)
   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler.ProcessIncrementalDiscoveryData(DatabaseConnection databaseConnection)
   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler.Process()
   at Microsoft.EnterpriseManagement.Mom.DiscoveryDatabaseAccess.DiscoveryPackageProcessor.ProcessWithRetry(HandleProcessing handleProcessing, RetryPolicy retryPolicy)
   at Microsoft.EnterpriseManagement.ServiceDataLayer.ConnectorFrameworkConfigurationService.ProcessDiscoveryData(Guid discoverySourceId, IList`1 entityInstances, IDictionary`2 streams, ObjectChangelist`1 extensions)

Answers

  • John_LongJohn_Long Customer Adept IT Monkey ✭✭
     I'm getting the same. I've enabled Azure Application Insights to track the instances of these failures. Appears to be the case for both IR and SR's.


  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    What role do you have the submitter mapped to?
    In the request for are you referencing any CI's data thru query results?

  • John_LongJohn_Long Customer Adept IT Monkey ✭✭
    Hi @Brian_Wiest, in this case I think they're end users. Some of my reviewers are having issues saving Review Activity approvals as well but that's a different issue. For the service requests failings, no, there shouldn't be any CI's referenced.
  • John_LongJohn_Long Customer Adept IT Monkey ✭✭
    @Brian_Wiest in my case, I believe I had modified permissions mistakenly for some staff as I'm digging through an issue where by end-users seem to be losing their ability to open tickets even though they are the Affected User.

    Quite a challenge to debug implied permissions!
  • SpoonerSpooner Member IT Monkey ✭

    So it would appear that the End User role just doesn't have enough permissions.

    I had to use one of the Operator Roles, and strip out almost all of the permissions for these 'End Users' to be able to submit SRs.

  • Peter_SettlePeter_Settle Customer Advanced IT Monkey ✭✭✭

    We are experiencing the same issue with users creating SR's and then not being able to view them.

    They are End Users but this normally provides sufficient permissions for them.

    Any help in this matter would be appreciated.


  • Peter_SettlePeter_Settle Customer Advanced IT Monkey ✭✭✭

    Just for extra info:

    Current Portal Version: 7.4.2012.11

    Management Pack Version: 7.7.2012.185
  • Justin_WorkmanJustin_Workman Cireson Support Ninja IT Monkey ✭✭✭✭
    It sounds to me like maybe the role doesn't have permissions to the template.  I agree troubleshooting SCSM permissions is a pain!
  • Peter_SettlePeter_Settle Customer Advanced IT Monkey ✭✭✭

    My issue is that the Affected person, logged the SR and then can not view it, which to me is strange, to say the least.

  • Sam_PackerSam_Packer Customer IT Monkey ✭
    We are having this issue as well, same error. It's happening to about 10 people (we have over 500 end users). The Domain Users group has access through the the end user role. Anyone have a fix for this yet? I am baffled.
  • Sam_PackerSam_Packer Customer IT Monkey ✭
    Update on this. It's still occurring here. The commonality is that the people it's happening to were employed with the company, terminated, and then rehired. All of our people in this situation are having the issue. Is there something maybe in the database that is not clearing out or something when they are leaving the firm? Still baffled. Any ideas anyone?
  • Karen_Bruster1Karen_Bruster1 Member IT Monkey ✭

    @Sam_Packer, are you pulling in your users via the AD connector?

    If so have you tried removing them from Configuration Items--> Users, and then rerunning the AD connector?

    I had that happen with a customer who left then came back.

  • Justin_WorkmanJustin_Workman Cireson Support Ninja IT Monkey ✭✭✭✭
    @Sam_Packer
    I believe @Karen_Bruster1 is on the right track.  It's likely their DistinguishedName in SCSM is out of sync with AD.  You can do like she says and delete their CIs and bring them back with the AD connector, or you can try to update their DistinguishedName with what is listed in AD and then restart cachebuilder. 
  • Sam_PackerSam_Packer Customer IT Monkey ✭
    Thanks for your replies! I am working through each one now. Matching up the name in AD with SCSM has fixed a few. There are a few others who have the same name in both and it's still not working, but it's probably something on our end. 
  • H_GerlingH_Gerling Member IT Monkey ✭
    any news on this?
    We still have this problem, without changed DN (Current Portal Version: 8.3.1.2016).
Sign In or Register to comment.