RSS Subscription 168 Posts and 2,769 Comments

Lync 2010 DHCP for Network Communications and PIN/Certificate Authentication

The Lync 2010 Phone Edition requires the usage of DHCP for a couple reasons.  One of these being the ability to function on a network and the other being the ability to sign-in for newer phones that do not support NTLM but will rather utilize certificate based authentication as well as PIN Authentication. The ability to use DHCP options allowing the Lync 2010 Phone Edition to be able to contact the appropriate services in order to sign-in is new in Lync 2010 Phone Edition.

If you take your phone and plug it into your computer, you do not need to go through the DHCP Process to sign-in as it uses your Lync client. If you want to bring your phone home with you, you must go through the DHCP sign-in process at least once to get your phone fully provisioned for certificate based authentication and PIN authentication. Once you have an existing certificate on the phone, that certificate can be used to obtain a new certificate if needed.  Just don’t go put your phone in the closet for months and expect it to still work.  You may end up having to bring it into the enterprise to go through the DHCP Process to obtain a new certificate.

General DHCP Codes Used

General DHCP Options for Phones to Function on a Network

These DHCP Options in Lync Server 2010 also existed in Office Communications Server 2007 R2.  These options include:

  • 015
  • 119

Option 15 is used when you want a connection-specific suffix.  This is typical in a single domain environment.

Option 119 is used when you want to define a domain search list.  This is typical when you have multiple DNS namespaces that you want a phone to be able to search through.

New DHCP Options in Lync 2010 allowing newer Lync 2010 Phone Edition devices to sign-in

These newly provided DHCP Options in Lync Server 2010 allow newer Lync 2010 Phone Edition devices that do not support NTLM Authentication to sign-in.  These options include:

  • 43
  • 120
  • 55

Option 43 is the Lync Server Pool Certificate Provisioning Service URL which utilizes the Web Components FQDN.  A few things to note about this:

  • If using a single server, this will be the typical internal web components FQDN
  • If using a hardware load balanced pool, this will be the Pool FQDN
  • If using DNS load balancing, there are some requirements to override the internal web components FQDN.  This is because DNS Load Balancing works for SIP Traffic.  A hardware load balancer is still required to load balance HTTP and DCOM Traffic. Because of this, your Web Components FQDN will be different and point to a VIP that uses the Hardware Load Balancer.  Because of this, if using DNS Load Balancing, you will want to specify an FQDN that is different from your Pool FQDN.  If using HLB across the board, Option 43 will be the Pool FQDN.
  • Phones such as the new Polycom CX500 and CX600 that do not use NTLM to authenticate will require certificate and PIN authentication to be able to logon.  This means that they will need to be able to contact the Web Components FQDN to request a certificate so they can utilize the certificate to do certificate based authentication.  If they cannot contact the Web Components FQDN at time of sign-in, they will be unable to login.  For example, at the time of sign-in, if you are in a branch office that does not have a pool but does have either an SBA or an SBS, you will obtain option 43 and make a connection attempt to Web Components.  If your WAN link is down or your Central Site that contains your pool is offline, your phone will be unable to retrieve a certificate for certificate based authentication and the phone will not be able to sign-in

Option 120 according to the Technet DHCP documentation for Lync 2010, states Option 120 should point to the Pool FQDN or the Director FQDN.  In a Branch Office scenario, the Technet Documentation states where you have a Survivable Branch Appliance (SBA) or a Survivable Branch Server (SBS), you would have DHCP in those Branch Office subnets provide users with the FQDN of the SBA or SBS so they register to a local server for  Option 120.

Option 55 is used by the device to ask the server for the values of specific options (in our case 120 and 43).

DHCP Server – Regular DHCP Servers and/or Lync DHCP Servers

If you have a DHCP Server that can handle all the above DHCP Option Codes like Windows, then you’re all set. The problem is, not all DHCP Servers can handle all the above requirements. Lync DHCP is a new function in Lync Server 2010 that was not previously provided in previous versions.  For the above codes, not all DHCP Servers will be able to handle these codes.  Microsoft was smart about this and came up with their own Lync DHCP Server which is built into all Lync Registrars.  A Lync Registrar lives on either a Front End Server, SBA, or SBS.  Its job is to listen to DHCP Inform messages that come from a specific type of vendor class client known as MS-UC-Client.  When the Lync DHCP Server sees this vendor class client broadcast DHCP Informs, the Lync DHCP Server will provide the necessary DHCP Option values back to a client allowing these devices to sign into the network.

One important thing to keep in mind, you can utilize Lync DHCP even when there is another DHCP Server servicing that same segment/subnet.  The Lync DHCP Server does NOT participate in the IP acquisition process.  It can live alongside another DHCP Server just fine.  Again, the Lync DHCP Server only listens for DHCP Informs from the MS-UC Client vendor class only and only gives back the necessary Lync specific DHCP Option Values so Lync 2010 Phone Edition can sign into the network.

For the Windows DHCP Server or the Lync DHCP Server, Microsoft created a new tool called DHCPUtil which helps clean existing DHCP Options mentioned above and/or prepare your DHCP Server with these DHCP Option Values.  You can then run a script called DHCPConfigScript.bat that takes the data provided by DHCPUtil and configures your Windows DHCP Server or your Lync DHCP Server.  I will not go into detail about DHCPUtil or DHCPConfigScript.bat in this article.  You can read more on that here.

Sign-in Process Examples

Let’s take a look at two examples:

  • Sign-in Process using a Hardware Load Balanced Pool
  • Sign-in Process using DNS Load Balancing

Sign-in Process using a Hardware Load Balanced Pool

In this example, our Pool is Load Balanced and therefore, just like in Office Communications Server 2007 R2, our Pool Name and our Internal Web Components FQDN can be the same.  Because of this, our Option 43 will point to our Internal Web Components FQDN in our Central Site.  Because we have an SBA in our Branch Site, we will specify Option 120 to include the local Registrar for that branch site.  Our Polycom CX600 would do a DHCP Inform, find the Windows DHCP, find Option 43, contact the Web Components FQDN, get a certificate for mutual authentication, then use Option 120 to contact the local SBA.  If the SBA has a certificate that contains a domain (whether it be in the CN or the SAN of the certificate) that matches the SIP URI of the user attempting to connect, the user will be allowed to connect and all is well.

Sign-in Process using a DNS Load Balanced Pool

In this example, our Pool is DNS Load Balanced which changes the process a little. As stated earlier, DNS Load Balancing is for SIP Only.  We still need a Hardware Load Balancer for DCOM and HTTP.  Therefore, we will have a special FQDN specifically for our Web Components. Everything in the following paragraph is 100% identical to the previous Hardware Load Balancing example.

Our Option 43 will point to our Internal Web Components FQDN in our Central Site.  Because we have an SBA in our Branch Site, we will specify Option 120 to include the local Registrar for that branch site.  Our Polycom CX600 would do a DHCP Inform, find the Windows DHCP, find Option 43, contact the Web Components FQDN, get a certificate for mutual authentication, then use Option 120 to contact the local SBA.  If the SBA has a certificate that contains a domain (whether it be in the CN or the SAN of the certificate) that matches the SIP URI of the user attempting to connect, the user will be allowed to connect and all is well.

Share

13 Responses to “Lync 2010 DHCP for Network Communications and PIN/Certificate Authentication”

  1. […] for Network Communications and PIN/Certificate Authentication: http://www.shudnow.net/2010/11/18/lync-2010-dhcp-for-network-communications-and-pincertificate-authe… […]

  2. […] for Network Communications and PIN/Certificate Authentication: http://www.shudnow.net/2010/11/18/lync-2010-dhcp-for-network-communications-and-pincertificate-authe… […]

  3. on 09 Dec 2010 at 12:33 amEssam

    Is it possible to use Windows Network Load Balancing instead of Hardware Load Balancing?

  4. on 09 Dec 2010 at 7:42 amElan Shudnow

    It's currently not supported by Microsoft.

  5. on 09 Dec 2010 at 4:10 pmEric

    I downloaded Lync 2010 from our licensing site but dhcputil isn't part of the .iso…was this removed in RTM or put somewhere else?

  6. on 11 Dec 2010 at 9:41 amElan Shudnow

    On the installed server:
    C:\Program Files\Common Files\Microsoft Lync Server 2010

  7. on 13 Dec 2010 at 1:51 amAhsan Khan

    Dear Elan,

    I need your help to clear my concepts on Lync Enterprise Voice, I have deployed Lync 2010 STD Edition and IM,Conf and Aud/Vid everything is working fine. Even i am using Polycom phone and it can call to other Polycom phone also.

    When i am configuring line URI in user's properties and i am testing the calls using Extension no like From 4120 To 4121 it is not working. Even i have created a normalization rule for internal calls and it is successfully normalizing the extension no to E164 format.

    You are requested to explain that whether a Gateway is required to call internal extensions (4120 to 4121) or it should work without a media gateway? The users who have these extensions they are enabled for Enterprise voice.

    Please reply me as soon as possible so i should be able to fix the issue.

    Regards,

    Ahsan

  8. on 14 Dec 2010 at 4:54 pmElan Shudnow

    There is something called User Services that live on the Front End. If you call an internal user and that normalized # matches a user's TEL URI, the call will stay on the Front End and will call that user's Lync Endpoints. When a normalized number does not match a user's TEL URI, it will pass user services, go to the Mediation, get converted to G.711, and get sent to the gateway.

  9. on 10 Jan 2011 at 5:49 pmChristian

    Hi Elan,

    i´m right i can´t use lync phones without the dhcp options?
    What about user who want to use the phones at home?
    All the setting have to come "autodiscoverd?" is no other way possible?
    Using AAstra phone´s

    Do you plan some documentation about enabling calendar feature for the phones?

    Great Blog!
    Regards Christian

  10. on 13 Jan 2011 at 4:30 amDeon

    Hi Elan,

    Is the DHCPUtil.exe tool supported on Windows Sevrer 2003?

    Get an error saying: "The image file DHCPUtil.exe is valid but is for a machine type otherother than the current machine.

    Kind Regards,
    Deon

  11. on 31 Jan 2011 at 11:39 amElan Shudnow

    Deon, when running DHCPUtil, it gives you 2 options. #1 is to run DHCP with the ability to run the configuration script directly. #2 is output you can run from the command line directly without the need for DHCPUtil. #2 will work for you.

  12. […] for Network Communications and PIN/Certificate Authentication: http://www.shudnow.net/2010/11/18/lync-2010-dhcp-for-network-communications-and-pincertificate-authe… […]

  13. […] DHCP for Network Communications and PIN/Certificate Authentication: http://www.shudnow.net/2010/11/18/lync-2010-dhcp-for-network-communications-and-pincertificate-authe… […]

Trackback this post | Feed on Comments to this post

Leave a Reply