10.2 Technical Information

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 Security

The 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:

• MS DOS Network client 3.0 with the basic network redirector installed.

• Windows 95 with the network redirector update installed.

• Windows 98 [Second Edition].

• Windows Me.

N OTE

MS Windows XP Home does not have facilities to become a Domain Member and it cannot participate in domain logons .

The following versions of MS Windows fully support domain security protocols.

• Windows NT 3.5x.

• Windows NT 4.0.

• Windows 2000 Professional.

• Windows 200x Server/Advanced Server.

• Windows XP Professional.

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

• Plaintext passwords are not passed across the network. Someone using a network sniffer cannot just record passwords going to the SMB server.

• Plaintext passwords are not stored anywhere in memory or on disk.

• Windows NT does not like talking to a server that does not support encrypted passwords. It will refuse to browse the server if the server is also in User Level security mode. It will insist on prompting the user for the password on each connection, which is very annoying. The only things you can do to stop this is to use SMB encryption.

• Encrypted password support allows automatic share (resource) reconnects.

• Encrypted passwords are essential for PDC/BDC operation.

10.2.1.2 Advantages of Non-Encrypted Passwords

• Plaintext passwords are not kept on disk, and are not cached in memory.

• Uses same password file as other UNIX services such as Login and FTP.

• Use of other services (such as Telnet and FTP) that send plain text passwords over the network, so sending them for SMB is not such a big deal.

10.2.2 Mapping User Identifiers between MS Windows and UNIX

Every 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 Machines

Samba-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:

^[1] http://www.padl.com

• nss_ldap: An LDAP Name Service Switch module to provide native name service support for AIX, Linux, Solaris, and other operating systems. This tool can be used for centralized storage and retrieval of UIDs/GIDs.

• pam_ldap: A PAM module that provides LDAP integration for UNIX/Linux system access authentication.

• idmap_ad: An IDMAP backend that supports the Microsoft Services for UNIX RFC 2307 schema available from their web site ^[2] .

  ^[2] http://www.padl.com/download/xad_oss_plugins.tar.gz