RSS Subscription 168 Posts and 2,769 Comments

Archive for August, 2009

Office Communications Server 2007 R2 Audio/Media Negotiation

Read the Lync Server 2010 version of this article here.

There are several ways in which we can utilize Audio/Video streams in Office Communications Server (OCS) R2.   The same “should… but not verified” work the same in OCS 2007 R1.  There aren’t really any places out there that describe how the media session works in different circumstances.  For example, what servers and ports are utilized when doing Audio/Video through the Live Meeting 2007 client when connected to the On-Premise Web Conferencing feature in OCS 2007 R2?  How about when you do a peer to peer with both users being internal to the network?  How about both users being external to the environment and connecting through the Edge?  How about when you do a peer to peer with one user being internal and one user being external?  Want to know?  Read on…

Media Ports and Restricting Amount of Ports Being Used

The first thing to understand is that in OCS 2007 R2, when a user attempts to activate any type of audio and/or video, they first attempt a peer to peer session.  The ports utilized here are TCP/UDP 1024-65535.  You can see what ports are used for OCS 2007 R2 here and here.  This port range is utilized mainly for users who are internal to the network.  If you want users to utilize peer to peer audio while internal to the network, you must ensure that this port range is open even if users are in different sites.

But what if you don’t want this entire port range open between your sites?  You can utilize Group Policy in both OCS 2007 R2  to limit the amount of ports that are being used.

These two settings include:

  • PortRange/MaxMediaPort
  • PortRange/MinMediaPort

The above group policy settings modify the following three registry keys:

  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\Enabled REG_DWORD 1
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MaxMediaPort REG_DWORD 40039 (for example)
  • HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator\Portrange\MinMediaPort REG_DWORD 40000 (for example)

Note: Both clients must have these registry keys set in order for the modified port range to take effect.

You must have at least 40 ports open which is an IETF Interactive Connectivity Establishment (ICE) protocol requirement to ensure that Audio/Video port negotiation works for peer to peer while internal to the network.  ICE is a protocol that provides a mechanism for firewall or NAT traversal.  The RFC draft for this protocol can be found here.

Audio/Video Connectivity Scenarios

Two Users Internal to the Network (media ports open)

When these two users are internal , they will attempt peer to peer.  Because they can successfully connect to each other, they utilize peer to peer media.  This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server.  Because these users connect directly to each other for media, they have no need to connect to the Edge.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Audio/Video through the Web Conferencing Server

When users are connected through On-Premise Web Conferencing and activate Live Meeting (when internal or external… doesn’t matter), they are connecting directly through the Front End’s Conferencing MCU’s.  Because of this, even when it’s two users, the user’s are still connecting to the Front End MCUs.  If both user’s are external, they still connect through the Front End MCUs but are proxied through the Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users Internal to the Network and Any Users External to the Network

As previously stated, any time you have more than two users, peer to peer is no longer utilized and users always connect directly to the MCU on the Front End Servers.  This means that both users internal to the network will connect to their Front End server(s) and the external user will connect to the Front End server as well utilizing the Edge Server for proxying to the Front End.  There is absolutely no peer to peer connectivity in this situation.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users on the Internet

When these two users are external , they will attempt peer to peer.  Because they can successfully connect to each other, they utilize peer to peer media.  This is why OCS scales pretty high; because a lot of connections are one to one which means that peer to peer media connections are never bridged through the server.  Because these users connect directly to each other for media, they have no need to connect to the Edge for Audio/Video.  You will still see the user connected to the Access/Edge over port 443 and/or 5061 (if these are your remote access port and federation port if you are using federation).  When users are connected through On-Premise Web Conferencing and activate Live Meeting, they are connecting directly through the Front End’s Conferencing MCU’s.  The Front End will have a certificate that contains the Pool Name and will/can contain SAN names for additional SIP domains that you may contain.  Because of this, SAN names are supported on Front End Servers.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Two Users Internal to the Network (media ports closed)

When these two users are internal , they will attempt peer to peer.  During their ICE negotiation, as previously stated, they will know the Internal Edge NIC in case their peer to peer connectivity fails. Because they fail to connect to each other, they will connect to the internal Edge NIC over either UDP 3478 or TCP 443.  ICE has a mechanism where it will test a lot of candidates to see where connections should be made.  ICE will test UDP 3478 and TCP 443 in parallel and if UDP 3478 works, the client will receive UDP 3478 due to it having less overhead.  If UDP 3478 does not work, the client will receive TCP 443.   If you anticipate on blocking ports between your users, make sure your Edge Server can scale high enough to deal with the amount of Audio/Video connections it will be handling.  To block one of your sites from doing peer to peer with other sites, block the peer to peer port range (discussed at the beginning of this article) from that site and block that site from communicating over UDP 3478 and TCP 443 to the Edge Server.  This will prevent clients from doing any type of media communication from user’s outside of their own site.  If you want to allow them to do peer to peer for users in some sites, modify the firewall ACLs accordingly for those sites.

Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

One User External and One User Internal

When one user is internal and one user is external , they will attempt peer to peer but not in the same sense as in two internal users. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge.  As stated earlier, UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing.  If you attempt a telnet edgeserver.domain.com over the Internet, telnet will fail to connect.  This is because telnet uses TCP.  You can do a netstat -an to see your server listening on UDP 3478 and utilize a different program such as netcat which can attempt telnet to UDP by using netcat -u host 3478.  More information on netcat here.

Moving on… we see that the user will connect to the A/V Edge over UDP 3478 or TCP 443, but what about the internal user?  Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well.  The Front End A/V MCU will not be used in this scenario.  When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.

Note: Diffserv markings for Quality of Service (QoS) are lost through an Audio/Video Edge Server.

Note: The red arrow signifies a successful media connection only.  The diagram does not reference any other signaling such as SIP.

Issue to be aware of in OCS 2007 R2 (not verified as an issue in Lync 2010)

Certain certificate vendors like to add www automatically to the CN of your certificate request with consent from the person requesting the certificate.

So for example, our certificate request for a regular certificate (non SAN) was CN=Servername.domain.com.  These vendors provided the following certificate:

  • CN=Servername.domain.com
  • SAN=www.Servername.domain.com

Now this is where you can run into an issue when doing peer to peer and falling back to the internal Edge NIC or when one person is on the Internet and one person is internal while using Communicator.  Some certificate vendors like to assign a www as a SAN name to your regular (non-SAN) cert.  So if you requested a CN of Servername.domain.com, these vendors will automatically add www in front of your CN.  This messes up peer to peer audio/video negotiation.

This is important to remember when getting a 3rd party certificate for the Internal Edge NIC.  It is not supported to have anything other than a CN for this certificate.  The reason why is ICE negotiation will not work properly.  Because the www.servername.domain.com will be there as a SAN, the client will be provided the www.servername.domain.com name for ICE connectivity to the internal Edge NIC which will obviously fail.  Because of this, the scenarios above which utilize the Internal Edge NIC will fail.  To recap, the following two scenarios end up using the Internal Edge NIC:

  • One user internal to the network and one user external to the network
  • Internal users attempting to do peer to peer (media ports being closed) and falling back to the Internal Edge NIC

There are a few ways to fix/workaround the problem:

  • Use a Windows PKI implementation for Internal Edge NIC
  • Deal with the SAN name but use a CNAME for www.servername and redirect that to the servername HOST/A record using Internal DNS to do this as you are dealing with the Internal Edge NIC.
  • If the vendor doesn’t add www to their SAN certs, you can get a SAN cert only with the CN filled out
  • Go with a different vendor that doesn’t automatically add www to their regular certificates.
Share

Publishing Exchange 2007 Autodisover in ISA 2006 – Part 2

Since writing the first part of this article here,  I’ve seen a lot of questions about how you really publish things like the Autodiscover as there have been many articles out there where they keep the Autodiscover in the Outlook Anywhere rule and others where they separate it out.  I wrote the first part of this  article  a while back when Autodiscover was quite unknown and I was a bit new to ISA and figuring things out.  Since then, I have done quite a bit with Autodiscover and written several articles about it as well as done a lot with ISA itself.  Because of that, I wanted to create a part 2 and really detail on the different methods which you can use in regards to authentication and how it really ties together.

One thing needs to be taken into consideration. Integrated Authentication in IIS uses NTLM or Kerberos.  These protocols were designed to prevent man in the middle attacks.  What this means is that when you create an ISA rule, you cannot typically have your rule’s authentication delegation using Integrated Authentication as this will mean that ISA is attempting to do a man in the middle attack.  There are two ways to make this work.  One is by using Kerberos Constrained Delegation in which you use a separate listener which listens on NTLM and then use Kerberos Constrained Delegation to talk to Exchange.  This way, you enable Outlook Anywhere for NTLM, then allow ISA to request Kerberos tickets and pass that right to Exchange.  The other  method is to set the rule to not require the client to authentication to ISA but the client can authenticate directly to Exchange.  This prevents ISA from delegating NTLM and then allows the client to NTLM auth directly to Exchange.  This way you can have 1 listener because when you configure the bypass, it’ll trump the requirement to authenticate to the listener.  And because Autodiscover uses Integrated Auth, you can have Autodiscover on the same rule.

An important thing to note is that if you do decide to go with Kerberos Constrained Delegation, both the ISA and CAS computer accounts need to be on the same domain.  It is because of this, the KCD method will not work when ISA is joined as a workstation.

So the existing ways to publish Exchange with Autodiscover are the following:

  1. Outlook Anywhere NTLM
    1. Two Configurations
      i.      Increased Security and added complexity – Utilize a separate listener just for your OA rule that utilizes NTLM and then configure Kerberos Constrained Delegation as the Authentication Delegation mechanism within the OA rule to authenticate to IIS on the Exchange CAS RPC Proxy Server
      ii.      Reduced Security and less complexity – Utilize the same listener for all Exchange Services including OA and take ISA Pre-Authentication out of the mix and allow the client to authenticate directly to the Exchange Server.  Because ISA Pre-Authentication is taken out of the mix, NTLM will work and the user will not be prompted since there’s nothing in the middle preventing a man in the middle attack.
    2. Because you’ll be using NTLM with OA, you can use Autodiscover on the same rule
  2. Outlook Anywhere Basic
    1. Use the same listener for all Exchange Services.
    2. Set listener to forms based authentication since the listener will fall back to Basic Authentication since OA does not support Forms.
    3. Configure each rule with the appropriate authentication delegation mechanism so each service in the /path/* for that rule contains the same authentication within IIS.  So for example, if I have OAB and EWS on that same rule and Basic Authentication delegation is configured for that rule, IIS for both OAB and EWS will need to contain Basic Authentication

So let’s take a look at Outlook Anywhere with NTLM.  Because we’re using NTLM, we’ll need to either create a new listener and have that use NTLM and then use Kerberos Constrained Delegation.  This way, a client on the internet can use NTLM and then the ISA machine needs to be able to request Kerberos tickets on behalf of the authenticated user and then pass this service ticket to the Exchange Server.  This gets around the man in the middle attack.  But because of this, you’ll need the NTLM listener and then a different listener for things such as OWA/EAS/Etc..  With this method, you’ll have 2 listeners. Because you’re using NTLM, you can have your Autodiscover path (which passes NTLM to Exchange) on the same rule as Outlook Anywhere.

Now with Kerberos Constrained Delegation, that’s the only time you’ll have a 2nd listener.  Any other situation you’ll have just a single listener.  You can still use Outlook Anywhere with NTLM, but in this case, you’ll have to configure your rule to not require authenetication from ISA and to just allow the client to authenticate directly.  This way, you’re bypassing Pre-Authentication.  But even with bypassing pre-authentication, you’re still being authenticated.

Now with any of the above 2 configurations, you can have Autodiscover on the Oulook Anywhere rule because you’re essentially allowing the client to use NTLM (first method uses NTLM on listener and KCD to authenticate to the Exchange Server and second one bypasses ISA pre-authentication and lets client authenticate directly to Exchange in which NTLM will work.)

Now if you’re using Basic Authentication for Outlook Anywhere, you can just have 1 listener that just does Forms Based Authentication.  This is because if the service authenticating to the listener does not support FBA, ISA 2006 (not ISA 2004) has the capability to fallback to basic authentication.  It’s this reason you can use a single listener.  Then for all the services, you’ll need to make sure the rule’s authentication delegation is set approproiately.  Authentication Delegation is always only set on a rule and the delegation type has to match what is set in IIS on Exchange.  So if you authenticate to ISA’s listener via FBA, ISA will then look at the rule’s authentication delegation and then use that authentication type to authenticate back to Exchange.  It knows which rule to use by looking at the /path/* in the rule.

When you use this method, I will typically put Autodiscover in its own rule and set that to bypass pre-auth while all other services are not bypassing pre-auth.  I don’t leave the /autodiscover/ path  in the Outlook Anywhere rule because they will now be using different authentication types.  And I don’t want to be authenticated by Autodiscover and Outlook Anywhere (if using basic) so I let Autodiscover bypass pre-auth but still require Outlook Anywhere to authenticate.

One thing to keep in mind here, is with ISA 2006, if you configure a rule to bypass pre-auth, it’ll trump the listener and the client won’t need to satisfy the listener authentication and the authentication will pass through in which Exchange will then perform the necessary authentication.

Share