VERSION: Bump version up to 4.0.25.
[Samba.git] / docs-xml / Samba3-ByExample / SBE-AddingUNIXClients.xml
blob45a09a8fb1dee33fc9df1c9867a6ff5d3b224765
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
3 <chapter id="unixclients">
4   <title>Adding Domain Member Servers and Clients</title>
6     <para><indexterm>
7         <primary>Open Magazine</primary>
8       </indexterm><indexterm>
9         <primary>survey</primary>
10       </indexterm>
11         The most frequently discussed Samba subjects over the past 2 years have focused around domain control and printing. 
12         It is well known that Samba is a file and print server. A recent survey conducted by <emphasis>Open Magazine</emphasis> found 
13         that of all respondents, 97 percent use Samba for file and print services, and 68 percent use Samba for Domain Control. See the 
14         <ulink url="http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba">Open-Mag</ulink>
15         Web site for current information. The survey results as found on January 14, 2004, are shown in
16         <link linkend="ch09openmag"/>.
17         </para>
19         <figure id="ch09openmag">
20                 <title>Open Magazine Samba Survey</title>
21                 <imagefile scale="60">openmag</imagefile>
22         </figure>
24         <para>
25         While domain control is an exciting subject, basic file and print sharing remains the staple bread-and-butter
26         function that Samba provides. Yet this book may give the appearance of having focused too much on more
27         exciting aspects of Samba deployment. This chapter directs your attention to provide important information on
28         the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology
29         may be. So let's get back to our good friends at Abmas.
30         </para>
32 <sect1>
33         <title>Introduction</title>
35       <para><indexterm>
36           <primary>Linux desktop</primary>
37         </indexterm><indexterm>
38           <primary>Domain Member</primary>
39           <secondary>server</secondary>
40         </indexterm>
41         Looking back over the achievements of the past year or two, daily events at Abmas are rather straightforward
42         with not too many distractions or problems. Your team is doing well, but a number of employees
43         are asking for Linux desktop systems. Your network has grown and demands additional domain member servers. Let's
44         get on with this; Christine and Stan are ready to go.
45         </para>
47       <para><indexterm>
48           <primary>Domain Member</primary>
49           <secondary>desktop</secondary>
50         </indexterm>
51         Stan is firmly in control of the department of the future, while Christine is enjoying a stable and
52         predictable network environment. It is time to add more servers and to add Linux desktops. It is
53         time to meet the demands of future growth and endure trial by fire.
54         </para>
56         <sect2>
57         <title>Assignment Tasks</title>
59         <para><indexterm>
60             <primary>Active Directory</primary>
61           </indexterm>
62         You must now add UNIX/Linux domain member servers to your network. You have a friend who has a Windows 2003
63         Active Directory domain network who wants to add a Samba/Linux server and has asked Christine to help him
64         out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use
65         her help to get validation that Samba really does live up to expectations.
66         </para>
68         <para>
69         Over the past 6 months, you have hired several new staff who want Linux on their desktops. You must integrate
70         these systems to make sure that Abmas is not building islands of technology. You ask Christine to
71         do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
72         the right decision, don't you?
73         </para>
75         </sect2>
76 </sect1>
78 <sect1>
79         <title>Dissection and Discussion</title>
81         <para>
82         <indexterm><primary>winbind</primary></indexterm>
83         Recent Samba mailing-list activity is witness to how many sites are using winbind. Some have no trouble
84         at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning
85         an inability to achieve identical user and group IDs between Windows and UNIX environments.
86         </para>
88         <para>
89         You provide step-by-step implementations of the various tools that can be used for identity
90         resolution. You also provide working examples of solutions for integrated authentication for
91         both UNIX/Linux and Windows environments.
92         </para>
94         <sect2>
95                 <title>Technical Issues</title>
97                 <para>
98                 One of the great challenges we face when people ask us, <quote>What is the best way to solve
99                 this problem?</quote> is to get beyond the facts so we not only can clearly comprehend
100                 the immediate technical problem, but also can understand how needs may change.
101                 </para>
103                 <para>
104                 <indexterm><primary>integrate</primary></indexterm>
105                 There are a few facts we should note when dealing with the question of how best to
106                 integrate UNIX/Linux clients and servers into a Windows networking environment:
107                 </para>
109                 <itemizedlist>
110                         <listitem><para>
111                         <indexterm><primary>Domain Controller</primary></indexterm>
112                         <indexterm><primary>authoritative</primary></indexterm>
113                         <indexterm><primary>accounts</primary><secondary>authoritative</secondary></indexterm>
114                         <indexterm><primary>PDC</primary></indexterm>
115                         <indexterm><primary>BDC</primary></indexterm>
116                         A domain controller (PDC or BDC) is always authoritative for all accounts in its domain.
117                         This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs
118                         to the same values that the PDC resolved them to.
119                         </para></listitem>
121                         <listitem><para>
122                         <indexterm><primary>local accounts</primary></indexterm>
123                         <indexterm><primary>Domain Member</primary><secondary>authoritative</secondary><tertiary>local accounts</tertiary></indexterm>
124                         <indexterm><primary>Domain accounts</primary></indexterm>
125                         <indexterm><primary>winbindd</primary></indexterm>
126                         A domain member can be authoritative for local accounts, but is never authoritative for
127                         domain accounts. If a user is accessing a domain member server and that user's account
128                         is not known locally, the domain member server must resolve the identity of that user
129                         from the domain in which that user's account resides. It must then map that ID to a
130                         UID/GID pair that it can use locally. This is handled by <command>winbindd</command>.
131                         </para></listitem>
133                         <listitem><para>
134                         Samba, when running on a domain member server, can resolve user identities from a
135                         number of sources:
136                         </para>
138                         <itemizedlist>
139                                 <listitem><para>
140                                 <indexterm><primary>getpwnam</primary></indexterm>
141                                 <indexterm><primary>getgrnam</primary></indexterm>
142                                 <indexterm><primary>NSS</primary></indexterm>
143                                 <indexterm><primary>LDAP</primary></indexterm>
144                                 <indexterm><primary>NIS</primary></indexterm>
145                                 By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call. 
146                                 On systems that support it, this utilizes the name service switch (NSS) facility to 
147                                 resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename> 
148                                 file. NSS can be configured to use LDAP, winbind, NIS, or local files.
149                                 </para></listitem>
151                                 <listitem><para>
152                                 <indexterm><primary>passdb backend</primary></indexterm>
153                                 <indexterm><primary>PADL</primary></indexterm>
154                                 <indexterm><primary>nss_ldap</primary></indexterm>
155                                 Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured).
156                                 This requires the use of the PADL nss_ldap tool (or equivalent).
157                                 </para></listitem>
159                                 <listitem><para>
160                                 <indexterm><primary>winbindd</primary></indexterm>
161                                 <indexterm><primary>SID</primary></indexterm>
162                                 <indexterm><primary>winbindd_idmap.tdb</primary></indexterm>
163                                 <indexterm><primary>winbindd_cache.tdb</primary></indexterm>
164                                 Directly by querying <command>winbindd</command>. The <command>winbindd</command>
165                                 contacts a domain controller to attempt to resolve the identity of the user or group. It
166                                 receives the Windows networking security identifier (SID) for that appropriate
167                                 account and then allocates a local UID or GID from the range of available IDs and
168                                 creates an entry in its <filename>winbindd_idmap.tdb</filename> and 
169                                 <filename>winbindd_cache.tdb</filename> files.
170                                 </para>
172                                 <para>
173                                 <indexterm><primary>idmap backend</primary></indexterm>
174                                 <indexterm><primary>mapping</primary></indexterm>
175                                 If the parameter <smbconfoption name="idmap backend">ldap:ldap://myserver.domain</smbconfoption>
176                                 was specified and the LDAP server has been configured with a container in which it may
177                                 store the IDMAP entries, all domain members may share a common mapping.
178                                 </para></listitem>
179                         </itemizedlist>
181                         <para>
182                         Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of
183                         the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename> and
184                                 <filename>winbindd_cache.tdb</filename> files to do this.
185                         </para>
187                         <para>
188                         Which of the resolver methods is chosen is determined by the way that Samba is configured 
189                         in the &smb.conf; file. Some of the configuration options are rather less than obvious to the 
190                         casual user.
191                         </para></listitem>
193                         <listitem><para>
194                         <indexterm><primary>winbind trusted domains only</primary></indexterm>
195                         <indexterm><primary>domain member</primary><secondary>servers</secondary></indexterm>
196                         <indexterm><primary>domain controllers</primary></indexterm>
197                         If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
198                         of being resolved using) the NSS facility, it is possible to use the 
199                         <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
200                         in the &smb.conf; file. This parameter specifically applies to domain controllers, 
201                         and to domain member servers.
202                         </para></listitem>
204                 </itemizedlist>
206                 <para>
207                 <indexterm><primary>Posix accounts</primary></indexterm>
208                 <indexterm><primary>Samba accounts</primary></indexterm>
209                 <indexterm><primary>LDAP</primary></indexterm>
210                 For many administrators, it should be plain that the use of an LDAP-based repository for all network
211                 accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and
212                 controllable facility. You eventually appreciate the decision to use LDAP.
213                 </para>
215                 <para>
216                 <indexterm><primary>nss_ldap</primary></indexterm>
217                 <indexterm><primary>identifiers</primary></indexterm>
218                 <indexterm><primary>resolve</primary></indexterm>
219                 If your network account information resides in an LDAP repository, you should use it ahead of any
220                 alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command>
221                 tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides
222                 a more readily controllable method for asserting the exact same user and group identifiers 
223                 throughout the network.
224                 </para>
226                 <para>
227                 <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
228                 <indexterm><primary>winbind trusted domains only</primary></indexterm>
229                 <indexterm><primary>getpwnam</primary></indexterm>
230                 <indexterm><primary>smbd</primary></indexterm>
231                 <indexterm><primary>Trusted Domains</primary></indexterm>
232                 <indexterm><primary>External Domains</primary></indexterm>
233                 In the situation where UNIX accounts are held on the domain member server itself, the only effective
234                 way to use them involves the &smb.conf; entry 
235                 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>. This forces 
236                 Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can
237                 then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter
238                 disables the use of Samba with trusted domains (i.e., external domains).
239                 </para>
241                 <para>
242                 <indexterm><primary>appliance mode</primary></indexterm>
243                 <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
244                 <indexterm><primary>winbindd</primary></indexterm>
245                 <indexterm><primary>automatically allocate</primary></indexterm>
246                 Winbind can be used to create an appliance mode domain member server. In this capacity, <command>winbindd</command>
247                 is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation
248                 is made for all accounts that connect to that domain member server, whether within its own domain or from
249                 trusted domains. If not stored in an LDAP backend, each domain member maintains its own unique mapping database.
250                 This means that it is almost certain that a given user who accesses two domain member servers does not have the
251                 same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data
252                 is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files.
253                 </para>
254         
255                 <para>
256                 <indexterm><primary>mapping</primary></indexterm>
257                 The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs
258                 mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member
259                 servers so configured. This solves one of the major headaches for network administrators who need to copy
260                 files between or across network file servers.
261                 </para>
263         </sect2>
265         <sect2>
266                 <title>Political Issues</title>
268                 <para>
269                 <indexterm><primary>OpenLDAP</primary></indexterm>
270                 <indexterm><primary>NIS</primary></indexterm>
271                 <indexterm><primary>yellow pages</primary><see>NIS</see></indexterm>
272                 <indexterm><primary>identity management</primary></indexterm>
273                 One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in
274                 particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
275                 is different and requires a new approach to the need for a better identity management solution. The more
276                 you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
277                 </para>
279                 <para>
280                 LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos. 
281                 The reason these are preferable is because they are heterogenous. Windows solutions of this sort are <emphasis>not</emphasis> 
282                 heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that 
283                 you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires 
284                 commercial integration products. But it's not what Active Directory was designed for.
285                 </para>
287                 <para>
288                 <indexterm><primary>directory</primary></indexterm>
289                 <indexterm><primary>management</primary></indexterm>
290                 A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
291                 is the first application group to almost force network administrators to use LDAP. It should be pointed
292                 out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has
293                 finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
294                 organizational directory needs.
295                 </para>
297         </sect2>
299 </sect1>
301 <sect1>
302         <title>Implementation</title>
304         <para>
305         <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
306         <indexterm><primary>Domain Member</primary><secondary>client</secondary></indexterm>
307         <indexterm><primary>Domain Controller</primary></indexterm>
308         The domain member server and the domain member client are at the center of focus in this chapter.
309         Configuration of Samba-3 domain controller is covered in earlier chapters, so if your 
310         interest is in domain controller configuration, you will not find that here. You will find good
311         oil that helps you to add domain member servers and clients.
312         </para>
314         <para>
315         <indexterm><primary>Domain Member</primary><secondary>workstations</secondary></indexterm>
316         In practice, domain member servers and domain member workstations are very different entities, but in
317         terms of technology they share similar core infrastructure. A technologist would argue that servers
318         and workstations are identical. Many users would argue otherwise, given that in a well-disciplined
319         environment a workstation (client) is a device from which a user creates documents and files that
320         are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item,
321         but a server is viewed as a core component of the business.
322         </para>
324         <para>
325         <indexterm><primary>workstation</primary></indexterm>
326         We can look at this another way. If a workstation breaks down, one user is affected, but if a
327         server breaks down, hundreds of users may not be able to work. The services that a workstation
328         must provide are document- and file-production oriented; a server provides information storage
329         and is distribution oriented.
330         </para>
332         <para>
333         <indexterm><primary>authentication process</primary></indexterm>
334         <indexterm><primary>logon process</primary></indexterm>
335         <indexterm><primary>user identities</primary></indexterm>
336         <emphasis>Why is this important?</emphasis> For starters, we must identify what
337         components of the operating system and its environment must be configured. Also, it is necessary
338         to recognize where the interdependencies between the various services to be used are.
339         In particular, it is important to understand the operation of each critical part of the
340         authentication process, the logon process, and how user identities get resolved and applied
341         within the operating system and applications (like Samba) that depend on this and may
342         actually contribute to it.
343         </para>
345         <para>
346         So, in this chapter we demonstrate how to implement the technology. It is done within a context of
347         what type of service need must be fulfilled.
348         </para>
350         <sect2 id="sdcsdmldap">
351         <title>Samba Domain with Samba Domain Member Server &smbmdash; Using NSS LDAP</title>
353         <para>
354         <indexterm><primary>ldapsam</primary></indexterm>
355         <indexterm><primary>ldapsam backend</primary></indexterm>
356         <indexterm><primary>IDMAP</primary></indexterm>
357         <indexterm><primary>mapping</primary><secondary>consistent</secondary></indexterm>
358         <indexterm><primary>winbindd</primary></indexterm>
359         <indexterm><primary>foreign SID</primary></indexterm>
360         In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
361         an LDAP ldapsam backend. We are adding to the LDAP backend database (directory)
362         containers for use by the IDMAP facility. This makes it possible to have globally consistent
363         mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run 
364         <command>winbindd</command> as part of your configuration. The primary purpose of running
365         <command>winbindd</command> (within this operational context) is to permit mapping of foreign
366         SIDs (those not originating from the the local Samba server). Foreign SIDs can come from any
367         domain member client or server, or from Windows clients that do not belong to a domain. Another
368         way to explain the necessity to run <command>winbindd</command> is that Samba can locally
369         resolve only accounts that belong to the security context of its own machine SID. Winbind
370         handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated
371         from the parameter values set in the &smb.conf; file for the <parameter>idmap uid</parameter> and
372         <parameter>idmap gid</parameter> ranges. Where LDAP is used, the mappings can be stored in LDAP
373         so that all domain member servers can use a consistent mapping.
374         </para>
376         <para>
377         <indexterm><primary>winbindd</primary></indexterm>
378         <indexterm><primary>getpwnam</primary></indexterm>
379         <indexterm><primary>NSS</primary></indexterm>
380         If your installation is accessed only from clients that are members of your own domain, and all 
381         user accounts are present in a local passdb backend then it is not necessary to run
382         <command>winbindd</command>. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam.
383         </para>
385         <para>
386         It is possible to use a local passdb backend with any convenient means of resolving the POSIX
387         user and group account information. The POSIX information is usually obtained using the
388         <command>getpwnam()</command> system call. On NSS-enabled systems, the actual POSIX account
389         source can be provided from
390         </para>
392         <itemizedlist>
393                 <listitem><para>
394                 <indexterm><primary>/etc/passwd</primary></indexterm>
395                 <indexterm><primary>/etc/group</primary></indexterm>
396                 Accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>.
397                 </para></listitem>
399                 <listitem><para>
400                 <indexterm><primary>NSS</primary></indexterm>
401                 <indexterm><primary>compat</primary></indexterm>
402                 <indexterm><primary>ldap</primary></indexterm>
403                 <indexterm><primary>nis</primary></indexterm>
404                 <indexterm><primary>nisplus</primary></indexterm>
405                 <indexterm><primary>hesiod</primary></indexterm>
406                 <indexterm><primary>ldap</primary></indexterm>
407                 <indexterm><primary>nss_ldap</primary></indexterm>
408                 <indexterm><primary>PADL Software</primary></indexterm>
409                 Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
410                 via multiple methods. The methods typically include <command>files</command>,
411                 <command>compat</command>, <command>db</command>, <command>ldap</command>, 
412                 <command>nis</command>, <command>nisplus</command>, <command>hesiod.</command>  When
413                 correctly installed, Samba adds to this list the <command>winbindd</command> facility.
414                 The ldap facility is frequently the nss_ldap tool provided by PADL Software.
415                 </para></listitem>
416         </itemizedlist>
418         <note><para>
419         To advoid confusion the use of the term <literal>local passdb backend</literal> means that
420         the user account backend is not shared by any other Samba server &smbmdash; instead, it is
421         used only locally on the Samba domain member server under discussion.
422         </para></note>
424         <para>
425         <indexterm><primary>Identity resolution</primary></indexterm>
426         The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of Samba and system 
427         components that are involved in the identity resolution process where Samba is used as a domain
428         member server within a Samba domain control network.
429         </para>
431 <figure id="ch9-sambadc">
432         <title>Samba Domain: Samba Member Server</title>
433         <imagefile scale="60">chap9-SambaDC</imagefile>
434 </figure>
436         <para>
437         <indexterm><primary>IDMAP</primary></indexterm>
438         <indexterm><primary>foreign</primary></indexterm>
439         In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam
440         to obtain authentication and user identity information. The IDMAP information is stored in the LDAP
441         backend so that it can be shared by all domain member servers so that every user will have a
442         consistent UID and GID across all of them. The IDMAP facility will be used for all foreign
443         (i.e., not having the same SID as the domain it is a member of) domains. The configuration of 
444         NSS will ensure that all UNIX processes will obtain a consistent UID/GID.
445         </para>
447         <para>
448         The instructions given here apply to the Samba environment shown in <link linkend="happy"/> and <link linkend="net2000users"/>.
449         If the network does not have an LDAP slave server (i.e., <link linkend="happy"/> configuration), 
450         change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
451         </para>
453         <procedure>
454         <title>Configuration of NSS_LDAP-Based Identity Resolution</title>
456                 <step><para>
457                 Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate
458                 this file in the directory <filename>/etc/samba</filename>.
459                 </para></step>
461                 <step><para>
462                 <indexterm><primary>ldap.conf</primary></indexterm>
463                 Configure the file that will be used by <constant>nss_ldap</constant> to
464                 locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>.
465                 If your implementation of <constant>nss_ldap</constant> is consistent with
466                 the defaults suggested by PADL (the authors), it will be located in the
467                 <filename>/etc</filename> directory. On some systems, the default location is
468                 the <filename>/etc/openldap</filename> directory, however this file is intended
469                 for use by the OpenLDAP utilities and should not really be used by the nss_ldap
470                 utility since its content and structure serves the specific purpose of enabling
471                 the resolution of user and group IDs via NSS.
472                 </para>
474                 <para>
475                 Change the parameters inside the file that is located on your OS so it matches
476                 <link linkend="ch9-sdmlcnf"/>.  To find the correct location of this file, you
477                 can obtain this from the library that will be used by executing the following:
478 <screen>
479 &rootprompt; strings /lib/libnss_ldap* | grep ldap.conf
480 /etc/ldap.conf
481 </screen>
482                 </para></step>
484                 <step><para>
485                 Configure the NSS control file so it matches the one shown in
486                 <link linkend="ch9-sdmnss"/>.
487                 </para></step>
489                 <step><para>
490                 <indexterm><primary>Identity resolution</primary></indexterm>
491                 <indexterm><primary>getent</primary></indexterm>
492                 Before proceeding to configure Samba, validate the operation of the NSS identity 
493                 resolution via LDAP by executing:
494 <screen>
495 &rootprompt; getent passwd
497 root:x:0:512:Netbios Domain Administrator:/root:/bin/false
498 nobody:x:999:514:nobody:/dev/null:/bin/false
499 bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
500 stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
501 chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
502 maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
503 jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
504 bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
505 temptation$:x:1009:553:temptation$:/dev/null:/bin/false
506 vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
507 fran$:x:1008:553:fran$:/dev/null:/bin/false
508 josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash
509 </screen>
510                 You should notice the location of the users' home directories. First, make certain that
511                 the home directories exist on the domain member server; otherwise, the home directory
512                 share is not available. The home directories could be mounted off a domain controller
513                 using NFS or by any other suitable means. Second, the absence of the domain name in the
514                 home directory path is indicative that identity resolution is not being done via winbind.
515 <screen>
516 &rootprompt; getent group
518 Domain Admins:x:512:root,jht
519 Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
520 Domain Guests:x:514:
521 Accounts:x:1000:
522 Finances:x:1001:
523 PIOps:x:1002:
524 sammy:x:4321:
525 </screen>
526                 <indexterm><primary>secondary group</primary></indexterm>
527                 <indexterm><primary>primary group</primary></indexterm>
528                 <indexterm><primary>group membership</primary></indexterm>
529                 This shows that all is working as it should be. Notice that in the LDAP database
530                 the users' primary and secondary group memberships are identical. It is not
531                 necessary to add secondary group memberships (in the group database) if the
532                 user is already a member via primary group membership in the password database.
533                 When using winbind, it is in fact undesirable to do this because it results in
534                 doubling up of group memberships and may cause problems with winbind under certain 
535                 conditions. It is intended that these limitations with winbind will be resolved soon
536                 after Samba-3.0.20 has been released.
537                 </para></step>
539                 <step><para>
540                 <indexterm><primary>slapcat</primary></indexterm>
541                 The LDAP directory must have a container object for IDMAP data. There are several ways you can
542                 check that your LDAP database is able to receive IDMAP information. One of the simplest is to
543                 execute:
544 <screen>
545 &rootprompt; slapcat | grep -i idmap
546 dn: ou=Idmap,dc=abmas,dc=biz
547 ou: idmap
548 </screen>
549                 <indexterm><primary>ldapadd</primary></indexterm>
550                 If the execution of this command does not return IDMAP entries, you need to create an LDIF
551                 template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using
552                 the following command:
553 <screen>
554 &rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
555                 -w not24get &lt; /etc/openldap/idmap.LDIF
556 </screen>
557                 </para></step>
559                 <step><para>
560                 Samba automatically populates the LDAP directory container when it needs to. To permit Samba
561                 write access to the LDAP directory it is necessary to set the LDAP administrative password
562                 in the <filename>secrets.tdb</filename> file as shown here:
563 <screen>
564 &rootprompt; smbpasswd -w not24get
565 </screen>
566                 </para></step>
568                 <step><para>
569                 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
570                 <indexterm><primary>Domain join</primary></indexterm>
571                 The system is ready to join the domain. Execute the following:
572 <screen>
573 &rootprompt; net rpc join -U root%not24get
574 Joined domain MEGANET2.
575 </screen>
576                 This indicates that the domain join succeeded.
577                 </para>
579                 <para>
580                 Failure to join the domain could be caused by any number of variables. The most common
581                 causes of failure to join are:
582                 </para>
584                 <para>
585                 <itemizedlist>
586                         <listitem><para>Broken resolution of NetBIOS names to the respective IP address.</para></listitem>
587                         <listitem><para>Incorrect username and password credentials.</para></listitem>
588                         <listitem><para>The NT4 <parameter>restrict anonymous</parameter> is set to exclude anonymous
589                                 connections.</para></listitem>
590                 </itemizedlist> 
591                 </para>
593                 <para>
594                 The connection setup can be diagnosed by executing:
595 <screen>
596 &rootprompt; net rpc join -S 'pdc-name' -U administrator%password -d 5
597 </screen>
598                 <indexterm><primary>failed</primary></indexterm>
599                 <indexterm><primary>failed join</primary></indexterm>
600                 <indexterm><primary>rejected</primary></indexterm>
601                 <indexterm><primary>restrict anonymous</primary></indexterm>
602                 Note: Use "root" for UNIX/Linux and Samba, use "Administrator" for Windows NT4/200X. If the cause of
603                 the failure appears to be related to a rejected or failed NT_SESSION_SETUP*  or an error message that
604                 says NT_STATUS_ACCESS_DENIED immediately check the Windows registry setting that controls the
605                 <constant>restrict anonymous</constant> setting. Set this to the value 0 so that an anonymous connection
606                 can be sustained, then try again.
607                 </para>
609                 <para>
610                 It is possible (perhaps even recommended) to use the following to validate the ability to connect
611                 to an NT4 PDC/BDC:
612 <screen>
613 &rootprompt; net rpc info -S 'pdc-name' -U Administrator%not24get
614 Domain Name: MEGANET2
615 Domain SID: S-1-5-21-422319763-4138913805-7168186429
616 Sequence number: 1519909596
617 Num users: 7003
618 Num domain groups: 821
619 Num local groups: 8
621 &rootprompt; net rpc testjoin -S 'pdc-name' -U Administrator%not24get
622 Join to 'MEGANET2' is OK
623 </screen>
624                 If for any reason the following response is obtained to the last command above,it is time to
625                 call in the Networking Super-Snooper task force (i.e., start debugging):
626 <screen>
627 NT_STATUS_ACCESS_DENIED
628 Join to 'MEGANET2' failed.
629 </screen>
630                 </para></step>
632                 <step><para>
633                 <indexterm><primary>wbinfo</primary></indexterm>
634                 Just joining the domain is not quite enough; you must now provide a privileged set
635                 of credentials through which <command>winbindd</command> can interact with the 
636                 domain servers. Execute the following to implant the necessary credentials:
637 <screen>
638 &rootprompt; wbinfo --set-auth-user=Administrator%not24get
639 </screen>
640                 The configuration is now ready to obtain the Samba domain user and group information.
641                 </para></step>
643                 <step><para>
644                 You may now start Samba in the usual manner, and your Samba domain member server
645                 is ready for use. Just add shares as required.
646                 </para></step>
648         </procedure>
650 <example id="ch9-sdmsdc">
651 <title>Samba Domain Member in Samba Domain Using LDAP &smbmdash; &smb.conf; File</title>
652 <smbconfblock>
653 <smbconfcomment>Global parameters</smbconfcomment>
654 <smbconfsection name="[global]"/>
655 <smbconfoption name="unix charset">LOCALE</smbconfoption>
656 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
657 <smbconfoption name="security">DOMAIN</smbconfoption>
658 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
659 <smbconfoption name="log level">10</smbconfoption>
660 <smbconfoption name="syslog">0</smbconfoption>
661 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
662 <smbconfoption name="max log size">50</smbconfoption>
663 <smbconfoption name="smb ports">139</smbconfoption>
664 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
665 <smbconfoption name="printcap name">CUPS</smbconfoption>
666 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
667 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
668 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
669 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
670 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
671 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
672 <smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
673 <smbconfoption name="idmap backend">ldap:ldap://lapdc.abmas.biz</smbconfoption>
674 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
675 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
676 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
677 <smbconfoption name="printing">cups</smbconfoption>
679 <smbconfsection name="[homes]"/>
680 <smbconfoption name="comment">Home Directories</smbconfoption>
681 <smbconfoption name="valid users">%S</smbconfoption>
682 <smbconfoption name="read only">No</smbconfoption>
683 <smbconfoption name="browseable">No</smbconfoption>
685 <smbconfsection name="[printers]"/>
686 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
687 <smbconfoption name="path">/var/spool/samba</smbconfoption>
688 <smbconfoption name="guest ok">Yes</smbconfoption>
689 <smbconfoption name="printable">Yes</smbconfoption>
690 <smbconfoption name="browseable">No</smbconfoption>
692 <smbconfsection name="[print$]"/>
693 <smbconfoption name="comment">Printer Drivers</smbconfoption>
694 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
695 <smbconfoption name="admin users">root, Administrator</smbconfoption>
696 <smbconfoption name="write list">root</smbconfoption>
697 </smbconfblock>
698 </example>
700 <example id="ch9-ldifadd">
701 <title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title>
702 <screen>
703 dn: ou=Idmap,dc=abmas,dc=biz
704 objectClass: organizationalUnit
705 ou: idmap
706 structuralObjectClass: organizationalUnit
707 </screen>
708 </example>
710 <example id="ch9-sdmlcnf">
711 <title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title>
712 <screen>
713 URI     ldap://massive.abmas.biz ldap://massive.abmas.biz:636
714 host    192.168.2.1
715 base    dc=abmas,dc=biz
716 binddn  cn=Manager,dc=abmas,dc=biz
717 bindpw  not24get
719 pam_password exop
721 nss_base_passwd ou=People,dc=abmas,dc=biz?one
722 nss_base_shadow ou=People,dc=abmas,dc=biz?one
723 nss_base_group  ou=Groups,dc=abmas,dc=biz?one
724 ssl     no
725 </screen>
726 </example>
728 <example id="ch9-sdmnss">
729 <title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
730 <screen>
731 passwd:         files ldap
732 shadow:         files ldap
733 group:          files ldap
735 hosts:          files dns wins
736 networks:       files dns
738 services:       files
739 protocols:      files
740 rpc:            files
741 ethers:         files
742 netmasks:       files
743 netgroup:       files
744 publickey:      files
746 bootparams:     files
747 automount:      files
748 aliases:        files
749 </screen>
750 </example>
752         </sect2>
754         <sect2 id="wdcsdm">
755                 <title>NT4/Samba Domain with Samba Domain Member Server: Using NSS and Winbind</title>
757         <para>
758         You need to use this method for creating a Samba domain member server if any of the following conditions
759         prevail:
760         </para>
762         <itemizedlist>
763                 <listitem><para>
764                 LDAP support (client) is not installed on the system.
765                 </para></listitem>
767                 <listitem><para>
768                 There are mitigating circumstances forcing a decision not to use LDAP.
769                 </para></listitem>
771                 <listitem><para>
772                 The Samba domain member server must be part of a Windows NT4 Domain, or a Samba Domain.
773                 </para></listitem>
774         </itemizedlist>
776         <para>
777         <indexterm><primary>Windows ADS Domain</primary></indexterm>
778         <indexterm><primary>Samba Domain</primary></indexterm>
779         <indexterm><primary>LDAP</primary></indexterm>
780         Later in the chapter, you can see how to configure a Samba domain member server for a Windows ADS domain.
781         Right now your objective is to configure a Samba server that can be a member of a Windows NT4-style
782         domain and/or does not use LDAP.
783         </para>
785         <note><para>
786         <indexterm><primary>duplicate accounts</primary></indexterm>
787         If you use <command>winbind</command> for identity resolution, make sure that there are no
788         duplicate accounts.
789         </para>
791         <para>
792         <indexterm><primary>/etc/passwd</primary></indexterm>
793         For example, do not have more than one account that has UID=0 in the password database. If there 
794         is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database, 
795         it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the 
796         tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will 
797         break. This means that the <constant>Administrator</constant> account must be called 
798         <constant>root</constant>.
799         </para>
801         <para>
802         <indexterm><primary>/etc/passwd</primary></indexterm>
803         <indexterm><primary>ldapsam</primary></indexterm>
804         <indexterm><primary>tdbsam</primary></indexterm>
805         Winbind will break if there is an account in <filename>/etc/passwd</filename> that has 
806         the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
807         </para></note>
809         <para>
810         <indexterm><primary>credentials</primary></indexterm>
811         <indexterm><primary>traverse</primary></indexterm>
812         <indexterm><primary>wide-area</primary></indexterm>
813         <indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm>
814         <indexterm><primary>tdbdump</primary></indexterm>
815         The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
816         The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename>
817         files. This provides considerable performance benefits compared with the LDAP solution, particularly
818         where the LDAP lookups must traverse WAN links. You may examine the contents of these
819         files using the tool <command>tdbdump</command>, though you may have to build this from the Samba
820         source code if it has not been supplied as part of a binary package distribution that you may be using.
821         </para>
823         <procedure>
824         <title>Configuration of Winbind-Based Identity Resolution</title>
826                 <step><para>
827                 Using your favorite text editor, create the &smb.conf; file so it has the contents
828                 shown in <link linkend="ch0-NT4DSDM"/>.
829                 </para></step>
831                 <step><para>
832                 <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
833                 Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in
834                 <link linkend="ch9-sdmnss"/>.
835                 </para></step>
837                 <step><para>
838                 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
839                 The system is ready to join the domain. Execute the following:
840 <screen>
841 net rpc join -U root%not2g4et
842 Joined domain MEGANET2.
843 </screen>
844                 This indicates that the domain join succeed.
846                 </para></step>
848                 <step><para>
849                 <indexterm><primary>winbind</primary></indexterm>
850                 <indexterm><primary>wbinfo</primary></indexterm>
851                 Validate operation of <command>winbind</command> using the <command>wbinfo</command>
852                 tool as follows:
853 <screen>
854 &rootprompt; wbinfo -u
855 MEGANET2+root
856 MEGANET2+nobody
857 MEGANET2+jht
858 MEGANET2+maryv
859 MEGANET2+billr
860 MEGANET2+jelliott
861 MEGANET2+dbrady
862 MEGANET2+joeg
863 MEGANET2+balap
864 </screen>
865                 This shows that domain users have been listed correctly.
866 <screen>
867 &rootprompt; wbinfo -g
868 MEGANET2+Domain Admins
869 MEGANET2+Domain Users
870 MEGANET2+Domain Guests
871 MEGANET2+Accounts
872 MEGANET2+Finances
873 MEGANET2+PIOps
874 </screen>
875                 This shows that domain groups have been correctly obtained also.
876                 </para></step>
878                 <step><para>
879                 <indexterm><primary>NSS</primary></indexterm>
880                 <indexterm><primary>getent</primary></indexterm>
881                 <indexterm><primary>winbind</primary></indexterm>
882                 The next step verifies that NSS is able to obtain this information
883                 correctly from <command>winbind</command> also.
884 <screen>
885 &rootprompt; getent passwd
887 MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
888                       /home/MEGANET2/root:/bin/bash
889 MEGANET2+nobody:x:10001:10001:nobody:
890                       /home/MEGANET2/nobody:/bin/bash
891 MEGANET2+jht:x:10002:10001:John H Terpstra:
892                       /home/MEGANET2/jht:/bin/bash
893 MEGANET2+maryv:x:10003:10001:Mary Vortexis:
894                       /home/MEGANET2/maryv:/bin/bash
895 MEGANET2+billr:x:10004:10001:William Randalph:
896                       /home/MEGANET2/billr:/bin/bash
897 MEGANET2+jelliott:x:10005:10001:John G Elliott:
898                       /home/MEGANET2/jelliott:/bin/bash
899 MEGANET2+dbrady:x:10006:10001:Darren Brady:
900                       /home/MEGANET2/dbrady:/bin/bash
901 MEGANET2+joeg:x:10007:10001:Joe Green:
902                       /home/MEGANET2/joeg:/bin/bash
903 MEGANET2+balap:x:10008:10001:Bala Pillay:
904                       /home/MEGANET2/balap:/bin/bash
905 </screen>
906                 The user account information has been correctly obtained. This information has
907                 been merged with the winbind template information configured in the &smb.conf; file.
908 <screen>
909 &rootprompt;# getent group
911 MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
912 MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
913         MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
914         MEGANET2+joeg,MEGANET2+balap
915 MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
916 MEGANET2+Accounts:x:10003:
917 MEGANET2+Finances:x:10004:
918 MEGANET2+PIOps:x:10005:
919 </screen>
920                 </para></step>
922                 <step><para>
923                 The Samba member server of a Windows NT4 domain is ready for use.
924                 </para></step>
926         </procedure>
928 <example id="ch0-NT4DSDM">
929 <title>Samba Domain Member Server Using Winbind &smb.conf; File for NT4 Domain</title>
930 <smbconfblock>
931 <smbconfcomment>Global parameters</smbconfcomment>
932 <smbconfsection name="[global]"/>
933 <smbconfoption name="unix charset">LOCALE</smbconfoption>
934 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
935 <smbconfoption name="security">DOMAIN</smbconfoption>
936 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
937 <smbconfoption name="log level">1</smbconfoption>
938 <smbconfoption name="syslog">0</smbconfoption>
939 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
940 <smbconfoption name="max log size">0</smbconfoption>
941 <smbconfoption name="smb ports">139</smbconfoption>
942 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
943 <smbconfoption name="printcap name">CUPS</smbconfoption>
944 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
945 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
946 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
947 <smbconfoption name="template primary group">"Domain Users"</smbconfoption>
948 <smbconfoption name="template shell">/bin/bash</smbconfoption>
949 <smbconfoption name="winbind separator">+</smbconfoption>
950 <smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
951 <smbconfoption name="printing">cups</smbconfoption>
953 <smbconfsection name="[homes]"/>
954 <smbconfoption name="comment">Home Directories</smbconfoption>
955 <smbconfoption name="valid users">%S</smbconfoption>
956 <smbconfoption name="read only">No</smbconfoption>
957 <smbconfoption name="browseable">No</smbconfoption>
959 <smbconfsection name="[printers]"/>
960 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
961 <smbconfoption name="path">/var/spool/samba</smbconfoption>
962 <smbconfoption name="guest ok">Yes</smbconfoption>
963 <smbconfoption name="printable">Yes</smbconfoption>
964 <smbconfoption name="browseable">No</smbconfoption>
966 <smbconfsection name="[print$]"/>
967 <smbconfoption name="comment">Printer Drivers</smbconfoption>
968 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
969 <smbconfoption name="admin users">root, Administrator</smbconfoption>
970 <smbconfoption name="write list">root</smbconfoption>
971 </smbconfblock>
972 </example>
974         </sect2>
976         <sect2 id="dcwonss">
977         <title>NT4/Samba Domain with Samba Domain Member Server without NSS Support</title>
979         <para>
980         No matter how many UNIX/Linux administrators there may be who believe that a UNIX operating
981         system that does not have NSS and PAM support to be outdated, the fact is there
982         are still many such systems in use today. Samba can be used without NSS support, but this
983         does limit it to the use of local user and group accounts only.
984         </para>
986         <para>
987         The following steps may be followed to implement Samba with support for local accounts.
988         In this configuration Samba is made a domain member server. All incoming connections
989         to the Samba server will cause the look-up of the incoming username. If the account
990         is found, it is used. If the account is not found, one will be automatically created
991         on the local machine so that it can then be used for all access controls.
992         </para>
994         <procedure>
995         <title>Configuration Using Local Accounts Only</title>
997                 <step><para>
998                 Using your favorite text editor, create the &smb.conf; file so it has the contents
999                 shown in <link linkend="ch0-NT4DSCM"/>.
1000                 </para></step>
1002                 <step>
1003                 <para><indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
1004                 The system is ready to join the domain. Execute the following:
1005 <screen>
1006 net rpc join -U root%not24get
1007 Joined domain MEGANET2.
1008 </screen>
1009                 This indicates that the domain join succeed.
1010                 </para></step>
1012                 <step><para>
1013                 Be sure to run all three Samba daemons: <command>smbd</command>, <command>nmbd</command>, <command>winbindd</command>.
1014                 </para></step>
1016                 <step><para>
1017                 The Samba member server of a Windows NT4 domain is ready for use.
1018                 </para></step>
1019         </procedure>
1021 <example id="ch0-NT4DSCM">
1022 <title>Samba Domain Member Server Using Local Accounts &smb.conf; File for NT4 Domain</title>
1023 <smbconfblock>
1024 <smbconfcomment>Global parameters</smbconfcomment>
1025 <smbconfsection name="[global]"/>
1026 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1027 <smbconfoption name="workgroup">MEGANET3</smbconfoption>
1028 <smbconfoption name="netbios name">BSDBOX</smbconfoption>
1029 <smbconfoption name="security">DOMAIN</smbconfoption>
1030 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1031 <smbconfoption name="log level">1</smbconfoption>
1032 <smbconfoption name="syslog">0</smbconfoption>
1033 <smbconfoption name="add user script">/usr/sbin/useradd -m '%u'</smbconfoption>
1034 <smbconfoption name="add machine script">/usr/sbin/useradd -M '%u'</smbconfoption>
1035 <smbconfoption name="add group script">/usr/sbin/groupadd '%g'</smbconfoption>
1036 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1037 <smbconfoption name="max log size">0</smbconfoption>
1038 <smbconfoption name="smb ports">139</smbconfoption>
1039 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
1040 <smbconfoption name="printcap name">CUPS</smbconfoption>
1041 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
1042 <smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
1043 <smbconfoption name="printing">cups</smbconfoption>
1045 <smbconfsection name="[homes]"/>
1046 <smbconfoption name="comment">Home Directories</smbconfoption>
1047 <smbconfoption name="valid users">%S</smbconfoption>
1048 <smbconfoption name="read only">No</smbconfoption>
1049 <smbconfoption name="browseable">No</smbconfoption>
1051 <smbconfsection name="[printers]"/>
1052 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1053 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1054 <smbconfoption name="guest ok">Yes</smbconfoption>
1055 <smbconfoption name="printable">Yes</smbconfoption>
1056 <smbconfoption name="browseable">No</smbconfoption>
1058 <smbconfsection name="[print$]"/>
1059 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1060 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1061 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1062 <smbconfoption name="write list">root</smbconfoption>
1063 </smbconfblock>
1064 </example>
1065         </sect2>
1067         <sect2 id="adssdm">
1068         <title>Active Directory Domain with Samba Domain Member Server</title>
1070         <para>
1071         <indexterm><primary>Active Directory</primary><secondary>join</secondary></indexterm>
1072         <indexterm><primary>Kerberos</primary></indexterm>
1073         <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm>
1074         One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory
1075         domain using Kerberos protocols. This makes it possible to operate an entire Windows network
1076         without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An
1077         exhaustively complete discussion of the protocols is not possible in this book; perhaps a
1078         later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate
1079         in. For now, we simply focus on how a Samba-3 server can be made a domain member server.
1080         </para>
1082         <para>
1083         <indexterm><primary>Active Directory</primary></indexterm>
1084         <indexterm><primary>LDAP</primary></indexterm>
1085         <indexterm><primary>Identity resolution</primary></indexterm>
1086         <indexterm><primary>Kerberos</primary></indexterm>
1087         The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba-3 interfaces with
1088         Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
1089         for UNIX (SFU) has been installed and correctly configured, it is possible to use client LDAP
1090         for identity resolution just as can be done with Samba-3 when using an LDAP passdb backend.
1091         The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL
1092         Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of 
1093         LDAP-based identity resolution is a little less secure. In view of the fact that this solution
1094         requires additional software to be installed on the Windows 200x ADS domain controllers,
1095         and that means more management overhead, it is likely that most Samba-3 ADS client sites
1096         may elect to use winbind.
1097         </para>
1099         <para>
1100         Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3
1101         you are using has been compiled and linked with all the tools necessary for this to work.
1102         Given the importance of this step, you must first validate that the Samba-3 message block
1103         daemon (<command>smbd</command>) has the necessary features.
1104         </para>
1106         <para>
1107         The hypothetical domain you are using in this example assumes that the Abmas London office
1108         decided to take its own lead (some would say this is a typical behavior in a global
1109         corporate world; besides, a little divergence and conflict makes for an interesting life).
1110         The Windows Server 2003 ADS domain is called <constant>london.abmas.biz</constant> and the
1111         name of the server is <constant>W2K3S</constant>. In ADS realm terms, the domain controller
1112         is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the
1113         domain name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>.
1114         </para>
1116         <figure id="ch9-adsdc">
1117                 <title>Active Directory Domain: Samba Member Server</title>
1118                 <imagefile scale="60">chap9-ADSDC</imagefile>
1119         </figure>
1121         <procedure>
1122         <title>Joining a Samba Server as an ADS Domain Member</title>
1124                 <step><para>
1125                 <indexterm><primary>smbd</primary></indexterm>
1126                 Before you try to use Samba-3, you want to know for certain that your executables have
1127                 support for Kerberos and for LDAP. Execute the following to identify whether or
1128                 not this build is perhaps suitable for use:
1129 <screen>
1130 &rootprompt; cd /usr/sbin
1131 &rootprompt; smbd -b | grep KRB
1132    HAVE_KRB5_H
1133    HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
1134    HAVE_KRB5
1135    HAVE_KRB5_AUTH_CON_SETKEY
1136    HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
1137    HAVE_KRB5_GET_PW_SALT
1138    HAVE_KRB5_KEYBLOCK_KEYVALUE
1139    HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
1140    HAVE_KRB5_MK_REQ_EXTENDED
1141    HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
1142    HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
1143    HAVE_KRB5_STRING_TO_KEY
1144    HAVE_KRB5_STRING_TO_KEY_SALT
1145    HAVE_LIBKRB5
1146 </screen>
1147                 This output was obtained on a SUSE Linux system and shows the output for
1148                 Samba that has been compiled and linked with the Heimdal Kerberos libraries.
1149                 The following is a typical output that will be found on a Red Hat Linux system that
1150                 has been linked with the MIT Kerberos libraries:
1151 <screen>
1152 &rootprompt; cd /usr/sbin
1153 &rootprompt; smbd -b | grep KRB
1154    HAVE_KRB5_H
1155    HAVE_ADDRTYPE_IN_KRB5_ADDRESS
1156    HAVE_KRB5
1157    HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
1158    HAVE_KRB5_ENCRYPT_DATA
1159    HAVE_KRB5_FREE_DATA_CONTENTS
1160    HAVE_KRB5_FREE_KTYPES
1161    HAVE_KRB5_GET_PERMITTED_ENCTYPES
1162    HAVE_KRB5_KEYTAB_ENTRY_KEY
1163    HAVE_KRB5_LOCATE_KDC
1164    HAVE_KRB5_MK_REQ_EXTENDED
1165    HAVE_KRB5_PRINCIPAL2SALT
1166    HAVE_KRB5_PRINC_COMPONENT
1167    HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
1168    HAVE_KRB5_SET_REAL_TIME
1169    HAVE_KRB5_STRING_TO_KEY
1170    HAVE_KRB5_TKT_ENC_PART2
1171    HAVE_KRB5_USE_ENCTYPE
1172    HAVE_LIBGSSAPI_KRB5
1173    HAVE_LIBKRB5
1174 </screen>
1175                 You can validate that Samba has been compiled and linked with LDAP support
1176                 by executing:
1177 <screen>
1178 &rootprompt; smbd -b | grep LDAP
1179 massive:/usr/sbin # smbd -b | grep LDAP
1180    HAVE_LDAP_H
1181    HAVE_LDAP
1182    HAVE_LDAP_DOMAIN2HOSTLIST
1183    HAVE_LDAP_INIT
1184    HAVE_LDAP_INITIALIZE
1185    HAVE_LDAP_SET_REBIND_PROC
1186    HAVE_LIBLDAP
1187    LDAP_SET_REBIND_PROC_ARGS
1188 </screen>
1189                 This does look promising; <command>smbd</command> has been built with Kerberos and LDAP
1190                 support. You are relieved to know that it is safe to progress.
1191                 </para></step>
1193                 <step><para>
1194                 <indexterm><primary>Kerberos</primary><secondary>libraries</secondary></indexterm>
1195                 <indexterm><primary>MIT Kerberos</primary></indexterm>
1196                 <indexterm><primary>Heimdal Kerberos</primary></indexterm>
1197                 <indexterm><primary>Kerberos</primary><secondary>MIT</secondary></indexterm>
1198                 <indexterm><primary>Kerberos</primary><secondary>Heimdal</secondary></indexterm>
1199                 <indexterm><primary>Red Hat Linux</primary></indexterm>
1200                 <indexterm><primary>SUSE Linux</primary></indexterm>
1201                 <indexterm><primary>SerNet</primary></indexterm>
1202                 <indexterm><primary>validated</primary></indexterm>
1203                 The next step is to identify which version of the Kerberos libraries have been used.
1204                 In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is
1205                 essential that it has been linked with either MIT Kerberos version 1.3.1 or later,
1206                 or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may
1207                 identify what version of the MIT Kerberos libraries are installed on your system by
1208                 executing (on Red Hat Linux):
1209 <screen>
1210 &rootprompt; rpm -q krb5
1211 </screen>
1212                 Or on SUSE Linux, execute:
1213 <screen>
1214 &rootprompt; rpm -q heimdal
1215 </screen>
1216                 Please note that the RPMs provided by the Samba-Team are known to be working and have
1217                 been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE
1218                 Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in
1219                 Germany.
1220                 </para>
1222                 <para>
1223                 From this point on, you are certain that the Samba-3 build you are using has the
1224                 necessary capabilities. You can now configure Samba-3 and the NSS. 
1225                 </para></step>
1227                 <step><para>
1228                 Using you favorite editor, configure the &smb.conf; file that is located in the 
1229                 <filename>/etc/samba</filename> directory so that it has the contents shown 
1230                 in <link linkend="ch9-adssdm"/>.
1231                 </para></step>
1233                 <step><para>
1234                 Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-sdmnss"/>.
1235                 </para></step>
1237                 <step><para>
1238                 <indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm>
1239                 Delete the file <filename>/etc/samba/secrets.tdb</filename> if it exists. Of course, you
1240                 do keep a backup, don't you?
1241                 </para></step>
1243                 <step><para>
1244                 Delete the tdb files that cache Samba information. You keep a backup of the old
1245                 files, of course. You also remove all files to ensure that nothing can pollute your
1246                 nice, new configuration. Execute the following (example is for SUSE Linux):
1247 <screen>
1248 &rootprompt; rm /var/lib/samba/*tdb
1249 </screen>
1250                 </para></step>
1252                 <step><para>
1253                 <indexterm><primary>testparm</primary></indexterm>
1254                 Validate your &smb.conf; file using <command>testparm</command> (as you have
1255                 done previously). Correct all errors reported before proceeding. The command you
1256                 execute is:
1257 <screen>
1258 &rootprompt; testparm -s | less
1259 </screen>
1260                 Now that you are satisfied that your Samba server is ready to join the Windows
1261                 ADS domain, let's move on.
1262                 </para></step>
1264                 <step><para>
1265                 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>join</tertiary></indexterm>
1266                 <indexterm><primary>Kerberos</primary></indexterm>
1267                 This is a good time to double-check everything and then execute the following
1268                 command when everything you have done has checked out okay:
1269 <screen>
1270 &rootprompt; net ads join -UAdministrator%not24get
1271 Using short domain name -- LONDON
1272 Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
1273 </screen>
1274                 You have successfully made your Samba-3 server a member of the ADS domain
1275                 using Kerberos protocols.
1276                 </para>
1278             <para>
1279                 <indexterm><primary>silent return</primary></indexterm>
1280                 <indexterm><primary>failed join</primary></indexterm>
1281                 In the event that you receive no output messages, a silent return means that the
1282                 domain join failed. You should use <command>ethereal</command> to identify what
1283                 may be failing. Common causes of a failed join include:
1285                 <itemizedlist>
1286                         <listitem><para>
1287                         <indexterm><primary>name resolution</primary><secondary>Defective</secondary></indexterm>
1288                         Defective or misconfigured DNS name resolution.
1289                         </para></listitem>
1291                         <listitem><para>
1292                         <indexterm><primary>Restrictive security</primary></indexterm>
1293                         Restrictive security settings on the Windows 200x ADS domain controller
1294                         preventing needed communications protocols. You can check this by searching
1295                         the Windows Server 200x Event Viewer.
1296                         </para></listitem>
1298                         <listitem><para>
1299                         Incorrectly configured &smb.conf; file settings.
1300                         </para></listitem>
1302                         <listitem><para>
1303                         Lack of support of necessary Kerberos protocols because the version of MIT
1304                         Kerberos (or Heimdal) in use is not up to date enough to support the necessary
1305                         functionality.
1306                         </para></listitem>
1307                 </itemizedlist>
1309                 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm>
1310                 <indexterm><primary>RPC</primary></indexterm>
1311                 <indexterm><primary>mixed mode</primary></indexterm>
1312                 In any case, never execute the <command>net rpc join</command> command in an attempt
1313                 to join the Samba server to the domain, unless you wish not to use the Kerberos
1314                 security protocols. Use of the older RPC-based domain join facility requires that
1315                 Windows Server 200x ADS has been configured appropriately for mixed mode operation.
1316                 </para></step>
1318                 <step><para>
1319                 <indexterm><primary>tdbdump</primary></indexterm>
1320                 <indexterm><primary>/etc/samba/secrets.tdb</primary></indexterm>
1321                 If the <command>tdbdump</command> is installed on your system (not essential),
1322                 you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If
1323                 you wish to do this, execute:
1324 <screen>
1325 &rootprompt; tdbdump secrets.tdb
1327 key = "SECRETS/SID/LONDON"
1328 data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
1329    F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
1330    00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
1331    00\00\00\00\00\00\00\00"
1334 key = "SECRETS/MACHINE_PASSWORD/LONDON"
1335 data = "le3Q5FPnN5.ueC\00"
1338 key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
1339 data = "\02\00\00\00"
1342 key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
1343 data = "E\89\F6?"
1345 </screen>
1346                 This is given to demonstrate to the skeptics that this process truly does work.
1347                 </para></step>
1349                 <step><para>
1350                 It is now time to start Samba in the usual way (as has been done many time before
1351                 in this book).  
1352                 </para></step>
1354                 <step><para>
1355                 <indexterm><primary>wbinfo</primary></indexterm>
1356                 This is a good time to verify that everything is working. First, check that
1357                 winbind is able to obtain the list of users and groups from the ADS domain controller.
1358                 Execute the following:
1359 <screen>
1360 &rootprompt; wbinfo -u
1361 LONDON+Administrator
1362 LONDON+Guest
1363 LONDON+SUPPORT_388945a0
1364 LONDON+krbtgt
1365 LONDON+jht
1366 </screen>
1367                 Good, the list of users was obtained. Now do likewise for group accounts:
1368 <screen>
1369 &rootprompt; wbinfo -g
1370 LONDON+Domain Computers
1371 LONDON+Domain Controllers
1372 LONDON+Schema Admins
1373 LONDON+Enterprise Admins
1374 LONDON+Domain Admins
1375 LONDON+Domain Users
1376 LONDON+Domain Guests
1377 LONDON+Group Policy Creator Owners
1378 LONDON+DnsUpdateProxy
1379 </screen>
1380                 Excellent. That worked also, as expected.
1381                 </para></step>
1383           <step><para><indexterm>
1384                 <primary>getent</primary>
1385               </indexterm>
1386                 Now repeat this via NSS to validate that full identity resolution is
1387                 functional as required. Execute:
1388 <screen>
1389 &rootprompt; getent passwd
1391 LONDON+Administrator:x:10000:10000:Administrator:
1392              /home/LONDON/administrator:/bin/bash
1393 LONDON+Guest:x:10001:10001:Guest:
1394              /home/LONDON/guest:/bin/bash
1395 LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
1396              /home/LONDON/support_388945a0:/bin/bash
1397 LONDON+krbtgt:x:10003:10000:krbtgt:
1398              /home/LONDON/krbtgt:/bin/bash
1399 LONDON+jht:x:10004:10000:John H. Terpstra:
1400              /home/LONDON/jht:/bin/bash
1401 </screen>
1402                 Okay, ADS user accounts are being resolved. Now you try group resolution:
1403 <screen>
1404 &rootprompt; getent group
1406 LONDON+Domain Computers:x:10002:
1407 LONDON+Domain Controllers:x:10003:
1408 LONDON+Schema Admins:x:10004:LONDON+Administrator
1409 LONDON+Enterprise Admins:x:10005:LONDON+Administrator
1410 LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
1411 LONDON+Domain Users:x:10000:
1412 LONDON+Domain Guests:x:10001:
1413 LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
1414 LONDON+DnsUpdateProxy:x:10008:
1415 </screen>
1416                 This is very pleasing. Everything works as expected.
1417                 </para></step>
1419                 <step><para>
1420                 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>info</tertiary></indexterm>
1421                 <indexterm><primary>Active Directory</primary><secondary>server</secondary></indexterm>
1422                 <indexterm><primary>Kerberos</primary></indexterm>
1423                 You may now perform final verification that communications between Samba-3 winbind and
1424                 the Active Directory server is using Kerberos protocols. Execute the following:
1425 <screen>
1426 &rootprompt; net ads info
1427 LDAP server: 192.168.2.123
1428 LDAP server name: w2k3s
1429 Realm: LONDON.ABMAS.BIZ
1430 Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
1431 LDAP port: 389
1432 Server time: Sat, 03 Jan 2004 02:44:44 GMT
1433 KDC server: 192.168.2.123
1434 Server time offset: 2
1435 </screen>
1436                 It should be noted that Kerberos protocols are time-clock critical. You should
1437                 keep all server time clocks synchronized using the network time protocol (NTP).
1438                 In any case, the output we obtained confirms that all systems are operational.
1439                 </para></step>
1441                 <step><para>
1442                 <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm>
1443                 There is one more action you elect to take, just because you are paranoid and disbelieving,
1444                 so you execute the following command:
1445 <programlisting>
1446 &rootprompt; net ads status -UAdministrator%not24get
1447 objectClass: top
1448 objectClass: person
1449 objectClass: organizationalPerson
1450 objectClass: user
1451 objectClass: computer
1452 cn: fran
1453 distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
1454 instanceType: 4
1455 whenCreated: 20040103092006.0Z
1456 whenChanged: 20040103092006.0Z
1457 uSNCreated: 28713
1458 uSNChanged: 28717
1459 name: fran
1460 objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
1461 userAccountControl: 69632
1462 badPwdCount: 0
1463 codePage: 0
1464 countryCode: 0
1465 badPasswordTime: 0
1466 lastLogoff: 0
1467 lastLogon: 127175965783327936
1468 localPolicyFlags: 0
1469 pwdLastSet: 127175952062598496
1470 primaryGroupID: 515
1471 objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
1472 accountExpires: 9223372036854775807
1473 logonCount: 13
1474 sAMAccountName: fran$
1475 sAMAccountType: 805306369
1476 operatingSystem: Samba
1477 operatingSystemVersion: 3.0.20-SUSE
1478 dNSHostName: fran
1479 userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
1480 servicePrincipalName: CIFS/fran.london.abmas.biz
1481 servicePrincipalName: CIFS/fran
1482 servicePrincipalName: HOST/fran.london.abmas.biz
1483 servicePrincipalName: HOST/fran
1484 objectCategory: CN=Computer,CN=Schema,CN=Configuration,
1485                               DC=london,DC=abmas,DC=biz
1486 isCriticalSystemObject: FALSE
1487 -------------- Security Descriptor (revision: 1, type: 0x8c14)
1488 owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
1489 group SID: S-1-5-21-4052121579-2079768045-1474639452-513
1490 ------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
1491 ------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
1492                mask: 0x20, object flags: 0x3)
1493 access SID:  S-1-1-0
1494 access type: AUDIT OBJECT
1495 Permissions:
1496         [Write All Properties]
1497 ------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
1498                mask: 0x20, object flags: 0x3)
1499 access SID:  S-1-1-0
1500 access type: AUDIT OBJECT
1501 Permissions:
1502         [Write All Properties]
1503 ------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
1504 ------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
1505 access SID:  S-1-5-21-4052121579-2079768045-1474639452-512
1506 access type: ALLOWED
1507 Permissions: [Full Control]
1508 ------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
1509 access SID:  S-1-5-32-548
1511 ------- ACE (type: 0x05, flags: 0x12, size: 0x38, 
1512                 mask: 0x10, object flags: 0x3)
1513 access SID:  S-1-5-9
1514 access type: ALLOWED OBJECT
1515 Permissions:
1516         [Read All Properties]
1517 -------------- End Of Security Descriptor
1518 </programlisting>
1519                 And now you have conclusive proof that your Samba-3 ADS domain member server
1520                 called <constant>FRAN</constant> is able to communicate fully with the ADS
1521                 domain controllers.
1522                 </para></step>
1524         </procedure>
1527         <para>
1528         Your Samba-3 ADS domain member server is ready for use. During training sessions,
1529         you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename>
1530         files. Since curiosity just took hold of you, execute the following:
1531 <programlisting>
1532 &rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb
1534 key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
1535 data = "UID 10001\00"
1538 key = "UID 10005\00"
1539 data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
1542 key = "GID 10004\00"
1543 data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
1546 key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
1547 data = "UID 10003\00"
1551 &rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb
1553 key = "UL/LONDON"
1554 data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
1555    Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
1556    S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
1557    Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
1558    S-1-5-21-4052121579-2079768045-1474639452-514\10
1559    SUPPORT_388945a0\10SUPPORT_388945a0.
1560    S-1-5-21-4052121579-2079768045-1474639452-1001-
1561    S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
1562    krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
1563    S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
1564    John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
1565    S-1-5-21-4052121579-2079768045-1474639452-513"
1568 key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
1569 data = "\00\00\00\00bp\00\00\02\00\00\00.
1570    S-1-5-21-4052121579-2079768045-1474639452-1110\03
1571    jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
1572    Administrator\01\00\00\00"
1575 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
1576 data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
1579 key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
1580 data = "\00\00\00\00bp\00\00\01\00\00\00-
1581    S-1-5-21-4052121579-2079768045-1474639452-500\0D
1582    Administrator\01\00\00\00"
1585 key = "SEQNUM/LONDON\00"
1586 data = "xp\00\00C\92\F6?"
1589 key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
1590 data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
1591    S-1-5-21-4052121579-2079768045-1474639452-1110-
1592    S-1-5-21-4052121579-2079768045-1474639452-513"
1595 key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
1596 data = "\00\00\00\00bp\00\00-
1597    S-1-5-21-4052121579-2079768045-1474639452-502"
1600 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
1601 data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
1604 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
1605 data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
1608 key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
1609 data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
1610    S-1-5-21-4052121579-2079768045-1474639452-502-
1611    S-1-5-21-4052121579-2079768045-1474639452-513"
1613 ....
1614 </programlisting>
1615         Now all is revealed. Your curiosity, as well as that of your team, has been put at ease.
1616         May this server serve well all who happen upon it.
1617         </para>
1619 <example id="ch9-adssdm">
1620 <title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
1621 <smbconfblock>
1622 <smbconfcomment>Global parameters</smbconfcomment>
1623 <smbconfsection name="[global]"/>
1624 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1625 <smbconfoption name="workgroup">LONDON</smbconfoption>
1626 <smbconfoption name="realm">LONDON.ABMAS.BIZ</smbconfoption>
1627 <smbconfoption name="server string">Samba 3.0.20</smbconfoption>
1628 <smbconfoption name="security">ADS</smbconfoption>
1629 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1630 <smbconfoption name="log level">1</smbconfoption>
1631 <smbconfoption name="syslog">0</smbconfoption>
1632 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1633 <smbconfoption name="max log size">50</smbconfoption>
1634 <smbconfoption name="printcap name">CUPS</smbconfoption>
1635 <smbconfoption name="ldap ssl">no</smbconfoption>
1636 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1637 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1638 <smbconfoption name="template primary group">"Domain Users"</smbconfoption>
1639 <smbconfoption name="template shell">/bin/bash</smbconfoption>
1640 <smbconfoption name="winbind separator">+</smbconfoption>
1641 <smbconfoption name="printing">cups</smbconfoption>
1643 <smbconfsection name="[homes]"/>
1644 <smbconfoption name="comment">Home Directories</smbconfoption>
1645 <smbconfoption name="valid users">%S</smbconfoption>
1646 <smbconfoption name="read only">No</smbconfoption>
1647 <smbconfoption name="browseable">No</smbconfoption>
1649 <smbconfsection name="[printers]"/>
1650 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1651 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1652 <smbconfoption name="guest ok">Yes</smbconfoption>
1653 <smbconfoption name="printable">Yes</smbconfoption>
1654 <smbconfoption name="browseable">No</smbconfoption>
1656 <smbconfsection name="[print$]"/>
1657 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1658 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1659 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1660 <smbconfoption name="write list">root</smbconfoption>
1661 </smbconfblock>
1662 </example>
1664         <sect3>
1665         <title>IDMAP_RID with Winbind</title>
1667         <para>
1668         <indexterm><primary>idmap_rid</primary></indexterm>
1669         <indexterm><primary>SID</primary></indexterm>
1670         <indexterm><primary>RID</primary></indexterm>
1671         <indexterm><primary>IDMAP</primary></indexterm>
1672         The <command>idmap_rid</command> facility is a new tool that, unlike native winbind, creates a
1673         predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method
1674         of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data
1675         in a central place. The downside is that it can be used only within a single ADS domain and
1676         is not compatible with trusted domain implementations.
1677         </para>
1679         <para>
1680         <indexterm><primary>SID</primary></indexterm>
1681         <indexterm><primary>allow trusted domains</primary></indexterm>
1682         <indexterm><primary>idmap uid</primary></indexterm>
1683         <indexterm><primary>idmap gid</primary></indexterm>
1684         This alternate method of SID to UID/GID  mapping can be achieved with the idmap_rid
1685         plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the
1686         RID to a base value specified. This utility requires that the parameter
1687         <quote>allow trusted domains = No</quote> must be specified, as it is not compatible
1688         with multiple domain environments. The <parameter>idmap uid</parameter> and
1689         <parameter>idmap gid</parameter> ranges must be specified.
1690         </para>
1692         <para>
1693         <indexterm><primary>idmap_rid</primary></indexterm>
1694         <indexterm><primary>realm</primary></indexterm>
1695         The idmap_rid facility can be used both for NT4/Samba-style domains as well as with Active Directory.
1696         To use this with an NT4 domain, the <parameter>realm</parameter> is not used. Additionally the
1697         method used to join the domain uses the <constant>net rpc join</constant> process.
1698         </para>
1700         <para>
1701         An example &smb.conf; file for an ADS domain environment is shown in <link linkend="sbe-idmapridex"/>.
1702         </para>
1704 <example id="sbe-idmapridex">
1705 <title>Example &smb.conf; File Using <constant>idmap_rid</constant></title>
1706 <smbconfblock>
1707 <smbconfcomment>Global parameters</smbconfcomment>
1708 <smbconfsection name="[global]"/>
1709 <smbconfoption name="workgroup">KPAK</smbconfoption>
1710 <smbconfoption name="netbios name">BIGJOE</smbconfoption>
1711 <smbconfoption name="realm">CORP.KPAK.COM</smbconfoption>
1712 <smbconfoption name="server string">Office Server</smbconfoption>
1713 <smbconfoption name="security">ADS</smbconfoption>
1714 <smbconfoption name="allow trusted domains">No</smbconfoption>
1715 <smbconfoption name="idmap backend">idmap_rid:KPAK=500-100000000</smbconfoption>
1716 <smbconfoption name="idmap uid">500-100000000</smbconfoption>
1717 <smbconfoption name="idmap gid">500-100000000</smbconfoption>
1718 <smbconfoption name="template shell">/bin/bash</smbconfoption>
1719 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
1720 <smbconfoption name="winbind enum users">No</smbconfoption>
1721 <smbconfoption name="winbind enum groups">No</smbconfoption>
1722 <smbconfoption name="winbind nested groups">Yes</smbconfoption>
1723 </smbconfblock>
1724 </example>
1726         <para>
1727         <indexterm><primary>large domain</primary></indexterm>
1728         <indexterm><primary>Active Directory</primary></indexterm>
1729         <indexterm><primary>response</primary></indexterm>
1730         <indexterm><primary>getent</primary></indexterm>
1731         In a large domain with many users, it is imperative to disable enumeration of users and groups.
1732         For example, at a site that has 22,000 users in Active Directory the winbind-based user and
1733         group resolution is unavailable for nearly 12 minutes following first start-up of
1734         <command>winbind</command>. Disabling of such enumeration results in instantaneous response.
1735         The disabling of user and group enumeration means that it will not be possible to list users
1736         or groups using the <command>getent passwd</command> and <command>getent group</command>
1737         commands. It will be possible to perform the lookup for individual users, as shown in the procedure
1738         below.
1739         </para>
1741         <para>
1742         <indexterm><primary>NSS</primary></indexterm>
1743         <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
1744         The use of this tool requires configuration of NSS as per the native use of winbind. Edit the
1745         <filename>/etc/nsswitch.conf</filename> so it has the following parameters:
1746 <screen>
1748 passwd: files winbind
1749 shadow: files winbind
1750 group:  files winbind
1752 hosts:  files wins
1754 </screen>
1755         </para>
1757         <para>
1758         The following procedure can be used to utilize the idmap_rid facility:
1759         </para>
1761         <procedure>
1762                 <step><para>
1763                 Create or install and &smb.conf; file with the above configuration.
1764                 </para></step>
1766                 <step><para>
1767                 Edit the <filename>/etc/nsswitch.conf</filename> file as shown above.
1768                 </para></step>
1770                 <step><para>
1771                 Execute:
1772 <screen>
1773 &rootprompt; net ads join -UAdministrator%password
1774 Using short domain name -- KPAK
1775 Joined 'BIGJOE' to realm 'CORP.KPAK.COM'
1776 </screen>
1777                 </para>
1779                 <para>
1780                 <indexterm><primary>failed join</primary></indexterm>
1781                 An invalid or failed join can be detected by executing:
1782 <screen>
1783 &rootprompt; net ads testjoin
1784 BIGJOE$@'s password:
1785 [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
1786   ads_connect: No results returned
1787 Join to domain is not valid
1788 </screen>
1789                 The specific error message may differ from the above because it depends on the type of failure that
1790                 may have occurred. Increase the <parameter>log level</parameter> to 10, repeat the above test,
1791                 and then examine the log files produced to identify the nature of the failure.
1792                 </para></step>
1794                 <step><para>
1795                 Start the <command>nmbd</command>, <command>winbind,</command> and <command>smbd</command> daemons in the order shown.
1796                 </para></step>
1798                 <step><para>
1799                 Validate the operation of this configuration by executing:
1800                 <indexterm><primary></primary></indexterm>
1801 <screen>
1802 &rootprompt; getent passwd administrator
1803 administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash
1804 </screen>
1805                 </para></step>
1806         </procedure>
1808         </sect3>
1810         <sect3>
1811         <title>IDMAP Storage in LDAP using Winbind</title>
1813         <para>
1814         <indexterm><primary>ADAM</primary></indexterm>
1815         <indexterm><primary>ADS</primary></indexterm>
1816         The storage of IDMAP information in LDAP can be used with both NT4/Samba-3-style domains as well as
1817         with ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any standards-compliant
1818         LDAP server can be used. It is therefore possible to deploy this IDMAP configuration using
1819         the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM, and so on.
1820         </para>
1822         <para>
1823         The example in <link linkend="sbeunxa"/> is for an ADS-style domain.
1824         </para>
1826 <example id="sbeunxa">
1827 <title>Typical ADS Style Domain &smb.conf; File</title>
1828 <smbconfblock>
1829 <smbconfcomment>Global parameters</smbconfcomment>
1830 <smbconfsection name="[global]"/>
1831 <smbconfoption name="workgroup">SNOWSHOW</smbconfoption>
1832 <smbconfoption name="netbios name">GOODELF</smbconfoption>
1833 <smbconfoption name="realm">SNOWSHOW.COM</smbconfoption>
1834 <smbconfoption name="server string">Samba Server</smbconfoption>
1835 <smbconfoption name="security">ADS</smbconfoption>
1836 <smbconfoption name="log level">1 ads:10 auth:10 sam:10 rpc:10</smbconfoption>
1837 <smbconfoption name="ldap admin dn">cn=Manager,dc=SNOWSHOW,dc=COM</smbconfoption>
1838 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
1839 <smbconfoption name="ldap suffix">dc=SNOWSHOW,dc=COM</smbconfoption>
1840 <smbconfoption name="idmap backend">ldap:ldap://ldap.snowshow.com</smbconfoption>
1841 <smbconfoption name="idmap uid">150000-550000</smbconfoption>
1842 <smbconfoption name="idmap gid">150000-550000</smbconfoption>
1843 <smbconfoption name="template shell">/bin/bash</smbconfoption>
1844 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
1845 </smbconfblock>
1846 </example>
1848         <para>
1849         <indexterm><primary>realm</primary></indexterm>
1850         In the case of an NT4 or Samba-3-style domain the <parameter>realm</parameter> is not used, and the
1851         command used to join the domain is <command>net rpc join</command>. The above example also demonstrates
1852         advanced error reporting techniques that are documented in the chapter called "Reporting Bugs" in
1853         <quote>The Official Samba-3 HOWTO and Reference Guide, Second Edition</quote> (TOSHARG2).
1854         </para>
1856         <para>
1857         <indexterm><primary>MIT kerberos</primary></indexterm>
1858         <indexterm><primary>Heimdal kerberos</primary></indexterm>
1859         <indexterm><primary>/etc/krb5.conf</primary></indexterm>
1860         Where MIT kerberos is installed (version 1.3.4 or later), edit the <filename>/etc/krb5.conf</filename>
1861         file so it has the following contents:
1862 <screen>
1863 [logging]
1864  default = FILE:/var/log/krb5libs.log
1865  kdc = FILE:/var/log/krb5kdc.log
1866  admin_server = FILE:/var/log/kadmind.log
1868 [libdefaults]
1869  default_realm = SNOWSHOW.COM
1870  dns_lookup_realm = false
1871  dns_lookup_kdc = true
1873 [appdefaults]
1874  pam = {
1875    debug = false
1876    ticket_lifetime = 36000
1877    renew_lifetime = 36000
1878    forwardable = true
1879    krb4_convert = false
1881 </screen>
1882         </para>
1884         <para>
1885         Where Heimdal kerberos is installed, edit the <filename>/etc/krb5.conf</filename>
1886         file so it is either empty (i.e., no contents) or it has the following contents:
1887 <screen>
1888 [libdefaults]
1889         default_realm = SNOWSHOW.COM
1890         clockskew = 300
1892 [realms]
1893         SNOWSHOW.COM = {
1894                 kdc = ADSDC.SHOWSHOW.COM
1895         }
1897 [domain_realm]
1898         .snowshow.com = SNOWSHOW.COM
1899 </screen>
1900         </para>
1902         <note><para>
1903         Samba cannot use the Heimdal libraries if there is no <filename>/etc/krb5.conf</filename> file.
1904         So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no
1905         need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically.
1906         </para></note>
1907         <para>
1908         Edit the NSS control file <filename>/etc/nsswitch.conf</filename> so it has the following entries:
1909 <screen>
1911 passwd: files ldap
1912 shadow: files ldap
1913 group:  files ldap
1915 hosts:  files wins
1917 </screen>
1918         </para>
1920         <para>
1921         <indexterm><primary>PADL</primary></indexterm>
1922         <indexterm><primary>/etc/ldap.conf</primary></indexterm>
1923         You will need the <ulink url="http://www.padl.com">PADL</ulink> <command>nss_ldap</command>
1924         tool set for this solution. Configure the <filename>/etc/ldap.conf</filename> file so it has
1925         the information needed. The following is an example of a working file:
1926 <screen>
1927 host    192.168.2.1
1928 base    dc=snowshow,dc=com
1929 binddn  cn=Manager,dc=snowshow,dc=com
1930 bindpw  not24get
1932 pam_password exop
1934 nss_base_passwd ou=People,dc=snowshow,dc=com?one
1935 nss_base_shadow ou=People,dc=snowshow,dc=com?one
1936 nss_base_group  ou=Groups,dc=snowshow,dc=com?one
1937 ssl     no
1938 </screen>
1939         </para>
1941         <para>
1942         The following procedure may be followed to affect a working configuration:
1943         </para>
1944         <procedure>
1945                 <step><para>
1946                 Configure the &smb.conf; file as shown above.
1947                 </para></step>
1949                 <step><para>
1950                 Create the <filename>/etc/krb5.conf</filename> file following the indications above.
1951                 </para></step>
1953                 <step><para>
1954                 Configure the <filename>/etc/nsswitch.conf</filename> file as shown above.
1955                 </para></step>
1957                 <step><para>
1958                 Download, build, and install the PADL nss_ldap tool set. Configure the
1959                 <filename>/etc/ldap.conf</filename> file as shown above.
1960                 </para></step>
1962                 <step><para>
1963                 Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP
1964                 as shown in the following LDIF file:
1965 <screen>
1966 dn: dc=snowshow,dc=com
1967 objectClass: dcObject
1968 objectClass: organization
1969 dc: snowshow
1970 o: The Greatest Snow Show in Singapore.
1971 description: Posix and Samba LDAP Identity Database
1973 dn: cn=Manager,dc=snowshow,dc=com
1974 objectClass: organizationalRole
1975 cn: Manager
1976 description: Directory Manager
1978 dn: ou=Idmap,dc=snowshow,dc=com
1979 objectClass: organizationalUnit
1980 ou: idmap
1981 </screen>
1982                 </para></step>
1984                 <step><para>
1985                 Execute the command to join the Samba domain member server to the ADS domain as shown here:
1986 <screen>
1987 &rootprompt; net ads testjoin
1988 Using short domain name -- SNOWSHOW
1989 Joined 'GOODELF' to realm 'SNOWSHOW.COM'
1990 </screen>
1991                 </para></step>
1993                 <step><para>
1994                 Store the LDAP server access password in the Samba <filename>secrets.tdb</filename> file as follows:
1995 <screen>
1996 &rootprompt; smbpasswd -w not24get
1997 </screen>
1998                 </para></step>
2000                 <step><para>
2001                 Start the <command>nmbd</command>, <command>winbind</command>, and <command>smbd</command> daemons in the order shown.
2002                 </para></step>
2003         </procedure>
2006         <para>
2007         <indexterm><primary>diagnostic</primary></indexterm>
2008         Follow the diagnostic procedures shown earlier in this chapter to identify success or failure of the join.
2009         In many cases a failure is indicated by a silent return to the command prompt with no indication of the
2010         reason for failure.
2011         </para>
2013         </sect3>
2015         <sect3>
2016         <title>IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension</title>
2018         <para>
2019         <indexterm><primary>rfc2307bis</primary></indexterm>
2020         <indexterm><primary>schema</primary></indexterm>
2021         The use of this method is messy. The information provided in this section is for guidance only
2022         and is very definitely not complete. This method does work; it is used in a number of large sites
2023         and has an acceptable level of performance.
2024         </para>
2026         <para>
2027         An example &smb.conf; file is shown in <link linkend="sbewinbindex"/>.
2028         </para>
2030 <example id="sbewinbindex">
2031 <title>ADS Membership Using RFC2307bis Identity Resolution &smb.conf; File</title>
2032 <smbconfblock>
2033 <smbconfcomment>Global parameters</smbconfcomment>
2034 <smbconfsection name="[global]"/>
2035 <smbconfoption name="workgroup">BUBBAH</smbconfoption>
2036 <smbconfoption name="netbios name">MADMAX</smbconfoption>
2037 <smbconfoption name="realm">BUBBAH.COM</smbconfoption>
2038 <smbconfoption name="server string">Samba Server</smbconfoption>
2039 <smbconfoption name="security">ADS</smbconfoption>
2040 <smbconfoption name="idmap uid">150000-550000</smbconfoption>
2041 <smbconfoption name="idmap gid">150000-550000</smbconfoption>
2042 <smbconfoption name="template shell">/bin/bash</smbconfoption>
2043 <smbconfoption name="winbind use default domain">Yes</smbconfoption>
2044 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
2045 <smbconfoption name="winbind nested groups">Yes</smbconfoption>
2046 </smbconfblock>
2047 </example>
2049         <para>
2050         <indexterm><primary>nss_ldap</primary></indexterm>
2051         The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary
2052         to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the
2053         following:
2054 <screen>
2055 ./configure --enable-rfc2307bis --enable-schema-mapping
2056 make install
2057 </screen>
2058         </para>
2060         <para>
2061         <indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
2062         The following <filename>/etc/nsswitch.conf</filename> file contents are required:
2063 <screen>
2065 passwd: files ldap
2066 shadow: files ldap
2067 group:  files ldap
2069 hosts:  files wins
2071 </screen>
2072         </para>
2074         <para>
2075         <indexterm><primary>/etc/ldap.conf</primary></indexterm>
2076         <indexterm><primary>nss_ldap</primary></indexterm>
2077         The <filename>/etc/ldap.conf</filename> file must be configured also. Refer to the PADL documentation
2078         and source code for nss_ldap instructions.
2079         </para>
2081         <para>
2082         The next step involves preparation on the ADS schema. This is briefly discussed in the remaining
2083         part of this chapter.
2084         </para>
2086                 <sect4>
2087                 <title>IDMAP, Active Directory, and MS Services for UNIX 3.5</title>
2089                 <para>
2090                 <indexterm><primary>SFU</primary></indexterm>
2091                 The Microsoft Windows Service for UNIX version 3.5 is available for free
2092                 <ulink url="http://www.microsoft.com/windows/sfu/">download</ulink>
2093                 from the Microsoft Web site. You will need to download this tool and install it following
2094                 Microsoft instructions.
2095                 </para>
2097                 </sect4>
2099                 <sect4>
2100                 <title>IDMAP, Active Directory, and AD4UNIX</title>
2102                 <para>
2103                 Instructions for obtaining and installing the AD4UNIX tool set can be found from the
2104                 <ulink url="http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/An_Alternative_Approach">
2105                 Geekcomix</ulink> Web site.
2106                 </para>
2108                 </sect4>
2110         </sect3>
2112         </sect2>
2114         <sect2>
2115         <title>UNIX/Linux Client Domain Member</title>
2117         <para><indexterm>
2118             <primary>user credentials</primary>
2119           </indexterm>
2120         So far this chapter has been mainly concerned with the provision of file and print
2121         services for domain member servers. However, an increasing number of UNIX/Linux
2122         workstations are being installed that do not act as file or print servers to anyone
2123         other than a single desktop user. The key demand for desktop systems is to be able
2124         to log onto any UNIX/Linux or Windows desktop using the same network user credentials.
2125         </para>
2127         <para><indexterm>
2128             <primary>Single Sign-On</primary>
2129             <see>SSO</see>
2130           </indexterm>
2131         The ability to use a common set of user credential across a variety of network systems
2132         is generally regarded as a single sign-on (SSO) solution. SSO systems are sold by a
2133         large number of vendors and include a range of technologies such as:
2134         </para>
2136         <itemizedlist>
2137                 <listitem><para>
2138                 Proxy sign-on
2139                 </para></listitem>
2141                 <listitem><para>
2142                 Federated directory provisioning
2143                 </para></listitem>
2145                 <listitem><para>
2146                 Metadirectory server solutions
2147                 </para></listitem>
2149                 <listitem><para>
2150                 Replacement authentication systems
2151                 </para></listitem>
2152         </itemizedlist>
2154         <para><indexterm>
2155             <primary>Identity management</primary>
2156           </indexterm>
2157         There are really four solutions that provide integrated authentication and
2158         user identity management facilities:
2159         </para>
2161         <itemizedlist>
2162                 <listitem><para>
2163                 Samba winbind (free). Samba-3.0.20 introduced a complete replacement for Winbind that now
2164                 provides a greater level of scalability in large ADS environments.
2165                 </para></listitem>
2167                 <listitem><para>
2168                 <ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP tools (free).
2169                 </para></listitem>
2171                 <listitem><para>
2172                 <ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (commercial).
2173                 </para></listitem>
2175                 <listitem><para>
2176                 <ulink url="http://www.centrify.com">Centrify</ulink> DirectControl (commercial). 
2177                 Centrify's commercial product allows UNIX and Linux systems to use Active Directory
2178                 security, directory and policy services.  Enhancements include a centralized ID mapping that 
2179                 allows Samba, DirectControl and Active Directory to seamlessly work together.
2180                 </para></listitem>
2181         </itemizedlist>
2183         <para>
2184         The following guidelines are pertinent to the deployment of winbind-based authentication
2185         and identity resolution with the express purpose of allowing users to log on to UNIX/Linux desktops
2186         using Windows network domain user credentials (username and password).
2187         </para>
2189         <para>
2190         You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed
2191         systems logons (SSO), providing user and group accounts are stored in an LDAP directory. This
2192         provides logon services for UNIX/Linux users, while Windows users obtain their sign-on
2193         support via Samba-3.
2194         </para>
2196         <para>
2197         <indexterm><primary>Windows Services for UNIX</primary><see>SUS</see></indexterm>
2198         On the other hand, if the authentication and identity resolution backend must be provided by
2199         a Windows NT4-style domain or from an Active Directory Domain that does not have the Microsoft
2200         Windows Services for UNIX installed, winbind is your best friend. Specific guidance for these
2201         situations now follows.
2202         </para>
2204         <para>
2205         <indexterm><primary>PAM</primary></indexterm>
2206         <indexterm><primary>Identity resolution</primary></indexterm>
2207         <indexterm><primary>NSS</primary></indexterm>
2208         To permit users to log on to a Linux system using Windows network credentials, you need to
2209         configure identity resolution (NSS) and PAM. This means that the basic steps include those
2210         outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
2211         usually do not need to provide file and print services to a group of users, the configuration
2212         of shares and printers is generally less important. Often this allows the share specifications
2213         to be entirely removed from the &smb.conf; file. That is obviously an administrator decision.
2214         </para>
2216                 <sect3>
2217                 <title>NT4 Domain Member</title>
2219                 <para>
2220                 The following steps provide a Linux system that users can log onto using
2221                 Windows NT4 (or Samba-3) domain network credentials:
2222                 </para>
2224                 <procedure>
2225                         <step><para>
2226                         Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that
2227                         all validation tests function as shown.
2228                         </para></step>
2230                         <step><para>
2231                         Identify what services users must log on to. On Red Hat Linux, if it is
2232                         intended that the user shall be given access to all services, it may be
2233                         most expeditious to simply configure the file 
2234                         <filename>/etc/pam.d/system-auth</filename>.
2235                         </para></step>
2237                         <step><para>
2238                         Carefully make a backup copy of all PAM configuration files before you
2239                         begin making changes. If you break the PAM configuration, please note
2240                         that you may need to use an emergency boot process to recover your Linux
2241                         system. It is possible to break the ability to log into the system if
2242                         PAM files are incorrectly configured. The entire directory 
2243                         <filename>/etc/pam.d</filename> should be backed up to a safe location.
2244                         </para></step>
2246                         <step><para>
2247                         If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
2248                         so it matches <link linkend="ch9-pamwnbdlogin"/>.
2249                         </para></step>
2251                         <step><para>
2252                         To provide the ability to log onto the graphical desktop interface, you must edit
2253                         the files <filename>gdm</filename> and <filename>xdm</filename> in the 
2254                         <filename>/etc/pam.d</filename> directory.
2255                         </para></step>
2257                         <step><para>
2258                         Edit only one file at a time. Carefully validate its operation before attempting
2259                         to reboot the machine.
2260                         </para></step>
2261                 </procedure>
2263                 </sect3>
2265                 <sect3>
2266                 <title>ADS Domain Member</title>
2268                 <para>
2269                 This procedure should be followed to permit a Linux network client (workstation/desktop)
2270                 to permit users to log on using Microsoft Active Directory-based user credentials.
2271                 </para>
2273                 <procedure>
2274                         <step><para>
2275                         Follow the steps outlined in <link linkend="adssdm"/> and ensure that
2276                         all validation tests function as shown.
2277                         </para></step>
2279                         <step><para>
2280                         Identify what services users must log on to. On Red Hat Linux, if it is
2281                         intended that the user shall be given access to all services, it may be
2282                         most expeditious to simply configure the file 
2283                         <filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>.
2284                         </para></step>
2286                         <step><para>
2287                         Carefully make a backup copy of all PAM configuration files before you
2288                         begin making changes. If you break the PAM configuration, please note
2289                         that you may need to use an emergency boot process to recover your Linux
2290                         system. It is possible to break the ability to log into the system if
2291                         PAM files are incorrectly configured. The entire directory 
2292                         <filename>/etc/pam.d</filename> should be backed up to a safe location.
2293                         </para></step>
2295                         <step><para>
2296                         If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
2297                         so it matches <link linkend="ch9-pamwnbdlogin"/>.
2298                         </para></step>
2300                         <step><para>
2301                         To provide the ability to log onto the graphical desktop interface, you must edit
2302                         the files <filename>gdm</filename> and <filename>xdm</filename> in the 
2303                         <filename>/etc/pam.d</filename> directory.
2304                         </para></step>
2306                         <step><para>
2307                         Edit only one file at a time. Carefully validate its operation before attempting
2308                         to reboot the machine.
2309                         </para></step>
2310                 </procedure>
2312                 </sect3>
2314 <example id="ch9-pamwnbdlogin">
2315 <title>SUSE: PAM <filename>login</filename> Module Using Winbind</title>
2316 <screen>
2317 # /etc/pam.d/login
2319 #%PAM-1.0
2320 auth sufficient pam_unix2.so    nullok
2321 auth sufficient pam_winbind.so use_first_pass use_authtok
2322 auth required   pam_securetty.so
2323 auth required   pam_nologin.so
2324 auth required   pam_env.so
2325 auth required   pam_mail.so
2326 account sufficient      pam_unix2.so
2327 account sufficient      pam_winbind.so user_first_pass use_authtok
2328 password required       pam_pwcheck.so  nullok
2329 password sufficient     pam_unix2.so    nullok use_first_pass use_authtok
2330 password sufficient     pam_winbind.so  use_first_pass use_authtok
2331 session sufficient      pam_unix2.so    none
2332 session sufficient      pam_winbind.so  use_first_pass use_authtok
2333 session required        pam_limits.so
2334 </screen>
2335 </example>
2337 <example id="ch9-pamwbndxdm">
2338 <title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title>
2339 <screen>
2340 # /etc/pam.d/gdm (/etc/pam.d/xdm)
2342 #%PAM-1.0
2343 auth     sufficient     pam_unix2.so     nullok
2344 auth     sufficient     pam_winbind.so   use_first_pass use_authtok
2345 account  sufficient     pam_unix2.so
2346 account  sufficient     pam_winbind.so   use_first_pass use_authtok
2347 password sufficient     pam_unix2.so
2348 password sufficient     pam_winbind.so   use_first_pass use_authtok
2349 session  sufficient     pam_unix2.so
2350 session  sufficient     pam_winbind.so   use_first_pass use_authtok
2351 session  required       pam_dev perm.so
2352 session  required       pam_resmgr.so
2353 </screen>
2354 </example>
2356 <example id="ch9-rhsysauth">
2357 <title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title>
2358 <screen>
2359 #%PAM-1.0
2360 auth        required      /lib/security/$ISA/pam_env.so
2361 auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
2362 auth        sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
2363 auth        required      /lib/security/$ISA/pam_deny.so
2365 account     required      /lib/security/$ISA/pam_unix.so
2366 account     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
2368 password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
2369 # Note: The above line is complete. There is nothing following the '='
2370 password    sufficient    /lib/security/$ISA/pam_unix.so \
2371                                              nullok use_authtok md5 shadow
2372 password    sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
2373 password    required      /lib/security/$ISA/pam_deny.so
2375 session     required      /lib/security/$ISA/pam_limits.so
2376 session     sufficient    /lib/security/$ISA/pam_unix.so
2377 session     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
2378 </screen>
2379 </example>
2381         </sect2>
2383         <sect2>
2384                 <title>Key Points Learned</title>
2386                 <para>
2387                 The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
2388                 learned how to integrate such servers so that the UID/GID mappings they use can be consistent
2389                 across all domain member servers. You also discovered how to implement the ability to use Samba
2390                 or Windows domain account credentials to log on to a UNIX/Linux client.
2391                 </para>
2393                 <para>
2394                 The following are key points made in this chapter:
2395                 </para>
2397                 <itemizedlist>
2398                         <listitem><para>
2399                         Domain controllers are always authoritative for the domain.
2400                         </para></listitem>
2402                         <listitem><para>
2403                         Domain members may have local accounts and must be able to resolve the identity of 
2404                         domain user accounts. Domain user account identity must map to a local UID/GID. That 
2405                         local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data 
2406                         across all domain member machines.
2407                         </para></listitem>
2409                         <listitem><para>
2410                         Resolution of user and group identities on domain member machines may be implemented 
2411                         using direct LDAP services or using winbind.
2412                         </para></listitem>
2414                         <listitem><para>
2415                         On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for identity management 
2416                         and PAM is responsible for authentication of logon credentials (username and password).
2417                         </para></listitem>
2418                 </itemizedlist>
2420         </sect2>
2422 </sect1>
2424 <sect1>
2425         <title>Questions and Answers</title>
2427         <para>
2428         The following questions were obtained from the mailing list and also from private discussions
2429         with Windows network administrators.
2430         </para>
2432         <qandaset defaultlabel="chap09qa" type="number">
2433         <qandaentry>
2434         <question>
2436                 <para>
2437                 We use NIS for all UNIX accounts. Why do we need winbind?
2438                 </para>
2440         </question>
2441         <answer>
2443             <para>
2444                 <indexterm><primary>NIS</primary></indexterm>
2445                 <indexterm><primary>encrypted passwords</primary></indexterm>
2446                 <indexterm><primary>smbpasswd</primary></indexterm>
2447                 <indexterm><primary>tdbsam</primary></indexterm>
2448                 <indexterm><primary>passdb backend</primary></indexterm>
2449                 <indexterm><primary>Winbind</primary></indexterm>
2450                 You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted
2451                 passwords that need to be stored in one of the acceptable passdb backends.
2452                 Your choice of backend is limited to <parameter>smbpasswd</parameter> or
2453                 <parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of
2454                 SIDs from trusted domains to local UID/GID values.
2455                 </para>
2457             <para>
2458                 <indexterm><primary>winbind trusted domains only</primary></indexterm>
2459                 <indexterm><primary>getpwnam()</primary></indexterm>
2460                 On a domain member server, you effectively map Windows domain users to local users
2461                 that are in your NIS database by specifying the <parameter>winbind trusted domains
2462                 only</parameter>. This causes user and group account lookups to be routed via
2463                 the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client,
2464                 this pushes the resolution of users and groups out through NIS.
2465                 </para>
2467                 <para>
2468                 As a general rule, it is always a good idea to run winbind on all Samba servers.
2469                 </para>
2471         </answer>
2472         </qandaentry>
2474         <qandaentry>
2475         <question>
2477                 <para>
2478                 Our IT management people do not like LDAP but are looking at Microsoft Active Directory. 
2479               Which is better?<indexterm>
2480                 <primary>Active Directory</primary>
2481               </indexterm>
2482                 </para>
2484         </question>
2485         <answer>
2487             <para><indexterm>
2488                 <primary>LDAP</primary>
2489                 <secondary>server</secondary>
2490               </indexterm><indexterm>
2491                 <primary>Kerberos</primary>
2492               </indexterm><indexterm>
2493                 <primary>schema</primary>
2494               </indexterm>
2495                 Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
2496                 infrastructure. Most IT managers who object to LDAP do so because
2497                 an LDAP server is most often supplied as a raw tool that needs to be configured and
2498                 for which the administrator must create the schema, create the administration tools, and
2499                 devise the backup and recovery facilities in a site-dependent manner. LDAP servers
2500                 in general are seen as a high-energy, high-risk facility.
2501                 </para>
2503             <para><indexterm>
2504                 <primary>management</primary>
2505               </indexterm>
2506                 Microsoft Active Directory by comparison is easy to install and configure and
2507                 is supplied with all tools necessary to implement and manage the directory. For sites
2508                 that lack a lot of technical competence, Active Directory is a good choice. For sites
2509                 that have the technical competence to handle Active Directory well, LDAP is a good
2510                 alternative. The real issue is, What type of solution does
2511                 the site want? If management wants a choice to use an alternative, they may want to
2512                 consider the options. On the other hand, if management just wants a solution that works,
2513                 Microsoft Active Directory is a good solution.
2514                 </para>
2516         </answer>
2517         </qandaentry>
2519         <qandaentry>
2520         <question>
2522                 <para>
2523                 We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible 
2524                 to use NIS in place of LDAP?
2525                 </para>
2527         </question>
2528         <answer>
2530             <para><indexterm>
2531                 <primary>NIS</primary>
2532               </indexterm><indexterm>
2533                 <primary>LDAP</primary>
2534               </indexterm><indexterm>
2535                 <primary>encrypted passwords</primary>
2536               </indexterm><indexterm>
2537                 <primary>synchronized</primary>
2538               </indexterm><indexterm>
2539                 <primary>secure account password</primary>
2540               </indexterm><indexterm>
2541                 <primary>PDC</primary>
2542               </indexterm><indexterm>
2543                 <primary>BDC</primary>
2544               </indexterm>
2545                 Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping
2546                 the Windows (SMB) encrypted passwords database correctly synchronized across the entire
2547                 network. Workstations (Windows client machines) periodically change their domain
2548                 membership secure account password. How can you keep changes that are on remote BDCs
2549                 synchronized on the PDC?
2550                 </para>
2552             <para><indexterm>
2553                 <primary>centralized storage</primary>
2554               </indexterm><indexterm>
2555                 <primary>management</primary>
2556               </indexterm><indexterm>
2557                 <primary>network Identities</primary>
2558               </indexterm>
2559                 LDAP is a more elegant solution because it permits centralized storage and management
2560                 of all network identities (user, group, and machine accounts) together with all information
2561                 Samba needs to provide to network clients and their users.
2562                 </para>
2564         </answer>
2565         </qandaentry>
2567         <qandaentry>
2568         <question>
2570                 <para>
2571                 Are you suggesting that users should not log on to a domain member server? If so, why?
2572                 </para>
2574         </question>
2575         <answer>
2577             <para><indexterm>
2578                 <primary>security</primary>
2579               </indexterm><indexterm>
2580                 <primary>data</primary>
2581                 <secondary>integrity</secondary>
2582               </indexterm><indexterm>
2583                 <primary>mapped drives</primary>
2584               </indexterm>
2585                 Many UNIX administrators mock the model that the personal computer industry has adopted
2586                 as normative since the early days of Novell NetWare. The old
2587                 perception of the necessity to keep users off file and print servers was a result of
2588                 fears concerning the security and integrity of data. It was a simple and generally
2589                 effective measure to keep users away from servers, except through mapped drives.
2590                 </para>
2592             <para><indexterm>
2593                 <primary>user logins</primary>
2594               </indexterm><indexterm>
2595                 <primary>risk</primary>
2596               </indexterm><indexterm>
2597                 <primary>user errors</primary>
2598               </indexterm><indexterm>
2599                 <primary>strategy</primary>
2600               </indexterm><indexterm>
2601                 <primary>policy</primary>
2602               </indexterm>
2603                 UNIX administrators are fully correct in asserting that UNIX servers and workstations
2604                 are identical in terms of the software that is installed. They correctly assert that
2605                 in a well-secured environment it is safe to store files on a system that has hundreds
2606                 of users. But all network administrators must factor into the decision to allow or
2607                 reject general user logins to a UNIX system that is principally a file and print
2608                 server the risk to operations through simple user errors.
2609                 Only then can one begin to appraise the best strategy and adopt a site-specific
2610                 policy that best protects the needs of users and of the organization alike.
2611                 </para>
2613             <para><indexterm>
2614                 <primary>system level logins</primary>
2615               </indexterm>
2616                 From experience, it is my recommendation to keep general system-level logins to a
2617                 practical minimum and to eliminate them if possible. This should not be taken as a
2618                 hard rule, though. The better question is, what works best for the site?
2619                 </para>
2621         </answer>
2622         </qandaentry>
2624         <qandaentry>
2625         <question>
2627             <para><indexterm>
2628                 <primary>trusted domains</primary>
2629               </indexterm><indexterm>
2630                 <primary>domain</primary>
2631                 <secondary>trusted</secondary>
2632               </indexterm><indexterm>
2633                 <primary>winbind trusted domains only</primary>
2634               </indexterm><indexterm>
2635                 <primary>domain members</primary>
2636               </indexterm>
2637                 We want to ensure that only users from our own domain plus from trusted domains can use our
2638                 Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind
2639                 trusted domains only</parameter> parameter. We now find that users from trusted domains 
2640                 cannot access our servers, and users from Windows clients that are not domain members
2641                 can also access our servers. Is this a Samba bug?
2642                 </para>
2644         </question>
2645         <answer>
2647             <para><indexterm>
2648                 <primary>distributed</primary>
2649               </indexterm><indexterm>
2650                 <primary>NIS</primary>
2651               </indexterm><indexterm>
2652                 <primary>rsync</primary>
2653               </indexterm><indexterm>
2654                 <primary>LDAP</primary>
2655               </indexterm><indexterm>
2656                 <primary>winbindd</primary>
2657               </indexterm><indexterm>
2658                 <primary>/etc/passwd</primary>
2659               </indexterm>
2660                 The manual page for this <parameter>winbind trusted domains only</parameter> parameter says,
2661                 <quote>This parameter is designed to allow Samba servers that are members of a Samba-controlled 
2662                 domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users 
2663                 in the hosts primary domain. Therefore,  the user <constant>SAMBA\user1</constant> would be 
2664                 mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead 
2665                 of allocating a new UID for him or her.</quote> This clearly suggests that you are trying
2666                 to use this parameter inappropriately.
2667                 </para>
2669             <para><indexterm>
2670                 <primary>valid users</primary>
2671               </indexterm>
2672                 A far better solution is to use the <parameter>valid users</parameter> by specifying
2673                 precisely the domain users and groups that should be permitted access to the shares. You could, 
2674                 for example, set the following parameters:
2675 <screen>
2676 [demoshare]
2677         path = /export/demodata
2678         valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
2679 </screen>
2680                 </para>
2683         </answer>
2684         </qandaentry>
2686         <qandaentry>
2687         <question>
2689                 <para>
2690                 What are the benefits of using LDAP for my domain member servers?
2691                 </para>
2693         </question>
2694         <answer>
2696             <para><indexterm>
2697                 <primary>LDAP</primary>
2698               </indexterm><indexterm>
2699                 <primary>benefit</primary>
2700               </indexterm><indexterm>
2701                 <primary>UID</primary>
2702               </indexterm><indexterm>
2703                 <primary>GID</primary>
2704               </indexterm><indexterm>
2705                 <primary>Domain Controllers</primary>
2706               </indexterm><indexterm>
2707                 <primary>Domain Member servers</primary>
2708               </indexterm><indexterm>
2709                 <primary>copy</primary>
2710               </indexterm><indexterm>
2711                 <primary>replicate</primary>
2712               </indexterm><indexterm>
2713                 <primary>identity</primary>
2714               </indexterm>
2715                 The key benefit of using LDAP is that the UID of all users and the GID of all groups
2716                 are globally consistent on domain controllers as well as on domain member servers.
2717                 This means that it is possible to copy/replicate files across servers without
2718                 loss of identity.
2719                 </para>
2721             <para><indexterm>
2722                 <primary>Identity resolution</primary>
2723               </indexterm><indexterm>
2724                 <primary>winbind</primary>
2725               </indexterm><indexterm>
2726                 <primary>IDMAP backend</primary>
2727               </indexterm><indexterm>
2728                 <primary>LDAP</primary>
2729               </indexterm><indexterm>
2730                 <primary>Domain Controllers</primary>
2731               </indexterm><indexterm>
2732                 <primary>Domain Member</primary>
2733                 <secondary>servers</secondary>
2734               </indexterm><indexterm>
2735                 <primary>Posix</primary>
2736               </indexterm><indexterm>
2737                 <primary>account information</primary>
2738               </indexterm>
2739                 When use is made of account identity resolution via winbind, even when an IDMAP backend
2740                 is stored in LDAP, the UID/GID on domain member servers is consistent, but differs
2741                 from the ID that the user/group has on domain controllers. The winbind allocated UID/GID
2742                 that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter>
2743                 idmap uid/gid</parameter> in the &smb.conf; file. On domain controllers, the UID/GID is
2744                 that of the POSIX value assigned in the LDAP directory as part of the POSIX account information.
2745                 </para>
2747         </answer>
2748         </qandaentry>
2750         <qandaentry>
2751         <question>
2753                 <para>
2754                 Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
2755                 my DNS configuration?
2756                 </para>
2758         </question>
2759         <answer>
2761             <para><indexterm>
2762                 <primary>DNS</primary>
2763                 <secondary>configuration</secondary>
2764               </indexterm><indexterm>
2765                 <primary>DNS</primary>
2766                 <secondary>lookup</secondary>
2767               </indexterm><indexterm>
2768                 <primary>hosts</primary>
2769               </indexterm><indexterm>
2770                 <primary>/etc/nsswitch.conf</primary>
2771               </indexterm><indexterm>
2772                 <primary>NSS</primary>
2773               </indexterm><indexterm>
2774                 <primary>/etc/hosts</primary>
2775               </indexterm><indexterm>
2776                 <primary>WINS</primary>
2777                 <secondary>lookup</secondary>
2778               </indexterm>
2779                 Samba depends on correctly functioning resolution of hostnames to their IP address. Samba
2780                 makes no direct DNS lookup calls, but rather redirects all name-to-address calls via the
2781                 <command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant>
2782                 entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying
2783                 resolution process is implemented. If the <constant>hosts</constant> entry in your NSS
2784                 control file says:
2785 <screen>
2786 hosts: files dns wins
2787 </screen>
2788                 this means that a hostname lookup first tries the <filename>/etc/hosts</filename>.
2789                 If this fails to resolve, it attempts a DNS lookup, and if that fails, it tries a
2790                 WINS lookup.
2791                 </para>
2793             <para><indexterm>
2794                 <primary>NetBIOS</primary>
2795               </indexterm><indexterm>
2796                 <primary>TCP/IP</primary>
2797               </indexterm><indexterm>
2798                 <primary>name resolution</primary>
2799               </indexterm>
2800                 The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
2801                 been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
2802                 is the preferred name resolution technology. This usually makes most sense when Samba
2803                 is a client of an Active Directory domain, where NetBIOS use has been disabled. In this
2804                 case, the Windows 200x autoregisters all locator records it needs with its own DNS
2805                 server or servers.
2806                 </para>
2808         </answer>
2809         </qandaentry>
2811         <qandaentry>
2812         <question>
2814                 <para>
2815                 Our Windows 2003 Server Active Directory domain runs with NetBIOS disabled. Can we
2816                 use Samba-3 with that configuration?
2817                 </para>
2819         </question>
2820         <answer>
2822                 <para>
2823                 Yes.
2824                 </para>
2826         </answer>
2827         </qandaentry>
2829         <qandaentry>
2830         <question>
2832             <para><indexterm>
2833                 <primary>net</primary>
2834                 <secondary>ads</secondary>
2835                 <tertiary>join</tertiary>
2836               </indexterm><indexterm>
2837                 <primary>net</primary>
2838                 <secondary>rpc</secondary>
2839                 <tertiary>join</tertiary>
2840               </indexterm>
2841                 When I tried to execute net ads join, I got no output. It did not work, so
2842                 I think that it failed. I then executed net rpc join and that worked fine.
2843                 That is okay, isn't it?
2844                 </para>
2846         </question>
2847         <answer>
2849             <para><indexterm>
2850                 <primary>Kerberos</primary>
2851               </indexterm><indexterm>
2852                 <primary>authentication</primary>
2853               </indexterm>
2854                 No. This is not okay. It means that your Samba-3 client has joined the ADS domain as
2855                 a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication.
2856                 </para>
2858         </answer>
2859         </qandaentry>
2861         </qandaset>
2863 </sect1>
2865 </chapter>