summaryrefslogtreecommitdiffstats
path: root/docs/htmldocs/Samba-HOWTO-Collection.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/Samba-HOWTO-Collection.html')
-rw-r--r--docs/htmldocs/Samba-HOWTO-Collection.html589
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