Section 10.5. Additional Winbind Features

10.5. Additional Winbind Features

Winbind is most known for its ability to create Unix accounts for Windows domain users and groups. However, it possesses some lesser-known but equally useful functionality. These features can further help you consolidate authentication, unify authorization controls, and provide accounts in Samba domains for trusted domain users and groups.

10.5.1. PAM and Domains

Winbind's PAM interface provides Unix services other than Samba a means to authenticate domain users. Consider the case of providing domain users access to an IMAP or POP mail server without requiring a second password. Any Unix service using PAM authentication may be configured to support domain credentials in this manner. We'll use an OpenSSH server as an example, due to its pervasiveness in Unix networks.

It may seem obvious, but we must remind you to verify that the Unix service in question has been compiled to include PAM support. Few things are more frustrating than spending a hour in attempt to deduce why the server is not recognizing the PAM changes and finally realizing that the configuration file is being completely ignored. Vendors usually provide documentation regarding the features that were enabled when the software was built. In the absence of this, a quick check with ldd or the strings utility will indicate whether a binary has been linked with libpam.so:

 $ ldd /usr/sbin/sshd | grep pam          libpam.so.0 => /lib/libpam.so.0 (0x4008f000) $ strings /usr/sbin/sshd | grep pam  pam_get_item pam_getenvlist pam_end pam_chauthtok pam_authenticate  <...remaining output deleted...> 

If both of these checks fail to return any output, there's a high probability that the server does not include PAM support. If that is the case, you may be able to find an updated package from your OS vendor or, if all else fails, to recompile the server software yourself.

It is also a good idea to verify that any runtime PAM configuration settings are turned on as well. For example, OpenSSH requires that the UsePAM option be enabled in its configuration file (usually /etc/ssh/sshd_config):

 UsePAM yes 

If you make any changes to the sshd_config file, make sure to send a HUP signal to sshd so that it will reload its configuration.

Once you know that the server is honoring its PAM configuration file, you can add the pam_winbind library to the stack. For OpenSSH, this means editing either /etc/pam.conf or /etc/pam.d/ssh (depending on your server's operating system) and adding a line to the list of auth modules. The following snippet from /etc/pam.d/ssh on a SUSE Linux host specifies that sshd will attempt to authenticate the user against local files first and fall back to Winbind if this fails:

 auth  sufficient   pam_unix2.so auth  required     pam_winbind.so  use_first_pass 

pam_winbind also supports the PAM account module type. This configuration from /etc/pam.d/ssh at least verifies that your libnss_winbind is functioning properly:

 account sufficient        pam_unix2.so account required          pam_winbind.so 

Now let's take another look at the getpwnam( ) reply returned by winbindd that was presented earlier:

 EDEN\leezard:*:10000:10002:Lee Zard:/home/EDEN/leezard:/bin/false 

Winbind fills in the home directory location (here, /home/EDEN/leezard) from the template homedir parameter (assuming that you use an idmap backend other than the ad plug-in). But Winbind does not verify that the directory path exists or attempt to create it. These jobs are commonly handled by another PAM module or some means outside of PAM. For ease of use, our example configuration loads the pam_mkhomedir module as part of the session configuration to create the user's home directory and populate it with basic shell initialization files:

 session required   pam_unix2.so session required   pam_mkhomedir.so  skel=/etc/skel/ umask=0022 

The pam_unix2 library performs auditing, such as writing session information to the system's utmp logs.

The pam_winbind library is omitted from this section of /etc/pam.d/ssh, because it does not implement PAM session support.

Before anyone attempts to log in, you must give users a valid shell. Set the template shell parameter to whatever shell you prefer:

     template shell = /bin/bash 

After restarting winbindd, verify that the parameter has taken effect:

 $ getent passwd "EDEN\leezard" EDEN\leezard:*:10000:10002:Lee Zard:/home/EDEN/leezard:/bin/bash 

Now we can finally log in to the server zero using an SSH client:

 $ ssh -l "eden\leezard" zero Password: <password for leezard> Creating directory '/home/EDEN/leezard'. Creating directory '/home/EDEN/leezard/Documents'. Creating directory '/home/EDEN/leezard/public_html'. Have a lot of fun... EDEN\leezard@zero:~> whoami EDEN\lizard EDEN\leezard@zero:~> id uid=10004(EDEN\leezard) gid=10002(EDEN\domain users) groups=10002(EDEN\domain users),10015(EDEN\linux admins) 

If the login fails, enable additional debugging in sshd and examine its logfiles. You can also make pam_winbind generate additional debugging information by passing it the debug parameter as part of the PAM configuration. The discussion of tracing processes presented Chapter 12 may also be of use in this case.

Some users find typing the fully qualified DOMAIN\username login string to be annoying or just confusing. Although there is no cure for this for users in trusted domains, it is possible to instruct Winbind to assume its own domain if one is not specified when authenticating non-Samba services. This is done by enabling the winbind use default domain global option, shown in Table 10-7, in smb.conf:

     winbind use default domain = yes 

Table 10-7. Winbind PAM option

Parameter	Value	Description	Default	Scope
winbind use default domain	boolean	If enabled, Winbind assumes that unqualified user and group names are to be looked up in the domain to which it has been joined.	no	Global

The user EDEN\leezard can now log on to the server by simply executing ssh leezard@zero. Table 10-7 summarizes this configuration option.

Of course, you may not wish to allow all domain users to log in to your Unix server. The require_membership_of option allows you to specify the SID of a group to which the user must belong in order for the authentication to succeed. Remember that you can use wbinfo -n to resolve a domain account name to a SID. For example, here we obtain the SID for the EDEN\Linux Admins group:

 $ wbinfo -n "EDEN\linux admins" S-1-5-21-4200961138-2496335650-1239021823-1209 Domain Group (2) 

We can then add this SID to the auth line for pam_winbind to prevent anyone who is not a member of EDEN's Linux Admins domain group from logging on via SSH. The pam_winbind configuration line has been wrapped for readability:

 auth  sufficient   pam_unix2.so auth  required     pam_winbind.so  use_first_pass    require_membership_of=S-1-5-21-4200961138-2496335650-1239021823-1209 

pam_winbind also supports changing of a user's domain password. We can let the /etc/pam.d/passwd file set the credentials for either a local account or a domain account by specifying the follow two lines:

 password  sufficient  pam_unix2.so password  required    pam_winbind.so 

We'll conclude this section with Table 10-8, which gives a complete list of pam_winbind's configuration parameters.

Table 10-8. pam_winbind options

Parameter	Description
debug	Enable additional log messages from pam_winbind.
require_membership_of=SID require-membership-of=SID	Restrict authentication to users belonging to a specific domain group.
try_first_pass	Attempt to use the initial password entered by the user before prompting for new credentials.
unknown_ok	Ignore any failures for users who cannot be found via getpwnam( ) calls. This option is relevant only in the account module configuration.
use_authtok	Use PAM's authentication token when changing passwords.
use_first_pass	Use only the initial password entered by the user. Do not prompt for new credentials if the initial one cannot be validated.

10.5.2. Local Nested Groups

Windows offers several types of groups. We won't attempt to explain all of them, but it is important to understand how local groups function in order to understand Samba's implementation of them.

Under Windows NT 4.0, a local group (sometimes referred to as an alias) was local to a machine or group of domain controllers. The local group existed under the domain of the local machine's SID. Microsoft extended this model in AD and made local groups defined on the domain controllers available to all domain members. Samba implements the Windows NT 4.0 model of local groups.

The important feature that makes local groups attractive is that they can contain local users, domain users, or domain groups. This is how all Domain Admins gain administrative access to machines joined to a domain. The Windows client adds the Domain Admins group to the local Administrators group upon joining the domain. Figure 10-4 shows the EDEN\Domain Admins group as a member of the Administrators group on a Windows XP member server.

Figure 10-4. Local Administrators group on a Windows XP client containing Domain Admins group

Winbind provides Samba's support for local group nesting by creating Unix groups in its idmap table and unrolling the group membership before returning a list of users via NSS. In other words, Samba returns a single flat list of users, even if some of those users were buried in various nested group memberships.

You must begin with a working Winbind installation using the tdb or ldap idmap backend. This means that the idmap uid and gid ranges have been defined in smb.conf, the libnss_winbind library has been installed, /etc/nsswitch.conf has been updated for the Winbind services, and winbindd is successfully answering requests.

Next, add the following line to Samba's configuration to turn on the local group feature and restart winbindd:

 [global]     winbind nested groups = yes 

Use the lusrmgr.msc tool from a Windows client to create a new group, as shown in Figure 10-5. You can add domain groups as members, as well as users. In the figure, we have added the EDEN\Linux Admins domain group and a local user named slug to the local ZERO\sysadmin groups.

Figure 10-5. Creating a local group on a Samba server with the Windows XP MMC

When we expand the group using the getent tool, the Linux Admins group has been expanded to its individual members: EDEN\leezard and EDEN\adam.

 $ getent group 'zero\sysadmin' ZERO\sysadmin:x:10011:slug,EDEN\lizard,EDEN\adam 

The real advantage of doing this, from a Unix administrator's perspective, is that you can now use the gid 10011 in filesystem ACLs or other Unix authorization policies and it will apply to members of the Linux Admins domain group. With a little imagination, you can find many ways to take advantage of group nesting on your servers. Table 10-9 finishes up our discussion regarding local groups with a brief summary of the new parameter presented.

Table 10-9. Winbind group nesting options

Parameter	Value	Description	Default	Scope
winbind nested groups	boolean	Enables Winbind's support for providing and expanding local group membership via NSS.	no	Global