large sync up with 2.2

(This used to be commit 96523293da19df201703fed6130f1ff9ba25324b)
author: Gerald Carter <jerry@samba.org> 2001-04-19 21:33:44 +0000
committer: Gerald Carter <jerry@samba.org> 2001-04-19 21:33:44 +0000
commit: f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39 (patch)
tree: 7ae84ac676262759cdbfbe8260e650050dc2722b /docs/htmldocs/winbind.html
parent: e3fc10eab22443376ac3312447874607810dbc6b (diff)
download: samba-f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39.tar.gz
samba-f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39.tar.bz2
samba-f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39.zip
1 files changed, 490 insertions, 0 deletions
diff --git a/docs/htmldocs/winbind.html b/docs/htmldocs/winbind.html
new file mode 100644
index 0000000000..2f023561ed
--- /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
author	Gerald Carter <jerry@samba.org>	2001-04-19 21:33:44 +0000
committer	Gerald Carter <jerry@samba.org>	2001-04-19 21:33:44 +0000
commit	f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39 (patch)
tree	7ae84ac676262759cdbfbe8260e650050dc2722b /docs/htmldocs/winbind.html
parent	e3fc10eab22443376ac3312447874607810dbc6b (diff)
download	samba-f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39.tar.gz samba-f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39.tar.bz2 samba-f95fb5fe3941a0ef916ac85c6ccf4aecf17aaf39.zip