Slashdot Mirror
Samba 4 Technology Preview Released
daria42 writes "Samba creator Andrew Tridgell has officially released a technology preview of Samba 4 at the Linux.conf.au conference in New Zealand, ending a three-year wait for users. But wait before upgrading those servers. 'It may eat your cat,' says the Samba team in a statement, 'but is far more likely to choose to munch on your password database.'" From the article: "'Samba 4 supports the server-side of the Active Directory logon environment used by Windows 2000 and later, so we can do full domain join and domain logon operations with these clients,' the group said in a statement on its Web site, noting this feature was 'the main emphasis' for the new software."
Came across this (short but interesting) interview with Jeremy Allison, one of the project's lead developers, where he talks about Samba 4:
a d&name=News&file=article&sid=217
:-)
http://www.linuxformat.co.uk/modules.php?op=modlo
Any software that has a 'Susan Stage' has got to be cool
Debian allready has packages.
/etc/apt/sources.list first.
Install them by running:
aptitude install -t experimental samba
But you'll need to add an entry for experimental to
If you don't know how to, you shouldn't be messing with experimental software anyway.
There has been info about Samba 4 for some time. Andrew Bartlett wrote a year ago an interesting thesis about Samba 4 and Active Directory (PDF).
But the release of this TP is good news, I hope that the use of Microsoft's Active Directory as an authentication service for Linux systems is coming to an end. All what we need now is a nice GUI.
-= If you fight Dragons long enough, you will become a Dragon =-
Actually, windows copied in 2000 what was available in other environments for many years. AD is the bastard son of ldap+kerberos+smb.
What took years is reverse-engineering all the weird quirks MS introduced in the previously standard systems.
Besides, Samba can do a lot nifty things AD can't, so who's behind?
Ciao, Renato
Um, no. LDAP and Kerberos weren't invented by Microsoft. They put the two together and called it Active Directory, straying away from the RFCs and throwing in all manner of tweaks that required extensive reverse engineering on the part of the Samba team to figure out. That means figuring out the protocol from the packets, which is an incredible feat, especially as Microsoft's protocol designs aren't easily discerned and contain all sorts of weird gotchas (purposefully).
There's a lot of complexity under that GUI of yours and, whether you want to believe it or not, Microsoft isn't such an innovative organization. Generally, they poach something that's already widely available and tweak it so it won't be interoperable with other systems. If you call that innovation, then I guess that speaks for itself.
I'm not a sysadmin, but I never got how NFS prevented a user plugging a computer which they have root access on into the network, mounting a common NFS mount, "su"ing to somebody's UID and then deleting their files. AFAICS, SMB handles this by requiring credentials of some kind from the computer. Can anyone explain this?
"Authentication" with NFS is IP based. You grant access to NFS mounts by specifying which hosts can mount that share. This implies that the hosts you allow are trusted, and that your network is trusted as well. So yes, if a computer you have root access to has been granted read/write access to an NFS mount then you can just su to someone else's UID and delete their files on that NFS mount.
Is it a good idea to use NFS in a security sensitive environment? Probably not.
Easy... as in SWAT?
Mr. Universe: "They can't stop the signal, Mal. They can never stop the signal."
Lets be clear on this point -
When vista comes out, samba will not break.
MS will simply have changed the standard/protocol/whatever in some way that thier own prior implementations will be tolerant of but Samba will not. Samba will not be busted, MS' own implementation of thier own technology (or other peoples tech, kerberos for example) is what will be busted.
Well, actually Microsoft faced a difficult challenge when they decided to go with Kerberos. The NT security model wasn't a very good fit, but they were committed to it by years of investment and dependent design decisions, not to mention a huge installed base. They had to find a way to paste SIDs onto Kerberos. It was a long time before the rest of us got an unencumbered look at the TDATA that they worked out to do this, but once the format was known working with it should not be that complicated.
In terms of volume of proprietary information to work out, the plethora of interlocking directory object types that an ADS client depends on has got to be the big challenge. The static characteristics of these objects and their attributes are documented (I use the term loosely) in the PSDK, but how they are used or even what some values mean is not at all clear. Throw in a few obvious copy/paste errors in the doco. to cloud the issue further and it's not surprising that Samba took this long. Create a new ADS forest and look at all the stuff that was put into it out of nowhere.