4. User accounts Contents of this section 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: * http://www.c2.org/hackmsoft/ 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.) 4.1 How do I set accounts for Samba users 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, , 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 * ftp://nimbus.anu.edu.au/pub/tridge/libdes/libdes.tar.92-10.13.gz . 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. 4.2 How do I put accounts into smbpasswd file? 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 > smbpasswd If 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). 4.3 How do I change a Samba password? 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". 4.4 What security levels are available? 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. 4.5 Logging in from a client. 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! 4.6 Why does my NT machine misbehave with USER security level? 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? . 4.7 How do I share the same file/directory between a group of 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