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.
“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
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
- 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
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
- 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
- Open the Internet Services Manager console and navigate to the Web
site that hosts the virtual directory for Conferencing Server.
- Right-click and open Properties.
- Click the Directory Security tab
- In the Secure Communications area, click “Server Certificate.” The
wizard launches, which will install the server certificate.
- Click Next.
- Select “Create a new certificate” and click Next.
- Select “Send request immediately to an online Certification Authority”
and click Next.
- Type a friendly name for the certificate.
- Enter the following information as it exists on the CA: organization
name, organization unit.
- 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.
- Enter country, state or province, city or locality and click Next.
- Select Certification Authority. You should see the name of your CA
in the drop-down list. Click Next.
- 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
- 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.
- On the Directory Security tab in the Secure Communications area,
click the Edit button.
- Check the box “Require Secure Channel SSL.”
- In the Client certificates area, check “Require client certificates.”
- Click OK twice to close the Properties page.
Configure the Conferencing Private Virtual Directory
to Insist on Client Authentication
- In Internet Services Manager, navigate to the properties page of
the ConferencingPrivate virtual directory.
- Click the Directory Security Properties tab.
- In the “Anonymous access and authentication control” area, click
- 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.)
- Click OK twice to close the Properties page.
Configuring the Conferencing Server’s Default URL for
You also want to use a secure connection by default for Conferencing
- Open Start_Programs_Exchange Server_Conferencing Management Service
- Click the site of the Conferencing Server.
- In the details pane, right-click the server and select Properties
- Click the Conference Settings tab.
- Change the default access URL from http to https.
- Click OK to close the Properties page.
- Open the Services console.
- Stop and start the Conference Management Service for the conferencing
|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.
- The user should be logged on. You can’t request a certificate as
you and then give the certificate to another user.
- If a Certificates console hasn’t been built for this user, open a
new MMC (Start, Run, MMC, Enter).
- From the console menu select “Add/remove snap-in.” Add the Certificates
snap-in, choosing the “My user account” management option.
- Expand the Certificates current user container and right-click on
the Personal folder.
- Select All Tasks, then select Request New Certificate and launch
the Certificate Request Wizard.
- Click Next.
- Select the “User” certificate template and click Next.
- Enter a friendly name. This information will be used to identify
the certificate when the client joins the session.
- Click Next, then Finish.
- Click Install Certificate.
- Verify that the certificate is in the Certificates_Personal_Certificates
- 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.
- Create an AD global group and add user accounts of your designated
- Create a local group on the Conferencing Server and add the global
group to its membership.
- 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.
- 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.
- Right-click the Calendar object and then click Properties.
- Click the Permissions tab.
- Use the Add button to add the local scheduling group and then assign
it Author permissions.
- Verify that anonymous users are not given permissions here.
- Click OK to close all windows.
- Close Outlook and logoff.
- 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
- Open Exchange Server_Conferencing console.
- Right-click on the Exchange Conferencing\site conferencing site and
- Click the Conference Settings tab.
- 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.
- Check or uncheck the “Change conference time” to allow or deny the
scheduler the ability to extend the conference time.
- Click the Logging Page.
- 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.
|Table 1. Conferencing Server Logging
Server Log Items
Conferencing Provider Log Items
||Client connection refused
||Client connection failed
||New MCU server added
|Time extension requested
||Client join attempted
|Resource extension requested
||Client invite attempted
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. Open Properties page of the Data Conferencing Server.
- 2. Select the Visibility page.
- 3. Click the Add button.
- 4. Enter the network address and subnet mask for the subnet of those
allowed to connect to the Conferencing Server.
- 5. Click the General page.
- 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.
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
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
- Create a global group. (Alternatively, if you allow all users to
conference, you could use the Domain Users group.)
- Add users you wish to allow to conference. (Domain Users already
includes all users in the domain.)
- Create a local group (or use Users) on the Conferencing Server. I’ve
called mine “Conferencing Users.”
- Place the global group in the local group.
- Open the group policy for the OU in which the Conferencing Server
resides. Ideally this OU will contain only Conferencing Servers.
- Navigate to Windows Settings_ Machine Settings_Security Settings.
- Double-click Local Policies_User Rights_Logon Locally.
- Use the Add button to add your local group and give it this right.
- Click OK to close the right.
- Close the Domain Security Policy.
- 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:
- Open Calendar and select “New Meeting Request” from the Actions menu.
- Click the “To” button.
- Scroll the list and select the Data Conference resource. Be sure
to include it in the “Resources” window.
- Scroll the list and select each attendee and add them to the “Required”
or “Optional” windows.
- Enter a subject and message of your choice.
- Uncheck the “Allow external attendees” box.
- Set the time of the meeting.
- 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).