Automatic Office Communicator Sign-In (Part 1 - The Correct DNS Service Location (SRV) Record)

Three items are key for automatic Office Communicator sign-in to work in an OCS 2007 environment:
2. 1. Specifying the correct FQDN in DNS for the SRV record used for automatic sign-in. Ensuring the correct Subject Name (and possibly Subject Alternative Names) are specified on the OCS certificate where the client connects (e.g. the certificate on the Front-End or Director role). 3. Ensuring that the Certificate Authority that issued the certificate is trusted by the client.

In my experience, Office Communicator sign-in issues are usually caused by one of these settings not being correct. Ill explore each of these requirements in seperate blog posts. Ill start now with the first: specifying the correct FQDN in DNS for the SRV record. At a high-level, when an Office Communicator client is configured for automatic sign-in, it goes through the following steps to obtain an IP address to connect to:
1. A query is made to DNS (against the DNS server configured on the Windows client) for an SRV record associated with the SIP domain of the SIP address for the user attempting to sign-in. The SRV record must be of a particular format. See my previous blog post on what the format of the DNS record should be. The SIP domain is the right-hand-side of the user s SIP address (e.g. example.com for the SIP address user@example.com). 2. The successful DNS query returns two key pieces of information: a fully-qualified domain name (FQDN) and a Port. 3. The client then does a DNS A record lookup on the FQDN to get an IP address associated with the FQDN. 4. The Communicator client attempts a connection to the IP address and Port.

Note: if the Communicator client is not configured for automatic sign-in, it just uses the DNS A record for the FQDN (or hostname) configured directly in the client. Also, if no SRV records are found, Communicator tries several DNS host (A record) lookups (see my previous blog post for the specific formats). What FQDN should be listed for the DNS SRV record? Depending on your environment, this could be the FQDN of an OCS Front-End, a Director, or the Virtual IP (VIP) of a load balancer. The table below answers the most common scenarios. TABLE 1: WHAT SHOULD THE AUTOMATIC SIGN-IN DNS SRV RECORD POINT TO?
Pool Type Standard Edition Server YES With Director With HLB DNS SRV FQDN Front-End Server Director DNS (A) Record IP of Front-End IP of Director

Consolidated Enterprise Pool YES YES Expanded Enterprise Pool YES YES YES YES

Pool Director (1) Pool Pool Director (1) Director (1)

IP of Front-End in Pool IP of Director Internal VIP of HLB Internal VIP of HLB IP of Director IP of Director

Notes:
(1) HLB = Hardware Load Balancer (2) If the Director is a Standard Edition, the FQDN is the FQDN of Standard Edition Server. If the Director is an Enterprise Edition, the FQDN will be the FQDN of the Pool associated with the Director. (3) If you have multipe SIP domains in your environment, you require a DNS SRV record for each one.
InsideOCS has a free download tool (the Automatic Sign-In Troubleshooting Tool) that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used. For more details all the automatic sign-in process and it s requirements, see:

y y

y DNS Records and Office Communicator Automatic Client Sign-In Automatic Office Communicator Sign-In (Part 2 ensuring the correct Subject Name on the Certificate) Automatic Office Communicator Sign-In (Part 3 ensuring the client trusts the issuing Certificate Authority)

Also, Page 65 of the Microsoft Office Communications Server 2007 Planning Guide details the DNS SRV requirements for automatic client sign-in. Byron Spurlok has a good post with more details on how to create these DNS records on your DNS server.
Share and Enjoy:

y y y y y y y y y

August 28th, 2008 | Tags: communicator automatic sign in, communicator dns, communicator login, microsoft communicator sign in, microsoft ocs automatic sign-in, OCS Automatic Sign-In, OCS Certificates, ocs dns, ocs login, Office Communications Server Automatic Client Sign-In, Office Communications Server Certificates, _sipinternaltls | Category: Client, Communicator, DNS, Debugging

Automatic Office Communicator Sign-In (Part 2 ensuring the correct Subject Name on the Certificate)
A crucial setting to make automatic Office Communicator sign-in work is ensuring that the correct Subject Name (and possibly Subject Alternative Name) is specified on the certificate which resides on the OCS server where the Communicator client connects (e.g. on the Front-End or Director role). When you look at the Certificate details, the Subject Name is listed as the Subject property. The basic requirement for the Subject Name on the certificate is that it match the DNS FQDN of the hostname that the client is connecting to. For example, if Office Communicator determines that it needs to connect to the FQDN host1.example.com, the Subject Name on the certificate should be host1.example.com. Note: the actual requirement is that the Common Name (CN) portion of the Subject Name matches the DNS FQDN, but many documents use Subject Name and Common Name interchangably (the Common Name is just the CN portion of the SN). Certificates also have one or more Subject Alternative Names (SANs) which specify alternate hostname(s) that the host can be known as. Generally speaking, if the correct FQDN does not match the SN, but is listed as one of the SANs, the certificate naming requirement will be satisfied. For OCS clients connecting to an Enterprise pool, the pool name must be the Subject Name. The primary use for this certificate check is for security purposes. It allows the client to be sure that the server it wants to connect to is indeed that server. Think of a server certificate as a passport for that server it validates its identity to all the clients that use it. Two factors can make setting the proper SN confusing: 1. Using OCS 2007 Standard Edition vs. Enterprise. Use of a Director (between the client and OCS 2007 server).

2.

As a general rule, the Subject Name of the certificate should match the fully qualified hostname of the first OCS server the client connects to. If it is an enterprise edition deployment, the Subject Name should be the FQDN of the enterprise pool. FYI Hardware Load Balancers (HLBs) do not affect the SN on the certificate. HLBs just pass the connection through to the OCS server. The following table summarizes the Subject Name requirement on the certificate for different OCS deployments: Situation Standard Edition Server Consolidated Enterprise Pool With Director With HLB Certificate Subject Name (SN/CN) Front-End FQDN Yes Director FQDN Pool FQDN Yes Director FQDN

Yes Yes Expanded Enterprise Pool Yes Yes Yes

Pool FQDN Pool FQDN Director FQDN Director FQDN

Note: For an Enterprise Pool, the Subject Alternative Name (SAN) should include a entry for each supported SIP domain in the format sip.<domain> if you selected either of these options when creating the pool with the Configure Pool Wizard: 1) Configure Clients for Automatic Sign-In, or 2) Configure this pool to redirect sign-in requests. If you have multiple SIP domains and use the OCS certificate wizard, it will automatically add sip.domain.com to the SAN for all supported SIP domains. In August 2009, Microsoft released an excellent white paper clearly describing the certificate requirements for OCS: Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2 (the link refers to a collection of OCS documentation scroll down to find the OCS 2007 R2 Deploying Certificates.doc ). InsideOCS has a free download tool (the Automatic Sign-In Troubleshooting Tool) that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used. For more details all the automatic sign-in process and it s requirements, see:

y DNS Records and Office Communicator Automatic Client Sign-In Automatic Office Communicator Sign-In (Part 1 The Correct DNS Service Location (SRV) Record) y Automatic Office Communicator Sign-In (Part 3 ensuring the client trusts the issuing Certificate Authority)
Share and Enjoy:

y y y y y y y y y September 14th, 2008 | Tags: automatic sign-in, communicator login, ocs login, SAN, SN, Subject Name, TCP, TLS, _sip.domain.com | Category: DNS, Deployment, Pools, Uncategorized

Automatic Office Communicator Sign-In (Part 3 ensuring the client trusts the issuing Certificate Authority)
In my previous two posts (Communicator Automatic Sign-In Part 1 and Part 2) I explored two common pitfalls to make Office Communicator 2007 Automatic Sign-In work with OCS 2007. In this post I explain one last hurdle: ensuring that the client trusts the Certificate Authority (CA) that issued the certificate used on the OCS 2007 server. If the Office Communicator client does not trust the CA that issued the certificate, an error will be displayed on sign-in: There was a problem verifying the certificate from the server .

This is often an issue in environments that employ self-signed certificates - especially if the Communicator client is being used in a different AD forest that the issuing CA (e.g. lab environments). A self-signed certificate is a certificate issued by a Certificate Authority (CA) that is generally not well known (e.g. listed as one of the default Certificate Authorities by the major Internet browsers. VeriSign and Entrust are examples of well known CA s). Well known CA s have the advantage of usually being automatically trusted by client computers. You can see the list of trusted CA s by default on most Microsoft Windows operating systems in the Internet Options (open Internet Explorer and navigate to Tools | Internet Options | Content | Certificates). Self-sign certificates can be created, issued, and used in an OCS 2007 environment using Microsoft Certificate Services (http://msdn.microsoft.com/en-us/library/aa376539(VS.85).aspx) which ships with Windows Server 2003 and 2000. During installation, Microsoft Certificate Services is given a name, and all certificates issued by that server are signed-by (the Issued-By field on the certificate) a Certificate Authority with this name. A crucial requirement for Office Communicator clients to work is that the client must trust the CA that issued the certificate being used on the OCS 2007 server the client is connecting to. Trust in this scenario equates to the CA being listed as one of the trusted certificate authorities on the client machine. An easy way to achieve this trust is to import the OCS 2007 server into the client s certificate store. On most Windows clients this can be easily done by doing the following: 1. Export the certificate on the OCS 2007 server (to a file). Remember the password you assigned to the certificate. 2. Make the file available on the client machine. 3. Double-click the certificate file on the client desktop. This will launch the certificate import wizard. 4. After a series of dialogs there are 2 warning dialogs before the import happens. One dialog is warning that you (the client) are about to trust the CA that issued this certificate. The client will now trust all self-signed certificates issued by your CA. Update: in August 2009, Microsoft released an excellent white paper clearly describing the certificate requirements for OCS: Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2 (the link refers to a collection of OCS documentation scroll down to find the OCS 2007 R2 Deploying Certificates.doc ). For more information on other OCS client/server client requirements that need to be met, you can find more information on Page 57 of the Microsoft Office Communications Server 2007 Planning Guide (http://www.microsoft.com/downloads/details.aspx?familyid=723347c6-fa1f-44d8-a7fa8974c3b596f4&displaylang). Note: Microsoft KB article 929395 (http://support.microsoft.com/kb/929395) lists partner companies that provide are certificates that meet the requirements to work with OCS 2007 and Exchange 2007. Inside OCS has a free download tool (the Automatic Sign-In Troubleshooting Tool) to help with the automatic sign-in troubleshooting process. Share and Enjoy:

y y y y y y y y y

September 23rd, 2008 | Tags: Certificate Subject Name, Client Automatic Sign-In Certificate, communicator login, ocs login, Office Communicator Automatic Sign-In | Category: Client, Communicator, Debugging, Deployment