MS "breaking" Samba

[Gerald Carter]

Long message notice.....

Simo Sorce wrote:
> 
> > Paul Leach wrote:
> >
> > We have never added any improvements (or 
> > non-improvements) to the protocols in order to 
> > "break" Samba (or to affect it in any way at 
> > all).  We tested Win2k against Samba as a file 
> > server to make sure that it continued to work 
> > as a "down-level" server, along with NT4,
> > OS/2, Windows 9x, and others. Of course, it (just
> > like NT4) would not support the new Windows 
> > 2000 features, by which we hope to entice our
> > customers to upgrade by providing new value to them.
> >
> > Just to be clear: we didn't test Win2k against Samba as 
> > a DC; we did test against NT4 DCs, however, so if 
> > Samba really does emulate all NT4 DC functionality, 
> > it should have been OK.
> >
> > Paul

Hi Paul.  Haven't head a peep from you in a while.  Hope 
things are well.  Just though I would inject that first.

> I'm not a Samba team member, but as I remember Samba 
> needed to upgrade from 2.0.6 to 2.0.7 just to serve files 
> to Win2k machines, so your claim that you tested Win 
> 2000 against Samba to ensure compatibility as file
> server must be false!
> 
> DC functionality was not supported so testing against it 
> was obviously not required, anyway win2k does not 
> function with samba 2.0.x in NT4 compatibility mode(how 
> much compatible is then??)
> 
> I hate to see this kind of statements from employee of 
> a company that is proven to have made unfair practices, I 
> think that if you care your personal reputation you 
> should check twice and prove your statements before speaking.

Simo,  Antagonism doesn't help.  :-)    MS did clean 
up many things in Win2k.  Perhaps the complaint is that
all the changes were not documented. (hey paul ;) )

So i will make another plea.  (quoting from a previous 
request by Luke).  Any (or all) of the information
would be a good thing.  


	i will move this off list after the 
  	initial request in case you would like 
	to discuss this further




.....begin plea.........................

> - What exactly is the information you would 
> need (i.e. interface UUIDs etc.)

IDL files:

samr.idl, spoolss.idl, netlogon.idl, lsarpc.idl, 
srvsvc.idl, wkssvc.idl, browsess.idl, winsmgr.idl, 
winreg.idl, svcctl.idl, eventlog.idl at least.

basically, anything that makes samba an NT4 PDC 
and/or NT 4 wksta domain member, which pretty much has 
all the bare-bones of these already [except winsmgr], 
_that_ much more stable and less likely to trash nt domain
systems it interoperates with [cf. samba prealpha 1.9 which 
is causing massive headaches for ISS Scanner Product: it 
causes it to crash].

Encryption / Authentication components:

- NTLMSSP, particularly NTLMSSP over DCE/RPC.

- NTLMv1 _and_ NTLMv2, *particularly* NTLMv2 and how it is 
used in NTLMSSP.  there are 4 sing/seal/client/server 
16-bit "magic constants" that are critical to getting 
NTLMv2-enabled NTLMSSP to work, and i really cannot - 
do not wish - to spend another two to three weeks trying 
to work these out, it gives me a headache :)

- the NETLOGOON "Schannel" , which i _know_ is not the 
right word, but there is no other description available.  
basically, it's what is activated when the NETLOGON "Sign" 
and "Seal" is negotiated.  paul leach will know what i 
am referring to.  it's used to encrypt \PIPE\NETLOGON.
it is _very_ similar in format to 
draft-brezak-krb5-rc4hmac-00.txt, but not _quite_ the same. 
NetrAuthenticate2's neg_flags argument must have 
the bit 0x40000000 set for the sign/seal to be activated.

[side-note:it would be _nice_ to have the details of 
the nt5 "schannel" systems, which can be negotiated 
with something like 0x7fff01ff or thereabouts by an 
nt workstation when joined to an nt5 domain in back-compat 
mode.  this presumably negotiates and activates such 
schemes as sha-1, crc-des-cbc and others that are related 
to the current use of kerberos and the encryption schemes 
that kerberos uses, again presumably because the NETLOGON 
pipe can be used by an nt5 wksta to obtain user-profile info.]

- LsaSetSecret's use of the "user session key"

- SamrSetUserinfo and SamrGetUserInfo's use of the "user 
session key".

- details of any mechanisms that have replace this because 
i know it's very insecure.

some of these are not new to me, it's just that i don't 
know _all_ of them, or the "finer details" - e.g i do not 
know how 128-bit NTLMSSP works, only 40-bit.

i documented as many as i could in my book: "DCE/RPC 
over SMB: Samba and Windows NT Domain Internals", it can 
be found on amazon.com.

NT5 Encryption / Authentication

- the PAC (application specific field) in the krb5 
ticket which contains the user profile info, the user 
session key and some unidentified, but probably
kerberos5-encryption-ms-specific-info.

- the additions to the \PIPE\NETLOGON to obtain a user 
profile or other info, which i have only heard rumor of

- how passwords are encrypted in the Active Directory 
[my guess is that they use SYSKEY, but i have no idea how, 
and my guess is also that the NT password has is stored 
_and_ the Unicode plain text is stored, again using
some SYSKEY related algorithm]

- probably also needed for "interop" purposes: the 
replication mechanism between AD forests.  this to 
allow NT _and_ unix to play a part: it allows for people 
to upgrade then migrate from unix krb5 to NT, but 
equally it allows them to migrate the other way, i know, 
so it's a double-edged sword, always, where "may be the 
best company win" :)








Cheers and the best,
jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com  VA Linux Systems    gcarter at valinux.com
       http://www.samba.org       SAMBA Team           jerry at samba.org
       http://www.eng.auburn.edu/~cartegw

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )