X-Git-Url: https://vcs.maemo.org/git/?p=samba;a=blobdiff_plain;f=docs%2Fhtmldocs%2FSamba3-HOWTO%2Fwinbind.html;fp=docs%2Fhtmldocs%2FSamba3-HOWTO%2Fwinbind.html;h=57dbe281f241671ea50fa3885887a7721956fe30;hp=0000000000000000000000000000000000000000;hb=6bca4ca307d55b6dc888e56cee47aebcddbce786;hpb=7fd70fa738b636089bcc6c961aa3eaa02f20dda2 diff --git a/docs/htmldocs/Samba3-HOWTO/winbind.html b/docs/htmldocs/Samba3-HOWTO/winbind.html new file mode 100644 index 0000000..57dbe28 --- /dev/null +++ b/docs/htmldocs/Samba3-HOWTO/winbind.html @@ -0,0 +1,1101 @@ +
Table of Contents
+ + + Integration of UNIX and Microsoft Windows NT through a unified logon has + been considered a “holy grail” in heterogeneous computing environments for + a long time. +
+ + + + + There is one other facility without which UNIX and Microsoft Windows network + interoperability would suffer greatly. It is imperative that there be a + mechanism for sharing files across UNIX systems and to be able to assign + domain user and group ownerships with integrity. +
+ + + + + winbind is a component of the Samba suite of programs that + solves the unified logon problem. Winbind uses a UNIX implementation of Microsoft + RPC calls, Pluggable Authentication Modules (PAMs), and the name service switch (NSS) to + allow Windows NT domain users to appear and operate as UNIX users on a UNIX + machine. This chapter describes the Winbind system, the functionality + it provides, how it is configured, and how it works internally. +
+ Winbind provides three separate functions: +
+ + + Authentication of user credentials (via PAM). This makes it possible to + log onto a UNIX/Linux system using user and group accounts from a Windows + NT4 (including a Samba domain) or an Active Directory domain. +
+ + + Identity resolution (via NSS). This is the default when winbind is not used. +
+
+
+
+
+
+
+
+ Winbind maintains a database called winbind_idmap.tdb in which it stores
+ mappings between UNIX UIDs, GIDs, and NT SIDs. This mapping is used only
+ for users and groups that do not have a local UID/GID. It stores the UID/GID
+ allocated from the idmap uid/gid range that it has mapped to the NT SID.
+ If idmap backend
has been specified as ldap:ldap://hostname[:389]
,
+ then instead of using a local mapping, Winbind will obtain this information
+ from the LDAP database.
+
+
+
+
+
+
+
+ If winbindd is not running, smbd (which calls winbindd) will fall back to
+ using purely local information from /etc/passwd
and /etc/group
and no dynamic
+ mapping will be used. On an operating system that has been enabled with the NSS,
+ the resolution of user and group information will be accomplished via NSS.
+
It is well known that UNIX and Microsoft Windows NT have + different models for representing user and group information and + use different technologies for implementing them. This fact has + made it difficult to integrate the two systems in a satisfactory + manner.
+ + + One common solution in use today has been to create + identically named user accounts on both the UNIX and Windows systems + and use the Samba suite of programs to provide file and print services + between the two. This solution is far from perfect, however, because + adding and deleting users on both sets of machines becomes a chore, + and two sets of passwords are required both of which + can lead to synchronization problems between the UNIX and Windows + systems and confusion for users.
We divide the unified logon problem for UNIX machines into + three smaller problems:
Obtaining Windows NT user and group information. +
Authenticating Windows NT users. +
Password changing for Windows NT users. +
+ + + Ideally, a prospective solution to the unified logon problem + would satisfy all the above components without duplication of + information on the UNIX machines and without creating additional + tasks for the system administrator when maintaining users and + groups on either system. The Winbind system provides a simple + and elegant solution to all three components of the unified logon + problem.
+ + + + + Winbind unifies UNIX and Windows NT account management by + allowing a UNIX box to become a full member of an NT domain. Once + this is done, the UNIX box will see NT users and groups as if + they were “native” UNIX users and groups, allowing the NT domain + to be used in much the same manner that NIS+ is used within + UNIX-only environments.
+ + + + + The end result is that whenever a + program on the UNIX machine asks the operating system to look up + a user or group name, the query will be resolved by asking the + NT domain controller for the specified domain to do the lookup. + Because Winbind hooks into the operating system at a low level + (via the NSS name resolution modules in the C library), this + redirection to the NT domain controller is completely + transparent.
+ + + Users on the UNIX machine can then use NT user and group + names as they would “native” UNIX names. They can chown files + so they are owned by NT domain users or even login to the + UNIX machine and run a UNIX X-Window session as a domain user.
+
+ The only obvious indication that Winbind is being used is
+ that user and group names take the form DOMAIN\user
and
+ DOMAIN\group
. This is necessary because it allows Winbind to determine
+ that redirection to a domain controller is wanted for a particular
+ lookup and which trusted domain is being referenced.
+ + + Additionally, Winbind provides an authentication service that hooks into the PAM system + to provide authentication via an NT domain to any PAM-enabled + applications. This capability solves the problem of synchronizing + passwords between systems, since all passwords are stored in a single + location (on the domain controller).
+ + Winbind is targeted at organizations that have an + existing NT-based domain infrastructure into which they wish + to put UNIX workstations or servers. Winbind will allow these + organizations to deploy UNIX workstations without having to + maintain a separate account infrastructure. This greatly + simplifies the administrative overhead of deploying UNIX + workstations into an NT-based organization.
+ + + Another interesting way in which we expect Winbind to + be used is as a central part of UNIX-based appliances. Appliances + that provide file and print services to Microsoft-based networks + will be able to use Winbind to provide seamless integration of + the appliance into the domain.
+ + The term foreign SID is often met with the reaction that it + is not relevant to a particular environment. The following documents an interchange + that took place on the Samba mailing list. It is a good example of the confusion + often expressed regarding the use of winbind. +
+ + Fact: Winbind is needed to handle users who use workstations that are NOT part + of the local domain. +
+ + Response: “Why? I've used Samba with workstations that are not part of my domains + lots of times without using winbind. I thought winbind was for using Samba as a member server + in a domain controlled by another Samba/Windows PDC.” +
+ + + + If the Samba server will be accessed from a domain other than the local Samba domain, or + if there will be access from machines that are not local domain members, winbind will + permit the allocation of UIDs and GIDs from the assigned pool that will keep the identity + of the foreign user separate from users that are members of the Samba domain. +
+ + + + + This means that winbind is eminently useful in cases where a single + Samba PDC on a local network is combined with both domain member and domain non-member workstations. + If winbind is not used, the user george on a Windows workstation that is not a domain + member will be able to access the files of a user called george in the account database + of the Samba server that is acting as a PDC. When winbind is used, the default condition + is that the local user george will be treated as the account DOMAIN\george and the + foreign (non-member of the domain) account will be treated as MACHINE\george because + each has a different SID. +
+ + + + + The Winbind system is designed around a client/server + architecture. A long-running winbindd daemon + listens on a UNIX domain socket waiting for requests + to arrive. These requests are generated by the NSS and PAM + clients and are processed sequentially.
The technologies used to implement Winbind are described + in detail below.
+ + + + + + Over the last few years, efforts have been underway by various Samba Team members to implement various aspects of + the Microsoft Remote Procedure Call (MSRPC) system. This system is used for most network-related operations + between Windows NT machines, including remote management, user authentication, and print spooling. Although + initially this work was done to aid the implementation of Primary Domain Controller (PDC) functionality in + Samba, it has also yielded a body of code that can be used for other purposes. +
+ + + + Winbind uses various MSRPC calls to enumerate domain users and groups and to obtain detailed information about + individual users or groups. Other MSRPC calls can be used to authenticate NT domain users and to change user + passwords. By directly querying a Windows PDC for user and group information, Winbind maps the NT account + information onto UNIX user and group names. +
+ + + + + Since late 2001, Samba has gained the ability to interact with Microsoft Windows 2000 using its “native + mode” protocols rather than the NT4 RPC services. Using LDAP and Kerberos, a domain member running + Winbind can enumerate users and groups in exactly the same way as a Windows 200x client would, and in so doing + provide a much more efficient and effective Winbind implementation. +
+ + + + + The NSS is a feature that is present in many UNIX operating systems. It allows system + information such as hostnames, mail aliases, and user information + to be resolved from different sources. For example, a standalone + UNIX workstation may resolve system information from a series of + flat files stored on the local file system. A networked workstation + may first attempt to resolve system information from local files, + and then consult an NIS database for user information or a DNS server + for hostname information.
+ + + + + + The NSS application programming interface allows Winbind + to present itself as a source of system information when + resolving UNIX usernames and groups. Winbind uses this interface + and information obtained from a Windows NT server using MSRPC + calls to provide a new source of account enumeration. Using standard + UNIX library calls, you can enumerate the users and groups on + a UNIX machine running Winbind and see all users and groups in + an NT domain plus any trusted domain as though they were local + users and groups.
+
+
+
+ The primary control file for NSS is /etc/nsswitch.conf
.
+ When a UNIX application makes a request to do a lookup,
+ the C library looks in /etc/nsswitch.conf
+ for a line that matches the service type being requested; for
+ example, the “passwd” service type is used when user or group names
+ are looked up. This config line specifies which implementations
+ of that service should be tried and in what order. If the passwd
+ config line is:
+
+passwd: files example +
+
+
+
+ then the C library will first load a module called
+ /lib/libnss_files.so
followed by
+ the module /lib/libnss_example.so
. The
+ C library will dynamically load each of these modules in turn
+ and call resolver functions within the modules to try to resolve
+ the request. Once the request is resolved, the C library returns the
+ result to the application.
+
+
+
+ This NSS interface provides an easy way for Winbind
+ to hook into the operating system. All that needs to be done
+ is to put libnss_winbind.so
in /lib/
+ then add “winbind” into /etc/nsswitch.conf
at
+ the appropriate place. The C library will then call Winbind to
+ resolve user and group names.
+ + + + + PAMs provide a system for abstracting authentication and authorization + technologies. With a PAM module, it is possible to specify different + authentication methods for different system applications without + having to recompile these applications. PAM is also useful + for implementing a particular policy for authorization. For example, + a system administrator may only allow console logins from users + stored in the local password file but only allow users resolved from + an NIS database to log in over the network.
+ + + + + + Winbind uses the authentication management and password + management PAM interface to integrate Windows NT users into a + UNIX system. This allows Windows NT users to log in to a UNIX + machine and be authenticated against a suitable PDC. + These users can also change their passwords and have + this change take effect directly on the PDC. +
+
+
+
+
+ PAM is configured by providing control files in the directory
+ /etc/pam.d/
for each of the services that
+ require authentication. When an authentication request is made
+ by an application, the PAM code in the C library looks up this
+ control file to determine what modules to load to do the
+ authentication check and in what order. This interface makes adding
+ a new authentication service for Winbind very easy: simply copy
+ the pam_winbind.so
module
+ to /lib/security/
, and the PAM
+ control files for relevant services are updated to allow
+ authentication via Winbind. See the PAM documentation
+ in PAM-Based Distributed Authentication, for more information.
+ + + + When a user or group is created under Windows NT/200x, + it is allocated a numerical relative identifier (RID). This is + slightly different from UNIX, which has a range of numbers that are + used to identify users and the same range used to identify + groups. It is Winbind's job to convert RIDs to UNIX ID numbers and + vice versa. When Winbind is configured, it is given part of the UNIX + user ID space and a part of the UNIX group ID space in which to + store Windows NT users and groups. If a Windows NT user is + resolved for the first time, it is allocated the next UNIX ID from + the range. The same process applies for Windows NT groups. Over + time, Winbind will have mapped all Windows NT users and groups + to UNIX user IDs and group IDs.
+ + + + + The results of this mapping are stored persistently in + an ID mapping database held in a tdb database. This ensures that + RIDs are mapped to UNIX IDs in a consistent way.
+ + + + + + An active directory system can generate a lot of user and group + name lookups. To reduce the network cost of these lookups, Winbind + uses a caching scheme based on the SAM sequence number supplied + by NT domain controllers. User or group information returned + by a PDC is cached by Winbind along with a sequence number also + returned by the PDC. This sequence number is incremented by + Windows NT whenever any user or group information is modified. If + a cached entry has expired, the sequence number is requested from + the PDC and compared against the sequence number of the cached entry. + If the sequence numbers do not match, then the cached information + is discarded and up-to-date information is requested directly + from the PDC.
+ + + +This section describes the procedures used to get Winbind up and +running. Winbind is capable of providing access +and authentication control for Windows Domain users through an NT +or Windows 200x PDC for regular services, such as telnet and ftp, as +well for Samba services. +
+ Why should I do this? +
+ + + + + This allows the Samba administrator to rely on the + authentication mechanisms on the Windows NT/200x PDC for the authentication + of domain members. Windows NT/200x users no longer need to have separate + accounts on the Samba server. +
+ Who should be reading this document? +
+ + + This document is designed for system administrators. If you are + implementing Samba on a file server and wish to (fairly easily) + integrate existing Windows NT/200x users from your PDC onto the + Samba server, this document is for you. +
+
+
+
+If you have a Samba configuration file that you are currently using, BACK IT UP!
+If your system already uses PAM, back up the /etc/pam.d
directory
+contents! If you haven't already made a boot disk, MAKE ONE NOW!
+
+
+
+
+Messing with the PAM configuration files can make it nearly impossible to log in to your machine. That's
+why you want to be able to boot back into your machine in single-user mode and restore your
+/etc/pam.d
to the original state it was in if you get frustrated with the
+way things are going.
+
+ + +The latest version of Samba-3 includes a functioning winbindd daemon. Please refer to the main Samba Web page, or better yet, your closest Samba mirror site for +instructions on downloading the source code. +
+ + + + +To allow domain users the ability to access Samba shares and files, as well as potentially other services +provided by your Samba machine, PAM must be set up properly on your +machine. In order to compile the Winbind modules, you should have at least the PAM development libraries installed +on your system. Please refer to the PAM Web site http://www.kernel.org/pub/linux/libs/pam/. +
+
+
+
+
+
+Before starting, it is probably best to kill off all the Samba-related daemons running on your server.
+Kill off all smbd, nmbd, and winbindd processes that may be running. To use PAM,
+make sure that you have the standard PAM package that supplies the /etc/pam.d
+directory structure, including the PAM modules that are used by PAM-aware services, several PAM libraries,
+and the /usr/doc
and /usr/man
entries for PAM. Winbind is built
+better in Samba if the pam-devel package is also installed. This package includes the header files
+needed to compile PAM-aware applications.
+
+
+
+
+
+PAM is a standard component of most current generation UNIX/Linux systems. Unfortunately, few systems install
+the pam-devel
libraries that are needed to build PAM-enabled Samba. Additionally, Samba-3
+may auto-install the Winbind files into their correct locations on your system, so before you get too far down
+the track, be sure to check if the following configuration is really
+necessary. You may only need to configure
+/etc/nsswitch.conf
.
+
+The libraries needed to run the winbindd daemon through nsswitch need to be copied to their proper locations: +
+root#
cp ../samba/source/nsswitch/libnss_winbind.so /lib
+
+
+I also found it necessary to make the following symbolic link: +
+root#
ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
+
And, in the case of Sun Solaris: + +
+root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1
+root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1
+root#
ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2
+
+
+
+As root, edit /etc/nsswitch.conf
to
+allow user and group entries to be visible from the winbindd
+daemon. My /etc/nsswitch.conf
file looked like
+this after editing:
+
+passwd: files winbind +shadow: files +group: files winbind +
+ + + + + +The libraries needed by the winbindd daemon will be automatically +entered into the ldconfig cache the next time +your system reboots, but it is faster (and you do not need to reboot) if you do it manually: +
+root#
/sbin/ldconfig -v | grep winbind
+
+This makes libnss_winbind
available to winbindd and reports the current
+search path that is used by the dynamic link loader. The use of the grep
+filters the output of the ldconfig command so that we may see proof that
+this library is indeed recognized by the dynamic link loader.
+
+
+
+
+
+
+The Sun Solaris dynamic link loader management tool is called crle. The
+use of this tool is necessary to instruct the dynamic link loader to search directories that
+contain library files that were not supplied as part of the original operating system platform.
+The following example shows how to use this tool to add the directory /usr/local/lib
+to the dynamic link loader's search path:
+
+root#
crle -u -l /usr/lib:/usr/local/lib
+
+When executed without arguments, crle reports the current dynamic +link loader configuration. This is demonstrated here: +
+root#
crle
+
+Configuration file [version 4]: /var/ld/ld.config
+ Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib
+ Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
+
+Command line:
+ crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib
+
+From this it is apparent that the /usr/local/lib
directory is included
+in the search dynamic link libraries in order to satisfy object module dependencies.
+
(This section is only for those running AIX.)
+
+
+
+
+
+
+The Winbind AIX identification module gets built as libnss_winbind.so
in the
+nsswitch directory of the Samba source. This file can be copied to /usr/lib/security
,
+and the AIX naming convention would indicate that it should be named WINBIND. A stanza like the following:
+
+WINBIND: + program = /usr/lib/security/WINBIND + options = authonly +
+can then be added to /usr/lib/security/methods.cfg
. This module only supports
+identification, but there have been reports of success using the standard Winbind PAM module for
+authentication. Use caution configuring loadable authentication modules, since misconfiguration can make
+it impossible to log on to the system. Information regarding the AIX authentication module API can
+be found in the “Kernel Extensions and Device Support Programming Concepts for AIX” document that
+describes the
+Loadable Authentication Module Programming Interface for AIX. Further information on administering the modules
+can be found in the System
+Management Guide: Operating System and Devices.
+
+
+
+
+Several parameters are needed in the smb.conf
file to control the behavior of winbindd. These
+are described in more detail in the winbindd(8) man page. My smb.conf
file, as shown in the smb.conf for Winbind Setup, was modified to include the necessary entries in the [global] section.
+
Example 23.1. smb.conf for Winbind Setup
+ + + +All machines that will participate in domain security should be members of +the domain. This applies also to the PDC and all BDCs. +
+ + + + + + + + + +The process of joining a domain requires the use of the net rpc join +command. This process communicates with the domain controller it will register with +(usually the PDC) via MS DCE RPC. This means, of course, that the smbd +process must be running on the target domain controller. It is therefore necessary to temporarily +start Samba on a PDC so that it can join its own domain. +
+
+
+
+Enter the following command to make the Samba server join the
+domain, where PDC
is the name of
+your PDC and Administrator
is
+a domain user who has administrative privileges in the domain.
+
+ + + + +Before attempting to join a machine to the domain, verify that Samba is running +on the target domain controller (usually PDC) and that it is capable of being reached via ports +137/udp, 135/tcp, 139/tcp, and 445/tcp (if Samba or Windows Server 2Kx). +
+ +The use of the net rpc join facility is shown here: +
+root#
/usr/local/samba/bin/net rpc join -S PDC -U Administrator
+
+The proper response to the command should be “Joined the domain
+DOMAIN
” where DOMAIN
+is your domain name.
+
+ + + +Eventually, you will want to modify your Samba startup script to +automatically invoke the winbindd daemon when the other parts of +Samba start, but it is possible to test out just the Winbind +portion first. To start up Winbind services, enter the following +command as root: +
+root#
/usr/local/samba/sbin/winbindd
+
+Use the appropriate path to the location of the winbindd executable file. +
+
+
+The command to start up Winbind services assumes that Samba has been installed in the /usr/local/samba
+directory tree. You may need to search for the location of Samba files if this is not the
+location of winbindd on your system.
+
+
+
+Winbindd can now also run in “dual daemon mode”. This will make it
+run as two processes. The first will answer all requests from the cache,
+thus making responses to clients faster. The other will
+update the cache for the query to which the first has just responded.
+The advantage of this is that responses stay accurate and are faster.
+You can enable dual daemon mode by adding -B
to the command line:
+
+root#
/usr/local/samba/sbin/winbindd -B
+
+
+ + +I'm always paranoid and like to make sure the daemon is really running. +
+root#
ps -ae | grep winbindd
+
+
+ +This command should produce output like the following if the daemon is running. +
+3025 ? 00:00:00 winbindd +
+
+ + +Now, for the real test, try to get some information about the users on your PDC: +
+root#
/usr/local/samba/bin/wbinfo -u
+
+This should echo back a list of users on your Windows users on +your PDC. For example, I get the following response: +
+CEO\Administrator +CEO\burdell +CEO\Guest +CEO\jt-ad +CEO\krbtgt +CEO\TsInternetUser +
+Obviously, I have named my domain “CEO” and my winbind separator is “\”. +
+ + +You can do the same sort of thing to get group information from the PDC: +
+root#
/usr/local/samba/bin/wbinfo -g
+CEO\Domain Admins +CEO\Domain Users +CEO\Domain Guests +CEO\Domain Computers +CEO\Domain Controllers +CEO\Cert Publishers +CEO\Schema Admins +CEO\Enterprise Admins +CEO\Group Policy Creator Owners +
+ + + + + + + +The function getent can now be used to get unified +lists of both local and PDC users and groups. Try the following command: +
+root#
getent passwd
+
+You should get a list that looks like your /etc/passwd
+list followed by the domain users with their new UIDs, GIDs, home
+directories, and default shells.
+
+The same thing can be done for groups with the command: +
+root#
getent group
+
+
+
+
+
+
+
+
+
+
+
+The winbindd daemon needs to start up after the smbd and nmbd daemons are running.
+To accomplish this task, you need to modify the startup scripts of your system.
+They are located at /etc/init.d/smb
in Red Hat Linux and in
+/etc/init.d/samba
in Debian Linux. Edit your
+script to add commands to invoke this daemon in the proper sequence. My
+startup script starts up smbd, nmbd, and winbindd from the
+/usr/local/samba/bin
directory directly. The start
+function in the script looks like this:
+
+start() { + KIND="SMB" + echo -n $"Starting $KIND services: " + daemon /usr/local/samba/bin/smbd $SMBDOPTIONS + RETVAL=$? + echo + KIND="NMB" + echo -n $"Starting $KIND services: " + daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS + RETVAL2=$? + echo + KIND="Winbind" + echo -n $"Starting $KIND services: " + daemon /usr/local/samba/sbin/winbindd + RETVAL3=$? + echo + [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ + touch /var/lock/subsys/smb || RETVAL=1 + return $RETVAL +} +
If you would like to run winbindd in dual daemon mode, replace +the line: +
+ daemon /usr/local/samba/sbin/winbindd +
+ +in the example above with: + +
+ daemon /usr/local/samba/sbin/winbindd -B +
. +
+The stop function has a corresponding entry to shut down the +services and looks like this: +
+stop() { + KIND="SMB" + echo -n $"Shutting down $KIND services: " + killproc smbd + RETVAL=$? + echo + KIND="NMB" + echo -n $"Shutting down $KIND services: " + killproc nmbd + RETVAL2=$? + echo + KIND="Winbind" + echo -n $"Shutting down $KIND services: " + killproc winbindd + RETVAL3=$? + [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \ + rm -f /var/lock/subsys/smb + echo "" + return $RETVAL +} +
+Winbind does not work on Solaris 9; see Winbind on Solaris 9 section +for details. +
+
+
+
+
+
+
+On Solaris, you need to modify the /etc/init.d/samba.server
startup script. It
+usually only starts smbd and nmbd but should now start winbindd, too. If you have Samba installed in
+/usr/local/samba/bin
, the file could contains something like this:
+
+
+ ## + ## samba.server + ## + + if [ ! -d /usr/bin ] + then # /usr not mounted + exit + fi + + killproc() { # kill the named process(es) + pid=`/usr/bin/ps -e | + /usr/bin/grep -w $1 | + /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` + [ "$pid" != "" ] && kill $pid + } + + # Start/stop processes required for Samba server + + case "$1" in + + 'start') + # + # Edit these lines to suit your installation (paths, workgroup, host) + # + echo Starting SMBD + /usr/local/samba/bin/smbd -D -s \ + /usr/local/samba/smb.conf + + echo Starting NMBD + /usr/local/samba/bin/nmbd -D -l \ + /usr/local/samba/var/log -s /usr/local/samba/smb.conf + + echo Starting Winbind Daemon + /usr/local/samba/sbin/winbindd + ;; + + 'stop') + killproc nmbd + killproc smbd + killproc winbindd + ;; + + *) + echo "Usage: /etc/init.d/samba.server { start | stop }" + ;; + esac +
+Again, if you would like to run Samba in dual daemon mode, replace: +
+/usr/local/samba/sbin/winbindd +
+in the script above with: +
+/usr/local/samba/sbin/winbindd -B +
+
+
+
+
+
+If you have made it this far, you know that winbindd and Samba are working
+together. If you want to use Winbind to provide authentication for other
+services, keep reading. The PAM configuration files need to be altered in
+this step. (Did you remember to make backups of your original
+/etc/pam.d
files? If not, do it now.)
+
+
+
+
+
+
+
+You will need a PAM module to use winbindd with these other services. This
+module will be compiled in the ../source/nsswitch
directory
+by invoking the command:
+
+root#
make nsswitch/pam_winbind.so
+
+from the ../source
directory. The
+pam_winbind.so
file should be copied to the location of
+your other PAM security modules. On my Red Hat system, this was the
+/lib/security
directory. On Solaris, the PAM security
+modules reside in /usr/lib/security
.
+
+root#
cp ../samba/source/nsswitch/pam_winbind.so /lib/security
+
+
+
+The /etc/pam.d/samba
file does not need to be changed. I
+just left this file as it was:
+
+auth required /lib/security/pam_stack.so service=system-auth +account required /lib/security/pam_stack.so service=system-auth +
+
+
+
+
+
+
+
+
+
+The other services that I modified to allow the use of Winbind
+as an authentication service were the normal login on the console (or a terminal
+session), telnet logins, and ftp service. In order to enable these
+services, you may first need to change the entries in
+/etc/xinetd.d
(or /etc/inetd.conf
).
+Red Hat Linux 7.1 and later uses the new xinetd.d structure, in this case you need
+to change the lines in /etc/xinetd.d/telnet
+and /etc/xinetd.d/wu-ftp
from
+
+ enable = no +
+to +
+ enable = yes +
+
+
+
+For ftp services to work properly, you will also need to either
+have individual directories for the domain users already present on
+the server or change the home directory template to a general
+directory for all domain users. These can be easily set using
+the smb.conf
global entry
+template homedir.
+
+ +The directory in template homedir is not created automatically! Use pam_mkhomedir or +pre-create the directories of users to make sure users can log in on UNIX with their own home directory. +
+
+
+
+The /etc/pam.d/ftp
file can be changed
+to allow Winbind ftp access in a manner similar to the
+samba file. My /etc/pam.d/ftp
file was
+changed to look like this:
+
+auth required /lib/security/pam_listfile.so item=user sense=deny \ + file=/etc/ftpusers onerr=succeed +auth sufficient /lib/security/pam_winbind.so +auth required /lib/security/pam_stack.so service=system-auth +auth required /lib/security/pam_shells.so +account sufficient /lib/security/pam_winbind.so +account required /lib/security/pam_stack.so service=system-auth +session required /lib/security/pam_stack.so service=system-auth +
+
+The /etc/pam.d/login
file can be changed in nearly the
+same way. It now looks like this:
+
+auth required /lib/security/pam_securetty.so +auth sufficient /lib/security/pam_winbind.so +auth sufficient /lib/security/pam_unix.so use_first_pass +auth required /lib/security/pam_stack.so service=system-auth +auth required /lib/security/pam_nologin.so +account sufficient /lib/security/pam_winbind.so +account required /lib/security/pam_stack.so service=system-auth +password required /lib/security/pam_stack.so service=system-auth +session required /lib/security/pam_stack.so service=system-auth +session optional /lib/security/pam_console.so +
+ + + +In this case, I added the
auth sufficient /lib/security/pam_winbind.so
+lines as before, but also added the
required pam_securetty.so
+above it to disallow root logins over the network. I also added a +
sufficient /lib/security/pam_unix.so use_first_pass
+line after the winbind.so line to get rid of annoying +double prompts for passwords. +
+
+
+The /etc/pam.conf
needs to be changed. I changed this file so my Domain
+users can log on both locally as well as with telnet. The following are the changes
+that I made. You can customize the pam.conf
file as per your requirements, but
+be sure of those changes because in the worst case it will leave your system
+nearly impossible to boot.
+
+# +#ident "@(#)pam.conf 1.14 99/09/16 SMI" +# +# Copyright (c) 1996-1999, Sun Microsystems, Inc. +# All Rights Reserved. +# +# PAM configuration +# +# Authentication management +# +login auth required /usr/lib/security/pam_winbind.so +login auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass +# +rlogin auth sufficient /usr/lib/security/pam_winbind.so +rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 +rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +# +dtlogin auth sufficient /usr/lib/security/pam_winbind.so +dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +# +rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 +other auth sufficient /usr/lib/security/pam_winbind.so +other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass +# +# Account management +# +login account sufficient /usr/lib/security/pam_winbind.so +login account requisite /usr/lib/security/$ISA/pam_roles.so.1 +login account required /usr/lib/security/$ISA/pam_unix.so.1 +# +dtlogin account sufficient /usr/lib/security/pam_winbind.so +dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 +dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 +# +other account sufficient /usr/lib/security/pam_winbind.so +other account requisite /usr/lib/security/$ISA/pam_roles.so.1 +other account required /usr/lib/security/$ISA/pam_unix.so.1 +# +# Session management +# +other session required /usr/lib/security/$ISA/pam_unix.so.1 +# +# Password management +# +#other password sufficient /usr/lib/security/pam_winbind.so +other password required /usr/lib/security/$ISA/pam_unix.so.1 +dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 +# +# Support for Kerberos V5 authentication (uncomment to use Kerberos) +# +#rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +#dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 +#other account optional /usr/lib/security/$ISA/pam_krb5.so.1 +#other session optional /usr/lib/security/$ISA/pam_krb5.so.1 +#other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass +
+
+I also added a try_first_pass
line after the winbind.so
+line to get rid of annoying double prompts for passwords.
+
+Now restart your Samba and try connecting through your application that you +configured in the pam.conf. +
+ + + + + +The Winbind system, through the use of the NSS, PAMs, and appropriate +Microsoft RPC calls, have allowed us to provide seamless +integration of Microsoft Windows NT domain users on a +UNIX system. The result is a great reduction in the administrative +cost of running a mixed UNIX and NT network.
Winbind has a number of limitations in its current + released version that we hope to overcome in future + releases:
Winbind is currently only available for + the Linux, Solaris, AIX, and IRIX operating systems, although ports to other operating + systems are certainly possible. For such ports to be feasible, + we require the C library of the target operating system to + support the NSS and PAM + systems. This is becoming more common as NSS and + PAM gain support among UNIX vendors.
The mappings of Windows NT RIDs to UNIX IDs + is not made algorithmically and depends on the order in which + unmapped users or groups are seen by Winbind. It may be difficult + to recover the mappings of RID to UNIX ID if the file + containing this information is corrupted or destroyed.
Currently the Winbind PAM module does not take + into account possible workstation and logon time restrictions + that may be set for Windows NT users; this is + instead up to the PDC to enforce.
+ Do not under any circumstances run nscd on any system + on which winbindd is running. +
+ If nscd is running on the UNIX/Linux system, then + even though NSSWITCH is correctly configured, it will not be possible to resolve + domain users and groups for file and directory controls. +
“
+ My smb.conf
file is correctly configured. I have specified
+ idmap uid = 12000,
+ and idmap gid = 3000-3500
+ and winbind is running. When I do the following, it all works fine.
+ ”
+root#
wbinfo -u
+MIDEARTH\maryo +MIDEARTH\jackb +MIDEARTH\ameds +... +MIDEARTH\root + +root#
wbinfo -g
+MIDEARTH\Domain Users +MIDEARTH\Domain Admins +MIDEARTH\Domain Guests +... +MIDEARTH\Accounts + +root#
getent passwd
+root:x:0:0:root:/root:/bin/bash +bin:x:1:1:bin:/bin:/bin/bash +... +maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false +
“ +But the following command just fails: +” +
+root#
chown maryo a_file
+chown: `maryo': invalid user +
+“ +This is driving me nuts! What can be wrong? +”
+Same problem as the one above. +Your system is likely running nscd, the name service +caching daemon. Shut it down, do not restart it! You will find your problem resolved. +