Home Analyst Portal

Best practice: configure permissions for the Cireson portal - need help

Ingrid_GlatzIngrid_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

Answers

  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    edited June 2016
    Hi Ingrid

    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:





    Check the below video and skip to about 9 minutes for more info:


  • Ingrid_GlatzIngrid_Glatz Customer Adept IT Monkey ✭✭

    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.

  • Christopher_CarverChristopher_Carver Customer Adept IT Monkey ✭✭
    Hi 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?  
  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    Hi Chris

    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
  • Christopher_CarverChristopher_Carver Customer Adept IT Monkey ✭✭
    Thank you Joe, I have opened in incident as the problem persists.
  • Morten_MeislerMorten_Meisler Premier Partner Advanced IT Monkey ✭✭✭
    I have the same problem, it works if the tables are truncated and cachebuilder restarted, but then next day the user from domain 2 is blocked - user can enter portal but with no rights. Did you find a solution for this?

    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

    ERROR [   3] 16 Mar 2017 14:21:10,438: Group not found: cn=scsm_readonlyoperators,ou=scsm,ou=sg,dc=DOMAIN2,dc=local
    ERROR [  24] 16 Mar 2017 14:37:50,969: Error was thrown while retrieving membership of: CN=SCSM_DCA,OU=NyStruktur,OU=SCSM,OU=SG,DC=DOMAIN1,DC=net
    ERROR [  24] 16 Mar 2017 14:37:51,016: Error:
    System.DirectoryServices.AccountManagement.PrincipalOperationException: Information about the domain could not be retrieved (13 55).
       at System.DirectoryServices.AccountManagement.Utils.GetDcName(String computerName, String domainName, String siteName, Int32 flags)
       at System.DirectoryServices.AccountManagement.SDSCache.GetContext(String name, NetCred credentials, ContextOptions contextOptions)
       at System.DirectoryServices.AccountManagement.ADStoreCtx.ResolveCrossStoreRefToPrincipal(Object o)
       at System.DirectoryServices.AccountManagement.ADUtils.DirectoryEntryAsPrincipal(DirectoryEntry de, ADStoreCtx storeCtx)
       at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.get_CurrentAsPrincipal()
       at System.DirectoryServices.AccountManagement.FindResultEnumerator`1.get_Current()
       at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
       at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
       at Cireson.CacheBuilder.Service.Util.AdUtil.<>c__DisplayClass16.<GetMembers>b__14()
       at Cireson.CacheBuilder.Service.Util.AdUtil.GetMembers(GroupPrincipal groupPrincipal)


  • Christopher_CarverChristopher_Carver Customer Adept IT Monkey ✭✭
    This problem eventually made it to MS Premier Support and a on-site MS SME.

    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. 
Sign In or Register to comment.