Planning; Security

Microsoft® Windows® 2000 Server and Microsoft Windows Server™ 2003, the foundation of Microsoft Business Solutions CRM, provide sophisticated standards-based network security. The Kerberos version 5 authentication protocol is integrated into Active Directory®, which provides you with powerful standards-based authentication. In addition, users are able to use a single user name and password logon combination for the network.

In the broadest sense, security involves planning and considering tradeoffs. For example, a computer can be locked in a vault and only accessible to one system administrator. This computer may be secure, but it is not very usable because it is not connected to any other computer. If your business users require access to the Internet and your corporate intranet, you need to consider how to make your network both secure and usable.

Most organizations plan for external attacks and construct firewalls, but many companies do not consider how to mitigate a security breach once a malicious user gets inside the firewall. Securing your environment will work well if you ensure that users are not required to perform too many procedures and steps to conduct business in a secure manner. Implementing security policies should be as easy as possible for the users; otherwise, people tend to find ways to avoid doing things securely.

On This Page

Physical Security
Employees
For the System Administrator
Securing the Windows Server Operating System
External Security - Firewall
ISA Server 2000
Virus Protection
Locking Down the Servers by Using Group Policy
Locking Down the Web Servers Using IIS Lockdown
Client Communication Security
Network Security Strategies
Publishing to the Internet Using ISA Server
Interaction with Other Network Services
Security Operations

Physical Security

Physical security represents the best place to start preventing malicious attacks. We highly recommend that you keep all computers that have sensitive data on their hard drives in a locked facility. Limit physical access to areas where highly sensitive information resides. The best security software can be circumvented by physical means. For example, if a hard disk drive is stolen, eventually the data on that drive will be stolen as well. Lock the door to the data center.

It is important to remember physical security considerations when you develop security policies and procedures. Consider the following physical security issues when developing a policy:

• Ensure that you lock server rooms and places where software and manuals are stored.

• Keep unauthorized users away from the power and reset switches on the server.

• Consider removing the floppy disk drive or rewritable CD drives from client workstations.

• Ensure that you have basic burglar alarms installed regardless of how sensitive your data is.

• Ensure that you store backups of critical data off-site and that software is stored in fireproof containers when not in use.

Employees

It is a good idea to limit administrative rights across all products and features. As a default, give employees only read access to given system functions, unless they require greater access to perform their jobs. Follow the principle of least privilege: give users only the minimum privileges required to access data and functionality. For example, avoid requiring administrative rights as a default to run features.

Disgruntled and former employees are a threat to network security. Keep the following personnel issues in mind when developing policy:

• Conduct pre-employment background investigations.

• Make sure that you disable and later delete all associated accounts and passwords when an employee leaves.

• Train your users in security awareness and reporting suspicious activity.

• Do not grant privileges automatically. If users do not need access to particular computers, computer rooms, or sets of files, ensure that they do not have access.

• Train supervisors to identify and respond to potential employee problems.

• Expect "revenge" from disgruntled employees and former employees.

• Monitor system usage for unusual activity.

• Make sure that your employees understand their roles in maintaining network security.

• Give a copy of your company policies to every employee.

• Do not allow users to install their own software.

For the System Administrator

We highly recommend that you keep up with the latest security fixes available from Microsoft. Hackers are very adept at combining small bugs to enable large intrusions into a network. You should ensure that each individual computer is secure first, and then add security updates and patches.

Many links are provided throughout this guide to help you find valuable information about following best practices. For example, there is a section about using strong passwords to defeat a hacker from using a software program designed to "guess" passwords. Several security experts have identified a good rule of thumb to keep in mind: "There really is someone out there who is trying to guess your password." This may be a disgruntled former employee, a corporate spy, or some other malicious user.

Another rule of thumb offered by security experts is: "A secure network is a well-administered network." Keeping up with security patches, implementing a smoothly functioning security policy, and getting people to think about security will go a long way to preventing a breach.

Complexity comprises another tradeoff for securing your network. The more complex your network is, the more difficult it will be to secure or fix it once an intruder has successfully gained access. You should document the network topography thoroughly, with a goal toward keeping it as simple as possible.

Security is primarily concerned with risk management. Because technology is not a panacea, security requires a combination of technology and policy. That is, there will never be a product that you can simply unpack, install on your network, and instantly achieve perfect security. Instead, security is a result of both technology and policy-that is, it is how the technology is used that ultimately determines whether your network is secure. Microsoft delivers the technology, but only you and your corporate management can determine the right policies for your company. Plan for security early in the implementation and deployment process. Understand what you want to protect and what you are willing to do to protect it. Finally, develop contingency plans for emergencies before they happen. Couple thorough planning with solid technology and you will have great security.

Another good piece of advice from security experts states that security is a journey, not a destination. This guide will help you begin that journey and implement best practices to develop a secure network and a secure work environment. For more information about general security, see the article by Scott Culp, "The Ten Immutable Laws of Security Administration," located at microsoft.com/technet/columns/security/essays/10salaws.asp. (The security guidelines mentioned in this topic are extracted from the "The Ten Immutable Laws of Security Administration" article.)

Securing the Windows Server Operating System

The information in this section has been extracted mainly from the Windows Server online Help. The concepts presented apply to both the Windows 2000 Server and Windows Server 2003 products. Windows Server 2003 offers the most complete set of security features of any of the Windows Server products. The Windows Server 2003 Help contains complete information about all security features and procedures.

In addition, Microsoft has published Microsoft Solution for Securing Windows 2000 Server, located on the Microsoft Web site at: https://www.microsoft.com/technet/security/prodtech/windows2000/SECWIN2K/DEFAULT.MSPX.

For Windows Server 2003, Microsoft has published the Windows Server 2003 Security Guide, located on the Microsoft Web site at: https://www.microsoft.com/technet/security/prodtech/windowsserver2003/W2003HG/SGCH00.mspx.

The primary features of the Windows server security model of most concern are authentication, access control, and single sign-on:

• Authentication represents the process by which the system validates a user's identity through their logon credentials. A user's name and password are compared against an authorized list. If the system detects a match, access is granted to the extent specified in the permissions list for that user.

• Access control limits user access to information or computing resources based on the users' identity and their membership in various predefined groups. Access control is typically used by system administrators for controlling user access to network resources such as servers, directories, and files and is typically implemented by granting permissions to users and groups for access to specific objects.

• Single sign-on allows a user to log on to the Windows domain once, using a single password, and authenticate to any computer in the Windows domain. Single sign-on enables administrators to implement secure password authentication across the Windows network, while providing end users with ease of access.

The following sections provide a more detailed description of these three key features for securing your environment.

Authentication

Authentication is a fundamental aspect of system security. It confirms the identity of any user trying to log on to a domain or access network resources. The weak link in any authentication system is the user's password.

Passwords provide the first line of defense against unauthorized access to your domain and local computers. Use the following password best practices where appropriate for your organization.

Password Protection

• Always require strong passwords. For more information, see the following "Strong Passwords" section.

• If passwords must be written down on a piece of paper, store the paper in a secure place and destroy it when it is no longer needed.

• Never share passwords with anyone.

• Use different passwords for all user accounts.

• Change passwords immediately if they may be compromised.

• Be careful about where passwords are saved on computers. Some dialog boxes, such as those for remote access and other telephone connections, present an option to save or remember a password. Selecting this option poses a potential security threat because the password is stored in the system registry.

Strong Passwords

The role that passwords play in securing an organization's network is often underestimated and overlooked. As mentioned, passwords provide the first line of defense against unauthorized access to your organization. The Windows Server 2003 family has a new feature that checks the complexity of the password for the Administrator account during the setup of the operating system. If the password is blank or does not meet complexity requirements, the Windows Setup dialog box appears warning you of the dangers of not using a strong password for the Administrator account. In a workgroup environment, you will not be able to access a computer over the network using an account with a blank password. Weak passwords provide attackers with easy access to your computers and network, while strong passwords are considerably harder to crack, even with the password-cracking software that is available today.

Password-cracking tools continue to improve, and the computers used to crack passwords are more powerful than ever. Password-cracking software uses one of three approaches: intelligent guessing, dictionary attacks, and brute-force automated attacks that try every possible combination of characters. Given enough time, the automated method can crack any password. However, strong passwords are much harder to crack than weak passwords. A secure computer has strong passwords for all user accounts.

A weak password:

• Is no password at all.

• Contains your user name, real name, or company name.

• Contains a complete dictionary word. For example, the word Password is a weak password.

A strong password:

• Is at least seven characters long.

• Does not contain your user name, real name, or company name.

• Does not contain a complete dictionary word.

• Is significantly different from previous passwords. Passwords that increment (Password1, Password2, Password3 ...) are not strong.

• Contains characters from each of the four groups listed in the following table.

  Group	Examples
  Uppercase letters	A, B, C, ...
  Lowercase letters	a, b, c, ...
  Numerals	0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
  Symbols found on the keyboard (all keyboard characters not defined as letters or numerals).	` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : " ; ' < > ? , . /

Examples of strong passwords are Pa$sw0rD and J*p2leO4>F.

A password can meet most of the criteria of a strong password but still be rather weak. For example, Hello2U! is a relatively weak password even though it meets most of the criteria for a strong password and also meets the complexity requirements of password policy. H!elZl2o is a strong password because the dictionary word is interspersed with symbols, numbers, and other letters. It is important to educate users about the benefits of using strong passwords and to teach them how to create passwords that are actually strong.

You can create passwords that contain characters from the extended ASCII character set. Using extended ASCII characters increases the number of characters that you can choose when you create a password. As a result, it might take more time for password-cracking software to crack passwords that contain these extended ASCII characters than it does to crack other passwords. Before using extended ASCII characters in your password, test them thoroughly to make sure that passwords containing extended ASCII characters are compatible with applications that your organization uses. Be especially cautious about using extended ASCII characters in passwords if your organization uses several different operating systems.

You can find extended ASCII characters in Character Map. Some extended ASCII characters should not be used in passwords. Do not use a character if a keystroke is not defined for it in the lower-right corner of the Character Map dialog box. For more information about how to use Character Map, see the Windows Server online Help.

Examples of passwords that contain characters from the extended ASCII character set are kUµ!¶0o and Wf©$0k#»g¤5ªrd.

You can implement a password policy that enforces password complexity requirements. For more information about this policy, see "Password must meet complexity requirements" in the Windows Server online Help.

Windows passwords can be up to 127 characters long. However, if you are on a network that also has computers running Windows 95 or Windows 98, consider using passwords that are not longer than 14 characters. Windows 95 and Windows 98 support passwords of up to 14 characters. If your password is longer, you might not be able to log on to your network from those computers.

Define Password Policy so That All User Accounts Are Protected with Strong Passwords

• Define the Enforce password history policy setting so that several previous passwords are remembered. With this policy setting, users cannot use the same password when their password expires.

• Define the Maximum password age policy setting so that passwords expire as often as necessary for your environment, typically, every 30 to 90 days.

• Define the Minimum password age policy setting so that passwords cannot be changed until they are more than a certain number of days old. This policy setting works in combination with the Enforce password history policy setting. If a minimum password age is defined, users cannot repeatedly change their passwords to get around the Enforce password history policy setting and then use their original passwords. Users must wait the specified number of days to change their passwords.

• Define a Minimum password length policy setting so that passwords must consist of at least a specified number of characters. Long passwords-seven or more characters-are usually stronger than short ones. With this policy setting, users cannot use blank passwords, and they need to create passwords that are a certain number of characters long.

• Enable the Password must meet complexity requirements policy setting. This policy setting checks all new passwords to ensure that they meet basic strong password requirements. For a full list of these requirements, see "Password must meet complexity requirements" in the Windows Server online Help.

Implement an Account Lockout Policy

Be cautious when you define account lockout policy. You should not apply account lockout policy haphazardly. Although you increase the probability of thwarting an unauthorized attack on your organization with account lockout policy, you can also unintentionally lock out authorized users, which can be costly for your organization.

If you decide to apply account lockout policy, set the Account lockout threshold policy setting to a high enough number that authorized users are not locked out of their user accounts simply because they mistype a password.

Authorized users can be locked out if they change their passwords on one computer, but not on another computer. The computer that is still using the old password will continuously attempt to authenticate the user with the old password, and it will eventually lock out the user account. This might be a costly consequence of defining account lockout policy, because the authorized users cannot access network resources until their accounts are restored. This issue does not exist for organizations that use only domain controllers that are members of Windows Server family.

For more information about account lockout policy, see "Account lockout policy overview" in the Windows Server online Help. For information about how to apply or modify account lockout policy, see "To apply or modify account lockout policy," also in the Windows Server online Help.

Access Control

A Windows network and its resources can be secured by considering what rights users, groups of users, and other computers have on the network. You can secure a computer or multiple computers by granting users or groups specific user rights. You can secure an object, such as a file or folder, through assigning permissions to allow users or groups to perform specific actions on that object. Key concepts that make up access control include:

• Permissions

• Ownership of objects

• Inheritance of permissions

• User rights

• Object auditing

Permissions

Permissions define the type of access granted to a user or group for an object or object property such as files, folders, and registry objects. For example, the Finance group can be granted Read and Write permissions for a file named Payroll.dat.

Permissions are applied to any secured objects such as files, Active Directory objects, or registry objects. Permissions can be granted to any user, group, or computer. It is a good practice to assign permissions to groups.

You can assign permissions for objects to:

• Groups, users, and special identities (pre-defined users or groups) in the domain.

• Groups and users in that domain and any trusted domains.

• Local groups and users on the computer where the object resides.

The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:

• Read

• Modify

• Change owner

• Delete

When you set up permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print from it.

If you need to change the permissions on an individual object, you can simply start the appropriate tool and change the properties for that object. For example, to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click Properties. On the Security tab, you can change permissions on the file.

Ownership of Objects

An owner is assigned to an object when that object is created. By default in Windows 2000 Server, the owner is the creator of the object. This has changed in Windows Server 2003 for objects created by members of the Administrators group. When a member of the Administrators group creates an object in Windows Server 2003, the Administrators group becomes the owner, rather than the individual account that created the object. This behavior can be changed through the Local Security Settings Microsoft Management Console (MMC) snap-in, using the setting "System objects: Default owner for objects created by members of the Administrators group." No matter what permissions are set on an object, the owner of the object can always change the permissions on an object. For more information, see "Ownership" in the Windows Server online Help.

Inheritance of Permissions

Inheritance allows administrators to easily assign and manage permissions. This feature automatically causes objects within a container to inherit all the inheritable permissions of that container. For example, the files within a folder, when created, inherit the permissions of the folder. Only permissions marked to be inherited will be inherited.

User Rights

User rights grant specific privileges and logon rights to users and groups in your computing environment. For information about user rights, see "User rights" in the Windows Server online Help.

Object Auditing

You can audit users' access to objects. You can then view these security-related events in the security log using the Event Viewer. For more information, see "Auditing" in the Windows Server online Help.

Access Control Best Practices

• Assign permissions to groups rather than to users. Because it is inefficient to maintain user accounts directly, assigning permissions on a user basis should be the exception.

• Deny permissions should be used for certain special cases. Use Deny permissions to exclude a subset of a group which has Allow permissions. Use Deny permissions to exclude one special permission when you have already granted full control to a user or group.

• Never deny the Everyone group access to an object. If you deny everyone permission to an object, that includes administrators. A better solution would be to remove the Everyone group, as long as you give other users, groups, or computers permissions to that object.

• Assign permissions to an object as high on the tree as possible and then apply inheritance to propagate the security settings through the tree. You can quickly and effectively apply access control settings to all children or a subtree of a parent object. By doing this, you gain the greatest breadth of effect with the least effort. The permission settings you establish should be adequate for the majority of users, groups, and computers.

• Explicit permissions can sometimes override inherited permissions. Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry. Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.

• For permissions on Active Directory objects, make sure you understand the best practices specific to Active Directory objects. For more information, see "Best practices for assigning permissions on Active Directory objects" in the Windows Server 2003 online Help.

Single Sign-On

A key feature of Windows Server family authentication is its support of single sign-on. Single sign-on allows a user to log on to the Windows domain once, using a single password, and authenticate to any computer in the Windows domain without having to re-enter that password.

Single sign-on provides two main security benefits: For a user, the use of a single password or smart card reduces confusion and improves work efficiency. For administrators, the amount of administrative support required for domain users is reduced, because the administrator needs to manage only one account per user.

Authentication, including single sign-on, is implemented as a two-part process: interactive logon and network authentication. Successful user authentication depends on both of these processes. See the Windows Server online Help for more information about how to configure the Windows single sign-on feature.

External Security - Firewall

A firewall is a piece of hardware or software that prevents data packets from either entering or leaving a specified network. To control the flow of traffic, numbered ports corresponding to network protocols, are either opened or closed on the firewall to allow or deny data packets. The firewall looks at several pieces of information in each arriving or departing packet: the protocol through which the packet is being delivered, the destination or sender of the packet, the type of content contained in the packet, and the port number to which it is being sent. If the firewall is configured to accept the specified protocol through the targeted port, the packet is allowed through. Microsoft Small Business Server 2000 and Microsoft Windows Small Business Server 2003 Premium Edition both ship with Microsoft Internet Security and Acceleration (ISA) Server 2000 as its firewall solution.

ISA Server 2000

Microsoft ISA Server 2000 securely routes requests and responses between the Internet and client computers on the internal network.

ISA Server acts as the secure gateway to the Internet for clients on the local network. The ISA Server computer is transparent to the other parties in the communication path. The Internet user should not be able to tell that a firewall server is present, unless the user attempts to access a service or go to a site where the ISA Server computer denies access. The Internet server that is being accessed interprets the requests from the ISA Server computer as if the requests originated from the client application.

When you choose Internet Protocol (IP) fragment filtering, you enable the Web Proxy and Firewall services to filter packet fragments. By filtering packet fragments, all fragmented IP packets are dropped. A well-known "attack" involves sending fragmented packets and then reassembling them in such a way that may cause harm to the system.

ISA Server features an intrusion detection mechanism, which identifies the time when an attack is attempted against a network and performs a set of configured actions, or alerts, in case of an attack.

If Internet Information Services (IIS) is installed on the ISA Server computer, you must configure it to not use the ports that ISA Server uses for outgoing Web requests (by default, 8080) and for incoming Web requests (by default, 80). For example, you can change IIS to monitor port 81, and then configure the ISA Server computer to direct the incoming Web requests to port 81 on the local computer running IIS.

If there is a conflict between ports that ISA Server and IIS use, the setup program stops the IIS publishing service. You can then change IIS to monitor a different port, and then restart the IIS publishing service.

ISA Server Policies

You can define an ISA Server policy that dictates inbound and outbound access. Site and content rules specify which sites and content can be accessed. Protocol rules indicate whether a particular protocol is accessible for inbound and outbound communication.

You can create site and content rules, protocol rules, Web publishing rules, and IP packet filters. These policies determine how the ISA Server clients communicate with the Internet and what communication is permitted.

Virus Protection

A computer virus is an executable file that is designed to replicate itself, erase or corrupt data files and programs, and avoid detection. In fact, viruses are often rewritten and adjusted so that they cannot be detected. Viruses are often sent as e-mail attachments. Antivirus programs must be updated continuously to look for new and modified viruses. Viruses are the number one method of computer vandalism.

Antivirus software is specifically designed for the detection and prevention of virus programs. Because new virus programs are created all the time, many makers of antivirus products offer periodic updates of their software to customers. Microsoft strongly recommends that you use antivirus software in your environment.

Virus software is usually installed at each of these three places: user workstations, servers, and the network where e-mail comes in to (and in some cases, leaves) the organization. The Microsoft CRM-Exchange E-mail Router (the Router) works by intercepting e-mail as it enters the organization and posts an e-mail event to the Microsoft CRM server. If you have antivirus software installed at the client workstation and on the Microsoft Exchange 2000 servers or Microsoft Exchange Server 2003 servers that host mailboxes, but you do not have it on the Exchange servers that receive e-mail from the Internet, it is possible that the Router will receive a message infected with a virus and post it to Microsoft CRM before the message is received by the Exchange mailbox server and then detected and deleted.

This means that if your Exchange 2000 or Exchange 2003 organization has front-end Simple Mail Transfer Protocol (SMTP) servers, you should install virus protection software in front of the front-end SMTP server or on the front-end SMTP server itself. This way, as messages are received from the Internet, the virus protection software scans them before they enter the organization.

If your organization does not use SMTP front-end servers, but you have a virus scanning product that scans only the Exchange Information Stores for viruses, you should install a virus protection component that scans incoming SMTP e-mail. This way, messages will be scanned before they are sent to Microsoft CRM.

You need to communicate to users that at this point in time, a virus cannot do any damage to computer systems unless a user runs the virus. If a user receives a virus as an attachment in an e-mail message, for instance, the user can delete the virus without any harm to the e-mail server or the user's local computer.

Types of Viruses

Three main types of viruses infect computer systems: boot-sector viruses, file-infecting viruses, and Trojan horse programs.

Boot-Sector Viruses

When a computer starts, it scans the boot sector of the hard disk before loading the operating system or any other startup files. A boot-sector virus is designed to replace the information in the hard disk's boot sectors with its own code. When a computer is infected with a boot-sector virus, the virus' code is read into memory before anything else. After the virus is in memory, it can replicate itself onto any other disks that are in use in the infected computer.

File-Infecting Viruses

The most common type of virus, a file-infecting virus, attaches itself to an executable program file by adding its own code to the executable file. The virus code is usually added in such a way that it escapes detection. When the infected file is run, the virus can attach itself to other executable files. Files infected by this type of virus usually have a .com, .exe, or .sys file name extension.

Some file-infecting viruses are designed for specific programs. Program types that are often targeted are overlay (.ovl) files and dynamic-link library (.dll) files. Although these files are not run, executable files call them. The virus is transmitted when the call is made.

Damage to data occurs when the virus is triggered. A virus can be triggered when an infected file is run or when a particular environment setting, such as a specific system date, is met.

Trojan Horse Programs

A Trojan horse program is not a virus. The key distinction between a virus and a Trojan horse program is that a Trojan horse program does not replicate itself; it only destroys information on the hard disk. A Trojan horse program disguises itself as a legitimate program, such as a game or utility. But when run, it can destroy or scramble data.

Virus Prevention Best Practices

You can prevent the spread of a virus. Here are some tips to avoid infection:

• Install a virus protection solution that scans incoming messages from the Internet for viruses before the messages pass the Router. This will ensure that e-mails are scanned for known viruses before they are posted to Microsoft CRM.

• Know the source of the documents that you receive. If a person sends you a document or file, be sure you know whether you can trust him or her. Is this person someone you work with? Would this person send around files from untrustworthy sources?

• Talk to the person who created the document. If you are at all unsure whether the document is safe, contact the person who created the document.

• Use the Microsoft Office System macro virus protection. In the Microsoft Office System, the applications alert you if a document that you open contains macros. This feature allows you to either enable or disable the macros as you open the document.

• Use virus-scanning software to detect and remove macro viruses. Virus-scanning software can detect and often remove macro viruses from documents. Microsoft recommends the use of antivirus software that the International Computer Security Association (ICSA) certifies. You can view a current list of ICSA-certified antivirus products on the ICSA Web site (www.trusecure.com/).

For more information about viruses and computer security in general, refer to the following Microsoft Security Web sites:

• Microsoft Security & Privacy (https://www.microsoft.com/security/default.mspx)

• Security documentation on Microsoft TechNet (https://www.microsoft.com/technet/security/Default.mspx)

Locking Down the Servers by Using Group Policy

The goal of a security policy is to define the procedures for configuring and managing security in your environment. Group Policy in Windows 2000 and Windows Server 2003 can help you to implement technical recommendations in your security policy for all of the workstations and servers in your Active Directory domains. You can use Group Policy in conjunction with your Organizational Unit (OU) structure to define specific security settings for certain server roles.

If you use Group Policy to implement security settings, you can ensure that any changes made to a policy will apply to all servers using that policy, and that new servers will automatically obtain the new settings.

How Group Policy Is Applied

To use Group Policy safely and efficiently, it is very important to understand how it is applied. A user or computer object can be subject to multiple Group Policy objects (GPOs). These are applied sequentially, and the settings accumulate, except in the case of a conflict-where, by default, settings in later policies override those in earlier ones.

The first policy to apply is the local GPO. Every computer running Windows 2000 or Windows Server 2003 has a local GPO stored on it. By default, only nodes under Security Settings are configured. Settings in other parts of the namespace of the local GPO are neither enabled nor disabled. The local GPO is stored on each server in %systemroot%\System32\GroupPolicy.

After the local GPO, subsequent GPOs are applied at the site, domain, parent OU, and, finally, child OU levels. The following diagram shows how each policy is applied.

GPO application hierarchy

If multiple GPOs are defined at each level, an administrator will set the order in which they are applied.

The settings defined in a Group Policy will be applied to a user or computer if the Group Policy is applied to the user or computer's container and the settings appear in the Discretionary Access Control List (DACL) for the GPO with at least Apply Group Policy permission.

Note By default, the built-in group, Authenticated Users, has the Apply Group Policy permission. This group contains all domain users and computers.

Group Policy Structure

Group Policy configuration settings are stored in two locations:

• GPOs. Located in Active Directory.

• Security template files. Located in the local file system.

Changes made to the GPO are saved directly in Active Directory, while changes made to the security template files must be imported back into the GPO within Active Directory before the changes can be applied.

Windows 2000 Server comes with a number of security templates. You can apply the following templates in a low security environment:

• Basicwk.inf. For Windows 2000 Professional.

• Basicsv.inf. For Windows 2000 Server.

• Basicdc.inf. For Windows 2000-based domain controllers.

To implement higher security on Windows 2000-based computers, further templates are provided. These provide additional security settings to the basic templates:

• Securedc.inf and Hisecdc.inf. For domain controllers.

• Securews.inf and Hisecws.inf. For member servers and workstations.

In Windows Server 2003, the basic templates have been removed so that only the following relevant templates should be used:

• Securedc.inf and Hisecdc.inf. For domain controllers.

• Securews.inf and Hisecws.inf. For member servers and workstations.

These templates are considered incremental templates because the basic or secure templates must be applied before the incremental templates can be added. For this guide, we have created new security templates, using Hisecdc.inf and Hisecws.inf as the starting points. The aim is to create a very restrictive environment, which you can then selectively open to provide the functionality that you require, while still keeping security of premium importance.

Note It is important to test how any Group Policy changes will effect your Microsoft CRM environment before they are implemented in your production environment. This includes adding the security Group Policy templates listed previously.

Security Template Format

Template files are text-based files stored in the %systemroot%\security\templates folder. You can make changes to the template files from the Security Templates MMC snap-in or by using a text editor such as Notepad. It is recommended that you make any changes through the MMC snap-in because the code used is very cryptic. The following table shows how the policy sections map to sections of the template files.

Policy section	Template section
Account Policy	[System Access]
Audit Policy	[System Log] [Security Log] [Application Log]
User Rights	[Privilege Rights]
Security Options	[Registry Values]
Event Log	[Event Audit]
Restricted Groups	[Group Membership]
System Services	[Service General Setting]
Registry	[Registry Keys]
File System	[File Security]

Some sections within the security template file, such as [File Security] and [Registry Keys], contain specific access control lists (ACLs). These ACLs are text strings, defined by the Security Descriptor Definition Language (SDDL). For more information about editing security templates and about SDDL, see the MSDN Web site (msdn.microsoft.com).

Locking Down the Web Servers Using IIS Lockdown

IIS servers provide a great deal of functionality. However, to make your IIS servers as secure as possible, you should restrict this functionality to only that which is required. The easiest way to do this is with the IIS Lockdown tool. IIS Lockdown is a highly configurable utility that allows you to specify the nature of your Windows 2000 Web server. It will then remove any functionality that is not required for the particular Web server. You should, of course, test any changes thoroughly before implementing them in a production environment.

Windows Server 2003 and IIS 6.0 does not support or require IIS Lockdown. By default IIS 6.0 is not installed on Windows Server 2003. After it is installed, it is fully secured by default so that only static content is served. Any additional functionality must be configured by the administrator or the application that is being installed. Microsoft CRM will modify the settings it needs accordingly.

Note For Windows 2000 Server, the IIS Lockdown tool is available as part of the Security Toolkit and as a download from the Microsoft Security & Privacy Web site, located at: https://www.microsoft.com/downloads/details.aspx?FamilyID=dde9efc0-bb30-47eb-9a61-fd755d23cdec&DisplayLang=en.

Note The IIS Lockdown tool default configuration will need to be modified for Microsoft CRM. For more information, see the following "Install IIS Lockdown for use with Microsoft CRM" procedure.

Note There are known issues with running IIS Lockdown on Microsoft Small Business Server. For more information, see the Microsoft Knowledge Base article 311862, "How to Use The IIS Lockdown Tool with Small Business Server," located at support.microsoft.com/default.aspx?scid=kb;en-us;311862.

IIS Lockdown can perform many steps to help secure Web servers. These can include:

• Locking files.

• Disabling services and components.

• Installing URLScan.

• Removing unneeded Internet Server Application Programming Interface (ISAPI) DLL script mappings.

• Removing unneeded directories.

• Changing ACLs.

You can use IIS Lockdown to secure many types of IIS server roles. For each server, you should pick the most restrictive role that meets the needs of your Web server.

Install IIS Lockdown for use with Microsoft CRM

1. On the Welcome page, click Next.

2. On the End User License Agreement page, if you accept the agreement, click I accept and click Next.

3. On the Select Server Template page, select the Other (Server that does not match any of the listed roles) template, and click Next. If you are running IIS Lockdown on Exchange 2000 or Exchange 2003, use the supplied Exchange template.

4. On the Internet Services page, ensure that Web Service (HTTP) is selected. File Transfer service (FTP), E-mail service (SMTP) and News service (NNTP) should be shaded unless you have installed them. If you do not need these services, allow the IIS Lockdown tool to uninstall them. Do this by ensuring that their check boxes are cleared, and selecting the check box for Remove unselected services. Click Next.

5. On the Script Maps page, clear the check boxes for Active Server Pages and Index Server Web Interface; this will allow these services. Select the remaining mappings to ensure that they are blocked (unless you need them in your particular solution). Any selected script maps are disabled. Click Next.

6. On the Additional Security page, in Remove the selected virtual directories from this server section, clear the check box for Scripts, and ensure all the other options in this section are selected. Clear the check box for Writing to content directories, if you want to give anonymous users the ability to write into content directories. This is required for Microsoft FrontPage® Web Presence Providers (WPP) compliance (the page counter utility does this). Leave the check boxes for Running system utilities and Disable WebDAV selected. Click Next.

7. On the URLScan page, leave the Install URLScan filter on the server check box selected to install the URLScan filter (additional configuration will be required if this option is selected). Click Next.

8. Review the selected changes and click Next.

9. IIS Lockdown will report that it has finished and give you the option to view a report. Click Next.

10. Click Finish.

    Note The IIS Lockdown tool records configuration changes in the %systemroot%\System32\Inetsrv\Oblt-rep.log file. The tool records uninstall information in the %systemroot%\System32\Inetsrv\Oblt-log.log file. If you remove or modify the Oblt-log.log file, you can no longer undo changes that are made by the IIS Lockdown tool.

Configuring URLScan for Windows 2000 and Windows Server 2003

The previous procedure includes installing URLScan as a part of running IIS Lockdown. URLScan is an ISAPI filter that screens all incoming requests to an IIS Web server, and passes to the server only those requests that comply with a rule set. This can significantly improve the security of the server by helping ensure that the server sees only valid requests. In order for Microsoft CRM to function properly with URLScan, you must perform additional configuration after installation. In your environment there may be additional modifications required depending on the other applications your environment supports. All configuration of URLScan is done through the URLScan.ini file, which is located in the %systemroot%\System32\Inetsrv\URLScan folder. To configure URLScan, open this file in a text editor, such as Notepad, and make the appropriate changes. After you have updated the file, you will need to save it and restart IIS for the changes to take effect. For more information about the capabilities and configuration of URLScan, see "URLScan Security Tool" located at https://www.microsoft.com/technet/security/tools/urlscan.mspx.

Modify the URLScan.ini file

1. Open the URLScan.ini file in Notepad.

2. Scroll to the end of the file. At the bottom of the file you will find the section titled: [DenyUrlSequences] which appears as follows:

   [DenyUrlSequences]
   

.. ; Don't allow directory traversals ./ ; Don't allow trailing dot on a directory name \ ; Don't allow backslashes in URL : ; Don't allow alternate stream access % ; Don't allow escaping after normalization & ; Don't allow multiple CGI processes to run on a single request

3. Put a semicolon at the beginning of the line : \ ; Don't allow backslashes in URL

   The section now looks like this:

   [DenyUrlSequences]
   

.. ; Don't allow directory traversals ./ ; Don't allow trailing dot on a directory name ;\ ; Don't allow backslashes in URL : ; Don't allow alternate stream access % ; Don't allow escaping after normalization & ; Don't allow multiple CGI processes to run on a single request

4. Save and close the file.

5. Restart IIS.

   Note One way to quickly restart IIS is to run the IISRESET command at a command prompt.

Additional Security Recommendations

• Crystal Enterprise is automatically installed as part of the Microsoft CRM Server installation. A user called Administrator is also created with a blank password. This user has full permissions to Crystal Enterprise. This configuration is necessary for the installation of Crystal Enterprise to complete, but once the Microsoft CRM Server (and, therefore, Crystal Enterprise) is installed, you should change the password of this account, using CrystalAdmin.exe. For more information about how to perform this task, see Chapter 12, "Installing Microsoft CRM on Windows 2000."

• In machine.config and web.config you can determine whether debugging is enabled, and also whether detailed error messages are sent to the client. You should make sure that debugging is disabled on all production servers, and that a generic error message is sent to the client if a problem occurs. This avoids unnecessary information about the Web Server configuration being sent to the client.

• Make sure that the IIS Web root is installed on a non-system NTFS partition for file system-level security. A non-system partition is one other than the partition containing the operating system files. (For example, C:\Inetpub is on a typical system partition, where D:\Inetpub is not.)

• Make sure that the latest operating system and IIS service packs and updates are applied. Check the Microsoft Security & Privacy Web site (https://www.microsoft.com/security/default.mspx) for the latest details.

You can use the IISADMPWD virtual directory to reset Windows NT®, Windows 2000, and Windows Server 2003 passwords. It is designed primarily for intranet scenarios and is not installed as part of IIS 5.0 and IIS 6.0, but it is not removed when IIS 4.0 is upgraded to IIS 5.0 or IIS 6.0. It should be removed if you do not use an intranet or if you connect the server to the Web. For more information about this functionality, see the Microsoft Knowledge Base article Q184619, "How to Change Windows NT Account Passwords Using Internet Information Server (IIS) 4.0," located at support.microsoft.com/default.aspx?scid=kb;en-us;184619&sd=tech.

Client Communication Security

Microsoft Outlook® supports remote procedure call (RPC) encryption between the Exchange server and Microsoft CRM Sales for Outlook (the Outlook client). This simple security mechanism encrypts the network communications (RPCs) between the Exchange server and the Outlook client. This means that the message itself is not encrypted, so the Microsoft CRM server and Web client can access and read the content. But the network session between the client and server is encrypted, so a malicious user capturing network packets cannot view messages as they travel between client and server.

This type of encryption, known as RPC encryption, must be configured in the Outlook profile and is not configured by default.

Network Security Strategies

Because the design and deployment of an IP internetworking environment requires balancing private and public network concerns, the appropriately named "firewall" has become a key ingredient in safeguarding network integrity. A firewall is not a single component. The National Computer Security Association (NCSA) defines a firewall as "a system or combination of systems that enforces a boundary between two or more networks." Although different terms are used, that boundary is frequently known as a perimeter network. The perimeter network protects your intranet or enterprise local area network (LAN) from intrusion by controlling access from the Internet or other large networks.

Basic perimeter network

The previous figure shows a perimeter network bounded by firewalls placed between a private network and the Internet in order to secure the private network.

Organizations vary in their approach to using firewalls for providing security. IP packet filtering offers weak security, is cumbersome to manage, and is easily defeated. Application gateways are more secure than packet filters and easier to manage because they pertain only to a few specific applications, such as a particular e-mail system. Circuit gateways are most effective when the user of a network application is of greater concern than the data being passed by that application. The proxy server is a comprehensive security tool that includes an application gateway, safe access for anonymous users, and other services. The following provides some information about these different options

• IP packet filtering was the earliest implementation of firewall technology. Packet headers are examined for source and destination addresses, Transmission Control Protocol (TCP), and User Datagram Protocol (UDP) port numbers, and other information. Packet filtering is a limited technology that works best in clear security environments where, for example, everything outside the perimeter network is not trusted and everything inside is. In recent years, various vendors have improved on the packet filtering method by adding intelligent decision-making features to the packet-filtering core, thus creating a new form of packet filtering called stateful protocol inspection. You can configure packet filtering either 1) to accept specific types of packets and deny all others, or 2) to deny specific types of packets and accept all others.

• Application gateways are used when the actual content of an application is of greatest concern. That they are application-specific is both their strength and their limitation, because they do not adapt easily to changes in technology.

• Circuit gateways are tunnels built through a firewall connecting specific processes or systems on one side with specific processes or systems on the other. Circuit gateways are best employed in situations where the person using an application is potentially a greater risk than the information carried by the application. The circuit gateway differs from a packet filter in its ability to connect to an out-of-band application scheme that can add additional information.

• Proxy servers are comprehensive security tools, which include firewall and application gateway functionality, that manage Internet traffic to and from a LAN. Proxy servers also provide document caching and access control. A proxy server can improve performance by caching and directly supplying frequently requested data, such as a popular Web page. A proxy server can also filter and discard requests that the owner does not consider appropriate, such as requests for unauthorized access to proprietary files.

Take advantage of those firewall security features that can help you. Position a perimeter network in your network topology at a point where all traffic from outside the corporate network must pass through the perimeter maintained by the external firewall. You can fine-tune access control for the firewall to meet your needs and can configure firewalls to report all attempts at unauthorized access.

To minimize the number of ports that you need to open on the inner firewall, you can use an application layer firewall, such as ISA Server 2000. ISA Server allows you to position your SMTP server, Microsoft CRM server, and your Outlook Web Access (OWA) front-end server behind the firewall. Using Server Publishing and Web Publishing rules, ISA Server will impersonate internal servers to the outside world without placing those servers in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet).

For more information about TCP/IP, see "Designing a TCP/IP Network," located at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/C4DFABB6-7A3D-432C-B3C3-F0A44C766158.mspx.

Network Security Scenarios

The level of network security that your organization requires will depend on several factors. It usually comes to a compromise between budget and the need to keep your corporate data safe. It is possible for a small company to provide a very complex security structure that will provide the highest level of network security possible. But the small company may not be able to afford that level of security. In this section, we will look at four scenarios and make recommendations in each that will provide varying levels of security at a relative cost.

No Firewall

If your organization has a connection to the Internet but no firewall, we highly recommend that you implement some measure of network security. There are simple network firewall appliances that provide a measure of security, which is enough to deter most would-be hackers.

One Simple Firewall

The minimum level of security recommended is a single firewall between the Internet and your corporate data, as shown in the following figure. This firewall may not provide any level of advanced security and should not be considered very secure. But it is better than nothing

Simple firewall

Hopefully your budget will allow for a more secure solution that will protect your corporate data. One such solution is ISA Server, as shown in the following figure. The increased cost of this additional server provides a great deal more security than your average consumer firewall that does only network address translation (NAT) and packet filtering.

ISA Server firewall

This single firewall solution is more secure than an entry level firewall appliance and provides Windows-specific security services.

One Existing Firewall

If your organization has an existing firewall that separates your intranet from the Internet, you may want to consider an additional firewall that provides multiple ways to configure internal resources to the Internet.

One such method is Web publishing, in which an ISA Server is deployed in front of an organization's Web server, or Microsoft CRM server, that is providing access to Internet users. With incoming Web requests, ISA Server can impersonate a Web server to the outside world, fulfilling client requests for Web content from its cache. ISA Server forwards requests to the Web server only when the requests cannot be served from its cache.

Another method is server publishing. ISA Server allows you to publish internal servers to the Internet without compromising the security of your internal network. You can configure Web publishing and server publishing rules that determine which requests should be sent to a server on your local network, providing an increased layer of security for your internal servers.

Existing firewall

For example, you can place your Microsoft Exchange server behind the ISA Server computer and create server publishing rules that allow the e-mail server to be published to the Internet. Incoming e-mail to the Exchange server is intercepted by the ISA Server computer, which gives the appearance of an e-mail server to clients. ISA Server can filter the traffic and forward it to the Exchange server. Your Exchange server is never exposed directly to external users and sits in its secure environment, maintaining access to other internal network services.

You can also place your Microsoft CRM server behind the ISA Server computer and create a Web publishing rule that allows Internet clients to access Microsoft CRM information through the ISA Server. Web requests destined for the Microsoft CRM server are intercepted by the ISA Server computer, which gives the appearance of the Microsoft CRM server. ISA examines the URL requests and forwards them to the Microsoft CRM server when applicable.

In this scenario you have some level of security with a traditional firewall. ISA is providing an extra level of security by publishing internal networking services on the Internet without allowing Internet hosts to directly access your corporate servers.

Two Existing Firewalls

The fourth scenario is where your organization has two firewalls in place with an established perimeter network, as shown in the following figure. Each one or more of these firewall servers is providing reverse proxy services so that Internet clients are not accessing servers on the intranet directly. Rather, one of the firewalls, ideally the internal firewall, is intercepting network requests for internal servers, inspecting those packets, and then forwarding them on behalf of the Internet host.

Two existing firewalls

This scenario is similar to the third scenario after the second firewall is added. The only difference is that the internal firewall that supports reverse proxy is not an ISA Server. In this scenario, we recommend that you work closely with the members of your organization that manage each firewall to define the server publishing rules so that they adhere to your security policy.

Extending Network Security on the Microsoft CRM Server

If you have one of the four previous scenarios, you can add another layer of security by creating an additional network segment between the Microsoft CRM server and the internal firewall. This is done by adding a second network interface card (NIC) to the Microsoft CRM server and to an Exchange 2000 or Exchange 2003 front-end SMTP server and segmenting the physical network connections so that the front-net is not on the same physical segment as the back-net. The Microsoft CRM server and the Exchange 2000 or Exchange 2003 front-end server straddle the front-net and back-net network segments, as shown in the following figure.

Multihome servers

Routing is not configured between the two NICs on the Microsoft CRM server or the Exchange front-end SMTP server. Microsoft CRM and Exchange 2000 or Exchange 2003 will initiate all network communication on the network segment that is appropriate for the destination host. This way, Internet hosts cannot get past the Microsoft CRM server or the Exchange front-end server to servers on the back-net, adding an additional level of security between Internet hosts and your back-end servers.

Publishing to the Internet Using ISA Server

ISA Server integrates a multilayer enterprise firewall to provide security and a scaleable, high-performance Web cache to accelerate network performance. ISA Server comes in two versions. ISA Server Standard Edition is a stand-alone server supporting a maximum of four processors. ISA Server Enterprise Edition is designed for larger-scale deployments, supporting server arrays, multilevel policy, and computers with any number of processors.

ISA Server combines both the firewall and cache functions of the "network edge" in a single product. It can be integrated in a single server or an array of servers or deployed in a modular fashion using separate computers for each component while sharing the administration and policy.

ISA Server will help protect your servers from being attacked. However, you also need to protect the data that is traveling to and from your servers. When Web browser clients on the Internet access Microsoft CRM using Hypertext Transfer Protocol (HTTP), the following occurs:

• An HTTP request is sent to the ISA Server from the Web browser. If permitted by the ISA publishing rules, the requests are passed to the Microsoft CRM servers.

• ISA Server establishes a new HTTP connection to the Microsoft CRM server with its own IP address as the source IP address.

• The HTTP requests are processed on the Microsoft CRM server. As part of the processing, the Microsoft CRM server authenticates the user and contacts against the global catalog server.

For more information, see "Microsoft Internet Security and Acceleration Server 2000 (ISA) Technical Overview," located at

https://www.microsoft.com/technet/prodtechnol/isa/2000/evaluate/isatecov.mspx.

ISA Server Planning

How ISA Server is implemented in your organization will depend on several factors, which include the physical and logical makeup of your organization as well as your organization's security requirements. Never before have so many security options been available. Part of the planning process is identifying the security components necessary to meet your organization's security requirements.

When using ISA Server as a firewall, you benefit from features and technologies, including:

• Multilayer firewall

• Stateful inspection

• Broad application support

• Integrated virtual private networking (VPN)

• System hardening

• Integrated intrusion detection

• Smart application filters

• Transparency for all clients

• Advanced authentication

• Secure publishing

• E-mail content screening

• Ability of inspecting Secure Sockets Layer (SSL) traffic

Caching can significantly improve network performance, reduce traffic and latency, and improve the user experience by providing faster access. It also saves valuable network bandwidth by locally storing and serving the most frequently requested content.

When using ISA Server for Web caching, you benefit from features and technologies, including:

• High-performance Web caching

• Scalability

• Distributed and hierarchical caching

• Active caching

• Scheduled content download

• Streaming media support

• Programmable cache control

The functions of ISA Server that you implement will depend on the services that you will provide to Internet users. Microsoft CRM allows you to publish Microsoft CRM information about the Internet for Microsoft CRM users. A minimum requirement for ISA Server is to secure your connection to the Internet so that unauthorized users do not have access to your corporate data. The services listed previously, along with protocol encryption, can help to secure your valuable corporate assets. The following table provides the information about determining services that your internal clients require.

To plan for these services, you must define four areas of ISA Server:

• Capacity planning guidelines

• ISA Server features

• Client requirements

• Interaction with other network services

  If you want to	Then use
  Improve the performance of Web requests for internal clients.	Web Proxy clients.
  Avoid deploying client software or configuring client computers.	SecureNAT clients. SecureNAT clients do not require any software or specific configuration.
  Improve Web performance in an environment with non-Microsoft operating systems.	SecureNAT clients. SecureNAT client requests are transparently passed to the Firewall service of the ISA Server and then to the caching service for caching.
  Publish servers that are located on your internal network.	SecureNAT clients. Internal servers can be published as SecureNAT clients, which eliminates the need for creating special configuration settings on the publishing server. It is not recommended to set up publishing servers as Firewall clients.
  Allow Internet access only for authenticated users.	Firewall clients. You can configure user-based access policy rules for Firewall clients.

For more information about planning ISA Server, see:

• Security with Internet Security and Acceleration Server 2000 white paper, located at https://www.microsoft.com/technet/isa/2000/operations/performance.mspx

• Caching with Internet Security and Acceleration Server 2000 white paper, located at https://www.microsoft.com/sql/default.mspx

• Microsoft Active Directory Storage and Replication Impact (on ISA) white paper, located at https://www.microsoft.com/technet/isa/2000/operations/performance.mspx

• Deployment of ISA Server at Microsoft white paper, located at https://www.microsoft.com/technet/isa/2000/operations/performance.mspx

• Comparing ISA Server and Internet Connection Firewall, located at https://www.microsoft.com/technet/isa/2000/operations/performance.mspx

Interaction with Other Network Services

Previously, you may have used Routing and Remote Access (RRAS) in Windows 2000 Server to make network services and computers available to remote clients. ISA Server provides the remote connectivity and extends RRAS by offering more extensive and flexible security features. ISA Server packet filtering replaces RRAS packet filtering. ISA Server uses the dial-up connections that you configured for RRAS.

Similarly, you may have previously used the Internet Connection Sharing (ICS) or network address translation (NAT) features of Windows 2000 and Windows Server 2003 to access the Internet. ISA Server can be used instead of ICS or NAT, replacing and enhancing their functions in the organization. ISA Server provides the connectivity enabled by ICS or NAT and adds sophisticated security and caching features.

Security Operations

This section contains recommended security settings for the various servers involved in running Microsoft CRM. Several network/server environments are possible, ranging from a single Small Business Server running all Microsoft CRM components, to four separate servers running each Microsoft CRM component individually. For the purpose of this section, we are assuming that the roles are split over separate servers, because this allows us to secure each server role separately. However, if you combine the components over fewer servers, you will still be able to implement many of the suggestions in this section.

Security Patch Management

Operating systems and applications are often immensely complex. They can consist of millions of lines of code, written by many different programmers. It is essential that the software works reliably and does not compromise the security or stability of your IT environment. To minimize any problems, programs are tested thoroughly before release. However, attackers continually strive to find weaknesses in software and anticipating all attacks in the future is impossible.

For many organizations, patch management will form a part of their overall change and configuration management strategy. However, whatever the nature and size of your organization, it is vital to have a good patch management strategy, even if you do not yet have effective change and configuration management in place. The vast majority of successful attacks against computer systems occur to those systems that are not fully up to date on security patches.

Security patches present a specific challenge to most organizations. Once a weakness has been exposed in software, attackers will generally spread information about it quickly throughout the community. When a weakness occurs in its software, Microsoft will strive to release a security patch as soon as possible. Until you deploy the patch, the security you depend upon and expect may be severely diminished.

In the Microsoft CRM environment, you will need to ensure that you are up to date on security patches across the four server roles that the Microsoft CRM server uses. To ease this task, you should consider using the technologies that Microsoft has made available to help you. These include:

• The Microsoft Security Notification Service. The Security Notification Service is an e-mail list that distributes notices whenever an update becomes available for a verified vulnerability. It serves as a valuable piece of a proactive security strategy and is available at the TechNet Product Security Notification Web site: https://www.microsoft.com/technet/security/bulletin/notify.mspx.

• The Security Bulletin Search Tool. This search tool is available at the HotFix & Security Bulletin Service Web site at: https://www.microsoft.com/technet/security/current.aspx. You can determine which updates you need based on your operating system, applications, and service packs you are currently running.

• Microsoft Baseline Security Analyzer (MBSA). This graphical user interface (GUI) tool is available at the Microsoft Baseline Security Analyzer Web site: https://www.microsoft.com/technet/security/tools/mbsahome.mspx. This tool works by comparing the current status of a computer against a list of updates maintained by Microsoft. MBSA also performs some basic security checks for password strength and expiration settings, guest account policies, and a number of other areas. MBSA also will look for vulnerabilities in IIS, Microsoft SQL Server™ 2000, Exchange 5.5, Exchange 2000, and Exchange Server 2003. It can therefore be an invaluable tool for anyone responsible for the security of Microsoft CRM.

• Microsoft Software Update Services (SUS). Formerly known as Windows Update Corporate Edition, this tool enables enterprises to host on local computers all critical updates and security rollup packages (SRPs) available on the public Windows Update site. This tool works with a new release of automatic update (AU) clients to form the basis for a powerful automatic download and install strategy. The new AU client set includes a client for Windows 2000 and Windows Server 2003 operating systems, and includes the ability to automatically install downloaded updates. For more information about Microsoft SUS, see https://www.microsoft.com/windows2000/windowsupdate/sus/default.asp.

• Microsoft Systems Management Server (SMS) Software Update Services Feature Pack. The SMS Software Update Services Feature Pack contains a number of tools aimed at easing the process of issuing software updates throughout the enterprise. The tools include a Security Update Inventory Tool, a Microsoft Office Inventory Tool for Updates, the Distribute Software Updates Wizard, and an SMS Web Reporting Tool with Web Reports Add-in for Software Updates. For more information about each tool, see https://www.microsoft.com/smserver/downloads/20/featurepacks/suspack/.

You can use a combination of these tools if you want, but it is very important that you ensure that all security issues are addressed as quickly as possible, while maintaining the stability of your environment.

Addressing Microsoft CRM-Specific Security Issues

Microsoft CRM-specific security patches are located on the CustomerSource Web site: https://www.microsoft.com/dynamics/customersource.mspx. You should regularly check the Web site to ensure that you are fully up to date on any security issues specifically affecting Microsoft CRM.

Addressing Client-Side Security Issues

Microsoft CRM users can ensure that their clients stay current on security patches for Windows 2000, Windows XP, and Windows Server 2003 by using the Windows Update tool provided with these systems. Also, if Microsoft Security Update Services is installed on the server, much of the update process can be automated internally in your organization. However, you should be aware that clients may have Microsoft SQL Server 2000 Desktop Engine (MSDE) installed on them. These clients require SQL Server patches to be installed, in addition to any Windows patches. The Microsoft Security Notification Service will send you details of all SQL Server security patches.

Modifying Security Settings

You can make a number of changes to your Microsoft CRM environment that will provide added security. If you already have a Windows 2000 or Windows Server 2003 domain structure, you may already have applied some of these settings, but they are mentioned here because they are appropriate for a Microsoft CRM implementation.

Most of the settings here can be applied at the domain, Organizational Unit (OU), or individual server levels. However, some can or should be set only at the domain level; this is indicated where applicable.

Domain Policy

Settings, such as password length, will change according to the overall security policy of your organization. It is, however, very important that you define these settings appropriately. Here are some suggestions for appropriate settings.

Password Policy

By default, a standard password policy is enforced for all servers in the domain. This table lists the settings for a standard password policy, as well as recommended minimums for your environment

Policy	Default setting (Windows 2000)	Default setting (Windows Server 2003)	Recommended minimum setting
Enforce password history	1 password remembered	24 passwords remembered	24 passwords remembered
Maximum password age	42 days	42 days	42 days
Minimum password age	0 days	1 day	2 days
Minimum password length	0 characters	7 characters	8 characters
Password must meet complexity requirements	Disabled	Enabled	Enabled
Store password using reversible encryption for all users in the domain	Disabled	Disabled	Disabled

Complexity requirements

When the Password must meet complexity requirements setting of Group Policy is enabled, it requires passwords to be at least six characters in length (although it is recommended that you set this to eight characters). It also requires that passwords contain characters from at least three of these classes:

• Uppercase letters: A, B, C,...Z

• Lowercase letters: a, b, c,...z

• Numbers: 0, 1, 2,...9

• Non-alphanumeric characters, such as punctuation symbols

  Note A password policy should not only be enforced on servers running Windows 2000 or Windows Server 2003, but also on any other devices requiring a password for authentication. Network devices, such as routers and switches, are very susceptible to attack if they are using simple passwords. Attackers may try to gain control of these network devices in order to bypass firewalls.

In addition to the measures you can take to enforce good use of passwords, you should also ensure that your users are well-educated about passwords. You should make sure that they understand never to give out or write down passwords, and that they should "lock" their workstations, even if they are away for only a moment. It is also important that users understand for themselves the difference between secure and non-secure passwords:

Non-secure passwords may contain any of the following:

• A user's name or e-mail alias

• The name of the user's child, parent, spouse, or friend

• Any word (such as table or computer) found in a dictionary

• A birth date

• A phone number

• A Social Security or other government identification number

• Any easily obtained personal information

Secure passwords should contain all of the following:

• Uppercase letters (A, B, C,...Z)

• Lowercase letters (a, b, c,...z)

• Numbers (0, 1, 2,...9)

• Special characters (such as punctuation)

• At least eight characters (more is better)

• No easily obtained personal information

• No words (such as "table" or "computer") found in a dictionary

Remember, even if you set minimum requirements for passwords, such as requiring special characters and uppercase and lowercase letters, users can still choose non-secure passwords or-worse yet-leave their passwords out in the open. Educating users about the importance of secure passwords is essential.

Administrator account

As part of your password policy, you should pay close attention to the local and domain Administrator accounts. These accounts have a high level of privilege over the servers and domain, and by default will not be locked out. Make sure that the password on your Administrator accounts are particularly complex. You should also consider renaming the standard local administrator account on each server and making the password different on each of your member servers. This reduces the risk of an attacker gaining access to one server and being able to gain access to others as a result.

Use the following procedures to rename accounts and reset passwords on domain controllers and servers.

Rename the Domain Administrator account and reset password on a domain controller

1. On the Start menu, point to Programs, and click Administrative Tools.

2. In the Administrative Tools dialog box, double-click Active Directory Users and Computers.

3. In the Active Directory Users and Computers dialog box, select Users, and navigate to the Administrator account.

4. Right-click the Administrator account and select Rename. Type the new name for the disguised Administrator account. Note this name somewhere physically secure so you do not lose the ability to log on as the Administrator.

5. If appropriate, right-click the renamed Administrator account, select Reset Password, and set the password to the one chosen for this Administrator account. Note this password and store it in a separate, physically secure location.

Rename the Local Administrator account and reset password on a server

1. On the Start menu, point to Programs, and click Administrative Tools.

2. In the Administrative Tools dialog box, double-click Computer Management.

3. In the Computer Management dialog box, expand System Tools, then Local Users and Groups. Select Users, and navigate to the Administrator account.

4. Right-click the Administrator account, and select Rename. Type the new name for the disguised Administrator account. Note this name somewhere physically secure so you do not lose the ability to log on as the Administrator of this server.

5. If appropriate, right-click the renamed Administrator account, select Reset Password, and set the password to the one chosen for this Administrator account. Note this password and store it in a separate physically secure location.

Account Lockout Policy

An effective account lockout policy will help prevent an attacker from successfully guessing the passwords of your accounts. This table lists the settings for a default account lockout policy, as well as recommended minimums for your environment.

Policy	Default setting (both Windows 2000 and Windows Server 2003)	Recommended minimum setting
Account Lockout Duration	Not defined	30 minutes
Account Lockout Threshold	0	5 invalid logon attempts
Reset account lockout after	Not defined	30 minutes

With the recommended minimum settings listed here, an account that has five invalid logon attempts within 30 minutes is locked out for 30 minutes (after which it will be reset back to 0 bad attempts and log on can be attempted again). A locked out account can be unlocked only by an administrator. To increase the level of security in your organization, you should consider increasing the account lockout duration and decreasing the account lockout threshold.

Note Password and account policy must be set at the domain level. If these policies are set on the OU level or anywhere else in Active Directory, they will affect local accounts and not domain accounts. It is possible to have only one domain account policy; for more information, see the Microsoft Knowledge Base (support.microsoft.com/) article Q255550, "Configuring Account Policies in Active Directory."

Other Security Settings

The settings in the following tables apply to either or both Windows 2000 and Windows Server 2003, and can be enforced locally on each server, or if you prefer, at the OU level. You should not enforce these settings at the domain level, because the domain will normally also contain client computers that do not require many of the settings contained here.

Note The settings defined in this section have been tested on a pure Microsoft CRM environment. However, it is vital that you thoroughly test these settings to make sure that they work in your environment before using them in a production setting.

Note If you want to enforce security settings at the OU level, you need to ensure that each of the servers supporting Microsoft CRM is in an appropriate OU to receive the settings. The location of servers in different OUs should be part of your Active Directory design process.

Audit Policy Settings

The Audit Policy settings apply to both Windows 2000 and Windows Server 2003. They are important to keep you aware of changes made to your Microsoft CRM environment. By enabling auditing, you ensure that the security log in Event Viewer will contain relevant information about which accounts were responsible for what changes. The settings should be applied to all servers in your Microsoft CRM environment.

Policy	Computer setting	Comments
Audit account logon events	Success, Failure	None.
Audit account management	Success, Failure	None.
Audit directory service access	Failure	Applies only to a domain controller. This generates a huge amount of events listing every successful access of Active Directory.
Audit logon events	Success, Failure	None.
Audit object access	Success, Failure	None.
Audit policy change	Success, Failure	Enabling Success audits (in addition to Failure) will greatly increase log entries and system accountability.
Audit privilege use	Failure	None.
Audit process tracking	No Auditing	This is enabled only in high-security or debugging scenarios.
Audit system events	Success, Failure	None.

Security Options Settings

The Security Options settings are different between Windows 2000 and Windows Server 2003, and have been provided in two separate tables. Many of the security options settings are not set to be restrictive in Windows 2000 server by default, whereas Windows Server 2003 is more secure by default. By understanding these settings, you can go a long way to reducing the risk of a successful attack on your environment.

The following options should be set on all Windows 2000 servers in your Microsoft CRM environment.

Option	Setting	Comments
Additional restrictions for anonymous connections	Do not allow enumeration of SAM accounts and shares	None.
Allow server operators to schedule tasks (domain controllers only)	Disabled	None.
Allow system to be shut down without having to log on	Disabled	None.
Allowed to eject removable NTFS media	Administrators	None.
Amount of idle time required before disconnecting session	15 minutes	None.
Audit the access of global system objects	Disabled	None.
Audit use of Backup and Restore privilege	Disabled	For more detailed auditing, this should be enabled, but be aware that many log entries will be created.
Automatically log off users when logon time expires	Enabled	None.
Automatically log off users when logon time expires (local)	Enabled	None.
Clear virtual memory page file when system shuts down	Enabled	On computers with a large amount of RAM (2 GB or more), this can significantly delay the shut down process by several minutes.
Digitally sign client communication (always)	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Digitally sign client communication (when possible)	Enabled	None.
Digitally sign server communication (always)	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Digitally sign server communication (when possible)	Enabled	None.
Disable CTRL+ALT+DEL requirement for logon	Disabled	None.
Do not display last user name in logon screen	Enabled	None.
LAN Manager Authentication Level	Send NTLM response only.	This setting assumes that all communicating computers can use NTLM authentication.
Message text for users attempting to log on	Not defined	None.
Message title for users attempting to log on	Not defined	None.
Number of previous logons to cache (in case domain controller is not available)	3 logons	None.
Prevent system maintenance of computer account password	Disabled	None.
Prevent users from installing printer drivers	Enabled	None.
Prompt user to change password before expiration	14 days	None.
Recovery Console: Allow automatic administrative logon	Disabled	None.
Recovery Console: Allow floppy copy and access to drives and folders	Disabled	None.
Rename administrator account	Not defined	None.
Rename guest account	Not defined	None.
Restrict CD-ROM drive access to locally logged-on user only	Enabled	None.
Restrict floppy access to locally logged-on user only	Enabled	None.
Secure channel: Digitally encrypt or sign secure channel data (always)	Enabled	You may need to set this to Not Defined if you have clients running versions of Windows prior to Windows 2000.
Secure channel: Digitally encrypt secure channel data (when possible)	Enabled	None.
Secure channel: Digitally sign secure channel data (when possible)	Enabled	None.
Secure channel: Require strong (Windows 2000 or later) session key	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Secure system partition (for RISC platforms only)	Not defined	None.
Send unencrypted password to connect to third-party SMB servers	Disabled	Server message block (SMB) is a protocol for sharing files, printers, serial ports, and communicationsabstractions between computers.
Shut down system immediately if unable to log security audits	Not defined	If you select Enabled and the security log is filled for any reason, the server will shut down and remain unusable until an administrator clears the log. You should ensure that you regularly back up and clear all event logs.
Smart card removal behavior	Lock Workstation	None.
Strengthen default permissions of global system objects (for example, Symbolic Links)	Enabled	None.
Unsigned driver installation behavior	Do not allow installation	None.
Unsigned non-driver installation behavior	Warn but allow installation	None.

The following options should be set on all Windows Server 2003 servers in your Microsoft CRM environment.

Option	Setting	Comments
Accounts: Administrator account status	Enabled	None.
Accounts: Guest account status	Disabled	None.
Accounts: Limit local account use of blank passwords to console logon only	Enabled	None.
Accounts: Rename administrator account	Administrator	None.
Accounts: Rename guest account	Guest	None.
Audit: Audit the access of global system objects	Disabled	None.
Audit: Audit the use of Backup and Restore privilege	Disabled	For more detailed auditing, this should be enabled, but be aware that many log entries will be created.
Audit: Shut down system immediately if unable to log security audits	Disabled	If you select Enabled and the security log is filled for any reason, the server will shut down and remain unusable until an administrator clears the log. You should ensure that you regularly back up and clear all event logs.
Devices: Allow undock without having to log on	Enabled	None.
Devices: Allowed to format and eject removable media	Administrators	On computers with a large amount of RAM (2 GB or more), this can significantly delay the shut down process by several minutes.
Devices: Prevent users from installing printer drivers	Enabled	None.
Devices: Restrict CD-ROM access to locally logged-on user only	Enabled	None.
Devices: Restrict floppy access to locally logged-on user only	Enabled	None.
Devices: Unsigned driver installation behavior	Warn but allow installation	None.
Domain controller: Allow server operators to schedule tasks	Disabled	None.
Domain controller: LDAP server signing requirements	Not defined	Lightweight Directory Access Protocol (LDAP) is a specification for a client-server protocol to retrieve and manage directory information.
Domain controller: Refuse machine account password changes	Not defined	None.
Domain member: Digitally encrypt or sign secure channel data (always)	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Domain member: Digitally encrypt secure channel data (when possible)	Enabled	None.
Domain member: Digitally sign secure channel data (when possible)	Enabled	None.
Domain member: Disable machine account password changes	Disabled	None.
Domain member: Maximum machine account password age	30 days	None.
Domain member: Require strong (Windows 2000 or later) session key	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Interactive logon: Do not display last user name	Disabled	None.
Interactive logon: Do not require CTRL+ALT+DEL	Disabled	None.
Interactive logon: Message text for users attempting to log on	Not defined	None.
Interactive logon: Message title for users attempting to log on	Not defined	None.
Interactive logon: Number of previous logons to cache (in case domain controller is not available)	3 logons	None.
Interactive logon: Prompt user to change password before expiration	14 days	None.
Interactive logon: Require Domain Controller authentication to unlock workstation	Disabled	None.
Interactive logon: Require smart card	Disabled	None.
Interactive logon: Smart card removal behavior	Lock Workstation	None.
Microsoft network client: Digitally sign communications (always)	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Microsoft network client: Digitally sign communications (if server agrees)	Enabled	None.
Microsoft network client: Send unencrypted password to third-party SMB servers	Disabled	Server message block (SMB) is a protocol for sharing files, printers, serial ports, and communications abstractions between computers.
Microsoft network server: Amount of idle time required before suspending session	15 minutes	None.
Microsoft network server: Digitally sign communications (always)	Enabled	This setting assumes that all communicating computers (including clients) are running Windows 2000 or later.
Microsoft network server: Digitally sign communications (if client agrees)	Enabled	None.
Microsoft network server: Disconnect clients when logon hours expire	Enabled	None.
Network access: Allow anonymous SID/Name translation	Disabled	None.
Network access: Do not allow anonymous enumeration of SAM accounts	Enabled	None.
Network access: Do not allow anonymous enumeration of SAM accounts and shares	Disabled	None.
Network access: Do not allow storage of credentials or .NET Passports for network authentication	Disabled	None.
Network access: Let Everyone permissions apply to anonymous users	Disabled	None.
Network access: Named Pipes that can be accessed anonymously	COMNAP, COMNODE, SQL\QUERY, SPOOLSS, EPMAPPER, LOCATOR, TrkWks, TrkSvr	None.
Network access: Remotely accessible registry paths	System\CurrentControlSet\ Control\ProductOptions, System\CurrentControlSet\ Control\Server Applications, Software\Microsoft\Windows NT\ CurrentVersion	None.
Network access: Remotely accessible registry paths and sub-paths	System\CurrentControlSet\ Control\Print\Printers, System\CurrentControlSet\ Services\Eventlog, Software\Microsoft\ OLAP Server, Software\Microsoft\Windows NT\ CurrentVersion\Print, Software\Microsoft\Windows NT\ CurrentVersion\Windows, System\CurrentControlSet\ Control\ContentIndex, System\CurrentControlSet\ Control\Terminal Server, System\CurrentControlSet\ Control\Terminal Server\UserConfig, System\CurrentControlSet\ Control\Terminal Server\ DefaultUserConfiguration, Software\Microsoft\Windows NT\CurrentVersion\Perflib, System\CurrentControlSet\ Services\SysmonLog	None.
Network access: Restrict anonymous access to Named Pipes and Shares	Enabled	None.
Network access: Shares that can be accessed anonymously	COMCFG,DFS$	None.
Network access: Sharing and security model for local accounts	Classic - local users authenticate as themselves	None.
Network security: Do not store LAN Manager hash value on next password change	Enabled	None.
Network security: Force logoff when logon hours expire	Enabled	None.
Network security: LAN Manager authentication level	Send NTLM response only	This setting assumes that all communicating computers can use NTLM authentication.
Network security: LDAP client signing requirements	Negotiate signing	None.
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients	No minimum	None.
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers	No minimum	None.
Recovery console: Allow automatic administrative logon	Disabled	None.
Recovery console: Allow floppy copy and access to all drives and all folders	Disabled	None.
Shutdown: Allow system to be shut down without having to log on	Disabled	None.
Shutdown: Clear virtual memory pagefile	Enabled	On computers with a large amount of RAM (2 GB or more), this can significantly delay the shut down process by several minutes.
System cryptography: Force strong key protection for user keys stored on the computer	Not defined	None.
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing	Disabled	None.
System objects: Default owner for objects created by members of the Administrators group	Administrators group	None.
System objects: Require case insensitivity for non-Windows subsystems	Enabled	None.
System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)	Enabled	None.
System settings: Optional subsystems	Posix	None.
System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies	Disabled	None.

User Rights Settings

Windows 2000 and Windows Server 2003 contain a number of user rights, which are sometimes less restrictive than they need to be for particular applications. You can use Group Policy to modify user rights on domain controllers or other servers running Microsoft CRM, Microsoft Exchange 2000, Microsoft Exchange Server 2003, and Microsoft SQL Server 2000. You should test carefully any changes you make to user rights to ensure that your environment still functions as it should.

Event Log Settings

These settings apply to both Windows 2000 and Windows Server 2003. By dramatically increasing the amount of auditing, you will significantly increase the number of events that can be recorded. The settings listed in the following table ensure that a large number of events can be written to the event log. However, they prevent the event log from being overwritten. This stops an attacker from making a change to the environment, then deliberately flooding the event logs to try and ensure that their change is overwritten. This also means that administration of the system must include regularly clearing and backing up the event logs.

Event log policy	Default settings	Recommended settings	Comments
Maximum application log size	512 kilobytes	80 MB	None.
Maximum security log size	512 kilobytes	80 MB	None.
Maximum system log size	512 kilobytes	80 MB	None.
Restrict guest access to application log	Disabled	Enabled	None.
Restrict guest access to security log	Disabled	Enabled	None.
Restrict guest access to system log	Disabled	Enabled	None.
Retain application log	Overwrite events as needed	Do not overwrite events	Be sure to regularly back up event logs before they fill up.
Retain security log	Overwrite events as needed	Do not overwrite events	Be sure to regularly back up event logs before they fill up.
Retain system log	Overwrite events as needed	Do not overwrite events	Be sure to regularly back up event logs before they fill up.

System Service Settings

In testing, a number of services have been found that are often set to Manual or Automatic and that, in an environment that is supporting only Microsoft CRM, you can safely disable. These settings are specified in the following table.

Server type	Services that can be disabled safely
Microsoft CRM server	Automatic Updates Clipbook DHCP Client Fax Service Internet Connection Sharing Kerberos Key Distribution Center NetMeeting Remote Desktop Sharing Network News Transport Protocol (NNTP) Print Spooler Telnet Wireless Configuration (Windows Server 2003 systems)
Exchange server	Automatic Updates Clipbook DHCP Client Fax Service Internet Connection Sharing Kerberos Key Distribution Center Microsoft Exchange IMAP4 Microsoft Exchange POP3 Microsoft Exchange Event Service NetMeeting Remote Desktop Sharing Network News Transport Protocol (NNTP) Print Spooler Telnet Wireless Configuration (Windows Server 2003 systems) World Wide Web Publishing Service
Domain controller	Automatic Updates Clipbook DHCP Client Fax Service Internet Connection Sharing NetMeeting Remote Desktop Sharing Routing and Remote Access Telnet Wireless Configuration (Windows Server 2003 systems)
SQL Server	Automatic Updates Clipbook DHCP Client Fax Service Internet Connection Sharing Intersite Messaging NetMeeting Remote Desktop Sharing Print Spooler Routing and Remote Access Telnet Wireless Configuration (Windows Server 2003 systems)

In your environment, some of these services are disabled already. You may also find other services that you can safely disable, but be sure to test thoroughly any changes that you make before introducing them to your production environment.

Other Security Recommendations

You should take a number of other measures to significantly increase the security of your Microsoft CRM environment. This section will discuss each of them in turn.

Microsoft CRM Administration Best Practices

By following a few simple rules in administration, you can dramatically increase the security of your Microsoft CRM environment:

• There is no need for Microsoft CRM users to have administrative privileges over the domain, so all Microsoft CRM user accounts should be restricted to Domain Users. Also, following the principle of least privilege, anyone using the Microsoft CRM system should have minimal rights. This starts at the domain level. A domain user account should be created and used to run Microsoft CRM. Domain Administrator accounts should never be used to run Microsoft CRM.

• Limit the number of Microsoft CRM Administrator and Operator roles to a few individuals who are responsible for rule changes. Other Microsoft CRM users that are Exchange or Active Directory administrators do not also need to be members of the Microsoft CRM users group.

• It is often common practice to reuse passwords across systems and domains. For example, an administrator responsible for two domains may create Domain Administrator accounts in each that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. In such a case, a compromise of a single account or computer can lead to a compromise of the entire domain. Passwords should never be reused in this way.

• It is also common practice to use Domain Administrator accounts as service accounts for common services such as backup systems. However, it is a security risk to use Domain Administrator accounts as service accounts, because the password must be stored, or cached, locally on every computer where the service resides. The password can easily be retrieved by anybody with administrative rights over the computer. In such a case, the compromise of one computer can lead to a compromise of the entire domain. Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible.

DNS Settings

Windows 2000 and Windows Server 2003 make heavy use of DNS, allowing computers to contact each other and services that they use. Microsoft CRM will not function properly in an environment with corrupt or non-functional DNS. You therefore need to take any steps that you can to make sure that DNS continues to function properly. These steps include:

• Allowing only secure updates of DNS.

• Securing the DNS cache against pollution.

• Removing root hints from DNS servers.

• Removing the cache file from internal servers.

The steps required to perform each of these tasks are located in Chapter 12, "Installing Microsoft CRM on Windows 2000."

Further SQL Server Settings

As Microsoft CRM relies intrinsically on SQL Server, it is important that you take measures to increase the security of your SQL Server database. The following steps will help you increase security:

• Make sure that the latest operating system and SQL Server service packs and updates are applied. Check the Microsoft Security & Privacy Web site (https://www.microsoft.com/security/default.mspx) for the latest details.

• Make sure that all SQL Server data and system files are installed on NTFS partitions for file system-level security. You should make the files accessible only to administrative or system-level users through NTFS permissions. This will safeguard against users accessing those files when the MSSQLSERVER service is not running.

• Use a low-privilege domain account or the LocalSystem (recommended) account for SQL Server service. This account should have minimal rights in the domain and should help contain (but not stop) an attack to the server in case of compromise. In other words, this account should have only local user-level permissions in the domain. In case that SQL Server is installed using a Domain Administrator account to run the services, a compromise of the SQL Server will lead to a compromise of the entire domain. If you need to change this setting, use SQL Server Enterprise Manager to make the change, because the access control lists (ACLs) on files, the registry, and user rights will be changed automatically.

• SQL Server is installed with two default databases named Northwind and pubs. Both databases are sample databases that are used for testing, training, and for general examples. They should not be deployed within a production system. Knowing that these databases are present can encourage an attacker to attempt exploits involving default settings and default configuration. If Northwind and pubs are present on your production SQL Server computer, you should remove them.

• BUILTIN\Administrators is by default a System Administrator on the SQL Server instance. In a large domain environment, that can be many individuals who are able to administer the Microsoft CRM SQL Server instance. There is no need for more than five individuals to have SYSADMIN permissions on the SQL Server, so you should remove the BUILTIN\Administrators group from the SYSADMIN role, create a custom role, and add select individuals into it for SQL Server SYSADMIN.

• SQL Server authenticates users with either Windows NT credentials or SQL Server credentials. This is known as Mixed Mode Security. You should use Integrated Security (Windows NT authentication only) for the highest security, which allows for the use of Windows NT credentials only, not SQL Server credentials.

• Auditing of the SQL Server system is disabled by default, so no conditions are audited. This makes intrusion detection difficult and aids attackers in covering their tracks. You should enable auditing of failed logins, at a minimum.

• Each SQL login is configured to use the master database as the default database. Although users should not have rights to the master database, as a best practice, you should change the default for every SQL login (except those with the SYSADMIN role) to use Organization _ name _MSCRM as the default database.

For current SQL Server security information, see https://www.microsoft.com/sql/technologies/security/default.mspx.

Additional Exchange Server Settings

Microsoft CRM uses an SMTP event sink to capture incoming mail, and it alters the subject line of outgoing mail. In addition, it routes SMTP mail to and from the Internet on behalf of Microsoft CRM. The following are some additional considerations for Exchange, some of which are specifically appropriate for Exchange in a Microsoft CRM environment:

• Protecting against virus attacks is an important part of any Exchange administrator's task. It is very common for antivirus measures to be taken for Exchange at the Information Store level. However, this will not protect the mail being received by Microsoft CRM. You therefore need to implement virus protection at the SMTP level, which will protect Microsoft CRM users from dangerous e-mails. More information about this can be found in Chapter 2, "The Planning Process."

• Exchange contains a rich series of mechanisms for providing granular administrative control of its infrastructure. In particular, you can use administrative groups to collect particular Exchange objects, such as servers, connectors, or policies, and then modify the ACLs on those administrative groups to ensure that only certain people can access them. You may, for example, want to allow Microsoft CRM administrators some control over those servers that directly affect their applications. By efficient use of administrative groups, you can ensure that you give Microsoft CRM administrators only the rights that they need to perform their jobs.

• If you want all mail addressed to a particular user to enter the Microsoft CRM system, you need to add the value CrmEmailEnabled to any of the Active Directory Extended Attributes for that user. In this way, you can protect against Microsoft CRM administrators abusing their power and feeding e-mail into the Microsoft CRM system that they should not. If you prevent Microsoft CRM administrators from modifying Active Directory settings themselves, they will then require the cooperation of an Active Directory administrator to make this change. Alternatively, in many cases, you may find it convenient to create a separate OU for Microsoft CRM users, and give Microsoft CRM administrators limited administrative rights over that OU. They can therefore make the change for any user in that OU, but not to any user outside the OU.

• Exchange 2000 and Exchange 2003 servers can be further locked down by running IIS Lockdown. Exactly how IIS Lockdown functions depends on the roles of the Exchange servers. For example, if any of your Exchange servers are Outlook Web Access (OWA) front-end servers, IIS Lockdown will ensure that the World Wide Web Publishing Service remains enabled. Otherwise, the service can be disabled.

• You should make sure that you adequately protect against unauthorized mail relay. Exchange 2000 and Exchange 2003 are configured to prevent relay by default. The exact settings you configure will depend on your message flow and configuration of your Internet Service Provider's mail server. However, the best way to approach this problem is to lock down your mail relay settings completely and then gradually open up your settings to allow e-mail to flow successfully.

Encrypting Network Traffic Flow

Microsoft CRM supports Web-based transactions through the platform Web server and a client running Internet Explorer. Unless Secure Sockets Layer (SSL) is enabled on the Web server, all transactions will traverse the network in clear text. To protect sensitive information on your Microsoft CRM server, you should enable SSL on the Web server by installing a supporting server certificate from a trusted Certificate Authority. You can require SSL for all clients through the Internet Information Services (IIS) Manager.

Communication between the back-end Microsoft CRM components, such as the platform, SQL Server computers, Exchange server, and domain controller, take place over clear text protocols, such as SMTP, LDAP, and SQL TCP/IP. For instance, all SQL queries from the platform are sent in readable, clear text across the network. In an untrusted network, or a network with specific encryption requirements, IP Security (IPSec) can be configured transparently between the back-end components to protect this traffic with encryption and strong authentication. IPSec protection takes place at the network and session layers, and, once setup correctly, will not affect Microsoft CRM functionality.