Affected users unable to open workitems
Eden_Ravenwood
Member IT Monkey ✭
When end users try to access work items where they are the affected user they receive the error in this screenshot:
they can see all their logged work items in the "My Requests" view but when they click on any of them this is the result. This happens from the moment the work item is logged and is true of all work items where they are the Affected user.
I have set the Domain Users group as a member of the End User role in SCSM and granted the end user role access to some parts of the catalogue and all my users are able to access those parts of the catalogue and log request using the portal, but they cannot subsequently view their requests.
What have I done wrong?
Eden
Best Answer
-
Eden_Ravenwood
Member IT Monkey ✭
The "How to troubleshoot User Access Issues in Cireson Portal" knowledge article finally got me sorted:
https://support.cireson.com/KnowledgeBase/View/35#/
Permission to access work items in the portal is not conveyed by the End User role which is locked down to have access to no queues. In my DEV environment the custom portal user role (based on the End User role) I had created had been modified to have access to all queues and hence all workitems. Since the Domain Users AD group had my Portal User role all users cdould access work items in the DEV environemnt. while in TEST and PRODUCTION that group kept the queue scoping of the End Users Roll on which it was based. resulting in users with no other role not having access to any work items.
So I now have things working as I have modified the queue scoping of my Portal Users group in TEST and PRODUCTION to grant access to all work items. However this raises a question, if my end users are dependant on a custom group that I created to manage access to the catalogue, how do end users have access to view work items in a basic configuration of the portal where they would normally only be members of the End User role which grants them no access to work items?
0
Answers
Also make sure that the "End User" role in SCSM has either the users added or a group that the users are direct members of. Do not have a group that contains groups as this can cause issues.
Personally i always use the built in "Domain Users" group.
The Cireson Cache Builder Service is running and seemingly without any issues. Catalogue and work items are synching between the portal and the console just fine. I had added the built in "Domain Users" group to the "End User" role just as you describe. The log for the cache builder service contains only these two entries:
2017-03-09 20:30:26,520, ERROR [WORK]: SQL Error:
System.Data.SqlClient.SqlException (0x80131904): A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.) ---> System.ComponentModel.Win32Exception (0x80004005): The semaphore timeout period has expired
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader()
at Cireson.ServiceManager.DAL.Wrappers.SqlCommandWrapper.ExecuteReader()
at Cireson.CacheBuilder.Service.Util.ServiceManagerUtil.<Read>d__5`1.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Cireson.CacheBuilder.Service.Util.ParentChildUtil.UpdateParentChildRelationships()
at Cireson.CacheBuilder.Service.Commands.WorkItemCommand.<>c__DisplayClass7_0.<<Synchronize>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Cireson.ServiceManager.DAL.Database.<Retry>d__11.MoveNext()
ClientConnectionId:8c876477-2d20-4dfb-bc3c-d48b998fc9b4
Error Number:121,State:0,Class:20
2017-03-09 20:30:26,613, ERROR [WORK]: Unable to sync WorkItemCommand, the operation failed, but will be tried again in 40965ms. Please review the log for errors, then correct them and restart the cachebuilder service if needed.
That is the complete log file, I have checked the Test and Development environments and the log files there are identical but for the time stamp of the two entries .
I have separate custom scsm groups that controls access to the catalogue for three levels of users; portal users, application administrators and analysts, and they all work as expected with as users access to the being controlled by the membership of the associated AD Groups. The portal users scsm group has the "Domain Users" AD group added just as the scsm "End Users" group does.
Interestingly this is occurring in our Test and Production environments but things are working correctly in the development environment. I have done a side by side comparison of the configuration of the three environments and can find no apparent differences between them in relation to the config that controls portal and catalogue access.
Analysts who are in custom SCSM roles based on the "Advanced Operators" role have no problems accessing specific work items.
Can you confirm for me that it is definitely the "End Users" role that allows basic access to the portal and that even without access to catalogue groups users with the End User role should be able to access the My Requests and My Work views and subsequently access and work items for which they are the affected or assigned user?
The "How to troubleshoot User Access Issues in Cireson Portal" knowledge article finally got me sorted:
https://support.cireson.com/KnowledgeBase/View/35#/
Permission to access work items in the portal is not conveyed by the End User role which is locked down to have access to no queues. In my DEV environment the custom portal user role (based on the End User role) I had created had been modified to have access to all queues and hence all workitems. Since the Domain Users AD group had my Portal User role all users cdould access work items in the DEV environemnt. while in TEST and PRODUCTION that group kept the queue scoping of the End Users Roll on which it was based. resulting in users with no other role not having access to any work items.
So I now have things working as I have modified the queue scoping of my Portal Users group in TEST and PRODUCTION to grant access to all work items. However this raises a question, if my end users are dependant on a custom group that I created to manage access to the catalogue, how do end users have access to view work items in a basic configuration of the portal where they would normally only be members of the End User role which grants them no access to work items?
Is there any official Statement to the argument that the end users have to be a member of the endusers group directly to get Access to their own workitems?
In our case there is exact the same error mentioned here with the error for the enduser. The SQL query from the KB article mentioned above gives the same answer. "user x does not have permission to Access workitem (...)".
A lookup in the AD tells me something else: the affected user is a member of the right endusers group but in a nested AD group.
I am asking because the change to put the users in the different groups make much effort. The customer is a worldwide company with a lot of languages, service offerings affected by language and also the AD architecture.
Hence the below note in KB77
NOTE: Adding Domain Users directly to a user role will work as expected. If Domain Users is nested inside of a group that is assigned to a user role, Active Directory will not return the membership of the Domain Users group as expected.
To confirm group membership enumeration use the below SQL queries when troubleshooting:
--Groups that a user is a member of
SELECT DG.UserName FROM CI$DomainGroup DG
INNER JOIN GroupMembership_CI$DomainGroup_CI$User GM ON GM.DomainGroupId = DG.Id
INNER JOIN CI$User U ON GM.UserId = U.Id
WHERE U.UserName = 'joe.burrows'
--Users that are a member of a group
SELECT U.UserName FROM CI$User U
INNER JOIN GroupMembership_CI$DomainGroup_CI$User GM ON GM.UserId = U.Id
INNER JOIN CI$DomainGroup DG ON GM.DomainGroupId = DG.Id
WHERE DG.UserName = 'ADGroupName'
The last days I have tried to find out which the problem ist.
I also tried the first query and put in the username. But the table is blank.
Is there a possibility to force a resync or something like this by username to get the access permission again?
The user is member of Group 1, Group 1 is member of Group 2, Group 2 is member of Group 3, and Group 3 is the used EndUsers Group.
Do you have any ideas?
Claas_Tews
Stop the Cachebuilder service, then run the following against the ServiceManagement DB?
TRUNCATE TABLE CI$User
TRUNCATE TABLE CI$DomainGroup
TRUNCATE TABLE LastModified
Then restart the Cachebuilder service.
Maybe there is something wrong with the AD Groups?
The table with the second query from Joe with the affected EndUsers Group is also empty. Other Groups: e.g. an Analyst or admin Group was successfull with the related members.
If you set logging level to ALL the cachebuilder.log file should give more clues as to why its failing to enumerate the membership.
Is this a multi domain environment with cross domain group nesting or single domain? Maybe best to get in a support ticket for further troubleshooting.
Cheers
Joe
From what I have read the End User role doesn't need access to any of the queues because the access to their own work items where they are the affected user should be implied. However this doesn't work in our case.
If I give that role access to all work items they can access their work items, but this action will at the same time give all the analysts access to all work items which will remove the benefits of using queues. This is not an option for us because some of the work items can contain sensitive information that only specific groups are allowed to see.
I have truncated CI$User, CI$DomainGroup and Last Modified tables in the ServiceManagement database and rerun the Cachebuilder. There are no errors in the Cachebuilder log and I can see that our test user is found and added to the correct User Role. However the user is still not able to view its own work items afterwards. When I check the Webconsole log I can see that it says that the user doesn't have the necessary access to perform the action. This has become really frustrating because I can't find what is causing this problem.