diff options
Diffstat (limited to 'docs/htmldocs/winbind.html')
| -rw-r--r-- | docs/htmldocs/winbind.html | 490 |
1 files changed, 0 insertions, 490 deletions
diff --git a/docs/htmldocs/winbind.html b/docs/htmldocs/winbind.html deleted file mode 100644 index 2f023561edc..00000000000 --- a/docs/htmldocs/winbind.html +++ /dev/null @@ -1,490 +0,0 @@ -<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 |