Home Self-Service Portal - Community

Affected users unable to open workitems

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_RavenwoodEden_Ravenwood Member IT Monkey ✭
    Answer ✓

    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?

Answers

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    Make sure that the cache service is running and that there are no errors in the cache log file.
    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.
  • Eden_RavenwoodEden_Ravenwood Member IT Monkey ✭

    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?

  • Eden_RavenwoodEden_Ravenwood Member IT Monkey ✭
    All the analysts in my system are members of the Analyst group as configured during the installation of the Cireson portal, and I assume this is why they can access specific work item where end users (who have no specific group configured during the Cireson portal installation) cant.  Would that be correct?
  • Eden_RavenwoodEden_Ravenwood Member IT Monkey ✭
    Answer ✓

    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?

  • Claas_TewsClaas_Tews Partner IT Monkey ✭
    Make sure that the cache service is running and that there are no errors in the cache log file.
    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.

    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.

  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    The cachebuilder can enumerate nested groups - only time this is not true is when a custom group has 'Domain Users' as the nested group. 

    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'

  • Claas_TewsClaas_Tews Partner IT Monkey ✭
    @Joe_Burrows : Thanks for your answer and the SQL queries.
    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?
  • Peter_SettlePeter_Settle Customer Advanced IT Monkey ✭✭✭

    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.

  • Claas_TewsClaas_Tews Partner IT Monkey ✭
    @Peter_Settle : I also tried this DB queries without success. :-( 
    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. 

    --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'


  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    Hi Claas

    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
  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭
    We have run into this problem as well. From the time when we decided to use queues in order to lock down work items for the analysts for each department we have received a lot of complaints from our end users that they are not able to open their own work items. They get the above error message.
    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.
Sign In or Register to comment.