CompTIA A+ Exam objectives 2.6
(Compare and contrast the differences of basic Microsoft Windows OS security settings)
There are different levels of user accounts built into the Windows operating system. There are administrators, guests, and standard users. An administrator is the super-user of the Windows operating system. If you have administrative rights, then you effectively can control everything about the operating system.
There are also guest users in the Windows operating system. These guest users are disabled by default. But if you do enable the guest user, they will have limited access to the operating system. The majority of people that log in to Windows are standard users. These are people that are browsing the internet or working on spreadsheets or word processing documents. A standard user does not have full and complete access to the operating system, but they are able to use the operating system to perform day-to-day tasks.
There are also groups built into Windows. Some of these groups can be created to assign rights and permissions to others, and other groups are built into the operating system. A good example of this is the power users group that provides additional rights and permissions to a standard user without giving them all of the permissions that may be assigned to an administrator. When you access a file in the Windows operating system, your access to that file may be controlled through NTFS permissions or share permissions.
NTFS permissions are permissions assigned to the file system itself. This means if you’re accessing a file locally on the computer, the NTFS permissions will apply. And if you’re accessing that file across the network using a share, these NTFS permissions will also apply to you as well. There is a separate group of permissions that are associated with users connecting across a share. This means you can have one set of permissions for people who are accessing this file locally and a completely different set of permissions for somebody accessing it across the network.
As you can imagine, this could create a conflict. What if the NTFS permission is set to deny access, but the share permission is set to allow access? Whenever you have that type of conflict, the most restrictive setting will win, which means if the deny is set on this file on either one of those permissions, then they deny will beat that allow permission that may be somewhere else. NTFS permissions are inherited from parent objects in the file system, which means you don’t have to manually assign NTFS permissions to every single file. It will simply use the permissions assigned to the parent object.
If you move that file to a different volume, then the permissions will be associated with where you put it on that volume. If you move that file within the same volume, there is simply a pointer that’s changed in the file system, which means it will keep the permissions if you’re moving it within the same volume. In this view, we’re looking at two different sets of permissions that are pointing to the same folder. This would be the folder under Users, Professor, Documents, and Reports.
You can see there may be NTFS permissions that provide full access to this particular folder. But if you were to look at the share permissions, anybody connecting across the network would only have read access to this particular folder. There are a number of shares that are created automatically by the operating system during the installation process. These are administrative shares, and most of these shares are hidden from view.
For example, any share that has a dollar sign at the end of it is automatically hidden by the operating system. So a share that had a C$ would be the share for the entire C drive, but it would be hidden by other people that are connecting to the system. Another good example of administrative shares are the ADMIN$ share and the PRINT$ share. If you wanted to view the shares available on your system, you can go to the command line and use the net share command to list out all the share names and the resources associated with that share.
We mentioned earlier that permissions associated with a file in the file system can have all of those permissions inherited from a parent object. If you were to manually change the permissions for that file in the file system, those permissions would be called explicit permissions. Here’s an example of inherited permissions. Here’s a music folder on my Windows computer. And you can see there are a number of folders underneath the Music folder. This means that the Music folder would have the parent permissions, and the folders underneath the Music folder would have the child permissions.
If we were to set permissions on the Music folder to allow access, we won’t have to go to each individual folder to also allow access, because all of those permissions will be inherited from the parent object. If we configured the Music folder to provide access, then access to all of the child folders would also be allowed, because those permissions are inherited from the parent object. We can override these inherited permissions by changing the permissions ourselves. And when we change them, they would be explicit permissions.
Let’s take the example of our music folder. If we set up a deny permission to our music folder, then that particular set of permissions would be inherited by all of the child objects. But there may be a child folder that we would like to provide access to others, and we can explicitly define what folder we would like to assign. So even though all of the other permissions were inherited, we can specify our own permissions, and those would be explicit permissions.
Learn more about our CompTIA A+ Certification
Credits: Professor Messor