End Users unable to submit new Service Requests

Spooner

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)

John_Long

 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_Wiest

What role do you have the submitter mapped to?
In the request for are you referencing any CI's data thru query results?

John_Long

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_Long

@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!

Spooner

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_Settle

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_Settle

Just for extra info:

Current Portal Version: 7.4.2012.11

Management Pack Version: 7.7.2012.185

Justin_Workman

It sounds to me like maybe the role doesn't have permissions to the template.  I agree troubleshooting SCSM permissions is a pain!

Peter_Settle

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_Packer

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_Packer

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_Bruster1

@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_Workman

@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_Packer

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_Gerling

any news on this?
We still have this problem, without changed DN (Current Portal Version: 8.3.1.2016).

Bhalaaji

I am also having the same issue. Please some one can help

Priyan_Mistry

Has anyone else found a solution or reason to the problem? We also have some users who are unable to submit service requests.

After some testing it looks like some users are only able to submit Service Requests when they have access the config items group "Global Operators Group"