The Director role in Microsoft Lync
Server 2013 is a specialized subset of the Front End server, which
simply provides authentication and redirection services. Unlike with a
Front End server, it is not possible to home user accounts on a
Director pool and it provides no user services to endpoints. The
primary function is to authenticate endpoints and then “direct” users
to the pool where their user account is actually homed.
When clients
sign in to a Director, they are first authenticated and then informed
of their primary and backup registrar pools. Directors are valuable in
deployments where multiple pools exist because they provide a single
point of authentication for the endpoints. When external access is
used, a Director can also serve as the next hop server between Edge
servers and the Front End pools. This extra hop between the Edge
servers and Front End pools can provide an additional layer of
protection against external attackers.
1. Dedicated Role
Just as in Lync Server 2010, the Director
role is a standalone role that is defined and installed like any other
server within the topology. For historical reference, during the Office
Communications Server timeframe, installing the Director role was
performed the same way as installing a Front End server and then was
followed by a series of manual steps to deactivate most of the Front
End services. These steps were well documented, but it was completely
up to the administrator to follow them correctly and completely. There
was also no way to prevent administrators or help desk users from
homing new user accounts on a Director pool because they appeared just
like any other Front End pool choice when enabling user accounts.
In Lync Server 2013 the Director is
still a completely dedicated and specific role separate from a Front
End server. It can be installed like any other role and requires none
of the manual deactivation steps previously required. This separation
not only improves the ease of deploying a Director, but increases the
security and stability of the role by not installing unnecessary
components and leaving deactivation to the administrator.
2. Benefits of a Director
The biggest challenge around
planning for a Director is determining whether a business even needs to
deploy the role. Historically, the Director has been an optional but
recommended server to deploy. In Lync 2013 the “recommended” text has
been removed and the role now appears to be optional, but that does not
necessarily diminish the value of a Director. This section covers the
reasons why organizations might still want to choose to deploy a
Director for Lync 2013.
Internal Endpoint Sign-In Process
Before you review the benefits of a Director,
it is important to first understand how an internal Lync client
actually signs in. Clients default to searching DNS for service
locator, or SRV, records based on the SIP address a user entered.
Multiple SRV records can be returned, each with a different weight and
priority so that a client can select the most preferred record. In the
case of Lync 2013 the client will select the record with the lowest
numeric priority and the highest numeric weight.
There is no logic in an endpoint to indicate
that it is initially connecting to a Director pool and not a Front End
server, meaning that the same DNS records, authentication methods, and
signaling are used from the endpoint’s perspective. The Director first
authenticates the user and then simply provides the user’s primary and
backup registrar pools.
Note
The Registrar is a component of the Lync
Front End service which runs on Front End pools and Director pools.
This component is responsible for authenticating users and handling
user sign-ins.
The client then attempts another sign-in to
the primary registrar pool the Director provided, and if that pool does
not respond it will attempt to register to the backup pool. The actual
sign-in process looks like the following:
1. Endpoint requests DNS SRV records for automatic configuration.
2. Lowest-priority and highest-weight record returns the name of the Director pool.
3. Endpoint attempts to register to the Director pool.
4. The Director first
attempts to verify the user’s credentials via certificate
authentication, Kerberos, or NTLM. If the credentials are invalid, the
endpoint is not authenticated and the connection is closed.
5. If the credentials
are verified successfully, the Director checks for the primary and
backup registrar pools assigned to the user.
6. The primary and backup registrar pool information is provided to the user in the form of a 301 Redirect SIP message.
7. The Director closes the session with the endpoint.
8. The endpoint attempts to authenticate again to the primary registrar.
9. The endpoint attempts to authenticate again to the backup registrar if the primary registrar does not respond.
After a Director authenticates an endpoint
and provides the registrar information, it will be removed from the
communication path. An endpoint will communicate with its own Front End
pool after receiving that information, as shown in Figure 1.
Figure 1. Director relation to internal pools.
The process shown in Figure 1 is true for clients as long as the DNS records for lyncdiscover and lyncdiscoverinternal are not published. These records are preferred by the Lync 2013 PC client over SRV records.
