DFS mapped to workstation share can't be accessed from workstation

Is there a restriction that stops me following the DFS path to a shared folder
on a workstation from that same workstation? Details of the configuration follow

I have a domain DFS Root hosted on 2 W2003 R2 member servers called
"\\waingels.wokingham.sch.uk\storage"
I created a shared folder on my workstation (105B) and shared it as
\\105B\Backups. In it I created a folder called 105B
Then I created a new DFS folder in the DFS Root called Backups (using the DFS
Management console)
In the backups folder I created a link called 105B to \\105B\Backups\105B

From the PC 105B I cannot access the folder
"\\waingels.wokingham.sch.uk\storage\backups\105B"
From all others PC I have tried I can access the folder OK. I can access the
share \\105B\backups and navigate to the folder 105B without error. The error
only occurs when I use the DFS path. I am logged in a Domain Admin

The error I get is <share> is not available. .... The network path was not
found.

 

You are correct--these "loopback" targets are disabled in XP SP2 clients by
default for security purposes. This can be adjusted in the registry of the
client. Just add a value (REG_DWORD) named "EnableDfsLoopbackTargets" to
HKLM/System/CurrentControlSet/Services/Mup/Parameters and set it to 1, then
reboot the client.

 

Thanks. It will only affect a few workstations so the reg hack is no problem. I
don't recall reading this in the How DFS works docs or elsewhere but then I may
have not realised the significance at the time. Searching Technet for the reg
value does not get any hits and it's not documented in the DFS Client Registry
Setting section of DFS Tools and Settings. (Perhaps it should be added to that
documentation set.)

I am a little curious about the logic that it is for security reasons. When on
the client I have total control of all data stored locally so preventing access
via DFS does nothing to prevent access to the data, The user can just access it
locally. What security issue does this restriction address? Just my curious mind
<g>

The only way I see to handle security is with correctly set up NTFS permissions
and restricting access to the drive via GPO.

 

Hi Dave,

You're right that this isn't listed in the Techref. I think this key was
added back for XPSP2 as part of the security enhancements but I don't recall
the exact reasons. I'll get the Techref updated and dig around for some
history on this.


--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies?

Visit our team blog at http://blogs.technet.com/filecab/default.aspx.

 

Hi again Dave,

The change in XPSP2 reduces the attack surface for SMB but I don't have
specific details about the reasoning behind this. It's not related to NTFS
or file security.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.