All great ideas are controversial, or have been at one time.
David
Lechnyr <david@lechnyr.com>
May
20, 2002
Once long ago, there was a buzzword referred to as "DCE/RPC". This stood for Distributed Computing Environment / Remote Procedure Calls, and conceptually was a good idea. Microsoft came along and decided to implement this concept in the form of SMB (Server Message Block, or the "what") using the NetBIOS (Network Basic Input/Output System, or the "how") compatibility layer. You can run SMB (i.e., transport) over several different protocols; many different implementations arose as a result, including NBIPX (NetBIOS over IPX, NwLnkNb, or NWNBLink) and NBT (NetBIOS over TCP/IP, or NetBT). As the years passed, NBT became the most common form of implementation until the advance of "Direct-Hosted TCP" -- the Microsoft marketing term for eliminating NetBIOS entirely and running SMB by itself across TCP only. As of yet, direct-hosted TCP has yet to catch on. And so the story goes...
Perhaps the best summary of the origins of SMB are voiced in the 1997 article
titled, CIFS: Common
Insecurities Fail Scrutiny: "Several megabytes of NT-security archives,
random whitepapers, RFCs, the CIFS spec, the Samba stuff, a few MS
knowledge-base articles, strings extracted from binaries, and packet dumps have
been dutifully waded through during the information-gathering stages of this
project, and there are *still* many missing pieces... While often tedious, at
least the way has been generously littered with occurrences of clapping hand to
forehead and muttering 'crikey, what are they *thinking*?!'"
--with-smbmount helps you to to avoid headaches later when you decide
you want to mount remote smb filesystems
--mandir changes the Samba
man page destination from the default of
/usr/local/samba/man/
--with-logfilebase changes the logfile
destination from the default of /usr/local/samba/logs/
$ cd /usr/local/src
$ wget http://us1.samba.org/samba/ftp/samba-2.x.y.tar.gz
$ wget http://us1.samba.org/samba/ftp/samba-2.x.y.tar.gz.md5
$ md5sum -c samba-2.x.y.tar.gz.md5
$ tar xzf samba-2.x.y.tar.gz
$ cd samba-2.x.y/source
$ ./configure --with-acl-support --with-logfilebase=/var/log/samba --with-smbmount --mandir=/usr/man
$ make
# make install
$ cd ../..
Samba's configuration file resides in /usr/local/samba/lib/smb.conf
and by default doesn't exist; you'll need to create it with your favorite
text editor. A good way to determine what the default values will be is to
create an empty smb.conf file (touch smb.conf), run testparm against it, and
grep for the value you're curious about. For those that just want to get
started, here's the quick & dirty smb.conf:
netbios name = server001
workgroup = myworkgroup
[public]
path = /home/public
read only = no
Below are a few of the more interesting configuration bits you might be interested in.
log level = 1 |
Useful for debugging. Leave at 0 for high-performance; 1 for normal monitoring (recommended and default); 2 or 3 for troubleshooting. |
log file = /var/log/%m.log |
Create one log file for each machine name that connects to your samba server |
interfaces = 192.168.0.0/16 127.0.0.1 |
Do you run your samba server on a machine that has a valid IP address to the Internet? For such a risky venture, you'll need to limit the interfaces on which Samba will run. Note: You'll still need to lock down your box, which isn't covered here! A common mistake is to set the interfaces line to the specific IP address of the box, when it is actually the IP subnet that your interface is on. If the /16 bit is confusing to you, you'll want to do some homework review on subnet masks. Always include the loopback (127.0.0.1) address. |
encrypt passwords = Yes |
I would, wouldn't you? Windows 95 and 95a clients may have problems here; in which case you'll need to do some more reading up on the Samba website regarding this. |
time server = Yes |
With this, you can have your clients issue a |
socket options = |
TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=4096
SO_SNDBUF=8192 Here's a nifty optimization trick: Set the socket options as above, and start Samba. Find a large file or create one yourself ( dd if=/dev/zero of=testfile count=1024 bs=1024).
Disable any of your client's anti-virus software, restart Samba, then take
the file and copy it to the server while timing how long it takes
(SO_RCVBUF). Restart Samba (to flush the memory cache) and
copy the file back to your workstation, timing the result
(SO_SNDBUFF). Lather, rinse, & repeat with different
values in increments/decrements of 1024. Find your optimum values for the
server and use them. |
logon script = %G.bat
domain logons = Yes
os level = 40
lm
announce = False
dns proxy = No
wins support = Yes
invalid users = root
@wheel
hide unreadable = Yes
hide files = /example.txt/*.bad/
veto
files = /*.exe/*.com/*.vbs/*.chm/riched20.dll/*.{*}/lost+found/
veto oplock
files = /*.mdb/*.MDB/
[homes]
comment = "%S Home Directory"
username = %S
writable =
yes
create mask = 0600
directory mask = 0700
only user =
Yes
browseable = No
[sample]
path = /example/sample1
valid users =
+usergroup
force group = +usergroup
writable = yes
create mask =
0660
directory mask = 0770
[netlogon]
path = /example/netlogon
admin users = sam
write
list = sam
To run as a Primary Domain controller (PDC), you will need the following entries added to your smb.conf file:
[global]
domain logons = yes
security = user
os level = 99
[netlogon]
path = /usr/local/samba/netlogon
First, on the Windows XP machine, must have a unique NetBIOS machine name that is not the same as any username. Then, make the following changes to the registry and reboot:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
On the Samba server, add an entry for the NetBIOS machine name of the client that will be joining the domain to the /etc/passwd file. You'll want to use a unique group id (gid) as well. Note the addition of the dollar sign ($) to the NetBIOS machine name. For example, if your machine's name was "pc14", the entry in the /etc/passwd file would be:
pc14$:x:400:400:Workstation:/dev/null:/bin/false
Next, add an entry for the machine into your SMB password file. The -m switch tells smbpasswd to treat this account as a machine account. Note the lack of the dollar sign ($) here.
/usr/local/samba/bin/smbpasswd -m -a pc14
And add another entry, if you haven't yet, for the only username that can join workstations to domains (at least, with the current version of Samba). Make sure to use a different password than the actual root account.
/usr/local/samba/bin/smbpasswd -a root
On the client computer, log in as the local Administrator. It won't consistently work if you log in as another user that also has Local Admin rights. Then open up the My Computer icon, select Tools, then Disconnect Network Drive. Disconnect all the connections that are on the Samba server. You might be suprised; some connections occur that never show up in the My Computer icon; you have to actually force the disconnection in this manner. Next, right-click on the My Computer icon and choose Properties, then the Computer Name tab. Click the "Change" button, select Domain, and enter the name of the domain that you are going to join. You'll be prompted for a username/password pair; enter the username of "root" and the root smb password. If this works, you'll be welcomed to the domain!
If this doesn't work, try rebooting and increase the logging level on your
Samba server to see which step you might be missing. Note that each workstation
must have an entry in the DNS and/or in the file /etc/hosts
(not /usr/local/samba/lib/lmhosts), or they won't be able to log
in.
This is a frequently asked question by system administrators wishing to secure remote SMB traffic. It is technically in the realm of SSH, but will be touched on briefly here. However, please note that even running SMB by itself without SSH over a 56k dialup line is still terribly slow to the point of frustration. If you don't have a high speed link, you probably don't even want to deal with tunneling over SSH as a result.
The good news is that tunneling works, even though you can only tunnel TCP. This works for both SMB NetBIOS and SMB Direct-Hosted. The unfortunate news is that due to a design limitation in the GUI API of Windows 95/98/ME, you'll only be able to perform your tunneled work in a MS-DOS window. Once you step outside of this and attempt to interact with your remote server via the GUI, you'll find 30-60 second periods where the computer will pause/hang, after which it will complain that the path is invalid or unavailable. One possible explanation is the 16/32-bit nature of this type of Windows OS, however there has yet to be a confirmation of this by either Microsoft or the Samba team. Those using the 32-bit Windows 2000/XP systems will not have this limitation whatsoever.
Since UDP tunneling is not available under SSH, on your Windows 2000/XP box
you'll need to create an entry in your
%systemroot%\System32\drivers\etc\LMHOSTS file:
127.0.0.1 FAKENAME #PRE
Where FAKENAME is a bogus NetBIOS name that you will use to
refer to your Samba server. This file will not be reread until you reboot unless
you issue the following command (note the uppercase-R):
nbtstat -R
Configure your client's SSH program to forward port 139/tcp to port 139/tcp on the server, and connect via SSH. Once done, open up a MS-DOS window and issue this command:
NET VIEW \\FAKENAME
Viola! It works, and you can confirm the encryption with a packet filter.
Microsoft mainly provides file and printer sharing via two different methods:
In general, SMB sessions are established in the following order:
Protocol dialects (from SMB Negotiate Protocol, step 3 above) are selected from one of the following:
In the Session Startup (step 4, above) Passwords are encrypted (or not) according to one of the following methods:
Linus Torvalds has this to say about Microsoft Windows:
"What's fundamentally wrong is that nobody ever had any taste when they did it. Microsoft has been very much into making the user interface look good, but internally it's just a complete mess. And even people who program for Microsoft and who have had years of experience, just don't know how it works internally. Worse, nobody dares change it. Nobody dares to fix bugs because it's such a mess that fixing one bug might just break a hundred programs that depend on that bug. And Microsoft isn't interested in anyone fixing bugsÂthey're interested in making money. They don't have anybody who takes pride in Windows 95 as an operating system. People inside Microsoft know it's a bad operating system and they still continue obviously working on it because they want to get the next version out because they want to have all these new features to sell more copies of the system. The problem with that is that over time, when you have this kind of approach, and because nobody understands it, because nobody REALLY fixes bugs (other than when they're really obvious), the end result is really messy. You can't trust it because under certain circumstances it just spontaneously reboots or just halts in the middle of something that shouldn't be strange. Normally it works fine and then once in a blue moon for some completely unknown reason, it's dead, and nobody knows why. Not Microsoft, not the experienced user and certainly not the completely clueless user who probably sits there shivering thinking "What did I do wrong?" when they didn't do anything wrong at all. That's what's really irritating to me."