Best practice: configure permissions for the Cireson portal - need help
Ingrid_Glatz
Customer Adept IT Monkey ✭✭
I'm struggling in configuring permissions in SCSM to allow access to certain things in the portal. We do have an environment with approx. 20 domains/forests where users should have access to offerings and other views in the portal.
According to a Cireson KB article, the Domain Users group can be used directly in a User Role, but it doesn't work when this group is nested. Unfortunately, it doesn't work either when I add this group into the user role directly. Within the User Role, all Domain Users groups are listed (aaa\Domain Users, bbb\Domain Users, ccc\Domain Users and so on), no group nesting. Checking the Cache Builder log file, I see "Group not found: CN=Domain Users,CN=Users,DC=aaa,DC=net" for all of the Domain Users groups.
What's the best way to give access to common offerings and others in the portal for every user in every domain? Is it really required to create new user groups in every domain for all Domain users to be able to configure permissions in the portal? Who has the same issue and has found a solution?
Thanks for your help.
Ingrid
Best Answer
-
Joe_Burrows
Cireson Devops Super IT Monkey ✭✭✭✭✭
Hi IngridThis is what confused me a lot. Are you only referring to the Domain Users group in the domain where SCSM and the Portal are installed?
Correct, if adding directly to a role it will work for the local domain. eg I have SCSM in domain1 and my end user role will contain "domain users", for domain2 im unable to target or nest domain users in any groups for the cachebuilder to enumerate this (You will always get Group not found if you target 'domain users' from a foreign domain)
So I must create a global group that contains all my users in domain2, nest this to a universal group in domain2, then nest my universal group in a domain local group in domain1, add this domain local group to my end user role in SCSM. Nesting this way will also maximise performance in a multi-domain forest.
Hope this helps!
Regards
Joe5
Answers
It does make it tricky working with a large number of domains as you wont be able to use the domain users groups for the foreign domains. You will need to create groups and use cross domain group nesting to get this to work.
See below examples:
Hi Joe,
according to your KB article "Troubleshooting End User Service Catalog/Request Offering View, - NOTE: Adding Domain Users directly to a user role will work as expected", I should be able to use the Domain Users group.
The same is written in the KB article "How To Troubleshoot Issues in the Cireson Portal - Note: the special group "Domain Users" can be directly assigned to the user role, but it cannot be assigned to the user role via membership in another group (i.e. User Role -> Some Group -> Domain Users)".
This is what confused me a lot. Are you only referring to the Domain Users group in the domain where SCSM and the Portal are installed? Not Domain Users groups from other domains that have 2-way-trusts with the resource domain? Then you should add an additional note to these articles not to use Domain Users groups from other domains.
I'm fine with other permissions using dedicated groups and users in all of the domains, I just don't get ALL USERS from all domains to access certain offerings in the portal. I guess I will have to create additional groups in each of the domains to hold all Domain Users.
Correct, if adding directly to a role it will work for the local domain. eg I have SCSM in domain1 and my end user role will contain "domain users", for domain2 im unable to target or nest domain users in any groups for the cachebuilder to enumerate this (You will always get Group not found if you target 'domain users' from a foreign domain)
So I must create a global group that contains all my users in domain2, nest this to a universal group in domain2, then nest my universal group in a domain local group in domain1, add this domain local group to my end user role in SCSM. Nesting this way will also maximise performance in a multi-domain forest.
Hope this helps!
Regards
Joe
I followed your steps and created a UG in domain 2 for my users and then add that AD group to the domain 1 domain local group where SCSM and Cireson resides. Everything works perfectly for 24 hours and then poof everyone in domain 2 are blocked from the portal. Purge the LastModified table, remove the domain 2 users from the CI$User table, restart the cache and 10 minutes later everything is fine again. Rinse and repeat every 24 hours.
So to narrow down the problem I leverage the spCheck_UserWorkItemPermissions and spCheck_UserRequestOfferingPermissions stored procedures on the Cireson side and the PowerShell script .\Get-UserPermissions.ps1 that one of the Cireson employees blogged about on the SCSM side.
When the problem manifests itself I try the .\Get-UserPermissions.ps1 script first on the SCSM side. It sees the user and correctly states the user has the proper access permissions. Yet, when I run the Cireson stored procedures it reports permission is denied.
A few things to consider. Domain 2 users have a disabled account on Domain 1under a different SID, but their SID for Domain 2 is in Domain 1 account's SID history. I believe Cireson's cache builder is reauthenticating the user on their SID in Domain 1, the DC in domain 1 is finding the SID in SID history and reporting back the domain 1 account back to the CacheBuilder.
Thoughts?
Nothing comes to mind for a quick fix as sounds like you have implemented the correct nesting process for the portal, seems odd that the scoped access schedule removes access again 24hours latter. We would need to review the logs and chat with the Dev team for advice here.
Lets get this in a support ticket and can get the right eyes across it.
Cheers
Joe
Domain 2: Universal Group (scsm_readonlyoperators) with User X
Domain 1 (where SCSM resides): Domain Local group (SCSM_DCA) with Universal group from Domain 2 in.
Can't make scoped view just for this SCSM_DCA. View does not show up for User X
In my case, the issue has to do with SID history turned on in AD. If SID history is turned on things go sideways with no fix. At some point Cireson's solution is validating the domain2 account with the domain controller. The DC looks at the account and sees the account has SID history turned on. The DC then returns back the domain1 account to Cireson; which Cireson stores the domain1 account and removes the domain2 account from access.
So when the account user logs in using the domain2 account, Cireson has no record for that account to have access. The SME told me that SID history should only be turned on for a short time to perform a AD migration and that this behavior in AD dates back to NT 4.0. The only way to resolve this is to have Cireson's process realize the account holder can come in through multiple domains and that domain2\account is mapped to domain1\account. Which I doubt will happen.
Luckily for me the 4+ year domain migration was coming to an end and customers had to suffer a little. Though I did get docked on my performance review from those who had loud voices thinking the solution was unstable. Damn the reasoning and all that fun stuff Dilbert cartoons are built from.
I was on the verge of enabling one of my Orchestrator runbooks to run every 5 minutes that would check and correct the Cireson authorization table. Luckily it didn't come down to that. If you are faced with the exact same problem, you might think of doing something similar.
Hi @Christopher_Carver,
short question, which table do you mean with Cireson authorization table?
Regards