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>
7 <primary>Open Magazine</primary>
8 </indexterm><indexterm>
9 <primary>survey</primary>
11 The most frequently discussed Samba subjects over the past two 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 Open Magazine found
13 that of all respondents: 97% use Samba for file and print services, and 68% 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, as shown in
16 <link linkend="ch09openmag"/>.
19 <image id="ch09openmag">
20 <imagedescription>Open Magazine Samba Survey</imagedescription>
21 <imagefile scale="60">openmag</imagefile>
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 Abmas and our good friends Bob Jordan and company.
33 <title>Introduction</title>
36 <primary>Linux desktop</primary>
37 </indexterm><indexterm>
38 <primary>Domain Member</primary>
39 <secondary>server</secondary>
41 Bob Jordan looks back over the achievements of the past year or two. Daily events are rather straightforward
42 with not too many distractions or problems. Bob, 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.
48 <primary>Domain Member</primary>
49 <secondary>desktop</secondary>
51 Stan Soroka 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. Go on, walk the steps
54 with Stan and Company.
58 <title>Assignment Tasks</title>
61 <primary>Active Directory</primary>
63 You must now add UNIX/Linux Domain Member servers to your network. You have a friend who has a Windows 2003
64 Active Directory Domain network who wants to add a Samba/Linux server and has asked Christine to help him
65 out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use
66 her help to get validation that Samba really does live up to expectations.
70 Over the past six months, you have hired several new staff who want Linux on their desktops. You must integrate
71 these systems to make sure that Abmas is not building islands of technology. You ask Christine to
72 do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make
73 the right decision, don't you?
80 <title>Dissection and Discussion</title>
83 <primary>winbind</primary>
85 Recent Samba mailing list activity is witness to how many sites are using winbind. Some have no trouble
86 at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning
87 an inability to achieve identical user and group IDs between Windows and UNIX environments.
91 You provide step-by-step implementations of the various tools that can be used for identity
92 resolution. You also provide working examples of solutions for integrated authentication for
93 both UNIX/Linux and Windows environments.
97 <title>Technical Issues</title>
100 One of the great challenges we face when people ask us, <quote>What is the best way to solve
101 this problem?</quote> is to get beyond the facts so we can not only clearly comprehend
102 the immediate technical problem, but also understand how needs may change.
106 <primary>integrate</primary>
108 There are a few facts we should note when dealing with the question of how best to
109 integrate UNIX/Linux clients and servers into a Windows networking environment:
113 <listitem><para><indexterm>
114 <primary>Domain Controller</primary>
115 </indexterm><indexterm>
116 <primary>authoritative</primary>
117 </indexterm><indexterm>
118 <primary>accounts</primary>
119 <secondary>authoritative</secondary>
120 </indexterm><indexterm>
121 <primary>PDC</primary>
122 </indexterm><indexterm>
123 <primary>BDC</primary>
125 A Domain Controller (PDC or BDC) is always authoritative for all accounts in its Domain.
126 This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs
127 to the same values that the PDC resolved them to.
130 <listitem><para><indexterm>
131 <primary>local accounts</primary>
132 </indexterm><indexterm>
133 <primary>Domain Member</primary>
134 <secondary>authoritative</secondary>
135 <tertiary>local accounts</tertiary>
136 </indexterm><indexterm>
137 <primary>Domain accounts</primary>
138 </indexterm><indexterm>
139 <primary>winbindd</primary>
141 A Domain Member can be authoritative for local accounts, but is never authoritative for
142 Domain accounts. If a user is accessing a Domain Member server and that user's account
143 is not known locally, the Domain Member server must resolve the identity of that user
144 from the Domain in which that user's account resides. It must then map that ID to a
145 UID/GID pair that it can use locally. This is handled by <command>winbindd</command>.
149 Samba, when running on a Domain Member server, can resolve user identities from a
153 <listitem><para><indexterm>
154 <primary>getpwnam</primary>
155 </indexterm><indexterm>
156 <primary>getgrnam</primary>
157 </indexterm><indexterm>
158 <primary>NSS</primary>
159 </indexterm><indexterm>
160 <primary>LDAP</primary>
161 </indexterm><indexterm>
162 <primary>NIS</primary>
164 By executing a system <command>getpwnam()</command> or <command>getgrnam()</command> call.
165 On systems that support it, this utilizes the name service switch (NSS) facility to
166 resolve names according to the configuration of the <filename>/etc/nsswitch.conf</filename>
167 file. NSS can be configured to use LDAP, winbind, NIS, or local files.
170 <listitem><para><indexterm>
171 <primary>passdb backend</primary>
172 </indexterm><indexterm>
173 <primary>PADL</primary>
174 </indexterm><indexterm>
175 <primary>nss_ldap</primary>
177 Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured).
178 This requires the use of the PADL nss_ldap tool (or equivalent).
181 <listitem><para><indexterm>
182 <primary>winbindd</primary>
183 </indexterm><indexterm>
184 <primary>SID</primary>
185 </indexterm><indexterm>
186 <primary>winbindd_idmap.tdb</primary>
187 </indexterm><indexterm>
188 <primary>winbindd_cache.tdb</primary>
190 Directly by querying <command>winbindd</command>. The <command>winbindd</command>
191 contact a Domain Controller to attempt to resolve the identity of the user or group. It
192 receives the Windows networking security identifier (SID) for that appropriate
193 account and then allocates a local UID or GID from the range of available IDs and
194 creates an entry in its <filename>winbindd_idmap.tdb</filename> and
195 <filename>winbindd_cache.tdb</filename> files.
199 <primary>idmap backend</primary>
200 </indexterm><indexterm>
201 <primary>mapping</primary>
204 <smbconfoption name="idmap backend">ldap:ldap://myserver.domain</smbconfoption>
205 was specified and the LDAP server has been configured with a container in which it may
206 store the IDMAP entries, all Domain Members may share a common mapping.
212 Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of
213 the ID mapping database. It uses the <filename>winbindd_idmap.tdb</filename>, and
214 <filename>winbindd_cache.tdb</filename> files to do this.
218 Which of the above resolver methods is chosen is determined by the way that Samba is configured
219 in the &smb.conf; file. Some of the configuration options are rather less than obvious to the
223 <listitem><para><indexterm>
224 <primary>winbind enable local accounts</primary>
225 </indexterm><indexterm>
226 <primary>Domain Member</primary>
227 <secondary>servers</secondary>
228 </indexterm><indexterm>
229 <primary>Domain Controllers</primary>
231 If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable
232 of being resolved using) the name service switch (NSS) facility, it is imperative to use the
233 <smbconfoption name="winbind enable local accounts">Yes</smbconfoption>
234 in the &smb.conf; file. This parameter specifically applies only to Domain Controllers,
235 not to Domain Member servers.
240 <primary>Posix accounts</primary>
241 </indexterm><indexterm>
242 <primary>Samba accounts</primary>
243 </indexterm><indexterm>
244 <primary>LDAP</primary>
246 For many administrators, it should be plain that the use of an LDAP-based repository for all network
247 accounts (both for Posix accounts as well as for Samba accounts) provides the most elegant and
248 controllable facility. You eventually appreciate the decision to use LDAP.
252 <primary>nss_ldap</primary>
253 </indexterm><indexterm>
254 <primary>identifiers</primary>
255 </indexterm><indexterm>
256 <primary>resolve</primary>
258 If your network account information resides in an LDAP repository, you should use it ahead of any
259 alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command>
260 tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, as it provides
261 a more readily controllable method for asserting the exact same user and group identifiers
262 throughout the network.
266 <primary>Domain Member</primary>
267 <secondary>server</secondary>
268 </indexterm><indexterm>
269 <primary>winbind trusted domains only</primary>
270 </indexterm><indexterm>
271 <primary>getpwnam</primary>
272 </indexterm><indexterm>
273 <primary>smbd</primary>
274 </indexterm><indexterm>
275 <primary>Trusted Domains</primary>
276 </indexterm><indexterm>
277 <primary>External Domains</primary>
279 In the situation where UNIX accounts are held on the Domain Member server itself, the only effective
280 way to use them involves the &smb.conf; entry
281 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>. This forces
282 Samba (<command>smbd</command>) to perform a <command>getpwnam()</command> system call that can
283 then be controlled via <filename>/etc/nsswitch.conf</filename> file settings. The use of this parameter
284 disables the use of Samba with Trusted Domains (i.e., External Domains).
288 <primary>appliance mode</primary>
289 </indexterm><indexterm>
290 <primary>Domain Member</primary>
291 <secondary>server</secondary>
292 </indexterm><indexterm>
293 <primary>winbindd</primary>
294 </indexterm><indexterm>
295 <primary>automatically allocate</primary>
297 Winbind can be used to create an appliance mode Domain Member server. In this capacity, <command>winbindd</command>
298 is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation
299 is made for all accounts that connect to that Domain Member server, whether within its own Domain or from
300 Trusted Domains. If not stored in an LDAP backend, each Domain Member maintains its own unique mapping database.
301 This means that it is almost certain that a given user who accesses two Domain Member servers does not have the
302 same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data
303 is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files.
307 <primary>mapping</primary>
309 The use of an LDAP backend for the Winbind IDMAP facility permits Windows Domain security identifiers (SIDs)
310 mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all Domain Member
311 servers so configured. This solves one of the major headaches for network administrators who need to copy
312 files between/across network file servers.
318 <title>Political Issues</title>
321 <primary>OpenLDAP</primary>
322 </indexterm><indexterm>
323 <primary>NIS</primary>
324 </indexterm><indexterm>
325 <primary>yellow pages</primary>
327 </indexterm><indexterm>
328 <primary>identity management</primary>
330 One of the most fierce conflicts recently being waged is one of resistance to the adoption of LDAP, in
331 particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP
332 is different and requires a new approach to the need for a better identity management solution. The more
333 you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm.
337 LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos.
338 The reason these are preferable is because they are heterogenous. Windows solutions of this sort are NOT
339 heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that
340 you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires
341 commercial integration products &smbmdash; it's just not what Active Directory was designed for.
345 <primary>directory</primary>
346 </indexterm><indexterm>
347 <primary>management</primary>
349 A number of long-term UNIX devotees have recently commented in various communications that the Samba Team
350 is the first application group to almost force network administrators to use LDAP. It should be pointed
351 out that we resisted this as long as we could. It is not out of laziness or out of malice that LDAP has
352 finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total
353 organizational directory needs.
361 <title>Implementation</title>
364 <primary>Domain Member</primary>
365 <secondary>server</secondary>
366 </indexterm><indexterm>
367 <primary>Domain Member</primary>
368 <secondary>client</secondary>
369 </indexterm><indexterm>
370 <primary>Domain Controller</primary>
372 The Domain Member server and the Domain Member client are at the center of focus in this chapter.
373 Configuration of Samba-3 Domain Controller has been covered in earlier chapters, so if your
374 interest is in Domain Controller configuration, you will not find that here. You will find good
375 oil that helps you to add Domain Member servers and clients.
379 <primary>Domain Member</primary>
380 <secondary>workstations</secondary>
382 In practice, Domain Member servers and Domain Member workstations are very different entities, but in
383 terms of technology they share similar core infrastructure. A technologist would argue that servers
384 and workstations are identical. Many users would argue otherwise, given that in a well-disciplined
385 environment a workstation (client) is a device from which a user creates documents and files that
386 are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item,
387 but a server is viewed as a core component of the business.
391 <primary>workstation</primary>
393 One can look at this another way. If a workstation breaks down, one user is affected, but if a
394 server breaks down, hundreds of users may not be able to work. The services that a workstation
395 must provide are document and file production oriented; a server provides information storage
396 and is distribution oriented.
400 <primary>authentication process</primary>
401 </indexterm><indexterm>
402 <primary>logon process</primary>
403 </indexterm><indexterm>
404 <primary>user identities</primary>
406 <emphasis>Why is this important?</emphasis> &smbmdash; For starters, we must identify what
407 components of the operating system and its environment must be configured. Also, it is necessary
408 to recognize where the interdependencies between the various services to be used are.
409 In particular, it is important to understand the operation of each critical part of the
410 authentication process, the logon process, and how user identities get resolved and applied
411 within the operating system and applications (like Samba) that depend on this and may
412 actually contribute to it.
416 So, while here we demonstrate how to implement the technology. It is done within a context of
417 what type of service need must be fulfilled.
420 <sect2 id="sdcsdmldap">
421 <title>Samba Domain with Samba Domain Member Server &smbmdash; Using LDAP</title>
424 <primary>ldapsam</primary>
425 </indexterm><indexterm>
426 <primary>ldapsam backend</primary>
427 </indexterm><indexterm>
428 <primary>IDMAP</primary>
429 </indexterm><indexterm>
430 <primary>mapping</primary>
431 <secondary>consistent</secondary>
432 </indexterm><indexterm>
433 <primary>winbindd</primary>
434 </indexterm><indexterm>
435 <primary>foreign SID</primary>
437 In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using
438 an LDAP ldapsam backend. In this example, we are adding to the LDAP backend database (directory)
439 containers for use by the IDMAP facility. This makes it possible to have globally consistent
440 mapping of SIDs to/from UIDs/GIDs. This means that you are running <command>winbindd</command>
441 as part of your configuration. The primary purpose of running <command>winbindd</command> (within
442 this operational context) is to permit mapping of foreign SIDs (those not originating from our
443 own Domain). Foreign SIDs can come from any external Domain or from Windows clients that do not
448 <primary>winbindd</primary>
449 </indexterm><indexterm>
450 <primary>getpwnam</primary>
451 </indexterm><indexterm>
452 <primary>NSS</primary>
454 If your installation is accessed only from clients that are members of your own domain, then
455 it is not necessary to run <command>winbindd</command> as long as all users can be resolved
456 locally via the <command>getpwnam()</command> system call. On NSS-enabled systems, this condition
461 <listitem><para><indexterm>
462 <primary>/etc/passwd</primary>
463 </indexterm><indexterm>
464 <primary>/etc/group</primary>
466 All accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>.
469 <listitem><para><indexterm>
470 <primary>NSS</primary>
471 </indexterm><indexterm>
472 <primary>compat</primary>
473 </indexterm><indexterm>
474 <primary>compat</primary>
475 </indexterm><indexterm>
476 <primary>ldap</primary>
477 </indexterm><indexterm>
478 <primary>nis</primary>
479 </indexterm><indexterm>
480 <primary>nisplus</primary>
481 </indexterm><indexterm>
482 <primary>hesoid</primary>
483 </indexterm><indexterm>
484 <primary>ldap</primary>
485 </indexterm><indexterm>
486 <primary>nss_ldap</primary>
487 </indexterm><indexterm>
488 <primary>PADL Software</primary>
490 Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs
491 via multiple methods. The methods typically include: <command>files, compat, db, ldap,
492 nis, nisplus, hesoid.</command> When correctly installed, Samba adds to this list
493 the <command>winbindd</command> facility. The ldap facility is frequently the nss_ldap
494 tool provided by PADL Software.
499 <primary>Identity resolution</primary>
501 The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of samba and system
502 components that are involved in the Identity resolution process where Samba is used as a Domain
503 Member server within a Samba Domain Control network.
506 <image id="ch9-sambadc">
507 <imagedescription>Samba Domain: Samba Member Server</imagedescription>
508 <imagefile scale="60">chap9-SambaDC</imagefile>
512 <primary>IDMAP</primary>
513 </indexterm><indexterm>
514 <primary>foreign</primary>
516 In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam
517 to obtain authentication and user identity information. The IDMAP information is stored in the LDAP
518 backend so that it can be shared by all Domain Member servers so that every user will have a
519 consistent UID and GID across all of them. The IDMAP facility will be used for all foreign
520 (i.e., not having the same SID as the Domain it is a member of) Domains. The configuration of
521 NSS will ensure that all unix processes will obtain a consistent UID/GID.
525 The instructions given here apply to the Samba environment as shown in Chapters 6 and 7.
526 If your network does not have an LDAP slave server (i.e., Chapter 6 configuration), you
527 must change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
531 <title>Configuration of LDAP-Based Identity Resolution</title>
534 Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate
535 this file in the directory <filename>/etc/samba</filename>.
538 <step><para><indexterm>
539 <primary>ldap.conf</primary>
541 Configure the file that will be used by <constant>nss_ldap</constant> to
542 locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>.
543 If your implementation of <constant>nss_ldap</constant> is consistent with
544 the defaults suggested by PADL (the authors), it will be located in the
545 <filename>/etc</filename> directory. On some systems, the default location is
546 the <filename>/etc/openldap</filename> directory. Change the parameters inside
547 the file that is located on your OS so it matches <link linkend="ch9-sdmlcnf"/>.
548 To find the correct location of this file, you can obtain this from the
549 library that will be used by executing the following:
551 &rootprompt; strings /lib/libnss_ldap* | grep ldap.conf
557 Configure the name service switch (NSS) control file so it matches the one shown
558 in <link linkend="ch9-sdmnss"/>.
561 <step><para><indexterm>
562 <primary>Identity resolution</primary>
563 </indexterm><indexterm>
564 <primary>getent</primary>
566 Before proceeding to configure Samba, validate the operation of the NSS Identity
567 resolution via LDAP by executing:
569 &rootprompt; getent passwd
571 root:x:0:512:Netbios Domain Administrator:/root:/bin/false
572 nobody:x:999:514:nobody:/dev/null:/bin/false
573 bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
574 stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
575 chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
576 maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
577 jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
578 bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
579 temptation$:x:1009:553:temptation$:/dev/null:/bin/false
580 vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
581 fran$:x:1008:553:fran$:/dev/null:/bin/false
582 josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash
584 You should notice the location of the users' home directories. First, make certain that
585 the home directories exist on the Domain Member server; otherwise, the home directory
586 share is not available. The home directories could be mounted off a domain controller
587 using NFS, or by any other suitable means. Second, the absence of the Domain name in the
588 home directory path is indicative that Identity resolution is not being done via Winbind.
590 &rootprompt; getent group
592 Domain Admins:x:512:root,jht
593 Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
601 <primary>secondary group</primary>
602 </indexterm><indexterm>
603 <primary>primary group</primary>
604 </indexterm><indexterm>
605 <primary>group membership</primary>
607 This shows that all is working as it should. Notice that in the LDAP database
608 the users primary and secondary group memberships are identical. It is not
609 necessary to add secondary group memberships (in the group database) if the
610 user is already a member via primary group membership in the password database.
611 When using winbind, it is in fact undesirable to do this as it results in
612 doubling up of group memberships and may break winbind under certain conditions.
615 <step><para><indexterm>
616 <primary>slapcat</primary>
618 The LDAP directory must have a container object for IDMAP data. There are several ways you can
619 check that your LDAP database is able to receive IDMAP information. One of the simplest is to
622 &rootprompt; slapcat | grep -i idmap
623 dn: ou=Idmap,dc=abmas,dc=biz
627 <primary>ldapadd</primary>
629 If the execution of this command does not return IDMAP entries, you need to create an LDIF
630 template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using the following command:
632 &rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
633 -w not24get < /etc/openldap/idmap.LDIF
635 Samba automatically populates this LDAP directory container when it needs to.
638 <step><para><indexterm>
639 <primary>net</primary>
640 <secondary>rpc</secondary>
641 <tertiary>join</tertiary>
642 </indexterm><indexterm>
643 <primary>Domain join</primary>
645 The system is ready to join the Domain. Execute the following:
647 &rootprompt; net rpc join -U root%not24et
648 Joined domain MEGANET2.
650 This indicates that the Domain join succeeded.
654 <indexterm><primary>wbinfo</primary></indexterm>
655 Just joining the Domain is not quite enough, you must now provide a privilidged set
656 of credentials through which <command>winbindd</command> can interact with the ADS
657 Domain servers. Execute the following to implant the necessary credentials:
659 &rootprompt; wbinfo --set-auth-user=Administrator%not24get
661 - The configuration is now ready to obtain ADS Domain user and group information.
665 You may now start Samba in the usual manner and your Samba Domain Member server
666 is ready for use. Just add shares as required.
671 <smbconfexample id="ch9-sdmsdc">
672 <title>Samba Domain Member in Samba Domain Control Context &smbmdash; &smb.conf; File</title>
673 <smbconfcomment>Global parameters</smbconfcomment>
674 <smbconfsection name="[global]"/>
675 <smbconfoption name="unix charset">LOCALE</smbconfoption>
676 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
677 <smbconfoption name="security">DOMAIN</smbconfoption>
678 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
679 <smbconfoption name="log level">10</smbconfoption>
680 <smbconfoption name="syslog">0</smbconfoption>
681 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
682 <smbconfoption name="max log size">50</smbconfoption>
683 <smbconfoption name="smb ports">139 445</smbconfoption>
684 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
685 <smbconfoption name="printcap name">CUPS</smbconfoption>
686 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
687 <smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption>
688 <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
689 <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
690 <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
691 <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
692 <smbconfoption name="ldap admin dn">cn=Manager,dc=abmas,dc=biz</smbconfoption>
693 <smbconfoption name="idmap backend">ldap:ldap://lapdc.abmas.biz</smbconfoption>
694 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
695 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
696 <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>
697 <smbconfoption name="printer admin">root</smbconfoption>
698 <smbconfoption name="printing">cups</smbconfoption>
700 <smbconfsection name="[homes]"/>
701 <smbconfoption name="comment">Home Directories</smbconfoption>
702 <smbconfoption name="valid users">%S</smbconfoption>
703 <smbconfoption name="read only">No</smbconfoption>
704 <smbconfoption name="browseable">No</smbconfoption>
706 <smbconfsection name="[printers]"/>
707 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
708 <smbconfoption name="path">/var/spool/samba</smbconfoption>
709 <smbconfoption name="guest ok">Yes</smbconfoption>
710 <smbconfoption name="printable">Yes</smbconfoption>
711 <smbconfoption name="browseable">No</smbconfoption>
713 <smbconfsection name="[print$]"/>
714 <smbconfoption name="comment">Printer Drivers</smbconfoption>
715 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
716 <smbconfoption name="admin users">root, Administrator</smbconfoption>
717 <smbconfoption name="write list">root</smbconfoption>
720 <example id="ch9-ldifadd">
721 <title>LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF</title>
723 dn: ou=Idmap,dc=abmas,dc=biz
724 objectClass: organizationalUnit
726 structuralObjectClass: organizationalUnit
730 <example id="ch9-sdmlcnf">
731 <title>Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename></title>
733 URI ldap://massive.abmas.biz ldap://massive.abmas.biz:636
736 binddn cn=Manager,dc=abmas,dc=biz
741 nss_base_passwd ou=People,dc=abmas,dc=biz?one
742 nss_base_shadow ou=People,dc=abmas,dc=biz?one
743 nss_base_group ou=Groups,dc=abmas,dc=biz?one
748 <example id="ch9-sdmnss">
749 <title>NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename></title>
754 hosts: files dns wins
774 <title>NT4/Samba Domain with Samba Domain Member Server &smbmdash; Using Winbind</title>
777 You need to use this method for creating a Samba Domain Member server if any of the following conditions
783 LDAP support (client) is not installed on the system.
787 There are mitigating circumstances forcing a decision not to use LDAP.
791 The Samba Domain Member server must be part of a Windows NT4 Domain.
796 <primary>Windows ADS Domain</primary>
797 </indexterm><indexterm>
798 <primary>Samba Domain</primary>
799 </indexterm><indexterm>
800 <primary>LDAP</primary>
802 Later in the chapter, you can see how to configure a Samba Domain Member server for a Windows ADS Domain.
803 Right now your objective is to configure a Samba server that can be a member of a Windows NT4 style
804 Domain and/or does not use LDAP.
807 <note><para><indexterm>
808 <primary>duplicate accounts</primary>
810 If you use <command>winbind</command> for Identity resolution, do make sure that there are no
815 <primary>/etc/passwd</primary>
817 For example, do not have more than one account that has UID=0 in the password database. If there
818 is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database,
819 it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the
820 tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will
821 break. This means that the <constant>Administrator</constant> account must be called
822 <constant>root</constant>.
826 <primary>/etc/passwd</primary>
827 </indexterm><indexterm>
828 <primary>ldapsam</primary>
829 </indexterm><indexterm>
830 <primary>tdbsam</primary>
832 Winbind will break if there is an account in <filename>/etc/passwd</filename> that has
833 the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only.
837 <primary>credentials</primary>
838 </indexterm><indexterm>
839 <primary>traverse</primary>
840 </indexterm><indexterm>
841 <primary>wide-area</primary>
842 </indexterm><indexterm>
843 <primary>network</primary>
844 <secondary>wide-area</secondary>
845 </indexterm><indexterm>
846 <primary>tdbdump</primary>
848 The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials.
849 The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename>
850 files. This provides considerable performance benefits compared with the LDAP solution, particularly
851 where the LDAP lookups must traverse wide-area network links. You may examine the contents of these
852 files using the tool <command>tdbdump</command>, though you may have to build this from the Samba
853 source code if it has not been supplied as part of a binary package distribution that you may be using.
857 <title>Configuration of Winbind-Based Identity Resolution</title>
860 Using your favorite text editor, create the &smb.conf; file so it has the contents
861 shown in <link linkend="ch0-NT4DSDM"/>.
864 <step><para><indexterm>
865 <primary>/etc/nsswitch.conf</primary>
867 Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in
868 <link linkend="ch9-nsswbnd"/>.
871 <step><para><indexterm>
872 <primary>net</primary>
873 <secondary>rpc</secondary>
874 <tertiary>join</tertiary>
876 The system is ready to join the Domain. Execute the following:
878 net rpc join -U root%not24et
879 Joined domain MEGANET2.
881 This indicates that the Domain join succeed.
885 <step><para><indexterm>
886 <primary>winbind</primary>
887 </indexterm><indexterm>
888 <primary>wbinfo</primary>
890 Validate operation of <command>winbind</command> using the <command>wbinfo</command>
893 &rootprompt; wbinfo -u
904 This shows that Domain users have been listed correctly.
906 &rootprompt; wbinfo -g
907 MEGANET2+Domain Admins
908 MEGANET2+Domain Users
909 MEGANET2+Domain Guests
914 This shows that Domain groups have been correctly obtained also.
917 <step><para><indexterm>
918 <primary>NSS</primary>
919 </indexterm><indexterm>
920 <primary>getent</primary>
921 </indexterm><indexterm>
922 <primary>winbind</primary>
924 The next step verifies that NSS is able to obtain this information
925 correctly from <command>winbind</command> also.
927 &rootprompt; getent passwd
929 MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
930 /home/MEGANET2/root:/bin/bash
931 MEGANET2+nobody:x:10001:10001:nobody:
932 /home/MEGANET2/nobody:/bin/bash
933 MEGANET2+jht:x:10002:10001:John H Terpstra:
934 /home/MEGANET2/jht:/bin/bash
935 MEGANET2+maryv:x:10003:10001:Mary Vortexis:
936 /home/MEGANET2/maryv:/bin/bash
937 MEGANET2+billr:x:10004:10001:William Randalph:
938 /home/MEGANET2/billr:/bin/bash
939 MEGANET2+jelliott:x:10005:10001:John G Elliott:
940 /home/MEGANET2/jelliott:/bin/bash
941 MEGANET2+dbrady:x:10006:10001:Darren Brady:
942 /home/MEGANET2/dbrady:/bin/bash
943 MEGANET2+joeg:x:10007:10001:Joe Green:
944 /home/MEGANET2/joeg:/bin/bash
945 MEGANET2+balap:x:10008:10001:Bala Pillay:
946 /home/MEGANET2/balap:/bin/bash
948 The user account information has been correctly obtained. This information has
949 been merged with the winbind template information configured in the &smb.conf; file.
951 &rootprompt;# getent group
953 MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
954 MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
955 MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
956 MEGANET2+joeg,MEGANET2+balap
957 MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
958 MEGANET2+Accounts:x:10003:
959 MEGANET2+Finances:x:10004:
960 MEGANET2+PIOps:x:10005:
965 The Samba member server of a Windows NT4 Domain is ready for use.
969 <smbconfexample id="ch0-NT4DSDM">
970 <title>Samba Domain Member Server &smb.conf; File for NT4 Domain</title>
971 <smbconfcomment>Global parameters</smbconfcomment>
972 <smbconfsection name="[global]"/>
973 <smbconfoption name="unix charset">LOCALE</smbconfoption>
974 <smbconfoption name="workgroup">MEGANET2</smbconfoption>
975 <smbconfoption name="security">DOMAIN</smbconfoption>
976 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
977 <smbconfoption name="log level">1</smbconfoption>
978 <smbconfoption name="syslog">0</smbconfoption>
979 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
980 <smbconfoption name="max log size">0</smbconfoption>
981 <smbconfoption name="smb ports">139 445</smbconfoption>
982 <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
983 <smbconfoption name="printcap name">CUPS</smbconfoption>
984 <smbconfoption name="wins server">192.168.2.1</smbconfoption>
985 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
986 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
987 <smbconfoption name="template primary group">"Domain Users"</smbconfoption>
988 <smbconfoption name="template shell">/bin/bash</smbconfoption>
989 <smbconfoption name="winbind separator">+</smbconfoption>
990 <smbconfoption name="printer admin">root</smbconfoption>
991 <smbconfoption name="hosts allow">192.168.2., 192.168.3., 127.</smbconfoption>
992 <smbconfoption name="printing">cups</smbconfoption>
994 <smbconfsection name="[homes]"/>
995 <smbconfoption name="comment">Home Directories</smbconfoption>
996 <smbconfoption name="valid users">%S</smbconfoption>
997 <smbconfoption name="read only">No</smbconfoption>
998 <smbconfoption name="browseable">No</smbconfoption>
1000 <smbconfsection name="[printers]"/>
1001 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1002 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1003 <smbconfoption name="guest ok">Yes</smbconfoption>
1004 <smbconfoption name="printable">Yes</smbconfoption>
1005 <smbconfoption name="browseable">No</smbconfoption>
1007 <smbconfsection name="[print$]"/>
1008 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1009 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1010 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1011 <smbconfoption name="write list">root</smbconfoption>
1014 <example id="ch9-nsswbnd">
1015 <title>Name Service Switch Control File: <filename>/etc/nsswitch.conf</filename></title>
1017 # /etc/nsswitch.conf
1019 passwd: compat winbind
1020 group: compat winbind
1022 hosts: files dns wins
1042 <title>Active Directory Domain with Samba Domain Member Server</title>
1045 <primary>Active Directory</primary>
1046 <secondary>join</secondary>
1047 </indexterm><indexterm>
1048 <primary>Kerberos</primary>
1049 </indexterm><indexterm>
1050 <primary>Domain Member</primary>
1051 <secondary>server</secondary>
1053 One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory
1054 Domain using Kerberos protocols. This makes it possible to operate an entire Windows network
1055 without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An
1056 exhaustively complete discussion of the protocols is not possible in this book; perhaps a
1057 later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate
1058 in. For now, we simply focus on how a Samba-3 server can be made a Domain Member server.
1062 <primary>Active Directory</primary>
1063 </indexterm><indexterm>
1064 <primary>LDAP</primary>
1065 </indexterm><indexterm>
1066 <primary>Identity resolution</primary>
1067 </indexterm><indexterm>
1068 <primary>Kerberos</primary>
1070 The diagram in <link linkend="ch9-adsdc"/> demonstrates how Samba-3 interfaces with
1071 Microsoft Active Directory components. It should be noted that if Microsoft Windows Services
1072 for UNIX has been installed and correctly configured, it is possible to use client LDAP
1073 for Identity resolution just as can be done with Samba-3 when using an LDAP passdb backend.
1074 The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL
1075 Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of
1076 LDAP-based Identity resolution is a little less secure. In view of the fact that this solution
1077 requires additional software to be installed on the Windows 200x ADS Domain Controllers,
1078 and that means more management overhead, it is likely that most Samba-3 ADS client sites
1079 may elect to use winbind.
1083 Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3
1084 you are using has been compiled and linked with all the tools necessary for this to work.
1085 Given the importance of this step, you must first validate that the Samba-3 message block
1086 daemon (<command>smbd</command>) has the necessary features.
1090 The hypothetical domain you are using in this example assumes that the Abmas London office
1091 decided to take their own lead (some would say this is a typical behavior in a global
1092 corporate world; besides, a little divergence and conflict makes for an interesting life).
1093 The Windows Server 2003 ADS Domain is called <constant>london.abmas.biz</constant> and the
1094 name of the server is <constant>W2K3S</constant>. In ADS realm terms, the Domain Controller
1095 is known as <constant>w2k3s.london.abmas.biz</constant>. In NetBIOS nomenclature, the
1096 Domain Name is <constant>LONDON</constant> and the server name is <constant>W2K3S</constant>.
1099 <image id="ch9-adsdc">
1100 <imagedescription>Active Directory Domain: Samba Member Server</imagedescription>
1101 <imagefile scale="60">chap9-ADSDC</imagefile>
1105 <step><para><indexterm>
1106 <primary>smbd</primary>
1108 Before you try to use Samba-3, you want to know for certain that your executables have
1109 support for Kerberos and for LDAP. Execute the following to identify whether or
1110 not this build is perhaps suitable for use:
1112 &rootprompt; cd /usr/sbin
1113 &rootprompt; smbd -b | grep KRB
1115 HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
1117 HAVE_KRB5_AUTH_CON_SETKEY
1118 HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
1119 HAVE_KRB5_GET_PW_SALT
1120 HAVE_KRB5_KEYBLOCK_KEYVALUE
1121 HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
1122 HAVE_KRB5_MK_REQ_EXTENDED
1123 HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
1124 HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
1125 HAVE_KRB5_STRING_TO_KEY
1126 HAVE_KRB5_STRING_TO_KEY_SALT
1129 The above output was obtained on a SuSE Linux system and shows the output for
1130 Samba that has been compiled and linked with the Heimdal Kerberos libraries.
1131 The following is a typical output that will be found on a Red Hat Linux system that
1132 has been linked with the MIT Kerberos libraries:
1134 &rootprompt; cd /usr/sbin
1135 &rootprompt; smbd -b | grep KRB
1137 HAVE_ADDRTYPE_IN_KRB5_ADDRESS
1139 HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
1140 HAVE_KRB5_ENCRYPT_DATA
1141 HAVE_KRB5_FREE_DATA_CONTENTS
1142 HAVE_KRB5_FREE_KTYPES
1143 HAVE_KRB5_GET_PERMITTED_ENCTYPES
1144 HAVE_KRB5_KEYTAB_ENTRY_KEY
1145 HAVE_KRB5_LOCATE_KDC
1146 HAVE_KRB5_MK_REQ_EXTENDED
1147 HAVE_KRB5_PRINCIPAL2SALT
1148 HAVE_KRB5_PRINC_COMPONENT
1149 HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
1150 HAVE_KRB5_SET_REAL_TIME
1151 HAVE_KRB5_STRING_TO_KEY
1152 HAVE_KRB5_TKT_ENC_PART2
1153 HAVE_KRB5_USE_ENCTYPE
1157 You can validate that Samba has been compiled and linked with LDAP support
1160 &rootprompt; smbd -b | grep LDAP
1161 massive:/usr/sbin # smbd -b | grep LDAP
1164 HAVE_LDAP_DOMAIN2HOSTLIST
1166 HAVE_LDAP_INITIALIZE
1167 HAVE_LDAP_SET_REBIND_PROC
1169 LDAP_SET_REBIND_PROC_ARGS
1171 This does look promising; <command>smbd</command> has been built with Kerberos and LDAP
1172 support. You are relieved to know that it is safe to progress.
1175 <step><para><indexterm>
1176 <primary>Kerberos</primary>
1177 <secondary>libraries</secondary>
1178 </indexterm><indexterm>
1179 <primary>MIT Kerberos</primary>
1180 </indexterm><indexterm>
1181 <primary>Heimdal Kerberos</primary>
1182 </indexterm><indexterm>
1183 <primary>Kerberos</primary>
1184 <secondary>MIT</secondary>
1185 </indexterm><indexterm>
1186 <primary>Kerberos</primary>
1187 <secondary>Heimdal</secondary>
1188 </indexterm><indexterm>
1189 <primary>Red Hat Linux</primary>
1190 </indexterm><indexterm>
1191 <primary>SUSE Linux</primary>
1192 </indexterm><indexterm>
1193 <primary>SerNet</primary>
1194 </indexterm><indexterm>
1195 <primary>validated</primary>
1197 The next step is to identify which version of the Kerberos libraries have been used.
1198 In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is
1199 essential that it has been linked with either MIT Kerberos version 1.3.1 or later,
1200 or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may
1201 identify what version of the MIT Kerberos libraries are installed on your system by
1202 executing (on Red Hat Linux):
1204 &rootprompt; rpm -q krb5
1206 Or on SUSE Linux, execute:
1208 &rootprompt; rpm -q heimdal
1210 Please note that the RPMs provided by the Samba-Team are known to be working and have
1211 been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE
1212 Linux RPMs may be obtained from <ulink url="ftp://ftp.sernet.de">Sernet</ulink> in
1217 From this point on, you are certain that the Samba-3 build you are using has the
1218 necessary capabilities. You can now configure Samba-3 and the name service
1223 Using you favorite editor, configure the &smb.conf; file that is located in the
1224 <filename>/etc/samba</filename> directory so that it has the contents shown
1225 in <link linkend="ch9-adssdm"/>.
1229 Edit or create the NSS control file so it has the contents shown in <link linkend="ch9-nsswbnd"/>.
1232 <step><para><indexterm>
1233 <primary>/etc/samba/secrets.tdb</primary>
1235 Delete the file <filename>/etc/samba/secrets.tdb</filename>, if it exists. Of course, you
1236 do keep a backup, don't you?
1240 Delete the tdb files that cache Samba information. You keep a backup of the old
1241 files, of course. You also remove all files to ensure that nothing can pollute your
1242 nice, new configuration. Execute the following (example is for SUSE Linux):
1244 &rootprompt; rm /var/lib/samba/*tdb
1248 <step><para><indexterm>
1249 <primary>testparm</primary>
1251 Validate your &smb.conf; file using <command>testparm</command> (as you have
1252 done previously). Correct all errors reported before proceeding. The command you
1255 &rootprompt; testparm -s | less
1257 Now that you are satisfied that your Samba server is ready to join the Windows
1258 ADS Domain, let's move on.
1261 <step><para><indexterm>
1262 <primary>net</primary>
1263 <secondary>ads</secondary>
1264 <tertiary>join</tertiary>
1265 </indexterm><indexterm>
1266 <primary>Kerberos</primary>
1268 This is a good time to double-check everything and then execute the following
1269 command when everything you have done has checked out okay:
1271 &rootprompt; net ads join -UAdministrator%not24get
1272 Using short domain name -- LONDON
1273 Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'
1275 You have successfully made your Samba-3 server a member of the ADS Domain
1276 using Kerberos protocols.
1280 <primary>silent return</primary>
1281 </indexterm><indexterm>
1282 <primary>failed join</primary>
1284 In the event that you receive no output messages, a silent return means that the
1285 Domain join failed. You should use <command>ethereal</command> to identify what
1286 may be failing. Common causes of a failed join include:
1289 <listitem><para><indexterm>
1290 <primary>name resolution</primary>
1291 <secondary>Defective</secondary>
1293 Defective or misconfigured DNS name resolution.
1296 <listitem><para><indexterm>
1297 <primary>Restrictive security</primary>
1299 Restrictive security settings on the Windows 200x ADS Domain controller
1300 preventing needed communications protocols. You can check this by searching
1301 the Windows Server 200x Event Viewer.
1305 Incorrectly configured &smb.conf; file settings.
1309 Lack of support of necessary Kerberos protocols because the version of MIT
1310 Kerberos (or Heimdal) in use is not up to date enough to support the necessary
1315 <primary>net</primary>
1316 <secondary>rpc</secondary>
1317 <tertiary>join</tertiary>
1318 </indexterm><indexterm>
1319 <primary>RPC</primary>
1320 </indexterm><indexterm>
1321 <primary>mixed mode</primary>
1323 In any case, never execute the <command>net rpc join</command> command in an attempt
1324 to join the Samba server to the Domain, unless you wish not to use the Kerberos
1325 security protocols. Use of the older RPC-based Domain join facility requires that
1326 Windows Server 200x ADS has been configured appropriately for mixed mode operation.
1329 <step><para><indexterm>
1330 <primary>tdbdump</primary>
1331 </indexterm><indexterm>
1332 <primary>/etc/samba/secrets.tdb</primary>
1334 If the <command>tdbdump</command> is installed on your system (not essential),
1335 you can look inside the <filename>/etc/samba/secrets.tdb</filename> file. If
1336 you wish to do this, execute:
1338 &rootprompt; tdbdump secrets.tdb
1340 key = "SECRETS/SID/LONDON"
1341 data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
1342 F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
1343 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
1344 00\00\00\00\00\00\00\00"
1347 key = "SECRETS/MACHINE_PASSWORD/LONDON"
1348 data = "le3Q5FPnN5.ueC\00"
1351 key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
1352 data = "\02\00\00\00"
1355 key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
1359 This is given to demonstrate to the skeptics that this process truly does work.
1363 It is now time to start Samba in the usual way (as has been done many time before
1367 <step><para><indexterm>
1368 <primary>wbinfo</primary>
1370 This is a good time to verify that everything is working. First, check that
1371 winbind is able to obtain the list of users and groups from the ADS Domain Controller.
1372 Execute the following:
1374 &rootprompt; wbinfo -u
1375 LONDON+Administrator
1377 LONDON+SUPPORT_388945a0
1381 Good, the list of users was obtained. Now do likewise for group accounts:
1383 &rootprompt; wbinfo -g
1384 LONDON+Domain Computers
1385 LONDON+Domain Controllers
1386 LONDON+Schema Admins
1387 LONDON+Enterprise Admins
1388 LONDON+Domain Admins
1390 LONDON+Domain Guests
1391 LONDON+Group Policy Creator Owners
1392 LONDON+DnsUpdateProxy
1394 Excellent. That worked also, as expected.
1397 <step><para><indexterm>
1398 <primary>getent</primary>
1400 Now repeat this via NSS to validate that full Identity resolution is
1401 functional as required. Execute:
1403 &rootprompt; getent passwd
1405 LONDON+Administrator:x:10000:10000:Administrator:
1406 /home/LONDON/administrator:/bin/bash
1407 LONDON+Guest:x:10001:10001:Guest:
1408 /home/LONDON/guest:/bin/bash
1409 LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
1410 /home/LONDON/support_388945a0:/bin/bash
1411 LONDON+krbtgt:x:10003:10000:krbtgt:
1412 /home/LONDON/krbtgt:/bin/bash
1413 LONDON+jht:x:10004:10000:John H. Terpstra:
1414 /home/LONDON/jht:/bin/bash
1416 Okay, ADS user accounts are being resolved. Now you try group resolution as follows:
1418 &rootprompt; getent group
1420 LONDON+Domain Computers:x:10002:
1421 LONDON+Domain Controllers:x:10003:
1422 LONDON+Schema Admins:x:10004:LONDON+Administrator
1423 LONDON+Enterprise Admins:x:10005:LONDON+Administrator
1424 LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
1425 LONDON+Domain Users:x:10000:
1426 LONDON+Domain Guests:x:10001:
1427 LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
1428 LONDON+DnsUpdateProxy:x:10008:
1430 This is very pleasing. Everything works as expected.
1433 <step><para><indexterm>
1434 <primary>net</primary>
1435 <secondary>ads</secondary>
1436 <tertiary>info</tertiary>
1437 </indexterm><indexterm>
1438 <primary>Active Directory</primary>
1439 <secondary>server</secondary>
1440 </indexterm><indexterm>
1441 <primary>Kerberos</primary>
1443 You may now perform final verification that communications between Samba-3 winbind and
1444 the Active Directory server is using Kerberos protocols. Execute the following:
1446 &rootprompt; net ads info
1447 LDAP server: 192.168.2.123
1448 LDAP server name: w2k3s
1449 Realm: LONDON.ABMAS.BIZ
1450 Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
1452 Server time: Sat, 03 Jan 2004 02:44:44 GMT
1453 KDC server: 192.168.2.123
1454 Server time offset: 2
1456 It should be noted that Kerberos protocols are time-clock critical. You should
1457 keep all server time clocks synchronized using the network time protocol (NTP).
1458 In any case, the output we obtained confirms that all systems are operational.
1461 <step><para><indexterm>
1462 <primary>net</primary>
1463 <secondary>ads</secondary>
1464 <tertiary>status</tertiary>
1466 There is one more action you elect to take, just because you are paranoid and disbelieving,
1467 so you execute the following command:
1469 &rootprompt; net ads status -UAdministrator%not24get
1472 objectClass: organizationalPerson
1474 objectClass: computer
1476 distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
1478 whenCreated: 20040103092006.0Z
1479 whenChanged: 20040103092006.0Z
1483 objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
1484 userAccountControl: 69632
1490 lastLogon: 127175965783327936
1492 pwdLastSet: 127175952062598496
1494 objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
1495 accountExpires: 9223372036854775807
1497 sAMAccountName: fran$
1498 sAMAccountType: 805306369
1499 operatingSystem: Samba
1500 operatingSystemVersion: 3.0.12-SUSE
1502 userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
1503 servicePrincipalName: CIFS/fran.london.abmas.biz
1504 servicePrincipalName: CIFS/fran
1505 servicePrincipalName: HOST/fran.london.abmas.biz
1506 servicePrincipalName: HOST/fran
1507 objectCategory: CN=Computer,CN=Schema,CN=Configuration,
1508 DC=london,DC=abmas,DC=biz
1509 isCriticalSystemObject: FALSE
1510 -------------- Security Descriptor (revision: 1, type: 0x8c14)
1511 owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
1512 group SID: S-1-5-21-4052121579-2079768045-1474639452-513
1513 ------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
1514 ------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
1515 mask: 0x20, object flags: 0x3)
1517 access type: AUDIT OBJECT
1519 [Write All Properties]
1520 ------- ACE (type: 0x07, flags: 0x5a, size: 0x38,
1521 mask: 0x20, object flags: 0x3)
1523 access type: AUDIT OBJECT
1525 [Write All Properties]
1526 ------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
1527 ------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
1528 access SID: S-1-5-21-4052121579-2079768045-1474639452-512
1529 access type: ALLOWED
1530 Permissions: [Full Control]
1531 ------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
1532 access SID: S-1-5-32-548
1534 ------- ACE (type: 0x05, flags: 0x12, size: 0x38,
1535 mask: 0x10, object flags: 0x3)
1537 access type: ALLOWED OBJECT
1539 [Read All Properties]
1540 -------------- End Of Security Descriptor
1542 And now you have conclusive proof that your Samba-3 ADS Domain Member Server
1543 called <constant>FRAN</constant>, is able to communicate fully with the ADS
1550 Your Samba-3 ADS Domain Member server is ready for use. During training sessions,
1551 you may be asked what is inside the <filename>winbindd_cache.tdb and winbindd_idmap.tdb</filename>
1552 files. Since curiosity just took hold of you, execute the following:
1554 &rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb
1556 key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
1557 data = "UID 10001\00"
1560 key = "UID 10005\00"
1561 data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
1564 key = "GID 10004\00"
1565 data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
1568 key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
1569 data = "UID 10003\00"
1573 &rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb
1576 data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
1577 Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
1578 S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
1579 Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
1580 S-1-5-21-4052121579-2079768045-1474639452-514\10
1581 SUPPORT_388945a0\10SUPPORT_388945a0.
1582 S-1-5-21-4052121579-2079768045-1474639452-1001-
1583 S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
1584 krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
1585 S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
1586 John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
1587 S-1-5-21-4052121579-2079768045-1474639452-513"
1590 key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
1591 data = "\00\00\00\00bp\00\00\02\00\00\00.
1592 S-1-5-21-4052121579-2079768045-1474639452-1110\03
1593 jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
1594 Administrator\01\00\00\00"
1597 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
1598 data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
1601 key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
1602 data = "\00\00\00\00bp\00\00\01\00\00\00-
1603 S-1-5-21-4052121579-2079768045-1474639452-500\0D
1604 Administrator\01\00\00\00"
1607 key = "SEQNUM/LONDON\00"
1608 data = "xp\00\00C\92\F6?"
1611 key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
1612 data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
1613 S-1-5-21-4052121579-2079768045-1474639452-1110-
1614 S-1-5-21-4052121579-2079768045-1474639452-513"
1617 key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
1618 data = "\00\00\00\00bp\00\00-
1619 S-1-5-21-4052121579-2079768045-1474639452-502"
1622 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
1623 data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
1626 key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
1627 data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
1630 key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
1631 data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
1632 S-1-5-21-4052121579-2079768045-1474639452-502-
1633 S-1-5-21-4052121579-2079768045-1474639452-513"
1637 Now all is revealed. Your curiosity, as well as that of those with you, has been put at ease.
1638 May this server serve well all who happen upon it.
1641 <smbconfexample id="ch9-adssdm">
1642 <title>Samba Domain Member &smb.conf; File for Active Directory Membership</title>
1643 <smbconfcomment>Global parameters</smbconfcomment>
1644 <smbconfsection name="[global]"/>
1645 <smbconfoption name="unix charset">LOCALE</smbconfoption>
1646 <smbconfoption name="workgroup">LONDON</smbconfoption>
1647 <smbconfoption name="realm">LONDON.ABMAS.BIZ</smbconfoption>
1648 <smbconfoption name="server string">Samba 3.0.12</smbconfoption>
1649 <smbconfoption name="security">ADS</smbconfoption>
1650 <smbconfoption name="username map">/etc/samba/smbusers</smbconfoption>
1651 <smbconfoption name="log level">1</smbconfoption>
1652 <smbconfoption name="syslog">0</smbconfoption>
1653 <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
1654 <smbconfoption name="max log size">50</smbconfoption>
1655 <smbconfoption name="printcap name">CUPS</smbconfoption>
1656 <smbconfoption name="ldap ssl">no</smbconfoption>
1657 <smbconfoption name="idmap uid">10000-20000</smbconfoption>
1658 <smbconfoption name="idmap gid">10000-20000</smbconfoption>
1659 <smbconfoption name="template primary group">"Domain Users"</smbconfoption>
1660 <smbconfoption name="template shell">/bin/bash</smbconfoption>
1661 <smbconfoption name="winbind separator">+</smbconfoption>
1662 <smbconfoption name="printing">cups</smbconfoption>
1664 <smbconfsection name="[homes]"/>
1665 <smbconfoption name="comment">Home Directories</smbconfoption>
1666 <smbconfoption name="valid users">%S</smbconfoption>
1667 <smbconfoption name="read only">No</smbconfoption>
1668 <smbconfoption name="browseable">No</smbconfoption>
1670 <smbconfsection name="[printers]"/>
1671 <smbconfoption name="comment">SMB Print Spool</smbconfoption>
1672 <smbconfoption name="path">/var/spool/samba</smbconfoption>
1673 <smbconfoption name="guest ok">Yes</smbconfoption>
1674 <smbconfoption name="printable">Yes</smbconfoption>
1675 <smbconfoption name="browseable">No</smbconfoption>
1677 <smbconfsection name="[print$]"/>
1678 <smbconfoption name="comment">Printer Drivers</smbconfoption>
1679 <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
1680 <smbconfoption name="admin users">root, Administrator</smbconfoption>
1681 <smbconfoption name="write list">root</smbconfoption>
1687 <title>UNIX/Linux Client Domain Member</title>
1690 <primary>user credentials</primary>
1692 So far this chapter has been mainly concerned with the provision of file and print
1693 services for Domain Member servers. However, an increasing number of UNIX/Linux
1694 workstations are being installed that do not act as file or print servers to anyone
1695 other than a single desktop user. The key demand for desktop systems is to be able
1696 to log onto any UNIX/Linux or Windows desktop using the same network user credentials.
1700 <primary>Single Sign-On</primary>
1703 The ability to use a common set of user credential across a variety of network systems
1704 is generally regarded as a Single Sign-On (SOS) solution. SOS systems are sold by a
1705 large number of vendors and include a range of technologies such as:
1714 Federated directory provisioning
1718 Meta-directory server solutions
1722 Replacement authentication systems
1727 <primary>Identity management</primary>
1729 There are really only three solutions that provide integrated authentication and
1730 user Identity management facilities:
1735 Samba Winbind (free)
1739 <ulink url="http://www.padl.com">PADL</ulink> PAM and LDAP Tools (free)
1743 <ulink url="http://www.vintela.com">Vintela</ulink> Authentication Services (Commercial)
1748 The following guidelines are pertinent in respect of the deployment of winbind-based authentication
1749 and Identity resolution with the express purpose of allowing users to log onto UNIX/Linux desktops
1750 using Windows network Domain user credentials (username and password).
1754 You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed
1755 systems logons (SSO) providing user and group accounts are stored in an LDAP directory. This
1756 provides logon services for UNIX/Linux users, while Windows users obtain their sign-on
1757 support via Samba-3.
1761 <primary>Windows Services for UNIX</primary>
1764 On the other hand, if the authentication and Identity resolution backend must be provided by
1765 a Windows NT4 style Domain or from an Active Directory Domain that does not have the Microsoft
1766 Windows Services for UNIX (SUS) installed, winbind is your best friend. Specific guidance for these
1767 situations now follows.
1771 <primary>PAM</primary>
1772 </indexterm><indexterm>
1773 <primary>Identity resolution</primary>
1774 </indexterm><indexterm>
1775 <primary>NSS</primary>
1777 To permit users to log onto a Linux system using Windows network credentials, you need to
1778 configure Identity resolution (NSS) and PAM. This means that the basic steps include those
1779 outlined above with the addition of PAM configuration. Given that most workstations (desktop/client)
1780 usually do not need to provide file and print services to a group of users, the configuration
1781 of shares and printers is generally less important. Often this allows the share specifications
1782 to be entirely removed from the &smb.conf; file. That is obviously an administrator decision.
1786 <title>NT4 Domain Member</title>
1789 The following steps provide a Linux system that users can log onto using
1790 Windows NT4 Domain (or Samba-3) Domain network credentials:
1795 Follow the steps outlined in <link linkend="wdcsdm"/> and ensure that
1796 all validation tests function as shown.
1800 Identify what services users must log onto. On Red Hat Linux, if it is
1801 intended that the user shall be given access to all services, it may be
1802 most expeditious to simply configure the file
1803 <filename>/etc/pam.d/system-auth</filename>.
1807 Carefully make a backup copy of all PAM configuration files before you
1808 begin making changes. If you break the PAM configuration, please note
1809 that you may need to use an emergency boot process to recover your Linux
1810 system. It is possible to break the ability to log into the system if
1811 PAM files are incorrectly configured. The entire directory
1812 <filename>/etc/pam.d</filename> should be backed up to a safe location.
1816 If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
1817 so it matches <link linkend="ch9-pamwnbdlogin"/>.
1821 To provide the ability to log onto the graphical desktop interface, you must edit
1822 the files <filename>gdm</filename> and <filename>xdm</filename> in the
1823 <filename>/etc/pam.d</filename> directory.
1827 Edit only one file at a time. Carefully validate its operation before attempting
1828 to reboot the machine.
1835 <title>ADS Domain Member</title>
1838 This procedure should be followed to permit a Linux network client (workstation/desktop)
1839 to permit users to log on using Microsoft Active Directory based user credentials.
1844 Follow the steps outlined in <link linkend="adssdm"/> and ensure that
1845 all validation tests function as shown.
1849 Identify what services users must log onto. On Red Hat Linux, if it is
1850 intended that the user shall be given access to all services, it may be
1851 most expeditious to simply configure the file
1852 <filename>/etc/pam.d/system-auth</filename> as shown in <link linkend="ch9-rhsysauth"/>.
1856 Carefully make a backup copy of all PAM configuration files before you
1857 begin making changes. If you break the PAM configuration, please note
1858 that you may need to use an emergency boot process to recover your Linux
1859 system. It is possible to break the ability to log into the system if
1860 PAM files are incorrectly configured. The entire directory
1861 <filename>/etc/pam.d</filename> should be backed up to a safe location.
1865 If you require only console login support, edit the <filename>/etc/pam.d/login</filename>
1866 so it matches <link linkend="ch9-pamwnbdlogin"/>.
1870 To provide the ability to log onto the graphical desktop interface, you must edit
1871 the files <filename>gdm</filename> and <filename>xdm</filename> in the
1872 <filename>/etc/pam.d</filename> directory.
1876 Edit only one file at a time. Carefully validate its operation before attempting
1877 to reboot the machine.
1883 <example id="ch9-pamwnbdlogin">
1884 <title>SUSE: PAM <filename>login</filename> Module Using Winbind</title>
1889 auth sufficient pam_unix2.so nullok
1890 auth sufficient pam_winbind.so use_first_pass use_authtok
1891 auth required pam_securetty.so
1892 auth required pam_nologin.so
1893 auth required pam_env.so
1894 auth required pam_mail.so
1895 account sufficient pam_unix2.so
1896 account sufficient pam_winbind.so user_first_pass use_authtok
1897 password required pam_pwcheck.so nullok
1898 password sufficient pam_unix2.so nullok use_first_pass use_authtok
1899 password sufficient pam_winbind.so use_first_pass use_authtok
1900 session sufficient pam_unix2.so none
1901 session sufficient pam_winbind.so use_first_pass use_authtok
1902 session required pam_limits.so
1906 <example id="ch9-pamwbndxdm">
1907 <title>SUSE: PAM <filename>xdm</filename> Module Using Winbind</title>
1909 # /etc/pam.d/gdm (/etc/pam.d/xdm)
1912 auth sufficient pam_unix2.so nullok
1913 auth sufficient pam_winbind.so use_first_pass use_authtok
1914 account sufficient pam_unix2.so
1915 account sufficient pam_winbind.so use_first_pass use_authtok
1916 password sufficient pam_unix2.so
1917 password sufficient pam_winbind.so use_first_pass use_authtok
1918 session sufficient pam_unix2.so
1919 session sufficient pam_winbind.so use_first_pass use_authtok
1920 session required pam_dev perm.so
1921 session required pam_resmgr.so
1925 <example id="ch9-rhsysauth">
1926 <title>Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind</title>
1929 auth required /lib/security/$ISA/pam_env.so
1930 auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
1931 auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
1932 auth required /lib/security/$ISA/pam_deny.so
1934 account required /lib/security/$ISA/pam_unix.so
1935 account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
1937 password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
1938 # Note: The above line is complete. There is nothing following the '='
1939 password sufficient /lib/security/$ISA/pam_unix.so \
1940 nullok use_authtok md5 shadow
1941 password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
1942 password required /lib/security/$ISA/pam_deny.so
1944 session required /lib/security/$ISA/pam_limits.so
1945 session sufficient /lib/security/$ISA/pam_unix.so
1946 session sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
1953 <title>Key Points Learned</title>
1956 The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you
1957 learned how to integrate such servers so that the UID/GID mappings they use can be consistent
1958 across all Domain Member servers. You also discovered how to implement the ability to use Samba
1959 or Windows Domain account credentials to log onto a UNIX/Linux client.
1963 The following are key points noted:
1968 Domain Controllers are always authoritative for the Domain.
1972 Domain Members may have local accounts and must be able to resolve the identity of
1973 Domain user accounts. Domain user account identity must map to a local UID/GID. That
1974 local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data
1975 across all Domain Member machines.
1979 Resolution of user and group identities on Domain Member machines may be implemented
1980 using direct LDAP services or using winbind.
1984 On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for Identity management
1985 and PAM is responsible for authentication of logon credentials (user name and password).
1994 <title>Questions and Answers</title>
1997 The following questions were obtained from the mailing list and also from private discussions
1998 with Windows network administrators.
2001 <qandaset defaultlabel="chap09qa" type="number">
2006 We use NIS for all UNIX accounts. Why do we need winbind?
2013 <primary>NIS</primary>
2014 </indexterm><indexterm>
2015 <primary>encrypted passwords</primary>
2016 </indexterm><indexterm>
2017 <primary>smbpasswd</primary>
2018 </indexterm><indexterm>
2019 <primary>tdbsam</primary>
2020 </indexterm><indexterm>
2021 <primary>passdb backend</primary>
2022 </indexterm><indexterm>
2023 <primary>Winbind</primary>
2025 You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted
2026 passwords that need to be stored in one of the acceptable passdb backends.
2027 Your choice of backend is limited to <parameter>smbpasswd</parameter> or
2028 <parameter>tdbsam</parameter>. Winbind is needed to handle the resolution of
2029 SIDs from trusted domains to local UID/GID values.
2033 <primary>winbind trusted domains only</primary>
2034 </indexterm><indexterm>
2035 <primary>getpwnam()</primary>
2037 On a Domain Member server, you effectively map Windows Domain users to local users
2038 that are in your NIS database by specifying the <parameter>winbind trusted domains
2039 only</parameter>. This causes user and group account lookups to be routed via
2040 the <command>getpwnam()</command> family of systems calls. On an NIS-enabled client,
2041 this pushes the resolution of users and groups out through NIS.
2045 As a general rule, it is always a good idea to run winbind on all Samba servers.
2055 Our IT management people do not like LDAP, but are looking at Microsoft Active Directory.
2056 Which is better?<indexterm>
2057 <primary>Active Directory</primary>
2065 <primary>LDAP</primary>
2066 <secondary>server</secondary>
2067 </indexterm><indexterm>
2068 <primary>Kerberos</primary>
2069 </indexterm><indexterm>
2070 <primary>schema</primary>
2072 Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos
2073 infrastructure. Most IT managers who object to LDAP do so because of the fact that
2074 an LDAP server is most often supplied as a raw tool that needs to be configured, and
2075 for which the administrator must create the schema, create the administration tools and
2076 devise the backup and recovery facilities in a site dependent manner. LDAP servers
2077 in general are seen as a high-energy, high-risk facility.
2081 <primary>management</primary>
2083 Microsoft Active Directory by comparison is easy to install, configure, and
2084 is supplied with all tools necessary to implement and manage the directory. For sites
2085 that lack a lot of technical competence, Active Directory is a good choice. For sites
2086 that have the technical competence to handle Active Directory well, LDAP is a good
2087 alternative. The real issue that needs to be addressed is what type of solution does
2088 the site want? If management wants a choice to use an alternative, they may want to
2089 consider the options. On the other hand, if management just wants a solution that works,
2090 Microsoft Active Directory is a good solution.
2100 We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible
2101 to use NIS in place of LDAP?
2108 <primary>NIS</primary>
2109 </indexterm><indexterm>
2110 <primary>LDAP</primary>
2111 </indexterm><indexterm>
2112 <primary>encrypted passwords</primary>
2113 </indexterm><indexterm>
2114 <primary>synchronized</primary>
2115 </indexterm><indexterm>
2116 <primary>secure account password</primary>
2117 </indexterm><indexterm>
2118 <primary>PDC</primary>
2119 </indexterm><indexterm>
2120 <primary>BDC</primary>
2122 Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping
2123 the Windows (SMB) encrypted passwords database correctly synchronized across the entire
2124 network. Workstations (Windows client machines) periodically change their Domain
2125 Membership secure account password. How can you keep changes that are on remote BDCs
2126 synchronized on the PDC?
2130 <primary>centralized storage</primary>
2131 </indexterm><indexterm>
2132 <primary>management</primary>
2133 </indexterm><indexterm>
2134 <primary>network Identities</primary>
2136 LDAP is a more elegant solution because it permits centralized storage and management
2137 of all network Identities (user, group and machine accounts) together with all information
2138 Samba needs to provide to network clients and their users.
2148 Are you suggesting that users should not log onto a Domain Member server? If so, why?
2155 <primary>security</primary>
2156 </indexterm><indexterm>
2157 <primary>data</primary>
2158 <secondary>integrity</secondary>
2159 </indexterm><indexterm>
2160 <primary>mapped drives</primary>
2162 Many UNIX administrators mock the model that the Personal Computer industry has adopted
2163 as normative since the early days of Novell Netware. One may well argue that the old
2164 perception of the necessity to keep users off file and print servers was a result of
2165 fears concerning the security and integrity of data. It was a simple and generally
2166 effective measure to keep users away from servers, except through mapped drives.
2170 <primary>user logins</primary>
2171 </indexterm><indexterm>
2172 <primary>risk</primary>
2173 </indexterm><indexterm>
2174 <primary>user errors</primary>
2175 </indexterm><indexterm>
2176 <primary>strategy</primary>
2177 </indexterm><indexterm>
2178 <primary>policy</primary>
2180 UNIX administrators are fully correct in asserting that UNIX servers and workstations
2181 are identical in terms of the software that is installed. They correctly assert that
2182 in a well secured environment it is safe to store files on a system that has hundreds
2183 of users. But all network administrators must factor into the decision to allow or
2184 reject general user logins to a UNIX system that is principally a file and print
2185 server. One must take account of the risk to operations through simple user errors.
2186 Only then can one begin to appraise the best strategy and adopt a site-specific
2187 policy that best protects the needs of users and of the organization alike.
2191 <primary>system level logins</primary>
2193 From experience, it is my recommendation to keep general system level logins to a
2194 practical minimum and to eliminate them if possible. This should not be taken as a
2195 hard rule, though. The better question is, what works best for the site?
2205 <primary>winbind enable local accounts</primary>
2206 </indexterm><indexterm>
2207 <primary>/etc/passwd</primary>
2208 </indexterm><indexterm>
2209 <primary>options list</primary>
2210 </indexterm><indexterm>
2211 <primary>ACL</primary>
2212 </indexterm><indexterm>
2213 <primary>share</primary>
2215 In my &smb.conf; file, I enabled the parameter <parameter>winbind enable local accounts
2216 </parameter> on all Domain Member servers, but it does not work. The accounts I put in
2217 <filename>/etc/passwd</filename> do not show up in the options list when I try to set an
2218 ACL on a share. What have I done wrong?
2225 <primary>local users</primary>
2226 </indexterm><indexterm>
2227 <primary>local groups</primary>
2228 </indexterm><indexterm>
2229 <primary>UNIX account</primary>
2230 </indexterm><indexterm>
2231 <primary>getpwnam()</primary>
2232 </indexterm><indexterm>
2233 <primary>getgrgid()</primary>
2234 </indexterm><indexterm>
2235 <primary>Identity resolution</primary>
2236 </indexterm><indexterm>
2237 <primary>failure</primary>
2238 </indexterm><indexterm>
2239 <primary>Domain</primary>
2241 The manual page for this &smb.conf; file parameter clearly says, <quote>This parameter
2242 controls whether or not winbindd will act as a stand in replacement for the various
2243 account management hooks in smb.conf (for example, add user script). If enabled, winbindd
2244 will support the creation of local users and groups as another source of UNIX account
2245 information available via getpwnam() or getgrgid(), etc...</quote> By default this
2246 parameter is already enabled; therefore, the action you are seeing is a result of a failure
2247 of Identity resolution in the Domain.
2251 <primary>Domain logons</primary>
2252 </indexterm><indexterm>
2253 <primary>Identity resolution</primary>
2254 </indexterm><indexterm>
2255 <primary>Domain</primary>
2256 <secondary>user</secondary>
2257 </indexterm><indexterm>
2258 <primary>Domain</primary>
2259 <secondary>group</secondary>
2260 </indexterm><indexterm>
2261 <primary>UID</primary>
2262 </indexterm><indexterm>
2263 <primary>GID</primary>
2265 These are the accounts that are available for Windows network Domain logons. Providing
2266 Identity resolution has been correctly configured on the Domain Controllers, as well as
2267 on Domain Member servers. The Domain user and group identities automatically map
2268 to a valid local UID and GID pair.
2278 <primary>trusted domains</primary>
2279 </indexterm><indexterm>
2280 <primary>domain</primary>
2281 <secondary>trusted</secondary>
2282 </indexterm><indexterm>
2283 <primary>winbind trusted domains only</primary>
2284 </indexterm><indexterm>
2285 <primary>domain members</primary>
2287 We want to ensure that only users from our own domain plus from trusted domains can use our
2288 Samba servers. In the &smb.conf; file on all servers, we have enabled the <parameter>winbind
2289 trusted domains only</parameter> parameter. We now find that users from trusted domains
2290 cannot access our servers, and users from Windows clients that are not domain members
2291 can also access our servers. Is this a Samba bug?
2298 <primary>distributed</primary>
2299 </indexterm><indexterm>
2300 <primary>NIS</primary>
2301 </indexterm><indexterm>
2302 <primary>rsync</primary>
2303 </indexterm><indexterm>
2304 <primary>LDAP</primary>
2305 </indexterm><indexterm>
2306 <primary>winbindd</primary>
2307 </indexterm><indexterm>
2308 <primary>/etc/passwd</primary>
2310 The manual page for this <parameter>winbind trusted domains only</parameter> parameter says,
2311 <quote>This parameter is designed to allow Samba servers that are members of a Samba controlled
2312 domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users
2313 in the hosts primary domain. Therefore, the user <constant>SAMBA\user1</constant> would be
2314 mapped to the account <constant>user1</constant> in <filename>/etc/passwd</filename> instead
2315 of allocating a new UID for him or her.</quote> This would clearly suggest that you are trying
2316 to use this parameter inappropriately.
2320 <primary>valid users</primary>
2322 A far better solution would be to use the <parameter>valid users</parameter> by specifying
2323 precisely the Domain users and groups that should be permitted access to the shares. You could,
2324 for example, set the following parameters:
2327 path = /export/demodata
2328 valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"
2340 What are the benefits of using LDAP for my Domain Member servers?
2347 <primary>LDAP</primary>
2348 </indexterm><indexterm>
2349 <primary>benefit</primary>
2350 </indexterm><indexterm>
2351 <primary>UID</primary>
2352 </indexterm><indexterm>
2353 <primary>GID</primary>
2354 </indexterm><indexterm>
2355 <primary>Domain Controllers</primary>
2356 </indexterm><indexterm>
2357 <primary>Domain Member servers</primary>
2358 </indexterm><indexterm>
2359 <primary>copy</primary>
2360 </indexterm><indexterm>
2361 <primary>replicate</primary>
2362 </indexterm><indexterm>
2363 <primary>identity</primary>
2365 The key benefit of using LDAP is that the UID of all users and the GID of all groups
2366 are globally consistent on Domain Controllers as well as on Domain Member servers.
2367 This means that it is possible to copy/replicate files across servers without
2372 <primary>Identity resolution</primary>
2373 </indexterm><indexterm>
2374 <primary>winbind</primary>
2375 </indexterm><indexterm>
2376 <primary>IDMAP backend</primary>
2377 </indexterm><indexterm>
2378 <primary>LDAP</primary>
2379 </indexterm><indexterm>
2380 <primary>Domain Controllers</primary>
2381 </indexterm><indexterm>
2382 <primary>Domain Member</primary>
2383 <secondary>servers</secondary>
2384 </indexterm><indexterm>
2385 <primary>Posix</primary>
2386 </indexterm><indexterm>
2387 <primary>account information</primary>
2389 When use is made of account Identity resolution via winbind, even when an IDMAP backend
2390 is stored in LDAP, the UID/GID on Domain Member servers is consistent, but differs
2391 from the ID that the user/group has on Domain Controllers. The winbind allocated UID/GID
2392 that is stored in LDAP (or locally) will be in the numeric range specified in the <parameter>
2393 idmap uid/gid</parameter> in the &smb.conf; file. On Domain Controllers, the UID/GID is
2394 that of the Posix value assigned in the LDAP directory as part of the Posix account information.
2404 Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into
2405 my DNS configuration?
2412 <primary>DNS</primary>
2413 <secondary>configuration</secondary>
2414 </indexterm><indexterm>
2415 <primary>DNS</primary>
2416 <secondary>lookup</secondary>
2417 </indexterm><indexterm>
2418 <primary>hosts</primary>
2419 </indexterm><indexterm>
2420 <primary>/etc/nsswitch.conf</primary>
2421 </indexterm><indexterm>
2422 <primary>NSS</primary>
2423 </indexterm><indexterm>
2424 <primary>/etc/hosts</primary>
2425 </indexterm><indexterm>
2426 <primary>WINS</primary>
2427 <secondary>lookup</secondary>
2429 Samba depends on correctly functioning resolution of host names to their IP address. Samba
2430 makes no direct DNS lookup calls, but rather redirects all name to address calls via the
2431 <command>getXXXbyXXX()</command> function calls. The configuration of the <constant>hosts</constant>
2432 entry in the NSS <filename>/etc/nsswitch.conf</filename> file determines how the underlying
2433 resolution process is implemented. If the <constant>hosts</constant> entry in your NSS
2436 hosts: files dns wins
2438 This means that a host name lookup first tries the <filename>/etc/hosts</filename>.
2439 If this fails to resolve, it attempts a DNS lookup and if that fails, it tries a
2444 <primary>NetBIOS</primary>
2445 </indexterm><indexterm>
2446 <primary>TCP/IP</primary>
2447 </indexterm><indexterm>
2448 <primary>name resolution</primary>
2450 The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has
2451 been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS
2452 is the preferred name resolution technology. This usually makes most sense when Samba
2453 is a client of an Active Directory Domain, where NetBIOS use has been disabled. In this
2454 case, the Windows 200x auto-registers all locator records it needs with its own DNS
2465 Our Windows 2003 Server Active Directory Domain runs with NetBIOS disabled. Can we
2466 use Samba-3 with that configuration?
2483 <primary>net</primary>
2484 <secondary>ads</secondary>
2485 <tertiary>join</tertiary>
2486 </indexterm><indexterm>
2487 <primary>net</primary>
2488 <secondary>rpc</secondary>
2489 <tertiary>join</tertiary>
2491 When I tried to execute <quote>net ads join</quote>, I got no output. It did not work, so
2492 I think that it failed. I then executed <quote>net rpc join</quote> and that worked fine.
2493 That is okay, isn't it?
2500 <primary>Kerberos</primary>
2501 </indexterm><indexterm>
2502 <primary>authentication</primary>
2504 No. This is not okay. It means that your Samba-3 client has joined the ADS Domain as
2505 a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication.
git.samba.org / tprouty / samba.git / blob