Hidden Shares and Novell Storage Manager
Novell Cool Solutions: Feature
Digg This -
Posted: 27 Sep 2006
A Forum reader asked this question:
"I have a 200-user AD system in a test domain. I would like to copy a 16Mb file into the home directories of all users. The home directories don't exist yet.
When I select 'Storage template' or 'Vault Path' in 'User Policy Properties' the only option I appear to have is to use \\servername\NSMProxyhome rather than \\servername\C$\setup, which is the directory containing the 16Mb file I want to backfill my user directories with. The NSMProxyRights group has full rights to \\servername\C$\setup. Am I missing something obvious?"
And here's the response from the experts at Condrey Consulting ...
You need to create a visible share for your template. NSM does not use any hidden shares. Once you have added the visible share you will need to use the Rebuild Share list found in Utilities, under the Admin Dashboard. This will make the share available without restarting the NSMEngine service.
We had some internal discussions during development of the NSM-AD product w/respect to the issues regarding visible shares vs. hidden shares. We decided to not display the hidden shares for two main reasons. One is that in keeping with the common look and feel of other Windows applications, displaying hidden shares would introduce non-standard behavior in the user's experience with the UI. The other is that there are typically many more hidden shares present than there are visible shares, and not all of those shares are even file system shares. Many can be printers, communications ports and other more esoteric devices that are still present as shares. Displaying hidden shares would drastically increase the "noise level" w/o any increase in the "signal level" in terms of conveying information to the user.
Incidentally, although "C$" does provide shared access to the root folder of a drive on a server, it's technically not identified as a file share. It falls into the category of special administrative shares. There's a registry setting you can toggle that enables or disables the automatic creation of special administrative shares at system boot time.
Technically, at the low level when a program is enumerating shares, *all* shares are being provided to us by the Win32 API functions that we use to enumerate the shares that any given server has published. There's nothing in particular that is special about a hidden share except for the fact that it has a trailing "$" character in its name, which Microsoft has designated as meaning that the share shouldn't be listed in "normal" user interfaces.
Since all share names are visible at the API function level, there's no gaping security hole introduced by whether or not a share is visible or hidden, other than the fact that the share's existence is detectable thru normal user interfaces such as the Windows Explorer. However, non-privileged users can run the server admin program in Windows and see hidden shares w/o any extra privs being required. Again, a share being hidden doesn't add any additional security to the share.
On the Windows NT platform, shares have 2 levels of security associated with them. The first level of security is on the share itself, and you can assign permissions directly to the share that limits what sorts of operations can be done on the share. By default, a share has "Everyone - Read" access. If you want to secure the share further, you remove the permission assignment [equivalent to a trustee asignment in NetWare] for "Everyone" and grant explicit permissions to only the users & groups that you want to have any access to the share. Since it is required that a user have an identity that has been authenticated by a domain controller in the AD forest, it is impossible for any arbitrary unauthenticated user to access a share in any way since they lack the identification required to pass thru the share's assigned list of permissions.
Now, the second level of security associated with a share is actually the permissions assigned to the underlying file system folder that is actually being shared. Typically, this is for a folder on a NTFS volume, and there's a very richly featured set of permissions that can be granted with a fine degree of granularity. If a FAT32 volume had a folder shared, there wouldn't be any permissions on the folder itself. If a NFS volume were being shared, again, the permissions would be limited to whatever NFS is capable of supporting.
When a NTFS folder is shared, the access to it that users get will be the intersection of the share's permissions and the NTFS folder's permissions. If the share only grants "read" access but the NTFS folder's permissions allow "read" and "write", the user will still only get "read" access. So, typically, what is done is that on the share, "read" and "write" access are granted to Everyone and then on the NTFS folder itself more fine-grained permissions are assigned.
Again, relating to security, a user must have an identity established by having a domain controller authenticate their credentials. By default, all shares require users to be authenticated and to have an identity, so there's no issues related to shares requiring "strong passwords" being assigned to them. Back in the days of Windows for Workgroups and Windows 95/98/Me, yes, you'd assign passwords to a share, but that's not something that gets done in a domain environment and there's no mechanism for applying share-level passwords on the NT platform.
Incidentally, NSM isn't enumerating the shares in real-time when you go browsing for storage targets or storage templates. The Engine does a nightly scan to rebuild the list, or, as you've seen in the UI, you can manually initiate a rebuild of the list. Due to the large number of servers that may exist in some environments, and the cost in network I/O and the delay in elapsed time required to obtain the list of shares, it was decided to build the list once a day. That's because it shouldn't be changing frequently, and a manual rebuild can be done if needed due to the addition of a new share. Using this cached list of share names drastically speeds up the performance of the UI, as the Engine can directly send it the list of shares instead of making the user wait for shares to be dynamically enumerated, on-the-fly.
I'm not aware of any immediate plans to allow hidden shares to be enumerated and displayed, so, if needed for the short term, you can establish multiple share names for the same folder. If you have "C:\Templates" on a NTFS volume, you might have an existing share named "Templates$". You could create an additional share for the same folder, with the new share not being hidden. The new share could even have different security from the hidden share, although both shares would still intersect with the underlying NTFS permissions applied to the folder itself. This would allow legacy access to the hidden share without making any changes to access the share under a new name, while at the same time allowing NSM to enumerate a visible share to the same folder.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com