Authentication in Samba

In this second part of a four-part series on handling authentication and authorization in Samba, you will learn about pluggable authentication modules, a challenge/response authentication algorithm developed by Microsoft, and more. This article is excerpted from chapter five of Using Samba, Third Edition, written by Gerald Carter, Jay Ts and Robert Eckstein (O’Reilly, 2007; ISBN: 0596007698). Copyright © 2007 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

Pluggable Authentication Modules (PAM)

Pluggable Authentication Modules (PAM) are shared libraries that can be used in combination to allow an administrator to enforce a specific authentication security policy. For a complete discussion of PAM, first try searching your server’s operating system documentation. Another good source of information is the Linux PAM web site at http://www.kernel.org/pub/linux/libs/pam.

Each PAM module implements one or more of the following functions:

auth
  
User authentication requests

account
  
User account handling, such as password
      expiration and denying locked accounts

session
  
User management related to this specific session,
      such as logging user activity to the system’s utmp 
      file

password
     User password change requests

Samba is able to use PAM to authenticate users and enforce certain authorization controls based on the the configuration of the samba PAM service. On some platforms, such as Solaris, all services are configured in a single configuration file named /etc/pam.conf. On Linux hosts, these settings will be stored in /etc/pam.d/samba. The following configuration instructs the PAM library to verify that the server is not rejecting logins (i.e., the /etc/nologin file does not exist) and then validate the user against /etc/passwd:

  ## /etc/pam.d/samb a
  auth    requisite     pam_nologin.so
  auth    require       pam_unix.so

Our focus is not on PAM configuration specifics, but rather on how Samba, and smbd in particular, interacts with PAM. First it is necessary to verify that Samba was compiled to include the –with-pam configure option. The build output from smbd -b should include the WITH_PAM string if this is the case.

  $ smbd -b | grep WITH_PAM
     
WITH_PAM

If this check fails, return to Chapter 2 and rebuild Samba to include PAM support. You may also need to install additional software to get the PAM development files (e.g., the pam-devel package).

Once you have a PAM-aware version of smbd, it will require a properly configured /etc/pam.d/samba file. Samba makes use of the auth settings in its PAM configura tion file only if clients use clear-text passwords. If the encrypt passwords parameter has been enabled, the auth PAM module lines are ignored completely. However, it is possible to still make use of the remaining three PAM functions. The account and session settings are respected if the obey pam restrictions options is enabled in smb.conf. Any user password change requests that must be synchronized between Samba’s and the operating system’s list of users will pass through the PAM stack if pam password change = yes . Password synchronization is covered later in this chapter, so we will delay the complete discussion until then. Table 5-5 summarizes these two options and their default settings.

Table 5-5. PAM-related parameters

Parameter Value Description Default Scope
obey pam restrictions boolean

Controls whether smbd respects the account and session PAM configuration settings.

no Global
pam password change boolean If enabled, smbd will, upon receiving a password change request, use PAM for synchronizing a user’s Unix credentials. no Global

{mospagebreak title=NTLMv1} 

NTLM is the challenge/response authentication algorithm developed by Microsoft and utilized by Windows and other CIFS clients and servers. In the original implementations of NTLM, the client uses a hashed version of the user’s password to generate a 24-byte response to a challenge returned by the server in the negotiate protocol reply. The actual details of the algorithm are not important from the point of view of a systems administrator.* The key facts to remember are:

  1. The hashed password is never sent over the wire.
  2. The user’s password hash is a shared secret used to calculate the response. If the client’s and the server’s calculated response match, it proves that both knew the same initial password hash.
  3. Both the LanManager and NT password hashing algorithms do not use any salt. Therefore a string always produces the same LanMan and NT hashes.

The last point is important to remember, because it implies that the password hash is a plain-text equivalent. If an attacker were to uncover a user’s password hash, he could impersonate that user without deriving the original clear-text string. Even so, many users reuse a single password for multiple services (email, banking accounts, and so on). Given that the LanMan password is limited to 14 uppercase characters and possesses a very weak hashing algorithm, protecting Samba’s account database becomes extremely important.

Enabling NTLMv1 authentication in Samba is as simple as setting encrypt passwords = yes in the [global] section of smb.conf and then creating user accounts using either smbpasswd or the pdbedit utility, introduced in Chapter 2. When adding a new user, if the password is less than or equal to 14 characters in length, Samba stores two password hashes. Following is an entry from an smbpasswd file for a user named lizard with a password of test. The first string of hexadecimal digits is the LanMan hash followed by the NT password hash. Each field is separated by a colon. The line has been wrapped due to space limitations and appears as one line in your smbpasswd file.

 lizard:1004:01FC5A6BE7BC6929AAD3B435B51404EE :
   0CB6948805F797BF2A82807973B89537:[U        ]:LCT-44528BD2:

If the user’s password is longer than 14 characters, the LanMan hash is disabled so that the security value of the password is not degraded by storing a truncated version. A dis abled password is represented by a string of Xs. This is what lizard’s smbpasswd entry would look like with a password of somepasswordstringlongerthanfourteen:

 lizard:1009:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX :
   0FF1DFDA18B63EC50E1FD9ECFCDFDE05:[U        ]:LCT-44528C6B:

It is possible to disable a Samba server’s use of LanManager passwords altogether by setting the lanman auth option to no in the [global] service.

Table 5-6 summarizes the smb.conf parameters related to NTLMv1 authentication.

Table 5-6. NTLMv1-related parameters

Parameter Value Description Default Scope
encrypt passwords boolean Controls whether Samba advertises support for NTLM authentication. yes Global
lanman auth boolean Determines whether smbd should attempt to validate NTLM responses using the LanManager password hash. yes Global

NTLMv2

NTLMv2 is a variant of the original NTLM authentication scheme, and was introduced in Windows NT 4.0 SP4. However, it has seemed to gain any semblance of widespread adoption only in conjunction with Active Directory deployments. Its main advantage over NTLMv1 is protection against man-in-the-middle and replay attacks. As with NTLMv1, the actual protocol details are unimportant for day-to-day system administration duties.

Supporting NTLMv2 on Samba servers is a process of disabling support for the older authentication protocols. The following [global] section snippet illustrates the use of the lanman auth and ntlm auth parameters:

  [global]
     
## Enable support for only NTLMv2 on the server
     
encrypt passwords = yes
     
lanman auth = no
     
ntlm auth = no

Unlike many other client and server capabilities, support for NLTMv2 cannot be negotiated. If a client sends an NTLMv2 response, Samba always uses that. However, unless the older, less secure authentication schemes are disabled on the clients as well, NTLMv2 does very little to help improve the overall security of a system, primarily because both the NTLMv1 and NTLMv2 client responses are created using the NT password hash. The situation is comparable to restricting 9 out of your 10 hosts to SSH access but allowing Telnet access to the remaining tenth host. Security is only as strong as its weakest link.

Table 5-7 summarizes the parameters needed to restrict access to using NTLMv2 authentication only.

Table 5-7. NTLMv2-related parameters

Parameter Value Description Default Scope
ntlm auth boolean

Controls whether Samba should validating using the NTLMv1 24-byte response. This parameter should be disabled, along with the lanman auth option, to enforce use of NTLMv2.  

yes Global

{mospagebreak title=User Management}

Any discussion about authentication is fruitless without including the topic of users. After all, the users are the ones being authenticated. As early as Chapter 2 we have seen some basic utilities that can be used to create a user account (i.e., the smbpasswd tool). However, we have not really talked about what the smbpasswd and similar utilities actually do. Here we break the discussion into two parts. We cover the various ways that user account information can be stored, followed by a explanation of the user management tools provided by Samba. First, we expand upon the discussion of Windows SIDs that we started in Chapter 1.

Security Identi?ers

A Windows security identifier (SID) is a collection of numbers combined into a binary blob that uniquely identifies an object such as a user, group, or computer. The common string representations of a SID is written as:

  S-1-5-21-3489264249-1556752242-1837584028-1003

It is impossible to determine what type of object the SID represents by its value alone. It could be a user or a group or something else. Windows (and Samba) provide calls to convert this SID to a name and to obtain its type.

The structure of a SID can be broken down into four parts:

  1. The revision (S-1)
  2. The number of authorities and subauthorities (5)
  3. The top-level authority (21)
  4. One or more subauthorities (3489264249-1556752242-1837584028-1003)

The last 32-bit number in the list of subauthorities is referred to as a relative identifier (RID). To be completely accurate, each 32-bit number of the subauthority list is a RID, but generally people use the term only to refer to the last number in the list. In this example, the RID is 1003.

Removing the RID from the original SID leaves us with an identifier that represents the SID’s security domain. A security domain is not necessarily the same thing as an authentication domain (as discussed in Chapter 1), although there is a relationship between the two. In our example, the security domain would be S-1-5-21-3489264249-1556752242-1837584028. Each Windows host has a machine SID that defines its local domain. On domain controllers, the domain SID is identical to the local machine SID.

You can view Samba’s local machine SID by logging on as root and running the net command from a shell prompt.

  root# net getlocalsid
  SID for domain RAIN is: S-1-5-21-3489264249-1556752242-1837584028

The concepts of local and foreign security domains do not neatly match up to Unix hosts, which have one authentication domain, based on an entry in /etc/passwd. Even when a network of hosts is configured to be part of an NIS domain (which should not be confused with a Microsoft domain), there is no distinction between users within the NIS map and those existing in the local /etc/passwd file.

From the Windows GUI, the distinction between local and remote domains can be seen from the initial logon box. Figure 5-1 shows the drop-down list of domains available when logging onto a Windows XP client. The local Administrator account is distinguished from the Administrator account in a foreign domain by prefacing the username with either the local machine’s name (LETTUCEAdministrator) or the name of the foreign domain (ADAdministrator). These are two different user accounts with different SIDs, even though they share the same login name of Administrator.


Figure 5-1.  Selecting the domain when logging onto a Windows XP client

In addition to the local machine security domain, all Windows and Samba hosts are expected to support the S-1-5-32 domain, which is called BUILTIN . Groups existing within this domain have predefined RIDs. For example, the BUILTINAdministrators group has a SID of S-1-5-32-544 and the BUILTINUsers group’s SID is S-1-5-32-545.

More information on SIDs and authentication domains is presented in Chapters 9 and 10.

{mospagebreak title=Account Storage}

Samba exposes Unix objects—files, printers, users and groups—in a way that Windows clients understand. It is necessary, however, for Samba to store some additional attributes for users beyond the information in /etc/passwd. These attributes, such as the LanMan and NT password hashes, the user’s SID, and a home directory UNC path, are maintained in what is referred to as a passdb backend . This storage facility can currently take one of three forms:

  1. A flat text file
  2. A trivial database (tdb) file
  3. An LDAP directory service

The passdb backend parameter is a global option whose value is in the form name: argument[,argument] . The Samba code for passdb is written such that new storage modules can be written by the community. However, in this chapter, we concern ourselves with only three, which are distributed as part of the core Samba source code: smbpasswd , tdbsam , and ldapsam . Because each passdb module has its own list of supported options, we discuss possible argument values later, after we have covered each backend in depth. Frequently, arguments can be omitted in order to rely on the passdb module’s default behavior. If no backend is specified in smb.conf, Samba defaults to using an smbpasswd file.

passdb backend = smbpasswd

We have seen the structure of an entry from an smbpasswd file earlier in this chapter. Although the file’s format changed between Samba 1.9 and 2.0, smbpasswd is the original account storage mechanism used by Samba and still the recommended solution for most standalone servers. Additional storage facilities were not officially supported until Samba 3.0.* The structure of an smbpasswd entry is:

 username:uid:lanman_hash:nt_hash:flags:pw_lct

The fields are defined as follows:

username 

The user’s login name.

uid

The Unix numeric uid of the user. This field is currently ignored by Samba, because the value is obtained by querying the operating system instead.

lanman_hash
nt_hash

The user’s password hashes, represented as 32-character hexadecimal strings. A string of 32 Xs indicates an invalid password. A value of the string “NO PASSWORD” followed by 21 Xs in the lanman_hash  indicates that no password has been associated with this account. Accounts with no passwords are allowed access only if the null passwords option (Table 5-8) is enabled in the [global] section of smb.conf.

flags

Various single-character flags representing the type and state of the user’s account. The complete list of account flags is in Table 5-9.

pw_lct

The Unix timestamp of the user’s last successful password change, encoded as a hexadecimal string.

Table 5-8. Null passwords option

Parameter

Value

Description

Default

Scope

null passwords

boolean

Determines whether Samba allows connections using accounts with no associated password hash and possessing the Naccount flag.

no

Global

Table 5-9. User account flags supported by Samba

Flags Description
D Account is disabled.
I Interdomain trust account.
L The account has been autolocked due to bad login attempts.
N

No password is required by this account. This flag is honored only if the null passwords global parameter is enabled. 

S Backup domain controller trust account.
U User account.
W Workstation trust account.
X The associated password will not expire, regardless of the server’s password policy settings.

The following example configures Samba to use an smbpasswd text file for account storage:

  [global]
     
security = user
     
encrypt passwords = yes
     
passdb backend = smbpasswd

The file’s default location is set at compile time and can be determined by entering smbd -b | grep SMB_PASSWD_FILE . If you wish to assign a different location, append a colon and the desired absolute path to the smbpasswd module name:

  passdb backend = smbpasswd:/etc/smbpasswd

passdb backend = tdbsam

The TDB passdb backend, named tdbsam , expands upon the list of user attributes supported by the smbpasswd backend. tdbsam is the recommended method for storing accounts for a single Samba primary domain controller that does not share its users and groups with any Samba backup domain controllers. The full discussion of Samba domains is provided in Chapter 9. For now, it is sufficient to understand that a tdbsam is a database variant of smbpasswd with support for a richer set of attributes.

The default tdbsam database filename is passdb.tdb and is located in the /usr/local/samba/private directory. For custom Samba installations, you can determine this location by running smbd -b | grep PRIVATE_DIR . If you wish to change that location at runtime, tdbsam accepts, as its only argument, the absolute path to a tdb file:

  passdb backend = tdbsam:/etc/passdb.tdb

Please check back next week for the continuation of this article.

[gp-comments width="770" linklove="off" ]

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort