Discussion:
Strange secutity issue with DFS
(too old to reply)
JackH
2009-07-22 23:48:50 UTC
Permalink
Hello,

Windows 2008.

I currently have a DFS share named Termed Staff which contains a folder of
each staff name and their documents.

Now, I have a security group "SEC-Termed Staff" which allows staff access to
this folder and maps the drive letter.

Security is not inherited within the Termed Staff folder. The only
permissions are System, Domain Admin-Full access, and the local
administrator.

My plan is to assign staff read only permissions to the specific folders
within on an as needed basis.

What I am finding is that currently anyone is able to access these folders
within the Termed Staff folder and create folders.

I'm going crazy trying to find out why they can access these folders when
they are ont in any of the groups that have access to this. Any ideas???

I'm assuming this is realted to DFS in some way but I could be wrong.
JackH
2009-07-23 04:30:42 UTC
Permalink
I think I know what part of the issue is. i'm new with DFS so.... I had
created the DFSRoot folder and then created my folders in there and added
them to the name space. I'm thinking what I should do is create a folder at
d:\shares\Shared Folder and then add that folder to the dfs name space? Is
that the correct way to do this?
Post by JackH
Hello,
Windows 2008.
I currently have a DFS share named Termed Staff which contains a folder of
each staff name and their documents.
Now, I have a security group "SEC-Termed Staff" which allows staff access
to this folder and maps the drive letter.
Security is not inherited within the Termed Staff folder. The only
permissions are System, Domain Admin-Full access, and the local
administrator.
My plan is to assign staff read only permissions to the specific folders
within on an as needed basis.
What I am finding is that currently anyone is able to access these folders
within the Termed Staff folder and create folders.
I'm going crazy trying to find out why they can access these folders when
they are ont in any of the groups that have access to this. Any ideas???
I'm assuming this is realted to DFS in some way but I could be wrong.
DaveMills
2009-07-23 05:48:37 UTC
Permalink
Post by JackH
I think I know what part of the issue is. i'm new with DFS so.... I had
created the DFSRoot folder and then created my folders in there and added
them to the name space. I'm thinking what I should do is create a folder at
d:\shares\Shared Folder and then add that folder to the dfs name space? Is
that the correct way to do this?
You can create folders in the DFSRoot and they will be C:\DFSRoot\Newfolder but
you cannot add other physical folders to the name space. You can only add link
targets and they are UNC paths.
Post by JackH
Post by JackH
Hello,
Windows 2008.
I currently have a DFS share named Termed Staff which contains a folder of
each staff name and their documents.
Now, I have a security group "SEC-Termed Staff" which allows staff access
to this folder and maps the drive letter.
Security is not inherited within the Termed Staff folder. The only
permissions are System, Domain Admin-Full access, and the local
administrator.
My plan is to assign staff read only permissions to the specific folders
within on an as needed basis.
What I am finding is that currently anyone is able to access these folders
within the Termed Staff folder and create folders.
I'm going crazy trying to find out why they can access these folders when
they are ont in any of the groups that have access to this. Any ideas???
I'm assuming this is realted to DFS in some way but I could be wrong.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
JackH
2009-07-23 14:58:20 UTC
Permalink
Cool. I have ran into something else and may be this is by design.

I'm setting the permissions for folders on the server, not via the
namespace. What I'm finding is that if I don't remove the
Domain\Administrator account, not the Domain\Domain Administrator account,
staff have full rights to the folders. Why would this be as they are not
members of this adminsitrator account.
Post by DaveMills
Post by JackH
I think I know what part of the issue is. i'm new with DFS so.... I had
created the DFSRoot folder and then created my folders in there and added
them to the name space. I'm thinking what I should do is create a folder at
d:\shares\Shared Folder and then add that folder to the dfs name space?
Is
that the correct way to do this?
You can create folders in the DFSRoot and they will be
C:\DFSRoot\Newfolder but
you cannot add other physical folders to the name space. You can only add link
targets and they are UNC paths.
Post by JackH
Post by JackH
Hello,
Windows 2008.
I currently have a DFS share named Termed Staff which contains a folder of
each staff name and their documents.
Now, I have a security group "SEC-Termed Staff" which allows staff access
to this folder and maps the drive letter.
Security is not inherited within the Termed Staff folder. The only
permissions are System, Domain Admin-Full access, and the local
administrator.
My plan is to assign staff read only permissions to the specific folders
within on an as needed basis.
What I am finding is that currently anyone is able to access these folders
within the Termed Staff folder and create folders.
I'm going crazy trying to find out why they can access these folders when
they are ont in any of the groups that have access to this. Any ideas???
I'm assuming this is realted to DFS in some way but I could be wrong.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
IT Staff
2009-07-24 01:34:51 UTC
Permalink
i m having the same security issues with u.

it is common to set permissions on the remote servers and then use DFS to
add these remote servers as target folders.

But i realised that if u setup a hub/spoke, the hub member server
permissions will be overrides the remote server target folders.

i've not try anything yet, one thing u can try is to assigned the hub member
server to have the same permissions as the rest of the remote servers and
see whether this works.
Post by JackH
Cool. I have ran into something else and may be this is by design.
I'm setting the permissions for folders on the server, not via the
namespace. What I'm finding is that if I don't remove the
Domain\Administrator account, not the Domain\Domain Administrator account,
staff have full rights to the folders. Why would this be as they are not
members of this adminsitrator account.
Anthony [MVP]
2009-07-24 10:52:07 UTC
Permalink
Something else has gone wrong.
The NTFS security is replicated. So you should start with both target folder
roots having the same permissions. If they have different permissions you
will get a strange result, where a root permission does not trickle down
even though it says it does. You should never set permissions on the DFS
root folders. These are just storing information about the DFS target, and
users obviously need to be able to read the information.
You can set different Share permissions on the target folders. These are not
replicated. So for example you could enable the helpdesk to modify files at
a central site, but make a hub site Read Only.
Hope that helps,
Anthony
http://www.airdesk.com
Post by IT Staff
i m having the same security issues with u.
it is common to set permissions on the remote servers and then use DFS to
add these remote servers as target folders.
But i realised that if u setup a hub/spoke, the hub member server
permissions will be overrides the remote server target folders.
i've not try anything yet, one thing u can try is to assigned the hub
member server to have the same permissions as the rest of the remote
servers and see whether this works.
Post by JackH
Cool. I have ran into something else and may be this is by design.
I'm setting the permissions for folders on the server, not via the
namespace. What I'm finding is that if I don't remove the
Domain\Administrator account, not the Domain\Domain Administrator
account, staff have full rights to the folders. Why would this be as
they are not members of this adminsitrator account.
Loading...