summaryrefslogtreecommitdiffstats
path: root/docs/htmldocs
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs')
-rw-r--r--docs/htmldocs/Samba-HOWTO-Collection.html589
-rw-r--r--docs/htmldocs/smb.conf.5.html280
-rw-r--r--docs/htmldocs/winbind.html490
3 files changed, 1263 insertions, 96 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
diff --git a/docs/htmldocs/smb.conf.5.html b/docs/htmldocs/smb.conf.5.html
index 454f3fb62d8..95523fee04c 100644
--- a/docs/htmldocs/smb.conf.5.html
+++ b/docs/htmldocs/smb.conf.5.html
@@ -1222,6 +1222,15 @@ CLASS="PARAMETER"
><TT
CLASS="PARAMETER"
><I
+>lanman auth</I
+></TT
+></P
+></LI
+><LI
+><P
+><TT
+CLASS="PARAMETER"
+><I
>lm announce</I
></TT
></P
@@ -1402,6 +1411,15 @@ CLASS="PARAMETER"
><TT
CLASS="PARAMETER"
><I
+>max protocol</I
+></TT
+></P
+></LI
+><LI
+><P
+><TT
+CLASS="PARAMETER"
+><I
>max smbd processes</I
></TT
></P
@@ -1465,6 +1483,15 @@ CLASS="PARAMETER"
><TT
CLASS="PARAMETER"
><I
+>min protocol</I
+></TT
+></P
+></LI
+><LI
+><P
+><TT
+CLASS="PARAMETER"
+><I
>min wins ttl</I
></TT
></P
@@ -2239,7 +2266,7 @@ CLASS="PARAMETER"
><DIV
CLASS="REFSECT1"
><A
-NAME="AEN725"
+NAME="AEN734"
></A
><H2
>COMPLETE LIST OF SERVICE PARAMETERS</H2
@@ -3280,7 +3307,7 @@ CLASS="PARAMETER"
><DIV
CLASS="REFSECT1"
><A
-NAME="AEN1071"
+NAME="AEN1080"
></A
><H2
>EXPLANATION OF EACH PARAMETER</H2
@@ -7962,6 +7989,24 @@ CLASS="COMMAND"
></DD
><DT
><A
+NAME="LANMANAUTH"
+></A
+>lanman auth (G)</DT
+><DD
+><P
+>This parameter determines whether or not smbd will
+ attempt to authentication users using the LANMAN password hash.
+ If disabled, only clients which support NT password hashes (e.g. Windows
+ NT/2000 clients, smbclient, etc... but not Windows 95/98 or the MS DOS
+ network client) will be able to connect to the Samba host.</P
+><P
+>Default : <B
+CLASS="COMMAND"
+>lanman auth = yes</B
+></P
+></DD
+><DT
+><A
NAME="LEVEL2OPLOCKS"
></A
>level2 oplocks (S)</DT
@@ -9815,6 +9860,90 @@ CLASS="COMMAND"
></DD
><DT
><A
+NAME="MAXPROTOCOL"
+></A
+>max protocol (G)</DT
+><DD
+><P
+>The value of the parameter (a string) is the highest
+ protocol level that will be supported by the server.</P
+><P
+>Possible values are :</P
+><P
+></P
+><UL
+><LI
+><P
+><TT
+CLASS="CONSTANT"
+>CORE</TT
+>: Earliest version. No
+ concept of user names.</P
+></LI
+><LI
+><P
+><TT
+CLASS="CONSTANT"
+>COREPLUS</TT
+>: Slight improvements on
+ CORE for efficiency.</P
+></LI
+><LI
+><P
+><TT
+CLASS="CONSTANT"
+>LANMAN1</TT
+>: First <I
+CLASS="EMPHASIS"
+> modern</I
+> version of the protocol. Long filename
+ support.</P
+></LI
+><LI
+><P
+><TT
+CLASS="CONSTANT"
+>LANMAN2</TT
+>: Updates to Lanman1 protocol.
+ </P
+></LI
+><LI
+><P
+><TT
+CLASS="CONSTANT"
+>NT1</TT
+>: Current up to date version of
+ the protocol. Used by Windows NT. Known as CIFS.</P
+></LI
+></UL
+><P
+>Normally this option should not be set as the automatic
+ negotiation phase in the SMB protocol takes care of choosing
+ the appropriate protocol.</P
+><P
+>See also <A
+HREF="#MINPROTOCOL"
+><TT
+CLASS="PARAMETER"
+><I
+>min
+ protocol</I
+></TT
+></A
+></P
+><P
+>Default: <B
+CLASS="COMMAND"
+>max protocol = NT1</B
+></P
+><P
+>Example: <B
+CLASS="COMMAND"
+>max protocol = LANMAN1</B
+></P
+></DD
+><DT
+><A
NAME="MAXSMBDPROCESSES"
></A
>max smbd processes (G)</DT
@@ -10157,6 +10286,56 @@ CLASS="COMMAND"
></DD
><DT
><A
+NAME="MINPROTOCOL"
+></A
+>min protocol (G)</DT
+><DD
+><P
+>The value of the parameter (a string) is the
+ lowest SMB protocol dialect than Samba will support. Please refer
+ to the <A
+HREF="#MAXPROTOCOL"
+><TT
+CLASS="PARAMETER"
+><I
+>max protocol</I
+></TT
+></A
+>
+ parameter for a list of valid protocol names and a brief description
+ of each. You may also wish to refer to the C source code in
+ <TT
+CLASS="FILENAME"
+>source/smbd/negprot.c</TT
+> for a listing of known protocol
+ dialects supported by clients.</P
+><P
+>If you are viewing this parameter as a security measure, you should
+ also refer to the <A
+HREF="#LANMANAUTH"
+><TT
+CLASS="PARAMETER"
+><I
+>lanman
+ auth</I
+></TT
+></A
+> parameter. Otherwise, you should never need
+ to change this parameter.</P
+><P
+>Default : <B
+CLASS="COMMAND"
+>min protocol = CORE</B
+></P
+><P
+>Example : <B
+CLASS="COMMAND"
+>min protocol = NT1</B
+> # disable DOS
+ clients</P
+></DD
+><DT
+><A
NAME="MINWINSTTL"
></A
>min wins ttl (G)</DT
@@ -11187,7 +11366,10 @@ NAME="PASSWORDLEVEL"
with mixed-case passwords. One offending client is Windows for
Workgroups, which for some reason forces passwords to upper
case when using the LANMAN1 protocol, but leaves them alone when
- using COREPLUS!</P
+ using COREPLUS! Another problem child is the Windows 95/98
+ family of operating systems. These clients upper case clear
+ text passwords even when NT LM 0.12 selected by the protocol
+ negotiation request/response.</P
><P
>This parameter defines the maximum number of characters
that may be upper case in passwords.</P
@@ -12035,11 +12217,11 @@ CLASS="COMMAND"
><P
><PRE
CLASS="PROGRAMLISTING"
->print1|My Printer 1
-print2|My Printer 2
-print3|My Printer 3
-print4|My Printer 4
-print5|My Printer 5
+> print1|My Printer 1
+ print2|My Printer 2
+ print3|My Printer 3
+ print4|My Printer 4
+ print5|My Printer 5
</PRE
></P
><P
@@ -12439,71 +12621,15 @@ NAME="PROTOCOL"
>protocol (G)</DT
><DD
><P
->The value of the parameter (a string) is the highest
- protocol level that will be supported by the server.</P
-><P
->Possible values are :</P
-><P
-></P
-><UL
-><LI
-><P
-><TT
-CLASS="CONSTANT"
->CORE</TT
->: Earliest version. No
- concept of user names.</P
-></LI
-><LI
-><P
-><TT
-CLASS="CONSTANT"
->COREPLUS</TT
->: Slight improvements on
- CORE for efficiency.</P
-></LI
-><LI
-><P
-><TT
-CLASS="CONSTANT"
->LANMAN1</TT
->: First <I
-CLASS="EMPHASIS"
-> modern</I
-> version of the protocol. Long filename
- support.</P
-></LI
-><LI
-><P
-><TT
-CLASS="CONSTANT"
->LANMAN2</TT
->: Updates to Lanman1 protocol.
- </P
-></LI
-><LI
-><P
-><TT
-CLASS="CONSTANT"
->NT1</TT
->: Current up to date version of
- the protocol. Used by Windows NT. Known as CIFS.</P
-></LI
-></UL
-><P
->Normally this option should not be set as the automatic
- negotiation phase in the SMB protocol takes care of choosing
- the appropriate protocol.</P
-><P
->Default: <B
-CLASS="COMMAND"
->protocol = NT1</B
-></P
-><P
->Example: <B
-CLASS="COMMAND"
->protocol = LANMAN1</B
-></P
+>Synonym for <A
+HREF="#MAXPROTOCOL"
+> <TT
+CLASS="PARAMETER"
+><I
+>max protocol</I
+></TT
+></A
+>.</P
></DD
><DT
><A
@@ -16735,7 +16861,7 @@ CLASS="COMMAND"
><DIV
CLASS="REFSECT1"
><A
-NAME="AEN5269"
+NAME="AEN5310"
></A
><H2
>WARNINGS</H2
@@ -16765,7 +16891,7 @@ TARGET="_top"
><DIV
CLASS="REFSECT1"
><A
-NAME="AEN5275"
+NAME="AEN5316"
></A
><H2
>VERSION</H2
@@ -16776,7 +16902,7 @@ NAME="AEN5275"
><DIV
CLASS="REFSECT1"
><A
-NAME="AEN5278"
+NAME="AEN5319"
></A
><H2
>SEE ALSO</H2
@@ -16855,7 +16981,7 @@ CLASS="COMMAND"
><DIV
CLASS="REFSECT1"
><A
-NAME="AEN5298"
+NAME="AEN5339"
></A
><H2
>AUTHOR</H2
diff --git a/docs/htmldocs/winbind.html b/docs/htmldocs/winbind.html
new file mode 100644
index 00000000000..2f023561edc
--- /dev/null
+++ b/docs/htmldocs/winbind.html
@@ -0,0 +1,490 @@
+<HTML
+><HEAD
+><TITLE
+>Unifed Logons between Windows NT and UNIX using Winbind</TITLE
+><META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
+><BODY
+CLASS="ARTICLE"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="ARTICLE"
+><DIV
+CLASS="TITLEPAGE"
+><H1
+CLASS="TITLE"
+><A
+NAME="AEN1"
+>Unifed Logons between Windows NT and UNIX using Winbind</A
+></H1
+><HR></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN3"
+>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="AEN7"
+>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="AEN20"
+>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="AEN27"
+>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="AEN31"
+>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="AEN36"
+>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="AEN40"
+>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="AEN56"
+>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="AEN64"
+>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="AEN68"
+>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="AEN71"
+>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="AEN77"
+>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="AEN89"
+>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
+></BODY
+></HTML
+> \ No newline at end of file
generated by cgit (git 2.34.1) at 2025-09-14 13:51:28 +0000