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

SCUPA - a remote call control for the none-certified OCS phones

Hi, :)

a lot of people using Communicator still like the option to remote call control a phone. Fortunatly, it seems that someone has listen to this wishful thinking, especially for the one's using none-certified OCS phones from snom. (this post is not related to traditional RCC with 3.party SIP ua CSTA ecma TR / 87 gateway or TAPI approach!)

The tool is called SCUPA, a result of a very ambitious UCMA development project at SINC a german based MS Gold partner. To project-page (for the EN part simply scroll down). I had the luck to get hands-on the version 1.0.5.0, wich will be available soon on the project-page. Please consider this as a proof of concept and so please do not judge it too early. The developer team is well aware that there is still space for improments, indeed also in terms of security. From my point of view, for the UC application pioneer times we live in, they made a quiet seamless integrated useful add-on. Good job SINC! :)

Ok,now lets have a look: SCUPA comes as an MSI, so install and mass deployment - no problem. :)

When you open OC you will find a new extra option - hit SCUPA configuration:

You simply enter the IP adress of the snom phone you like to control.

No authentication to the phone? Yep!, remember its a PoC atm. You have to clean up the http webserver user account & password info at the snom phone. Access the webserver of the phone, go to SETUP, Advanced, QoS/Security and clear the user and pw line:

Additionally you can ignore the security warning via setting:

Please, dont forget to hit save at the bottom. Now back to OC and enter a number:

When the normalized number is marked, the rightclick offers you the Call via IP-Phone option. For a half second you will see something like this:

Maybe this can be suppressed in future releases. atm just ignore it :)

The up-popping menu is very ease to use and of course you get more numbers by selecting someone from your well known contacts:

For OC the current SCUPA PoC is a great first step. In combination with a snom OCS edition phone also the status is correctly changing to "on the phone". If you have not seen it yet, the contact list on snom OCS edition respects also the status information correctly (e.g. snom 820):


(live screen like shown on the 820 phone display - no photoshop fake ;) )

 


And Yes, :) you also can control all snom's without the OCS firmware, connected to your sip provider or ip-pbx, if you like. (afaik, only the snom M3, DECT to SIP is an exception.)



Unfortunatly atm, you can't call-control from Outlook or Sharepoint, as this will lead to an enterprise voice call with OC client (e.g. screenshot from Outlook 2010beta, but it's equal behavior in MOSS or former Outlooks):

It is also the case with TEL: URI's :( like this one: TEL:+4930123456789, you can't intercept the behavior with the current version of SCUPA.


The roadmap for an advanced version of SCUPA sounds promising for snom OCS edition owners:

1. secure call control via https with enterprise enrolled certificates on the phones
2. secure password and account changes to the snom, from within scupa - so no need for the user to enter the snom webserver directly.
3. much more control options / scenarios and interop between snom and scupa.

But atm this is all still up in the air and your feedback is highly appreciated at the SCUPA team! If you are interested, please feel free to contact the team leader Jan.Dierich (aahht) sinc.de - of course also possible via OCS federation!

I wish you a good testing experience, like I had so far! (btw.: Win7 x64 can possibly be an issue atm. - faced some app crashes). The version I used should be public available during next week, or regarding Win7 an improved one ;)

Have a great weekend,

ocs phone guy