NET 121b: Essentials of Networking

Chapter 17: Accessing and Managing Resources in a Windows Network

Objectives:

This chapter discusses topics related to Active Directory and shared file systems. The topics of this chapter are:

  1. Active Directory user accounts
  2. Active Directory group accounts
  3. NTFS
  4. Shared folders
  5. Printing in a Windows 2000 or 2003 environment
Concepts:

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 Policy tab.

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: turned on.
  • Store passwords using reversible encryption - Allows applications to read the users' passwords if necessary. Not recommended. Default: turned off.

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 minutes.

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, Kerberos 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 group—security and distribution—can 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 users—but, 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)
  • 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 domains.
  • 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 domain (only).
  • 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 exists.

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 (FAT16)
  • 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
FAT Type Logical Drive Size Cluster Size
FAT16 Up to 127 MB 4 sectors
128 MB to 255 MB 8 sectors
256 MB to 511 MB 16 sectors
512 MB to 1023 MB 32 sectors
1 GB to 2 GB (limit for DOS and Windows 9x) 64 sectors
2 GB to 4 GB (must be using NT, 2000, or XP) 64 sectors
FAT32 512 MB to 8 GB 4 sectors
8 GB to 16 GB 8 sectors
16 GB to 32 GB (limit for Windows 2000 and XP) 16 sectors
32 GB to 2 TB 32 sectors
NTFS Up to 512 MB 1 sector
512 MB to 1 GB 2 sectors
1 GB to 2 GB 4 sectors
More than 2 GB 8 sectors

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 printer objects
  • 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:

  1. User creates a print job with some application.
  2. 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).
  3. Print job is handed off to the spooler, a holding buffer on the PC.
  4. Client software on the PC calls the network print server, and copies the print job to the server when the server is ready.
  5. The print server places the print job in its own spooler, and performs internal processes on it.
  6. 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.
  7. The file may be processed further for the print device while spooled on the print server.
  8. 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.