Security Concepts

No computer will ever be completely secure if people other the than authorized users can physically access it.  Simple things like locked doors can make all of the difference in the world.  If the network is entirely contained in a secure building, the risk of unauthorized taps is also minimized or even eliminated.  Nevertheless, security measures must continue even after one gains access to a computer.  The security model built into Windows NT includes components to control who accesses which objects (such as files and shared printers), which actions an individual can take on an object, and which events are audited.  There are many ways that security can be implemented but we will focus on the concepts that apply most to us.

So, first of all, user-level security is implemented.   This basically means that who the user is determines what he will be allowed to do.   Then, there is access control for various objects (resources) in the network.  With access to objects across the network, this security model is implemented on two levels: share level and file/directory level.  Security at the file and directory level is only possible when using NTFS.  When these schemes are used together, a fairly high level of security is achieved.

We may not realize it at the time but from the point when we turn on our computers to the point of accessing our files on the network, we pass through several lines of security.  It basically goes like this:

1) You turn on the computer and the boot process begins.  During this process the computer loads the Registry and in it, it sees that you are a domain network user which means that in order for you to complete the start up process properly, you must connect to the domain (at least that is a frequently used standard).  That is why you have to enter your user name and password in the logon dialog box to complete the start up process.   Your computer then calls out to the network for a domain controller (which is an NT server that authenticates users) and the first one to respond attempts to authenticate you.  It looks at your computer name, user name and the hash from your password, compares it to the information stored in the security database (SAM), and if everything checks out, it let's you in by assigning you an access token (see glossary if needed).  This is the first line of defense.  From that point, everything you do or attempt to access will be limited by your individual rights and permissions, which is indicated in part by your access token.  That is why, with NT, when new permissions to an object are granted to a user, he will not be able to access the object until he logs on again, thus generating a new access token.

2) That brings us to the next level, whether or not you can access a particular area of the network.  Essentially, being logged on, in itself, doesn't really mean that you can access anything else.  Each object (files, folders, printers, etc.) has its own access control list (ACL) of users or groups and their permissions. One user may have full control of an object while another may only have permission to read it.  Of course, anyone who is not in the list at all, whether individually or as part of a group, gets no access.  By the way, although we will talk about groups later, if a user appears in the same ACL multiple times, perhaps as a member of different groups with different permissions, he will have access according to the least restrictive permission.  However, if any of the permissions is specifically set to No Access, this will override any other permissions that the user may have.   (Fundamentally, permissions in NT boil down to AccessDenied or AccessAllowed which consists of a combination of Read, Write, Execute, and Delete.  NT simplifies assigning permissions by grouping these settings into four easy to understand levels: Full Control, Change, Read and No Access.)

Logon scripts are often used to automate the process, but in order to utilize the files and programs on our network we must access a network share.  (For more information on networking and shares, please see When Windows is Networked.)  Your "home drive" (F:) and all of the other "network drives" that you use everyday are shared directories on a server in the domain.  Well, in order to access them NT must match your access token with an entry in the ACL of that share.  In other words, your user name, either individually or as part of a group, must have permissions granted to that share in order to get in.  Further, it can limit what you can do to any resources accessed through that share, even if no additional security has been specifically applied to objects accessible through that share.  Thus, if your share permissions allow you only to read, it doesn't matter what other permissions you are granted to the objects in that directory, you will only be able to "read" the objects.

Additionally, when access is granted through shares you only see what's in the share.  To the user, it seems to be a root level directory.   Although a share may be a low-level subdirectory on a server, the user can't see any of the other directories around or above the share, only within it.  That means that access could easily be limited to one corner area of the network using shares.   In any case, access to a share is another barrier of security that we cross daily.   Well, what's next?

3) With NTFS (which is implemented on virtually all of our NT servers) security can be configured for individual files and directories.  It is similar to attempts to access a share.  In addition to the permissions discussed above, at the NTFS level of security there are two more permissions: Change Permissions and Take Ownership.  Nevertheless, NT must match your access token with an entry in the ACL of that individual file or directory.  In other words, your user name, either individually or as part of a group, must have permissions granted to that object in order to get in.  That does not mean that a network administrator would have to concern himself with setting permissions to everything on a network.  By default, objects will inherit the ACL of its parent object.  Because this level of security can deny access to objects a root level share doesn't have to expose all of the data in subdirectories of that share directory.  For instance, though you may see several directories within a particular "network drive", you may only be able to access certain subdirectories.

In any case, this combination of security levels makes for many possible methods of securing a Windows NT network.  As shown in the above diagram, there are always at least three check points between you and the data you store on the network - domain authentication, access to the share, and access to the directories and files.  If, however, it were possible for you to log directly into the computer housing the data, you would bypass all but the NTFS security.  That is also why it is generally much more secure to store sensitive data on a server rather than on your workstation.

When a network includes many users it only makes sense to manage them in groups.  A user group is a set of users who have identical network rights and permissions because a group is, essentially, a network account that contains other accounts.  By applying rights or permissions to a group you apply those same rights or permissions to all of the members of that group.  Now, while they are a beneficial means to implement security with a large user population but there are important considerations for implementing groups in a domain.

First of all there are two types of groups in a domain: local groups and global groups.  In the language of Windows NT, local basically means "on this machine".  Therefore, a local user is a user whose account resides on a specific computer and who logs into that computer.  A local group is a group that is managed and assigned rights and permissions on a specific computer.  The term global, on the other hand, is a bit of an overstatement, but on our system it can be thought of as a synonym for domain or network (particularly since we use, for the most part, a single domain model).  Global accounts reside on the primary domain controller for the domain.  That means a global or "domain" user is recognized all across the domain and the same is true with a global group.

Let's reason on this.  If a local group is on a particular machine, it's not on any other machine.  That means that while it may be useful for organizing security settings on that machine, the group is unknown to other machines.  Therefore, local accounts are not for assigning permissions across the network, global accounts are.  One instructor sums it up this way, "global groups are for exporting users and local groups are for importing users."  This makes sense when you think about the fact that security restrictions are set on objects and the objects (files, folders, printers, etc.) are resources of the servers throughout a large network like ours.  Here's an example: There may be many users all around the domain that need access to a particular resource.  The network brothers may therefore create a global group that contains all of these users.  On the server that stores the resource, they may use a few local groups to manage the access levels granted to the resource.  Instead of adding the global group directly to the ACL of the resource, they would want to add the global group to one of the local groups already in the ACL.   In this case, the global group was used "export" the users to the resource machine and the local group essentially "imported" the global group into it.  The thing to remember is the fact that you can add a global group to a local group but cannot add a local group to a global group.

This has really been a very simplistic look at Windows NT's security.  If you need more information on the subject, please visit our Training Resources page for available books.  There are, though, things that we can all do.  Keeping doors locked and using effective passwords are really fundamental to everything discussed above.   Please visit the Information Systems Computer Security site for specific information about security guidelines and policies.  If there were any unfamiliar terms used above, please consult our glossary.

We hold the "key" to good security!