diff options
Diffstat (limited to 'docs/htmldocs/Samba-HOWTO-Collection.html')
-rw-r--r-- | docs/htmldocs/Samba-HOWTO-Collection.html | 589 |
1 files changed, 570 insertions, 19 deletions
diff --git a/docs/htmldocs/Samba-HOWTO-Collection.html b/docs/htmldocs/Samba-HOWTO-Collection.html index 3596af76022..cfb6ed37e5d 100644 --- a/docs/htmldocs/Samba-HOWTO-Collection.html +++ b/docs/htmldocs/Samba-HOWTO-Collection.html @@ -315,59 +315,141 @@ HREF="#AEN655" ><DT >6. <A HREF="#AEN669" +>Unifed Logons between Windows NT and UNIX using Winbind</A +></DT +><DD +><DL +><DT +><A +HREF="#AEN687" +>Abstract</A +></DT +><DT +><A +HREF="#AEN691" +>Introduction</A +></DT +><DT +><A +HREF="#AEN704" +>What Winbind Provides</A +></DT +><DD +><DL +><DT +><A +HREF="#AEN711" +>Target Uses</A +></DT +></DL +></DD +><DT +><A +HREF="#AEN715" +>How Winbind Works</A +></DT +><DD +><DL +><DT +><A +HREF="#AEN720" +>Microsoft Remote Procedure Calls</A +></DT +><DT +><A +HREF="#AEN724" +>Name Service Switch</A +></DT +><DT +><A +HREF="#AEN740" +>Pluggable Authentication Modules</A +></DT +><DT +><A +HREF="#AEN748" +>User and Group ID Allocation</A +></DT +><DT +><A +HREF="#AEN752" +>Result Caching</A +></DT +></DL +></DD +><DT +><A +HREF="#AEN755" +>Installation and Configuration</A +></DT +><DT +><A +HREF="#AEN761" +>Limitations</A +></DT +><DT +><A +HREF="#AEN773" +>Conclusion</A +></DT +></DL +></DD +><DT +>7. <A +HREF="#AEN776" >UNIX Permission Bits and WIndows NT Access Control Lists</A ></DT ><DD ><DL ><DT ><A -HREF="#AEN680" +HREF="#AEN787" >Viewing and changing UNIX permissions using the NT security dialogs</A ></DT ><DT ><A -HREF="#AEN689" +HREF="#AEN796" >How to view file security on a Samba share</A ></DT ><DT ><A -HREF="#AEN700" +HREF="#AEN807" >Viewing file ownership</A ></DT ><DT ><A -HREF="#AEN720" +HREF="#AEN827" >Viewing file or directory permissions</A ></DT ><DD ><DL ><DT ><A -HREF="#AEN735" +HREF="#AEN842" >File Permissions</A ></DT ><DT ><A -HREF="#AEN749" +HREF="#AEN856" >Directory Permissions</A ></DT ></DL ></DD ><DT ><A -HREF="#AEN756" +HREF="#AEN863" >Modifying file or directory permissions</A ></DT ><DT ><A -HREF="#AEN778" +HREF="#AEN885" >Interaction with the standard Samba create mask parameters</A ></DT ><DT ><A -HREF="#AEN842" +HREF="#AEN949" >Interaction with the standard Samba file attribute mapping</A ></DT @@ -2950,14 +3032,483 @@ CLASS="CHAPTER" ><HR><H1 ><A NAME="AEN669" ->Chapter 6. UNIX Permission Bits and WIndows NT Access Control Lists</A +>Chapter 6. Unifed Logons between Windows NT and UNIX using Winbind</A +></H1 +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN687" +>Abstract</A +></H1 +><P +>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. We present <I +CLASS="EMPHASIS" +>winbind + </I +>, a component of the Samba suite of programs as a + solution to the unied 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 paper describes the winbind + system, explaining the functionality it provides, how it is configured, + and how it works internally.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN691" +>Introduction</A +></H1 +><P +>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.</P +><P +>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 both of which which + can lead to synchronization problems between the UNIX and Windows + systems and confusion for users.</P +><P +>We divide the unifed logon problem for UNIX machines into + three smaller problems:</P +><P +></P +><UL +><LI +><P +>Obtaining Windows NT user and group information + </P +></LI +><LI +><P +>Authenticating Windows NT users + </P +></LI +><LI +><P +>Password changing for Windows NT users + </P +></LI +></UL +><P +>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 unifed logon + problem.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN704" +>What Winbind Provides</A +></H1 +><P +>Winbind unifies UNIX and Windows NT account management by + allowing a UNIX box to become a full member of a 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.</P +><P +>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 specied 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.</P +><P +>Users on the UNIX machine can then use NT user and group + names as they would use "native" UNIX names. They can chown files + so that 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.</P +><P +>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.</P +><P +>Additionally, Winbind provides a authentication service + that hooks into the Pluggable Authentication Modules (PAM) system + to provide authentication via a NT domain to any PAM enabled + applications. This capability solves the problem of synchronizing + passwords between systems as all passwords are stored in a single + location (on the domain controller).</P +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN711" +>Target Uses</A +></H2 +><P +>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 simplies + the administrative overhead of deploying UNIX workstations into + a NT based organization.</P +><P +>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.</P +></DIV +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN715" +>How Winbind Works</A +></H1 +><P +>The winbind system is designed around a client/server + architecture. A long running <B +CLASS="COMMAND" +>winbindd</B +> daemon + listens on a UNIX domain socket waiting for requests + to arrive. These requests are generated by the NSS and PAM + clients and processed sequentially.</P +><P +>The technologies used to implement winbind are described + in detail below.</P +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN720" +>Microsoft Remote Procedure Calls</A +></H2 +><P +>Over the last two 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 which + can be used for other purposes.</P +><P +>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.</P +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN724" +>Name Service Switch</A +></H2 +><P +>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 dierent sources. For example, a standalone + UNIX workstation may resolve system information from a series of + flat files stored on the local lesystem. A networked workstation + may first attempt to resolve system information from local files, + then consult a NIS database for user information or a DNS server + for hostname information.</P +><P +>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.</P +><P +>The primary control le for NSS is <TT +CLASS="FILENAME" +>/etc/nsswitch.conf + </TT +>. When a UNIX application makes a request to do a lookup + the C library looks in <TT +CLASS="FILENAME" +>/etc/nsswitch.conf</TT +> + for a line which 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 species which implementations + of that service should be tried andin what order. If the passwd + config line is:</P +><P +><B +CLASS="COMMAND" +>passwd: files example</B +></P +><P +>then the C library will first load a module called + <TT +CLASS="FILENAME" +>/lib/libnss_files.so</TT +> followed by + the module <TT +CLASS="FILENAME" +>/lib/libnss_example.so</TT +>. 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.</P +><P +>This NSS interface provides a very easy way for Winbind + to hook into the operating system. All that needs to be done + is to put <TT +CLASS="FILENAME" +>libnss_winbind.so</TT +> in <TT +CLASS="FILENAME" +>/lib/</TT +> + then add "winbind" into <TT +CLASS="FILENAME" +>/etc/nsswitch.conf</TT +> at + the appropriate place. The C library will then call Winbind to + resolve user and group names.</P +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN740" +>Pluggable Authentication Modules</A +></H2 +><P +>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 dierent 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.</P +><P +>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 eect directly on the Primary Domain Controller. + </P +><P +>PAM is congured by providing control files in the directory + <TT +CLASS="FILENAME" +>/etc/pam.d/</TT +> 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 <TT +CLASS="FILENAME" +>pam_winbind.so</TT +> module + is copied to <TT +CLASS="FILENAME" +>/lib/security/</TT +> and the pam + control files for relevant services are updated to allow + authentication via winbind. See the PAM documentation + for more details.</P +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN748" +>User and Group ID Allocation</A +></H2 +><P +>When a user or group is created under Windows NT + is it allocated a numerical relative identier (RID). This is + slightly dierent to UNIX which has a range of numbers which 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 congured 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.</P +><P +>The results of this mapping are stored persistently in + a ID mapping database held in a tdb database). This ensures that + RIDs are mapped to UNIX IDs in a consistent way.</P +></DIV +><DIV +CLASS="SECT2" +><HR><H2 +CLASS="SECT2" +><A +NAME="AEN752" +>Result Caching</A +></H2 +><P +>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 modied. 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.</P +></DIV +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN755" +>Installation and Configuration</A +></H1 +><P +>The easiest way to install winbind is by using the packages + provided in the <TT +CLASS="FILENAME" +>pub/samba/appliance/</TT +> + directory on your nearest + Samba mirror. These packages provide snapshots of the Samba source + code and binaries already setup to provide the full functionality + of winbind. This setup is a little more complex than a normal Samba + build as winbind needs a small amount of functionality from a + development code branch called SAMBA_TNG.</P +><P +>Once you have installed the packages you should read + the <B +CLASS="COMMAND" +>winbindd(8)</B +> man page which will provide you + with conguration information and give you sample conguration files. + You may also wish to update the main Samba daemons smbd and nmbd) + with a more recent development release, such as the recently + announced Samba 2.2 alpha release.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN761" +>Limitations</A +></H1 +><P +>Winbind has a number of limitations in its current + released version which we hope to overcome in future + releases:</P +><P +></P +><UL +><LI +><P +>Winbind is currently only available for + the Linux operating system, 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.</P +></LI +><LI +><P +>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.</P +></LI +><LI +><P +>Currently the winbind PAM module does not take + into account possible workstation and logon time restrictions + that may be been set for Windows NT users.</P +></LI +><LI +><P +>Building winbind from source is currently + quite tedious as it requires combining source code from two Samba + branches. Work is underway to solve this by providing all + the necessary functionality in the main Samba code branch.</P +></LI +></UL +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN773" +>Conclusion</A +></H1 +><P +>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.</P +></DIV +></DIV +><DIV +CLASS="CHAPTER" +><HR><H1 +><A +NAME="AEN776" +>Chapter 7. UNIX Permission Bits and WIndows NT Access Control Lists</A ></H1 ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A -NAME="AEN680" +NAME="AEN787" >Viewing and changing UNIX permissions using the NT security dialogs</A ></H1 @@ -2996,7 +3547,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN689" +NAME="AEN796" >How to view file security on a Samba share</A ></H1 ><P @@ -3048,7 +3599,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN700" +NAME="AEN807" >Viewing file ownership</A ></H1 ><P @@ -3136,7 +3687,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN720" +NAME="AEN827" >Viewing file or directory permissions</A ></H1 ><P @@ -3198,7 +3749,7 @@ CLASS="SECT2" ><HR><H2 CLASS="SECT2" ><A -NAME="AEN735" +NAME="AEN842" >File Permissions</A ></H2 ><P @@ -3260,7 +3811,7 @@ CLASS="SECT2" ><HR><H2 CLASS="SECT2" ><A -NAME="AEN749" +NAME="AEN856" >Directory Permissions</A ></H2 ><P @@ -3292,7 +3843,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN756" +NAME="AEN863" >Modifying file or directory permissions</A ></H1 ><P @@ -3390,7 +3941,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN778" +NAME="AEN885" >Interaction with the standard Samba create mask parameters</A ></H1 @@ -3664,7 +4215,7 @@ CLASS="SECT1" ><HR><H1 CLASS="SECT1" ><A -NAME="AEN842" +NAME="AEN949" >Interaction with the standard Samba file attribute mapping</A ></H1 |