Issue with Remote User Access for Clients using Windows XP and Windows 2008 R2 Front Ends

I was helping to troubleshoot an issue where users were unable to login via Remote User Access using the Edge server.  They were able to successfully login from inside the network, but externally, the client would come back with an error.  We made sure that the user account was enabled for Remote User Access and that they were able to successfully telnet to the Access Edge server.  We took SIPStack logging on the front-end and found a couple interesting error messages when the client tried to login.

The first error listed below is complaining about failing to be able to validate the user's credentials against Active Directory and the second is the SIP error message that is returned to the client.  It's a 401 Unauthorized with an error code 0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED).

TL_ERROR(TF_SECURITY) [8]0D04.12B4::09/28/2010-22:33:22.019.0006247e (SIPStack,SIPAdminLog::WriteSecurityEvent:SIPAdminLog.cpp(413))$$begin_record
LogType: security
Text: Failed to validate user credentials
Result-Code: 0x80090302
SIP-Start-Line: REGISTER sip:domain.com SIP/2.0
SIP-Call-ID: c8f814156fe8424b91f58a7593130b7a
SIP-CSeq: 3 REGISTER
Data: gssapi-data="NTLMSSP.........x...............H.......R.......b...........U..B..(.....d.o.m.a.i.n.b.a.r.k.s.d.a.D.6.2.0.-.S.P.A.R.E.1........(+H~B.\Q.d.^.7......0Nf........&U.*...F.i8...I".....E{..a"
$$end_record

TL_INFO(TF_PROTOCOL) [8]0D04.12B4::09/28/2010-22:33:22.019.0006269e (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 00008E99
Direction: outgoing;source="local"
Peer: ocsedgeint.domain.com:51824
Message-Type: response
Start-Line: SIP/2.0 401 Unauthorized
From
: <sip:username@domain.com>;tag=ef63196ac5;epid=66ae95f7d4
To: <sip:username@domain.com>;tag=9E59F3FCA63C8513AB67D79A59A71738
CSeq: 3 REGISTER
Call-ID: c8f814156fe8424b91f58a7593130b7a
Date: Tue, 28 Sep 2010 22:33:22 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="ocspool.domain.com", version=4
Via: SIP/2.0/TLS 10.1.1.143:51824;branch=z9hG4bK9CEF35AB.842743D325E6B7D1;branched=FALSE;ms-received-port=51824;ms-received-cid=13300
Via: SIP/2.0/TLS 192.168.2.104:1161;received=111.111.111.111;ms-received-port=54335;ms-received-cid=1F00
ms-diagnostics: 1000;reason="Final handshake failed";source="ocspool.domain.com";HRESULT="0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)"
Content-Length: 0
Message-Body: –
$$end_record

 

Their OCS environment is running on Windows 2008 R2 and as we continued to troubleshoot this we discovered that they didn't complete all the steps listed in KB982021 (https://support.microsoft.com/kb/982021/).  Specifically, they didn't complete Step 8. 

  1. The default security setting on Windows Server 2008 R2 operating system for NTLM SSP requires 128-bit encryption. Depending on the client operating system mix in the enterprise, you may have to reduce this setting on a Windows Server 2008 R2 operating system that is running Office Communications Server 2007 R2 as a down level operating system. The key is set to "No requirement."
    1. For any down level operating system, such as Windows XP or for Windows Vista, the default value is set to "No Minimum."
    2. For a Windows 7 operating system, the default value is set to "Requires 128-bit encryption."

For more information about the “Changes in NTLM Authentication” as it applies to Windows 2008 R2 and Windows 7 operating systems, please visit the following Microsoft Web site:

Learn more about the changes in NTLM Authentication

If you want to change the NTLM setting, follow these steps:

  1. Start secpol.msc on a Windows Server 2008 R2 operating system server.
  2. Click to select Local Policies and then click Security Options node.
  3. Make sure that the following values of the policies are set to "No Minimum."
    • Network Security: Minimum session security for NTLM SSP based (including secure RPC)
    • Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers

 

Once we changed the security policy the user could successfully login.  It just so happened that the users that couldn't login were running Windows XP.  Testing from a Windows 7 workstation before making the change resulted in the user being able to login.  Also, none of their internal Windows XP users had any problems logging in.  This makes sense, since internally the Communicator client is using Kerberos to authenticate and only when the user is external and coming in through the Edge server, is NTLM used.

So remember to follow all of the steps in KB982021 (https://support.microsoft.com/kb/982021/), especially if you have Windows XP users enabled for Remote User Access.