Why do you need a server in most cases? Active Directory, RDS, print server and a bunch of small and large services. The most noticeable role for all, perhaps, is the file server. With him, people, in contrast, from other roles work most consciously. They remember in what folder what is lying, where are the scans of documents, where are their reports, where are the faxes, where is the general folder, where everything can be accessed, where only one department can access, another, and they don’t even know about some
I want to talk about access to network and local folders on the server.
Access to shared resources on the server is, as everyone knows, through the SMB protocol already 3.0. Network access to folders can be limited by SMB and NTFS permissions. SMB permissions work only when accessing a shared folder over a network and have no effect on the availability of a folder locally. NTFS permissions work both over the network and locally, providing much more flexibility in creating access rights. SMB and NTFS permissions do not work separately, but complement each other, according to the principle of the most restrictive rights.
In order to share the folder in Server 2012 in the
SMB Share Cmdlets group , the New-SMBShare cmdlet has appeared. Using this cmdlet as an example, we will see all the features available when creating a public folder, except for cluster configurations (this is a separate large topic).
')
Creating a new shared folder looks very simple:
net share homefolder=s:\ivanivanov /grant:"admin",full /grant:"folderowner",change /grant:"manager",read /cache:programs /remark:"Ivanov"
or
new-smbshare homefolder s:\ivanivanov –cachingmode programs –fullaccess admin –changeaccess folderowner –readaccess manager –noaccess all –folderenumerationmode accessbased -description "Ivanov"
We understand:
-name
The name of the shared folder on the network may differ from the name of the folder on the local computer. Has a limit of 80 characters, you can not use the names of pipe and mailslot.
-path
The path to the local folder to be shared. The path must be complete, from the root of the disk.
-cachingmode
setting autonomy of files in a shared folder.
What is an offline file?A standalone file is a copy of a file located on the server. This copy is located on the local computer and allows you to work with the file without connecting to the server. When connected, changes are synchronized. Synchronized in both directions: if you made changes to your offline file - the next time you connect, the file on the server will be changed; if someone made changes on the server, then your local copy will be changed. If the changes occurred in both files at once - we get a synchronization error and have to choose which version to save. For collaboration, I would not use this opportunity, but if for each user to make a ball and restrict access for others to read, without the possibility of writing, we get the following buns:
- Work does not depend on the network - the switch may burn, the server may reboot, the wire may break or the access point may be turned off - the user works with his copy, without noticing that you have some kind of failure there, when the network connection is restored, his work goes to the server.
- The user can work anywhere: in the country, on the bus, on the plane - in those places where a VPN connection is unavailable for some reason.
- Even if the user works through a VPN, but the connection is either very slow, or is constantly disconnected - it’s easier to work with a standalone copy and synchronize the changes than to try to do something on the server.
- The user himself can choose what and when to synchronize, if given the opportunity.
Accepts the following values:
- none - the files are not accessible offline, access to the server requires access to the server
- manual - users choose the files that will be available offline
- programs - everything in the folder is accessible offline (documents and programs (files with the extension * .exe, * .dll))
- documents - documents are available, there is no program
- branchcache - caching instead of the user's local computer occurs on BranchCache servers, users choose offline files themselves
-noaccess, -readaccess, -changeaccess, -fullaccess
share permissions.
These permissions have one big advantage - they are very simple.
-noaccess secretary, steward - the secretary and the supply manager have nothing to do in the general folders of the accounting department
-readaccess auditor - the auditor checking the work of the accounting department can see the names of files and subfolders in the shared folder, open files for reading, run programs.
-changeaccess accountant - accountants in their shared folder can create files and subfolders, modify existing files, delete files and subfolders
-fullaccess admin - fullaccess is readaccess + changeaccess plus the ability to change permissions.
When creating a shared folder, the most restrictive rule is automatically applied - the “Everyone” group is given the right to read.
These permissions apply only to users who have access to the shared folder over the network. When logging into the system locally, for example, in the case of a terminal server, both the secretary and the farm manager will see whatever they wish in the accounting department. This is fixed by NTFS permissions. SMB permissions apply to all files and folders on a share. More fine-tuning access rights is also provided by NTFS permissions.
-concurrentuserlimit
With this option, you can limit the maximum number of connections to a shared folder. In principle, you can also use it to restrict access to a folder, complementing NTFS permissions, you just need to be sure of the required number of connections.
-description
A description of the share that is visible in the network environment. Description is a very good thing that many people neglect.
-encryptdata
encryption
In SMB to version 3.0, the only way to protect traffic from a file server to a client was VPN. How to implement it depended completely on the preferences of the system administrator: SSL, PPTP, IPSEC tunnels or something else. In Server 2012, encryption works out of the box, on a regular LAN or through untrusted networks, without requiring any special infrastructure solutions. It can be enabled both for the entire server and for individual shared folders. The encryption algorithm in SMB 3.0 is
AES-CCM , the hash algorithm instead of HMAC-SHA256 is
AES-CMAC . The good news is that SMB 3.0 supports hardware AES (
AES-NI ), the bad news is that Russia does not support AES-NI.
What threatens the inclusion of encryption? The fact that only clients that support SMB 3.0, that is, Windows 8, can work with encrypted public folders. Again, the reason is the maximum allowable restriction of user rights. It is assumed that the administrator knows what he is doing and, if necessary, will give access to clients with a different version of SMB. But since SMB 3.0 uses new encryption and hashing algorithms, client traffic with a different version of SMB will not be encrypted, you need a VPN. The command will help all clients go to the file server with encryption enabled.
set-smbserverconfiguration –rejectunencryptedaccess $false
In the default configuration (unencrypted traffic to encrypted shared folders is prohibited), if you try to access the client folder with an SMB version lower than 3.0 on the client, we will get an “Access error”. On the server, event 1003 will be added to the Microsoft-Windows-SmbServer / Operational log in which you can find the IP address of the client trying to gain access.
Encryption of SMB and EFS are different things that are not related to each other, that is, it can be used on FAT and ReFS volumes.
-folderenumerationmode
This is an Access-Based Enumeration. With Access-Based Enumeration enabled, users who do not have access to a shared folder will simply not see it on the file server and there will be fewer questions why I do not have access to this or that folder. The user sees their available folders and does not try to climb into the affairs of others. The default is off.
- accessbased - enable
- unrestricted - turn off
-temporary
This key creates a temporary shared folder, access to which will be terminated after the server is restarted. By default, permanent shared folders are created.
NTFS permissions
With the help of NTFS permissions, we can further differentiate the rights in the folder. We can prohibit a certain group from changing a specific file, leaving the possibility of editing the entire main file; in the same folder, one user group may have the rights to change one file and will not be able to view other files being edited by another user group and vice versa. In short, NTFS permissions allow us to create a very flexible access system, the main thing is not to get confused in it. In addition, NTFS permissions work both when accessing a folder over a network, complementing sharing permissions, as well as locally accessing files and folders.
There are six basic (basic) permissions, which are a combination of 14 additional (advanced) permissions.
Basic permissions
Full access (fullcontrol) - full access to a folder or file, with the ability to change access rights and audit rules for folders and files
Modify (modify) - the right to read, modify, view the contents of a folder, delete folders / files and run executable files. Includes Read and Execute (readandexecute), Write (write) and Delete (delete).
Reading and execution (readandexecute) - the right to open folders and files for reading, without the possibility of writing. It is also possible to launch executable files.
Folder contents list (listdirectory) - the right to view the contents of the folder
Read (read) - the right to open folders and files for reading, without the possibility of writing. Includes Folder Content / Data Reading (readdata), Reading Attributes (readattributes), Reading Optional Attributes (readextendedattributes) and Reading Permissions (readpermissions)
Write (write) - the right to create folders and files, modify files. Includes Creating Files / Writing Data (writedata), Creating Folders / Writing Data (appenddata), Writing Attributes (writeattributes) and Writing Optional Attributes (writeextendedattributes)
Additional permissions
I put only 1 of the 14 permissions on the folder and watched what happened. In the real world, in most cases, the basic permissions are enough, but I was interested in the behavior of folders and files with the most reduced permissions.
Traverse folders / file execution (traverse) - the right to run and read files, regardless of the permissions of the folder. The user will not have access to the folder, (what remains in the folder will remain a mystery), but files in the folder will be accessible via a direct link (full, relative or UNC path). You can put on the folder Traverse folders, and on the file any other permissions that the user needs to work. Create and delete files in the folder the user will not work.
Folder content / Read data (readdata) - the right to view the contents of the folder without the possibility of change. You cannot open and open files in the folder you are viewing.
Reading Attributes (readattributes) - the right to view the attributes (
FileAttributes ) of a folder or file.
You cannot view the contents of a folder or files or change any attributes.
Reading additional attributes (readextendedattributes) - the right to view additional attributes of a folder or file.
The only thing I could find from the additional attributes is that they are used for backward compatibility with OS / 2 applications. (
Windows Internals, Part 2: Covering Windows Server 2008 R2 and Windows 7 ). I know nothing more about them.
Creating files / writing data (writedata) - allows the user to create files in a folder to which he does not have access. You can copy files to a folder and create new files in a folder. You can not view the contents of the folder, create new folders and modify existing files. The user will not be able to change any file, even if he is the owner of this file - only to create.
Create folders / add data (appenddata) - allows the user to create subfolders in the folder and add data to the end of the file without changing the existing content.
CheckWith the creation of subfolders, everything is clear:
ni c:\testperms\testappend –itemtype directory
will work as expected - it will create a subfolder of testappend in the inaccessible for the user folder testperms. Let's try to add a line to the end of the file - we will emulate some kind of logging.
newevent >> c:\testperms\user.log .
Hmm ... In CMD does not work. And if so.
ac c:\testperms\user.log newevent ac : "C:\testperms\user.log".
And on the conveyor?
"newevent" | out-file c:\testperms\user.log -append out-file : "C:\testperms\user.log".
And so does not work.
Starting a black magic session: use the File class, the
AppendText method. Get the log object.
$log = [io.file]::appendtext("c:\testperms\user.log") "AppendText" "1" : " "c:\testperms\user.log"."
I think that
it is not worth trying the
AppendAllText $log = [io.file]::appendalltext("c:\testperms\user.log","newevent") "AppendAllText" "2" : " "c:\testperms\user.log"."
The point, in principle, is clear. Only the rights to write data to the file are not enough for the methods listed above, they need to write to the file. But along with this, we will give the opportunity to change the file, and not just add records, that is, we open the potential to destroy the entire contents of the file.
We need to revise the concept: let's not get the log object, but create a new one in which we will set all the parameters of interest to us. We need something where we can explicitly specify access rights. We need a
FileStream , and
FileStream Constructor will help us more specifically
(String, FileMode, FileSystemRights, FileShare, Int32, FileOptions) . The following parameters are needed:
- File path is understandable
- How to open a file - open the file and find the end of the file
- File Permissions - Data Acquisition
- Access for other FileStream objects - not needed
- Buffer size - default 8 bytes
- Additional options - no
It turns out like this:
$log = new-object io.filestream("c:\testperms\user.log",[io.filemode]::append,[security.accesscontrol.filesystemrights]::appenddata,[io.fileshare]::none,8,[io.fileoptions]::none)
Works! The object of the log we created, we will try to
write something there. The FileStream.Write method accepts incoming values ​​in bytes. We overtake the event we want to write, into bytes —
the Encoding class , the
GetEncoding method (we don’t need krakozyabry at the output) and
GetBytes (actually, conversion)
$event = " ." $eventbytes = [text.encoding]::getencoding("windows-1251").getbytes($event)
FileStream.Write Parameters:
What to write; where to start writing; the number of bytes to write
We write down:
$log.write($eventbytes,0,$eventbytes.count)
We are checking.
gc c:\testperms\user.log gc : "C:\testperms\user.log ".
Everything is normal, the user does not have rights to view written. Log on as administrator.
gc c:\testperms\user.log .
Everything is working.
The folder in which the file is located in addition to the permission to create folders / record data must also be given permission to the contents of the folder / read data. The file is only enough Create folders / dozapis data with disabled inheritance. Fully protect the user (and the user may be an attacker) from the files in which he should write something will not work, but on the other hand, except for the list of files in the folder, the user will not see and can not do.
The conclusion from this is simple: in batch files to implement secure logging of something does not work, PowerShell saves the ability to work with. NET objects.
Write attributes (writeattributes) - allow the user to change the attributes of a file or folder. It seems simple. But just to answer the question: “Photos of my cats occupy almost the entire place in my profile and I have no place for business correspondence. I would like to compress the folder with cats, but they require administrative rights from me. You said that I have the right to change the attributes of folders. Is this an attribute? Why can't I change it? ”
Yes, the user with the right to write attributes can change almost all the visible attributes of files and folders, except for the compression and encryption attributes. Technically, the user is given the right to perform the
SetFileAttributes function. And file compression is performed by the
DeviceIOControl function, which needs to pass the FSCTL_SET_COMPRESSION parameter and file compression is not its only job. Using this function, we can manage all devices and their resources in the system and, probably, giving the user this right to perform this function means to make it an administrator.
With encryption, the story is similar: the
EncryptFile function, which is exactly responsible for encryption, requires that the user has the rights to the contents of the folder / read data, create files / write data, read attributes, write attributes, and synchronize to an object. Without them, nothing happens.
Write extended attributes (writextendedattributes) . Well, these are the ones that are used for backward compatibility with OS / 2 applications, yeah. Well, and in the extended attributes of the file C: \ Windows \ system32 \ services.exe, recently began to write Trojans (
ZeroAccess.C ). Maybe you should turn them off at the top level? I can’t give an answer to this question, theoretically - maybe worth it, almost in production - I haven't tried.
Delete subfolders and files. (deletesubdirectoriesandfiles) An interesting resolution that applies only to folders. The point is to allow the user to delete subfolders and files in the parent folder without giving permission to Delete.
Suppose there is a catalog of products in which users enter data. There is a parent folder Catalog, inside the subfolders alphabetically, from A to Z, inside them there are some names. Names change every day, something is added, something changes, something becomes outdated and outdated information needs to be deleted. But it will not be very good if someone for parking or malicious intent will crash the entire K directory, which is very possible if users have the Delete right. If you take away the Delete right from users, then the administrator can safely change work, because he will carry out requests to delete one name or another all day.
This is where the Delete subfolders and files are enabled. On all letters of the alphabet, inheritance is disabled and the right to Delete subfolders and files is added to users. As a result, users cannot delete any letters in the catalog folder, but inside letters they can delete anything.
Delete (delete). Everything is simple here. Removal is removal. Does not work without the right Reading.
Reading permissions gives the user the right to view permissions on a folder or file. No permission - the user does not see permission on the Security tab
Change permissions (changepermissions) - allows the user to change permissions, in fact makes the user the administrator of the folder. You can use, for example, to delegate authority to tech support. Without the right to read permissions does not make any sense. Changing permissions does not imply a change of ownership of the folder.
Change of owner (takeownership) - for starters, who is the owner. The owner is the user who created the file or folder.
The owner’s peculiarity is that he has full access to the created folder, he can distribute permissions to his created folder, but what is more important - no one can deprive the owner of the right to change permissions to his folder or file. If Vasya created a folder, gave Petya full access, and Petya entered and slammed user access to the folder in general and Vasya in particular, then Vasya can easily restore the status quo, as he is the owner of the folder. Petya will not be able to change the owner of the folder, even if he has the Change of Owner permission. Moreover, even Vasya cannot change the owner, despite the fact that he created the folder. The change of ownership right applies only to the Administrators or Domain Administrators group.
But if Petya inside the Vasina folder created the file and did not give Vasya access to it, Vasya can only think and guess what is so secret inside this file. Vasya will not be able to change file permissions, because Peter is the owner of the file. Vasya will not be able to change the owner of the file either - changing the owner of subcontainers and objects is also a privilege of the Administrators group to which Vasya does not belong. – .
CMD icacls. PowerShell NTFS- :
,
$acl = get-acl c:\testperms
System.Security.AccessControl.FileSystemAccessRule . :
- / – ACL
- – ACE ( , )
- – GUI . 3 : none ( ), containerinherit ( ), objectinherit ( ). .
- ( GUI) – 3 : none ( ), inheritonly (ACE ), nopropagateinherit ( ).
- – (allow) (deny)
:
$permission = “contoso.com\admin”,”fullcontrol”,”containerinherit,objectinherit”,”none”,”allow”
ACE
$ace = new-object security.accesscontrol.filesystemaccessrule $permission
ACE
$acl.setaccessrule($ace) $acl | set-acl c:\testperms
SMB NTFS , . :
Type of | SMB- | NTFS- |
(Public) | – / | – |
Black box. , , – . | – / – / | – , . , – , ( , , ). .
– . |
Applications | – | – , , .
, . , , ( SysInternals Suite) .
|
| – / | – . |
Windows – . – 90% . : , , – , .
, .
:
MSDNTechnet