Old Windows clients send plain text passwords over the wire. Samba can check these passwords by encrypting them and comparing them to the hash stored in the UNIX user database. Newer Windows clients send encrypted passwords (so-called Lanman and NT hashes) over the wire, instead of plain text passwords. The newest clients will send only encrypted passwords and refuse to send plain text passwords, unless their registry is tweaked. These passwords can't be converted to UNIX-style encrypted passwords. Because of that, you can't use the standard UNIX user database, and you have to store the Lanman and NT hashes somewhere else. In addition to differently encrypted passwords, Windows also stores certain data for each user that is not stored in a UNIX user database. For example, workstations the user may logon from, the location where the user's profile is stored, and so on. Samba retrieves and stores this information using a passdb backend . Commonly available backends are LDAP, plain text file, and MySQL. For more information, see the man page for smb.conf regarding the passdb backend parameter. The resolution of SIDs to UIDs is fundamental to correct operation of Samba. In both cases shown, if winbindd is not running, or cannot be contacted, then only local SID/UID resolution is possible. See Figure 10.1 and Figure 10.2. Figure 10.1. IDMAP: Resolution of SIDs to UIDs.
Figure 10.2. IDMAP: Resolution of UIDs to SIDs.
10.2.1 Important Notes About SecurityThe UNIX and SMB password encryption techniques seem similar on the surface. This similarity is, however, only skin deep. The UNIX scheme typically sends cleartext passwords over the network when logging in. This is bad. The SMB encryption scheme never sends the cleartext password over the network but it does store the 16 byte hashed values on disk. This is also bad. Why? Because the 16 byte hashed values are a " password equivalent ." You cannot derive the user's password from them, but they could potentially be used in a modified client to gain access to a server. This would require considerable technical knowledge on behalf of the attacker but is perfectly possible. You should thus treat the datastored in whatever passdb backend you use (smbpasswd file, LDAP, MYSQL) as though it contained the cleartext passwords of all your users. Its contents must be kept secret and the file should be protected accordingly . Ideally, we would like a password scheme that involves neither plain text passwords on the network nor on disk. Unfortunately, this is not available as Samba is stuck with having to be compatible with other SMB systems (Windows NT, Windows for Workgroups, Windows 9x/Me). Windows NT 4.0 Service Pack 3 changed the default setting so plaintext passwords are disabled from being sent over the wire. This mandates either the use of encrypted password support or editing the Windows NT registry to re-enable plaintext passwords. The following versions of Microsoft Windows do not support full domain security protocols, although they may log onto a domain environment:
The following versions of MS Windows fully support domain security protocols.
All current releases of Microsoft SMB/CIFS clients support authentication via the SMB Challenge/Response mechanism described here. Enabling cleartext authentication does not disable the ability of the client to participate in encrypted authentication. Instead, it allows the client to negotiate either plain text or encrypted password handling. MS Windows clients will cache the encrypted password alone. Where plain text passwords are re-enabled through the appropriate registry change, the plain text password is never cached. This means that in the event that a network connections should become disconnected (broken), only the cached (encrypted) password will be sent to the resource server to effect an auto-reconnect. If the resource server does not support encrypted passwords the auto- reconnect will fail. Use of encrypted passwords is strongly advised. 10.2.1.1 Advantages of Encrypted Passwords
10.2.1.2 Advantages of Non-Encrypted Passwords
10.2.2 Mapping User Identifiers between MS Windows and UNIXEvery operation in UNIX/Linux requires a user identifier (UID), just as in MS Windows NT4/200x this requires a Security Identifier (SID). Samba provides two means for mapping an MS Windows user to a UNIX/Linux UID. First, all Samba SAM (Security Account Manager database) accounts require a UNIX/Linux UID that the account will map to. As users are added to the account information database, Samba will call the add user script interface to add the account to the Samba host OS. In essence all accounts in the local SAM require a local user account. The second way to effect Windows SID to UNIX UID mapping is via the idmap uid and idmap gid parameters in smb.conf . Please refer to the man page for information about these parameters. These parameters are essential when mapping users from a remote SAM server. 10.2.3 Mapping Common UIDs/GIDs on Distributed MachinesSamba-3 has a special facility that makes it possible to maintain identical UIDs and GIDs on all servers in a distributed network. A distributed network is one where there exists a PDC, one or more BDCs and/or one or more Domain Member servers. Why is this important? This is important if files are being shared over more than one protocol (e.g., NFS) and where users are copying files across UNIX/Linux systems using tools such as rsync . The special facility is enabled using a parameter called idmap backend . The default setting for this parameter is an empty string. Technically it is possible to use an LDAP based idmap backend for UIDs and GIDs, but it makes most sense when this is done for network configurations that also use LDAP for the SAM backend. A sample use is shown in Example 10.1. Example 10.1 Example configuration with the LDAP idmap backend[global] idmap backend = ldap:ldap://ldap-server.quenya.org:636 idmap backend = ldap:ldaps://ldap-server.quenya.org A network administrator who wants to make significant use of LDAP backends will sooner or later be exposed to the excellent work done by PADL Software. PADL http://www.padl.com [1] have produced and released to open source an array of tools that might be of interest. These tools include:
|