none
Permissions apply differently in Web Console and Designer RRS feed

  • Question

  • Greetings,

    I'm a bit stumped on this one. I've got an AD group that I used to grant permissions to the Orchestrator environment. I went through the different nodes and folders using the runbook Designer to grant permissions for this group.

    I added my test account into the group and I can then access all the objects in both the Runbook Designer and the Web Console.

    I then removed myself from the group (and logoff/logon) and I can no longer get access to anything in the Runbook Designer - as expected.

    However, when I open the Web Console I can still access everything, including starting/stopping runbooks.

    I've tried restarting the Web Server (the whole OS, not just IIS) and also restarting the Management Server, logged off my test account and tried again after restarting everything. I still can't access through Designer, but the Web Console *still* give me full control.

    I've checked through all the folders and groups and my test account isn't listed anywhere to give it other permissions that I have been able to find.

    Is there something "caching" my permissions somewhere or just giving me full rights regardless?

    Scott.

    Wednesday, February 27, 2013 1:41 AM

Answers

  • Scott,

    There is a known bug in the permissions granted by the Orchestrator web console under certain scenarios where users receive elevated rights.  I had this exact scenario myself in our environment.  I ended up opening a ticket with Microsoft and they provided me with an updated SQL stored procedure that fixed the issue.  They confirmed that this issue still exists in SP1.

    Thanks,
    Vaughn

    Wednesday, February 27, 2013 3:15 PM
  • I put a call into Microsoft and have confirmed that there is an updated Stored Procedure (Microsoft.SystemCenter.Orchestrator.GetSecurityToken) that seems to correct the issue. It *should* have been part of SP1, but looks like it has been missed for some reason (maybe not fully tested?)

    After updating with the new SP they sent me, I also needed to uninstall and re-install the Web Console, and it appears to have fixed the problem.

    update: Microsoft have given me the all clear to share the fix. I've posted it on my blog here:

    http://kickthatcomputer.wordpress.com/2013/02/28/orchestrator-2012-web-console-permissions-do-not-resest/



    Friday, March 1, 2013 4:56 AM

All replies

  • Hi,

    yes, it's caching. You'll have to wait 20 minutes or Execute "TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache" on the Orchestrator DB: http://www.sc-orchestrator.eu/index.php/scoblog/66-orchestrator-runbooks-missing-in-orchestrator-webconsole-or-service-manager

    Regards,

    Stefan


    German Orchestrator Portal , My blog in English

    Wednesday, February 27, 2013 4:03 AM
    Answerer
  • I've waited a lot longer than 20 minutes, I actually left it over-night after giving up on it yesterday.

    I looked at that table and it's already empty. I did the TRUNCATE anyway, but it didn't make any difference.

    Where does the "20 minutes" time come from? Is there a scheduled task or hard-coded value in a service that is supposed to be doing house-keeping that isn't working for me?

    Wednesday, February 27, 2013 4:23 AM
  • Hi Scott, the 20 minutes are from table [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Maintenance].[MaintenanceTasks] But table [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache doesn't seem to solve you problem because after truncating you experience the same problem. Regards, Stefan

    German Orchestrator Portal , My blog in English

    Wednesday, February 27, 2013 6:46 AM
    Answerer
  • Just out of curiosity, Do you know what uses that setting to perform the actual cleanup then?

    Any other thoughts for what might be causing the main issue? I'll try putting my account back into the group to see if that "resets" anything that got stuck.

    Wednesday, February 27, 2013 7:57 AM
  • Hi,

    the permissions for the Runbooks are set in Designer. Click right on Runbooks and choose "Permissions ...".

    Regards,

    Stefan


    German Orchestrator Portal , My blog in English

    Wednesday, February 27, 2013 8:28 AM
    Answerer
  • Yes, I know where the permissions are set, the issue is that once the permissions are removed, the account still has the permissions when going through web console. In Designer the permissions are acting correctly as they are set.
    Wednesday, February 27, 2013 8:31 AM
  • Hi,

    as I read from your initial post to this thread you are managing the permissions with Group Memberships. My intend was to control if the expected groups are set in the permissions.

    When you test the permissions with Designer do you see only the folders you set permission as expected or something else?

    Regards,

    Stefan


    German Orchestrator Portal , My blog in English

    Wednesday, February 27, 2013 8:47 AM
    Answerer
  • In Designer I only have the access granted according to the group memberships I have configured and granted permissions. If I remove a user from a group, the permissions in Designer are also removed from that user.

    If that user then connects to the Web Console however, they still have all the permissions. It seems like it is holding permissions as a persistent setting and not re-evaluating them for the user when going through the web console.

    Wednesday, February 27, 2013 11:42 AM
  • Hi again,

    if the User which connects to Orchestration Console has signed again to Windows I should work... if not I'm out, sorry.

    For access to designer the user needs (normally) access to omanagement (http://support.microsoft.com/kb/2779526)

    Good luck!

    Stefan



    German Orchestrator Portal , My blog in English

    Wednesday, February 27, 2013 11:52 AM
    Answerer
  • Scott,

    There is a known bug in the permissions granted by the Orchestrator web console under certain scenarios where users receive elevated rights.  I had this exact scenario myself in our environment.  I ended up opening a ticket with Microsoft and they provided me with an updated SQL stored procedure that fixed the issue.  They confirmed that this issue still exists in SP1.

    Thanks,
    Vaughn

    Wednesday, February 27, 2013 3:15 PM
  • Thanks for trying though Stefan. Don't worry, I'm sure  I'll come up with plenty of other questions you can help answer. :D
    Wednesday, February 27, 2013 8:21 PM
  • I put a call into Microsoft and have confirmed that there is an updated Stored Procedure (Microsoft.SystemCenter.Orchestrator.GetSecurityToken) that seems to correct the issue. It *should* have been part of SP1, but looks like it has been missed for some reason (maybe not fully tested?)

    After updating with the new SP they sent me, I also needed to uninstall and re-install the Web Console, and it appears to have fixed the problem.

    update: Microsoft have given me the all clear to share the fix. I've posted it on my blog here:

    http://kickthatcomputer.wordpress.com/2013/02/28/orchestrator-2012-web-console-permissions-do-not-resest/



    Friday, March 1, 2013 4:56 AM
  • Hey Stefan,

    Just thought I'd let you know MS confirmed the issue, gave me a technet link to a "related" issue and also gave me permission to share the fix (see answer at end of thread)

    Scott.

    Tuesday, March 5, 2013 1:02 AM