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."

Jeremy Allison on Samba 4

[Anonymous Coward]

Came across this (short but interesting) interview with Jeremy Allison, one of the project's lead developers, where he talks about Samba 4:

http://www.linuxformat.co.uk/modules.php?op=modloa d&name=News&file=article&sid=217 [linuxformat.co.uk]

Any software that has a 'Susan Stage' has got to be cool :-)

Re:Jeremy Allison on Samba 4

[laptop006]

Erm, he's not a major developer of samba 4, Tridge is, Andrew Bartlett is, and a few others are, but Jeremy isn't (at least according to Andrew Bartlett yesterday).

I'm at LCA2006 and have spent several hours with both Tridge and Andrew Bartlett, testing, fixing bugs, and identifing missing features of samba4. I'm not a samba team member, just a sys-admin who wants samba4 to be the best code possible before I deploy it.

it's in Debian

[CAPSLOCK2000]

Debian allready has packages.
Install them by running:
aptitude install -t experimental samba

But you'll need to add an entry for experimental to /etc/apt/sources.list first.
If you don't know how to, you shouldn't be messing with experimental software anyway.

Samba 4

[YearOfTheDragon]

There has been info about Samba 4 for some time. Andrew Bartlett [samba.org] wrote a year ago an interesting thesis about Samba 4 and Active Directory [samba.org] (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 [securityfocus.com] is coming to an end. All what we need now is a nice GUI [samba.org].

Re:Only 6 years

[RenatoRam]

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?

Re:Just Work (TM)

[rpbailey1642]

Well, granted I did have to set up the config file, but it wasn't too terribly difficult:
[global]
workgroup = WORKGROUP
server string = Description of Server
security = share

( Rpbailey Notes: This might be where you were led astray. You probably had samba set to use passwords instead of share security. )

[Multimedia]
path = /usr/multimedia
writable = yes
comment = Multimedia
browseable = yes
public = yes
---
Just make sure that the directory in question is writable by your samba user (assuming you have a user that samba runs as) or is otherwise writable. The most "playing around" you have to do is with permissions on that one folder.

Good luck!

Re:Only 6 years

[TallMatthew]

So, in 2006, Samba is finally able to do what windows was able in 2000?

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.

Re:What is this samba you speak of?

[Spacelord]

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.

Re:What is this samba you speak of?

[StressedEd]

The default behaviour is to not allow this. From the manual,
man -S 5 exports

              Very often, it is not desirable that the root user on a client machine
              is also treated as root when accessing files on the NFS server. To this
              end, uid 0 is normally mapped to a different id: the so-called anony-
              mous or nobody uid. This mode of operation (called 'root squashing') is
              the default, and can be turned off with no_root_squash.

Re:Just Work (TM)

[HoosierPeschke]

Easy... as in SWAT? [samba.org]

Re:it's in Debian

[Thing 1]

"If you don't know how to breathe, you shouldn't bother taking your first breath."

Or, closer to the original: "Breathing. If you don't know how to, you shouldn't be messing with environmental oxygenation anyway."

Here's a link to a howto [debian.org] for configuring your Debian installation to use the experimental packages. (It's in section 4.6.4.3, or just search on the page for "experimental".)

Lets be clear -

[gentimjs]

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.

Re:What is this samba you speak of?

[Professor_UNIX]

That doesn't help when the root user creates a user account with the correct UID and then logs in as that user, does it?

Nope. That's how I used to update some web files on a central NFS server here long after the person left. I just added an account with his UID on my workstation, mounted the central NFS server's web share and voila. I could read/write his files just fine. Traditional NFS is HORRIBLE from a security standpoint since the only authentication involved is IP based and the only authorization is to rely on the UID/GID to prevent other users from munging with your files. This relies on only having trusted hosts having read/write access to your network. Newer versions of NFS add additional security mechanisms in place for both authentication and authorization, but they are rarely used from what I've seen since most people still use it the way NFS v2 behaved (relying on IP address and UID/GID) rather than Kerberos and certificates.

Samba 3 Almost but not quite Active Directory,.

[Zombie Ryushu]

On my home network, I have been using Samba as an internal network file system for Linux to Linux networking. I use LDAP as my Database backend, Kerberos as my means of authentication too Samba.

You see I discovered something about Windows and SMB. Windows Cached its passwords. The passwords were replayed across the network whenever a new socket was opened. Konqueror would not replicate this behavior unless forced to by the KDE Control center. I have a big long thing that describes the whole thing.

It is not totally perfect but I want you to tell me if you think that
this constitutes Active Directory, or at least something close.
Eitherway, This is a major accomplishment for me, and I wanted some
suggestions or potential improvements because I know this isn't perfect
but it is a noticable advancement.

Abstract

The general idea is that we have a single unifying database system
(LDAP) a single protocol for Sign-On (Kerberos) Name resolution (Bind
DNS) And a network File system (CIFS by care of Samba.)

Basically, Kerberos now acts as a single sign-on (SSO) facility for my
home network.

When you log in Linux Pluggable Authentication Modules (PAM) verify the
account's credibility via LDAP, and request a ticket from the Kerberos
Key Distribution Center. based on the Principal (Username and Password)
and Policies in the Kerberos Realm.

These are DNS Service records thaat help clients find their KDC without the need for client side configuration files. This is how clients detect servers without Broadcast discovery protocols like Netbios Message Block,. The reason this is important is because it elimanates the "replay" attack threat from the fact that Windows likes to Cache its passwords in SAM files (PWL Files in the 9x Series). Even without the User's knowlege.

Some things I want to draw attention to.

First, this is a Windows 2000 Style Port 445 CIFS (SMBX) connection between two Linux machines. NOT a port 139 NT4 Netbios Session (SMB) connection.

The second thing I want you to notice is the fact that both servers are doing SPENGO, also known as "Sign and Seal" In Windows 2003 Server.

Finally that it aquaired the valid Kerberos Principal and ticket, and did a valid Kerberos setup.

Sorry if I sound incoherent. I'm tired.

Re:Only 6 years

[mwood]

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.