Freigeben über

Why use a Director?

  • Artikel
An excellent post I came across on an internal discussion today: https://blogs.technet.com/b/dougl/archive/2009/04/26/the-ocs-director-component.aspx

 

The Director Component in OCS: Traffic Flow, Authentication, and Use Cases

Over the years, I’ve seen a number of different discussions about the directors, what they do, how they behave, and when we should use them. This post summarizes what I believe to be the salient points concerning the director component. Hopefully, this will serve to clarify rather than confuse.

One of the advantages of directors that we originally touted was that it “offloaded authentication” and relieved the pool of that duty. This is only partially true. The behavior is slightly different whether we are talking about external users or internal users.

Director Traffic

Please consider the following diagram while I describe the traffic flow:

Traffic flow diagram with director

External case (the Chicago user in the diagram):

  • The remote user initiates SIP registration with the Access Edge. The Access Edge validates some SIP headers and determines that the registration should be sent to its next internal hop—the Director. (For the purposes of this discussion, the Director could be any Pool configured as the next internal hop. There is no functional difference.) This is the flow marked A in the diagram.
  • The Director authenticates the registration and performs an AD lookup to find the user’s home pool. (Authentication here must be via NTLM because the client cannot contact a domain controller to acquire a Kerberos ticket.)
  • The Director proxies the traffic to the user’s home pool. (Redirecting an external user makes no sense since the external Communicator client cannot contact the pool directly.) This is the flow marked B in the diagram.
  • Traffic proxied to the pool from the director does not require additional authentication. (The client performed NTLM authentication at the director, each SIP message is now correctly signed, and the traffic to the pool is coming from a trusted server—the director—not the client.)

Internal case (the London user in the diagram):

  • Internal user initiates SIP registration with the Director. (This happens because this company has configured their internal DNS SRV records to automatically configure Communicator to register with the director.) This is the flow marked X in the diagram.
  • The Director authenticates the registration and performs an AD lookup to find the user’s home pool. (Kerberos can be used here because the client is internal.)
  • The Director redirects the client to the user’s home pool. (Redirecting, in this case, simply means that it sends a 301 SIP response to the registration request. The response contains the FQDN of the user’s home pool.)
  • The user now follows the regular registration process with their home pool (discovered via the 301 response). This requires authenticating to the pool. The second authentication is necessary because of the challenge/response authentication nature of client-to-server communications. No information from the original authentication request will be contained (nor would it make sense) in these requests. This is the flow marked Y in the diagram.
Director Benefits

Given the above understanding, let’s make some application. Here are the benefits of directors:

Security: In an environment with an access edge but no director, unauthenticated traffic will be sent to your production pool for authentication. The edge server will validate some SIP headers but it would be possible to craft a SIP message that gets through. This gives an attacker a direct path to your internal production server. The director component lets you isolate that unauthenticated traffic to a server that is less critical. Some organizations will find this very important even in single pool deployments.

Performance: For remote users, the director will proxy all SIP traffic. Without directors, you have to pick a pool that will proxy the traffic. This could have a performance impact to the users homed on that pool. The director is also handling authentication for those remote users.

When to Use a Director

I have been asked if there’s a certain number of users that your deployment should be supporting before it makes sense to have a director. It’s not the user-count that is important; it is whether or not the deployment has remote access and the number of internal pools. Let’s consider the four different combinations of these two factors:

  • Environments with multiple pools and remote access: The director serves a critical role as the “next hop” inbound from the edge and proxies traffic from remote users to the appropriate pool. A director should always be used when the customer has multiple pools and remote users.

  • Environments with multiple pools and no remote access: One way to provide automatic configuration of Communicator involves configuring the internal DNS records to point the client to the director. The director is useful in this scenario as it will handle the redirection of your internal clients. In the absence of a director, you can configure Communicator to register with any pool and it will be redirected but you must plan for this additional load. (Some customers will be uncomfortable requiring the use of a remote director to sign into a local pool and may prefer an unsupported solution that involves configuring DNS differently or a supported solution using manual or group policy-based configuration.)

  • Environments with one pool and remote access: The benefit of preventing unauthenticated SIP traffic from reaching the user pool may be sufficient to justify a director.

  • Environments with one pool and no remote access: Even if the customer is not currently planning multiple pools, during migrations or for piloting different versions or configurations, it will be required to establish multiple pools. Start the design with no director but add it as part of the project that installs the second pool.

Note: I should point out that in the above traffic flow descriptions, when evaluating how to handle the registration request, the director or the pool doesn’t really know if the user is external or internal. All it knows is whether it is the first hop or not (based on SIP Via headers). The default behavior of every OCS front end (whether in a director pool or a user pool) is to redirect traffic to the correct home server if it is the first hop and proxy the traffic if it is not. (This default behavior can be changed by modifying the RedirectMethods property of MSFT_SIPEsEmSetting.)

--Doug

This post has been brought to you by Visio. Pretty drawing, huh?

OCS

Comments

  • Anonymous
    January 01, 2003
    thank you