by: Helge, published: Jul 23, 2010, updated: Oct 27, 2010, in

How to Modify Default Share Permissions and Other Tweaks

NTFS permissions are stored in the file system, that is well known. But where are share permissions stored?

As so often with Windows: in the registry. Network shares are defined by only a handful of relatively simple registry entries stored in the server service’s key which is, for historical reasons that go back way beyond OS/2, named “LanmanServer” (the workstation service is similarly named “LanmanWorkstation”).

The share definitions can be found here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares

There is one value per share of type REG_MULTI_SZ. The value name corresponds to the share name.

Permissions are stored in the subkey “Security”:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares\Security

Again, there is one value per share, this time of type REG_BINARY.

Now, what can you do with this information?

Migrate

For one, you could implement a low-level method of migrating shares from one server to another. Although crude, this method seems to have been popular enough to warrant an official description in Microsoft’s Knowledge Base.

Tweak

Or you could recreate share permissions in the style en vogue till Windows XP. Up to Server 2003 network shares had no security (descriptor) whatsoever on them. Being naked, they allowed full access to everyone. That changed with Server 2003 and XP SP1, where nakedness was not deemed secure enough any more and network shares got restrictive default permissions that only allowed read access, which then had to be changed by the administrator to full access again. Sigh.

In my case I needed to create a share with a NULL security descriptor to test my permission manipulation tool SetACL. Creating such a beast is not so easy. When deleting all access control entries (ACEs) from the DACL, you do not get a NULL security descriptor granting full access to everyone, but instead an empty DACL that block every kind of access! Here is a sample SetACL command that clears all non-inherited ACEs from a DACL:

D:\>setacl -on test -ot shr -actn list
"test",5,"DACL(not_protected):[empty]"

So I had to resort to the low-level registry method to create my NULL-SD share:

  1. Stop the server service
  2. Rename the registry value that stores the security descriptor for my share “test”: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares\Security\test -> testX
  3. Start the server service

Voilà! Now SetACL prints out the following when listing permissions of the share “test”:

D:\>setacl -on test -ot shr -actn list
INFO: The object <test> has a NULL security descriptor (granting full control to everyone) and is being ignored.

Change Default Share Permissions

The LanmanServer registry key not only stores the permissions for existing shares, but also a default security descriptor assigned to new shares upon creation. With the following information it is easy to modify the permissions newly created shares get by default, and recreate the comfortable situation we had before Windows Server 2003, for example.

Default share permissions are stored in the binary value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity\SrvsvcDefaultShareInfo

That value is not present by default. In order to create it and populate it with useful content, follow these steps:

  1. Create a template share named, for example, test.
  2. Assign appropriate permissions to your template share “test” using the GUI.
  3. Double-click the value storing the security descriptor of your “test” share: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares\Security\test. Select everything (!) by pressing CTRL+SHIFT+END. Copy the selection with CTRL+C.
  4. Create a new empty binary value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity\SrvsvcDefaultShareInfo.
  5. Double-click SrvsvcDefaultShareInfo and press CTRL+V to paste the binary representation of the security descriptor you copied earlier.
  6. Restart the “server” service (aka LanmanServer).
  7. Create a new share. You will notice that it immediately has the same permissions you assigned to the “test” share.
  8. You may now delete the “test” share.

More Tweaks

In addition to SrvsvcDefaultShareInfo the key LanmanServer\DefaultSecurity has some other very interesting values that all store security descriptors and that might warrant playing around with:

  • SrvsvcConfigInfo: Manage file and printer sharing
  • SrvsvcConnection: Manage file/print server connections
  • SrvsvcFile: Manage file server open files
  • SrvsvcServerDiskEnum: Enumerate file servers disks
  • SrvsvcSessionInfo: Manage file/print server sessions
  • SrvsvcShareAdminConnect: Connect to administrative shares
  • SrvsvcShareAdminInfo: Manage administrative shares
  • SrvsvcShareChange: ?
  • SrvsvcShareConnect: Connect to file and printer shares
  • SrvsvcShareFileInfo: Manage file shares
  • SrvsvcSharePrintInfo: Manage printer shares
  • SrvsvcStatisticsInfo: Read file/print server statistics
  • SrvsvcTransportEnum: Enumerate server transport protocols

The TweakUI tool seems to have an option to manipulate these security descriptors, although I admit I have not tried that out.

Previous Article EFS Encryption and CopyFile(Ex): Why DIY is Better
Next Article Taking Ownership Fails With UNC Path, Works Locally!?! Why?