Basic Security for Windows NT

Access Control and User Management


Introduction

Security starts with deciding who should be allowed access to which resources on your network, and implementing it. You can - later - add additional armor to your LAN, such as a firewall, some kind of VPN, packet sniffers and other network tools, and protect against viruses, Trojans, malicious ActiveX and JavaScript and the likes. But for starters, you'll need to decide, and implement, who is a legitimate user of your network, which files , directories printers, programs each user should be allowed to use, and set up a directory structure that allows for easy implementation of these decisions. No use in keeping the bad guys out if anyone inside can copy all of your trade secrets or other confidential information to a CD or a data stick and carry it out through the front door, right ? No point in protecting against computer wizards or script kiddies if a soon to be fired secretary with an axe to grind can crash your servers as easily as she can type a letter, no ?

Apart from that, basic network security (i.e. good user management) can also make things slightly harder for the bad guys on the Internet. You do not want to be the network admin who couldn't fend of the first guy who got your server's IP address and took over the server with no other tools than 3 common DOS commands. (Don't believe it happens ? Look here).

This paper will discuss the basics of user management, file access and security on a Windows NT server. Most of the concepts also apply for Windows 2000 Server and other NT based operating systems, although there may be slight differences in where to click OK or Continue. With Windows 2000, Microsoft introduced the 'Active Directory'. This did not introduce essential changes to the security topics here, the ACtive Directory is merely a database where all settings are kept, centrally, and therefore easier to maintain. It's also a directory service that allows users a single logon to multiple services. He functionality provided by the Active Directory goes further than that, but it does not make the need for a good user management and security policy obsolete.

User name and password policy

The people who you'll allow access to your network need to be identified, so you'll have to give them a user name, and they'll have to be able to proof that they're allowed access, so they'll need passwords. You'll need to decide how user names will be formed (e. g. jsmith for Joe Smith), and you'll have top set a few rules for passwords (e.g. Minimum length, format, will they expire ? how soon ? will the user have to change it so that even the admin doesn't know it ? will user accounts be locked after a given number of incorrect logins ? etc.) The Windows dialog window where you create user accounts have all the necessary check boxes.

What rules you set for names and passwords depends on what you decide on, given the situation in the company or organisation you work for. A few words on passwords, though.

A few guidelines for passwords

Long passwords that are not real words are difficult to remember, so we have a contradiction here. A good workaround for that, is a combination of an easy to remember word and an easy to remember number (but not something obvious as your name and your date of birth, and not just "secret123", but a nice mix, e.g. pur12ple - from "purple" and my shoe size : 12), or to use the first (second, 3rd, ... ) character of every word in an easy to remember phrase. You can make up a sentence, or use the last 12 words from the 2nd sentence on page 45 in the 'Windows for Dummies' book. Or so.
As a network administrator, you may have to provide passwords for a lot of users, and replace them regularly, so a good password generating system (like the trick with the book) can be helpful.

But don't use these examples, or anything too similar. Crackers will add things like those to their word lists, just in case someone is stupid enough to do just that.

Here's a good introduction to Windows NT passwords.

Still, brute force (simply try every possible combination) will break any password. It will just take longer if the password is long, not a real word, has numbers or punctuation marks in it, ... etc.

Users and groups

Every user gets an account. An account can be understood as 'the permission to log on to a system' : based on the combination of your user name and password, the system will decide to allow you to log on, or not. Attached to this account can be a profile : a combination of configurations and preferences (de background colour of your desktop, a personal directory for your files, certain start-up options, ...)

A user can also be given the permission to use resources (read certain files, edit some of them as well, create files in a this or that directory, run this program but not that, etc) or perform certain actions or tasks in the system (the right to make a backup, to install software, and so on). Users can be organised in groups, and these groups can be given permisions and rights as well. The users who are member of a group will inherit the permissions of that group. The administrator can however decide to revoke certain inherited permissions from a user, or ad additional permissions. Usually it's a good idea to avoid that : if users have only inherited permissions (from the group they belong to), management is easier : all you need to do is keep the right users in the right groups and all will have just the permissions they need.

Groups can not contain other groups. Unlike eg directories in a file system, or unlike what can be expeted in a classification system, you can not lcreate a hierarchy of groups, like, say, jsmith is member of the group 'programmers', the 'programmers' group is member of a groep 'employees', therefore jsmith is member of 'employuees' and inherits the permission associated with this group. It does not work that way in Windows NT.

There is an exception to this rule : so-called global groups can be member of so-called local groups. This has to do with the fact that local and global are two separate kinds of groups, with a different purpose. We'll get to that later. The fact remains that you can not use user groups to create a hierarchical classification of users.

Introducing ... The Silly Software Company

It would seem that if a company that is clearly structured, e.g.. in more or less independent teams, departments etc., the organisation of the groups will just have top reflect the organisational units (teams, task forces, departments) in the company. But you can not make a group member of another group. Therefore you'll have to devide the users into as many groups as necessary to reflect all entities or units that exist in your company.

A way to do this could be to look at the present staff, see who needs access to what files or directories, then make groups to match the smallest common denominator. Consequently, people who take on a wider range of responsabilities or tasks, will have to belong to more than one group. One can well imagine that a person can have a secretarial task in a department. He shoulld maybe belong the a group that shares access to secreterial / administrative data, documents , etc., and/or to a group that shares information about that specific department. This shows at least two ways of looking at the organisation :
grouping according to the departments in the company (sales - production - marketing - ...)
grouping according to the lfunctional level (clerk - assistant - coordinator - managing director - ...)

Case Study : The Silly Software Company

Consider the Silly Software Company, a small software producing firm with a programmers team, headed by the chief programmer, a financial department consisting of a financial director and a secretary/bookkeeper, its in-house network and system administrator who's also the helpdesk of the staff, a marketing team, and a general manager.

And we're only looking at 1 directory now. Having to manage access of this group to a whole bunch of directories, but not necessarily all subdirectories, becomes a nightmare. This also indicates that not only the grouping should reflect the organisational structure of the company, the directory tree should do so as well.

Unfortunately, people will have different roles.

Working out how the groups as well as the directory tree will reflect this reality and setting it up correctly is a lot more difficult than clicking 'create user' > > next > > 'member of ...' > > next > > next > > finish. Clearly defining a consistent organisation of responsibilities and lines of communications throughout the company may be e necessary first step to set up adequate security in terms of access to information.

We'll use the case of the Silly Software Company to further explain this in more detail. - link to case study -

NTFS file access

Take a look at the properties of a file or directory on a DOS or Windows system. You'll see that the filesystem (FAT or FAT32) provides 4 attributes for each file : read-only, archive, hidden, system. Each can be on or off. If a file is read-only, it means it can only be read (opened), not written (changed, edited). These attributes are properties of the file, so a file that is read-only will be read-only for any and every user, including applications. But of course, any user could turn the read-only attribute off, and the file would become editable, to any user.

NTFS provides file level security : On an NTFS file system, you can manage the access to each file and directory for each user individually, or a specific group of users. The list of which users/groups are allowed which access to a given file or directory is called the Access Control List of that file, and its written to the disk together with the content of the file. The settings in the ACL are sometimes referred to as 'local permissions'.
Possible permissions (both for files and directories), are

Read - R
Read de contents of files. Read properties (size, name, ...) of files and directories
Write - W
Create files and subdirectories in the directory in question. Change Properties. Change contents of a file
Delete - D
Remove files or directories
Execute - X
Execute commands, run programs
Change Permissions - P
Change the permissions on a file or directory
Take Ownership - O
Assme the role of 'owner' of a file or directory, and assume the permissions associayted with this role

The owner always has permissions that a normal user wouldn't have. Say I have write access to a directory so I can create a file there. I can not delete files from that directory, except for the files I've created myself, because I'm owner of those files. That gives me additional power : As owner i can always delete my own files, unless some one has taken ownership of that file, then he will have that additional power. The owner also has the pwer to change the permissions on 'his' files.

When setting NTFS security permissions to directories, they only apply to that directory, not necessarily to the files in the directory or the subdirectories of that directory. However, you can force the files to inherit the security of the directory that holds them by opting for 'Replace Permissions on Existing Files"
You can force subdirectories to inherit their parent directory's security by opting to 'Replace permissions on subdirectories'

These local (NTFS) permissions can be assigned to users or to groups.

User Groups

Lets have another look at the Silly Software Company :

What level of access will the chief programmer then have in regard to the personel\ directory ?

In a case like this, permissions apply in a cumulative way. You 'add up' the permissions. So if chief programmer has read access as a member of 'programmers' and 'write access' ass member of 'team leaders', the resulting applicable permission is 'read and write access'.

Rules to work out combined permissions

So far, it's still quite manageable. Taking into account these priority rules and the option to enforce inheritance throughout the branches of the directory tree, we can probably figure out NTFS security settings that give all employees the right level of access to the information they require.

default security settings

User Rights

Besides that, users can be given or denied the right to execute actions, such as the right to make a backup, the right to add a workstation to the domain, .... These rights refer to actions within the system, where as permissions refer to access priviliges regarding objects in the system, such as files or directories. and are not associated with file locations,

A user can e.g. be given the permission to 'backup files and directories' - this permission then overrules any (lack of) permissions for that user, he'll have the permission to backup all files, disregardless of the level of access that he has been permitted.

Shared directories and permissions

The permissions discussed so far are called local permissions, or NTFS permissions, because they are part of the NTFS file system on our Windows NT file server. However, the Silly Software employees all have their own workstation, and use the office network to get to their files on the server. Things would remain simple if for 'remote access', the same security would apply as for 'local access'. I mean, if it has been decided that the chief programmer has reader access to the file 'shoppinglist.doc' in the D:\misc\purchase folder, it shouldn't make any difference whether he reads that file from the monitor at the server machine, or uses the network to read it from behind his own desk, on his workstation.
Unix-like operating systems do it that way. With their mainframe-terminal background, it would probably not make sense to them to do it any other way. Windows, however, is a stand-alone single-user system with networking features added to it, and probably that is what made Microsoft decide to distinguish between local access and remote access.

Under windows, you indicate that a directory should be accessible over a network (this is called a 'share'), and then you can set access rules to it (called 'permissions'). These permissions do not necessarily need to be the same as the NTFS security (local permissions).

You can also make multiple shares on the same directory, thus creating the possibility to set different sets of permissions on each share. A lot of flexibility here, but also plenty of room for confusion. It may make sense to set the permissions on the shares identical to the NTFS security on the corresponding directories - after all, that should already reflect your security policy or the normal communication lines and information management in your company. It does mean you have to duplicate your effort, i.e. setting the same rules twice, once in NTFS, a second time as permissions on shares. I guess that's the price you pay for choosing a user-friendly operating system :-).

Share Permissions are predefined sets of NTFS permissions.

For shared directories, the following permissions can be set :

Permission NTFS equivalent Description
No Access
List R + X execute a dir command, see the files in the directory
Read R + X idem
Add W + X create new files, move files to the directory, create subdirectories
Add & Read R + W + X
Change R + W + X +D
Full Control R + W + X + D + P+O all permissions

Note that by default 'Everyone' has 'Full Control' on Windows NT shares. That makes for a system that's operational as soon as you've finished running setup, but it also makes for a system that's accessible for everyone, until you've changed it. Remember that 'Full Control' includes the power to take away access priviliges from other users, even from the Administrator. Very dangerous situation.

On shared Files; the following permissions can be set :

Permission NTFS equivalent Description
No Access
Read R + X read a file, execute a command or program
Change R + W + X + D change the contents or properties of a file
Full Control R + W + X + D + P + O all permissions

Again, permissions can be assigned to users or to groups. If a users is member of more than one group, or if a user is given permissions as an individual and other permissions through his membership of a group, these permissions are to be added up to find the resulting permissions.
No Access stile rules out other permissions.

When Share permissions and NTFS security are not identical, the more restrictive set counts. To figura out what access rules apply :

Admin shares

Windows NT will, by itself, create shares on the root of every volume (drive, partition), and on a number of directories. So even before you've created any shares yourself, the C:\, D:\, E:\ drive will already be shared. These are called Administrative shares; they can not be changed or removed, and should only be accessible for the system, and for the administrator. They can also be used as access points for intrusion. They're normally not visible, but can be approached by their share names (C$; D$, E$, etc.), e.g. with the net use command. Other admin shares are admin$ and IPC$.
Since you can not modify the shares, they only way to protect them is by setting NTFS security on the directories they represent.

One other thing to keep in mind is that permissions only count for shares, shared directories (or files).. Directories and files that are not shared can only be protected by NTFS security.

Local Users and Domain Users, Local groups and Global groups.

'Local' usally refers to the machine or system you are working on. If you create local user accounts on a machine, these users will be known on this machine only.

Domain users are known throughout the domain (domain : A group of computers and devices on a network that are administered as a unit with common rules and procedures - webopedia). The domain user accounts are used to manage user accounts, independent of the machine they log on. Domain users are known to the domain controller (they are stored in the domain database). Local Users are only know to one specific machine, i.e the machine were the local acocount is created.

It is common in a network to create domain accounts for users. However, it wout make sence to have at least a local (administrator) account to each machine so that you can log on to that machine and use it (and its local resources), even if the domain controller or the network is temporarily down and domain accounts can not be logged on to.

Local groups are created to manage access to resources on a specific machine. Eg. You can use local groups on your file server to manage the user access to these files.
(like : local group A has read/write access to directory A, local group B has reader access to directory A, and read/write access to directories B and BB, etc ). Local groups can contain global groups. Global groups are used to group domain user accounts, according to the level of acces they require.
You may for instance create a global group 'Secretaries', and add this group to the local groep A on the file server, to give all users who are member of 'Secretaries' read/write access to directory A on that server.
So :

That, together with the NTFS permissions - share permissions dichotomy, form the basics of user management in an NT domain.

HOW TO

How do you implement al of that on a small company network that has one server (taking the roles of Primary Domain controller file server), and a bunch of employees which all have their own workstation.

It would make sense to create separate partitions, e.g. a system partition (windows NT files, applications), and a data partition. No user (other that the administrator) should have access to the system files, so thhis partition can be blocked of with NTFS Access Control.

If the users need to use applications from the server, these will need to be installed in a separate partitions that then can have different access control settings. This may have to be considered if workstations need to get e.g. virus signature files to update their antivirus programs from the program directory of the server's anti-virus program.

The data partition is then the partition that contains the files the users will want to read, change create, move, delete, ... In this partition, the difficult task begins of distributing files over directories and subdirectories, and setting permissions for users and user groups, in a consistent and manageable manner - using both NTFS Access Control Lists and the Permissions associated with shares.

-- Case Study / Work shop --

Log On to services

An other question that needs to be addressed is : How to deal with access to e.g. a mail server, a datbase server. What kind of directory / file access do users need to be able to use these services ? Do they need permissions on the directorie or filers where the actual dtabase files are kept ? on the directory where the program files of that server are kept ? Or do they just need to log on to a service - and the server (database engine, mail server) will access the files and return the data to the user ?

It's latter option that applies : users log on to a server, and get what the server delivers, without needing permissions to the files where the data are actually stored : client-server architecture. (proberen met share op lotus notes, program link). However, you may have to create separate user accounts for these servers, except if they are capable of using the domain account logon to authentuiicate a user (more perobable when using Microsoft software such as Microsoft SQL server or Exchange, or when using a directory service such as Active Directory - Windows2000 and following) -. A user may need a separate logon for access to Lotus Notes / Domino Server or Interbase (database server). And therefore the user administration for these applications will also need to be dealed with separately. But that's beyound the scope of this paper.

Click or Script ?

Next ... Next ... Next ... OK ... Apply ... Next ... Next ... New ... Next ... Next ...
You can well imagine that clicking through the 'create user' dialogs to create a user is not to difficult, and you get a good view on all the psossible settings. Likewise for creating shares and setting permissions, or adding NTFS security to files.

However, if you need to create 20 groups, 100 identical users (just different names) in each group, set access rules to directories and files etc etc, all by clicking nect - nect - OK,n it gets boring. And then, if for some reason you ever need to redo exactly the same on another machien (bought a new sever, or so), it gets really boring. Or a real challenge, if you do not remember (or if you haven't documented) what your file access an user account settings are.

You can avoid some of this by using scripts. Scripts are files that list all commands (exactly, with correct parameters and all) you need to execute a certain task such as creating a user account, create a group, add the user to the group, etc. It can make your life a lot less stressful.

See Case Study and Scripts for exemples.

More about User Management on Windows NT, 2000, XP

Security and User Management

User Management on Linux

I'm still working on it ...
This page is a summary of information found in books and on webpages (see links), but I haven't checked every assumption or tested every conclusion yet, so I can not guarantee all of this is 100% correct and complete.

NEXT


Koen Noens
June 2003