Passwords are a thorny issue with Samba. So much so, in fact, that they are almost always the first major problem that users encounter when they install Samba, and generate by far the most questions sent to Samba support groups. In previous chapters, we've gotten around the need for passwords by placing the
guest
ok option in each of our configuration files, which allows connections without authenticating passwords. However, at this point, we need to delve deeper into Samba to discover what is happening on the network.
Passwords sent from individual clients can be either encrypted or non-encrypted. Encrypted passwords are, of course, more secure. A non-encrypted password can be easily read with a packet sniffing program, such as the modified
tcpdump program for Samba that we used in Chapter 3,
Configuring Windows Clients. Whether passwords are encrypted depends on the operating system that the client is using to connect to the Samba server.
Table 6.5 lists which Windows operating systems encrypt their passwords before sending them to the primary domain controller for authentication. If your client is not Windows, check the system documentation to see if SMB passwords are encrypted.
There are actually two different encryption methods used: one for Windows 95 and 98 clients that reuses Microsoft's LAN Manager encryption style, and a separate one for Windows NT clients and servers. Windows 95 and 98 use an older encryption system inherited from the LAN Manager network software, while Windows NT clients and servers use a newer encryption system.
If encrypted passwords are supported, Samba stores the encrypted passwords in a file called
smbpasswd. By default, this file is located in the
private directory of the Samba distribution (
/usr/local/samba/private). At the same time, the client stores an encrypted version of a user's password on its own system. The plaintext password is never stored on either system. Each system encrypts the password automatically using a known algorithm when the password is set or changed.
When a client requests a connection to an SMB server that supports encrypted passwords (such as Samba or Windows NT), the two computers undergo the following negotiations:
-
The client attempts to negotiate a protocol with the server.
-
The server responds with a protocol and indicates that it supports encrypted passwords. At this time, it sends back a randomly-generated 8-byte challenge string.
-
The client uses the challenge string as a key to encrypt its already encrypted password using an algorithm predefined by the negotiated protocol. It then sends the result to the server.
-
The server does the same thing with the encrypted password stored in its database. If the results match, the passwords are equivalent and the user is authenticated.
Note that even though the original passwords are not involved in the authentication process, you need to be very careful that the encrypted passwords located inside of the
smbpasswd file are guarded from unauthorized users. If they are compromised, an unauthorized user can break into the system by replaying the steps of the previous algorithm. The encrypted passwords are just as sensitive as the plaintext passwords - this is known as
plaintext-equivalent data in the cryptography world. Of course, you should also ensure that the clients safeguard their plaintext-equivalent passwords as well.
You can configure Samba to accept encrypted passwords with the following global additions to
smb.conf. Note that we explicitly name the location of the Samba password file:
[global]
security = user
encrypt passwords = yes
smb passwd file = /usr/local/samba/private/smbpasswd
Samba, however, will not accept any users until the
smbpasswd file has been initialized.
