Configuring OCS 2007 for DNS Splitting

Automatic configuration allows Communicator to find and connect to the appropriate OCS server without manually entering a server name into its settings. Communicator has special requirements for DNS and certificates to make this work properly.

The problem that OCS likes other Microsoft UC solutions does not support multiple SIP name. Most of organizations need DNS splitting as security requirement.

Here you are the Scenario: We have organization that its internal domain name is Contoso.ad and have E2K3 server with E-mail Policy @contoso.com, they need to implement new OCS server to support internal and external users.

Easy, maybe it looks like that…The problem that office communicator is designed to log-on using server within same domain name i.e. the OCS FQDN must be in our case OCSSRV.contoso.ad.

Until now, it is okay but the user must log-on with name user@contoso.com so we have to support contoso.com SIP domain.

Are you confused? It is little tricky… here you are the solution

Hosting Domain Contoso.ad, Contoso.com

OCS Computer FQDN OCSSRV.contoso.ad

Supported SIP Domains:

Contoso.ad (default inherited from AD)

Contoso.com

DNS Records (Internal)

Split DNS configuration is a requirement for automatic configuration. Simply put, split DNS means you have two DNS zones for one domain name. One DNS zone exists on internal DNS servers and provides name resolution only for internal clients. Another DNS zone exists on external DNS servers to service external clients.

Split DNS is required so that users can use the same sign-on name in Communicator and have their correct login server resolved inside and outside the network.

First, we have to create primary DNS zone in internal domain with name Contoso.com. Create A record in it for OCSSRV server.

The following SRV records need to be created. Note that these records must be created in the DNS database of the servers authoritative for the particular zone.

Service Records (SRV)

ARecord

IP Address

_sipinternaltls._tcp.Contoso.ad

OCSSRV.contoso.ad

192.168.1.11

_sipinternaltls._tcp.Contoso.com

OCSSRV.contoso.com

192.168.1.11

Certificate Configuration

To support multiple domains for encrypted communications we require that all front-ends in the Pool be configured with a certificate. The certificate must match the FQDN returned by any DNS SRV query. Therefore, the certificate must contain multiple entries. We call these SANs (Subject Alternate Name) and the certificate must include the FQDN of the pool and one entry for each supported SIP domain.

Subject Name

OCSSRV.contoso.ad

Subject Alternate Name

Sip.contoso.ad

Sip.contoso.com

OCSSRV.contoso.com

OCSSRV.contoso.ad

I tried to do that through the OCS certificate configuration wizard …It should work.

but if it failed you can do it through another way.

You have to obtain Subject Alternative Name (SAN) to your OCS certificate. The OCS certificate is submitted to a certification authority (CA) that is configured on a Microsoft Windows Server 2003-based computer. The SAN lets you connect to a domain controller by using a Domain Name System (DNS) name other than the computer name. I will explain how to add SAN attributes to a certification request that is submitted to an enterprise CA (ContosoCA)

How to configure a CA to accept a SAN attribute from a certificate request

By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behavior, run the following commands at a command prompt on the server that runs the Certification Authority service.

How to create and submit a certificate request

When you submit a certificate request to an enterprise CA, the certificate template must be configured to use the SAN in the request instead of using information from the Active Directory directory service.

How to use Web enrollment pages to submit a certificate request to an enterprise CA

To submit a certificate request that contains a SAN to an enterprise CA, follow these steps:

What happens to name resolution for contoso.com in this case? I assume there is an external DNS that is authoritative for that namespace. When you create a primary zone for it on your internal DNS, IT is now authoritative for that zone and internal clients will not be able to resolve addresses for external hosts anymore…

We are setting up a OCS 2007 server, and we have several external domains at our company that our customers use to contact us. Some divisions of the business have some domain suffixes and some divisions of the business have other domain suffixes (Example: johndoe@companya.com, johndee@companyb.com, johncee@companyc.com, etc.) In total, we have 80 domain suffixes. We are going to add each of the external domains as SANs to our OCS 2007 certificate, because we would like a user’s IM address to be the same as their email address.

Is there a limitation on the number of SANs you can have in a single certificate?

I’m using, and have been using, UCC/SAN certs from GoDaddy since 2007 when we first rolled out E12.

I’m also using GoDaddy UCC certs on my current OCS 2007 R2 rollout.

Worst case is you install the entire cert chain to the server since the CA might not be recognized. This doesn’t seem to be an issue with server 2008, but it was an issue with server 2003.

David, I’m trying to accomplish exactly what you are: support mulitple external login access within our org. This is due to a merger of two companies. The thing that gets me is that *technically* UCC/SAN certs aren’t supported on the Edge server (though many people report that it works just fine). Internally we have no issues as we run split DNS and we are authoritative DNS for our own domains (we host our own DNS and different servers. This just makes the splitting of the zones easier as I don’t need to coordinate changes with an ISP).

For hosted access with Exchange involved there will be other concerns: segementing the GAL(s), etc. Other than that it should work fine.

I’m using certs from my internal CA for all but where actual external access is needed. Meaning my Frontend server, enterprise pools, and some edge services that only communicate internally. Saved me a lot of money and it works fine. My SIP routing domain is the same as my AD so it makes my life easier in this respect.

Lastly, GoDaddy is about $3600 for a three year, 100 domain UCC. You can search for “GoDaddy promotional codes” though and easily save another 25%. So figure about $3K from GoDaddy.

About Zeros & Ones

Hi, I’m Mohamed Fawzi and I am working as Senior Infrastructure System Engineer for LINK development company. This blog covers Virtualization technology and Cloud Computing.
*All the usual disclaimers are applied :)
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.