Debugging permissions problems

Stephane_Bouillon

Hi,

The permissions and access rights for users and agents are impacted by multiple settings: AD membership, Role definition in SCSM, Catalog Group, and finally service offerings. Is there an easy way to "debug" when a user should be seeing an offering but doesn't and/or when a user sees an offering he should not see ?

Justin_Workman

Is SG_SCSM_Agents_Y (either directly or through other group membership) a member of the AnalystsADGroup defined in Admin Settings?

Stephane_Bouillon

This was due to the analyst group being configured as user group for the default Advanced Operator role, which is unscoped and has global access. Once I corrected that, it shows up as expected.

Justin_Workman

@Stephane_Bouillon - This is an interesting question.  There are many layers when getting to the bottom of why a user can or can't see a Request Offering.  I don't think there's a tool or anything to walk through all those layers to determine why a user can or can't see an offering.  It sounds like you've got a handle on where all the layers are.  I think it's just a matter walking through them manually.  Also, don't forget the final layer of restarting the cachebuilder after adjusting any of the above layers

Stephane_Bouillon

Thanks Justin, for end users I have it pretty well covered

-) In AD:
the users are part of a group SG_SCSM_Users_X

-) In SCCM Security Role Definition: End Users X
All management packs can be accessed (set at creation time of the role)
No access to any queue
All configuration items can be accessed
Only catalog item CG End Users X can be accessed
All form templates can be accessed
Users from SG_SCSM_Users_X

-) In Catalog group definition for CG End Users X
Service offerings and request offerings specific to this group of users

This gives me granular control over which users can request which services. If a user is part of an AD group or multiple groups, they see the corresponding services.

For Agents however, I can't find what I'm doing wrong, I limit them to a single queue, but for some reason they see all the services available

Stephane_Bouillon

I created

-) in AD:
SG_SCSM_Agents_Y

-) In SCCM Role Definition:  Agents Y (Incident Resolver)
All management packs can be accessed (set at creation time of the role)
Access to one single queue Incident queue Y
All configuration items can be accessed
No access to any catalog item groups
No access to any tasks
No access to any views
No access to any forms
Users from SG_SCSM_Agents_Y

-) In Cireson Portal Support Group Mappings
Incident Support Group Y is mapped to SG_SCSM_Agents_Y
Service Request Support Group Y is mapped to SG_SCSM_Agents_Y

When I log on with a user who is member of the SG_SCSM_Agents_Y AD group, I don't see the icon for Team Work

What am I missing ?

Justin_Workman

Is SG_SCSM_Agents_Y (either directly or through other group membership) a member of the AnalystsADGroup defined in Admin Settings?

Stephane_Bouillon

It was not, I have added it and
-) re-synchronized the AD connector for all users
-) restarted the cache builder service
-) recycled the CiresonPortal application pool
-) logged out of the browser and logged back in
-) Ctrl-F5 to refresh the page

Now, when I logon as an Y agent, I see the Team Work icon, but when I click it there are no incidents, although incidents do exist for the support group.

Also, all of a sudden, I see all available service request offerings, where I should only see a subset of them.

Stephane_Bouillon

I noticed there was a mismatch between the group name in the Users section of the Configuration Items in the SCSM console and the actual name of the SG_SCSM_Agents_Y group. I deleted the item and then resynchronized, which re-imported the group correctly. I then re-configured the Cireson Group mappings, and the incidents now show up correctly in the Team Work view.

However, the user still sees way too many service request offerings. I must still be overlooking something obvious.

Stephane_Bouillon

This was due to the analyst group being configured as user group for the default Advanced Operator role, which is unscoped and has global access. Once I corrected that, it shows up as expected.