Linux samba change password
smbpasswd [-a] [-c ] [-x] [-d] [-e] [-D debuglevel] [-n] [-r ] [-R ] [-m] [-U username[%password]] [-h] [-s] [-w pass] [-W] [-i] [-L] [username]
DESCRIPTION
This tool is part of the samba (7) suite.
The smbpasswd program has several different functions, depending on whether it is run by the root user or not. When run as a normal user it allows the user to change the password used for their SMB sessions on any machines that store SMB passwords.
By default (when run with no arguments) it will attempt to change the current user’s SMB password on the local machine. This is similar to the way the passwd(1) program works. smbpasswd differs from how the passwd program works however in that it is not setuid root but works in a client-server mode and communicates with a locally running smbd (8) . As a consequence in order for this to succeed the smbd daemon must be running on the local machine. On a UNIX machine the encrypted SMB passwords are usually stored in the default passdb backend.
When run by an ordinary user with no options, smbpasswd will prompt them for their old SMB password and then ask them for their new password twice, to ensure that the new password was typed correctly. No passwords will be echoed on the screen whilst being typed. If you have a blank SMB password (specified by the string «NO PASSWORD» in the smbpasswd file) then just press the key when asked for your old password.
smbpasswd can also be used by a normal user to change their SMB password on remote machines, such as Windows NT Primary Domain Controllers. See the ( -r ) and -U options below.
When run by root, smbpasswd allows new users to be added and deleted in the smbpasswd file, as well as allows changes to the attributes of the user in this file to be made. When run by root, smbpasswd accesses the local smbpasswd file directly, thus enabling changes to be made even if smbd is not running.
OPTIONS
This option specifies that the username following should be added to the local smbpasswd file, with the new password typed (type for the old password). This option is ignored if the username following already exists in the smbpasswd file and it is treated like a regular change password command. Note that the default passdb backends require the user to already exist in the system password file (usually /etc/passwd ), else the request to add the user will fail.
This option is only available when running smbpasswd as root.
This option can be used to specify the path and file name of the smb.conf configuration file when it is important to use other than the default file and / or location.
This option specifies that the username following should be deleted from the local smbpasswd file.
This option is only available when running smbpasswd as root.
This option specifies that the username following should be disabled in the local smbpasswd file. This is done by writing a ‘D’ flag into the account control space in the smbpasswd file. Once this is done all attempts to authenticate via SMB using this username will fail.
If the smbpasswd file is in the ‘old’ format (pre-Samba 2.0 format) there is no space in the user’s password entry to write this information and the command will FAIL. See smbpasswd (5) for details on the ‘old’ and new password file formats.
This option is only available when running smbpasswd as root.
This option specifies that the username following should be enabled in the local smbpasswd file, if the account was previously disabled. If the account was not disabled this option has no effect. Once the account is enabled then the user will be able to authenticate via SMB once again.
If the smbpasswd file is in the ‘old’ format, then smbpasswd will FAIL to enable the account. See smbpasswd (5) for details on the ‘old’ and new password file formats.
This option is only available when running smbpasswd as root.
debuglevel is an integer from 0 to 10. The default value if this parameter is not specified is zero.
The higher this value, the more detail will be logged to the log files about the activities of smbpasswd. At level 0, only critical errors and serious warnings will be logged.
Levels above 1 will generate considerable amounts of log data, and should only be used when investigating a problem. Levels above 3 are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic.
This option specifies that the username following should have their password set to null (i.e. a blank password) in the local smbpasswd file. This is done by writing the string «NO PASSWORD» as the first part of the first password stored in the smbpasswd file.
Note that to allow users to logon to a Samba server once the password has been set to «NO PASSWORD» in the smbpasswd file the administrator must set the following parameter in the [global] section of the smb.conf file :
null passwords = yes
This option is only available when running smbpasswd as root.
-r remote machine name
This option allows a user to specify what machine they wish to change their password on. Without this parameter smbpasswd defaults to the local host. The remote machine name is the NetBIOS name of the SMB/CIFS server to contact to attempt the password change. This name is resolved into an IP address using the standard name resolution mechanism in all programs of the Samba suite. See the -R name resolve order parameter for details on changing this resolving mechanism.
The username whose password is changed is that of the current UNIX logged on user. See the -U username parameter for details on changing the password for a different username.
Note that if changing a Windows NT Domain password the remote machine specified must be the Primary Domain Controller for the domain (Backup Domain Controllers only have a read-only copy of the user account database and will not allow the password change).
Note that Windows 95/98 do not have a real password database so it is not possible to change passwords specifying a Win95/98 machine as remote machine target.
-R name resolve order
This option allows the user of smbpasswd to determine what name resolution services to use when looking up the NetBIOS name of the host being connected to.
The options are :»lmhosts», «host», «wins» and «bcast». They cause names to be resolved as follows:
lmhosts : Lookup an IP address in the Samba lmhosts file. If the line in lmhosts has no name type attached to the NetBIOS name (see the lmhosts (5) for details) then any name type matches for lookup.
host : Do a standard host name to IP address resolution, using the system /etc/hosts , NIS, or DNS lookups. This method of name resolution is operating system depended for instance on IRIX or Solaris this may be controlled by the /etc/nsswitch.conf file). Note that this method is only used if the NetBIOS name type being queried is the 0x20 (server) name type, otherwise it is ignored.
wins : Query a name with the IP address listed in the wins server parameter. If no WINS server has been specified this method will be ignored.
bcast : Do a broadcast on each of the known local interfaces listed in the interfaces parameter. This is the least reliable of the name resolution methods as it depends on the target host being on a locally connected subnet.
The default order is lmhosts, host, wins, bcast and without this parameter or any entry in the smb.conf (5) file the name resolution methods will be attempted in this order.
This option tells smbpasswd that the account being changed is a MACHINE account. Currently this is used when Samba is being used as an NT Primary Domain Controller.
This option is only available when running smbpasswd as root.
This option may only be used in conjunction with the -r option. When changing a password on a remote machine it allows the user to specify the user name on that machine whose password will be changed. It is present to allow users who have different user names on different systems to change these passwords.
This option prints the help string for smbpasswd , selecting the correct one for running as root or as an ordinary user.
This option causes smbpasswd to be silent (i.e. not issue prompts) and to read its old and new passwords from standard input, rather than from /dev/tty (like the passwd(1) program does). This option is to aid people writing scripts to drive smbpasswd
This parameter is only available if Samba has been compiled with LDAP support. The -w switch is used to specify the password to be used with the ldap admin dn. Note that the password is stored in the secrets.tdb and is keyed off of the admin’s DN. This means that if the value of ldap admin dn ever changes, the password will need to be manually updated as well.
NOTE: This option is same as «-w» except that the password should be entered using stdin.
This parameter is only available if Samba has been compiled with LDAP support. The -W switch is used to specify the password to be used with the ldap admin dn. Note that the password is stored in the secrets.tdb and is keyed off of the admin’s DN. This means that if the value of ldap admin dn ever changes, the password will need to be manually updated as well.
This option tells smbpasswd that the account being changed is an interdomain trust account. Currently this is used when Samba is being used as an NT Primary Domain Controller. The account contains the info about another trusted domain.
This option is only available when running smbpasswd as root.
Run in local mode.
This specifies the username for all of the root only options to operate on. Only root can specify this parameter as only root has the permission needed to modify attributes directly in the local smbpasswd file.
NOTES
Since smbpasswd works in client-server mode communicating with a local smbd for a non-root user then the smbd daemon must be running for this to work. A common problem is to add a restriction to the hosts that may access the smbd running on the local machine by specifying either allow hosts or deny hosts entry in the smb.conf (5) file and neglecting to allow «localhost» access to the smbd.
In addition, the smbpasswd command is only useful if Samba has been set up to use encrypted passwords.
VERSION
This man page is part of version 4.15.0 of the Samba suite.
SEE ALSO
AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.
Источник
Linux.yaroslavl.ru
 |
Using Samba
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.
Encrypted or Non-encrypted
Windows 95 with SMB Update
Windows NT 4.0 before SP 3
Windows NT 4.0 after SP 3
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:
Samba, however, will not accept any users until the smbpasswd file has been initialized.
While Unix authentication has been in use for decades, including the use of telnet and rlogin access across the Internet, it embodies well-known security risks. Plaintext passwords are sent over the Internet and can be retrieved from TCP packets by malicious snoopers. However, if you feel that your network is secure and you wish to use standard Unix /etc/passwd authentication for all clients, you can do so, but you must disable encrypted passwords on those Windows clients that default to using them.
In order to do this, you must modify the Windows registry by installing two files on each system. Depending on the platform involved, the files are either NT4_PlainPassword.reg or Win95_PlainPassword.reg. You can perform this installation by copying the appropriate .reg files from the Samba distribution’s /docs directory to a DOS floppy, and running it from the Run menu item on the client’s Start Menu button. Incidentally, the Windows 95 .reg file works fine on Windows 98 as well.
After you reboot the machine, the client will not encrypt its hashed passwords before sending them to the server. This means that the plaintext-equivalent passwords can been seen in the TCP packets that are broadcast across the network. Again, we encourage you not to do this unless you are absolutely sure that your network is secure.
If passwords are not encrypted, you can indicate as much in your Samba configuration file:
Samba stores its encrypted passwords in a file called smbpasswd, which by default resides in the /usr/local/samba/private directory. The smbpasswd file should be guarded as closely as the passwd file; it should be placed in a directory to which only the root user has read/write access. All other users should not be able to read from the directory at all. In addition, the file should have all access closed off to all users except for root.
Before you can use encrypted passwords, you will need to create an entry for each Unix user in the smbpasswd file. The structure of the file is somewhat similar to a Unix passwd file, but has different fields. Figure 6.3 illustrates the layout of the smbpasswd file; the entry shown is actually one line in the file.
Here is a breakdown of the individual fields:
This is the username of the account. It is taken directly from the system password file.
This is the user ID of the account. Like the username, it is taken directly from the system password file and must match the user it represents there.
LAN Manager Password Hash
This is a 32-bit hexadecimal sequence that represents the password Windows 95 and 98 clients will use. It is derived by encrypting the string KGS!@#$% with a 56-bit DES algorithm using the user’s password (forced to 14 bytes and converted to capital letters) twice repeated as the key. If there is currently no password for this user, the first 11 characters of the hash will consist of the sequence NO PASSWORD followed by X characters for the remainder. Anyone can access the share with no password. On the other hand, if the password has been disabled, it will consist of 32 X characters. Samba will not grant access to a user without a password unless the null passwords option has been set.
NT Password Hash
This is a 32-bit hexadecimal sequence that represents the password Windows NT clients will use. It is derived by hashing the user’s password (represented as a 16-bit little-endian Unicode sequence) with an MD4 hash. The password is not converted to uppercase letters first.
This field consists of 11 characters between two braces ([]). Any of the following characters can appear in any order; the remaining characters should be spaces:
This account is a standard user account.
This account is currently disabled and Samba should not allow any logins.
This account has no password associated with it.
This is a workstation trust account that can be used to configure Samba as a primary domain controller (PDC) when allowing Windows NT machines to join its domain.
Last Change Time
This code consists of the characters LCT- followed by a hexidecimal representation of the amount of seconds since the epoch (midnight on January 1, 1970) that the entry was last changed.
There are a few ways you can add a new entry to the smbpasswd file:
You can use the smbpasswd program with the -a option to automatically add any user that currently has a standard Unix system account on the server. This program resides in the /usr/local/samba/bin directory.
You can use the addtosmbpass executable inside the /usr/local/samba/bin directory. This is actually a simple awk script that parses a system password file and extracts the username and UID of each entry you wish to add to the SMB password file. It then adds default fields for the remainder of the user’s entry, which can be updated using the smbpasswd program later. In order to use this program, you will probably need to edit the first line of the file to correctly point to awk on your system.
In the event that the neither of those options work for you, you can create a default entry by hand in the smbpasswd file. The entry should be entirely on one line. Each field should be colon-separated and should look similar to the following:
This consists of the username and the UID as specified in the system password file, followed by two sets of exactly 32 X characters, followed by the account flags and last change time as it appears above. After you’ve added this entry, you must use the smbpasswd program to change the password for the user.
If you need to change the encrypted password in the smbpasswd file, you can also use the smbpasswd program. Note that this program shares the same name as the encrypted password file itself, so be sure not to accidentally confuse the password file with the password-changing program.
The smbpasswd program is almost identical to the passwd program that is used to change Unix account passwords. The program simply asks you to enter your old password (unless you’re the root user), and duplicate entries of your new password. No password characters are shown on the screen.
You can look at the smbpasswd file after this command completes to verify that both the LAN Manager and the NT hashes of the passwords have been stored in their respective positions. Once users have encrypted password entries in the database, they should be able to connect to shares using encrypted passwords!
Having a regular password and an encrypted version of the same password can be troublesome when you need to change both of them. Luckily, Samba affords you a limited ability to keep your passwords synchronized. Samba has a pair of configuration options that can be used to automatically update a user’s regular Unix password when the encrypted password is changed on the system. The feature can be activated by specifying the unix password sync global configuration option:
With this option enabled, Samba will attempt to change the user’s regular password (as root ) when the encrypted version is changed with smbpasswd. However, there are two other options that have to be set correctly in order for this to work.
The easier of the two is passwd program . This option simply specifies the Unix command used to change a user’s standard system password. It is set to /bin/passw d %u by default. With some Unix systems, this is sufficient and you do not need to change anything. Others, such as Red Hat Linux, use /usr/bin/passwd instead. In addition, you may want to change this to another program or script at some point in the future. For example, let’s assume that you want to use a script called changepass to change a user’s password. Recall that you can use the variable %u to represent the current Unix username. So the example becomes:
Note that this program will be called as the root user when the unix password sync option is set to yes . This is because Samba does not necessarily have the plaintext old password of the user.
The harder option to configure is passwd chat . The passwd chat option works like a Unix chat script. It specifies a series of strings to send as well as responses to expect from the program specified by the passwd program option. For example, this is what the default passwd chat looks like. The delimiters are the spaces between each groupings of characters:
The first grouping represents a response expected from the password-changing program. Note that it can contain wildcards (*), which help to generalize the chat programs to be able to handle a variety of similar outputs. Here, *old*password* indicates that Samba is expecting any line from the password program containing the letters old followed by the letters password , without regard for what comes on either side or between them. Once instructed to, Samba will wait indefinitely for such a match. Is Samba does not receive the expected response, the password will fail.
The second grouping indicates what Samba should send back once the data in the first grouping has been matched. In this case, you see %o\n . This response is actually two items: the variable %o represents the old password, while the \n is a newline character. So, in effect, this will «type» the old password into the standard input of the password changing program, and then «press» Enter.
Following that is another response grouping, followed by data that will be sent back to the password changing program. (In fact, this response/send pattern continues indefinitely in any standard Unix chat script.) The script continues until the final pattern is matched.[2]
[2] This may not work under Red Hat Linux, as the password program typically responds «All authentication tokens updated successfully,» instead of «Password changed.» We provide a fix for this later in this section.
You can help match the response strings sent from the password program with the characters listed in Table 6.6. In addition, you can use the characters listed in Table 6.7 to help formulate your response.
Zero or more occurrences of any character.
Allows you to include matching strings that contain spaces. Asterisks are still considered wildcards even inside of quotes, and you can represent a null response with empty quotes.
The user’s old password
The user’s new password
The linefeed character
The carriage-return character
The tab character
For example, you may want to change your password chat to the following entry. This will handle scenarios in which you do not have to enter the old password. In addition, this will also handle the new all tokens updated successfully string that Red Hat Linux sends:
Again, the default chat should be sufficient for many Unix systems. If it isn’t, you can use the passwd chat debug global option to set up a new chat script for the password change program. The passwd chat debug option logs everything during a password chat. This option is a simple boolean, as shown below:
After you activate the password chat debug feature, all I/O received by Samba through the password chat will be sent to the Samba logs with a debug level of 100, which is why we entered a new log level option as well. As this can often generate multitudes of error logs, it may be more efficient to use your own script, by setting the passwd program option, in place of /bin/passwd to record what happens during the exchange. Also, make sure to protect your log files with strict file permissions and to delete them as soon as you’ve grabbed the information you need, because they contain the passwords in plaintext.
The operating system on which Samba is running may have strict requirements for valid passwords in order to make them more impervious to dictionary attacks and the like. Users should be made aware of these restrictions when changing their passwords.
Earlier we said that password synchronization is limited. This is because there is no reverse synchronization of the encrypted smbpasswd file when a standard Unix password is updated by a user. There are various strategies to get around this, including NIS and freely available implementations of the pluggable authentication modules (PAM) standard, but none of them really solve all the problems yet. In the future, when Windows 2000 emerges, we will see more compliance with the Lightweight Directory Access Protocol (LDAP), which promises to make password synchronization a thing of the past.
The options in Table 6.8 will help you work with passwords in Samba.
Источник
