UC Unleashed

In this scenario, IM & Presence would work for some users to federated contacts, but wouldn’t work for others.

Federated User Access was enabled in the Global External Access Policy and in the Global Access Edge Configuration policy. The target domain was in the Federated Domains list as an allowed domain. There was no discernable pattern as to what users could communicate with federated contacts, and what users could not. They were spread across various Front End servers, OUs, etc. Various clients on the workstation made no difference.

When looking at logs in Snooper on the front end that the user connects to, “Federation is disabled” would appear when the user attempted to send a message out:Â

09/16/2011|13:09:13.108 FB8:109C INFO :: SIP/2.0 504 Server time-out
Proxy-Authentication-Info: Kerberos qop=”auth”, opaque=”59715D13″, srand=”DF93B1E9″, snum=”16″, rspauth=”040401ffffffffff0000000000000000450a1d9cc165348ae016ee91″, targetname=”sip/USSFA1L14POOL2.global.mydomain.net”, realm=”SIP Communications Service”, version=4
From: “user, test”<sip:test.user@mydomain.com>;tag=94a0d94c10;epid=67fd7944cb
To: <sip:prichard@federateddomain.com>;tag=6E14486DE28A93804279A401E6E7A4CF
Call-ID: db3c59b759ef4065adb458d54d03a687
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 10.1.1.98:58376;ms-received-port=58376;ms-received-cid=63500
ms-diagnostics: 1065;reason=”Federation is disabled“;domain=”federateddomain.com”;source=”sip.mydomain.com”
Server: RTC/4.0
Content-Length: 0

And traffic for this user would never get to the Access Edge servers. This was the case for ANY federated contacts the “broken” users would attempt to communicate with. Yet, other workers wouldn’t have ANY problem communicating to these same federated contacts. In fact, a “good” user could log onto a test workstation, launch Communicator, and it would work – but then close Communicator and launch Communicator as a “broken” user and not be able to communicate – even from the same Windows session. There was no pattern other than “broken” users would always be broken, and working users would always work.

Many things were inspected, and I tried doing things such as disabling the users in Lync and then re-enabling them. I drain stopped the Front End server that was the user’s preferred server to force them onto another server – no luck.

PSS spent several weeks on this one. Everything was configured correctly. What we decided to try was to set the Minimum session security for NTLM SSP based clients & servers. By default, a Windows 2008 R2 server has both settings set to 128-bit minimum. But Windows XP and earlier clients default to only 40-bit. It didn’t make much sense that this would work since we could duplicate both working and broken users on the same machine. But it was worth a shot. Here’s what we did.

Open the Local Security Policy and navigate to Local Policies>Security Options. Find the Network security: Minimum session security for NTLM SSP based (including secre RPC) clients & servers settings, as shown below:

Minimum session security for NTLM SSP based (including secure RPC) clients

Double click on each and clear the Require 128-bit encrytion checkbox as shown below:

Minimum session security for NTLM SSP based (including secure RPC) clients

The settings should now show “No minimum” in the Local Security Policy as shown below:

Minimum session security for NTLM SSP based (including secure RPC) clients

The settings don’t take effect until the server is rebooted. We performed this process on all of the Lync servers in the environment. Incidentally, the settings just change some registry keys. So we can instead change the values using the following PowerShell lines, which will make their way into my server build scripts:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "NtlmMinClientSec" -Value 0 Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "NtlmMinServerSec" -Value 0

After the servers were rebooted, and user connections reestablished (which took some time), the problem disappeared. All users were able to communicate with federated contacts.