These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

UNIX03/Securing Smbpasswd

Classnotes | UNIX03 | RecentChanges | Preferences
The smbpasswd file is required if you wish to use encrypted passwords on your Windows computers, which is the default since Windows 95 OSR-2 and Windows NT, patch level 3. You will need to have the directive 
 encrypt passwords = yes

in the smb.conf file.

The smbpasswd file consists of 6 different colon-deliminated fields:

  1. User name. This is an unencrypted Windows username. Case is not important.
  2. UNIX UID. This is the UID used to control file system permissions.
  3. LAN manager password. The user's password is used as salt against a determined character sequence to derive this entry.
  4. NT-password. The password is converted to Unicode and then encrypted using MD4.
  5. Account flags. This tells which type of account is being used.
    1. U = user account
    2. D = disabled
    3. N = an account with no password (dangerous)
    4. W = a workstation account used to configure Samb's Domain controller features
  6. The time from UNIX epoch when the last account update occured.

If you have the null passwords directive set in the smb.conf file, you should never see any accounts without passwords. As a system administrator, watch very carefully for these. In the book, on page 212 you will find a Perl script which will help you find null accounts quickly.

User Accounts

Every user that connects to the Samba server must have a user account. Never forget that underneath Samba is a UNIX box, and the access rules for Linux provide a foundation for Samba.

winbind

The winbind daemon is a recent addition to Samba (during the 2.2 series). It allows a Windows domain controller to function as the /etc/passwd and /etc/group file.

There are a few directives that need to be placed in the smb.conf file to enable this behaviour. Plus, you will need to start the winbind daemon before you start Samba. 

 [global]
   winbind uid = 1000-24999
   winbind gid = 25000-29999
   security = domain
   password server = PDC, BDC

These two directives control which UIDs and GIDs are assigned on the Linux system for accounts on the domain controller. You want to set these in a region which is well beyond whatever you may have set or will set for local Linux accounts. If you are attempting to use another authentication service (such as NIS) in conjunction with winbind, be certain that the ranges you specify for the various authentication systems do not overlap. If they do, you will get weird results and corrupt your security model.

If you plan to allow home directories on the Linux box while using winbind, you will be responsible for their creation prior to the user logging in. The template home dir directive in the global section will provide a way of automatically determining where the user's home directory will be located. Also, if you plan to use winbind, the default login shell is /bin/false. If your Windows users have any reason to log in directly to the machine (not through Samba), the parameter template shell will need to be changed to reflect this.

winbind and unmatched UIDs/GIDs

Another consideration about the winbind daemon is when running it on multiple Linux servers, even if you configure them in exactly the same way, the Linux UIDs and GIDs for the domain accounts are almost guaranteed not to match. (See example pg 224). There is no way to automatically fix this, and it becomes aw real issue if you are attempting to use winbind with another protocol (especially NFS) which requires syncronization between different authentications.

Classnotes | UNIX03 | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited June 7, 2003 4:06 am (diff)
Search:
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.