M
Mark Rockman
If you go to Help and Support and navigate to NET USE
documentation, there is an implication (by the absence of
explanation) that the reader is familiar with how the
operating system works when a drive letter is to become
associated with a network file shared folder (aka
a "share.") Per an undocumented protocol, in the default
case, in which the user does not specify a userid/password
combination, the userid/password combination of the
requesting context is passed to the computer on which the
share resides. That computer validates the combination in
its own context which may be a domain or may be a local
security database of a workgroup. A carelessly created
workgroup will not necessary have every userid/password
combination defined on every workgroup member computer.
Therefore, NET USE, or its GUI equivalent, will solicit a
userid/password combination. The user interaction in no
way indicates that the combination required is in the
context of the share, not in the context of the logged in
user. This is excessively confusing. Also, shares that
require user interaction to establish, fail to reestablish
automatically at the next login, further confusing the
user. Recommendations: change the user interface to
ensure the user understands the mechanism and therefore is
able to enter the userid/password combination of the
context of the share that the system desires; change the
help and support materials so that the mechanism is
crystal clear to the user. The common understanding that
network file shares are wildly insecure needs to be
rectified in light of the fact that encrypted passwords
are required to be sent in the workgroup case. They may
be insecure, but not wildly.
documentation, there is an implication (by the absence of
explanation) that the reader is familiar with how the
operating system works when a drive letter is to become
associated with a network file shared folder (aka
a "share.") Per an undocumented protocol, in the default
case, in which the user does not specify a userid/password
combination, the userid/password combination of the
requesting context is passed to the computer on which the
share resides. That computer validates the combination in
its own context which may be a domain or may be a local
security database of a workgroup. A carelessly created
workgroup will not necessary have every userid/password
combination defined on every workgroup member computer.
Therefore, NET USE, or its GUI equivalent, will solicit a
userid/password combination. The user interaction in no
way indicates that the combination required is in the
context of the share, not in the context of the logged in
user. This is excessively confusing. Also, shares that
require user interaction to establish, fail to reestablish
automatically at the next login, further confusing the
user. Recommendations: change the user interface to
ensure the user understands the mechanism and therefore is
able to enter the userid/password combination of the
context of the share that the system desires; change the
help and support materials so that the mechanism is
crystal clear to the user. The common understanding that
network file shares are wildly insecure needs to be
rectified in light of the fact that encrypted passwords
are required to be sent in the workgroup case. They may
be insecure, but not wildly.