none
Admin shares available to non-administrative users over loopback address RRS feed

  • Question

  • I have several RemoteApp hosts, they all have MS excel installed. All hosts are covered with multiple lockdown technologies including Applocker, Group Policy and IPSec. All drives are restricted via GPO along with modified permissions.

    Scenario.

    A non-administrative user starts Excel on a RemoteApp host. They open the "file open" window and in file name type \\127.0.0.1\c$. They are presented with the c:\ drive of the system. The same is true of c$ d$ admin$ etc...

    The same user typing \\127.0.0.1\c$ in the address\location bar of open file window is told that this has been restricted by their system administrator.

    The same user attempting to acess the admin shares from another machine is prompted for credentials.

    Why does the loopback adapter appear to ignore the admin share permissions?

    Tuesday, May 14, 2013 12:11 PM

Answers

  • Probably the last update on this. The support Rep has emailed the following.

    "This behavior occurs because the administrative share's default share permission was changed in Windows Server 2008, which allows the active logon account to access the administrative shares.

    The administrative share's default share permission is controlled by the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\DefaultSecurity\SrvsvcShareAdminConnect.

    To configure Windows Server 2008 to behave the same as Windows Server 2003, we can export the registry value above from Window Server 2003, and import it to Windows Server 2008. Please Note: We need to restart the server for the change to take effect."

    I have tested this fix on my W2K8 R2 SP1 machine and i can confirm that non-administrative users started getting the prompt for user name & password.

    For those wanting to achieve the same behaviour, you can find the registry binary data you need to import below.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\DefaultSecurity]
    "SrvsvcShareAdminConnect"=hex:01,00,04,80,64,00,00,00,70,00,00,00,00,00,00,00,\
      14,00,00,00,02,00,50,00,03,00,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,\
      00,00,05,20,00,00,00,20,02,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,00,\
      00,05,20,00,00,00,25,02,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,00,00,\
      05,20,00,00,00,27,02,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,00,00,\
      00,00,00,05,12,00,00,00

    • Marked as answer by DanMartinelli Tuesday, June 4, 2013 4:16 PM
    Tuesday, June 4, 2013 4:16 PM

All replies

  • Hi,

    Thanks for posting in Microsoft TechNet forums.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Thank you for your understanding and support.

    Regards

    Kevin

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

     
    Wednesday, May 15, 2013 4:14 AM
  • Hi,

    I did a test on my PC and found that I could use a non-admin account to access c$ either in file name or in the address\location bar with no issues. I think when we use the \\127.0.0.1 to browse the files, we won't just use the share permission, file permission is also used.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, May 17, 2013 10:01 AM
  • Hi Laura,

    Thanks for verification of the issue. The address\location bar is restricted via policy in my environment so I wouldn't expect it to work, however I an still surprised by the file name in conjunction with 127.0.0.1.

    Until a complete technical explanation of the issue can be reached I’ve disabled the admin shares.


    Friday, May 17, 2013 1:09 PM
  • is the guest account enabled on your server?

    MCP/MCSA/MCTS/MCITP

    Friday, May 17, 2013 1:42 PM
  • No, there are no guest accounts enabled on any server of the servers.
    Friday, May 17, 2013 2:01 PM
  • UPDATE:

    After disabling the admin shares, and creating new shares to replace them using a the local administrators group in the share permissions. The non-administrative users are told that they do not have permission to access the share.

    I think I'm missing something. What's the difference between the automatically created admin share permissions and the manually created shares using the local administrators group?

    Friday, May 24, 2013 10:17 AM
  • The only differnce I know of is the way they are stored.

    Normals shares are stored in HKLM\SYSTEM\CurrentControlSet\Services\Lanmanserver\shares

    The administrative shares ar ot stored there but are shared each time the 'server'  service (=lanmanserver)  starts, which leads to the belief they are hardcoded into svchost.

    However there are some things that can be configured for the administrative shares in  HKLM\SYSTEM\CurrentControlSet\Services\Lanmanserver, bot in \parameters as in \defaultsecurity

    I could not reproduce your issue in any of my testenvironment servers. I suggest you compare the \lanamanserver keys to those of running servers that do not show the same issue. Some configuration might have changed settings that produce the issue.


    MCP/MCSA/MCTS/MCITP

    Friday, May 24, 2013 11:29 AM
  • Thanks for the quick response SenneVL.

    Please can you confirm the OS of your testing environment.

    I have verified this problem on 4 machines in 3 forests. 3 WS2008 R2 SP1 servers with the Remote Desktop Services role instaled and one Windows 7 SP1 workstation. So I have no baseline for comparison. Would it be possible for you to send me your \paramaters and \defaultsecurity keys to use as a baseline control?

    Friday, May 24, 2013 12:49 PM
  • I'm sorry to have to tell you it will not help :/

    I've verified the issue on a Windows 2008 R2 SP1 with only application server role installed. I created a local user, added it to remote desktop users and did logon using RDP. I confirm that i can connect to \\127.0.0.1\c$ in this setup.

    This does not occur in 2003/2003 r2 (verified). There, as expected, a login prompt appears. I will again verify this for 2008 and 2012 later today. As I recall, I tested it few days ago on some random servers, probably Windows 2012.

    I guess this is one for Microsoft to solve!


    MCP/MCSA/MCTS/MCITP


    • Edited by SenneVL Friday, May 24, 2013 1:50 PM
    Friday, May 24, 2013 1:44 PM
  • I opened a support ticket and a Microsoft representative has confirmed that this behavious is "by design". We've not closed the case yet but i'll post the outcome here when we do. I'm not sure if i'll ever get the reason behind it being "by design".
    Monday, June 3, 2013 9:09 AM
  • It might be a case of "broken by design" :'(

    Please keep me/us posted!


    MCP/MCSA/MCTS/MCITP

    Monday, June 3, 2013 9:13 AM
  • Yesterday I received an email from the support representative bringing KB314984 to my attention. This KB doesn't really tell us anything we didn't already know. However there was one interesting pont he added at the end.

    "...Windows created for root partitions and volumes (such as C$) and the system root folder (ADMIN$). This is administrative share, that is accessible remotely by administrators only. However C: of local share is accessible by default by user, that has local access permission."

    In response to this I posed the question "By this do you mean that the share permissions are ignored in favour of the DACL?" and received the response "Yes you are correct the share permissions are ignored in favour of the DACL."

    Again I asked the question "If this is true then why when I create a share of the C drive, using the local administrator group in the share permissions, does a non-administrative user accessing the share over the loopback address get denied access? The same DACL exists. By the logic above, the share permissions do not matter if a loopback address is used."

    I just got off the phone with the support representative again, who told me that there is no difference in share permissions between the auto-created shares of c$ d$ etc... and a manually created one using the BUILTIN\Administrators group. This is still considered a "by design" feature however he has forwarded my question to his superior and the Microsoft connect team for deeper analysis.

    I've asked for a technical explanation of the difference.

    • Edited by DanMartinelli Tuesday, June 4, 2013 11:01 AM formatting
    Tuesday, June 4, 2013 10:59 AM
  • Probably the last update on this. The support Rep has emailed the following.

    "This behavior occurs because the administrative share's default share permission was changed in Windows Server 2008, which allows the active logon account to access the administrative shares.

    The administrative share's default share permission is controlled by the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\DefaultSecurity\SrvsvcShareAdminConnect.

    To configure Windows Server 2008 to behave the same as Windows Server 2003, we can export the registry value above from Window Server 2003, and import it to Windows Server 2008. Please Note: We need to restart the server for the change to take effect."

    I have tested this fix on my W2K8 R2 SP1 machine and i can confirm that non-administrative users started getting the prompt for user name & password.

    For those wanting to achieve the same behaviour, you can find the registry binary data you need to import below.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\DefaultSecurity]
    "SrvsvcShareAdminConnect"=hex:01,00,04,80,64,00,00,00,70,00,00,00,00,00,00,00,\
      14,00,00,00,02,00,50,00,03,00,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,\
      00,00,05,20,00,00,00,20,02,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,00,\
      00,05,20,00,00,00,25,02,00,00,00,00,18,00,03,00,0f,00,01,02,00,00,00,00,00,\
      05,20,00,00,00,27,02,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,00,00,\
      00,00,00,05,12,00,00,00

    • Marked as answer by DanMartinelli Tuesday, June 4, 2013 4:16 PM
    Tuesday, June 4, 2013 4:16 PM