MS "breaking" Samba
gcarter at valinux.com
Tue Sep 26 13:08:14 GMT 2000
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
> - What exactly is the information you would
> need (i.e. interface UUIDs etc.)
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
- 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
- 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,
/\ 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
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
More information about the samba-ntdom