locked
OCS 2007 R2 reverse proxy RRS feed

  • Question

  • Hi,

    I would like to deploy OCS 2007 R2 in my organization. We will use it ONLY for IM and presence, for both internal AND remote users. The total number of users is below 200, with less tan 10% remote users.
    Therefore, I have decided that I need an Edge server in DMZ and a Standard OCS R2 server in LAN. However, I don't understand two things:
     1. do I need a reverse proxy server as well? If so, what would it be used for (remember, only IM)?
     2. how many public certificates I need for the external interface of my Edge server, taken into account that I won't be using Web conferencing?

    Thank you very much for all your help!
    Tuesday, October 27, 2009 11:25 AM

All replies

  • a_burdujan,

                Thank you for the details of your deployment, it sounds pretty strait forward. Whether you need a separate reverse proxy is a good question, and I think in general one I hear from customers quite a bit. Security, in separation of function is actually the purpose of the OCS edge server itself, so for functionality you do not need a separate server to proxy this, but you can use a separate server if you would like; some organizations like to put multiple "Layers on the Onion". My days of designing Cisco networks and firewalls though makes me say that I would ABSOLUTELY recommend having a public (normally w/ the DG), and private interface on the Edge server to separate functions further.

                Certificates seem to be the biggest stumbling block by far, and when I manned the phones for OCS at Microsoft, they were our largest single call generator for OCS as well.  

                As far as the external certificate goes, you need a cert to handle each name that the server is referred to by. This can be handled many ways, and I will stick to the basics. An edge server can handle any combination of the 3 roles, IM, WebConf or A/V. Because some of the services may commonly use the same ports (specifically 443) we usually create different names for each connection point, and so different IPs. This really is not needed in all cases as we can control the ports used and redirect to an additional port, such as 444. In this case we could potentially use one name to handle connections for all services (each handled by unique ports, and so no port conflict for the services, given that we are using a single IP). Even where multiple names are used to provide services, a certificate can be configured (using SANs) to answer for all the names associated (See link below).

                Certificates only deal with the name or alias of the service connection point. So, in your case you only have one connection point facing the internet, and so you will need just one certificate subject name for public connection. However, you will also need a certificate to put on the internal interface for secure (MTLS) communications to the OCS pool server. If you have a internal PKI environment you can get a separate certificate from your PKI to save the money and time, but if not, and assuming you are using a publc trust to get it, I would recommend getting a single public certificate for the OCS edge server with the "Subject name" being you IM public connection point, and the local server name associated on the cert in the SAN. This will usually save you money and a whole lot of headache with managing multiple certificates.

                Hope this helps, please let us know if you have any questions

    -Here is an example where a SAN is used and how it is added to the certificate. The article in whole is not directly in line with what we are doing, but it may help to give you a baseline for adding SANs to a certificate, and what they are for. http://support.microsoft.com/kb/931351



    Don't forget to give credit where credit is due, vote this as helpful if it helped you.
    Thursday, October 29, 2009 1:45 AM
  • Hi Jared,

    thank you so much for this perfectly clear answer! I really appreciate your help and hope to be able to help somebody myself in the near future.
    Thursday, October 29, 2009 11:10 AM