Really Dire Warning. Due to severe implementation bugs of
the RC4 cipher as used by Microsoft whatever is stored in Windows and
Windows 95 .pwl files is crackable in a matter of seconds! I mean it
literally. I do not know about NT one way or another. If you value
your security do not store there your "real" passwords - ever! At a
minimum, one may disable "password caching" on Windows, but this,
although supported and entirely possible, may be somewhat of an
inconvenience to the users. The problem is that by default Windows
cache network passwords in files with the .pwl
extension in
the windows directory of the user's system. This file contains
encrypted versions of the passwords, but the encryption method used
(RC4) has been implemented very poorly, so it is possible to break the
encryption using a program which has been posted publicly on the
net. Of course, for someone to take advantage of this flaw, one would
have to have physical or filesystem access to the .pwl files on a
client machine.
Microsoft has acknowledged the problem, and has provided a patch for Windows 95 clients. This patch is supposed to fix the implementation problems, and also changes the cipher method to use a 128bit key, rather than the previously used 32 bit key. This should also provide a better level of protection from "brute force" attacks. One may obtain further information about this bug, locations of patches and other interesting reading on Microsoft security issues from:
To my best knowledge at the time of this writing the patch was available only for "US version" of Windows 95. A promised patch for "international" variants is still in a making. (One wonders about new RC4 width and U.S. cryptography export regulations, but this is pure speculation at this moment.)
Samba users need Unix accounts on a Samba server. These accounts can
be provided by the usual /etc/passwd
mechanism or may be
distributed with NIS ("yellow pages"). The server uses them to get
the information about uid number and groups to which users belong.
These accounts can be pretty minimal in the sense that Samba will be
quite happy with an entry which has '*' in a password field and
/bin/false
for a shell (`real' Unix logins with this type of
account will be impossible, obviously enough). Still one should be
careful with this advice if you have real security concerns. On many
machines (very popular on Linux systems) /bin/false
is a shell
script script. This may provide a foothold to a determined attacker.
It is advisable to replace it with a "true" compiled program (linked
statically if you use shared libraries).
Tim Baverstock, <warwick@mmm.co.uk>
, suggests to use
/bin/passwd
instead of /bin/false
. That way account
owners are free to modify passwords, without bothering sysadmin, by
telnetting to a server. To do the same for passwords used by Samba,
when you have them, make your smbpasswd
program (usually
located at /usr/local/samba/bin/smbpasswd
) into a "faux
shell"; /bin/passwd
"shell" can be very handy for POP-only
users, for example. In the later case '*' in a password field is
obviously counterproductive and a true thing has to be there.
When checking access to services, Samba may need also its own password
file. This happens only when you will set a global configuration
parameter encrypted passwords
to "yes". Passwords in this
file (/usr/local/samba/private/smbpasswd
for a default
installation) do not, or rather should not, have anything in common
with Unix passwords.
An ENCRYPTION writeup from the Samba distribution is required reading for this and provides detailed information. Pay attention to security issues.
Before compiling Samba with encryption support you will need an extra DES crypt library. Sources can be found at
WARNING: due to US Government regulations (ITAR) you cannot export this library (classified as munitions) from the U.S. to another country. It is totally immaterial that you imported it from abroad in the first place (and which is legal). The only exception to this rule is Canada, but Canada is also covered by regulations analogous to ITAR.
Before trying any manipulations with this file save a backup copy of it with the current information, maybe to smbpasswd.old
This file has a pretty strict format and typing entries with an editor
is not Great Fun. The script mksmbpasswd.sh
will
create a required skeleton from /etc/passwd
entries.
Another method, which allows adding selected accounts to
smbpasswd
at any time, consists of listing them as arguments
to the addtosmbpass
(awk) program. Feed it the old
(existing) smbpasswd information on stdin and the resulting rewrite
will be printed on stdout. When starting any empty file use
/dev/null
as input. An example usage may look like this:
addtosmbpass name1 name2 name3 name4 < smbpasswd.old > smbpasswdIf any of the argument names already occur in input then those will be skipped and that information will not change. Another advantage is that
addtosmbpass
, if needed. will search for necessary
information in NIS databases (if you run NIS authentication).
If remote password changing works (this is the case only for some
systems) and the password program
is configured to affect the
smbpasswd
utility, then a user may use that. Otherwise, a
user has to logon on the server and run smbpasswd
there -
similar to a normal passwd
program; non-root users can change
passwords only for themselves. If this is impossible then the System
Administrator has to perform this service for the user. This may be
better if you don't want to see user passwords such as "wageslave" or
"Chevrolet".
The default security is SHARE, which means that individual shares have
their own access passwords. Clients authenticate themselves on every
connection but do not send user names. Samba, being a Unix creature,
actually does only username/password checks. This means that it has
fudge things a bit by guessing names, going through a list of a
username
configuration parameter and checking against Unix
passwords (a detailed description in the smb.conf
manual
page is a required reading). Some clients do not allow for any other
security.
From a Unix point of view a more natural security level is USER. Pairs
username/password are validated once per session (unless the
revalidate
option on a share is set). Either
/etc/passwd
or smbpasswd
stores encrypted passwords.
See
How do I set accounts for Samba users
for more on that.
If you have a secure NT box on your network then you may designate it as the password server. With SERVER setting access check looks to clients the same as with security USER but passwords are passed for checks to another SMB server on the network. Currently Samba cannot act as a password server.
Starting with version 1.9.15p6 Samba distribution includes a longer writeup on SMB security levels. Please consult for more details.
When logging from a Windows client and with USER security a user will be using two passwords - one to get an access to the network and another to get shares from a server.
If these two passwords are the same then the server will not ask for a password the second time but it will accept an access as validated and it will show immediately the shares to browse, and network mounts defined in Filemanager or Explorer will normally be established.
If these passwords are different then a user will not be able to
browse before first login to a (known) share; the second password,
stored in smbpasswd
will have then been supplied.
See also
What security levels are available?
.
Passwords are not stored on Windows machines in a manner which could be called secure; neither physically nor cryptographically. It may be highly advisable to use different passwords for login to Samba server even if the method with two identical passwords is quite convenient.
Be also aware that screen-saver passwords on Windows side are usually trivial to bypass, leaving your unattended connections to a server much less secure than you may think. Publicly posted programs are available which will break a Windows screensaver password in the blink of an eye!
If a server does not use `encrypted passwords', in the sense given by
smb.conf
, the NT box will not browse it; it will also
repeatedly ask for passwords on every single connection. See also the
encryption remarks in
How do I set accounts for Samba users?
.
This is particularly relevant if a group of users works on the same
files and wants to share results. Set a special service available
for these users, make one of them an owner - in the Unix sense - of
everything and set the force user
property on this service
in the smb.conf
file. Setting permissions that way will apply
to all files and subdirectories of a chosen service.
In such a setup controlling who can write in a given moment to a file
becomes essential. Samba allows for locking
for a service.
If this is not enough than there is revision control software in the
MS-DOS world (for example "MKS Source Integrity", "PVCS") but it costs
real money. Depending on what, and how you are doing this, it may be money
very well spent.
Another option would be to use software like RCS or CVS on the Unix
side. This would require logging to a Unix host for checking files
in and out. See however also magic script
on
smb.conf
manual page.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter