NTLMv2 support is now ready for the none-certified OCS phones

Hi, :)

some enterprises and organisation using Microsoft OCS have the need to force all client and server machines to support NTLMv2 only, for security concerns to LAN Manager and NTLMv1. Until now, it was impossible to connect the none-certified OCS phones from snom, a Berlin based ip-phone vendor to this kind of OCS infrastructures.

I had the luck to get hands-on the first version of snom's OCS Edition firmware, which supports NTLMv2 now and I like to share my test results with you.

Prep:

First I forced my UC /  AD test enviroment to NTLMv2 only. I guess this steps are quite similar to what is done in the mentioned "high security" networks. For my tests I simply edited the default domain policy, via Group Policy Management. (Please don't change anything following this explanations in a productive enviroment!)

  

The summary should look like:

When the policy is applied, you can check any windows based domain-joined machine, like your OCS Front End or Standard Edition Server if its is really activated.

Open local security policy, security options.

The LAN manager authentication level should look like:

As you can see the option is grayed out, change impossible, cause it is set via GPO.

If you try to connect a snom using the OCS edition firmware without NTLMv2 support, the log on the snom phone will show you statements like this:

[3]27/10/2009 18:26:44: Challenge: Unknown scheme Kerberos
[6]27/10/2009 18:26:44: Using user "Heiko.Riedel" and domain "ucc" for NTLM authentication
[3]27/10/2009 18:26:44: Challenge: Unknown scheme Kerberos
[6]27/10/2009 18:26:44: gui_object::challenge_user: Challenge User but wrong state 16
[2]27/10/2009 18:26:44: Registrar Heiko.Riedel@ucc.de refused with code 401
[5]27/10/2009 18:26:44: Will try to reregister in 300 seconds

It simply means the "old" firmware was unable to support the authentification challenge (NTLMv2) from OCS R1 / R2. With the latest firmware version (snaphot 8.2 - 10.19.09.) it will register without any issue and works as expected :) The first attempt fails (NTLMv1) and then it switches (NTLMv2) - so backward compatibility is well respected:

[8]27/10/2009 18:43:30: Send Packet REGISTER
[5]27/10/2009 18:43:30: sip::send_register: reregister timer for line 0 set to 300s
[8]27/10/2009 18:43:30: Routing to outbound proxy sip:sip.ucc.de:5061;transport=tls
[8]27/10/2009 18:43:30: DNS cache_lookup: a sip.ucc.de -> 172.21.18.3
[7]27/10/2009 18:43:30: Trusted IP Addresses: tls:172.21.18.3
[3]27/10/2009 18:43:30: Challenge: Unknown scheme Kerberos
[8]27/10/2009 18:43:30: Routing to explicit plan tls 172.21.18.3 5061
[8]27/10/2009 18:43:30: Send Packet REGISTER
[6]27/10/2009 18:43:30: Using user "Heiko.Riedel" and domain "ucc" for NTLM authentication
[8]27/10/2009 18:43:30: Routing to explicit plan tls 172.21.18.3 5061
[8]27/10/2009 18:43:30: Send Packet REGISTER
[2]27/10/2009 18:43:30: Registered at registrar as Heiko.Riedel@ucc.de (Expires: 900 secs)

This screenshot shows the client version summary on the OCS Frontend Server including two snom 360, one 370,one 820 and five OC clients R2 on none-domain-joined machines.

The NTLMv2 implementation was done for the whole snom OCS product family, of course. (As before regarding an OCS support, the M3 Dect2Sip is the only exception. It's not a secret today that the M3 is just an rebranded RTX.)

résumé

Shortsighted, the support of NTLMv2 on this snom phone's looks like nothing special. But from my point of view it is very suprising, in many ways:

1. it show's snom is committed to interop with Microsoft and capable to do it.
   
2. they respect the (security) requirements of their customers.
3. the snom team seems to shun no challenge

especially if you consider all the well known trouble around NTLMv2 with SAMBA, MAC OS, Linux etc. in Microsoft Active Directory based infrastructures and the fact that Microsoft NTLMv2 is not peanut upgrade to v1.

Good job - snom!

Regards, 

ocs phone guy