Share via

Do I need a director with OCS R2?

  • Article

I was asked this from a school district in Southern California who was rolling out OCS R2 and enterprise voice for the all their faculty and staff.

The answer depends on your OCS R2 architecture and whether your access is from internal or external networks.  For most schools, a single pool would apply and therefore a director would be optional depending on your external access security requirements.

 

Here is some information gathered from our product team to think about when considering a director:

 

Director traffic flow with External user access:

  • Remote user initiates SIP registration with Access Edge. Access Edge validates some SIP headers, determines that the registration should be sent to its next internal hop -- the Director. 
  • 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.)
  • 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.)

Director traffic flow with Internal user access:

  • Internal user initiates SIP registration with Director.
  • 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.)

What are the benefits of directors?

Security:   In an environment with an access edge and no director, unauthenticated traffic will be sent to your production pool for authentication.  The director lets you isolate that unauthenticated traffic to a server that is less critical (Director). Some schools will find this very critical even in single pool deployments. Other schools more than likely won't care.

Performance: For remote users, the director will proxy all SIP traffic. Without directors and with multiple pools, you have to pick a pool that will proxy the traffic. This could potentially have a performance impact to the users homed on that pool.

 

When I should I use a director server?

  • 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: The only supported solution that provides automatic configuration of Communicator involves configuring the internal DNS records to point the client to the director. 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 use 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.

Other notes:

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 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.

Comments

  • Anonymous
    January 01, 2003
    I was asked this from a school district in Southern California who was rolling out OCS R2 and enterprise

  • Anonymous
    January 01, 2003
    Ed, The director role gets installed automatically on a Front End. With smaller sized deployments this is sufficient.  I have only seen this role broken to a dedicated server with large scale deployemnts (20,000 users or higher).

  • Anonymous
    September 05, 2009
    The comment has been removed

  • Anonymous
    April 22, 2010
    How about hardware requirements for a directory?  Surely they do not need to be as beefy as the listed hardware requirements for a enterprise pool server or consolidated edge server, right?

  • Anonymous
    April 22, 2010
    Oops, meant "director" there, not directory.

  • Anonymous
    May 07, 2010
    Currently, we have a set of Directors setup in our infrastructure.  Internal and external traffic works as defined.  Would there be any benefit to tuning federation setting for each pool to route out to the director than to the the access edge?  Right not they route directly to access edge for federation and PIC.