> has repeatedly stated that SQL Server has never > used unpublished APIs to acheive its performance
Well good for him. I wasn't talking about performance. I was talking about single sign on integration with the OS. Which can be a significant driving sales factor. Why do you think we try so hard to do the same thing for Samba ?
> I really think that makes the whole "MS uses > unpublished APIS to its advantage" argument moot > don't you think?
No I don't, for reasons stated above. Performance is not the only way to gain an advantage over the competition.
> The SQL developers apparently went to the NT > developers, asked how to do this, and were told. > When other significant customers (not > reverse-engineering cloners), who happened to be > outside Microsoft, wanted the same feature, > Microsoft published it. > > What's your complaint
Nice story. Ok, would you call Oracle, Informix or Sybase "reverse engineering cloners" ?
No ?
Then why couldn't they do single sign on under NT ? Why only SQLServer ? Maybe a hidden API ?
Microsoft have been caught doing this, again and again and again. Red handed. Why do you thing the DOJ wants an MS Apps and MS OS companies. To stop *exactly* this kind of thing happening.
BTW: The "reverse engineering cloners" comment is especially funny, as MS Lanman was originally developed by 3COM, MS-SQLServer was based on the Sybase code (and still uses the same over the wire transport TDS format)... Should I go on ?
> It's explicitly stated that you can only do > standard (i.e. supply uname/pwd at SQL Server > logon time) logon off a TCP/IP
Do you remember your NT API history ? I do (you aparently do not).
In NT3.1, there was *no way* to authenticate a user given just a username and password.
The LogonUser API was only released in the NT3.5 timeframe.
The SQLServer Team used the *undocumented* LSALogonUser API I believe (not having access to their source code I cannot be sure of course).
As I stated - a use of an *undocumented* API to give advantage to a Microsoft application product on a Microsoft OS. An API *not* available to other application vendors.
I don't think this is much in question from people who were working on this at the time.
> Worried that your little reverse-engineering > projects won't be possible for much longer
That's funny:-). Samba may be many things, but "little" it isn't any more:-).
We now have *permanant*, *full time* contributors from HP, SGI, Veritas and IBM, that's not counting the full time people at VA Linux Systems and Linuxcare.
What's the matter, not *worried* about a little reverse engineering project, are you... ?
What, like a little UNIX reverse engineering project called "Linux":-).
> In fact, there are about a dozen PUBLISHED API's > on NT that allow you to authenticate users in various ways.
There are *NOW*. Didn't you read my post ? This was on NT3.1, before even the LogonUser API was public.
Although the MS SQLserver group obviously knew about it (along with the SSPI APIs).
That's the point. MS App developers get inside knowledge that other developers don't get until later.
Don't you think Oracle would have *liked* to have done single sign on in thir NT product, just like SQLServer did ? They couldn't because the OS division doesn't give advanced knowledge of APIs like that to MS-Application competitors. This is one of the reasons MS is in the "illegal monopoly, let's break 'em up" position it is in today.
> What evidence do you have that any secret API's > were given out by the Windows team?
Back when I worked at Vantive, I was doing a port of their UNIX product to Windows NT (now I spend my time helping people port from NT to Linux, so it goes:-).
We were using MS-SQLserver for the port. Now this was back in the NT3.1 timeframe. MS-SQLserver could do a very neat thing. It could take an authenticated Windows users who had logged onto the domain, and allow that user to access a SQL database *without needing to log on again* - ie., the Windows domain password was being used to control access to the SQLserver database.
Wow, what a neat trick, I thought. I'd really like to be able to do that to control access to the Vantive product (as then a username/password would only be created once, in the Domain, and the SQLserver and Vantive products would both use the same logon/password pair).
So I started to look to see how it was done.....
Can you guess ? It was not possible given *any* published API's at the time.
Now (5+ years later), the SSPI is revealed as the way they probably did this.
But no one outside MS had access to that API. Oracle on NT couldn't do this (no single sign on). Sybase & Informix on NT couldn't either....
Don't tell me the OS team don't leak private API information to the app development team without explaining the story above please.
"Or look at samba 2.x only way to get that from $GI is to pay their $2000+ yearly samba software support"
Oh for heavens sake. I was involved in the pricing discussions at SGI on this point. I was pushing for them to charge *more* than they do !
Supporting a new protocol is *hard*. Tech support staff need training, engineering infrastructure needs building....
For most commercial companies, spending $2000 for a year tech support for a file server is *peanuts*. Remember that's with no client access license restrictions - as many clients as the file server supports. And IRIX servers support *lots* of clients:-).
My personal opinion is SGI are *undercharging* for Samba:-).
> More importantly, the standard DCE approach > admits of a nasty race condition, where a second > user uses a first user's workstation token to > get at his or her user ACL entry.
Huh ? This doesn't make sense. All the packets used in kerberos are integrity and privacy protected. The scenario you describe is simply not possible. Also, there is no such thing as a 'workstation token'. Kerberos principals are users and services, not machines.
The "MS hack", as you describe it, has *nothing* to do with any potential race conditions in DCE.
I would suggest reading "Network Security", by Perlman, Kaufman and Spencer for an excellent introduction to these topics.
No, actually it is still an issue. I have been requesting that Microsoft document this extension (Hi Peter:-) ever since I heard about Win2k (then WinNT5) being kerberos based back in '97. I was porting MIT Kerberos 5 to Windows NT 4.x at the time for Cygnus (now RedHat).
Every time I ask (and I've asked *many* times, publically as well as privately) Microsoft have said "yes we are committed to documenting this". I believe them. I just want to *see* the documentation first....
Yep. The O'Reilly book, "DCE Security Programming" by Wei Hu, ISBN 1-56592-134-8 (just don't buy it from Amazon:-).
Page 37, section entitled "How PAC's are used" explains how a standard Kerb5 TGT is obtained, then a ticket to the privillage service is obtained, then a second TGT (called a PTGT) is obtained from the privillage service. This PTGT contains the authorisation data (user and groups in the form of DCE UUIDs) stored in the "application data" field.
It was done this way so a *standard* kerb5 server could be used as a authentication source, with a secondary server used as an *authorization* source.
Microsoft could have done the same. They didn't, but modified the Kerb5 KDC directly and put authorization data into the TGT. That's what the fuss is about.
> MS-Extensions. - This is the vendor data that is > allowed as part of the spec. Same place the > IBM/Transarc/SecurityDynamics/Entrust/etc put > there propriatory data.
This is incorrect. The DCE PAC's are created by first getting a *standard* TGT from a Kerb5 KDC, then using that to get an additional TGT containing the PAC. Microsoft could have done the same. They chose not to. That is what people are objecting to.
Ha ! That's funny. There have been *many* deliberate violators of the GPL. Anyone who has managed a large, successful GPL'ed project will have come across these people (I know Samba has).
What usually happens is that after some polite legal words the violators back down (in all cases I know of). This is why the violators have never ended up in court.
This is a testament to the legal security of the GPL, in that no violator has yet had the courage to challenge in court what they did (and some have been *very* well funded indeed).
I expect the same thing to happen here that happens in most of these cases - the violators will back down before losing in court.
FreeBSD *was* tested with Samba (this was in the FreeBSD 2.x timeframe just after the Mindcraft benchmarks - not with 3.x).
It did about the same for SMB fileserving as Linux did. I was dissapointed as I would have loved to get an Intel Open Source based rebuttal to the Mindcraft benchmarks and I didn't care if it was FreeBSD or Linux. I was pushing to get the tests done, and had FreeBSD done much better I would have pushed PC Week to do a Samba+FreeBSD test. Remember, I'm promoting Samba, not an OS:-).
Unfortunately, at least with FreeBSD 2.x the TCP stack was also very single threaded in the kernel.
Things look *much* better with the 2.3.x Linux kernels, and I hope they improve in the same way for the *BSD's also !
> It's Linus' vision of what the kernel needed and > didn't need. It's the same thing with Java.
No, you miss a vital point.
If enough people decide that Linus' vision is flawed, then they can just fork the code and ignore him. Happens all the time (the RealTime Linux people come to mind).
Sun rules Java with an iron fist. Good luck trying to fork the language (Microsoft tried).
Remember, the GPL is your *only* friend:-).
Regards,
Jeremy Allison, Samba Team.
Re:It would be nice if it would work with Frontpag
on
Samba 2.06 Released
·
· Score: 1
HP and Northrop Grummond (sp?) have donated some code to help with this. Needs a little work though. I'm targeting 2.0.7 (2.0.6 oops bugs notwithstanding:-) for this.
> It would be nice to see a single task, > multithreaded model. That would really kick ass > IMHO.
Actually, no, I'm afraid it would suck:-). Come to one of my Samba talks if you want the gory details why, but essentially the problem is with threads switching user contexts. Think about how Samba provides UNIX security....
Slashdot Mirror
> has repeatedly stated that SQL Server has never > used unpublished APIs to acheive its performance
Well good for him. I wasn't talking about performance. I was talking about single sign on integration with the OS. Which can be a significant driving sales factor. Why do you think we try so hard to do the same thing for Samba ?
> I really think that makes the whole "MS uses
> unpublished APIS to its advantage" argument moot
> don't you think?
No I don't, for reasons stated above. Performance is not the only way to gain an advantage over the competition.
Regards,
Jeremy Allison,
Samba Team.
> The SQL developers apparently went to the NT
:-).
> developers, asked how to do this, and were told.
> When other significant customers (not
> reverse-engineering cloners), who happened to be
> outside Microsoft, wanted the same feature,
> Microsoft published it.
>
> What's your complaint
Nice story. Ok, would you call Oracle, Informix or Sybase "reverse engineering cloners" ?
No ?
Then why couldn't they do single sign on under NT ? Why only SQLServer ? Maybe a hidden API ?
Microsoft have been caught doing this, again and again and again. Red handed. Why do you thing the DOJ wants an MS Apps and MS OS companies. To stop *exactly* this kind of thing happening.
BTW: The "reverse engineering cloners" comment is especially funny, as MS Lanman was originally developed by 3COM, MS-SQLServer was based on the Sybase code (and still uses the same over the wire transport TDS format)... Should I go on ?
Who are the reverse engineering cloners here
Regards,
Jeremy Allison,
Samba Team.
> It's explicitly stated that you can only do
> standard (i.e. supply uname/pwd at SQL Server
> logon time) logon off a TCP/IP
Do you remember your NT API history ? I do (you aparently do not).
In NT3.1, there was *no way* to authenticate a user given just a username and password.
The LogonUser API was only released in the NT3.5 timeframe.
The SQLServer Team used the *undocumented* LSALogonUser API I believe (not having access to their source code I cannot be sure of course).
As I stated - a use of an *undocumented* API to give advantage to a Microsoft application product on a Microsoft OS. An API *not* available to other application vendors.
I don't think this is much in question from people who were working on this at the time.
Regards,
Jeremy Allison,
Samba Team.
> Worried that your little reverse-engineering
:-). Samba may be many things, but "little" it isn't any more :-).
:-).
> projects won't be possible for much longer
That's funny
We now have *permanant*, *full time* contributors from HP, SGI, Veritas and IBM, that's not counting the full time people at VA Linux Systems and Linuxcare.
What's the matter, not *worried* about a little reverse engineering project, are you... ?
What, like a little UNIX reverse engineering project called "Linux"
Regards,
Jeremy Allison,
Samba Team.
> In fact, there are about a dozen PUBLISHED API's
> on NT that allow you to authenticate users in various ways.
There are *NOW*. Didn't you read my post ?
This was on NT3.1, before even the LogonUser API
was public.
Although the MS SQLserver group obviously knew about it (along with the SSPI APIs).
That's the point. MS App developers get inside knowledge that other developers don't get until later.
Don't you think Oracle would have *liked* to have done single sign on in thir NT product, just like SQLServer did ? They couldn't because the OS division doesn't give advanced knowledge of APIs like that to MS-Application competitors. This is one of the reasons MS is in the "illegal monopoly, let's break 'em up" position it is in today.
Regards,
Jeremy Allison,
Samba Team.
> Why couldn't you use ImpersonateXxx/OpenThreadToken/RevertToSelf functions
:-).
:-).
:-).
Ah, the peanut gallery
Yes I was waiting for this comment
So, tell me how you made those functions work *OVER A TCP CONNECTION*, NOT A NAMED PIPE, in NT 3.1 ?
No answer, well SHUT UP THEN !
Regards,
Jeremy Allison,
Samba Team.
(Who is feeling in a pissy mood today
> What evidence do you have that any secret API's > were given out by the Windows team?
:-).
Back when I worked at Vantive, I was doing a port of their UNIX product to Windows NT (now I spend my time helping people port from NT to Linux, so it goes
We were using MS-SQLserver for the port. Now this was back in the NT3.1 timeframe. MS-SQLserver could do a very neat thing. It could take an authenticated Windows users who had logged onto the domain, and allow that user to access a SQL database *without needing to log on again* - ie., the Windows domain password was being used to control access to the SQLserver database.
Wow, what a neat trick, I thought. I'd really like to be able to do that to control access to the Vantive product (as then a username/password would only be created once, in the Domain, and the SQLserver and Vantive products would both use the same logon/password pair).
So I started to look to see how it was done.....
Can you guess ? It was not possible given *any* published API's at the time.
Now (5+ years later), the SSPI is revealed as the way they probably did this.
But no one outside MS had access to that API. Oracle on NT couldn't do this (no single sign on). Sybase & Informix on NT couldn't either....
Don't tell me the OS team don't leak private API information to the app development team without explaining the story above please.
Regards,
Jeremy Allison,
Samba Team.
AC wrote :
:-).
:-).
"Or look at samba 2.x only way to get that from $GI is to pay their $2000+ yearly samba software support"
Oh for heavens sake. I was involved in the pricing discussions at SGI on this point. I was pushing for them to charge *more* than they do !
Supporting a new protocol is *hard*. Tech support staff need training, engineering infrastructure needs building....
For most commercial companies, spending $2000 for a year tech support for a file server is *peanuts*. Remember that's with no client access license restrictions - as many clients as the file server supports. And IRIX servers support *lots* of clients
My personal opinion is SGI are *undercharging* for Samba
Regards,
Jeremy Allison,
Samba Team.
I suffered from the same problem. The CD key
:-).
:-).
is listed on a little tag inside the *back page*
of the manual, *not* (as the manual states) on
the CD.
What is on the CD is the product bar code (boy,
did I feel dumb after typing this in
Regards & happy linux quaking
Jeremy Allison,
Samba Team.
> More importantly, the standard DCE approach
> admits of a nasty race condition, where a second
> user uses a first user's workstation token to
> get at his or her user ACL entry.
Huh ? This doesn't make sense. All the packets used in kerberos are integrity and privacy protected. The scenario you describe is simply not possible. Also, there is no such thing as a 'workstation token'. Kerberos principals are users and services, not machines.
The "MS hack", as you describe it, has *nothing* to do with any potential race conditions in DCE.
I would suggest reading "Network Security", by Perlman, Kaufman and Spencer for an excellent introduction to these topics.
Regards,
Jeremy Allison,
Samba Team.
No, actually it is still an issue. I have been requesting that Microsoft document this extension (Hi Peter :-) ever since I heard about Win2k (then WinNT5) being kerberos based back in '97. I was porting MIT Kerberos 5 to Windows NT 4.x at the time for Cygnus (now RedHat).
Every time I ask (and I've asked *many* times, publically as well as privately) Microsoft have said "yes we are committed to documenting this". I believe them. I just want to *see* the documentation first....
Regards,
Jeremy Allison,
Samba Team.
> Can you link to any hard data?
:-).
Yep. The O'Reilly book, "DCE Security Programming" by Wei Hu, ISBN 1-56592-134-8 (just don't buy it from Amazon
Page 37, section entitled "How PAC's are used" explains how a standard Kerb5 TGT is obtained, then a ticket to the privillage service is obtained, then a second TGT (called a PTGT) is obtained from the privillage service. This PTGT contains the authorisation data (user and groups in the form of DCE UUIDs) stored in the "application data" field.
It was done this way so a *standard* kerb5 server could be used as a authentication source, with a secondary server used as an *authorization* source.
Microsoft could have done the same. They didn't, but modified the Kerb5 KDC directly and put authorization data into the TGT. That's what the fuss is about.
Regards,
Jeremy Allison,
Samba Team.
> MS-Extensions. - This is the vendor data that is
> allowed as part of the spec. Same place the
> IBM/Transarc/SecurityDynamics/Entrust/etc put
> there propriatory data.
This is incorrect. The DCE PAC's are created by first getting a *standard* TGT from a Kerb5 KDC, then using that to get an additional TGT containing the PAC. Microsoft could have done the same. They chose not to. That is what people are objecting to.
Regards,
Jeremy Allison,
Samba Team.
"the first deliberate violator of the GPL"
Ha ! That's funny. There have been *many* deliberate violators of the GPL. Anyone who has managed a large, successful GPL'ed project will have come across these people (I know Samba has).
What usually happens is that after some polite legal words the violators back down (in all cases I know of). This is why the violators have never ended up in court.
This is a testament to the legal security of the GPL, in that no violator has yet had the courage to challenge in court what they did (and some have been *very* well funded indeed).
I expect the same thing to happen here that happens in most of these cases - the violators will back down before losing in court.
Regards,
Jeremy Allison,
Samba Team.
FreeBSD *was* tested with Samba (this was in the FreeBSD 2.x timeframe just after the Mindcraft benchmarks - not with 3.x).
:-).
It did about the same for SMB fileserving as Linux did. I was dissapointed as I would have loved to get an Intel Open Source based rebuttal to the Mindcraft benchmarks and I didn't care if it was FreeBSD or Linux. I was pushing to get the tests done, and had FreeBSD done much better I would have pushed PC Week to do a Samba+FreeBSD test. Remember, I'm promoting Samba, not an OS
Unfortunately, at least with FreeBSD 2.x the TCP stack was also very single threaded in the kernel.
Things look *much* better with the 2.3.x Linux kernels, and I hope they improve in the same way for the *BSD's also !
Regards,
Jeremy Allison,
Samba Team.
Linux can support MS Outlook clients, with all those nice embraced-and-extended features.
:-).
Check out HP's OpenMail :
http://www.ice.hp.com/cyc/om/00/index.html
It has a Linux server that supports the Outlook
features the marketing and sales depts. want
Check it out - kill these rumours (Linux can't
support Exchange functionality) *NOW* !
Regards,
Jeremy Allison,
Samba Team.
> It's Linus' vision of what the kernel needed and
:-).
> didn't need. It's the same thing with Java.
No, you miss a vital point.
If enough people decide that Linus' vision is
flawed, then they can just fork the code and
ignore him. Happens all the time (the RealTime
Linux people come to mind).
Sun rules Java with an iron fist. Good luck
trying to fork the language (Microsoft tried).
Remember, the GPL is your *only* friend
Regards,
Jeremy Allison,
Samba Team.
HP and Northrop Grummond (sp?) have donated some code to help with this. Needs a little work though. I'm targeting 2.0.7 (2.0.6 oops bugs notwithstanding :-) for this.
Jeremy Allison,
Samba Team.
Shaman wrote :
:-). Come to one of my Samba talks if you want the gory details why, but essentially the problem is with threads switching user contexts. Think about how Samba provides UNIX security....
> It would be nice to see a single task,
> multithreaded model. That would really kick ass
> IMHO.
Actually, no, I'm afraid it would suck
Cheers,
Jeremy Allison,
Samba Team.