Template permissions
David_Morris1
Member Advanced IT Monkey ✭✭✭
Hi,
We have multiple change management templates most of which are locked down to certain users/groups, because of this the analysts can only access scoped templates from the "new" draw at the bottom of the page. Seemingly randomly this scoping is no longer applied to some users / groups allowing them to see/use all change templates in the system. a Cache builder restart resolves this issue.
any ideas? Cireson support have claim this must be a workflow changing permissions or a SCSM issue and to contact Microsoft but as a cache builder restart resolves the issue I'm reluctant to believe this is the case
Thanks
Dave
We have multiple change management templates most of which are locked down to certain users/groups, because of this the analysts can only access scoped templates from the "new" draw at the bottom of the page. Seemingly randomly this scoping is no longer applied to some users / groups allowing them to see/use all change templates in the system. a Cache builder restart resolves this issue.
any ideas? Cireson support have claim this must be a workflow changing permissions or a SCSM issue and to contact Microsoft but as a cache builder restart resolves the issue I'm reluctant to believe this is the case
Thanks
Dave
0
Answers
Enabled full logging on cachebuilder and found the following error
WARN [ 3]: cn=User, Name,ou=users,ou=noc,dc=localhost is a member of cn=scsm-noc-workflow,ou=noc_scsm,ou=groups,ou=noc,dc=localhost, but does not exist in the database.
Performed a fix from MS that forces a FULL AD sync via the AD connector
To do a FULL AD connector synchronization you need to reset the watermark on the AD connector. Steps below:
-- Execute the following SQL Query to find the DataSourceID number for the AD Connector that is used to bring the users into SM Use ServiceManager
Select * from LFX.datasource
-- Update the line below replacing # with the corresponding AD connector DataSourceID from above to reset the AD Watermark for that connector. The Next AD Synchornization performed will be a FULL synchronization.
[LFX].[ResetWatermarkForDataSource] #,'erroroutput'
-- From the Service Manager Console select the AD Connector and then click "Synchronize Now".
This cleared the sync error between SCSM and the Cachebuilder.
When you click New > Work Item > Change Request > From Template, the browser sends a call to http://portalserver/api/V3/Template/GetTemplates?classId=e6c9cf6e-d7fe-1b5d-216c-c3f5d2c7670c with an authorization token associated with the user. The server connects to the SCSM SDK as that user and calls GetObjectTemplates(). It is at this point that scoping occurs. SCSM should only return the objects on which the user is scoped.
The portal takes the list of templates returned by SCSM, filters them by the class type, and returns that list to the portal user.
The cache builder has no part to play in this process. I cannot explain why restarting the cache builder should remedy the situation. Perhaps the calls that the cache builder makes to the SCSM SDK cause it to re-evaluate the scoping on the users?
It might be interesting when you find yourself in this situation again, to run a PowerShell session as the affected end user and then use the Get-SCSMObjectTemplate cmdlet from SMLets to check if the user can read that template.
We actually have 3 separate portals to allow us to copy with multiple time zones, all installed on separate management servers with separate ServiceManagement DB all connecting back to one SCSM instance, we see this issue on all 3 portals intermittently across multiple users,
at the moment of writing i currently have the issue showing on my non admin account on one portal and not the others, running the GET-SCSMObjectTemplate shows the 1 change template my non admin account should see and so does 2 of the three portals, the other shows all changes templates in the system both on the UI and by browsing directly to the API link you mentioned above
"copy with multiple time zones"
Seems like a heavy load on your SCSM instance to have three replicas for time zones.
Just wondering the design.
(I have one portal server servicing 8 time zones and 33K users)
I wonder if this is related to an issue we used to see in the portal, where the ServiceManager connection would timeout for the user and the portal would reconnect as the service account to complete the action. I know this was still an issue on some versions of V7.4. Typically you would see updates in the work item history showing as modified by the service account rather than by an analyst. In fact, the session timer was introduced to stop this from happening.
I have not heard of this problem recurring in more recent builds. Would you consider upgrading the portal?
this maybe the case so worth looking at, we will be upgrading but are heading into Christmas change freeze so wont be until the new year
The only issue I run into is if I use the ARO to map the date entered to the SR title or description. It is saved in the time zone for the entered user with no time zone information so it may not match the time zone of the support desk processing the request.
So I do everything I can not to map dates to free text fields when I can. And if the business case requires it I add to the ARO prompt to please enter the value in EST time. (All our support desks are EST)
HTH
I.E if a user in a US timezone at UTC -5 logs onto a portal where the management server is in UK time UTC +0 and requests access to a system for 10am it logs into SCSM as 10am UTC not the converted US Local time (5am UTC) meaning the access will be granted 5 hours early meaning without using a seperate portal for the US time zone the users that arent in the management servers local time would have to convert the times on input
Not that I have seen. Any Date prompt that I have mapped to a date field IE Schedule Start Date That date gets saved in UTC in the database adjusted from the users workstation time zone.
If the portal is not saving the date correctly I would open a ticket.
I opened PR70630 to have this addressed the other day.