1. Trang chủ
  2. » Công Nghệ Thông Tin

The Best Damn Windows Server 2003 Book Period- P47 pdf

10 292 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 10
Dung lượng 413,1 KB

Nội dung

a tree that represents the directory tree. By browsing the folders in this tree, you can select the con- tainer you want the object moved to, and then click OK to being the move. When using Active Directory Users and Computers, multiple objects can be selected and moved to other locations.You can select these objects as you would files in Windows Explorer, by dragging your mouse over the objects to be moved.You can also select a series of objects by holding down the Shift key as you click on objects, or select a number of individual objects by holding down the Ctrl key as you click on them. After selecting the objects to be moved, perform the actions we just discussed to move them to another container or OU. Moving Objects with the DSMOVE Command DSMOVE is used to move objects within a domain, and can be used to rename objects. DSMOVE is a command-line utility that is used from the command prompt. Providing you don’t need to move an object to another domain, you can use this tool to move an object to other locations in the directory tree.The syntax for using this tool is as follows: DSMOVE UserDN [-newparent ParentDN] -pwd {Password|*} In using this syntax, several different parameters must be entered for moving the object.The UserDN parameter specifies the DN of the object being moved.The –newparent switch indicates that you are using DSMOVE to move an object, and is used with the ParentDN variable to specify the DN of the new location. To illustrate how this command is used, let’s say you wanted to move an object called BuddyJ from the Sales OU in knightware.ca to the Finance OU in the same domain.To move this object, you would use the following command: Dsmove CN=BuddyJ,OU=Sales,DC=knightware,DC=ca –newparent OU=Finance,DC=knightware,DC=ca 426 Chapter 10 • Working with User, Group, and Computer Accounts Figure 10.41 Move Dialog Box 301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 426 DSMOVE also provides additional parameters to perform actions such as renaming an object, or controlling the type of input and output for this command.To review these parameters, refer to the section on DSMOVE in Chapter 9. Moving Objects with the MOVETREE Command MOVETREE is the Active Directory Object Manager tool. In addition to other capabilities, it is a command-line tool that allows you to move objects to other domains in a forest. By using this tool, you have the freedom to move a user account, computer account, group, or OU to any location within the directory, regardless of the domain. When an object is moved using this tool, it is first copied to the Lost and Found container before being moved to the destination domain. Objects that can’t be moved remain in this con- tainer, so you can manage them as needed. Because orphaned data might reside in this domain after using MOVETREE, you should check this container after performing a move. A variety of information isn’t moved with this tool.This includes data such as profiles, logon scripts, and personal information when moving user accounts. Local groups and global groups also aren’t moved, but membership in these groups remains unaffected so that security involving the moved objects remains the same. In addition to the limitations on data associated with accounts, there are also limitations when MOVETREE is used to move OUs between domains. When an OU is moved, group policies aren’t affected, as clients will continue to receive these settings from a link to the policy in the orig- inal domain. In other words, although the OU is now in another domain, clients will connect to the Group Policy Object (GPO) that is located in the original domain. Because this can cause perfor- mance issues, it is wise to recreate these policies in the domain where the OU has been moved, and then delete the GPO in the original domain (which is no longer needed). As a command-line tool, MOVETREE requires that certain parameters be used to effectively complete operations.The syntax for MOVETREE is as follows, and the parameters are explained in Table 10.6. MoveTree [/start | /continue | /check] [/s SrcDSA] [/d DstDSA] [/sdn SrcDN] [/ddn DstDN] [/u Domain\Username] [/p Password] [/quiet] Table 10.6 Parameters for MOVETREE Parameter Description /start Specifies whether to start a move with a /check option, or with the /startnocheck option, which starts the operation without a check. /continue Specifies to continue the move after a failure. /check Specifies to check the entire tree before moving an object. /s SrcDSA The SrcDSA variable is used to specify the FQDN of the source server. Working with User, Group, and Computer Accounts • Chapter 10 427 Continued 301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 427 Table 10.6 Parameters for MOVETREE Parameter Description /d DstDSA The DstDSA variable is used to specify the FQDN of the desti- nation server. /sdn SrcDN The SrcDN variable is used to specify the source subtree’s root DN. /ddn DstDN The DstDN variable is used to specify the destination subtree’s root DN. /u Domain\Username Specifies the domain and user account to use for the opera- tion. /p Password Specifies the password of the account to use for the operation. /quiet Specifies that quiet mode should be used, suppressing output. The Active Directory Object Manager tool isn’t installed with Active Directory, and thereby isn’t initially available for use. MOVETREE is available as part of the Active Directory Support Tools on the installation CD, and can be installed through Windows Explorer. By accessing the Support\Tools folder on the installation CD, right-clicking on SUPTOOLS.MSI, and then choosing Install from the menu that appears, the Windows Support Tools Setup Wizard will start. By following the instructions in this wizard, MOVETREE and the other support tools will be installed. You can use the following steps to install MOVETREE with AD support tools. Install MOVETREE with AD Support Tools 1. Insert the Windows Server 2003 Server installation CD into your CD-ROM drive. 2. From the Windows Start menu, select Windows Explorer. 3. When Windows Explorer opens, expand the node representing your CD-ROM drive, and then expand the Support | Tools folder. 4. When the contents of the Tools folder is displayed in the right pane, right-click on the SUPTOOLS.MSI file and click Install in the context menu. 5. When the Windows Support Tools Setup Wizard appears, click Next to continue. 6. On the End User License Agreement screen, click I Agree to install these tools, and then click Next to continue. 7. On the User Information screen, enter your name in the Name field, and the company you work for in the Organization field. By default, these fields will already be completed from information acquired from Windows Server 2003 Server. Click Next to continue. 8. On the Destination Directory screen, accept the default settings, and click Install Now to install the tools. 428 Chapter 10 • Working with User, Group, and Computer Accounts 301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 428 9. A dialog box will appear showing that files are being copied to the folder specified in the Destination Directory screen, and being installed on Windows Server 2003. Once com- pleted, the final screen of the wizard will appear, informing you that the tools were suc- cessfully installed. Click Finish to exit the wizard and complete the installation process. Troubleshooting Problems with Accounts Troubleshooting problems with accounts relies on the same methodologies and practices involved in troubleshooting other problems in Windows Server 2003. It requires an understanding of functions, configurations, and limitations. It also requires starting at the simplest possible solution for a problem and working up to the most complex. For example, if a user’s account wasn’t working, you wouldn’t start by restoring Active Directory from a previous backup from when the user was able to log on. You might, however, check to see if the account was disabled or locked out. It is important that you determine whether the problem exists with the user who’s logging on from a computer, or with the machine itself.You’ll remember that Active Directory uses both com- puter and user accounts. If a problem is resulting from the computer account, no user will be able to perform a certain action from the machine, regardless of what user account is used. At times, the problems that exist in a computer account might require resetting it. If you want to reset a computer account, in Active Directory Users and Computers, you can right-click on the account you want to reset, and then click Reset from the menu that appears. After a moment, a message box will appear stating that the account was reset. Another important part of troubleshooting is determining the scope of a problem. Is only one person experiencing a problem, or are a number of people experiencing the same difficulties? In doing so, you can determine whether the problem is with a user or computer account, or with a group of which these members are a part. The problem might not exist in the user’s account settings, but with DCs in the domain. For example, if you couldn’t create security principals in Active Directory, the problem could stem from the fact that the RID Master is unavailable.The DC that has the RID operations master role allo- cates RIDs used for SIDs. Because SIDs can’t be issued to new user accounts, computer accounts, and groups, these security principals can’t be created. You could use the command netdom query fsmo to identify which computers are holding single oper- ation master roles. Once you’ve identified the DC serving in a particular master role, you could either repair the machine, or assign the operations master role to another machine. Before going through all this work, however, you should remember that the reason why others can’t perform such actions might be because they don’t have the proper rights, privileges, or permissions. In all cases, remember to start by looking at the simplest possible solution first. Working with User, Group, and Computer Accounts • Chapter 10 429 301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 429 301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 430 Creating User and Group Strategies In this chapter:  Create a password policy for domain users.  Plan a security group strategy.  Plan a user authentication strategy. Introduction Knowing how to create users and groups and the procedures for moving and managing them is only half the battle when it comes to effectively using these security objects on the network.The network administrator must also be able to develop strategies for authenticating the identity of anyone who uses network resources, and plan how to use groups most effectively to provide the security and access needed. In today’s connected world, proof of your identity is often required to ensure that someone else is not trying to use your identity. It used to be that a username and pass- word were sufficient to authenticate someone to a network. However, password authen- tication is only the first step in true authentication of a user’s identity in today’s environment.You must have a well-defined password policy, which includes account lockout, password rotation, and other options to ensure limited access to your network. In this chapter, we develop a password policy for your Windows Server 2003 network. However, sometimes passwords and password policies are not enough, and we have to take authentication to the next plateau. Tools such as biometric devices, token devices, voice identification, and smart cards are becoming much more mainstream for user authentication as the price continues to drop and acceptance continues to rise. Smart cards are discussed in a later chapter “Planning, Implementing, Maintaining Public Key Infrastructure.” An effective authentication strategy works hand in hand with a security group strategy.A well-designed group strategy will ensure that users receive only the appropriate Chapter 11 431 301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 431 level of access to resources on the network. It will also reduce the workload of the administrator and make it easier to manage large numbers of users. Creating a Password Policy for Domain Users Since they are largely created and managed by end users, passwords have the potential to be the weakest link in any network security implementation. Since passwords are the “keys to the kingdom” of any computer system, the database that Windows Server 2003 uses to store password information will be a common attack vector for anyone attempting to hack your network. Windows Server 2003 offers several means to secure passwords on your network.A combination of technical measures, along with a healthy dose of user training and awareness, will go a long way toward pro- tecting the security of your network systems. Creating an Extensive Defense Model In modern computer security, a system administrator needs to create a security plan that uses many different mechanisms to protect a network from unauthorized access. Rather than relying solely on a hardware firewall and nothing else, defense in depth would also use strong passwords as well as other mechanisms on local client PCs, in the event that the firewall is compromised.The idea is to create a series of security mechanisms so that if one is circumvented, other systems and procedures are in place to help impede an attacker. Microsoft refers to this practice as an extensive defense model.The key points of this model are the following: ■ A viable security plan needs to begin and end with user awareness, since a technical mech- anism is only as effective as the extent to which the users on your network adhere to it.As an administrator, you need to educate your users about how to best protect their accounts from unauthorized attacks. ■ Use the system key utility (syskey) on all critical machines on your network.This utility, discussed later in this chapter, provides additional encryption for password information that is stored in the Security Accounts Manager (SAM) and Active Directory databases. ■ Educate your users about the potential hazards of selecting the Save My Password feature or any similar feature on mission-critical applications, such as remote access or VPN clients. ■ If you need to create one or more service accounts for applications to use, make sure that these accounts have different passwords. Otherwise, compromise of one account might leave multiple network applications open to attack. ■ If you suspect that a user account has been compromised, change the password immediately. If possible, consider renaming the account entirely, since it is now a known attack vector. ■ Create a password policy and/or account lockout policy that is appropriate to your organi- zation’s needs. It’s important to strike a balance between security and usability in designing these types of account policies. 432 Chapter 11 • Creating User and Group Strategies 301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 432 Strong Passwords In discussing security awareness with your user community, one of the most critical issues to con- sider is that of password strength.A weak password will provide potential attackers with easy access to your users’ computers, and consequently the rest of your company’s network. Well-formed pass- words will be significantly more difficult to decipher. Even though password-cracking utilities con- tinue to evolve and improve, educating your users regarding the importance of strong passwords will provide additional security for your network’s computing resources. According to Microsoft, a weak password is one that contains any portion of your name, your company’s name, or your network logon ID. For example, if a username was assigned as JSmith, and the user’s password was Smith12!@!, that would be considered a weak password.A password that contains any complete dictionary word—password, thunder, protocol—is also considered weak. It should be understood that blank passwords are weak as well. By comparison, a strong password will not contain any reference to your username, personal information, company name, or any word found in the dictionary. Strong passwords should also be at least seven characters long and contain characters from each of the following groups: ■ Uppercase letters A, B, C … ■ Lowercase letters z, y, x … ■ Numeric digits 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9 ■ Non-alphanumeric characters !, *, $, }, etc. Each strong password should be appreciably different from any previous passwords that the user has created. P!234abc, Q!234abc, and R!234abc, although each meeting the described password cri- teria, would not be considered strong passwords when viewed as a whole. System Key Utility Most password-cracking software used in attacking computer networks attempts to target the SAM database or the Active Directory database in order to access passwords for user accounts.To secure your password information, you should use the system key utility (the syskey.exe file itself is located in the %systemroot%\System32 directory by default) on every critical machine that you administer.This utility provides additional encryption for password information, which provides an extra line of defense against would-be attackers.To run the utility, click Start | Run then type syskey and click OK. Defining a Password Policy Using Active Directory, you can create a policy to enforce consistent password standards across your entire organization.The options you can specify include: how often passwords must be changed, the number of unique passwords a user must use before being able to reuse one, and the complexity level of passwords that are acceptable on your network. Additionally, you can specify an account lockout policy that will prevent users from logging on after a specified number of incorrect logon attempts. In this section, we discuss the steps necessary to enforce password and account lockout policies on a Windows Server 2003 network.You can use the following steps to create a domain password policy. Creating User and Group Strategies • Chapter 11 433 301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 433 Create a domain password policy 1. From the Windows Server 2003 desktop, open Start | Administrative Tools | Active Directory Users and Computers. Right-click the domain that you want to set a pass- word policy for, and select Properties. 2. Select the Group Policy tab, followed by the Default Domain Policy, as shown in Figure 11.1. Click the Edit button. 3. Navigate to Computer Configuration | Windows Settings | Security Settings | Account Policies | Password Policy. You’ll see the screen shown in Figure 11.2. Using password policies, you can configure the following settings: ■ Enforce password history This option allows you to define the number of unique passwords that Windows will retain. 434 Chapter 11 • Creating User and Group Strategies Figure 11.1 The Group Policy Tab Figure 11.2 Configuring Password Policy Settings 301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 434 ■ Maximum password age This setting defines how frequently Windows will prompt your users to change their passwords. ■ Minimum password age This setting ensures that passwords cannot be changed until they are more than a certain number of days old. ■ Minimum password length This option dictates the shortest allowable length that a user’s password can be. Enabling this setting also prevents users from setting a blank password. ■ Password must meet complexity requirements This policy setting, when activated, forces any new passwords created on your network to meet the com- plexity requirements. ■ Store passwords using reversible encryption This option stores a copy of the user’s password within the Active Directory database using reversible (cleartext) encryption.This is required for certain message digest functions and authentication protocols to work properly.This policy is disabled by default and should be enabled only if you are certain that your environment requires it. 4. For each item that you want to configure, right-click the item and select Properties.In this case, we’re enforcing a password history of three passwords. In the screen shown in Figure 11.3, place a check mark next to Define this policy setting, and then enter the appropriate value. Modifying a Password Policy You can modify an existing Windows Server 2003 password policy by navigating to the policy sec- tion of the appropriate computer or domain and make the changes. New and modified password policies are only enforced when passwords are changed.Therefore, altering password policy does not place an immediate burden on users.Typically, users won’t notice the policy change until their pass- words expire and they are forced to set new ones. If you need to ensure that all passwords are forced Creating User and Group Strategies • Chapter 11 435 Figure 11.3 Defining the Password History Policy 301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 435 . Tools 1. Insert the Windows Server 2003 Server installation CD into your CD-ROM drive. 2. From the Windows Start menu, select Windows Explorer. 3. When Windows Explorer opens, expand the node representing. copied to the folder specified in the Destination Directory screen, and being installed on Windows Server 2003. Once com- pleted, the final screen of the wizard will appear, informing you that the tools. have the potential to be the weakest link in any network security implementation. Since passwords are the “keys to the kingdom” of any computer system, the database that Windows Server 2003 uses

Ngày đăng: 04/07/2014, 23:20