It seems to be a day for writing about auto-discovery, the process whereby an application, in this case Microsoft Office Communicator (MOC), can use a limited amount of information to automatically discover the users’s OCS Server. Auto-discovery is based on MOC’s use of DNS resource records to obtain the necessary information. I’ve been reading the formal published specificatin in the absence of bed-time cocoa. Note that this mechanism is used by a MOC client to find an OCS server, and is different from Exchange’s auto-discovery service that enables Outlook to find an Exchange server. The OCS mechanism is simple and easy, while the Exchange service is more complex.
Using auto-discovery, MOC first obtains what the specificatin calls the Address-of-Record, aka the SIP URI. This could be something like sip:tfl@gktrain.net. From the AOR, MOC needs to determine a target domain (the spec just calls this domain). In this case, gktrain.net is the target domain.
The SIP URI has to obtained through user input. The user inputs his SIP URI (minus the “SIP:” scheme id, as well as AD credentials (in most cases these are the same, a UPN such as tfl@gktrain.net).
For fun, here’s a PowerShell script to get and display the target domain from the AOR
# Get-DomainFromAor.ps1# gets the domain from the AOR and displays result# Thomas Lee – tfl@psp.co.uk# Specfy an AOR$AOR = “sip:tfl@gktrain.net”# Get target domain$domain = ($aor.split(“@”))[1]# Display results“AOR : {0}” -f $aor“Target Domain : {0}” -f $domain
Having discovered the target domain, MOC’s auto-discovery then synthesises a series of DNS queries, and sends these to the local DNS server – one at a time until a successful query result is obtained (or not). If a query is successful, then the information in that query is used to find the user’s OCS server. If no query is successful MOC can log the user in.
As an alternative to auto-discovery, of course, the user can enter the server details manually. In that case, MOC used the manually entered information and does not attempt auto-discovery. To simplify the user experience, and reduce support costs, you should implement DNS-based auto-discovery.
There are two types of synthetic DNS queries that are used by MOC: synthetic SRV record queries and synthetic A record queries. Synthetic SRV records search for an SRV resource record that in turn points to the A record. Together the SRV and associated A record specify the IP address and port number that MOC uses to connect to an OCS Server for the target domain. Synthetic A record queries look for an A record that has the IP address of an OCS Server. MOC uses this address, plus a specific per-query port number to attempt the connection to an OCS Server for the target domain.
The MOC auto-discovery mechanism attempts the SRV queries first, and the A record queries next in an attempt to find an OCS Server. For clients conneting inside the organisation, the discovery should take just one query (and response). For external clients, e.g. connecting from the internet via OCS Edge services, there will be more.
The specific order that queries are conduced are as described below.
Order of Synthetic DNS queriesAs noted, Synthetic SRV queries are attempted first. If these are not successful, the synthetic A record queries are used. Here is the order:
(SRV Queries first)
If this query is successful, DNS returns one or more SRV resource each with an associated A record. MOC uses the first SRV record, and it’s associated A record. Both DNS round robin and SRV Record priority settings are be used to semi-randomise or to bias the order the SRV records are used. MOC takes the host name and port contained in the returned SRV record and the IP address specified in the associated A record to attempt to negotiate a SIP over TLS (over TCP) connection with OCS.
If this query is successful, DNS returns one or more SRV records and an associated A records MOC uses the host name and port contained in the the SRV record and the IP address specified in the associated A record.MOC uses the first SRV record, and it’s associated A record.Both DNS round robin and SRV Record priority settings are be used to semi-randomise or to bias the order the SRV records are used. MOC takes the host name and port contained in the returned SRV record and the IP address specified in the associated A record to attempt to negotiate a SIP over TCP (i.e. insecure) connection with OCS.
If this query is successful, then the steps shown for query 1 above are taken and a TLS connection is attempted.
If this query is successful, then the steps shown for query 2 above are taken and a TCP connection is attempted.
(A Record Queries next)
If this query is successful, then the MOC Client attempts a TLS connection to the IP Address specified in the returned A record, over port 443.
If this query is successful, then the MOC Client attempts a TCP connection to the IP Address specified in the returned A record. NB: The formal spec does not specify a port number, but it is believed the connection attempted is over port 5060. Cites pro/con and corrections are most welcome.
If this query is successful, then the MOC Client attempts a TLS connection as per query 5.
If this query is successful, then the MOC Client attempts a TCP connection as noted in query 6 (with same note).
If this query is successful, then the MOC Client attempts a TLS connection as per query 5.
As I noted, the client first tries to complete the SRV record queries. The client uses the queries in the order shown above to attempt to construct a list of candidate servers and once this list is complete, it begins attempting a connection. If queries 1 and 3 (TLS) above are completed and are successful before query 2 (TCP), then the client adds the TLS entries from both queries and ignores the TCP entries. If query 2 completes first, MOC waits till query 1 and 3 complete before moving on.
One potential security risk is DNS Poisoning, for example by a hacker returning a ‘bad’ SRV record (ie pointing to a rogue server). The MOC client ignores responses whose domain/subdomain is different from the calculated domain. Thus if a query returned an record pointing to a server called ocs.fakedomain.com MOC would ignore it.
After getting the results of the SRV queries, the client will move on to the A record queries. As a general rule, SRV records are used for internal clients, while A records are used for external clients. BUT: given this is DNS, you can use some, any or all of these various records as you choose (or indeed none of them and use manual configuration).
A final note for larger enterprises. If you have a large enterprise, you may have multiple pools and therefore multiple SRV or A records are returned. In this case, MOC’s list of servers to try are dictated by the order the RR’s are returned and the first record might be a valid OCS server, but the user is not homed on that server. OCS handles this via the director function and can re-direct the client to the users’s correct home server. The director function is separate and independent to the auto-discover mechanism
Best Practices
The best practices I can recommend are:
Troubleshooting
Troubleshooting OCS auto-discovery is for the most part simple – ensure you have the correct records are in DNS and that these are properly configured.
Some things to look out for:
You can use the client’s event log to see failed DNS queries – this shows AOR problems when you see a lot of records missing in the event log. It can also mean that the SRV records are missing or incorrectly specified.
If I get the time, I might try to write a PowerShell script to construct the synthetic queries, execute them and report on what’s found. Had enough yet? 🙂
(Borrowed from a post by Thomas Lee: http://tfl09.blogspot.com/)