Although not the first on this topic this article does contain a more comprehensive and detailed explanation of exactly how Option 43 is formatted and utilized, and is designed to assist in the configuration of any third-party DHCP service which supports the vendor-specific Option 43.  The following articles and documentation are all suggested reading when dealing with configuring Option 43 for use with Lync Server 2010 deployments.

• Configuring Lync Server for Phone Edition Devices
• Configuring DHCP Options to Enable Sign-in for IP Phones (Microsoft TechNet)
  • Appendix: Configuring DHCP Options on DHCP Servers other than Windows DHCP Server
• Configuring Lync DHCP using Cisco DHCP Servers (VLAN and PIN Auth) (Elan Shudow)
• Configuring DHCP Options on DHCP Servers other than Windows DHCP Server (Microsoft White Paper)

Note that DHCP Option 120 will not be discussed specifically in this article but the concepts covered do apply to the formatting and usage of Option 120 in the same way.  This is an industry standard SIP server option (see RFC 3361) which is not vendor specific and simply advertises the IP address or the Fully Qualified Domain Name (FQDN) of the SIP Registrar dedicated to handling registration requests for clients and devices on the network.  Lync Server specifically requires that the parameter is an FQDN as TLS connectivity requires the use of domain names (IP addresses are not supported by Lync for this option).

Background

Lync Server 2010 introduced the usage of DHCP Option 43 which is used to provide clients and devices on a network the ability to locate the Lync Server’s Certificate Provisioning service, and thus automatically download a certificate required to support secure HTTPS and TLS communications for the remainder of the session. Typically this new Option 43 is equated to the PIN Authentication feature provided in the Lync Phone Edition client written for the Aries family of devices, but it is not used solely for that purpose.  For example other qualified clients and devices can use this option to download the Root certificate even if PIN Authentication is not supported on that specific client.

Previously the only way a device or client could download a root certificate in order to trust the issuing CA of an OCS Registrar was by leveraging LDAP access to Active Directory.  When an Enterprise Windows CA is deployed the root certificate (and any issuing subordinate CAs certificates in the chain) are automatically placed into Active Directory and thus any domain-joined workstations will automatically have been provisioned the certificate(s) and the trust would already have been established. Also non-domain joined systems can leverage LDAP access to AD to download these CA certificate(s) as well.  In the case that a Standalone Windows CA is deployed then the certificate(s) are not placed into AD by default and must be done so manually.  Anyone who has ever attempted to get a Tanjay device to work on Office Communications Server on a network where a Windows Enterprise Certificate Authority was not deployed should be familiar with the process of manually importing Root (and possibly subordinate) CA certificates into Active Directory.

But with Lync Server there is now the CertProv web service included on the Front End (and Director) server which can facilitate the process of handing out any subordinate and/or root CA certificates.  The addition of DHCP Option 43 allows native Lync clients and any other Lync qualified devices or clients which are aware of this option the ability to perform this automatic provisioning process to build a secure TLS connection with the server and move on to registration and authentication steps.  In the LDAP process the older clients can query an LDAP server (Active Directory in this case) for the Certification Authority objectCategory and then be passed the root certificate.

Certificate Download

Now to take a peak at the Certificate Provisioning process provided by the Lync Web Services.  During the initial provisioning the client utilizes DHCP Option 43 to identify the full URL of the Certificate Provisioning service and opens a clear-text HTTP 80 connection to the web server.  This is the reason that Lync Phone Edition devices must be able to connect to the internal Lync web services over port 80 as well as 443.  (When a device is external the root certificate should already be trusted as in almost all cases the Access Edge Service should be equipped with a trusted public certificate.)

In the HTTP 200 OK response the message contains the entire Root CA certificate in PKCS #7 Base-64 format.

To validate that the provided certificate is actually the correct certificate the chain data can be decoded and verified using a few simple steps.  (As Wireshark is used in this example then these steps to export the raw data are specific to that application, but other network capture utilities also provide their own methods for copying or exporting the raw text.)

• Highlight the certificate data in the bottom window as shown in the previous screenshot and then select File > Export > Selected Packet Bytes and then save the file.
• Open the saved file in a text editor and select and copy the entire string.
• Paste the string into a certificate decoder (e.g. http://certlogik.com/decoder) and decode the data.  Notice that the Issuer and Subject fields should be the same value, indicating that this is a self-signed certificate.  It was issued by a certificate authority as inferred by the inclusion of the description “RootCA”’ in the Common Name.

Disassembling Option 43

A few of the related articles provided at the beginning were created to specifically address how to configure DHCP services which are not Windows DHCP, but they do not go into the deeper level of detail to explain the formatting of the parameters.  Understanding this clearly is key to formatting the information correctly for use with any type of DHCP service.  Since Option 43 is actually comprised of multiple sub-options some systems might ask for the individual parameters separately during configuration while other systems may require all values to be concatenated into a single string.  As each value is appended with a header to provide option and parameters length details it can be difficult to properly configure.

The first step is to fine out what the exact values are for a specific Lync Server deployment.

• From the Windows Command Prompt on the Lync Front End Server execute the DHCPUtil utility with the following switches to simply print out to the screen the resulting sub-option parameters required by the Lync Server.  The SipServer parameter should be defined as the FQDN of the Lync Front End Server.

“%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPUtil.exe” -SipServer  lync.schertz.local

Executing the above command will not impact any current DHCP configuration so it is safe to perform this simply to view the required parameters even if it has already been configured and is only being run as a learning exercise to follow along with this article.

If multiple Lync servers are deployed in the environment then the SipServer parameter may need to be defined as a Lync Pool FQDN (in the case of an Enterprise Edition deployment).  Additionally if any load balancing is configured on the Front End pool and the Internal Web Services FQDN is different than the Pool FQDN (in the case of DNS Load Balancing) then an additional switch of WebServer needs to be used to provide the Web Services FQDN.  If the WebServer swtich is not provided the command uses the SipServer value by default for both the registrar and web services location.

Additionally if a Director Server or Pool is in place then the Director FQDN is typically defined as the SipServer parameter (and the WebServer parameter is not needed).

The following table captures the output from the utility including the hexadecimal strings for each sub-option.

To understand what these values actually represent then the strings should be converted from hexadecimal to ASCII text.  Sub-Option 2 will be used in this example as it is a simple string which should be identical in every deployment..

• Reformat the hexadecimal value in groupings of two digits to facilitate easier reading of the string and to highlight the fact that each set of digits is part is a single hexadecimal value.  So this 10-character string is actually 5 unique hexadecimal values.

6874747073 = 68:74:74:70:73

• Using an ASCII character chart locate the hexadecimal value of the first grouping (e.g. “68”) and identify the resulting ASCII character for that value (e.g. “h”).

• Look up the remaining hexadecimal values in the string to convert the entire string into a readable ASCII string.

HEX = ASCII

68 = h
74 = t
74 = t
70 = p
73 = s

• So the output hexadecimal string of “6874747073” converted to ASCII is “https” which defines the URL Scheme.

Clearly this process could take considerable time to piece together the remaining sub-option values, so how that the process is understood a convertor can be used on the other values.

• By utilizing a Hex to ASCII Converter each sub-option string can be quickly decoded into plain English one at a time.

The resulting conversions should look nearly identical to the examples below, with traditionally only sub-option 3 being different as it should match the unique Lync Server FQDN in the specific environment.  Technically it is possible for sub-options 2, 4, and 5 to be different than the examples but rarely if ever are the defaults changed for the Lync certificate provisioning service URL, port, or security type values.

4D532D55432D436C69656E74 = “MS-UC-Client”

6874747073= “https”

6C796E632E7363686572747A2E6C6F63616C= “lync.schertz.local”

343433 = “443”

2F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663 = “/CertProv/CertProvisioningService.svc”

An important concept to understand is that every single ASCII character is represented by a unique two-digit hexadecimal code, so if a specific hexadecimal string happens to be 24 characters long (e.g. “4D532D55432D436C69656E74”) then the actual ASCII string would be exactly half of that value, or 12 characters (e.g. “MS-UC-Client”).  The importance of this will become clear in a later step when these values are concatenated into a single string.

To see the configuration in action the following trace shows the data provided by the DHCP server in a reply to the client’s INFORM request with each of the sub-options listed under VendorSpecificInformation – Type 43.

The highlighted text is the entire set of DHCP parameters concatenated in a single string complete with header information.  Both the hexadecimal and ASCII data is listed in the

2B 5A 01 0C 4D 53 2D 55 43 2D 43 6C 69 65 6E 74 02 05 68 74 74 70 73 03 12 6C 79 6E 63 2E 73 63 68 65 72 74 7A 2E 6C 6F 63 61 6C 04 03 34 34 33 05 25 2F 43 65 72 74 50 72 6F 76 2F 43 65 72 74 50 72 6F 76 69 73 69 6F 6E 69 6E 67 53 65 72 76 69 63 65 2E 73 76 63 DC 03 4E 41 50

+Z..MS-UC-Client..https..lync.schertz.local..443.%/CertProv/CertProvisioningService.svcÜ.NAP

Taking a closer look at the hexadecimal string the individual sub-option strings can be identified with additional data in between each value.  Each sub-option is represented by a grouping which includes a 2-bit header.

• The first value in the header highlighted in green indicates the Sub-Option (e.g. 0x01)
• The second value highlighted in orange indicates the Length of the sub-options value (e.g. 0x0C = 12)
• The third value highlighted in yellow is the Parameter Value  itself (e.g. 4D532D55432D436C69656E74)

2B 5A 01 0C 4D 53 2D 55 43 2D 43 6C 69 65 6E 74 02 05 68 74 74 70 73 03 12 6C 79 6E 63 2E 73 63 68 65 72 74 7A 2E 6C 6F 63 61 6C 04 03 34 34 33 05 25 2F 43 65 72 74 50 72 6F 76 2F 43 65 72 74 50 72 6F 76 69 73 69 6F 6E 69 6E 67 53 65 72 76 69 63 65 2E 73 76 63 DC 03 4E 41 50

As previously mentioned the Length is actually the amount of individual ASCII digits, or individual hexadecimal values which are represented by pairs of digits.  So either count the number of hexadecimal groupings or simply divide the total number of characters by two; either approach will result the in the correct value for the parameter’s length.

4D532D55432D436C69656E74 = 24 characters / 2 = 12 hexadecimal values

4D:53:2D:55:43:2D:43:6C:69:65:6E:74 = 12 hexadecimal values

12 decimal = 0C hexadecimal

And as noted before only sub-option 3 will typically be different between Lync Server environments, so when setting the values manually for any third-party DHCP server solution make sure to pay close attention to the length as the Web Server FQDN will vary between deployments.  The rest of the sub-options should match the example above exactly.

As for the few unmentioned values at the beginning and end of the captured string the leading 2B and 5A values represent the DHCP Option number of 43 (2B hexadecimal = 43 decimal) and the length of the entire Vendor Specific parameter (5A hexadecimal = 90 decimal).  And the trailing data (DC 03 4E 41 50) is part of Sub-Option 220 which defines DHCP NAP information and is unrelated to Lync.

It should now be quite evident that if the proper Length value is not defined when setting these parameters then clients would be unable to properly locate the beginning and end of each sub-option’s data string, and devices would fail to locate the Certificate Provisioning web service.