Thwarting Party Crashers

Nobody likes uninvited guests—and when they invade your online conferences, the consequences can be deadly. Exchange Conferencing Server can help you keep the riff-raff at bay.

• By Roberta Bragg
• November 01, 2001

“Hey Joey. Whaddya doin’ bringin’ her here?” Fat Al said around a soggy cigar stub. The stogie pushed out one side of his mouth, a fleck of spittle flew out the other. Hot ash fell on the table in front of him. The rest of the room was silent. The air was crowded with thick blue smoke and within it moved the souls of past sinners. My arms, which had been casually, if possessively, draped about Joey the Mutts’ broad neck and shoulders, tingled with anticipation. It was time...

Fat Al didn’t even have time to brush the ash off the table. White light erupted from the side of my purse and traveled through the hole in his head. While the rest of the cowboys were hittin’ the floor I turned and downed Joey with the second shot... Then I was outta’ there.
—Excerpted, with permission, from Fat Mamma and the Ting Tang Bang Gang by Ashley Commons

Bringing uninvited guests to the party can be deadly to you and your host. The message is clear—don’t. But what if you’re the host? What if your get—together is via online conferencing? Yeah, you can hide your cigar-smoking habits and not offend me with the fumes, but how do you keep unwanted guests out? If you’re considering adopting conferencing technology or are currently hosting unprotected meetings then I’ve got news for you—Microsoft Exchange Conferencing Server allows you to control not only the guest list, but the attendees, and to encrypt all data. If you need to have a confidential meeting with members of your gang, it’s not as difficult as it seems. Like Fat Mamma, you just have to have the right moves.

The first step is to determine whether you want to extend these meetings to include access from the Internet or stick to domain users. I’ll address local access for this go-a-round. Ultimately, if enough of you would like, I’ll cover securing Conferencing Server meetings with Internet-based attendees at another time.

Next, decide what type of security you want. There are four possibilities.

• Public. Anonymous access. No security, no encryption. Anyone can come.
• Restricted attendance. You can configure Conferencing Server to restrict attendance to authenticated users or invitees. But be careful: if I can authenticate and know the account name and password of an invitee, I can get into the meeting.
• Password-protected attendance. You can also limit attendance and apply a little more security by requiring the entry of a meeting password to get into the conference when you fill out the invitation form (Figure 1). Beware. This password is stored in clear text in your local Outlook calendar and mailbox. Don’t forget to check the “hidden” box to prevent exposing the password.
• Secured. Finally, if what you desire is out and out confidentiality—that is, encryption of the entire conversation and an authentication scheme that isn’t so easily compromised—then you want a “private” or secured conference. Data (not voice or audio) in a secured conference will be encrypted. This fourth choice is the toughest to implement but the most secure, and it’s where I’ll focus the rest of this article.

Figure 1. The Invitation form allows you to require the entry of a password for attendance. (Click image to view larger version.)

Scheduling conferences isn’t hard, and the first three choices above are easy and straightforward to implement. Establishing that first secured conference may, however, give you some headaches, especially if you’re not comfortable with all of the following: Exchange 2000, certificate services, SSL, Web server authentication, Outlook 2000, NetMeeting, H.323, T 120 and Conferencing Server. A lack of knowledge in one of these topics may not be a large impediment to your success, but jumping in without knowing about several of them is like jumping out of an airplane and not knowing where to find the parachute cord. As you frantically attempt to find it, it probably occurs to you that free-falling would still have been exciting even if you had asked some questions first.

Don’t be put off by that long list of technologies. Remember that few infrastructure projects now require singular knowledge. Multidisciplinary scenarios are par for the course. You don’t have to know all there is to know about everything in the mix, but you have to know something. I’ll supply the crib notes to get you started here, but if you’re clueless about many of these technologies expect to do some research.

Before starting, make sure you have Service Pack 1 installed on both your Win2K server and your Exchange Conferencing Server, and that you’ve got current versions of NetMeeting, Outlook, and IE (4.0 or above). Ready? Let’s get started!

Step One: Conferencing Server Basics
Make sure your Conferencing Server is set up and running smoothly If you’re new to Conferencing Server and experiencing difficulties scheduling regular meetings, remember that—in order to use Outlook—it’s necessary to make a registry entry to the profile of the user who will be scheduling the meetings. Use regedt32.exe on the client computer (or create your own batch file to automate this step) and navigate to HKEY_LOCAL_ USER_Software_Microsoft_Office_9.0_Outlook. Add the key, ExchangeConferencing.

You’ll know you’ve got it right if, when scheduling a conference, the Invitation form (Figure 1) allows you to choose “Microsoft Exchange Conferencing.” This selection modifies the conference entry form so you can choose conference types via the check box “Allow external users.”

Step Two: Public Key Infrastructure
In order to secure a conference you must provide a certificate for your Conferencing Server and client authentication certificates for all the users you wish to attend. You should do this as part of establishing a Public Key Infrastructure (PKI) in your enterprise. Here are rules and the steps specifically needed to use certificates for private conferencing.

• A Win2K Enterprise CA must be present in the same forest as the Conferencing Server. If you already have an established PKI using Win2K certificate services, you may be halfway there.
• A copy of the CA certificate must be present in the trusted root certificate store of each server and client system that will be part of the private conference. All involved servers should be in the forest and will receive a copy of this certificate by default. If you’re establishing your PKI, remember to allow time for the server certificate to be distributed. Client systems joined in a forest domain will also receive this certificate and add it to their list of trusted roots. If you want to involve clients that aren’t part of your forest, you must provide a copy of this certificate and the clients must be able to incorporate it into their trusted certificate store.
• The IIS server that hosts the conferencing server pages must have a server certificate installed.
• The virtual conferencing site must require SSL.
• The virtual conferencing site must require client authentication.
• Each client must have a client authentication certificate that’s acceptable to the SSL server. If clients are part of your forest, they can request certificates from the CA through the Web interface or from their certificates snap-in. If you wish to have private conversations with clients from other realms, you must either provide them with Active Directory accounts and certificates or accept their certificates, map them to user accounts and establish trust of their CA.

Let’s look at some of these steps in more detail.

Setting Up SSL on the Server

While documentation vaguely mentions that the Conferencing Server must have a server certificate, that’s not exactly what it means. If you think about how conferencing is accomplished (via connection to a virtual Web site on IIS), and you know something about secure Web servers, you’ll understand that it’s the Web server that needs the certificate to allow SSL (secure sockets layer) connections. In our case, however, we want to authenticate the clients as well, but don’t want to use a public CA. We want to use corporate credentials to validate the identity of attendees at our private conferences and to manage the encryption keys used during the conversation. Here’s how:

Install a Server Certificate

1. Open the Internet Services Manager console and navigate to the Web site that hosts the virtual directory for Conferencing Server.
2. Right-click and open Properties.
3. Click the Directory Security tab
4. In the Secure Communications area, click “Server Certificate.” The wizard launches, which will install the server certificate.
5. Click Next.
6. Select “Create a new certificate” and click Next.
7. Select “Send request immediately to an online Certification Authority” and click Next.
8. Type a friendly name for the certificate.
9. Enter the following information as it exists on the CA: organization name, organization unit.
10. Enter a common name. This should be a valid DNS name if Internet attendees will be invited. On the local network, a NetBIOS name will suffice. Click Next.
11. Enter country, state or province, city or locality and click Next.
12. Select Certification Authority. You should see the name of your CA in the drop-down list. Click Next.
13. Review the request and click Next to submit. The wizard should show successful completion and a certificate installed on the server.

Require That SSL be Used

1. You can use Internet Services Manager to require SSL for your entire site or only for some directories. To require SSL for all directories, open the Properties page of the Web site. To require SSL on the private conferencing location only, navigate to the ConferencingPrivate directory and open its Properties page.
2. On the Directory Security tab in the Secure Communications area, click the Edit button.
3. Check the box “Require Secure Channel SSL.”
4. In the Client certificates area, check “Require client certificates.”
5. Click OK twice to close the Properties page.

Configure the Conferencing Private Virtual Directory to Insist on Client Authentication

1. In Internet Services Manager, navigate to the properties page of the ConferencingPrivate virtual directory.
2. Click the Directory Security Properties tab.
3. In the “Anonymous access and authentication control” area, click Edit.
4. Clear the “Integrated Windows authentication” option. Make sure “Basic authentication’ is still checked. (By allowing basic authentication here, you’ve set the stage to allow all clients, not just those whose browsers can perform Windows authentication, to authenticate and join the conference. They’ll still perform the desired encryption.)
5. Click OK twice to close the Properties page.

Configuring the Conferencing Server’s Default URL for Clients

You also want to use a secure connection by default for Conferencing Server:

1. Open Start_Programs_Exchange Server_Conferencing Management Service console.
2. Click the site of the Conferencing Server.
3. In the details pane, right-click the server and select Properties (Figure 2).
4. Click the Conference Settings tab.
5. Change the default access URL from http to https.
6. Click OK to close the Properties page.
7. Open the Services console.
8. Stop and start the Conference Management Service for the conferencing site.

Figure 2. The Conference Settings tab allows you to permit the scheduler to make conference changes, such as end time and resource.

Configuring Clients for Private Conferencing

Each user you wish to invite to a private conference must have an authentication certificate. This means that every user must request a certificate. The good news is that many certificate types are multipurpose. That is, if you’ve established your PKI and are using it for EFS or encrypted e-mail, users may already have the appropriate certificate. If you’re just establishing your PKI, here’s how to add an appropriate certificate, the “User” certificate, to the clients’ personal store. The “User” certificate (based on a standard template) is a multipurpose certificate that can be used for EFS, client authentication, digital signature, secure e-mail and key encipherment (encryption). A certificate may be obtained by using the Web interface or the Certificates console. I’ve discussed the Web interface in a previous column, so I’ll use the Certificates console approach here.

1. The user should be logged on. You can’t request a certificate as you and then give the certificate to another user.
2. If a Certificates console hasn’t been built for this user, open a new MMC (Start, Run, MMC, Enter).
3. From the console menu select “Add/remove snap-in.” Add the Certificates snap-in, choosing the “My user account” management option.
4. Expand the Certificates current user container and right-click on the Personal folder.
5. Select All Tasks, then select Request New Certificate and launch the Certificate Request Wizard.
6. Click Next.
7. Select the “User” certificate template and click Next.
8. Enter a friendly name. This information will be used to identify the certificate when the client joins the session.
9. Click Next, then Finish.
10. Click Install Certificate.
11. Verify that the certificate is in the Certificates_Personal_Certificates folder.
12. Close the console.

Step Three: Final Set Up
A few final adjustments on the Conferencing Server will ensure that your private conferences remain private and run smoothly the first time.

• Designate someone, or some group, as the secure conference scheduler. Conferencing Server allows you to restrict who can schedule a conference or assume that this is a service anyone should be able to command. I’d argue on the side of restrictions, especially for private conferences.
• Restrict attendees to invitees and log their activity.
• (Optional) Restrict users by IP address range.
• Provide for interactive logon.

Designating Conference Schedulers

Restricting conference scheduling abilities to a few users helps conserve server resources and makes sure they’re available when needed.

1. Create an AD global group and add user accounts of your designated schedulers.
2. Create a local group on the Conferencing Server and add the global group to its membership.
3. Logon to the Conferencing Server using the account designated as the Data Conferencing resource account during setup. Logging on as this account will establish a Win2K profile for the account.
4. Open Outlook. This will lead you through the steps to create a mailbox profile. This will allow you to assign permissions to its mailbox resource. Schedulers invite the resource, of course, when you schedule the conference. In order to do so they must have permission.
5. Right-click the Calendar object and then click Properties.
6. Click the Permissions tab.
7. Use the Add button to add the local scheduling group and then assign it Author permissions.
8. Verify that anonymous users are not given permissions here.
9. Click OK to close all windows.
10. Close Outlook and logoff.
11. Stop and start the Microsoft Exchange Conferencing Service.

Restricting Attendees to Invitees and Logging Their Activity

In order to prevent unauthorized, but authenticable, users from crashing your private conferences, you must restrict attendees to invitees. To do so:

1. Open Exchange Server_Conferencing console.
2. Right-click on the Exchange Conferencing\site conferencing site and select Properties.
3. Click the Conference Settings tab.
4. Uncheck the “Change conference resource” box to prevent schedulers from changing resources during a conference. Should they switch from a pure data conferencing resource to one that allows video and audio, the privacy of the meeting content is at risk.
5. Check or uncheck the “Change conference time” to allow or deny the scheduler the ability to extend the conference time.
6. Click the Logging Page.
7. Select the items to log. I recommend you log them all. Items that can be logged are listed in Table 1. Logging only records the listed events. It does not log conversations.

Restricting Users by IP Address Range

If all users who will use a particular Conferencing Server are within similar address ranges, you can restrict connections to the server to those addresses. This is called restricting visibility.

1. 1. Open Properties page of the Data Conferencing Server.
2. 2. Select the Visibility page.
3. 3. Click the Add button.
4. 4. Enter the network address and subnet mask for the subnet of those allowed to connect to the Conferencing Server.
5. 5. Click the General page.
6. 6. Select the option to which these restrictions will apply by checking the box “Restrict Visibilty” for either local sites, client and T 120 MCU server connections or from the Internet.

New Web Tool Service Pack 1 for Exchange Conferencing Server (don't confuse this with Exchange 2000 SP1-that's a different product) adds a new Web-scheduling tool. This can be used to schedule a conference even if users aren't using Microsoft Outlook. It can also be used to list conferences and join a conference. To use the tool, apply the service pack and navigate to https://shazam/ConferencingPrivate/default.asp?select=0 as shown in this figure: The Web Conferencing Scheduler, included with Exchange Conferencing Server's Service Pack 1, allows you to set up a conference with users who aren't using Microsoft Outlook. (Click image to view larger version.) The Web Conferencing Scheduler, included with Exchange Conferencing Server's Service Pack 1, allows you to set up a conference with users who aren't using Microsoft Outlook.

Providing for Interactive Logon

Now that you’ve configured Conferencing Server to require authenticated logon and to prevent party crashers, you must allow users to interactively logon. As you may recall, users logging onto an IIS Web server require the ability to “logon locally.” In fact, if you inspect group policy, you’ll see that the IIS user account IUSR_ computername has this privilege by default. To allow your conferencing attendees this right, you must assign it.

1. Create a global group. (Alternatively, if you allow all users to conference, you could use the Domain Users group.)
2. Add users you wish to allow to conference. (Domain Users already includes all users in the domain.)
3. Create a local group (or use Users) on the Conferencing Server. I’ve called mine “Conferencing Users.”
4. Place the global group in the local group.
5. Open the group policy for the OU in which the Conferencing Server resides. Ideally this OU will contain only Conferencing Servers.
6. Navigate to Windows Settings_ Machine Settings_Security Settings.
7. Double-click Local Policies_User Rights_Logon Locally.
8. Use the Add button to add your local group and give it this right.
9. Click OK to close the right.
10. Close the Domain Security Policy.
11. Use the secedit_refreshpolicy machine_policy command at the command prompt to kick off policy replication.

Step Four: Scheduling and Joining a Secure Conference
To schedule a conference you can use either the Outlook 2000 interface or the new Web Conferencing Scheduler included in Service Pack 1. (See “New Web Tool” for an example.)

To use Outlook to schedule a secure meeting:

1. Open Calendar and select “New Meeting Request” from the Actions menu.
2. Click the “To” button.
3. Scroll the list and select the Data Conference resource. Be sure to include it in the “Resources” window.
4. Scroll the list and select each attendee and add them to the “Required” or “Optional” windows.
5. Enter a subject and message of your choice.
6. Uncheck the “Allow external attendees” box.
7. Set the time of the meeting.
8. Click Send. The Conferencing Server will respond with a pop-up window telling you the conference has been scheduled.

Figure 3. When the time for the meeting arrives, attendees will be requested to select a certificate to use for identification.

Figure 4. After authenticating using their Windows logon, users will be able to use the NetMeeting chat securely. (Click image to view larger version.)

Conference invitees will receive the URL of the meeting in their invitation. At the time of the conference they can join by clicking on this URL. If they’re early, a Web page on the conferencing site will tell them they’ll automatically join when it’s time. NetMeeting will be started, and they’ll be asked to select a certificate to use for authentication (Figure 3) and to logon. To do so they must enter their Windows logon credentials in the form domainname\userid. After authentication, they’ll be able to use the NetMeeting chat as usual. The words “secure call” will appear on the NetMeeting screen (Figure 4).