NET 121b: Essentials of Networking
Chapter 17: Accessing and Managing Resources in a Windows Network
This chapter discusses topics related to Active Directory and shared
file systems. The topics of this chapter are:
- Active Directory user accounts
- Active Directory group accounts
- Shared folders
- Printing in a Windows 2000 or 2003 environment
Windows Active Directory database keeps track of resources on your network.
Copies of the Active Directory database are kept on servers called Domain
Controllers. (The environment that your Active Directory serves is your
Domain.) The resources you can manage include users and workstations,
each of which can have an object representing it in Active Directory.
To make things easier for a change, the tool you will use most often to
manage these objects is called Active Directory Users and Computers.
Active Directory Users and Computers is only available on a server, or on a workstation that has administrative tools installed on it.
In addition, you cannot use this tool without sufficient rights to the domain you are trying to manage.
To access Active Directory Users and Computers, you can select it from the server's Administrative Tools menu. You can also run it by clicking Start, Run, and entering
the file name dsa.msc. The text notes that you will find more features
in the Server 2003 version of the utility than in the one for Windows
2000, such as the capacity to save queries.
User and Computer objects are created for ease of management.
To allow you to manage groups of users and workstations at a time,
you generally place them in Organizational Units (OUs), containers
that represent some aspect of your organization, such as locations or
work units. The text reminds us that you can create as many OUs as you
need, and need not place new users in the default Users container.
When creating a User object, you need only fill in the fields for First
Name, Last Name, Logon Name, and Password. This is
good, since the text reveals that you cannot fill in many of the available
fields until after the object has been created. Activity A-1 in
the text describes creating a user account, then adding that account to
a Group Policy that will allow a someone to log in under that account.
You can see why you would want to create several Users, then add them
at once to the policy.
Policies are the means Active Directory uses to apply rights and
permissions to users. A particular policy is discussed: the Default
Domain Policy. To get to it, open Active Directory Users and Computers,
access the properties of the domain object, and click the Group
The text now drills further into policies. From the Group Policy tab,
click Edit. (Which you cannot do without sufficient rights.) You should know some details about three important
policies that are deeper still. To get to them drill down through Computer Configuration,
Windows Settings, Security Settings, and Account Policies.
(The word byzantine just leaps to mind, doesn't it?) You
finally arrive at a screen that shows Password Policy, Account
Lockout Policy, and Kerberos policy. (For some unfathomable
reason, Microsoft refers to theses policies as nodes. Let's humor
them and call them nodes, too.)
The Password Policy node allows you to set rules for passwords
on your system. You can set the following properties (which are good to
know when troubleshooting):
- Enforce password history - Most users want to use the same
password every time they are prompted to change it. This is bad for
security. This property sets the number changes a user must make to
his/her password before being allowed to change to a previously used
password. The default value is 24.
- Maximum password age - In other words, how old can a password
be before the user must change it. The default value is 42 days.
(Active Directory prompts a user to change a password several days before
it actually expires.)
- Minimum password age - Remember those users who want to keep
the same password all the time? This rule sets the minimum time between
password changes, to confound users who would run through two dozen
changes to get to their favorite word again. Default value: 1 day.
- Minimum password length - Sets the minimum length for passwords.
Can be 0 for users who are allowed not to have passwords. (NOT
recommended!) Must be a value between 1 and 14 (inclusive) for
users who must have passwords. Default value: 7 characters.
- Complexity requirements - If turned on, complexity requires
several conditions be met by a password. It can't contain a portion
of the user's logon name, it must contain three of these characteristics:
upper case letters, lower case letters, numbers,
and characters that are neither letters nor numbers. Default:
- Store passwords using reversible encryption - Allows applications
to read the users' passwords if necessary. Not recommended. Default:
The Account Lockout Policy node allows you to set rules about
accounts being locked, which happens when there are several failed attempts
to log in to an account:
- Account lockout duration - The explanation of this property
in the text is wrong. Follow this
link for confirmation of the correct information. This property
sets how long an account locked by the system stays locked before it
is automatically unlocked by the system. There is no default value.
The practical range is 1 to 99999 minutes. If you set this value
to 0, this means that the account will NOT unlock automatically.
- Account lockout threshold - How many failed attempts
to log in must occur for the system to lock an account. The text says
that if you set this to 0, accounts will never automatically
lock. The practical range for this setting is 1 to 999.
- Reset account lockout counter after - How long (in minutes)
it takes after a failed logon attempt before that logon attempt does
not count against the threshold value. No default. Range is 1 to 99999
The Kerberos Policy node allows you to set rules for Kerberos, the default
authentication protocol in Active Directory. Your book does not introduce
or explain it well. The following is from an article by Randall F. Smith,
Authentication Events Explained, at WindowsSecurity.com (The emphasis
and minor grammar corrections are mine.)
Kerberos uses the concept of tickets. A ticket is small amount
of encrypted, session specific data issued by the domain controller.
When a client needs to access a server on the network, it first obtains
a ticket from the domain controller for that server. The ticket
and other data supplied by the client vouches for the client's identity
and provides a way for the client to authenticate the server as well
which means Kerberos provides mutual authentication of both client and
server. Using timestamps and other techniques, Kerberos protects tickets
from cracking or replay attacks by eavesdroppers on the network.
- Enforce user logon restrictions - Checks whether the user has
rights to resources with every request, based on the policies in effect
on each server. Default: turned on.
- Maximum lifetime for service ticket - Sets a time limit for
tickets that allow access to resources. Default: 600 minutes
The other setting described in the text are less clear. We will leave
them for discussion in a Windows Server Administration class.
The text goes on to discuss problems that might keep a user from logging
in to your system. You should be aware of some of the classic problems,
and some of the more unusual ones:
- Incorrect user name or password - especially in environments
that require users to have several IDs and passwords, a user can easily
be mistaken about what to type.
- Account lockout - You should be aware of the lockout duration
in your environment. An administrator can unlock an account regardless
of it being locked by a the system or by another admin.
- Account disabled - Not the same as a lockout. It is possible
to create an account but not enable it (turn it on). In such a case,
that is all the admin needs to do to let the user in.
- Logon hour restrictions - User accounts can be restricted to
specific days of the week, and specific hours of the day. If a user
has changed work hours, this setting will need to be modified.
- Workstation restrictions - Users can be restricted to using
specific workstations. This kind of security is less commonly used,
since it prevents users from working anywhere on a campus.
- Domain controller problems - Users may be unable to contact
domain controllers if their DNS settings are wrong. DNS is used to find
the IP address of servers in the network.
- Client time settings - If a workstation's clock is more than
5 minutes out of synchronization with a Domain Controller, Kerberos
will not allow contact.
- Down-level clients - If your workstations run Windows 95, 98,
or NT, they are not fully compliant with Active Directory. Logon issues
may be corrected with Active Directory Client Extension, which can be
installed on those workstations.
- Local logon problems - Some users must log on to specific servers
or workstations to work on them. If the required logon is local to that
machine, Active Directory rights will not help. An administrator will
have to create a local ID for each user on each such computer.
The text goes on to discuss Active Directory group accounts. A
group is a list of users. Some groups can be granted rights
through policies just as a user is granted rights, but granting rights
to groups is more efficient. Users can be added to and removed from groups
more easily and accurately than a complex set of rights can be granted
to several users over and over.
The text states that groups are necessary because Organizational Units
cannot be assigned rights or permissions. Groups may be allowed to
contain a user from any domain in your forest, but OUs can only contain
objects from the domain they are in.
Groups come in two types:
- Security groups - groups that can be assigned rights and permissions
- Distribution groups - groups that cannot be assigned rights
or permissions, but can be used with an e-mail program
Groups have an attribute called scope. The following information
is an extract from a Microsoft site about Active
Directory on Windows 2000 servers:
Both types of groupsecurity and distributioncan have one
of three scopes (four when you include local groups, which exist in
Windows 2000 to provide backward compatibility with Windows NT groups).
A group's scope determines the extent to which the group can be nested
in other groups or referenced in DACLs on resources in the Active Directory
domain or forest.
By default, when you create a new group, it is configured as a security
group with global scope (in both mixed-mode and native-mode domains).
If you have multiple forests, you can place groups (or usersbut,
typically, you should put users only into global groups) from any trusted
domain into a local or domain local group. You can establish trust between
any two domains in any two forests.
The four possible Windows 2000 group scopes are:
- Groups with local scope (also called local groups)
- Groups with domain local scope (also called domain local
- Groups with global scope (also called global groups)
- Groups with universal scope (also called universal groups)
With some minor differences, domain local and global groups exist in
the Windows NT operating system (where they are called local groups
and global groups). Universal groups are new in Windows 2000. The following
subsections describe each type of group scope.
Groups with Local Scope
The local groups used in both Windows NT and Windows 2000 are precursors
of and are in some ways similar to the domain local groups (described
next) introduced in Windows 2000. Local groups are sometimes referred
to as machine local groups to contrast them with domain local groups.
Local groups have the following features:
- Mode. Local groups are the only type of local group available in
a Windows 2000 mixed-mode domain. In the case of Windows 2000 native-mode
domains, only Built-in groups have local scope.
- Membership. Local groups can have members from anywhere in the forest,
from trusted domains in other forests, and from trusted down-level
- Permissions. A local group has only machine-wide scope; that is,
it can be used to grant resource permissions only on the machine on
which it exists. (Note, however, that local groups created on a domain
controller are available on every domain controller in that domain
and can be used to grant resource permissions on any domain controller
in that domain.)
Groups with Domain Local Scope
Domain local groups, a new feature of the Windows 2000 operating system,
have the following features:
- Mode. Domain local groups are available only in native-mode (but
not mixed-mode) domains.
- Membership. Like local groups, domain local groups can have members
from anywhere in the forest, from trusted domains in other forests,
and from trusted down-level domains.
- Permissions. A domain local group has domain-wide scope; that is,
it can be used to grant resource permissions on any Windows 2000 machine
within the domain in which it exists (but not beyond its domain).
Groups with Global Scope
Global groups, effectively the same as Windows NT global groups, have
the following features:
- Mode. Global groups exist in both mixed-mode and native-mode domains.
- Membership. Global groups can have members from within their own
- Permissions. Although a global group is limited to domain-wide scope
as far as membership goes, it can be made a member of machine or domain
local groups or granted permissions in any domain (including trusting
domains in other forests and down-level domains with which a trust
relationship exists). That is, groups with global scope can be put
into other groups in any trusting domain.
Groups with global scope help you manage directory objects that require
daily maintenance, such as user and computer accounts.
Groups with Universal Scope
Universal groups, a new feature of the Windows 2000 operating system,
have the following features:
- Mode. Universal groups are available only in native-mode domains.
- Membership. Universal groups can have members from any Windows 2000
domain in the forest. (Universal groups can contain members from mixed-mode
domains in the same forest, but this is not recommended. Members from
such domains cannot have the universal group's SID added to their
access token because universal groups are not available in mixed-mode
domains. Therefore, troubleshooting access problems would be difficult.)
- Permissions. Universal groups can be granted permissions in any
domain, including in domains in other forests with which a trust relationship
The text continues with a discussion of file systems used in various
versions of Windows. A hard drive keeps track of the location of
data with a directory listing and a FAT table, just like
a floppy disk. A hard drive can have two (redundant copies) of
several kinds of FAT tables. The problem with older systems is the large cluster size they require. Think of sectors and tracks as being physical aspects of a disk that are dealt with by the BIOS. Think of clusters as being logical aspects of a disk that are dealt with by the Operating System. A cluster is defined in another text as "the smallest unit of data that can be read from or written to at one time". Every time you write a file, you must use at least one cluster, regardless of the actual file size. This means that systems with large cluster sizes waste drive space when you save small files. Consider this information about FAT tables and cluster sizes:
- DOS and every version of Windows since 3.1 can use 16 bit FAT tables
- Windows 95, version 2, and later can use 32 bit FAT tables (FAT32),
which are larger and can use larger addresses. Windows 2000 and XP can
use FAT32, but only if the drive is no larger than 32 GB.
- Windows NT can use any of these, or NT File System (NTFS) tables
which are larger still, using the most addresses. Windows 2000 and XP
also prefer NTFS.
- FAT 16 is usable for hard drives up to 2 or 4 GB (see below)
in size, but there is a penalty for large drives. The larger the drive,
the larger the cluster size for a 16 bit table.
- FAT 32 is better organized, and is practical for drives up
to 8 GB, where its cluster size is about 4 KB. From 8 GB to 16 GB, the
cluster size goes up to about 8 KB per cluster.
- NTFS allows the use of much larger hard drives.
The chart below shows cluster sizes for various logical drive sizes using
FAT16, FAT32, and NTFS. For another view of the same data, see this
page at PC Mechanic.
Cluster Sizes for various FAT types
||Logical Drive Size
||Up to 127 MB
||128 MB to 255 MB
||256 MB to 511 MB
||512 MB to 1023 MB
||1 GB to 2 GB (limit for DOS and Windows 9x)
||2 GB to 4 GB (must be using NT, 2000, or XP)
||512 MB to 8 GB
||8 GB to 16 GB
||16 GB to 32 GB (limit for Windows 2000 and XP)
||32 GB to 2 TB
||Up to 512 MB
||512 MB to 1 GB
||1 GB to 2 GB
||More than 2 GB
You may wonder why we don't just use NTFS on all large hard drives.
It is because NTFS is not available unless you are running Windows
NT, 2000, or XP.
You will probably use NTFS on any workstation you install in current
environments. You will want to be familiar with the file system permissions
that can be granted to users in NTFS:
- Full control - users can do anything they wish
- Modify - users cannot delete files and subfolders, cannot change permissions,
and cannot take ownership; they can do anything else
- Read and execute - users can browse the file structure, read files,
and run programs. Rights flow down to child folders and files.
- List folder contents - users can browse the file structure, but cannot
execute programs. Rights flow down to child folders, but not files.
- Read - users can read files, but cannot move from one folder to another
- Write - users can create files and folders, can set attributes, and
can read permissions
- Special permissions - users can be granted or denied specific permissions
included in the sets above with this setting
The next topic in the chapter is shared folders. A shared folder
is typically a network resource made available to specific groups of users.
The normal tool for creating folders is Windows Explorer. A user with sufficient
rights to a folder can access its properties, and the Sharing
tab within them. On that tab, you set a Share name for the
folder. The text notes that you can make it a hidden share by appending
a $ to the end of the folder's Share name.
Shared folders can also be managed through the Computer Management
console. It can be accessed on a Windows XP machine by right-clicking
the My Computer icon, and selecting Manage. The advantage to using
this tool is that you can use a wizard to apply preset group permissions
to folders as you create them.
The last major topic in the chapter is printing. The text introduces
operational definitions of several terms that are different in a Microsoft
network than in any other kind of network:
- print device - the physical device that any normal person would
call a printer is called a print device by Microsoft
- printer - Microsoft defines a printer as an Active Directory
configuration object that provides a point of connection for users,
and holds the necessary driver for the print device
- print driver - a program that serves as an interface between
the user's operating system and the print device to be used
- print server - the server that holds the print drivers and
- print client - a computer that sends a print job to a printer
and print device
The text offers an eight step process for sending a print job
to a print device:
- User creates a print job with some application.
- The print job is sent from the application to the Graphic Device
Interface (part of Windows), where it is rendered
(translated into print codes by the driver on the PC).
- Print job is handed off to the spooler, a holding buffer on
- Client software on the PC calls the network print server, and copies
the print job to the server when the server is ready.
- The print server places the print job in its own spooler, and
performs internal processes on it.
- The print server routes the print job to the print provider,
another internal process that serves as a buffer that can be
managed by network admins.
- The file may be processed further for the print device while
spooled on the print server.
- When formatting is complete, and the print device is ready, the print
server sends the job to the print device.
When using Active Directory for network printing, printers must be published,
made available to users.