|
16User AdministrationSometimes the fact that you have worked with older computer operating systems can be an impediment to using a new operating system such as Windows NT. There are many computer professionals who are not old timers in the computer industry, but they have worked with a number of systems dating from an old DEC PDP-8E through IBM mainframes and DEC VAX computers to the more modern UNIX and NT systems that they work on today. Many of the concepts that evolved in user administration on older systems can be useful even on modern systems like Windows NT. The goal for this chapter is to merge an understanding of the fundamental techniques of user administration with the tools and functionality provided by Windows NT server. By now, you have come to appreciate that one of the design characteristics of Windows NT is flexibility. In user administration, you will find a number of options available to you when you want to perform a task. This chapter covers those options here and some of the rationale for various techniques. To accomplish these goals, this chapter is divided into the following sections:
General Topics Related to User AdministrationEarlier computer operating systems depended on a user ID coded on a control card in the card deck. They did not really control my access to the computer. This was controlled more by the person who accepted or rejected my card deck. Soon, however, billing considerations came into play and computer operating systems started to track user IDs to determine who gets the bill. Of course, when money is involved, you have to be concerned with access controls to ensure that the right person gets the bill. This was the beginning of passwords. It was somewhat hokey in that all you had to do is get access to a control card that someone stupidly threw away and you had all of the access that you needed. It was almost painful, thinking back to those days of card decks. Productivity was low and costs enormous. I only had to use such systems a few times because many of the places I used for computer services tended to use DEC PDP and VAX equipment, which was one of the early terminal-intensive systems, although I did have my introduction to switch registers and paper tape (if you do not know what those things are, you probably need a history guide since I have not seen any of these things around in years) on these systems. Anyway, for a long time, access was so limited to computer types that setting up accounts remained relatively simple. The main attributes of an account were user ID, password, spending limit, and your status (computer center staff had absolute priority followed by professors, graduate students, and ultimately undergraduates). Because people did not have access to any real operating system functions (we were typing in card decks into text files and then running them), there was little risk that key system features would be compromised. That is not to say that prehistoric hackers were not at work on these vintage systems; it was more that the potential damage was small and, therefore, not a big concern. Computers started to catch on, however. After they got out of the information systems and academic environments, security suddenly became a very hot topic. The big push for security initially was driven by money. Computers were still a long way from being able to display MPEG movies, but people figured out that computers were ideal for those complex financial systems that were so difficult to accurately track. When money started to flow in computer systems, there arose a great incentive to start doing illegal things (such as transferring a few million dollars to your personal account). At first, financial systems were still batch jobs that were run by trusted computer staff members, but as more people saw the power of these systems, those people wanted access. Operating system vendors came out with a number of security features designed to control not only whether you had access to a system, but which resources (files, disks, printers, and so on) you were allowed to use. The next wave of security came from the military/intelligence community. The military/intelligence community faced the need to process huge volumes of classified material and keep it all straight. Their needs were even greater than the financial community in that if you caught someone taking money, you usually could recover it. If someone sold your top-secret war plans, you couldn't ask hostile governments to mail them back and forget about what they read. This led the government to pour a lot of money into developing security systems that provided fine levels of control as to what you could see, when you could see it, a record of when you actually did see it, and so on. This money was in the form of research grants on security theory to purchases of those early secure systems that were primitive by today's standards, but helped move the industry along so that it got to where it is today. Now most of you reading this chapter probably are not working for the Central Intelligence Agency or National Security Agency. Therefore, you probably are turned off by the idea of having to put in a huge amount of work just to configure every user account on your system. This is one of the challenges that Windows NT faces. The folks at Microsoft decided early on to implement a system that allowed for high levels of security. NT Security ModelWindows NT is certified at the C2 level by the National Security Agency. For those of you not familiar with those terms, it means that NSA put Windows NT through a tough series of checks on security and determined that it had a very reasonable security system based on a set of standards published in what is known as the Oracle guide (it has a typically long and boring title, but the cover is orange so that is how everyone identifies it). There are operating systems with the higher B level security rating, but very few commercial applications will run on these operating systems because the security features usually get in the way of basic functionality. An alternative to this is to secure the network on which the computer is located with a firewall (a network device that filters out unauthorized traffic), which usually has a B-level rating. The Windows NT team made a good decision when implementing their security model in that they allow you to degrade the security level of the operating system based on your needs. For example, the capability of the operating system to force you to change your password after a specified number of days and have a password with a controlled complexity (that is, 12345 does not cut it) is a requirement for certification. If you are in a wonderfully friendly environment in which security risks are low, you have the option of creating user accounts where the password never expires and users can even have a blank password. I would not recommend such a lax security environment, especially if you are connected to large networks or the Internet, but it is your choice. You can choose a tough security setup, a very lax one, or perhaps a reasonable compromise between the two, depending on your local needs. This leads to your first task as a user account administrator. You have to design a security plan that will implement that "just right" security environment for your system. The start to this design process is a knowledge of the options that Windows NT affords you. This chapter covers the basic security model and the basic options from which you can choose in the next several sections. These sections prepare you for the remaining sections of this chapter, which show you how to actually implement your grand plans. Windows NT User SecurityThis section discusses a few basics that should help you to understand how Windows NT approaches the task of security management. As with most computer functions, there are a number of ways to implement security. Figure 16.1 shows three of the more common models that you might run into. Each of these models has advantages and disadvantages, which will be covered so that you can better understand the strengths and weaknesses of the Windows NT security model. Alternative security models. Simple Access Security ModelPerhaps the simplest model is what I am calling the simple access system. It consists of a login ID and password combination that allows you access into the computer. After you are in the system, you have free range to access anything you want. The advantage of this type of system is that it is simple to administrate and provides adequate security in very simple environments. The disadvantage of this system is that it allows anyone who can get in to roam freely and access all resources. This may not seem like a problem to PC users who are used to having full access to the system, but on a mainframe in which you have a large number of different systems (such as engineering, accounting, and human resources), you run into problems when access to sensitive data and other resources is available. Resource Password Security ModelAn alternative implemented in some environments is to assign a password to each resource (as can be used in Windows for Workgroups). For example, you would set a special password on a directory or printer and then only distribute that password to those people you wanted to have access to that system. I have called this resource access in Figure 16.1. The advantages of this system are that it provides control over access on a resource-by-resource basis and is relatively simple to set up. The disadvantage is that it can be difficult to maintain. Suppose that someone obtains access to the password for the human resources data or someone transfers out of human resources and therefore, should have their access revoked. Your only alternative is to change the password on this data and distribute the new password to everyone who needs it. User Access Security ModelWindows NT follows the model labeled user access in Figure 16.1. This starts with a logon ID and password that identifies you to the operating system. After the operating system knows who you are, it then checks your name against a list of access restrictions when you access resources. The most common examples of resources in a Windows NT environment are shared directories, printers, and remote access connections. This access model has the advantage of providing a fine level of control, although there are those additional administrative actions needed to not only authorize the user to access the system but also to authorize the user to use all the resources that are appropriate for them. If you want this finer level of security, it is going to take more work. Windows NT provides you with some design features to make this job easier. These features come from observing the work of the typical system administrator. The first thing that became apparent was that users who performed the same job function tended to need the same operating system security accesses to perform their tasks. The system administrator typed the same series of access grants repeatedly, for all these folks. Why not capture all these privilege grants into a series of buckets and then just grant one or more buckets of privileges to the users? Creating GroupsThis is the concept of groups in Windows NT and other operating systems. You create the name for the group, select the privileges for that group, and then determine who gets that group of privileges. This is a powerful feature, especially for system administrators who have a large number of users for which to care. To take full advantage of groups, however, you need to plan the way in which you are going to organize your groups. Your first reaction might be to create a group for every type of user who will access your system. While this will work, it usually requires more work and that you create more groups. Let me show you an example of how a building block approach can be useful. Suppose that your server is supporting the accounting, marketing, and engineering departments. You have accountants who need access to the accounting data files and an accounting supervisor who accesses accounting data, plus a management information system. Your marketing department users access marketing data and have a supervisor who accesses this data, plus the management information system. Finally, you have the engineers who access two project databases (electronics and mechanical) and also have a supervisor who requires access to the management information system, as well as both project databases. From my previous discussion, you might say that there are seven Windows NT user groups that should be formed: accountant, accountant manager, marketing, marketing manager, electronics engineer, mechanical engineer, and engineering manager. You could create just five groups: accounting, marketing, electronics engineer, mechanical engineer, and management. You would grant the managers of the various departments two group privileges (such as accounting and manager). This is a simple example of a powerful concept. Suppose that your organization is more loosely organized and you have people working on multiple project teams that have their own privilege sets. If you construct the basic privilege sets correctly, you can grant and revoke group access to these individuals as they come and go from the various project teams. The two points should be emphasized are that you initially should spend some time planning your groups to save you work later on and that you re-evaluate your group structure from time to time, as the needs of your users evolve. Now you have worked out a system whereby you can easily administer a server with a large number of users and still have time left over to catch up on your reading. Word of your skill has spread far and wide. The next thing you know, your management has decided that you should maintain not only your server, but all the servers in your company. There probably will not be any pay increase associated with this responsibility, but you still have to get the job done. Building WorkgroupsA typical network of PC servers include machines running database management systems, acting as file servers, acting as mail servers, and so on. A given user may require access to many of these servers as time goes on (for example, I want to send a print job to the color laser printer on the second floor because it is the only one in the building and is attached to the second floor server). Keeping up with generating an account and assigning the correct privileges to a large number of users on multiple servers could become quite a burden. This brings up another consideration. Because Microsoft uses nice graphical tools to list the other computers on the network when you are trying to access remote resources, what would that display look like in a company that has several thousand computers? Most administrators do not want to have to scroll down through several hundred items in the list to find the one that they want. The solution to this problem is to group computers together into what Microsoft refers to as workgroups. A workgroup is one or more computers on a network that claim to have some logical relationship to one another. I say claim to have a relationship because you could take your computer, and via the Network Settings tool in Control Panel, join any group on your network, and it would appear to be a member of this group when people go to access network resources. Building DomainsNow we return to the problem of maintaining a number of computers on a network. Just as user groups solved the problem of granting a large number of access privileges to users on a single server, grouping computers together is Microsoft's solution to administrating a large number of servers on the network. As pointed out previously, however, the workgroup concept does not provide much in the way of security. Anyone can say that he or she is a member of the workgroup with a few simple settings changes on his or her computer. The solution to this is what Microsoft refers to as a domain. One can think of a domain as a secure workgroup with centralized administration. Figure 16.2 shows the different security configurations for a Windows NT network. The key here is that there needs to be a centralized security configuration database that verifies who you are and then relays this information to any other nodes on the network from which you are requesting resource access. For those who serve as administrators, this has the side blessing of providing a single maintenance point for the entire network. Windows NT network configurations.
The domain is a nice concept, but how do you implement one? It is somewhat impractical to configure a system in which all security information is stored on every node on the network. Actually, that would be a disadvantage for security purposes because it would provide opportunities for hackers to tweak the local security database when they log in as administrators on their local machines. Microsoft domain networks use servers that are designated as domain controllers to store this security access information. There are two types of domain controllers: primary and backup. Imagine a day when everything goes wrong with your server (crashes, failed hard disks, and so on). If only one domain controller existed on the network, you would have no way to validate users and allow them to access network resources. A backup domain controller enables the network to continue servicing your users until your primary domain controller returns to operation. The difference between primary and backup domain controllers revolves around the fact that when two servers disagree on a password (perhaps one server was down or is having a problem with a corrupted security file) or some other access privilege, someone has to settle the disagreement. The primary domain controller is the one that is right in this case. Backup domain controllers have other functions in addition to providing authentication services when the primary domain controller is down. First and foremost is that they can authenticate users on the network. The primary controller ensures that everyone is synchronized with one another, but any domain controller can authenticate a user to the domain. Therefore, if your servers are on several different network segments, you can place a local domain controller on each network segment to support those users. An important item to remember is that primary domain controllers are born, not made. By this I mean that you configure a machine as a primary domain controller during the installation procedure. You cannot change your mind later on and click a few buttons in the Control Panel to convert a regular machine to a primary domain controller. Also, a given domain on a given network can have only one primary domain controller. If two machines on a network and claim to be the primary domain controller, a battle will ensue to see which one the rest of the network trusts as the primary domain controller. That unit will get control of the domain and the other will be prevented from joining the domain, which makes absolute sense from a security point of view. Another important consideration is that other computers need permission to enter the domain. You cannot just change your Control Panel network settings to reflect that you now are a trusted member of the SALES domain. Instead, you need to have someone log in as domain administrator and authorize your entry onto the domain before you can participate in this security environment. This prevents someone from developing a program to gather security data from the network by sending and receiving authentication requests from a computer running an anything goes operating system, such as MS-DOS. Now that you are an expert on Windows NT domains, there is other topic to challenge you with. Imagine that you are supporting a large company. This organization is so large that it actually has multiple system administrators in multiple locations. You could build a large, centralized computer center on which all the corporate servers reside and have a central administrative staff take care of these computers. This, however, is a clumsy architecture prone to slow long-distance communications circuits and has many components that could fail and take down the entire network. In reality, it usually makes sense to implement multiple domains that are matched up with the locations and organizations within your company. Domain Trust RelationshipsIn this era of cooperation among different groups to achieve the overall organizational goals, however, a way to get accesses to services within another domain can come in quite handy. To make this happen, Microsoft implemented what it called trust relationships among domains. This works much like the way the name implies. You tell one domain that it should trust the security validations of another domain. It is not carte blanche access to all the resources in your domain by any user validated in the other domain. You still must grant access privileges to the users of that other domain in order for them to get access to any resources that you have not designated as being available to everyone. This brings up yet another set of terms you must become familiar with in order to be a Windows NT domain system administrator: local and global groups. Within your domain, you can use local groups to assign privileges to access resources. In effect, you are saying that if a user can show credentials that he or she is a member of group that has access to a resource (as determined by a domain controller), then the machine providing the requested resources should honor the request. What do you do when other domain administrators create groups that have the same name that you have used (managers, for example)? The answer is that the groups you typically create are local groups that identify the user within your domain. If you want to identify a user to other domains with which you have set up trust relationships, you must create what Microsoft refers to as a global domain, whose name is coordinated with the trusted and trusting domains out there. The domain administrators in these domains then grant access to their resources to the global groups, which is how users in other domains get access to resources. A few points need to be made about trust relationships. First, trust relationships are one-way, not two-way. If I trust you, that does not mean that you trust me. Second, both domain administrators must agree to the trust relationship. I cannot just say that I trust you and you cannot say that I trust you. Finally, the relationships are not point-to-point and do not imply any hierarchy of trust relationships. By this I mean that if domain A trusts domain B, and domain B trusts domain C, this does not imply that domain A trusts domain C. This actually can be helpful to administrators. You might not be familiar with the trust relationships of another domain. That domain may have trust relationships with domains that you do not want to establish a trust relationship with for your domain. Before finishing this general discussion on domain security, a few points need some attention. First, the Security Account Manager (SAM) for the domain server can only manage 16,000 user accounts. For most of us, that is a large limit and we will never even get close to it. It does, however, have implications for those large organizations that would like to use a large, centralized domain controller to serve as the master account controller for all users in the organization. It also affects how people architect their trust relationship hierarchy to ensure that all their groups work together. Figure 16.3 shows some of the alternative domain configurations. Alternative domain trust relationships.
I provide three examples of domain configurations, which should cover most Windows NT networks. In the first case, which I refer to as Master Domain, you have a central domain which serves as the master security environment for the organization. Other domains provide services to the end users based on information obtained from the master domain. This allows more efficient administration and better control over security at the cost of being dependent that the master domain will always be accessible. The next domain configuration example that I propose is what I call peer to peer. In this case, each domain has its own administration and controls granting access to its users. Users from one domain can access resources in the other domain, based on grants to foreign groups based on trust agreements between the domains. This provides localized control over security while allowing users to access resources in other domains. It is probably the simplest one to maintain. The final example that I provide is what I call multiple trust relationships. While the master domain configuration is a parent child environment and the peer to peer is an everyone is equal environment, the multiple trust relationships can be thought of as a complex web of security and access grants. Conceptually it is similar to the peer to peer in that everyone takes care of their own people. The difference here is that you grant access rights to a number of other domains. This can be complex to administer, but may be the appropriate solution in environments where local divisions control their networks and only allow other divisions to access their resources as needed. There are a number of other domain trust architectures which could be thought up. The examples above are designed to illustrate some of the basic environments that you might run across. The peer to peer would probably be the simplest to implement if you are just starting out. For a more complete discussion of the domain environment and trust relationships, the guides in the Windows NT Resource kit provide several chapters which go into the concepts of networking and security in more detail. After having taken up quite a number of pages in this chapter, this discussion merely is a summary of what could be said about the Windows NT security model. You can download a number of technical papers form the Web and the various Microsoft CDs that provide additional detailed information about the intricacies of the domain and workgroup security implementations. There could be entire chapters to the various authentication system components, such as NETLOGON. This chapter, however, has a more practical intent. This discussion was designed to prepare you for the next section, which discusses the controls that the system administrator has over a given user's account. Together, these two sections prepare you for the day-to-day chores of user administration and the how-to sections that make up the remainder of this chapter. Attributes of a UserIt would be extremely difficult for you to properly control user accounts if you did not know the various things over which you have control. This section discusses the components in what I call the overall user environment. Following is a simple summary list of control features:
If you want to get fancy, you can find more to tweak, but from my experience, this is the set that will serve you in the vast majority of cases. The preceding items interact with one another to help you accomplish your goals. Each item is incomplete by itself and requires the other items to properly control the user's interactions with resources. The rest of this section provides an overview of each of these tools that you will need to understand in order to become a full-fledged Windows NT system administrator. Logon IDs, Passwords, and GroupsThe first topic is the user logon ID and password. The concepts actually are relatively simple and resemble those on most other operating systems. This is the first instance of how the various properties of the user environment will interact, however. Many security types set limitations on the passwords that are selected in order to make them difficult to guess. The rule of thumb usually is "at least seven characters long." Even if you, as the administrator, create the user logon ID and password following this rule, what will stop the users from using the password change utilities to choose a password such as "12345"? To prevent this, you will need to use the policy features of Windows NT. The group feature has already been discussed as a powerful tool in the user administration process. The key here is that resource accesses can be given to either individuals or groups. When given to groups, a user who is made a member of that group automatically inherits all the privileges of the group itself. This enables you to quickly give users the privileges they need to complete their jobs. Another advantage of this is that you can choose the group names to be meaningful to you. This enables you to quickly scroll through the list of groups and determine which groups are appropriate for a new user. Account Policies, Rights, and ProfilesThe account policy feature is not always used by NT administrators, but can be quite powerful. The user policy under Windows NT sets up other facets of the user operating environment other than the group privileges related to what the user is allowed to do on the system. This is where you set up the system to ensure that the password is complex and secure enough for your organization's security needs. Some of the features controlled by the user profile include the following:
A closely related set of policies made by the system administrator are user rights. These focus primarily on what the user is allowed to do with the operating system. This is discussed in detail in the User Rights section, but for now you should have a feel for a few of the functions of the User Rights tool.
A closely related user control feature is the user profile. This feature specifies the available program groups. It also controls whether the Run command is allowed on the File menu. You can create a number of profiles and assign them to various users. There used to be some confusion over having to work with multiple tools that were needed to set up the profile of operation for a given user. The good news about Windows NT 4 is that Microsoft has consolidated almost all of the user setup controls in the User Manager tool. When you call up the properties screen for a given user under User Manager, you will find a button labeled Profile which discusses many of the features discussed in the next couple of paragraphs. Some enhanced fine-tuning over the user's working environment can be made using the System Policy Editor on the Administrative Tools menu. You get to control some low level details such as which wallpaper graphic will be displayed as the desktop for a given user. The System Policy Editor allows you to assign a policy to a given user or group. Home Directories, Logon Scripts, Logon Time, and Logon CapabilitiesThe next control feature of the user environment is the home directory. You have the option of specifying a directory that the user will access by default for all save operations that are directly controlled by the operating system. If you open up a DOS prompt, for example, the home directory will be the default. Note, however, that many applications (such as Microsoft Word) have their own Settings panel in which they set up the default storage and retrieval directories for their files. Another useful environmental control feature is the logon script. Suppose that there is an action to want performed every time the user logs in, but you cannot find any operating system setting to accomplish your goal. An alternative is to create a batch file (or an executable program) that performs the action you want and then specify that file or program to be the logon script for a given set of users. This also is a nice alternative in environments in which you want to force the users into a menu program or perhaps even just a single application when they log in. In these cases, you can enhance security and usability by not allowing the users to get to the desktop and have the full power of the Windows NT operating system.
Rounding out the list of environmental control features, you come to the capability to control when a user can log in to the system. A major security concern in some organizations is that a user could come in after hours and access the system in an illegal manner. Other environments might contain large batch jobs or have system maintenance activities that occur during specified periods. If these maintenance activities require that all users be logged off, it would be helpful to have a utility that kept disallow users from logging in during these periods. Windows NT provides such a utility in the User Manager tool that gives you a good degree of control over the hours that users can access the system. Remote AccessYou use the RAS administrative utilities to specify whether a given user has access to RAS. You also can implement additional security by requiring a call-back to a specified number when a user dials into your system. This way, the only way someone can hack in, using one of your user's IDs would be if they were calling from the user's house (add breaking and entering to the computer hacking crimes). Remote access to computer resources such as data files and electronic mail is a wonderful convenience, however it can also be a major security hole. Anyone with a modem and telephone connection can dial up your server (assuming that they know the telephone number) and gain access to your network, bypassing all of the physical security controls of your building. You need to consider the impact of security against productivity when implementing RAS dial-in. An interesting note for version 4.0 of NT is that RAS security is now integrated into the User Manager tool. In version 3.51, you set up the properties of your user (with the exception of remote access) using the User Manager tool. You then had to use the RAS Admin tool to grant dial in privileges (which were defaulted to prevent remote access). While you can still use the RAS Admin tool to set up dial-in privileges, the User Properties page allows you to set up dial-in permissions for the section user from within User Manager. User EnvironmentFinally, the user environment is rounded out by rights and privileges set up for the applications provided on your server. Depending on the application, rights and privileges may simply enhance the environmental parameters you set up for the user as the Windows NT administrator, or they may form a complete environment of their own. If you are using a client-server architecture to access information on a Windows NT Oracle database, for example, the database will provide all security and control the user environment. In many cases, the user does not even need an operating system account to access the database. Windows NT Server's User Manager ToolThis section discusses the practical nuts and bolts of Windows NT user administration. The main tool that enables you to control your users is the User Manager tool, which is available on the Administrative Tools menu. User Manager has one of two titles, depending on whether you are using a server, a workstation in a domain, or a workstation in a workgroup. The server always uses the User Manager for Domain tools (even when you are in a workgroup). The workstation uses User Manager (without the Domains) when you are in a workgroup, but will use User Manager for Domains if it is in a domain. In the domain environment, the updates are sent to the domain controllers rather than the local security database. My first impression of the administrative environment in Windows NT 3.5 was based on the Control Panel mindset. When you have a function you want to perform, you build a small application to perform the function and slap it into a program group with the other administrative tools. I am impressed with the trend in Windows NT 4, and especially in the User Manager tool, towards building integrated tools. The User Manager tool sets almost all of the administrative properties for a user. It even integrates with Microsoft Exchange Server (their electronic mail system in BackOffice) to bring up properties pages to configure the person's electronic mail account when you add a new user to the operating system. With all of the power built into User Manager, I like to place a shortcut to the application on my desktop so that I have ready access to it. Most of the tools in Windows NT 4.0 seem determined to use an explorer-like tree control somewhere in their display. User Manager is one exception to this rule (at least for now). Its interface adheres to the basic premise of a relatively clean interface that provides access to all the necessary control features using pull-down menus and simple controls, such as double-clicking. Figure 16.4 shows the basic User Manager display. The User Manager for Domains Display.
This review of User Manager begins by going through the key pull-down menu items that you will be using. The first of these menus is the User menu. Here you will see a couple of clues that tell you are using a Windows NT 4.0 server, which gives me the User Manager for Domains utility. The clues are that there are menu picks to add a New Global Group and Select Domain. These menu picks typically display a dialog box that enables you to fill in the details of the action you are taking or prompts you to confirm that you really want to do what you asked for (such as delete a user). The actions on these menus are taken for the user that is highlighted in the case of copy, delete, rename, and properties. The remaining items, such as New User, by their very definition imply that you should see a dialog box to create a new item or perform an action, such as select domain. The next menu is the Policies menu. View menu was skipped because it is pretty much what you would expect (it controls the way in which items are sorted in the display and provides an option to refresh the lists). The Policies menu provides you with access to most of the user environmental parameters that do not involve resource access discussed in the last section. It also includes a function enables you to set your Trust Relationships. An extension of my last thought in the preceding paragraph is shown in Figure 16.4. Here you see the integration of the Microsoft Exchange Server with the User Manager. This integration goes a long way actually in that when you add a user to your system that contains Exchange Server, you will be prompted to enter the information needed to create an electronic mail account. With the exception of RAS access, which is discussed in the Remote Access Service (RAS) Security section later in this chapter, User Manager is one place to perform almost all your user-management activities. Groups in User ManagerNow it is time to go over some of the functions that are activated by these menus. The first function enables you to add or modify groups. You can add a new group by choosing either New Local Group or New Global Group from the User menu. To modify an existing group, highlight the group and choose Properties from the User menu or double-click the group name. Figure 16.5 shows the panel that appears when you modify the properties of an existing group. The only difference you will see when adding a new group is that you are allowed to enter the group name; otherwise the panels are identical. The Group Properties pane is very simple with which to work. You have the group name, a text description to help you out in the future, and two sets of lists. The first list shows the users who are members of the group. The second list shows the users who are not members of the group. To move users between the members and non-members categories, highlight the user you want to move and click the Add or Remove buttons. Group Properties dialog box under User Manager. User Properties in User ManagerThe User Properties panel is shown in Figure 16.6. It enables administrators to add or modify the basic logon properties of a user and, therefore, is one of the most commonly used tools in User Manager. As you can see, it is a simple panel that enables you to enter username (when adding users, this becomes a non-editable field when modifying the properties of an existing user), full name, description of the user, and two fields that enable the administrator to modify the user's password. In addition, the checkboxes control the following features:
User Properties Page of User Manager. Group Memberships in User ManagerAt the bottom of the User Properties page are important buttons with which you need to become familiar. These buttons access dialog boxes that enable you to set many of the other environmental parameters for the user's account. The first of these properties is the group affiliation of the user. Figure 16.7 shows the Group Memberships dialog box. As you can see, it provides you with two lists; one showing the groups to which the user belongs and one that shows the groups to which the user does not belong. The Add and Remove buttons enable you to move a group from one list to the other. Group Memberships dialog box of User Manager. User Environment Profile in User ManagerThe User Environment Profile is activated by the profile button. Figure 16.8 shows the panel that appears. Be careful not to confuse this button with the User Profile Editor that is provided in the Administrative Tools Start Menu group. The Profile button enables you to select the user profile file (as edited by the User Profile Editor) that applies to this user. It also enables you to specify a logon script that runs every time the user logs onto the system or domain. At the bottom of this panel are fields that enable you to specify the home directory the operating system will use as a default for those times when the applications do not provide their own fully qualified path. User Environment Profile panel of User Manager. Logon Hours in User ManagerContinuing on with the user environmental parameters that are controlled using from the buttons on the bottom of the User Properties page, you come to the Logon Hours panel (see Figure 16.9). To set the hours of operations, using your mouse, highlight the range of hours with which you want to work and then click the allow or disallow buttons. The sections with the blue lines through the middle are the allowed hours of operation. The sections that are black are the hours in which the user is not allowed to log on. The key here is that these are the hours when the system will allow the logon (connection) process to occur. It does not automatically log off users who are on the system if they are still on the system after the allowed hours. Logon Hours Panel of User Manager. Workstations Allowed in User ManagerAnother useful feature on the User Properties page is the capability to restrict workstations from which a particular user is allowed to log in. Figure 16.10 shows the basic data entry panel, which is a very simple interface. You can allow the user to log on from all workstations in the domain or you can specify the list of workstations from which the user can log on. This is helpful in operational environments where users should be at a specific console when performing certain critical tasks. You should ensure that people can log into enough workstations to ensure system access in the event of hardware or network failures. Logon Workstations panel of User Manager. Account Parameters in User ManagerThe next dialog box that you can access from the buttons at the bottom of the User Properties page controls certain parameters related to the user's account (see Figure 16.11). The first parameter controls when the user's account expires. This usually is implemented as a safeguard to prevent you from forgetting to disable the account of a contractor or permanent employee when they leave. I tend not to use this parameter, but there are some environments in which this parameter might be mandatory (such as access to a computer that requires a security clearance to be updated at regular intervals so that access is not denied). The other parameter enables you to specify whether this is a Global Account (which is the normal account that you create) or a local account for users from non-trusted domains. Account Information panel of User Manager. PoliciesNext is a discussion of the attributes of the user environment that are controlled from the Policies pull-down menu. This is where you set the global policies for your domain or server as a whole, as opposed to the properties that you set for individual users. The first of these property pages is the Account Policy page (see Figure 16.12). Most of the features you see in this figure determine whether you are going to implement those complex security features that Microsoft had to put into Windows NT to receive that C2 security certification. The good news is that you can turn them all off, turn them all on, or select the features that will be operational, based on your needs. For further discussion of policies, see Chapter 25, Advanced Security Guidelines. Account Policy dialog box of User Manager. User RightsThe next policy editor user the Policies pull-down menu is the User Rights Policy editor that facilitates granting users and groups the capability to perform certain sensitive system functions. Figure 16.13 shows the dialog box that appears. You need to select the function that you wish to grant or revoke privileges on and then use the add or remove buttons to add or remove users or groups from this privilege. The following list discusses the privileges you can control with the ??? dialog box:
User Rights Policy dialog box of User Manager. AuditingThe final policy editor that you will work with sets up the events to be audited by your system. Chapter 24 discusses auditing in greater detail. For now, just look at Figure 16.14. As you can see, you have the option of disabling auditing (you still have the basic security and system event monitoring provided by Event Viewer) or activating only the pieces that interest you. Before activating any of these menu choices, you need to think about the times per day the event you are going to audit occurs. For example, while security policy changes are rare (and also extremely important from a security point of view), use of user rights occurs many times per minute. Each time the event occurs, you will have a record written to the audit trail that you have to review (this also takes up space on your hard disk drives). It is a balancing act of getting enough information without creating more information than you can review or store. Audit Policy dialog box in User Manager. Trust RelationshipsThe Trust Relationships dialog box enables you to say that you trust another domain or that you permit another domain to trust you (see Figure 16.15). Remember that both sides must agree to a trust relationship (I trust you and you allow me to trust you) before anything happens with it. You should be sure that you are comfortable with the implications of trust relationships and discuss the setup with the other domain administrators before you set up trust relationships. The key to a successful multiple domain configuration is having an agreed to plan before the network is implemented. Trust Relationships dialog box in User Manager. Other User Manager PanelsThere are a few other minor panels that you can find on the User Manager display, but the ones discussed in this section are the ones that you will need to get your day-to-day job done. Before moving on, there are a few topics to clean up. First are the following groups created by default when you set up a Windows NT 4.0 server:
Predefined AccountsYou also will have the following accounts set up for you:
Windows NT Server's System Policy EditorAlmost all the properties of a user's environment are set by the User Manager tool. Microsoft has continued to enhance this feature so that it is a complete tool for administrators. The System Policy Editor (which is not yet integrated into User Manager) enables you to set a series of parameters that relate to the appearance of the user's desktop, which operating system functions (i.e. Control Panel) they are allowed to access and other very fine controls over user activity. (See Figure 16.16.) If you are running servers exclusively using a client-server architecture, you probably will not use the System Policy Editor often because your users will access the server through the network for shared resources. If you have a number of users who actually work on NT workstations, you might want to take the time to become familiar with the functionality that this editor allows you to control on your user accounts. System Policy Editor. Remote Access Service (RAS) SecurityThe Remote Access Service (RAS) monitoring and configuration tool is access from the Administrative Tools menu. Its purpose is to control the service that monitors your modems for dial in requests. It also allows you to specify which users are allowed to access the modems, although the User Manager tool can also be used in NT 4 to set up user access to RAS. Another key change in NT 4 is that the dial-out utilities are no long called RAS. Instead, they are located under the Dial-Up Networking tool in the Accessories menu or in the My Computer display. The Remote Access Admin tool has a simple display that shows you the status of the RAS server on the computer that you have selected as shown in Figure 16.17. Note that you can control and monitor the RAS services on another computer by choosing the Sever menu, Select Domain or Server option. Remote Access Admin Display.
The first task you might want to accomplish is to start or stop the remote access service. Stopping and starting RAS might be necessary to run other communication packages that will not run as long as your modem is dedicated to listening for incoming calls to RAS. The stop and stop functions are located on the Server menu, along with a pause (which means don't take calls, but don't shut down the server or free up the modem). An interesting thing to note is that you can select the domain and server you are administrating when you are in a domain environment. This is another example of how Microsoft is integrating remote administration into their basic tools as opposed to building separate remote access tools. (Just wait until you see the next version of the operating system and applications which will integrate Web access). How do you control who accesses your system via telephone lines? The Permissions menu item on the Users menu is the main access control tool. It is relatively simple to understand. You select a user you are interested in and then specify in Grant dial-in permission to user whether the user has dial-in access. At the bottom of the dialog box is the option of setting whether the system calls back the user. Call backs are a security feature that limits the hacker's capability to log into the system. Suppose that your users only want access from home and you set up the system so that it automatically calls the user back at home after a successful logon. Even if a hacker successfully guesses the user's ID and password, the worst that will happen is that the user's PC at home will get a call back, thereby preventing the hacker from gaining any real access to your system. An innovation in NT 4.0 RAS is the fact that you now can specify the RAS access permissions for users from within the User Manager tool that was discussed in the User Manager section of this chapter. Remote Access Permissions dialog box.
There is one final topic left in my RAS discussion. Suppose that you see the lights on your modem and know that someone has dialed in. How do you find out who it is that is logged in? The Active Users menu item on the Users menu shows you who is connected, to which server the user is connected, and when that user's connection started (see Figure 16.19). The buttons at the right of the display enable you to get more information on the user account, send that user a message, (such as "the system is going down in 10 minutes"), or even disconnect the user. Chapter 20 discussed RAS in more detail. Remote Access user's display. Resource Access GrantsSo far, we have classified users into groups and set environmental parameters for them. However, they still have next to nothing in terms of shared network resources unless they are connected to their local machines. The other half of the user administration picture is the access grants to resources. This actually is quite simple under the new Windows NT 4.0 interface. For example, to grant a user access to a directory, you follow a simple two-step process. First, you select the directory that is to be shared using Explorer or My Computer tools and create a share name for it. (See Figure 16.20.) The easiest way to create a share name is to highlight the directory of interest and then right-click your mouse and select the sharing option from the pop-up menu appears. Creating a share name for a folder.
Step two in this process is to select the permissions button on the Sharing tab dialog and fill in the Permissions dialog box. (See Figure 16.21.) This functions like most of the other administrative control tools. To delete permissions, highlight that user and click the Remove button. To add permissions, click the Add button, select first the user or group to give the permission to, and then choose the type of access permission. For files, the permissions are Full Control, which allows directory modification, Read which allows users to look but not touch, Change which allows them to look but not change, and No Access which does not allow them to even look at the list of files. Access through the Share Permissions dialog box.
The concepts in the preceding paragraph apply to printers also. You select the Printers options of the Settings selection on the Start menu and then highlight the printer with which you want to work. Specify the share name under the Sharing tab of the tab dialogs that are presented to you when you right-click on that printer and select the Sharing menu option. You control who has access to the printer on the security tab dialog. The enhanced NT 4 printer setup options provide the fine degree of printer control that is provided by mainframes and minicomputer systems, which is pretty impressive for a little PC-based server. Routine MonitoringThis has been a long and challenging chapter as user administration is complex. It also is an important topic to administrators because it takes up a fair amount of their time. You probably are ready to take a break about now, but there is one more thing you need to know. Suppose that you set up the most perfect user administration scheme known to mankind (fantastic groups, the best policies, and so on). How long do you think things are going to stay the same? From my experience, change is the one thing that you can count on. You will have users quit and others that take their place. People move between departments and get promoted. You have to keep up with these changes to ensure that everyone has the user environment that they need (and also that they do not have more than they need). To do this, you need to have a system whereby the needs of the users are conveyed to you, the system administrator. Many companies have forms that personnel departments have filled out when people leave or change jobs. If you can get this form routed to you, it can save you time checking to see that everyone is where they are supposed to be. You also can make up user request forms (either paper or online) to change privileges after they have the appropriate approvals. Finally, you need to periodically schedule some of your limited time to go through the settings that I have discussed in this chapter to ensure that things are still correct. Enough said, to keep your system running smoothly, you have to look at it and tune it up occasionally. SummaryThis chapter has covered a lot of ground. You must think about many things when dealing with Windows NT user administration. You first have to understand the basic security and user environment options that are provided for you. You next have to come up with a plan of how you want to administer your system. Finally, you have to understand the tools that Microsoft provides to perform these administrative tasks. This chapter is just a starting point for many of you. There are many technical papers, located on the Microsoft TechNet CDs, that cover the intricacies of the Windows network and NT security system. Before leaving this chapter, however, you should be comfortable with the basic concepts of NT user administration and be able to set up your basic server, workgroup or domain.
|
