When you mention Exchange Server 2007 security, many administrators are familiar with the various built-in mechanisms used to harden Exchange. What's often overlooked is that it's just as important to use administrative policies to secure your Exchange organization.
Why you should secure Exchange 2007 using administrative policies
Administrative policies, which vary from company to company, dictate how to configure and run the Exchange organization. Although Microsoft doesn't have any official Exchange Server administrative policy best practices, here are some rules that can benefit most companies
Apply global security settings in an Exchange organization
One important step for securing an Exchange Server 2007 organization is to apply global security settings when possible. Exchange Server 2007 lets you manage security at a more granular level than was possible with previous versions of Exchange. Even so, using granular security settings is not necessarily a good thing.
It seems that the more granular a security policy is, the more difficult it is to manage. Using global security settings prevents an administrator from wondering what settings apply to a particular server or recipient. Setting policies globally is especially important for organizations that are subject to regulatory issues. In such cases, applying security policies at a high level ensures that no objects are missed as might have happened if security was applied at a lower level. It also ensures that the policies are being applied consistently across an entire organization.
Who should have an Exchange mailbox?
Although it seems that email is something everyone has, there are some accounts that should not be mail-enabled. The domain administrator account is a perfect example.
There are several reasons why you shouldn't mail-enable the domain administrator account. First, this account is a favorite target of hackers, spammers and malware authors. Having a mailbox link to the administrator account implies that someone is regularly logging into the domain administrator account. Unfortunately, administrative actions need to be performed at times and doing so requires administrative access.
Don't use the domain administrator account unless it's absolutely necessary. Instead, I recommend creating two separate user accounts for each user who needs administrative access to the system. One account should be granted administrative permissions; the other account should be a basic user account.
This accomplishes a few things. First, it allows administrators to perform day-to-day tasks, such as checking email without being logged on using administrator credentials. Additionally, if a user has to perform an administrative action, the action can be audited to a specific user account so that it's easy to find out who performed it. If the domain administrator account is used for all administrative actions, audit logs would show the actions. It also would be impossible to determine who was responsible for those actions.
In addition, I recommend that you don't associate mailboxes with any account the administrator must access. If a user was to open an infected email message accidentally and the attachment was able to execute, the malicious attachment would run with administrative credentials and would have free reign over the system. Using two separate user accounts for each administrator lets you link the administrator's mailbox to a non-administrative account.
Standardize server builds throughout your Exchange organization
I recommend standardizing server builds. Keep versions of Windows Server and Exchange Server consistent that you're running in your organization. When possible, you should not only run the same version consistently across the organization, but you also should run the same service pack level as well as the same set of patches, drivers and updates.
Consistent server builds ease the management process, and sometimes Microsoft will change the way that a particular setting behaves when it releases a security patch or a service pack. If you aren't running consistent server builds, you may apply the same security settings across all your Exchange servers, but not all servers will receive the same level of protection. This may lead to a false sense of security and will result in the administrative staff needlessly spending hours troubleshooting an issue that would not have existed if all versions were consistent
How to copy and transfer a Microsoft Outlook 2007 auto fill list
Switching PCs can often be as simple as installing Microsoft Windows and loading a few applications, but there also are some user-specific facets to the transfer. Anyone who has used roaming profiles in Microsoft Windows knows that they tend to prolong the logon and logoff processes. For this reason, I don't use them in my organization. I have, however, started copying a user's desktop icons and Internet Explorer (IE) favorites list from the profile to the new PC.
After replacing my own PC, I received an unusual request -- a user wanted her Microsoft Outlook 2007 auto fill list back. The Outlook auto fill list is Microsoft Outlook's email address cache.
Whenever you send an email message to someone, Outlook caches the address. The next time you need to send an email to that recipient, you only need to type the first couple of characters of the recipient's email address, and Outlook fills in the rest.
Auto fill list is stored as part of the user's profile in a nickname file (has an .NK2 extension). Once you locate the nickname file, it's fairly easy to transfer it to another PC.
The file's location varies depending on the version of Windows you are using. In Microsoft Windows Vista, it's located in the \Users\user name\Application Data\Microsoft\Outlook folder. Because this is a protected folder, you will need to gain access to the folder before you can make a copy of the nickname file.
The first step in gaining access to the folder is to make it visible. Here's how to do that:
1. Log on as an administrator and then open Windows Explorer.
2. Choose Folder and Search Options commands from the Options menu. Windows will display the Folder Options properties sheet.
3. Deselect the following check boxes:
Hide Extensions for Known File Types
Hide Protected Operating System Files (recommended)
4. You also must select the Show Hidden Files and Folders option, then click OK.
The necessary folders will now be visible, but you still won't have access to them. This is because Windows places an explicit denial on the Application Data folder; this denial overrides any type of permissions that have been granted.
To gain access to the nickname file, you must get rid of the explicit denial. To do so, navigate through Windows Explorer to C:\Users\user name\Application Data. Right-click on the Application Data folder and choose the Properties command from the menu.
When the Application Data properties sheet appears, go to the Security tab and click Advanced, followed by Edit. There is one access control list entry that is set as a specific denial (Figure 1). Select this entry and click Remove.
Figure 1. Eliminate the Microsoft Outlook Deny entry.
Click OK three times and you should be able to gain access to the Application Data folder. Navigate to the Microsoft\Outlook folder beneath the Application Data folder, and copy the .NK2 file to removable media.
Note: The name of the .NK2 file matches the name of Microsoft Outlook's profile. For machines with a single Outlook profile, the filename will be Outlook.nk2. For machines with multiple Outlook profiles, there will be a separate .NK2 file for each profile. Figure 2 shows an example of this type of configuration.
Figure 2. There is a separate .NK2 for each of the user's Outlook profiles.
Copy each of the .NK2 files to removable media. Log onto the new machine using the end user's account and create any necessary Outlook profiles. When you are done, log out and log back in as an administrator.
Use the technique that I demonstrated earlier to gain access to the user's Application Data directory. Finally, find the \Users\user name\Application Data\Microsoft\Outlook folder and replace any existing .NK2 files with the ones you copied from the other machine.
Please let me know if this post was helpful.
No comments:
Post a Comment