Patches for channel and service binding for NTLM (extended protection)

Andrew Bartlett abartlet at
Fri Jan 6 21:31:22 MST 2012

On Mon, 2011-10-10 at 22:44 +0000, Stephen Zarkos wrote:
> Hi folks,
> Forwarding per Andrew Bartlett's request:
> Earlier this year we had an intern working with us to implement a proof of concept for extended protection (channel and service binding) for Firefox and Samba.  To enable this scenario on the client side, we were able to use libraries available on Windows and contribute code to the Mozilla team to make this all work.  On the Linux side, however, Firefox utilizes Samba for NTLM authentication and so he also built some patches for Samba to enable this scenario.
> These patches have been approved for release as 'GPLv2 or later' and copyright has been assigned to me (just like our build farm patches earlier).  My only concern is that these patches may be bit stale and may need some work.  Hopefully they are still useful to you and are not so huge that you can see what he was trying to do.  The original developer (Guillermo Robla Vicario <groblavicario at>) may be able to assist a bit with questions, although he's no longer with MS and is quite busy these days :)
> Please let me know what you think.  Also, for reference the Mozilla bug related to Guillermo's contribution to that team can be seen here:


I do apologise for the long delay in looking into these patches.  I've
started to look into them more closely, and I'm rather confused and
surprised by the design.  Why is ntlm_auth parsing the NTLMSSP blob and
then re-generating it?

This data should be communicated down to NTLMSSP - in master, this
should be via gensec, but even in the versions this patch was first
built for, the NTLMSSP layer is still distinct, with an 'update()'
interface that should be respected.

Also, it seems that the parsing is stretching the simple msrpc_gen
interface beyond what is reasonable.  In master and 3.6 you can see how
we now use NDR for some elements.  Is there an IDL for this extension
that we should use instead?


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list