See Also
Topic Last Modified: 2011-02-10
In Microsoft Lync 2010, there are three possible authentication methods. The method that you use depends on the device type, and on what the administrator has set up on Web Services. Polycom CX600 and Aastra 6725ip, devices support personal identification numbers (PINs) and certificate authentication, Polycom CX700 support NTLM and certificate authentication.
By enabling the Web Services certificate and PIN authentication methods on the Polycom CX600 and Aastra 6725ip, and on the Polycom CX 700 devices, you can connect to Microsoft Lync Server 2010. If certificate authentication is disabled on Web Services, Polycom CX600 and Aastra 6725ip devices cannot work unless you pair them with a computer to enter credentials, but Polycom CX700 will continue to connect externally and internally. If PIN authentication is disabled, on the Polycom CX600 and Aastra 6725ip will not work, but Polycom CX700 will continue to function.
Additionally, there are supported authentication methods on the Registrar policy. In this case, if certificate authentication is disabled, Polycom CX600, CX500 and Aastra 6725ip, 6721ip devices will not work at all. Polycom CX700 still functions because it uses NTLM to authenticate.
The device sends user credentials to Web Services as part of an authentication request. In the case of NTLM authentication, the credentials are the domain user name and password. In the case of PIN authentication, the credentials are the phone number and the PIN. In both cases, the client’s Lync certificate, which is obtained in the previous step, is used to negotiate the security of the communication channel for all subsequent communications.
 Note: |
|---|
| If two users enter the same phone number, their PIN is used to disambiguate them. If a phone number + PIN pairing is not unique, the phone number and extension is used to disambiguate. Phone number + extension must always be unique. This scenario might occur when the PIN is first set, rather than during authentication, however, it is worth understanding in the context of PIN authentication. |
Issue 1: User’s Account Is
Locked (Applies to Polycom CX 600 and Aastra 6725ip)
Issue: The maximum number of attempts have been made to authenticate using incorrect PIN for the user. The number of retries that are allowed is set in the PIN policy for the site or the user.
Resolution: After the user has incorrectly entered her PIN more than the number of allowed retries, the account can only be unlocked by an administrator on the Lync Server. An administrator can unlock the account for that user by using Microsoft Lync Server 2010 Control Panel. To do this, connect to the Lync Server 2010 Control Panel. If the administrator is not a member of a Lync Server 2010 administrative role, the administrator cannot connect In Lync Server 2010 Control Panel, click User, and then type the user's name in the search field. In the search results, double-click the user to view the user's settings, and then reset the user's PIN.
Alternately, the user can reset her PIN on the Dial-in Conferencing Settings webpage. To open the Dial-in conferencing Settings webpage, do one of the following:
- In the Microsoft Outlook messaging and collaboration client,
click Conferencing item and then click Dial-in
Settings.
- In Lync 2010, click Menu, click Tools, and then
click Dial-in Settings.
- In a meeting invitation, click Find a Local Number or
Forgot your dial-in PIN.
After the user resets the PIN, the user can reenter the correct PIN on the device and authentication continues.
Issue 2: PIN has expired
(Applies to Polycom CX 600 and Aastra 6725ip)
Issue: The PIN for the user’s account has expired. PIN expiration is set in the PIN policy for the site the user is homed on or for a specific user.
Resolution: PIN expiration is one of the attributes of the PIN policy assigned to the site or user. To determine what the PIN policy is for the user, you need to log on as a member of a Lync Server 2010 administrative role. For details, see Role-Based Access Control in the Planning documentation. First, connect to the Lync Server 2010 Control Panel. If the administrator is not a member of a Lync Server 2010 administrative role, the administrator cannot connect.
If the PIN has expired, reset the user’s PIN. In Lync Server 2010 Control Panel, click User, and then type the user's name in the search field. In the search results, double-click the user to view the user's settings, and then reset the user's PIN.
Alternately, users can reset their PIN on the Dial-in Conferencing Settings webpage. To open the Dial-in Conferencing Settings webpage, do one of the following:
- In the Microsoft Outlook messaging and collaboration client,
click Conferencing item and then click Dial-in
Settings.
- In Lync 2010, click Menu, click Tools, and then
click Dial-in Settings.
- In a meeting invitation, click Find a Local Number or
Forgot your dial-in PIN.
After the PIN is reset, the user can reenter the correct PIN on the device and authentication continues.
Issue 3: User doesn’t have a PIN
(Applies to Polycom CX 600 and Aastra 6725ip)
Issue: The user does not have a PIN that the user can use to authenticate.
Resolution: Create a PIN for the user. To do this, connect to the Lync Server 2010 Control Panel. If the administrator is not a member of a Lync Server 2010 administrative role, the administrator cannot be able to connect.
In Lync Server 2010 Control Panel, click User, and then type the user name in the search field. In the search results, double-click the user to view the user's settings, and set the user's PIN.
Alternately, the user can set his PIN on the Dial-in Conferencing Setting webpage. To open the Dial-in Conferencing Settings webpage, do one of the following:
- In the Microsoft Outlook messaging and collaboration client,
click Conferencing item and then click Dial-in
Settings.
- In Lync 2010, click Menu, click Tools, and then
click Dial-in Settings.
- In a meeting invitation, click Find a Local Number or
Forgot your dial-in PIN.
After the PIN is reset, the user can reenter the correct PIN on the device and authentication continues. You can provide the new PIN to the user (for example, in an email message). After the user has received his new PIN, he enters this value along with his phone number into the device and then he can authenticate.
Issue 4: Ambiguous Phone Number.
(Applies to Polycom CX 600 and Aastra 6725ip)
Issue: The phone number entered by the user on the device is not unique or cannot be attributed to a specific user.
Resolution: Reset the phone number for the user. To do this, connect to the Lync Server 2010 Control Panel. If the administrator is not a member of a Lync Server 2010 administrative role, the administrator cannot connect.
In Lync Server 2010 Control Panel, click User, and then type the user's name in the search field. In the search results, double-click the user's name to view the user's settings, and they type the new phone number in the Line URI field. To save your changes, click Commit. Send the new phone number to the user. After the user has received the new phone number, the user should enter this value, along with a PIN, into the device and be able to authenticate.
| Note: |
|---|
| If two users enter the same phone number, their PINs are used to disambiguate them. If a phone number + PIN pairing is not unique, the phone number and extension are used to disambiguate. Phone number + extension must always be unique. |
Issue 5: Multiple Devices Are
Having Problems with PIN Authentication (Applies to Polycom CX 600
and Aastra 6725ip)
Issue: This indicates a problem on the server side, rather than with a specific user. To determine the source of the problem, open the Lync Server Management Shell and run the test-OcsAuth cmdlet. Only an administrator with the CsVoiceAdministrator role or the CsAdministrator role have sufficient administrator rights and permissions to run the test-OcsAuth cmdlet. For details about the Lync Server 2010 administrative roles, see Role-Based Access Control in the Planning documentation.
Resolution: Run the following synthetic transaction:
 Copy Code |
|
|---|---|
$cred = get-credential test-CsClientAuth -UserSipAddress <SIP address> -UserCredential $cred -TargetFQDN |
|
Do not specify TargetFQDN if you want DHCP discovery to be used. If not, provide the destination FQDN into the synthetic transaction and DHCP discovery will be bypassed.
The output shows you at what point authentication failed. For example, the DHCP discovery message might not receive a response. Follow the directions in the transaction output to resolve the problem.
Issue 6: User Cannot Sign In to
Lync Server
Issue: A user enters their valid credentials (whether the use a PIN and phone number on a Polycom CX600, CX500 and Aastra 6725ip, 6721ip, or a domain user name and password on Polycom CX700 ), however, Lync is unable to sign in the user. The user is not enabled for unified communications (UC). The device displays a message similar to the following: "Cannot sign in. Your sign-in address is incorrect or your account is not set up."
Resolution: Enable the user for Lync Server. To do this, open to the Lync Server 2010 Control Panel. If the administrator is not a member of a Lync Server 2010 administrative role, the administrator cannot connect.
In Lync Server 2010 Control Panel, click User, and then type the user name in the search field. In the search results, double-click the user to view the user's settings, and then select the Enabled for Lync Server check box. Under Telephony, select Enterprise Voice and then type the user’s phone number in the Line URI field. If necessary, change the user's dial plan policy. To save your changes, click Commit.
When the user reenter her credentials into the device, she can authenticate and log on again. This time the user is able to log on to Lync Server.
Issue 7: Certificate Publication
Fails
Issue: The get-and-publish request for the user’s certificate can fail if the Registrar is unable to publish the user’s certificate to User Services. The device will not receive the user’s certificate, and the user will not be able to log on and must start again.
Resolution: Verify that Web Services is able to generate and publish a certificate for the user, by running the following synthetic transaction:
| Copy Code |
|
|---|---|
$cred = get-credential test-CsClientAuth -UserSipAddress <sip address> -UserCredential $cred -TargetFQDN |
|
If you want to use DHCP discovery, do not specify TargetFQDN. If you do not want to use DHCP discovery, provide the destination FQDN in the synthetic transaction and DHCP discovery will be bypassed.
The output shows you at what point authentication failed. For example, the DHCP discovery message might not receive a response. To resolve the problem, follow the directions in the transaction output.
If this succeeds, restart the device and have the user try to authenticate again. If it fails, resolve the problem indicated.