There is a lot of contradictory information about the right way to secure files and folders. Even if you look at various Microsoft documents, you will find inconsistencies. Therefore, I tend to disregard the various TechNet articles and do security my way. The way that I implement security is to secure files and folders at the file level.
There are several important ground rules that I follow to make things work correctly. First, unless a user is accessing a file or folder directly from the server console, they will need a path through which to gain access to the file.
In Windows, this path is usually a share point. Therefore, although I tend not to use share level security, I still use share points as a way of letting users access the protected files from across the network. The difference is that I set the security on my shares to allow everyone to have Full Control.
I want to clear up a common myth. In Windows Server, the Everyone group contained both authenticated and nonauthenticated anonymous users. In Windows Server though, anonymous users are not a part of the Everyone group. To avoid confusion though, I only grant permissions to security groups; never to individual users. I also grant permission only to folders; rarely to individual files. Using this technique eliminates the vast majority of the confusion that may occur when granting permissions and when trying to determine who has access to what.
Inheritance Now that I have discussed the basic differences between share level and file level permissions, I want to address the issue of inheritance. Earlier I explained that a file inherits the permissions of its parent folder. You would then have to combine the inherited permissions with the explicit permissions to determine the effective permissions for the file or folder.
What made this tricky was that sometimes conflict would occur because contradictory permissions might be assigned to the parent folder and the current file or folder. In such a situation, it was easy to resolve contradictions because explicit permissions always override inherited permissions. For example, what do you do if a user is a member of two different security groups with two different levels of access to a file or folder? Again, the rights are combined and an explicit deny overrides an explicit allow.
In Windows , Microsoft took the initiative to make inheritances and effective permissions much easier to calculate. To see how the new mechanisms work, right-click on a file or folder and select the Properties command from the resulting shortcut menu. The Security tab displays assigned rights, but not inherited rights. If you want to view the inherited rights for the file or folder, you will have to click the Advanced button.
When you do, Windows will display the Advanced Security Settings properties sheet for the file or folder. This properties sheet contains a Permissions tab. The top portion of the Permissions tab displays all users and groups that have access to the file or folder. This list tells the user or group name, the type of permission Allow or Deny , and the effective permission Full Control, Read, etc.
The nice part about this list is that not only does it tell you the effective permission, it even tells you where the permission was inherited from. Another nice feature of the Permissions tab is that it contains its own set of Add, Edit, and Remove buttons. The Permissions tab also contains two check boxes that are worth mentioning. The first check box, when enabled, is designed to allow inheritable permissions from the parent to propagate this object and to all child objects.
Basically, this means that if you select this check box then the current file or folder will inherit permissions from the parent folder. It also means that if you happen to be working with a folder rather than a file, that any permissions used here, whether assigned or inherited, will apply to subfolders. This check box is selected by default.
Normally, you would want to leave this check box selected. From a Windows administration standpoint, it is considered to be bad management to deselect this check box. The reason is that if you disable inherited permissions, then it tends to become more difficult to figure out what permissions belong to which folder.
This is another check box that can get you into trouble. I strongly recommend never using this one. But, when i try to the access the file from win xp, i could not access. When i type in the username and password, it keep prompting me to type again, i'm sure i enter the correct value. By the way, the window server can access the share folder in winxp but not the other way. Anyone have face the same problems before?
Thanks cheng. Friday, December 11, AM. Hi cheng99, Can you please try configuring the security option on Windows Server file server? Server manager 2. Local Users and Groups 3. Enable Guest account Then you may try to acces the file server from windows XP client. Hope it helps. Monday, December 14, AM. But it does not work as well. The same effect happen? It keep asking me to type user name and password, but i am sure that the user name n passworsd is correct.
Any where my server is in workgroup not domain. Blank Passwords It won't work for Win by default - blocks network access from accounts with blank passwords. Logon from multiple machines Yes - this would be possible. I know this may seem like you answered the question well, but I still cannot get this thing to work. First I created a user account on the server that was the same as the client computer windows xp pro and gave full permissions and security to the file sharing folder.
This didn't work. Then I tried to set up a domain, but I really don't know how to do this and I can't get that to work either. All I want to do is create a shared folder on the network so that all the computers can accesses it without having to log in everytime.
Ok, i had the same problem and have found the solution. Every article I have find about this problem, talk about "how to secure windows". But in this case i have a very small site were the users are not System Administrators and I don't want to stay everyday hang to the phone. So, here is your answer to make windows Server works in a workgroup without need of autencathion you can use XP clients with passwords o without them, is the same Is the same configuration of XP simple's file sharing but in windows sever you don't have a check box.
And that's all. You don't need restart the system. In this simple file sharing model all network user authenticate as Guest in the server.
0コメント