Centralized Sign-In
Based on the previously described sign-in
process, administrators without a Director in a multiple Front End pool
environment face a dilemma of determining which pool should handle the
initial sign-in and authentication for all users. The Lync client
applications use weighted DNS SRV record lookups to find a pool, and
only one pool can be considered the most preferred. When a Director
exists, these DNS records typically point at the Director, which then
handles sending the user a SIP 301 Redirect message with the primary
and backup registrar pool information. Without a Director, one of the
Front End pools in the environment must be responsible for handling
these tasks for all users.
Historically, the Director role played a much
bigger part in the sign-in process every single day, and careful
planning was required to ensure that there was enough processing
capacity available to handle the bulk of sign-in and authentication
traffic occurring during the morning hours in each region. The benefit
of a dedicated Director from an internal perspective was that these
initial authentication requests were offloaded from Front End servers.
However, since Office Communications Server 2007 R2, the client applications have maintained a file called endpointconfiguration.cache
in the local settings folder of a user’s PC. This file contains the
user’s primary pool and preferred server in a pool so that on
subsequent sign-in attempts the client will actually attempt to first
contact the server in the file before falling back to any DNS SRV
record lookups and potentially leveraging a Director.
This means that although a Director
can certainly offload authentication and sign-in traffic from a Front
End pool for a user’s first sign-in, it’s of little benefit internally
on later sign-in attempts. The clients are generally bypassing the
Director altogether by leveraging their local cache information. Of
course, if that cache is removed or fails at some point, the Director
will be used again, but many organizations have begun to accept that
temporary traffic increase to a Front End pool.
Optimized External Access Path
Another strong benefit of using a Director is
its capability to serve as a barrier between internal pools and
external traffic. To understand the benefit here, it is important to
know that Edge servers do not authenticate external user requests
across the Internet and merely pass this traffic to a next-hop internal
server to handle authentication. This means that without a Director all
external traffic is being authenticated by a Front End pool, or in
other words, anonymous Internet traffic is being allowed to communicate
with an internal domain member server.
Instead of allowing authentication requests
from an Edge server to pass directly to a Front End pool, a Director
can be placed in between this communication path and used to
authenticate users before external traffic ever reaches a Front End
server. This doesn’t change the fact that an internal domain member is
accepting unauthenticated traffic, but it does
provide some protection for Front End pools because traffic will never
get through the Director without being authenticated.
A Director can also help simplify the
federation and remote access paths for SIP traffic within an
organization. Instead of requiring firewall rules for SIP between all
Front End pools, a Director pool can be specified as the outbound
federation route. This means that all Front End pools send their remote
traffic to the Director first, which then communicates with the Edge
servers. This scenario is depicted in Figure 2
where the Director stays within the communication path at all times to
ensure that the internal pools are protected. This topology also helps
with troubleshooting efforts because the signaling path is more
predictable, and reduces the number of firewall rules required.
Denial-of-Service Barrier
A compelling reason to deploy a
Director is the fact that it provides some isolation for Front End
pools from the Edge servers and Internet. If there was a
denial-of-service attack against the Edge servers, only the Edge
servers and the Director would be affected. This separation allows the
Front End pools to continue operating as normal without being impacted
by the attack. If a Director was not deployed as the next hop from an
Edge server, an attack could potentially impact a Front End pool and
cause a much larger disruption to user services.
Simple URL Entry Point
The final major benefit of a Director is to serve as a terminating point for the simple URLs in an environment, as shown in Figure 3.
Simple URLs are web URLs defined within Topology Builder that handle
redirects for meetings, dial-in access numbers, and, optionally, the
Lync Server Control Panel admin page. Just as with SRV records for
sign-in, these URLs each have a single namespace that can be shared
globally throughout the organization. When anonymous users connect to
one of these names with a valid request, they are provided a redirect
to the correct web services URL for a Front End pool. As with user
sign-in, any Front End pool can handle this functionality, but
publishing the simple URLs through a Director could be attractive to
organizations that don’t allow anonymous remote users to access their
Lync infrastructure.
Figure 3. Reverse proxy publishing of simple URLs to a Director.
As with the simple URLs in an
environment, lyncdiscover.domain.com is a hard-coded DNS name that Lync
mobile clients use to discover a connection point. Directors are a
perfect target for this record because they also run the Autodiscover
service within the internal and external IIS websites. Anonymous
mobility requests reach the Director, the user is authenticated, and the user then receives a redirect to the web services URL for the primary registrar pool.
