I was recently involved in a situation where the SIP domain was different from the internal AD domain. This could be the case if your organization supports multiple SIP domains, or you have a “split-brain” DNS configuration (i.e. there is one DNS zone for the outside world such as “example.com”, and another DNS zone used only in the internal organization such as “example.corp”).
In this situation, the user SIP domain and the FQDN of the OCS server or pool will be different. To make the automatic sign-in work for Communicator in this scenario the DNS records used for automatic sign-in, and the OCS certificate on the front-end or enterprise pool needs to be tweaked. I explain these below.
DNS Records
Communicator clients find an OCS server or pool to sign into via DNS SRV records (this process is well documented – my posting DNS Records and Office Communicator Automatic Client Sign-In describes it). Normally the SRV record resolves to the FQDN of the OCS standard edition host or OCS enterprise pool name, and a DNS A record lookup then yields an IP address.
When the SIP domain does not match the internal AD domain, the primary DNS zone (which your client computers reside it) should resolve to a FQDN matching the format “sip.example.com”, and then an DNS A record should be added for “sip.example.com” that resolves to the IP address of OCS front-end. In this case “example.com” refers to your SIP domain (the host portion of the SIP URIs that are assigned to users).
For example, if my SIP domain was example.com, and TLS was the transport protocol used to connect to OCS, I would need a DNS SRV record for “_sipinternaltls._tls.example.com” that resolved to “sip.example.com”, and a DNS A record that resolved “sip.example.com” to the IP address of my OCS front-end server.
Tip: if the corresponding TCP SRV record exists, and TCP is enabled on the OCS server, the Communicator client will silently fail on the TLS connection and use the TCP transport. If you enable Communicator Event Logging you will see an event log error stating the there is a mismatch between the SIP domain, and the OCS domain.
Certificate Requirements
The significant requirement differing domain scenario to work is that the SIP domain needs to be specified in the certificate Subject Alternative Name (SAN) list in the format “sip.example.com” (i.e. “example.com” is my SIP domain). Most documentation references this requirement even if your SIP domain and AD domain are the same, so this might already be set in your environment.
In an enterprise pool, all front-ends needs this certificate. Note: the Subject Name requirements stay the same.
More information about OCS and automatic sign-in:
Automatic Office Communicator Sign-In (Part 1 – The Correct DNS Service Location (SRV) Record)
The OCS 2007 Automatic Sign-In Troubleshooting Tool V2.0
Twitter
LinkedIn