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

Discussion in 'File Systems' started by Dave Mills, Jul 5, 2006.

  1. Dave Mills

    Dave Mills Guest

    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.
     
    Dave Mills, Jul 5, 2006
    #1
    1. Advertisements

  2. 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.
     
    Jill Zoeller [MSFT], Jul 5, 2006
    #2
    1. Advertisements

  3. Dave Mills

    Dave Mills Guest

    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.
     
    Dave Mills, Jul 6, 2006
    #3
  4. 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.
     
    Jill Zoeller [MSFT], Jul 6, 2006
    #4
  5. 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.



     
    Jill Zoeller [MSFT], Jul 7, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.