In this video from ITFreeTraining, I will look at the basics of how Windows Security
works. Understanding how security works in Windows will help you understand how to secure
your network as well as provide the building blocks for troubleshooting your network.
In order to do this, I will look at the security principal, security identifier, Access Control
Entry, Access Control List and, lastly, Access Tokens. All these work together to either
allow or deny access. In later videos, I will look at how permissions work. But this video
will provide you the foundation for those videos.
A security principal is an entity that can be authenticated. If you think about it, when
asking for access to anything, the first question that is asked is, who is asking for access?
The security principal is just that, who is asking for access?
To give some examples of security principals, a security principal can be a user or a computer.
These are the most common ones, but also a process running on the computer is considered
a security principal. If you consider an example of this, say you have a service running on
the computer, and that process requires access to files on the computer. The operating system
needs to know who is asking for access to those files. So, the process needs to have
a security principal applied to it. You will find that any object or entity in Windows
has a security principal. For example, an object in Active Directory will have a security
principal. This allows the operating system to determine who is asking for something or
who it is being applied to. So the security principal is kind of like giving something
a name. But this brings up the next question, what happens when two entities have the same
name?
This brings us to the next topic of security identifiers or SID's. A SID, put simply,
is a unique number. It is used to identify an object or entity in Windows just like a
serial number could be used to identify any household appliance.
Whenever an object or entity is created in Windows, a unique SID is created so, essentially,
every security principal has a unique SID. Windows now has a system of uniquely identifying
objects even if they have the same name.
Shown here are some example SID's. If you want to learn more about the format of a SID,
I have included a link in the references part of this video which describes the format of
the SID in more detail. Essentially all SID's start with S. The shorter SID's are non-domain
SID's, so are used only locally on a computer. The longer SID's are domain SID's which
include the authority, domain and a unique number. Since the SID is essentially a long
unique number, it is generally not that important to understand the format of them but, more
so, how they are used.
To show a real example of a SID, I will open Regedit and navigate down through regedit
until I reach the container ProfileList. Any user that logs in to a Windows system will
have a profile for that user automatically created and listed here. The containers listed
here are named after the SID of that user.
You can see the first three containers have short SIDs. These are profiles belonging to
local users. Below this is a profile belonging to a domain user. You can see that the ProfileImagePath
key that this profile belongs to is a user account called "trainer".
The container below this, you can see, belongs to the domain administrator account. This
is just one example of how SID's are used in Windows. To better understand how SID's
work, I will look at another example.
Let's consider a user called John Doe, who worked for the company. When the user was
created, the user was given a unique SID. John Doe later left the company and the user
account was deleted.
Later on, a new user (also called John Doe) started working for the company. When this
user was created, a new unique SID was created. You can see that even though the two users
have the same name, Windows can tell them apart because the SID's are different.
If a 3rd user was created in a different domain with, once again, the name John Doe, this
user will have a unique SID created and assigned to that user. You can see how 3 different
users can be uniquely identified. This essentially means that if you create a new user with the
same name, that user will always get a new SID. It is important to understand this fact
when deleting a user. When you delete a user, the SID associated with that user is also
deleted. As we will see in a moment, this SID may have been used in groups and assigned
to files, folders or objects. Once the user is deleted this association is lost. If you
are not 100% sure that you will never need that user again, nor the access granted to
that user, it is recommend to disabled the user rather than deleting it.
Disabling the user prevents it from being used but keeps any access that user had been
configured with. If you do decide that you need that user again, all you need to do is
enable the user. It is common practice to disable a user when they leave a company.
When a person is hired to replace that person, it is just a matter of renaming that user
to the name of the new user. Since the SID associated with that user still exists, the
new staff member will have all the same access as the previous staff member.
So now that we understand how security principals and SID's work, how do these get used to
determine what a user has access to?
In order to determine if a security principal is allowed access, an ACE and ACL are used.
These are Access Control Entry and Access control list. To understand how these work,
consider this example. The user John Doe wants to access a file in a word document.
In order for this to occur, Windows needs to determine if John Doe is allowed access
to the file. To do this, an ACE or Access Control Entry is created with the SID of John
Doe in it. This ACE is what grants John DOE access to the file. So what is an ACL? An
ACL is a list of ACE's or, to put it another way, a list of everyone who is allowed access
to the file.
In this case the access list only contains one entry, but more entries could be added.
For example, the domain users group, system users and admin users could be added. You
can see how the access control list controls who has access to the file. When an access
request is received, the SID from that request is looked at to see if there is a match in
the access list.
The next question that arises is: Is it possible for an attacker to get the SID of a user and
use that SID to gain access to a file that they do not have permission to access? To
answer this question, this brings us to the next part of the Windows Security process.
To prevent unauthorized access, Windows uses an Access token. The access token contains
the security context of that entity. The security context is essentially the SID, Permissions,
Group Membership, and anything that particular entity has access to. That sounds complicated
so let's looks at an example.
Consider, once again, you have the user John Doe. Before John Doe can access any resources
on the network, first John Doe needs to be authenticated by a Domain Controller. In order
for this to occur, John Doe enters in his password which the Domain Controller checks
to ensure that it is correct.
Once this occurs, the Domain Controller generates an access token for that user. In this access
token goes information like the User SID and the SID's for any groups that user is a
member of. This is then transferred to the user.
Now that the user has an access token, they can use that access token to access resources
on the network. Let's consider a server on the network with a file share. The file
share has permissions assigned to it which forms an Access Control List or ACL.
When the user attempts to access the file share, their token is transferred to the server.
Once the server has the token, it compares the SID's in the token with the SID's
in the access list assigned to the share. If it finds a match the user is granted access.
If no match is found, the user is denied access.
When an access token is presented to a server, the server is able to quickly check that the
access token is valid. Access Tokens use technology like digital signatures to ensure that a token
has not been modified. It is not a simple matter for an attacker to create their own
access token since they do not have the keys that the Domain Controller used to sign the
access token when it was created.
Also notice that, since the access token was created during authentication, if the user
is added or removed from any groups, the access token would need to be recreated. This essentially
means that when changes are made that effect the access token, the user must logoff and
log back on again for a new access token to be created.
This covers the fundamental concepts of Windows Security, but before finishing this video
let's have a look at how this works in a real operating system.
If I now open Windows Explorer and then open the properties for a folder on the c drive
and select the security tab, this will show the security Access Control List for this
folder. I have disconnected this computer from the network so it is not able to access
a Domain Controller.
You will notice that the first two entries, "Authenticated Users" and "System"
are present. These are what are referred to as special identities. There are special local
users that are the same on every install of Windows. I will cover special identities in
more detail in a later video. Since the local Windows install knows the identity of these
users, so to speak, it is able to display the name.
If I scroll down and then freeze the video, notice that the last two entries are the SID
rather than a friendly name. Since the SID is short we know this SID is local rather
than domain based. In this brief second where the video has been frozen, the operating system
has not had a chance to get any information about the two SID's.
If I now unfreeze the video, notice the top entries are still showing their SID's however
the bottom two entries have now been resolved. These are the local group administrators and
the local group users.
If I now plug the computer back into the network, the computer will once again be able to access
a Domain Controller to obtain this information. If I close this window and then reopen it
again, notice the SID's have changed to Trainer and Domain Users. You should be able
to see now that when it comes to security, the only thing that is stored in the access
control list is the SID and not the name. This is why you can rename a user or group
at any time without effecting the security that user or group has been used on.
There has been a lot covered in this video so let's perform a quick summary. A security
principal is an entity that can be authenticated. This is essentially a user, group or process.
When a security principal is created, for example a user is created, a unique SID is
created with it. Since this unique SID is used to identify the security principal, the
security principal can be renamed at any time. It should also be remembered that when the
entity is deleted, the SID is lost. For this reason, consider disabling rather than deleting.
Companies will often disable a user when that person leaves the company and rename and enable
the user account when a replacement is found.
A security identifier or SID is essentially a unique number. A SID is used in Access Control
Entries. For example, if you want to give access to someone, an Access Control entry
would need to be created to give them access. These Access Control Entries are put into
Access Control Lists.
An Access token is created when authentication occurs which is generally when a user first
logs in. The access token defines what the user can access, and is used to grant access
to other systems. The access token is mathematically time consuming to create and requires secret
keys to be created and stored on Domain Controllers. For this reason, it is not easy to fake an
access token; however, it is easy to check that the access token is legitimate. Since
the access token contains information about what can be accessed, when changes are made
like group membership, the access token must be recreated. In the case of users, this means
that they need to log off and log back on again.
This concludes this video. I hope you have found it useful and I look forward to seeing
you in other videos from us, till next time, thanks for watching.