You missed the part where I said this was never designed to be a
security feature but instead is used for housekeeping/display. Say, and
this is a real life example, I have a file server with 5000 home folder
shares on it called user1$ through user2$ and I have 10 project shares
on the server called proj1 through proj10. Some random user connects to
the server by \\servername to get a list of the project shares, if MSFT
didn't have the hidden mechanism the user would get a listing of 5010
shares instead of 10.
Your understanding or wish of what the $ concept is just needs to be
readjusted. It isn't about hiding it from the browse request, it is a
quick way to indicate to the client that the shares have been marked
hidden which is a guideline and a guideline only, to not display. If
MSFT intended for that to be a security feature, you can rest assured
they wouldn't be sending those share names when requested. It is simpler
not to send them than to not display them when they have been sent.
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm
Gerry Hickman wrote:
> Joe Richards [MVP] wrote:
>
>> hidden. The OS still sends the share in the list of shares for the
>> share enumeration request.
>
> In that case, it's very silly! If the enum is done by by a local process
> with a connection over DCOM then it's fair enough, it's listing shares
> that it's exposing.
>
> If it's showing up in a network browser, it defeats the whole point of
> the $ concept, which is to hide it from the browse request. Remember,
> it's not just C drives, it could be vast listings of a file server.
> You'd still have NTFS to get through, but it still defeats the whole
> point of them being "hidden".
>