From 992f1e6b8f86b346fddd266b04d29cde69585633 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Wed, 7 Apr 2004 10:15:11 +0000 Subject: Add all the source files from the old CVS tree, add the 5 missing chapters from the HOWTO and add jht's Samba by Example book. (This used to be commit 9fb5bcb93e57c5162b3ee6f9c7d777dc0269d100) --- docs/howto/Winbind.xml | 1239 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1239 insertions(+) create mode 100644 docs/howto/Winbind.xml (limited to 'docs/howto/Winbind.xml') diff --git a/docs/howto/Winbind.xml b/docs/howto/Winbind.xml new file mode 100644 index 0000000000..909c54e7e0 --- /dev/null +++ b/docs/howto/Winbind.xml @@ -0,0 +1,1239 @@ + + + + + TimPotter + + Samba Team +
tpot@linuxcare.com.au
+ + + &author.tridge; + + NaagMummaneni + +
getnag@rediffmail.com
+ + Notes for Solaris + + + JohnTrostel + +
jtrostel@snapserver.com
+ SNAP + + + + &author.jelmer; + &author.jht; + 27 June 2002 + + +Winbind: Use of Domain Accounts + + + Features and Benefits + + + 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, and the Name Service Switch to + allow Windows NT domain users to appear and operate as UNIX users on a UNIX + machine. This chapter describes the Winbind system, explaining the functionality + it provides, how it is configured, and how it works internally. + + + + Winbind provides three separate functions: + + + + + Authentication of user credentials (via PAM). + + + + Identity resolution (via NSS). + + + + 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 stored 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 ldapsam:url + then instead of using a local mapping Winbind will obtain this information + from the LDAP database. + + + + + winbindd + starting sambawinbindd + 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. + + + + + + + + + + Introduction + + 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, as + adding and deleting users on both sets of machines becomes a chore + and two sets of passwords are required &smbmdash; 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. + + + + + What Winbind Provides + + 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 any + program on the UNIX machine asks the operating system to lookup + 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 as 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 Pluggable Authentication Modules (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). + + + Target Uses + + 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. + + + + + + + How Winbind Works + + 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 is processed sequentially. + + The technologies used to implement Winbind are described + in detail below. + + + Microsoft Remote Procedure Calls + + Over the last few years, efforts have been underway + by various Samba Team members to decode 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. + + + + Microsoft Active Directory Services + + + 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. + + + + + Name Service Switch + + The Name Service Switch, or 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 filesystem. 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, one can enumerate the users and groups on + a UNIX machine running Winbind and see all users and groups in + a 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. + + + + Pluggable Authentication Modules + + Pluggable Authentication Modules, also known as PAM, + is 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 + a 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 Primary Domain + Controller. These users can also change their passwords and have + this change take effect directly on the Primary Domain Controller. + + + 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. All that needs + to be done is that the pam_winbind.so module + is copied 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. + + + + + User and Group ID Allocation + + 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 in which 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. + + + + + Result Caching + + +SAM + An active 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. + + + + + + Installation and Configuration + + +Introduction + + +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. + + + + + + + +Requirements + + +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 back to the original state they were 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 the PAM web site . + + + + +Testing Things Out + + +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 built +better in Samba if the pam-devel package is also installed. This package includes the header files +needed to compile PAM-aware applications. + + + +Configure <filename>nsswitch.conf</filename> and the Winbind Libraries on Linux and Solaris + + +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: + + + + +&rootprompt;cp ../samba/source/nsswitch/libnss_winbind.so /lib + + + + +I also found it necessary to make the following symbolic link: + + + +&rootprompt; ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2 + + +And, in the case of Sun Solaris: + +&rootprompt;ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1 +&rootprompt;ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1 +&rootprompt;ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2 + + + +Now, as root you need to edit /etc/nsswitch.conf to +allow user and group entries to be visible from the &winbindd; +daemon. My /etc/nsswitch.conf file look 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: + + + +&rootprompt;/sbin/ldconfig -v | grep winbind + + + +This makes libnss_winbind available to winbindd +and echos back a check to you. + + + + + +NSS Winbind on AIX + +(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 success reports using the standard Winbind PAM module for +authentication. Use caution configuring loadable authentication +modules since you can make +it impossible to logon to the system. More information about the AIX authentication module API can +be found at Kernel Extensions and Device Support Programming Concepts for AIX +in Chapter 18(John, there is no section like this in 18). Loadable Authentication Module Programming +Interface and more information on administering the modules +can be found at System +Management Guide: Operating System and Devices. + + + + +Configure smb.conf + + +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 next example, was modified to include the necessary entries in the [global] section. + + + + smb.conf for Winbind set-up +[global] + <...> + separate domain and username with '+', like DOMAIN+username +winbind separator+ + use uids from 10000 to 20000 for domain users +idmap uid10000-20000 + use gids from 10000 to 20000 for domain groups +idmap gid10000-20000 + allow enumeration of winbind users and groups +winbind enum usersyes +winbind enum groupsyes + give winbind users a real shell (only needed if they have telnet access) +template homedir/home/winnt/%D/%U +template shell/bin/bash + + + + + + +Join the Samba Server to the PDC Domain + + +Enter the following command to make the Samba server join the +PDC domain, where DOMAIN is the name of +your Windows domain and Administrator is +a domain user who has administrative privileges in the domain. + + + + +&rootprompt;/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. + + + + + +Starting and Testing the <command>winbindd</command> Daemon + + +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: + + + +&rootprompt;/usr/local/samba/bin/winbindd + + + +The above 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 that 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 to the command-line: + + + +&rootprompt;/usr/local/samba/bin/winbindd -B + + + +I'm always paranoid and like to make sure the daemon is really running. + + + +&rootprompt;ps -ae | grep winbindd + + +This command should produce output like this, if the daemon is running you would expect +to see a report something like this: + + +3025 ? 00:00:00 winbindd + + + +Now, for the real test, try to get some information about the users on your PDC: + + + +&rootprompt;/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: + + + +&rootprompt;/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: + + + +&rootprompt;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: + + + +&rootprompt;getent group + + + + + + +Fix the init.d Startup Scripts + + +Linux + + +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 they are located 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/bin/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/bin/winbindd + + +in the example above with: + + + daemon /usr/local/samba/bin/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 +} + + + + +Solaris + + +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/bin/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/bin/winbindd + +in the script above with: + + /usr/local/samba/bin/winbindd -B + + + + + + +Restarting + +If you restart the &smbd;, &nmbd;, and &winbindd; daemons at this point, you +should be able to connect to the Samba server as a Domain Member just as +if you were a local user. + + + + + +Configure Winbind and PAM + + +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: + + + +&rootprompt;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. + + + +&rootprompt;cp ../samba/source/nsswitch/pam_winbind.so /lib/security + + + +Linux/FreeBSD-specific PAM configuration + + +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 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. + + + + + +Solaris-specific configuration + + +The /etc/pam.conf needs to be changed. I changed this file so my Domain +users can logon both locally as well as 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. + + + + + + + + + + + +Conclusion + +The Winbind system, through the use of the Name Service +Switch, Pluggable Authentication Modules, 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. + + + + +Common Errors + + 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 Name Service Switch and Pluggable Authentication + Modules 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 mapping 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. + + + + NSCD Problem Warning + + + + + 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. + + + + + + Winbind Is Not Resolving Users and Groups + + + My &smb.conf; file is correctly configured. I have specified + idmap uid12000, + and idmap gid3000-3500 + and winbind is running. When I do the following it all works fine. + + + +&rootprompt;wbinfo -u +MIDEARTH+maryo +MIDEARTH+jackb +MIDEARTH+ameds +... +MIDEARTH+root + +&rootprompt;wbinfo -g +MIDEARTH+Domain Users +MIDEARTH+Domain Admins +MIDEARTH+Domain Guests +... +MIDEARTH+Accounts + +&rootprompt;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: + +&rootprompt;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. + + + + + + -- cgit