Now clearly the title of this article is a bit misleading as you cannot authenticate and sign-in to the Lync registrar using an Active Directory user account which is disabled.  But the scenario often exists where a SIP client may need to register as a disabled account.  For example the native registration of a Polycom HDX UC endpoint located in a conference room would often be tied to an existing Meeting Room mailbox defined in Exchange Server.  But as Exchange Server resource mailboxes by default are AD-disabled user accounts then the credentials of that account cannot be used to register to Lync Server.

The easiest approach is to simply re-enable the user account and set a password on it.  Although this account will still continue to function correctly Microsoft does not recommend those accounts to be re-enabled.  A solution that requires more administrative effort is to just create a new AD account for every endpoint which needs to sign-in to Lync Server and just use separate accounts for Exchange and Lync on each endpoint.

An alternative approach is to create a single ‘master’ AD user account which will be used to authenticate to the Lync registrar on all endpoints yet the unique SIP URI of each disabled account (resource mailbox) will still be used.  This one-to-many approach allows all endpoints to register as the unique meeting room account, yet a single set of credentials can be used.

The use case scenario shown in this article covers the configuration of a Polycom HDX 4000 UC endpoint to Exchange Server 2010 SP1 for Calendaring integration and Lync Server 2010 for SIP registration.  Although this approach is not technically supported by Microsoft it does work in OCS and Lync 2010 environments.

In order to sign-in with the SIP URI of one account, yet pass the credentials of another account the primary account must first trust the secondary account to allow this.  In Exchange the ‘master’ account is simply granted Full Access rights to the mailbox using either the Exchange server Management Console or Shell.  In OCS/Lync Server the steps are a bit more complex and require manually editing the source account in ADSIedit.

Update (April 2014): Lync 2013 no longer allows this one-to-many configuration as when multiple users attempt to sign-in to a Lync 2013 registrar using the same AD account for authentication then connectivity to Lync web services will fail for the additional users, reporting the following error in the logs:

X-Ms-diagnostics: 28064;source=”<FE-FQDN>;reason=”Multiple users found in AD for given PUID/SID.”\

Lync 2013 will allow unique authentication accounts to be defined for each Lync account in a 1:1 fashion, which does not really accomplish anything.  As Microsoft already supports enabling Exchange resource accounts for authentication on platforms like Lync Room System then using the same approach for other Lync clients and endpoints also works fine.

SIP Registration

This scenario uses an existing disabled user account named "’Chicago HDX4000’ which is mailbox-enabled using the SMTP address of chihdx4000@mslync.net and is Lync-enabled with the SIP URI of chihdx4000@mslync.net.  The exact same steps can be used on OCS 2007 and 2007 R2 deployments as well as Lync (which is the primary focus of this article).

Delegate Permissions

• Create a new ‘master’ user account in Active Directory (e.g. hdxsa@schertz.local).  This account is used only for authentication and should not be enabled in either Exchange or Lync server.

• Using either ADSIedit or the Attributes tab in Active Directory Users and Computers locate the objectSid attribute on the new ‘master’ account.

• Edit the attribute and copy the contents of the hexadecimal data on to the clipboard.

• Still using ADSIedit or the Attributes tab find one of the existing user accounts configured as an Exchange resource mailbox (e.g. Chicago HDX4000) and the locate the msRTCSIP-OriginatorSid attribute on the disabled user account.

• Edit the attribute and paste in the copied string (which is the objectSid of the master account) into the msRTCSIP-OriginatorSid attribute.  This will grant the master account the ability to authenticate to the Lync Server when the SIP URI of this account is used to sign-in.

Configure Endpoint

• On the HDX Admin Settings page browse to Network > IP Network and then Enable SIP.  Select TLS as the Transport Protocol and enter the Lync Server/Pool FQDN (e.g. lync.schertz.local) in for both the Proxy Server and Directory.
• The User Name field should contain the SIP URI of the AD-disabled, Lync-enabled account.
• The Domain User Name should contain the Universal Principal Name (UPN) of the new master account.

• From the Diagnostic menu on the HDX go to System Status and validate that the SIP Registrar Server status is shown as a green arrow.  Click on the link to display the registration status, as see below.

• Once registered, presence of the HDX can be seen and video calls placed directly to it from any Lync client.  The screenshot below shows me placing a video call from a Lync client on a laptop to my HDX on the other side of the room which was configured for auto-answer.

Calendar Integration

These optional steps are for setting up the additional Calendar Service integration and not required for basic SIP registration.

Delegate Permissions

• Using the Exchange Server Management Console select the resource mailbox and then grant Full Access rights to the new ‘master’ user account (e.g. SCHERTZ\hdxsa).

• Alternatively use the Exchange Server Management Shell to issue the following cmdlet to perform the same procedure.

Add-MailboxPermission -Identity ‘CN=Chicago HDX4000,OU=Resource Mailboxes,OU=JDS,DC=schertz,DC=local’ -User ‘SCHERTZ\hdxsa’ -AccessRights ‘FullAccess’

Configure Endpoint

• On the HDX Admin Settings page browse to Global Services > Calendaring Service and then Enable Calendaring Service.  Enter the FQDN of the Exchange Client Access Server in the Microsoft Exchange Server Address field (e.g. exch.schertz.local).
• The Domain field should contain the Active Directory NETBIOS domain name.
• The User Name field should contain the sAMAccountName of the new ‘master’ account.
• The Maibox field should contain the SMTP address of the AD-disabled, Exchange-enabled account.