none
Policy to disable remote shell on win7

    Question

  • I've seen this asked a bunch of times but can find no answer.  The win7 policy is computer > admin templates > windows components > windows remote shell > allow remote shell access.  The description reads:

    If you enable this policy setting and set it to False, new remote shell connections will be rejected by the server.

    There is no option to set to false.  My goal is to ensure my win7 desktops can neither send nor receive remote shell commands.

    Thanks,

    Jaime

    Tuesday, January 08, 2013 5:18 PM

Answers

  • Hi,

    Sorry for "thinking it is so".

    Based on my reseach, the corresponding registry key with the policy(computer Configuration\ admin templates\windows components\windows remote shell\allow remote shell access) is the following:
    HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\WinRS\allowremoteshellaccess

    The default value is True, that means "Allow remote shell access". If you set this parameter to False, the remote shell connections will be rejected by the server, that's what "set it to false" means.

    So just follow the description and "enable" the policy (that would set the registry to false) to reject the remote shell access. (It's really wierd for the policy is called "Allow remote shell access" :(  )

    Regards,
    Cicely

    • Marked as answer by JaimeBisceglia Thursday, January 10, 2013 7:48 PM
    Thursday, January 10, 2013 2:11 AM

All replies

  • Hi,

    Set it to False means set it to "Disabled", that would be OK.

    Regards,
    Cicely

    Wednesday, January 09, 2013 3:07 AM
  • So that would translate to "If you enable this policy and set it to disabled".. this makes even less sense :)  The one thing that is clear from the description is that setting to disabled means connections will be allowed.  Full description is:

    Configures access to remote shells.

    If you enable this policy setting and set it to False, new remote shell connections will be rejected by the server.

    If you disable or do not configure this policy setting, new remote shell connections will be allowed.


    Wednesday, January 09, 2013 3:35 PM
  • Hi,

    Sorry for "thinking it is so".

    Based on my reseach, the corresponding registry key with the policy(computer Configuration\ admin templates\windows components\windows remote shell\allow remote shell access) is the following:
    HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\WinRS\allowremoteshellaccess

    The default value is True, that means "Allow remote shell access". If you set this parameter to False, the remote shell connections will be rejected by the server, that's what "set it to false" means.

    So just follow the description and "enable" the policy (that would set the registry to false) to reject the remote shell access. (It's really wierd for the policy is called "Allow remote shell access" :(  )

    Regards,
    Cicely

    • Marked as answer by JaimeBisceglia Thursday, January 10, 2013 7:48 PM
    Thursday, January 10, 2013 2:11 AM
  • I think you got it, thanks!  FYI I am deciding to keep it simple and completely disable the WinRS service on all machines.  I don't think this GPO will do anything in addition.
    Thursday, January 10, 2013 7:51 PM
  • To me this still does not make sense.

    "HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\WinRS\allowremoteshellaccess

    The default value is True, that means "Allow remote shell access". If you set this parameter to False, the remote shell connections will be rejected by the server, that's what "set it to false" means."

    So, the default value is "True".  What is actually in the registry is this (allowremoteshellaccess "1") It is my understanding that 1 is equal to True and 0 is equal to false. Is this correct? 

    If we want to prevent remote shell connections then we would want it to be "false" which is "0".

    What confuses me and other people is that you stated in your next few lines. 

    "So just follow the description and "enable" the policy (that would set the registry to false) to reject the remote shell access."  

    So this indicates to me that what you are now saying is that it defaults to false because this sentence says"(that would set the registry to false)" 

    I think that what you meant to say is that in order to set it to false "allowremoteshellaccess" must be set to "0" That would really be the only thing that makes sense here. Or should we do like you say and leave it as "1"?

    Friday, October 04, 2013 6:44 PM
  • Having a look at WindowsRemoteShell.admx reveals how this setting works:

        <policy name="AllowRemoteShellAccess" class="Machine" displayName="$(string.AllowRemoteShellAccess)" explainText="$(string.AllowRemoteShellAccess_Help)" key="Software\Policies\Microsoft\Windows\WinRM\Service\WinRS" valueName="AllowRemoteShellAccess">
          <parentCategory ref="WinRS" />
          <supportedOn ref="windows:SUPPORTED_WindowsVista" />
          <enabledValue>
            <decimal value="1" />
          </enabledValue>
          <disabledValue>
            <decimal value="0" />
          </disabledValue>
        </policy>

    So, if you enable the policy setting in question, remote shell access is enabled and allowed. If you disable the policy setting, remote shell access is disabled.

    The irritation in this question is that the explanation of this setting simply is wrong...


    Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))

    Restore the forum design - my user defined Cascading Style Sheet!

    Saturday, October 05, 2013 1:24 PM
  • How they passed a security audit is beyond me.
    Saturday, October 05, 2013 10:28 PM
  • Beyond me, too... Maybe some kind of copy/paste error.

    Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))

    Restore the forum design - my user defined Cascading Style Sheet!

    Sunday, October 06, 2013 11:36 AM