These days, it seems that everyone wants to jump on the Internet bandwagon. However, while just about everybody wants to put their business on the Internet, many smaller companies simply can’t afford to do it themselves. Setting up Web servers and e-mail servers can be very expensive. Not only do you have the expense of the necessary hardware and software, but there’s also the expense of having a high-speed Internet connection with static IP addresses and the cost of having a tech support staff there to make sure that everything’s working correctly. Smaller companies that are determined to get on the Web are constantly looking for a cheaper way of doing so.
You may have never thought about hosting Web servers and mail servers for smaller companies, but there’s a lot of money to be made in doing just that. While IIS has provided the ability to host multiple Web sites for quite some time, the problem has always been hosting mail services for other companies. Hosting mail services for multiple companies wasn’t impossible under Exchange 5.5, but it was a little tricky and could get expensive. Exchange 2000 makes it easy to host mail services for several companies. In this Daily Drill Down, I’ll discuss some of the issues you’ll face when offering mail hosting to other companies.
When you’re hosting multiple companies, security quickly becomes one of the biggest concerns. Part of the reason for this is that you have absolutely no idea with whom you’ll be dealing. If you limited access to your e-mail servers to the employees of your own company, you could do background checks on your employees before you hired them to make sure that none had ever been arrested for any sort of computer-related offense. There’s no guarantee, however, that the companies to which you’re selling e-mail services have trustworthy employees.
Not only do you need to keep unethical users from doing things to crash your servers, but you also need to take steps to keep them from being able to access your company’s data or the data for any other company that you’re hosting. After all, no company wants the content of their e-mail compromised. Years ago, I worked for a company that provided messaging services to other companies through a BBS system. A number of the companies that we did business with actually made us sign a confidentiality agreement stating that we couldn’t disclose the fact that they were using our services.
The first step in protecting a company’s privacy is to ensure that users of one company can’t see the users from another company. The problem with doing so is that the Exchange 2000 Global Address List is derived directly from Windows 2000 Active Directory. Therefore, by default, if users do a global address query, they will see every user from every company.
Active Directory planning
As you can see, you’ll have to put some serious work into planning your company’s Active Directory structure. You must design your Active Directory structure in such a way that it keeps users from one company from seeing users in other companies, including yours. You must also design Active Directory so that it is very flexible.
For example, what would happen if one of the companies that you’re hosting suddenly decided to add 1,000 user accounts? In the best scenario, you’ve had them sign a contract that would keep them from suddenly pulling a stunt like that. For the sake of argument though, suppose that their people did lunch with your people and hammered out a deal that would allow them to add 1,000 extra users for a given price. Typically, when such a deal happens, the network administrators are the last to know about it. What usually happens is that your boss will casually mention that you need to host 1,000 extra e-mail accounts by tomorrow. This statement is usually followed up with the words “that isn’t a problem, is it?” Well, if you’ve designed your Active Directory to allow for some scalability, then this doesn’t present a problem (aside from the obvious hardware concerns).
Another situation that typically happens is that one of the companies you’re hosting will request something really weird that none of the other hosted companies is doing. Assuming that the unusual request is something that Exchange 2000 is capable of, you can grant the request as long as you’ve properly structured your Active Directory. Not only does your Active Directory need to contain policies that keep companies from seeing each other, but it should also be organized so that each company’s data physically exists within a separate structure. By designing your hosted environment in this manner, you can grant the unusual request without having to worry about the change having an adverse effect on the other companies you’re hosting.
If you’re reading this description and thinking that this sounds like a tall order, you’re right. But a little hard work and planning now will save you some headaches down the road. There are actually several ways to implement the Active Directory requirements I have described. Each method has its own advantages and disadvantages.
The first way that you can get the job done is to host each company within a single domain. In this method, you could create a separate organizational unit for each hosted company. This is a good technique because it’s scalable, easy to implement, and doesn’t require a lot of extra hardware. The downside is that it can be tricky to get the security right. Remember that you’ll have to create a set of policies to keep users from being able to see the other companies. You’ll also have to keep in mind that anytime you create a new user, Windows 2000 automatically makes the user a member of a default set of groups. These groups make some domain resources, such as printers, available to the users. If you decide to implement this type of hosting environment, you’ll have to be very careful with group security.
Another method is to place each company into a different domain. This method is great for security. As long as no funky trust relationships exist, this model will limit users to accessing resources found in their own domain. This way, even if you did forget to set a policy or remove a group membership, the damage that users could do would be limited to their own company. The problem with this technique is that it requires a lot of extra hardware and software. Remember that each domain controller can only host a single domain. Because it’s best to have at least two domain controllers per domain, you’ll end up having to buy a lot of servers. In addition, each of these servers will require you to purchase a separate copy of Windows 2000 and the appropriate number of client access licenses. Depending on your Exchange Server configuration, you may end up having to buy a lot of extra copies of Exchange Server as well.
Another option is to host each company in a separate Active Directory forest. This technique provides each company with optimal privacy since the individual forests don’t even know that the other forests exist. Another advantage to using this method is that it eliminates having a single point of failure. Even if an entire Active Directory forest were to come crashing down, the cataclysm would affect only a single company. While you’re focusing on fixing the problem, you can rest assured that no other hosted companies are being affected by the problem. Like the multiple domain model, the multiple forest model can be very expensive to implement. The obvious reason is that you’ll end up having to buy a lot of extra hardware and software. Every time you host another company, you’ll have to buy even more. There are also several hidden costs. One of these costs is the administrative expense. Remember that since each hosted company exists in a semi-independent network, your administrative staff will have to manage each network separately. If you’re hosting more than a couple of companies, this just isn’t practical. Because the networks interact with each other, you’ll also have the expense of separate backup hardware for each network.
Obviously, all of these techniques will get the job done, but none of them is perfect. So you might be wondering how Microsoft recommends coping with the situation. Microsoft recommends hosting each company in a single domain within a single forest. It also recommends creating a separate organizational unit for each hosted company. Each organizational unit should contain the users, distribution lists, and security groups for the individual company. From here, you’ll have to take a few extra steps to ensure security. A typical situation allows users of each company to log in, but a few of these users may also have the ability to create additional objects, such as mailboxes and user accounts. You’ll have to set up some policies to make sure that it’s impossible for users with this ability to accidentally give permissions that are too high to any accounts that they create. Since the users with the ability to create user accounts have a higher level of permissions than the other users, you’ll have to be especially careful to set up an appropriate policy. Remember that you don’t want to grant these users administrative access, since doing so could expose other parts of your network. Instead, you’ll have to develop a custom security policy that was designed especially for that type of user. You should also consider implementing auditing to make sure that no users are doing anything they shouldn’t.
Key management services
Since this Daily Drill Down is all about security and mail hosting, I’d like to address the issue of key management services. Key management is a security feature that allows users to encrypt and digitally sign e-mail messages. At first, it may seem like a really good idea to use key management services to enhance the security associated with the companies you’re hosting. But if you’re using Microsoft’s recommended hosting method, using key management services is a really bad idea.
The reason for this lies in the way that key management works. The key management services work by sharing a public key that’s used in the encryption process. If you’re hosting each company within a single domain, however, the same public key would apply to each company. This presents a big security problem. Another issue that you would have to deal with is that if a company were to stop using your hosting services, any existing messages would still be encrypted. Because the company wouldn’t be able to access your key management server, it would find it virtually impossible to ever decrypt the messages.
In this Daily Drill Down, I explained that it can be very lucrative for larger companies to host mail and Web services for smaller companies. I then went on to discuss some of the security issues that you’ll face should your company decide to pursue this type of opportunity. In part two, I’ll discuss some of the other logistical issues that you’ll face in a shared hosting environment.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.