Adding missed comment mark-up.
[import/samba-docs-svnimport.git] / Samba3-ByExample / SBE-KerberosFastStart.xml
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="kerberos">
4   <title>Active Directory, Kerberos, and Security</title>
5
6     <para><indexterm>
7         <primary>experiment</primary>
8       </indexterm>
9         By this point in the book, you have been exposed to many Samba-3 features and capabilities.
10         More importantly, if you have implemented the examples given, you are well on your way to becoming 
11         a Samba-3 networking guru who knows a lot about Microsoft Windows. If you have taken the time to 
12         practice, you likely have thought of improvements and scenarios with which you can experiment. You 
13         are rather well plugged in to the many flexible ways Samba can be used.
14         </para>
15
16     <para><indexterm>
17         <primary>criticism</primary>
18       </indexterm>
19         This is a book about Samba-3. Understandably, its intent is to present it in a positive light. 
20         The casual observer might conclude that this book is one-eyed about Samba. It is &smbmdash; what 
21         would you expect? This chapter exposes some criticisms that have been raised concerning 
22         the use of Samba. For each criticism, there are good answers and appropriate solutions.
23         </para>
24
25         <para>
26         Some criticism always comes from deep inside ranks that one would expect to be supportive of a particular 
27         decision. Criticism can be expected from the outside. Let's see how the interesting dynamic of 
28         criticism develops with respect to Abmas.
29         </para>
30
31     <para><indexterm>
32         <primary>straw-man</primary>
33       </indexterm>
34         This chapter provides a shameless self-promotion of Samba-3. The objections raised were not pulled
35         out of thin air. They were drawn from comments made by Samba users and from criticism during 
36         discussions with Windows network administrators. The tone of the objections reflects as closely 
37         as possible that of the original. The case presented is a straw-man example that is designed to 
38         permit each objection to be answered as it might occur in real life.
39         </para>
40
41 <sect1>
42         <title>Introduction</title>
43
44       <para><indexterm>
45           <primary>acquisitions</primary>
46         </indexterm><indexterm>
47           <primary>risk</primary>
48         </indexterm><indexterm>
49           <primary>assessment</primary>
50         </indexterm><indexterm>
51           <primary>Active Directory</primary>
52         </indexterm><indexterm>
53           <primary>Windows 2003 Serve</primary>
54         </indexterm>
55         Abmas is continuing its meteoric growth with yet further acquisitions. The investment community took
56         note of the spectacular projection of Abmas onto the global business stage. Abmas is building an
57         interesting portfolio of companies that includes accounting services, financial advice, investment
58         portfolio management, property insurance, risk assessment, and the recent addition of a a video rental
59         business. The pieces do not always appear to fit together, but Mr. Meany is certainly executing an 
60         interesting business growth and development plan. Abmas Video Rentals was recently acquired. 
61         During the time that the acquisition was closing, the Video Rentals business upgraded its Windows 
62         NT4-based network to Windows 2003 Server and Active Directory.
63         </para>
64
65       <para><indexterm>
66           <primary>Active Directory</primary>
67         </indexterm>
68         You have accepted the fact that Abmas Video Rentals will use Microsoft Active Directory.
69         The IT team, led by Stan Soroka, is committed to Samba-3 and to maintaining a uniform technology platform. 
70         Stan Soroka's team voiced its disapproval over the decision to permit this business to continue to 
71         operate with a solution that is viewed by Christine and her group as <quote>an island of broken 
72         technologies.</quote> This comment was made by one of Christine's staff as they were installing a new 
73         Samba-3 server at the new business.
74         </para>
75
76
77       <para><indexterm>
78           <primary>consultant</primary>
79         </indexterm><indexterm>
80           <primary>hypothetical</primary>
81         </indexterm>
82         Abmas Video Rentals' head of IT heard of this criticism. He was offended that a junior engineer
83         should make such a comment. He felt that he had to prepare in case he might be criticized for his 
84         decision to use Active Directory. He decided he would defend his decision by hiring the services 
85         of an outside security systems consultant to report<footnote>This report is entirely fictitious. 
86         Any resemblance to a factual report is purely coincidental.</footnote> on his unit's operations 
87         and to investigate the role of Samba at his site. Here are key extracts from this hypothetical 
88         report:
89         </para>
90
91       <blockquote><para><indexterm>
92             <primary>vulnerabilities</primary>
93           </indexterm><indexterm>
94             <primary>integrity</primary>
95           </indexterm><indexterm>
96             <primary>practices</primary>
97           </indexterm><indexterm>
98             <primary>Active Directory</primary>
99           </indexterm>
100         ... the implementation of Microsoft Active Directory at the Abmas Video Rentals, Bamingsham site,
101          has been examined. We find no evidence to support a notion that vulnerabilities exist at your site.  
102         ... we took additional steps to validate the integrity of the installation and operation of Active 
103         Directory and are pleased that your staff are following sound practices.
104         </para>
105
106         <para>
107         ...
108         </para>
109
110         <para><indexterm>
111             <primary>accounts</primary>
112             <secondary>user</secondary>
113           </indexterm><indexterm>
114             <primary>accounts</primary>
115             <secondary>group</secondary>
116           </indexterm><indexterm>
117             <primary>Backup</primary>
118           </indexterm><indexterm>
119             <primary>disaster recovery</primary>
120           </indexterm><indexterm>
121             <primary>validated</primary>
122           </indexterm><indexterm>
123             <primary>off-site storage</primary>
124           </indexterm>
125         User and group accounts, and respective privileges, have been well thought out. File system shares are
126         appropriately secured. Backup and disaster recovery plans are well managed and validated regularly, and
127         effective off-site storage practices are considered to exceed industry norms.
128         </para>
129
130         <para><indexterm>
131             <primary>compromise</primary>
132           </indexterm><indexterm>
133             <primary>secure</primary>
134           </indexterm><indexterm>
135             <primary>network</primary>
136             <secondary>secure</secondary>
137           </indexterm>
138         Your staff are justifiably concerned that the use of Samba may compromise their good efforts to maintain
139         a secure network. 
140         </para>
141
142         <para><indexterm>
143             <primary>winbind</primary>
144           </indexterm><indexterm>
145             <primary>security</primary>
146           </indexterm><indexterm>
147             <primary>secure</primary>
148           </indexterm><indexterm>
149             <primary>network</primary>
150             <secondary>management</secondary>
151           </indexterm>
152         The recently installed Linux file and application server uses a tool called <command>winbind</command> 
153         that is indiscriminate about security. All user accounts in Active Directory can be used to access data 
154         stored on the Linux system. We are alarmed that secure information is accessible to staff who should 
155         not even be aware that it exists. We share the concerns of your network management staff who have gone 
156         to great lengths to set fine-grained controls that limit information access to those who need access. 
157         It seems incongruous to us that Samba winbind should be permitted to be used considering that it voids this fine work.
158         </para>
159
160         <para><indexterm>
161             <primary>isolated</primary>
162           </indexterm><indexterm>
163             <primary>firewall</primary>
164           </indexterm><indexterm>
165             <primary>best practices</primary>
166           </indexterm>
167         Graham Judd [head of network administration] has locked down the security of all systems and is following 
168         the latest Microsoft guidelines. ... null session connections have been disabled ... the internal network 
169         is isolated from the outside world, the [product name removed] firewall is under current contract 
170         maintenance support from [the manufacturer].  ... our attempts to penetrate security of your systems 
171         failed to find problems common to Windows networking sites. We commend your staff on their attention to 
172         detail and for following Microsoft recommended best practices.
173         </para>
174
175         <para>
176         ...
177         </para>
178
179         <para><indexterm>
180             <primary>security</primary>
181           </indexterm><indexterm>
182             <primary>disable</primary>
183           </indexterm><indexterm>
184             <primary>essential</primary>
185           </indexterm><indexterm>
186             <primary>trusted computing</primary>
187           </indexterm>
188         Regarding the use of Samba, we offer the following comments: Samba is in use in nearly half of
189         all sites we have surveyed. ... It is our opinion that Samba offers no better security than Microsoft
190         ... what worries us regarding Samba is the need to disable essential Windows security features such as
191         secure channel support, digital sign'n'seal on all communication traffic, and running Active Directory in
192         mixed mode so that Samba clients and servers can authenticate all of it. Additionally, we are concerned that
193         Samba is not at the full capabilities of Microsoft Windows NT4 server. Microsoft has moved well beyond that
194         with trusted computing initiatives that the Samba developers do not participate in.
195         </para>
196
197         <para><indexterm>
198             <primary>integrity</primary>
199           </indexterm><indexterm>
200             <primary>hackers</primary>
201           </indexterm><indexterm>
202             <primary>accountable</primary>
203           </indexterm><indexterm>
204             <primary>flaws</primary>
205           </indexterm><indexterm>
206             <primary>updates</primary>
207           </indexterm><indexterm>
208             <primary>bug fixes</primary>
209           </indexterm><indexterm>
210             <primary>alarm</primary>
211           </indexterm>
212         One wonders about the integrity of an open source program that is developed by a team of hackers 
213         who cannot be held accountable for the flaws in their code. The sheer number of updates and bug
214         fixes they have released should ring alarm bells in any business.
215         </para>
216
217         <para><indexterm>
218             <primary>employment</primary>
219           </indexterm><indexterm>
220             <primary>jobs</primary>
221           </indexterm><indexterm>
222             <primary>risk</primary>
223           </indexterm>
224         Another factor that should be considered is that buying Microsoft products and services helps to 
225         provide employment in the IT industry. Samba and Open Source software place those jobs at risk.
226         </para></blockquote>
227
228       <para><indexterm>
229           <primary>Active Directory</primary>
230         </indexterm><indexterm>
231           <primary>independent expert</primary>
232         </indexterm>
233         This is also a challenge to rise above the trouble spot. You call Stan's team together for a simple 
234         discussion, but it gets further out of hand.  When you return to your office, you find the following 
235         email in your in-box:
236         </para>
237
238         <para>
239         Good afternoon,
240         </para>
241
242         <blockquote><attribution>Stan</attribution><para>
243         I apologize for the leak of internal discussions to the new business. It reflects poorly on our 
244         professionalism and has put you in an unpleasant position. I regret the incident.
245         </para>
246
247         <para>
248         I also wish to advise that two of the recent recruits want to implement Kerberos authentication 
249         across all systems. I concur with the desire to improve security. One of the new guys who is championing
250         the move to Kerberos was responsible for the comment that caused the embarrassment.
251         </para>
252
253         <para><indexterm>
254             <primary>Kerberos</primary>
255           </indexterm><indexterm>
256             <primary>OpenLDAP</primary>
257           </indexterm><indexterm>
258             <primary>Active Directory</primary>
259           </indexterm><indexterm>
260             <primary>consultant</primary>
261           </indexterm>
262         I am experiencing difficulty in handling the sharp push for Kerberos. He claims that Kerberos, OpenLDAP, 
263         plus Samba-3 will seamlessly replace Microsoft Active Directory. I am a little out of my depth with respect 
264         to the feasibility of such a move, but have taken steps to pull both of them into line. With your consent, 
265         I would like to hire the services of a well-known Samba consultant to set the record straight.
266         </para>
267
268         <para><indexterm>
269             <primary>criticism</primary>
270           </indexterm><indexterm>
271             <primary>policy</primary>
272           </indexterm><indexterm>
273             <primary>Windows Servers</primary>
274           </indexterm><indexterm>
275             <primary>Active Directory</primary>
276           </indexterm><indexterm>
277             <primary>budgetted</primary>
278           </indexterm><indexterm>
279             <primary>financial responsibility</primary>
280           </indexterm>
281         I intend to use this report to answer the criticism raised and would like to establish a policy that we
282         will approve the use of Microsoft Windows Servers (and Active Directory) subject to all costs being covered 
283         out of the budget of the division that wishes to go its own way. I propose that dissenters will still remain
284         responsible to meet the budgeted contribution to IT operations as a whole. I believe we should not coerce 
285         use of any centrally proposed standards, but make all noncompliance the financial responsibility of the 
286         out-of-step division. Hopefully, this will encourage all divisions to walk with us and not alone.
287         </para></blockquote>
288
289         <sect2>
290                 <title>Assignment Tasks</title>
291
292                 <para>
293                 You agreed with Stan's recommendations and hired a consultant to help defuse the powder
294                 keg. The consultant's task is to provide a tractable answer to each of the issues raised. The consultant must be able
295                 to support his or her claims, keep emotions to the side, and answer technically.
296                 </para>
297
298         </sect2>
299 </sect1>
300
301 <sect1>
302         <title>Dissection and Discussion</title>
303
304       <para><indexterm>
305           <primary>tool</primary>
306         </indexterm><indexterm>
307           <primary>benefit</primary>
308         </indexterm><indexterm>
309           <primary>choice</primary>
310         </indexterm><indexterm>
311           <primary>consultant</primary>
312         </indexterm><indexterm>
313           <primary>installation</primary>
314         </indexterm><indexterm>
315           <primary>income</primary>
316         </indexterm><indexterm>
317           <primary>employment</primary>
318         </indexterm>
319         Samba-3 is a tool. No one is pounding your door to make you use Samba. That is a choice that you are free to 
320         make or reject. It is likely that your decision to use Samba can greatly benefit your company. 
321         The Samba Team obviously believes that the Samba software is a worthy choice. 
322         If you hire a consultant to assist with the installation and/or deployment of Samba, or if you hire 
323         someone to help manage your Samba installation, you can create income and employment. Alternately, 
324         money saved by not spending in the IT area can be spent elsewhere in the business. All money saved 
325         or spent creates employment.
326         </para>
327
328       <para><indexterm>
329           <primary>economically sustainable</primary>
330         </indexterm><indexterm>
331           <primary>inter-operability</primary>
332         </indexterm><indexterm>
333           <primary>file and print service</primary>
334         </indexterm><indexterm>
335           <primary>cost</primary>
336         </indexterm><indexterm>
337           <primary>alternative</primary>
338         </indexterm>
339         In the long term, the use of Samba must be economically sustainable. In some situations, Samba is adopted
340         purely to provide file and print service interoperability on platforms that otherwise cannot provide 
341         access to data and to printers for Microsoft Windows clients. Samba is used by some businesses to
342         effect a reduction in the cost of providing IT services. Obviously, it is also used by some as an 
343         alternative to the use of a Microsoft file and print serving platforms with no consideration of costs.
344         </para>
345
346       <para><indexterm>
347           <primary>documentation</primary>
348         </indexterm><indexterm>
349           <primary>responsibility</primary>
350         </indexterm><indexterm>
351           <primary>fix</primary>
352         </indexterm><indexterm>
353           <primary>broken</primary>
354         </indexterm>
355         It would be foolish to adopt a technology that might put any data or users at risk. Security affects 
356         everyone. The Samba-Team is fully cognizant of the responsibility they have to their users. 
357         The Samba documentation clearly reveals that full responsibility is accepted to fix anything 
358         that is broken.
359         </para>
360
361       <para><indexterm>
362           <primary>commercial</primary>
363         </indexterm><indexterm>
364           <primary>software</primary>
365         </indexterm><indexterm>
366           <primary>commercial software</primary>
367         </indexterm><indexterm>
368           <primary>End User License Agreement</primary>
369           <see>EULA</see>
370         </indexterm><indexterm>
371           <primary>accountable</primary>
372         </indexterm><indexterm>
373           <secondary>liability</secondary>
374         </indexterm><indexterm>
375           <primary>accepts liability</primary>
376         </indexterm><indexterm>
377           <primary>price paid</primary>
378         </indexterm><indexterm>
379           <primary>product defects</primary>
380         </indexterm><indexterm>
381           <primary>reimburse</primary>
382         </indexterm><indexterm>
383           <primary>extent</primary>
384         </indexterm>
385         There is a mistaken perception in the IT industry that commercial software providers are fully 
386         accountable for the defects in products. Open Source software comes with no warranty, so it is 
387         often assumed that its use confers a higher degree of risk. Everyone should read commercial software 
388         End User License Agreements (EULAs). You should determine what real warranty is offered and the 
389         extent of liability that is accepted. Doing so soon dispels the popular notion that
390         commercial software vendors are willingly accountable for product defects. In many cases, the
391         commercial vendor accepts liability only to reimburse the price paid for the software. 
392         </para>
393
394       <para><indexterm>
395           <primary>consumer</primary>
396         </indexterm><indexterm>
397           <primary>EULA</primary>
398         </indexterm><indexterm>
399           <primary>track record</primary>
400         </indexterm><indexterm>
401           <primary>commercial software</primary>
402         </indexterm><indexterm>
403           <primary>support</primary>
404         </indexterm><indexterm>
405           <primary>vendor</primary>
406         </indexterm>
407         The real issues that a consumer (like you) needs answered are What is the way of escape from technical 
408         problems, and how long will it take? The average problem turnaround time in the Open Source community is 
409         approximately 48 hours. What does the EULA offer? What is the track record in the commercial software 
410         industry? What happens when your commercial vendor decides to cease providing support?
411         </para>
412
413       <para><indexterm>
414           <primary>source code</primary>
415         </indexterm><indexterm>
416           <primary>Open Source</primary>
417         </indexterm><indexterm>
418           <primary>hire</primary>
419         </indexterm><indexterm>
420           <primary>programmer</primary>
421         </indexterm><indexterm>
422           <primary>solve</primary>
423         </indexterm><indexterm>
424           <primary>fix</primary>
425         </indexterm><indexterm>
426           <secondary>problem</secondary>
427         </indexterm>
428         Open Source software at least puts you in possession of the source code. This means that when
429         all else fails, you can hire a programmer to solve the problem.
430         </para>
431
432         <sect2>
433                 <title>Technical Issues</title>
434
435                 <para>
436                 Each issue is now discussed and, where appropriate, example implementation steps are
437                 provided.
438                 </para>
439
440         <variablelist>
441                 <varlistentry>
442                         <term>Winbind and Security</term>
443             <listitem><para><indexterm>
444                   <primary>Winbind</primary>
445                 </indexterm><indexterm>
446                   <primary>Security</primary>
447                 </indexterm><indexterm>
448                   <primary>network</primary>
449                   <secondary>administrators</secondary>
450                 </indexterm><indexterm>
451                   <primary>Domain users</primary>
452                 </indexterm><indexterm>
453                   <secondary>Domain account</secondary>
454                 </indexterm><indexterm>
455                   <primary>credentials</primary>
456                 </indexterm><indexterm>
457                   <primary>Network Neighborhood</primary>
458                 </indexterm><indexterm>
459                   <primary>UNIX/Linux server</primary>
460                 </indexterm><indexterm>
461                   <primary>browse</primary>
462                 </indexterm><indexterm>
463                   <primary>shares</primary>
464                 </indexterm>
465                                 Windows network administrators may be dismayed to find that <command>winbind</command> 
466                                 exposes all domain users so that they may use their domain account credentials to 
467                                 log on to a UNIX/Linux system. The fact that all users in the domain can see the 
468                                 UNIX/Linux server in their Network Neighborhood and can browse the shares on the 
469                                 server seems to excite them further.
470                                 </para>
471
472               <para><indexterm>
473                   <primary>Domain Member server</primary>
474                 </indexterm><indexterm>
475                   <primary>familiar</primary>
476                 </indexterm><indexterm>
477                   <primary>fear</primary>
478                 </indexterm><indexterm>
479                   <primary>unknown</primary>
480                 </indexterm>
481                                 <command>winbind</command> provides for the UNIX/Linux domain member server or 
482                                 client, the same as one would obtain by adding a Microsoft Windows server or 
483                                 client to the domain. The real objection is the fact that Samba is not MS Windows 
484                                 and therefore requires handling a little differently from the familiar Windows systems.
485                                 One must recognize fear of the unknown.
486                                 </para>
487
488               <para><indexterm>
489                   <primary>network administrators</primary>
490                 </indexterm><indexterm>
491                   <primary>recognize</primary>
492                 </indexterm><indexterm>
493                   <primary>winbind</primary>
494                 </indexterm><indexterm>
495                   <primary>over-ride</primary>
496                 </indexterm><indexterm>
497                   <primary>Active Directory</primary>
498                   <secondary>management tools</secondary>
499                 </indexterm><indexterm>
500                   <primary>fears</primary>
501                 </indexterm>
502                                 Windows network administrators need to recognize that <command>winbind</command> does
503                                 not, and cannot, override account controls set using the Active Directory management
504                                 tools. The control is the same. Have no fear.
505                                 </para>
506
507               <para><indexterm>
508                   <primary>ADS Domain</primary>
509                 </indexterm><indexterm>
510                   <primary>account</primary>
511                   <secondary>ADS Domain</secondary>
512                 </indexterm><indexterm>
513                   <primary>winbind</primary>
514                 </indexterm><indexterm>
515                   <primary>browsing</primary>
516                 </indexterm><indexterm>
517                   <primary>permits</primary>
518                 </indexterm><indexterm>
519                   <primary>access</primary>
520                 </indexterm><indexterm>
521                   <primary>drive mapping</primary>
522                 </indexterm><indexterm>
523                   <primary>protected</primary>
524                 </indexterm><indexterm>
525                   <primary>security controls</primary>
526                 </indexterm><indexterm>
527                   <primary>access controls</primary>
528                 </indexterm>
529                                 Where Samba and the ADS domain account information obtained through the use of
530                                 <command>winbind</command> permits access, by browsing or by the drive mapping to
531                                 a share, to data that should be better protected. This can only happen when security
532                                 controls have not been properly implemented. Samba permits access controls to be set
533                                 on:
534                                 </para>
535
536                                 <itemizedlist>
537                                         <listitem><para>Shares themselves (i.e., the logical share itself)</para></listitem>
538                                         <listitem><para>The share definition in &smb.conf;</para></listitem>
539                                         <listitem><para>The shared directories and files using UNIX permissions</para></listitem>
540                                         <listitem><para>Using Windows 2000 ACLs &smbmdash; if the file system is POSIX enabled</para></listitem>
541                                 </itemizedlist>
542
543                                 <para>
544                                 Examples of each are given in <link linkend="ch10expl"/>.
545                                 </para>
546                                 </listitem>
547                 </varlistentry>
548
549                 <varlistentry>
550                         <term>User and Group Controls</term>
551             <listitem><para><indexterm>
552                   <primary>User and Group Controls</primary>
553                 </indexterm><indexterm>
554                   <primary>management</primary>
555                   <secondary>User</secondary>
556                 </indexterm><indexterm>
557                   <primary>management</primary>
558                   <secondary>group</secondary>
559                 </indexterm><indexterm>
560                   <primary>ADS</primary>
561                 </indexterm><indexterm>
562                   <primary>permissions</primary>
563                 </indexterm><indexterm>
564                   <primary>privileges</primary>
565                 </indexterm><indexterm>
566                   <primary>flexibility</primary>
567                 </indexterm><indexterm>
568                   <primary>access controls</primary>
569                 </indexterm><indexterm>
570                   <primary>share definition</primary>
571                 </indexterm>
572                                 User and group management facilities as known in the Windows ADS environment may be
573                                 used to provide equivalent access control constraints or to provide equivalent
574                                 permissions and privileges on Samba servers. Samba offers greater flexibility in the
575                                 use of user and group controls because it has additional layers of control compared to
576                                 Windows 200x/XP. For example, access controls on a Samba server may be set within
577                                 the share definition in a manner for which Windows has no equivalent.
578                                 </para>
579
580               <para><indexterm>
581                   <primary>analysis</primary>
582                 </indexterm><indexterm>
583                   <primary>system security</primary>
584                 </indexterm><indexterm>
585                   <primary>safe-guards</primary>
586                 </indexterm><indexterm>
587                   <primary>permissions</primary>
588                   <secondary>excessive</secondary>
589                 </indexterm><indexterm>
590                   <primary>file system</primary>
591                 </indexterm><indexterm>
592                   <primary>shared resource</primary>
593                 </indexterm><indexterm>
594                   <primary>share definition</primary>
595                 </indexterm>
596                                 In any serious analysis of system security, it is important to examine the safeguards
597                                 that remain when all other protective measures fail. An administrator may inadvertently
598                                 set excessive permissions on the file system of a shared resource, or he may set excessive
599                                 privileges on the share itself. If that were to happen in a Windows 2003 Server environment,
600                                 the data would indeed be laid bare to abuse. Yet, within a Samba share definition, it is
601                                 possible to guard against that by enforcing controls on the share definition itself. You
602                                 see a practical example of this a little later in this chapter.
603                                 </para>
604
605               <para><indexterm>
606                   <primary>diligence</primary>
607                 </indexterm><indexterm>
608                   <primary>weakness</primary>
609                 </indexterm>
610                                 The report that is critical of Samba really ought to have exercised greater due
611                                 diligence: the real weakness is on the side of a Microsoft Windows environment.
612                                 </para></listitem>
613                 </varlistentry>
614
615                 <varlistentry>
616                         <term>Security Overall</term>
617             <listitem><para><indexterm>
618                   <primary>defects</primary>
619                 </indexterm>
620                                 Samba is designed in such a manner that weaknesses inherent in the design of
621                                 Microsoft Windows networking ought not to expose the underlying UNIX/Linux file
622                                 system in any way. All software has potential defects, and Samba is no exception.
623                                 What matters more is how defects that are discovered get dealt with.
624                                 </para>
625
626               <para><indexterm>
627                   <primary>security</primary>
628                 </indexterm><indexterm>
629                   <primary>protection</primary>
630                 </indexterm><indexterm>
631                   <primary>compromise</primary>
632                 </indexterm><indexterm>
633                   <primary>consequential risk</primary>
634                 </indexterm>
635                                 The Samba Team totally agrees with the necessity to observe and fully implement
636                                 every security facility to provide a level of protection and security that is necessary
637                                 and that the end user (or network administrator) needs. Never would the Samba Team
638                                 recommend a compromise to system security, nor would deliberate defoliation of
639                                 security be publicly condoned; yet this is the practice by many Windows network
640                                 administrators just to make happy users who have no notion of consequential risk.
641                                 </para>
642
643               <para><indexterm>
644                   <primary>condemns</primary>
645                 </indexterm><indexterm>
646                   <primary>security fixes</primary>
647                 </indexterm><indexterm>
648                   <primary>updates</primary>
649                 </indexterm><indexterm>
650                   <primary>development</primary>
651                 </indexterm><indexterm>
652                   <primary>documentation</primary>
653                 </indexterm><indexterm>
654                   <primary>security updates</primary>
655                 </indexterm><indexterm>
656                   <primary>turn-around time</primary>
657                 </indexterm>
658                                 The report condemns Samba for releasing updates and security fixes, yet Microsoft
659                                 online updates need to be applied almost weekly. The answer to the criticism 
660                                 lies in the fact that Samba development is continuing, documentation is improving, 
661                                 user needs are being increasingly met or exceeded, and security updates are issued 
662                                 with a short turnaround time.
663                                 </para>
664
665               <para><indexterm>
666                   <primary>modularization</primary>
667                 </indexterm><indexterm>
668                   <primary>next generation</primary>
669                 </indexterm><indexterm>
670                   <primary>responsible</primary>
671                 </indexterm><indexterm>
672                   <primary>dependability</primary>
673                 </indexterm><indexterm>
674                   <primary>road-map</primary>
675                   <secondary>published</secondary>
676                 </indexterm>
677                                 The release of Samba-4 is expected around late 2004 to early 2005 and involves a near 
678                                 complete rewrite to permit extensive modularization and to prepare Samba for new 
679                                 functionality planned for addition during the next-generation series. The Samba Team 
680                                 is responsible and can be depended upon; the history to date suggests a high 
681                                 degree of dependability and on charter development consistent with published 
682                                 roadmap projections.
683                                 </para>
684
685               <para><indexterm>
686                   <primary>foundation members</primary>
687                 </indexterm><indexterm>
688                   <primary>Common Internet File System</primary>
689                   <see>CIFS</see>
690                 </indexterm><indexterm>
691                   <primary>network attached storage</primary>
692                   <see>NAS</see>
693                 </indexterm><indexterm>
694                   <primary>conferences</primary>
695                 </indexterm><indexterm>
696                   <primary>presence and leadership</primary>
697                 </indexterm><indexterm>
698                   <primary>leadership</primary>
699                 </indexterm><indexterm>
700                   <primary>inter-operability</primary>
701                 </indexterm>
702                                 Not well published is the fact that Microsoft was a foundation member of
703                                 the Common Internet File System (CIFS) initiative, together with the participation 
704                                 of the network attached storage (NAS) industry. Unfortunately, for the past few years,
705                                 Microsoft has been absent from active involvement at CIFS conferences and has
706                                 not exercised the leadership expected of a major force in the networking technology
707                                 space. The Samba Team has maintained consistent presence and leadership at all
708                                 CIFS conferences and at the interoperability laboratories run concurrently with
709                                 them.
710                                 </para></listitem>
711                 </varlistentry>
712
713                 <varlistentry>
714                         <term>Cryptographic Controls (schannel, sign'n'seal)</term>
715             <listitem><para><indexterm>
716                   <primary>Cryptographic</primary>
717                 </indexterm><indexterm>
718                   <primary>schannel</primary>
719                 </indexterm><indexterm>
720                   <primary>digital sign'n'seal</primary>
721                 </indexterm>
722                                 The report correctly mentions that Samba did not support the most recent
723                                 <constant>schannel</constant> and <constant>digital sign'n'seal</constant> features
724                                 of Microsoft Windows NT/200x/XPPro products. This is one of the key features 
725                                 of the Samba-3 release. Market research reports take so long to generate that they are
726                                 seldom a reflection of current practice, and in many respects reports are like a
727                                 pathology report &smbmdash; they reflect accurately (at best) status at a snapshot in time.
728                                 Meanwhile, the world moves on.
729                                 </para>
730
731               <para><indexterm>
732                   <primary>public specifications</primary>
733                 </indexterm><indexterm>
734                   <primary>protocols</primary>
735                 </indexterm><indexterm>
736                   <primary>algorithm</primary>
737                 </indexterm><indexterm>
738                   <primary>compatible</primary>
739                 </indexterm><indexterm>
740                   <primary>network</primary>
741                   <secondary>traffic</secondary>
742                   <tertiary>observation</tertiary>
743                 </indexterm><indexterm>
744                   <primary>defensible standards</primary>
745                 </indexterm><indexterm>
746                   <primary>secure networking</primary>
747                 </indexterm>
748                                 It should be pointed out that had clear public specifications for the protocols
749                                 been published, it would have been much easier to implement these features and would have
750                                 taken less time to do. The sole mechanism used to find an algorithm that is compatible
751                                 with the methods used by Microsoft has been based on observation of network traffic
752                                 and trial-and-error implementation of potential techniques. The real value of public
753                                 and defensible standards is obvious to all and would have enabled more secure networking
754                                 for everyone.
755                                 </para>
756
757               <para><indexterm>
758                   <primary>Critics</primary>
759                 </indexterm><indexterm>
760                   <primary>digital sign'n'seal</primary>
761                 </indexterm>
762                                 Critics of Samba often ignore fundamental problems that may plague (or may have plagued)
763                                 the users of Microsoft's products also. Those who are first to criticize Samba
764                                 for not rushing into release of <constant>digital sign'n'seal</constant> support
765                                 often dismiss the problems that Microsoft has 
766                                 <ulink url="http://support.microsoft.com/default.aspx?kbid=321733">acknowledged</ulink>
767                                 and for which a fix was provided. In fact,
768                                 <ulink url="http://www.tangent-systems.com/support/delayedwrite.html">Tangent Systems</ulink> 
769                                 have documented a significant problem with delays writes that can be connected with the
770                                 implementation of sign'n'seal. They provide a work-around that is not trivial for many
771                                 Windows networking sites. From notes such as this it is clear that there are benefits
772                                 from not rushing new technology out of the door too soon.
773                                 </para>
774
775               <para><indexterm>
776                   <primary>secure networking protocols</primary>
777                 </indexterm><indexterm>
778                   <primary>refereed standards</primary>
779                 </indexterm><indexterm>
780                   <primary>proprietary</primary>
781                 </indexterm><indexterm>
782                   <primary>digital rights</primary>
783                 </indexterm><indexterm>
784                   <primary>protection</primary>
785                 </indexterm><indexterm>
786                   <primary>networking protocols</primary>
787                 </indexterm><indexterm>
788                   <primary>diffusion</primary>
789                 </indexterm><indexterm>
790                   <primary>consumer</primary>
791                 </indexterm><indexterm>
792                   <primary>choice</primary>
793                 </indexterm>
794                                 One final comment is warranted. If companies want more secure networking protocols,
795                                 the most effective method by which this can be achieved is by users seeking
796                                 and working together to help define open and publicly refereed standards. The
797                                 development of closed source, proprietary methods that are developed in a
798                                 clandestine framework of secrecy, under claims of digital rights protection, does
799                                 not favor the diffusion of safe networking protocols and certainly does not
800                                 help the consumer to make a better choice.
801                                 </para></listitem>
802                 </varlistentry>
803
804                 <varlistentry>
805                         <term>Active Directory Replacement with Kerberos, LDAP, and Samba</term>
806                 <indexterm>
807                   <primary>Active Directory</primary>
808                   <secondary>Replacement</secondary>
809                 </indexterm><indexterm>
810                   <primary>Kerberos</primary>
811                 </indexterm><indexterm>
812                   <primary>LDAP</primary>
813                 </indexterm><indexterm>
814                   <primary>remote procedure call</primary>
815                   <see>RPC</see>
816                 </indexterm>
817                                 <listitem><para>
818                                 <literallayout>    </literallayout>
819                                 The Microsoft networking protocols extensively make use of remote procedure call (RPC)
820                                 technology. Active Directory is not a simple mixture of LDAP and Kerberos together
821                                 with file and print services, but rather is a complex, intertwined implementation
822                                 of them that uses RPCs that are not supported by any of these component technologies
823                                 and yet by which they are made to interoperate in ways that the components do not
824                                 support.
825                                 </para>
826
827               <para><indexterm>
828                   <primary>Active Directory</primary>
829                   <secondary>Server</secondary>
830                 </indexterm><indexterm>
831                   <primary>OpenLDAP</primary>
832                 </indexterm><indexterm>
833                   <primary>Kerberos</primary>
834                 </indexterm><indexterm>
835                   <primary>project maintainers</primary>
836                 </indexterm><indexterm>
837                   <primary>LDAP</primary>
838                 </indexterm>
839                                 In order to make the popular request for Samba to be an Active Directory Server a
840                                 reality, it is necessary to add to OpenLDAP, Kerberos, as well as Samba, RPC calls
841                                 that are not presently supported. The Samba Team has not been able to gain critical
842                                 overall support for all project maintainers to work together on the complex
843                                 challenge of developing and integrating the necessary technologies. Therefore, if
844                                 the Samba Team does not make it a priority to absorb Kerberos and LDAP functionality
845                                 into the Samba project, this dream request cannot become a reality.
846                                 </para>
847
848               <para><indexterm>
849                   <primary>missing RPC's</primary>
850                 </indexterm><indexterm>
851                   <primary>road-map</primary>
852                 </indexterm><indexterm>
853                   <primary>ADS</primary>
854                   <secondary>server</secondary>
855                 </indexterm><indexterm>
856                   <primary>MMC</primary>
857                 </indexterm><indexterm>
858                   <primary>managed</primary>
859                 </indexterm>
860                                 At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the
861                                 Samba development roadmap. If it is not on the published roadmap, it cannot be delivered
862                                 anytime soon. Ergo, ADS server support is not a current goal for Samba development.
863                                 The Samba Team is most committed to permitting Samba to be a full ADS domain member
864                                 that is increasingly capable of being managed using Microsoft Windows MMC tools.
865                                 </para></listitem>
866                 </varlistentry>
867         </variablelist>
868
869         <sect3>
870         <title>Kerberos Exposed</title>
871
872           <para><indexterm>
873               <primary>kerberos</primary>
874             </indexterm><indexterm>
875               <primary>unauthorized activities</primary>
876             </indexterm><indexterm>
877               <primary>authorized location</primary>
878             </indexterm>
879         Kerberos is a network authentication protocol that provides secure authentication for 
880         client-server applications by using secret-key cryptography. Firewalls are an insufficient 
881         barrier mechanism in today's networking world; at best they only restrict incoming network 
882         traffic but cannot prevent network traffic that comes from authorized locations from 
883         performing unauthorized activities.
884         </para>
885
886           <para><indexterm>
887               <primary>strong cryptography</primary>
888             </indexterm><indexterm>
889               <primary>identity</primary>
890             </indexterm><indexterm>
891               <primary>integrity</primary>
892             </indexterm>
893         Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses 
894         strong cryptography so that a client can prove its identity to a server (and vice versa) across an 
895         insecure network connection. After a client and server has used Kerberos to prove their identity, 
896         they can also encrypt all of their communications to assure privacy and data integrity as they go 
897         about their business.
898         </para>
899
900           <para><indexterm>
901               <primary>trusted third-party</primary>
902             </indexterm><indexterm>
903               <primary>principals</primary>
904             </indexterm><indexterm>
905               <primary>trusting</primary>
906             </indexterm><indexterm>
907               <primary>kerberos</primary>
908               <secondary>server</secondary>
909             </indexterm><indexterm>
910               <primary>secret</primary>
911             </indexterm>
912         Kerberos is a trusted third-party service. That means that there is a third party (the kerberos 
913         server) that is trusted by all the entities on the network (users and services, usually called 
914         principals). All principals share a secret password (or key) with the kerberos server and this 
915         enables principals to verify that the messages from the kerberos server are authentic. Therefore, 
916         trusting the kerberos server, users and services can authenticate each other.
917         </para>
918
919         <para>
920         <indexterm><primary>restricted export</primary></indexterm>
921         <indexterm><primary>MIT Kerberos</primary></indexterm>
922         <indexterm><primary>Heimdal Kerberos</primary></indexterm>
923         Kerberos was, until recently, a technology that was restricted from being exported from the United States.
924         For many years that hindered global adoption of more secure networking technologies both within the United States
925         and abroad. A free and unencumbered implementation of MIT Kerberos has been produced in Europe
926         and is available from the University of Paderborn, Sweden. It is known as the Heimdal Kerberos project.
927         In recent times the U.S. government has removed sanctions affecting the global distribution of MIT Kerberos.
928         It is likely that there will be a significant surge forward in the development of Kerberos-enabled applications
929         and in the general deployment and use of Kerberos across the spectrum of the information technology industry.
930         </para>
931
932         <para>
933         <indexterm><primary>Kerberos</primary><secondary>interoperability</secondary></indexterm>
934         A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation
935         of it. For example, a 2002
936         <ulink url="http://www.idg.com.sg/idgwww.nsf/0/5DDA8D153A7505A748256BAB000D992A?OpenDocument">IDG</ulink>
937         report<footnote>Note: This link is no longer active. The same article is still
938         available from <ulink url="http://199.105.191.226/Man/2699/020430msdoj/">ITWorld.com</ulink> (July 5, 2005)</footnote> by
939         states:
940         </para>
941
942         <blockquote><para>
943         A Microsoft Corp. executive testified at the software giant's remedy hearing that the company goes to 
944         great lengths to disclose interfaces and protocols that allow third-party software products to interact 
945         with Windows. But a lawyer with the states suing Microsoft pointed out that when it comes to the company's 
946         use of the Kerberos authentication specification, not everyone agrees.
947         </para>
948
949         <para>
950         <indexterm><primary>Kerberos</primary><secondary>unspecified fields</secondary></indexterm>
951         Robert Short, vice president of Windows core technology at Microsoft, wrote in his direct testimony prepared 
952         before his appearance that non-Microsoft operating systems can disregard the portion of the Kerberos version 
953         5 specification that Windows clients use for proprietary purposes and still achieve interoperability with 
954         the Microsoft OS. Microsoft takes advantage of unspecified fields in the Kerberos specification for storing 
955         Windows-specific authorization data, Short wrote. The designers of Kerberos left these fields undefined so 
956         that software developers could add their own authorization information, he said.
957         </para></blockquote>
958
959         <para>
960         <indexterm><primary>DCE</primary></indexterm>
961         <indexterm><primary>RPC</primary></indexterm>
962         It so happens that Microsoft Windows clients depend on and expect the contents of the <emphasis>unspecified
963         fields</emphasis> in the Kerberos 5 communications data stream for their Windows interoperability,
964         particularly when Samba is expected to emulate a Windows Server 200x domain controller. But the interoperability
965         issue goes far deeper than this. In the domain control protocols that are used by MS Windows XP Professional,
966         there is a tight interdependency between the Kerberos protocols and the Microsoft distributed computing environment
967         (DCE) RPCs that themselves are an integral part of the SMB/CIFS protocols as used by
968         Microsoft.
969         </para>
970
971         <para>
972         Microsoft makes the following comment in a reference in a
973         <ulink url="http://www.microsoft.com/technet/itsolutions/interop/mgmt/kerberos.asp">
974         technet</ulink> article:
975         </para>
976
977           <blockquote><para><indexterm>
978                 <primary>Privilege Attribute Certificates</primary>
979                 <see>PAC</see>
980               </indexterm><indexterm>
981                 <primary>access control</primary>
982               </indexterm>
983         The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC 
984         representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos 
985         tickets to convey Privilege Attribute Certificates (PACs) that define user identity and group membership. 
986         The DCE PAC is used in a similar manner as Windows NT Security IDs for user authorization and access control. 
987         Windows NT services will not be able to translate DCE PACs into Windows NT user and group identifiers. This 
988         is not an issue with Kerberos interoperability, but rather an issue of interoperability between DCE and 
989         Windows NT access control information.
990         </para></blockquote>
991
992         </sect3>
993
994         </sect2>
995
996 </sect1>
997
998 <sect1 id="ch10expl">
999         <title>Implementation</title>
1000
1001         <para>
1002         The following procedures outline the implementation of the security measures discussed so far.
1003         </para>
1004
1005         <sect2>
1006         <title>Share Access Controls</title>
1007
1008         <para><indexterm>
1009             <primary>Share Access Controls</primary>
1010           </indexterm><indexterm>
1011             <primary>filter</primary>
1012           </indexterm><indexterm>
1013             <primary>connection</primary>
1014           </indexterm>
1015         Access control entries placed on the share itself act as a filter at the time a when CIFS/SMB client (such as
1016         Windows XP Pro) attempts to make a connection to the Samba server.
1017         </para>
1018
1019         <procedure>
1020         <title>Create/Edit/Delete Share ACLs</title>
1021           <step><para><indexterm>
1022                 <primary>Domain Administrator</primary>
1023               </indexterm><indexterm>
1024                 <primary>account</primary>
1025               </indexterm>
1026                 From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator 
1027                 account (on Samba domains, this is usually the account called <constant>root</constant>).
1028                 </para></step>
1029
1030                 <step><para>
1031                 Click 
1032                 <menuchoice>
1033                         <guimenu>Start</guimenu>
1034                         <guimenuitem>Settings</guimenuitem>
1035                         <guimenuitem>Control Panel</guimenuitem>
1036                         <guimenuitem>Administrative Tools</guimenuitem>
1037                         <guimenuitem>Computer Management</guimenuitem>
1038                 </menuchoice>.
1039                 </para></step>
1040
1041                 <step><para>
1042                 In the left panel,
1043                 <menuchoice>
1044                         <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu>
1045                         <guimenuitem>Connect to another computer ...</guimenuitem>
1046                         <guimenuitem>Browse...</guimenuitem>
1047                         <guimenuitem>Advanced</guimenuitem>
1048                         <guimenuitem>Find Now</guimenuitem>
1049                 </menuchoice>. In the lower panel, click on the name of the server you wish to
1050                 administer. Click <menuchoice>
1051                                 <guimenu>OK</guimenu>
1052                                 <guimenuitem>OK</guimenuitem>
1053                                 <guimenuitem>OK</guimenuitem>
1054               </menuchoice>.<indexterm>
1055                 <primary>Computer Management</primary>
1056               </indexterm>
1057                 In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect
1058                 the change made. For example, if the server you are administering is called <constant>FRODO</constant>,
1059                 the Computer Management entry should now say <guimenu>Computer Management (FRODO)</guimenu>.
1060                 </para></step>
1061
1062                 <step><para>
1063                 In the left panel, click <menuchoice>
1064                         <guimenu>Computer Management (FRODO)</guimenu>
1065                         <guimenuitem>[+] Shared Folders</guimenuitem>
1066                         <guimenuitem>Shares</guimenuitem>
1067                 </menuchoice>.
1068                 </para></step>
1069
1070           <step><para><indexterm>
1071                 <primary>ACLs</primary>
1072               </indexterm><indexterm>
1073                 <primary>Share Permissions</primary>
1074               </indexterm>
1075                 In the right panel, double-click on the share on which you wish to set/edit ACLs. This
1076                 will bring up the Properties panel. Click the <guimenu>Share Permissions</guimenu> tab.
1077                 </para></step>
1078
1079           <step><para><indexterm>
1080                 <primary>access control settings</primary>
1081               </indexterm><indexterm>
1082                 <primary>Everyone</primary>
1083               </indexterm><indexterm>
1084                 <primary>full control</primary>
1085               </indexterm><indexterm>
1086                 <primary>over-rule</primary>
1087               </indexterm><indexterm>
1088                 <primary>permissions</primary>
1089               </indexterm><indexterm>
1090                 <primary>rejected</primary>
1091               </indexterm>
1092                 You may now edit/add/remove access control settings. Be very careful. Many problems have been
1093                 created by people who decided that everyone should be rejected but one particular group should
1094                 have full control. This is a catch-22 situation because members of that particular group also
1095                 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
1096                 set for the permitted group.
1097                 </para></step>
1098
1099                 <step><para>
1100                 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
1101                 buttons.
1102                 </para></step>
1103         </procedure>
1104
1105         </sect2>
1106
1107         <sect2>
1108         <title>Share Definition Controls</title>
1109
1110         <para><indexterm>
1111             <primary>Share Definition</primary>
1112             <secondary>Controls</secondary>
1113           </indexterm><indexterm>
1114             <primary>check-point</primary>
1115           </indexterm><indexterm>
1116             <primary>pile-driver</primary>
1117           </indexterm><indexterm>
1118             <primary>credential</primary>
1119           </indexterm><indexterm>
1120             <primary>powers</primary>
1121           </indexterm><indexterm>
1122             <primary>privileges</primary>
1123           </indexterm>
1124         Share-definition-based access controls can be used like a checkpoint or like a pile-driver. Just as a
1125         checkpoint can be used to require someone who wants to get through to meet certain requirements, so
1126         it is possible to require the user (or group the user belongs to) to meet specified credential-related 
1127         objectives. It can be likened to a pile-driver by overriding default controls in that having met the 
1128         credential-related objectives, the user can be granted powers and privileges that would not normally be 
1129         available under default settings.
1130         </para>
1131
1132         <para><indexterm>
1133             <primary>access controls</primary>
1134           </indexterm><indexterm>
1135             <primary>ACLs</primary>
1136           </indexterm><indexterm>
1137             <primary>share definition controls</primary>
1138           </indexterm><indexterm>
1139             <primary>hierarchy of control</primary>
1140           </indexterm>
1141         It must be emphasized that the controls discussed here can act as a filter or give rights of passage
1142         that act as a superstructure over normal directory and file access controls. However, share-level
1143         ACLs act at a higher level than do share definition controls because the user must filter through the
1144         share-level controls to get to the share-definition controls. The proper hierarchy of controls implemented
1145         by Samba and Windows networking consists of:
1146         </para>
1147
1148         <orderedlist>
1149                 <listitem><para>Share-level ACLs</para></listitem>
1150                 <listitem><para>Share-definition controls</para></listitem>
1151                 <listitem><para>Directory and file permissions</para></listitem>
1152                 <listitem><para>Directory and file POSIX ACLs</para></listitem>
1153         </orderedlist>
1154
1155         <sect3>
1156         <title>Checkpoint Controls</title>
1157
1158           <para><indexterm>
1159               <primary>Checkpoint Controls</primary>
1160             </indexterm>
1161         Consider the following extract from a &smb.conf; file defining the share called <constant>Apps</constant>:
1162 <screen>
1163 [Apps]
1164         comment = Application Share
1165         path = /data/apps
1166         read only = Yes
1167         valid users = @Employees
1168 </screen>
1169         This definition permits only those who are members of the group called <constant>Employees</constant> to 
1170         access the share.
1171         </para>
1172
1173           <note><para><indexterm>
1174                 <primary>Domain Member</primary>
1175                 <secondary>servers</secondary>
1176               </indexterm><indexterm>
1177                 <primary>winbind use default domain</primary>
1178               </indexterm><indexterm>
1179                 <primary>fully qualified</primary>
1180               </indexterm><indexterm>
1181                 <primary>valid users</primary>
1182               </indexterm><indexterm>
1183                 <primary>delimiter</primary>
1184               </indexterm>
1185         On domain member servers and clients, even when the <parameter>winbind use default domain</parameter> has
1186         been specified, the use of domain accounts in security controls requires fully qualified domain specification,
1187         for example, <smbconfoption name="valid users">@"MEGANET\Northern Engineers"</smbconfoption>. 
1188         Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a
1189         delimiter. 
1190         </para></note>
1191
1192           <para><indexterm>
1193               <primary>ACL</primary>
1194             </indexterm><indexterm>
1195               <primary>access</primary>
1196             </indexterm><indexterm>
1197               <primary>validate</primary>
1198             </indexterm>
1199         If there is an ACL on the share itself to permit read/write access for all <constant>Employees</constant>
1200         as well as read/write for the group <constant>Doctors</constant>, both groups are permitted through
1201         to the share. However, at the moment an attempt is made to set up a connection to the share, a member of
1202         the group <constant>Doctors</constant>, who is not also a member of the group <constant>Employees</constant>,
1203         would immediately fail to validate.
1204         </para>
1205
1206           <para><indexterm>
1207               <primary>share definition controls</primary>
1208             </indexterm>
1209         Consider another example. In this case, you want to permit all members of the group <constant>Employees</constant>
1210         except the user <constant>patrickj</constant> to access the <constant>Apps</constant> share. This can be
1211         easily achieved by setting a share-level ACL permitting only <constant>Employees</constant> to access the share,
1212         and then in the share definition controls excluding just <constant>patrickj</constant>. Here is how that might
1213         be done:
1214 <screen>
1215 [Apps]
1216         comment = Application Share
1217         path = /data/apps
1218         read only = Yes
1219         invalid users = patrickj
1220 </screen>
1221             <indexterm>
1222               <primary>permissions</primary>
1223             </indexterm>
1224         Let us assume that you want to permit the user <constant>gbshaw</constant> to manage any file in the
1225         UNIX/Linux file system directory <filename>/data/apps</filename>, but you do not want to grant any write
1226         permissions beyond that directory tree. Here is one way this can be done:
1227 <screen>
1228 [Apps]
1229         comment = Application Share
1230         path = /data/apps
1231         read only = Yes
1232         invalid users = patrickj
1233         admin users = gbshaw
1234 </screen>
1235             <indexterm>
1236               <primary>administrative rights</primary>
1237             </indexterm>
1238         Now we have a set of controls that permits only <constant>Employees</constant> who are also members of
1239         the group <constant>Doctors</constant>, excluding the user <constant>patrickj</constant>, to have 
1240         read-only privilege, but the user <constant>gbshaw</constant> is granted administrative rights.
1241         The administrative rights conferred upon the user <constant>gbshaw</constant> permit operation as
1242         if that user has logged in as the user <constant>root</constant> on the UNIX/Linux system and thus,
1243         for access to the directory tree that has been shared (exported), permit the user to override controls
1244         that apply to all other users on that resource.
1245         </para>
1246
1247         <para>
1248         There are additional checkpoint controls that may be used. For example, if for the same share we now
1249         want to provide the user <constant>peters</constant> with the ability to write to one directory to
1250         which he has write privilege in the UNIX file system, you can specifically permit that with the
1251         following settings:
1252 <screen>
1253 [Apps]
1254         comment = Application Share
1255         path = /data/apps
1256         read only = Yes
1257         invalid users = patrickj
1258         admin users = gbshaw
1259         write list = peters
1260 </screen>
1261             <indexterm>
1262               <primary>check-point controls</primary>
1263             </indexterm>
1264         This is a particularly complex example at this point, but it begins to demonstrate the possibilities.
1265         You should refer to the online manual page for the &smb.conf; file for more information regarding
1266         the checkpoint controls that Samba implements.
1267         </para>
1268
1269         </sect3>
1270
1271         <sect3>
1272         <title>Override Controls</title>
1273
1274           <para><indexterm>
1275               <primary>over-ride controls</primary>
1276             </indexterm>
1277         Override controls implemented by Samba permit actions like the adoption of a different identity 
1278         during file system operations, the forced overwriting of normal file and directory permissions,
1279         and so on. You should refer to the online manual page for the &smb.conf; file for more information regarding
1280         the override controls that Samba implements.
1281         </para>
1282
1283         <para>
1284         In the following example, you want to create a Windows networking share that any user can access.
1285         However, you want all read and write operations to be performed as if the user <constant>billc</constant>
1286         and member of the group <constant>Mentors</constant> read/write the files. Here is one way this
1287         can be done:
1288 <screen>
1289 [someshare]
1290         comment = Some Files Everyone May Overwrite
1291         path = /data/somestuff
1292         read only = No
1293         force user = billc
1294         force group = Mentors
1295 </screen>
1296             <indexterm>
1297               <primary>forced settings</primary>
1298             </indexterm><indexterm>
1299               <primary>overheads</primary>
1300             </indexterm>
1301         That is all there is to it. Well, it is almost that simple. The downside of this method is that
1302         users are logged onto the Windows client as themselves, and then immediately before accessing the
1303         file, Samba makes system calls to change the effective user and group to the forced settings
1304         specified, completes the file transaction, and then reverts to the actually logged-on identity.
1305         This imposes significant overhead on Samba. The alternative way to effectively achieve the same result
1306         (but with lower system CPU overheads) is described next.
1307         </para>
1308
1309           <para><indexterm>
1310               <primary>force user</primary>
1311             </indexterm><indexterm>
1312               <primary>force group</primary>
1313             </indexterm><indexterm>
1314               <primary>opportunistic</primary>
1315               <secondary>locking</secondary>
1316             </indexterm><indexterm>
1317               <primary>oplock break</primary>
1318             </indexterm><indexterm>
1319               <primary>performance degradation</primary>
1320             </indexterm>
1321         The use of the <parameter>force user</parameter> or the <parameter>force group</parameter> may
1322         also have a severe impact on system (particularly on Windows client) performance. If opportunistic
1323         locking is enabled on the share (the default), it causes an <constant>oplock break</constant> to be
1324         sent to the client even if the client has not opened the file. On networks that have high traffic
1325         density, or on links that are routed to a remote network segment, <constant>oplock breaks</constant>
1326         can be lost. This results in possible retransmission of the request, or the client may time-out while
1327         waiting for the file system transaction (read or write) to complete. The result can be a profound
1328         apparent performance degradation as the client continually attempts to reconnect to overcome the
1329         effect of the lost <constant>oplock break</constant>, or time-out.
1330         </para>
1331         
1332         </sect3>
1333
1334         </sect2>
1335
1336         <sect2>
1337         <title>Share Point Directory and File Permissions</title>
1338
1339         <para><indexterm>
1340             <primary>security</primary>
1341           </indexterm><indexterm>
1342             <primary>privilege controls</primary>
1343           </indexterm><indexterm>
1344             <primary>permission</primary>
1345           </indexterm><indexterm>
1346             <primary>share definition controls</primary>
1347           </indexterm>
1348         Samba has been designed and implemented so that it respects as far as is feasible the security and
1349         user privilege controls that are built into the UNIX/Linux operating system. Samba does nothing
1350         with respect to file system access that violates file system permission settings, unless it is
1351         explicitly instructed to do otherwise through share definition controls. Given that Samba obeys
1352         UNIX file system controls, this chapter does not document simple information that can be obtained
1353         from a basic UNIX training guide. Instead, one common example of a typical problem is used
1354         to demonstrate the most effective solution referred to in the immediately preceding paragraph.
1355         </para>
1356
1357         <para><indexterm>
1358             <primary>Microsoft Office</primary>
1359           </indexterm><indexterm>
1360             <primary>Word</primary>
1361           </indexterm><indexterm>
1362             <primary>Excel</primary>
1363           </indexterm>
1364         One of the common issues that repeatedly pops up on the Samba mailing lists involves the saving of
1365         Microsoft Office files (Word and Excel) to a network drive. Here is the typical sequence:
1366         </para>
1367
1368         <orderedlist>
1369                 <listitem><para>
1370                 A user opens a Work document from a network drive. The file was owned by user <constant>janetp</constant>
1371                 and <group>users</group>, and was set read/write-enabled for everyone.
1372                 </para></listitem>
1373
1374                 <listitem><para>
1375                 File changes and edits are made.
1376                 </para></listitem>
1377
1378                 <listitem><para>
1379                 The file is saved, and MS Word is closed.
1380                 </para></listitem>
1381
1382                 <listitem><para>
1383                 The file is now owned by the user <constant>billc</constant> and group <constant>doctors</constant>,
1384                 and is set read/write by <constant>billc</constant>, read-only by <constant>doctors</constant>, and
1385                 no access by everyone.
1386                 </para></listitem>
1387
1388                 <listitem><para>
1389                 The original owner cannot now access her own file and is <quote>justifiably</quote> upset.
1390                 </para></listitem>
1391         </orderedlist>
1392
1393         <para>
1394         There have been many postings over the years that report the same basic problem. Frequently Samba users
1395         want to know when this <quote>bug</quote> will be fixed. The fact is, this is not a bug in Samba at all.
1396         Here is the real sequence of what happens in this case.
1397         </para>
1398
1399         <para><indexterm>
1400             <primary>MS Word</primary>
1401           </indexterm><indexterm>
1402             <primary>ownership</primary>
1403           </indexterm><indexterm>
1404             <primary>permissions</primary>
1405           </indexterm>
1406         When the user saves a file, MS Word creates a new (temporary) file. This file is naturally owned
1407         by the user who creates the file (<constant>billc</constant>) and has the permissions that follow
1408         that user's default settings within the operating system (UNIX/Linux). When MS Word has finished writing
1409         the file to disk, it then renames the new (temporary) file to the name of the old one. MS Word does not
1410         change the ownership or permissions to what they were on the original file. The file is thus a totally
1411         new file, and the old one has been deleted in the process.
1412         </para>
1413
1414         <para>
1415         Samba received a request to create a new file, and then to rename the file to a new name. The old file that
1416         has the same name is now automatically deleted. Samba has no way of knowing that the new file should
1417         perhaps have the same ownership and permissions as the old file. To Samba, these are entirely independent
1418         operations.
1419         </para>
1420
1421         <para>
1422         The question is, <quote>How can we solve the problem?</quote>
1423         </para>
1424
1425         <para>
1426         The solution is simple. Use UNIX file system permissions and controls to your advantage. Follow these
1427         simple steps to create a share in which all files will consistently be owned by the same user and the
1428         same group:
1429         </para>
1430
1431
1432         <procedure>
1433         <title>Using Directory Permissions to Force File User and Group Ownership</title>
1434                 <step><para>
1435                 Change your share definition so that it matches this pattern:
1436 <screen>
1437 [finance]
1438         path = /usr/data/finance
1439         browseable = Yes
1440         read only = No
1441 </screen>
1442                 </para></step>
1443
1444           <step><para><indexterm>
1445                 <primary>permissions</primary>
1446                 <secondary>user</secondary>
1447               </indexterm><indexterm>
1448                 <primary>permissions</primary>
1449                 <secondary>group</secondary>
1450               </indexterm>
1451                 Set consistent user and group permissions recursively down the directory tree as shown here:
1452 <screen>
1453 &rootprompt; chown -R janetp.users /usr/data/finance
1454 </screen>
1455                 </para></step>
1456
1457           <step><para><indexterm>
1458                 <primary>accessible</primary>
1459               </indexterm>
1460                 Set the files and directory permissions to be read/write for owner and group, and not accessible
1461                 to others (everyone), using the following command:
1462 <screen>
1463 &rootprompt; chmod ug+rwx,o-rwx /usr/data/finance
1464 </screen>
1465                 </para></step>
1466
1467           <step><para><indexterm>
1468                 <primary>SGID</primary>
1469               </indexterm>
1470                 Set the SGID (supergroup) bit on all directories from the top down. This means all files 
1471                 can be created with the permissions of the group set on the directory. It means all users 
1472                 who are members of the group <constant>finance</constant> can read and write all files in 
1473                 the directory. The directory is not readable or writable by anyone who is not in the 
1474                 <constant>finance</constant> group. Simply follow this example:
1475 <screen>
1476 &rootprompt; find /usr/data/finance -type d -exec chmod ug+s {}\;
1477 </screen>
1478
1479                 </para></step>
1480
1481           <step><para><indexterm>
1482                 <primary>group membership</primary>
1483               </indexterm><indexterm>
1484                 <primary>primary group</primary>
1485               </indexterm><indexterm>
1486                 <primary>/etc/passwd</primary>
1487               </indexterm>
1488                 Make sure all users that must have read/write access to the directory have 
1489                 <constant>finance</constant> group membership as their primary group, 
1490                 for example, the group they belong to in <filename>/etc/passwd</filename>.
1491                 </para></step>
1492         </procedure>
1493
1494         </sect2>
1495
1496         <sect2>
1497         <title>Managing Windows 200x ACLs</title>
1498
1499         <para><indexterm>
1500             <primary>translate</primary>
1501           </indexterm><indexterm>
1502             <primary>Windows 2000 ACLs</primary>
1503           </indexterm><indexterm>
1504             <primary>Posix ACLs</primary>
1505           </indexterm><indexterm>
1506             <primary>side effects</primary>
1507           </indexterm>
1508         Samba must translate Windows 2000 ACLs to UNIX POSIX ACLs. This has some interesting side effects because
1509         there is not a one-to-one equivalence between them. The as-close-as-possible ACLs match means
1510         that some transactions are not possible from MS Windows clients. One of these is to reset the ownership
1511         of directories and files. If you want to reset ownership, this must be done from a UNIX/Linux login.
1512         </para>
1513
1514         <para>
1515         There are two possible ways to set ACLs on UNIX/Linux file systems from a Windows network workstation,
1516         either via File Manager or via the Microsoft Management Console (MMC) Computer Management interface.
1517         </para>
1518
1519         <sect3>
1520         <title>Using the MMC Computer Management Interface</title>
1521
1522         <procedure>
1523                 <step><para>
1524                 From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator 
1525                 account (on Samba domains, this is usually the account called <constant>root</constant>).
1526                 </para></step>
1527
1528                 <step><para>
1529                 Click 
1530                 <menuchoice>
1531                         <guimenu>Start</guimenu>
1532                         <guimenuitem>Settings</guimenuitem>
1533                         <guimenuitem>Control Panel</guimenuitem>
1534                         <guimenuitem>Administrative Tools</guimenuitem>
1535                         <guimenuitem>Computer Management</guimenuitem>
1536                 </menuchoice>.
1537                 </para></step>
1538
1539                 <step><para>
1540                 In the left panel,
1541                 <menuchoice>
1542                         <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu>
1543                         <guimenuitem>Connect to another computer ...</guimenuitem>
1544                         <guimenuitem>Browse...</guimenuitem>
1545                         <guimenuitem>Advanced</guimenuitem>
1546                         <guimenuitem>Find Now</guimenuitem>
1547                 </menuchoice>. In the lower panel, click on the name of the server you wish to
1548                 administer. Click <menuchoice>
1549                                 <guimenu>OK</guimenu>
1550                                 <guimenuitem>OK</guimenuitem>
1551                                 <guimenuitem>OK</guimenuitem>
1552                 </menuchoice>.
1553                 In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect
1554                 the change made. For example, if the server you are administering is called <constant>FRODO</constant>,
1555                 the Computer Management entry should now say: <guimenu>Computer Management (FRODO)</guimenu>.
1556                 </para></step>
1557
1558                 <step><para>
1559                 In the left panel, click <menuchoice>
1560                         <guimenu>Computer Management (FRODO)</guimenu>
1561                         <guimenuitem>[+] Shared Folders</guimenuitem>
1562                         <guimenuitem>Shares</guimenuitem>
1563                 </menuchoice>.
1564                 </para></step>
1565
1566             <step><para><indexterm>
1567                   <primary>Security</primary>
1568                 </indexterm><indexterm>
1569                   <primary>Properties</primary>
1570                 </indexterm><indexterm>
1571                   <primary>Permissions</primary>
1572                 </indexterm><indexterm>
1573                   <primary>Samba Domain server</primary>
1574                 </indexterm>
1575                 In the right panel, double-click on the share on which you wish to set/edit ACLs. This
1576                 brings up the Properties panel. Click the <guimenu>Security</guimenu> tab. It is best
1577                 to edit ACLs using the <constant>Advanced</constant> editing features. Click the 
1578                 <guimenu>Advanced</guimenu> button. This opens a panel that has four tabs. Only the 
1579                 functionality under the <constant>Permissions</constant> tab can be utilized with respect 
1580                 to a Samba domain server.
1581                 </para></step>
1582
1583             <step><para><indexterm>
1584                   <primary>access control</primary>
1585                 </indexterm><indexterm>
1586                   <primary>permitted group</primary>
1587                 </indexterm>
1588                 You may now edit/add/remove access control settings. Be very careful. Many problems have been
1589                 created by people who decided that everyone should be rejected but one particular group should
1590                 have full control. This is a catch-22 situation because members of that particular group also
1591                 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
1592                 set for the permitted group.
1593                 </para></step>
1594
1595                 <step><para>
1596                 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
1597                 buttons until the last panel closes.
1598                 </para></step>
1599         </procedure>
1600         
1601         </sect3>
1602
1603         <sect3>
1604         <title>Using MS Windows Explorer (File Manager)</title>
1605
1606         <para>
1607         The following alternative method may be used from a Windows workstation. In this example we work
1608         with a domain called <constant>MEGANET</constant>, a server called <constant>MASSIVE</constant>, and a
1609         share called <constant>Apps</constant>. The underlying UNIX/Linux share point for this share is
1610         <filename>/data/apps</filename>.
1611         </para>
1612
1613         <procedure>
1614                 <step><para>
1615                 Click <menuchoice>
1616                         <guimenu>Start</guimenu>
1617                         <guimenuitem>[right-click] My Computer</guimenuitem>
1618                         <guimenuitem>Explore</guimenuitem>
1619                         <guimenuitem>[left panel] [+] My Network Places</guimenuitem>
1620                         <guimenuitem>[+] Entire Network</guimenuitem>
1621                         <guimenuitem>[+] Microsoft Windows Network</guimenuitem>
1622                         <guimenuitem>[+] Meganet</guimenuitem>
1623                         <guimenuitem>[+] Massive</guimenuitem>
1624                         <guimenuitem>[right-click] Apps</guimenuitem>
1625                         <guimenuitem>Properties</guimenuitem>
1626                         <guimenuitem>Security</guimenuitem>
1627                         <guimenuitem>Advanced</guimenuitem>
1628                 </menuchoice>. This opens a panel that has four tabs. Only the functionality under the 
1629                 <constant>Permissions</constant> tab can be utilized for a Samba domain server.
1630                 </para></step>
1631
1632             <step><para><indexterm>
1633                   <primary>full control</primary>
1634                 </indexterm><indexterm>
1635                   <primary>over-rule</primary>
1636                 </indexterm>
1637                 You may now edit/add/remove access control settings. Be very careful. Many problems have been
1638                 created by people who decided that everyone should be rejected but one particular group should
1639                 have full control. This is a catch-22 situation because members of that particular group also
1640                 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
1641                 set for the permitted group.
1642                 </para></step>
1643
1644                 <step><para>
1645                 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
1646                 buttons until the last panel closes.
1647                 </para></step>
1648         </procedure>
1649
1650         </sect3>
1651
1652         <sect3>
1653         <title>Setting Posix ACLs in UNIX/Linux</title>
1654
1655           <para><indexterm>
1656               <primary>desired security setting</primary>
1657             </indexterm><indexterm>
1658               <primary>shared resource</primary>
1659             </indexterm>
1660         Yet another alternative method for setting desired security settings on the shared resource files and
1661         directories can be achieved by logging into UNIX/Linux and setting POSIX ACLs directly using command-line
1662         tools. Here is an example session on the same resource as in the immediately preceding example on a SUSE 9
1663         Linux system:
1664         </para>
1665
1666         <procedure>
1667                 <step><para>
1668                 Log into the Linux system as the user <constant>root</constant>.
1669                 </para></step>
1670
1671                 <step><para>
1672                 Change directory to the location of the exported (shared) Windows file share (Apps), which is in
1673                 the directory <filename>/data</filename>. Execute the following:
1674 <screen>
1675 &rootprompt; cd /data
1676 </screen>
1677                 Retrieve the existing POSIX ACLs entry by executing:
1678 <screen>
1679 &rootprompt; getfacl apps
1680 # file: apps
1681 # owner: root
1682 # group: root
1683 user::rwx
1684 group::rwx
1685 other::r-x
1686 </screen>
1687                 </para></step>
1688
1689             <step><para><indexterm>
1690                   <primary>recursively</primary>
1691                 </indexterm>
1692                 You want to add permission for <constant>AppsMgrs</constant> to enable them to
1693                 manage the applications (apps) share. It is important to set the ACL recursively
1694                 so that the AppsMgrs have this capability throughout the directory tree that is 
1695                 being shared. This is done using the <constant>-R</constant> option as shown.
1696                 Execute the following:
1697 <screen>
1698 &rootprompt; setfacl -m -R group:AppsMgrs:rwx /data/apps
1699 </screen>
1700                 Because setting an ACL does not provide a response, you immediately validate the command executed
1701                 as follows:
1702 <screen>
1703 &rootprompt; getfacl /data/apps
1704 # file: apps
1705 # owner: root
1706 # group: root
1707 user::rwx
1708 group::rwx
1709 group:AppsMgrs:rwx
1710 mask::rwx
1711 other::r-x
1712 </screen>
1713                 This confirms that the change of POSIX ACL permissions has been effective.
1714                 </para></step>
1715
1716             <step><para><indexterm>
1717                   <primary>setfacl</primary>
1718                 </indexterm><indexterm>
1719                   <primary>getfacl</primary>
1720                 </indexterm><indexterm>
1721                   <primary>directory tree</primary>
1722                 </indexterm><indexterm>
1723                   <primary>Windows ACLs</primary>
1724                 </indexterm><indexterm>
1725                   <primary>inheritance</primary>
1726                 </indexterm>
1727                 It is highly recommended that you read the online manual page for the <command>setfacl</command>
1728                 and <command>getfacl</command> commands. This provides information regarding how to set/read the default
1729                 ACLs and how that may be propagated through the directory tree. In Windows ACLs terms, this is the equivalent
1730                 of setting <constant>inheritance</constant> properties.
1731                 </para></step>
1732         </procedure>
1733
1734         </sect3>
1735
1736         </sect2>
1737
1738         <sect2>
1739                 <title>Key Points Learned</title>
1740
1741                 <para>
1742                 The mish-mash of issues were thrown together into one chapter because it seemed like a good idea.
1743                 Looking back, this chapter could be broken into two, but it's too late now. It has been done.
1744                 The highlights covered are as follows:
1745                 </para>
1746
1747                 <itemizedlist>
1748           <listitem><para><indexterm>
1749                 <primary>Winbind</primary>
1750               </indexterm><indexterm>
1751                 <primary>Active Directory</primary>
1752               </indexterm><indexterm>
1753                 <primary>password change</primary>
1754               </indexterm><indexterm>
1755                 <primary>logon hours</primary>
1756               </indexterm>
1757                         Winbind honors and does not override account controls set in Active Directory.
1758                         This means that password change, logon hours, and so on, are (or soon will be) enforced
1759                         by Samba winbind. At this time, an out-of-hours login is denied and password
1760                         change is enforced. At this time, if logon hours expire, the user is not forcibly
1761                         logged off. That may be implemented at some later date.
1762                         </para></listitem>
1763
1764           <listitem><para><indexterm>
1765                 <primary>Sign'n'seal</primary>
1766               </indexterm><indexterm>
1767                 <primary>schannel</primary>
1768               </indexterm>
1769                         Sign'n'seal (plus schannel support) has been implemented in Samba-3. Beware of potential
1770                         problems acknowledged by Microsoft as having been fixed but reported by some as still
1771                         possibly an open issue.
1772                         </para></listitem>
1773
1774           <listitem><para><indexterm>
1775                 <primary>Kerberos</primary>
1776               </indexterm><indexterm>
1777                 <primary>OpenLDAP</primary>
1778               </indexterm><indexterm>
1779                 <primary>Active Directory</primary>
1780               </indexterm><indexterm>
1781                 <primary>inter-operability</primary>
1782               </indexterm>
1783                         The combination of Kerberos 5, plus OpenLDAP, plus Samba, cannot replace Microsoft
1784                         Active Directory. The possibility to do this is not planned in the current Samba-3
1785                         roadmap. Samba-3 does aim to provide further improvements in interoperability so that
1786                         UNIX/Linux systems may be fully integrated into Active Directory domains.
1787                         </para></listitem>
1788
1789                         <listitem><para>
1790                         This chapter reviewed mechanisms by which Samba servers may be kept secure. Each of
1791                         the four key methodologies was reviewed with specific reference to example deployment
1792                         techniques.
1793                         </para></listitem>
1794                 </itemizedlist>
1795
1796         </sect2>
1797
1798 </sect1>
1799
1800 <sect1>
1801         <title>Questions and Answers</title>
1802
1803         <para>
1804         </para>
1805
1806         <qandaset defaultlabel="chap10qa" type="number">
1807         <qandaentry>
1808         <question>
1809
1810             <para><indexterm>
1811                 <primary>Sign'n'seal</primary>
1812               </indexterm><indexterm>
1813                 <primary>registry hacks</primary>
1814               </indexterm>
1815                 Does Samba-3 require the <constant>Sign'n'seal</constant> registry hacks needed by Samba-2?
1816                 </para>
1817
1818         </question>
1819         <answer>
1820
1821             <para><indexterm>
1822                 <primary>schannel</primary>
1823               </indexterm><indexterm>
1824                 <primary>Sign'n'seal</primary>
1825               </indexterm><indexterm>
1826                 <primary>registry change</primary>
1827               </indexterm>
1828                 No. Samba-3 fully supports <constant>Sign'n'seal</constant> as well as <constant>schannel</constant>
1829                 operation. The registry change should not be applied when Samba-3 is used as a domain controller.
1830                 </para>
1831
1832         </answer>
1833         </qandaentry>
1834
1835         <qandaentry>
1836         <question>
1837
1838                 <para>
1839                 Does Samba-3 support Active Directory?
1840                 </para>
1841
1842         </question>
1843         <answer>
1844
1845             <para><indexterm>
1846                 <primary>Active Directory</primary>
1847               </indexterm>
1848                 Yes. Samba-3 can be a fully participating native mode Active Directory client. Samba-3 does not
1849                 provide Active Directory services. It cannot be used to replace a Microsoft Active Directory
1850                 server implementation. Samba-3 can function as an Active Directory client (workstation) toolkit,
1851                 and it can function as an Active Directory domain member server.
1852                 </para>
1853
1854         </answer>
1855         </qandaentry>
1856
1857         <qandaentry>
1858         <question>
1859
1860             <para><indexterm>
1861                 <primary>mixed-mode</primary>
1862               </indexterm>
1863                 When Samba-3 is used with Active Directory, is it necessary to run mixed-mode operation, as was
1864                 necessary with Samba-2?
1865                 </para>
1866
1867         </question>
1868         <answer>
1869
1870             <para><indexterm>
1871                 <primary>native</primary>
1872               </indexterm>
1873                 No. Samba-3 can be used with NetBIOS over TCP/IP disabled, just as can be done with Windows 200x
1874                 Server and 200x/XPPro client products. It is no longer necessary to run mixed-mode operation,
1875                 because Samba-3 can join a native Windows 2003 Server ADS domain.
1876                 </para>
1877
1878         </answer>
1879         </qandaentry>
1880
1881         <qandaentry>
1882         <question>
1883
1884             <para><indexterm>
1885                 <primary>share level access controls</primary>
1886               </indexterm>
1887                 Is it safe to set share-level access controls in Samba?
1888                 </para>
1889
1890         </question>
1891         <answer>
1892
1893                 <para>
1894                 Yes. Share-level access controls have been supported since early versions of Samba-2. This is
1895                 very mature technology. Not enough sites make use of this powerful capability, neither on
1896                 Windows server or with Samba servers.
1897                 </para>
1898
1899         </answer>
1900         </qandaentry>
1901
1902         <qandaentry>
1903         <question>
1904
1905             <para><indexterm>
1906                 <primary>share ACLs</primary>
1907               </indexterm>
1908                 Is it mandatory to set share ACLs to get a secure Samba-3 server?
1909                 </para>
1910
1911         </question>
1912         <answer>
1913
1914             <para><indexterm>
1915                 <primary>file system security</primary>
1916               </indexterm><indexterm>
1917                 <primary>Windows 200x ACLs</primary>
1918               </indexterm><indexterm>
1919                 <primary>share definition controls</primary>
1920               </indexterm><indexterm>
1921                 <primary>share level ACL</primary>
1922               </indexterm><indexterm>
1923                 <primary>security</primary>
1924               </indexterm>
1925                 No. Samba-3 honors UNIX/Linux file system security, supports Windows 200x ACLs, and provides 
1926                 means of securing shares through share definition controls in the &smb.conf; file. The additional
1927                 support for share-level ACLs is like frosting on the cake. It adds to security but is not essential
1928                 to it.
1929                 </para>
1930
1931         </answer>
1932         </qandaentry>
1933
1934         <qandaentry>
1935         <question>
1936
1937             <para><indexterm>
1938                 <primary>valid users</primary>
1939               </indexterm>
1940                 The <parameter>valid users</parameter> did not work on the <smbconfsection name="[homes]"/>.
1941                 Has this functionality been restored yet?
1942                 </para>
1943
1944         </question>
1945         <answer>
1946
1947             <para><indexterm>
1948                 <primary>meta-service</primary>
1949               </indexterm>
1950                 Yes. This was fixed in Samba-3.0.2. The use of this parameter is strongly recommended as a safeguard
1951                 on the <smbconfsection name="[homes]"/> meta-service. The correct way to specify this is:
1952                 <smbconfoption name="valid users">%S</smbconfoption>.
1953                 </para>
1954
1955         </answer>
1956         </qandaentry>
1957
1958         <qandaentry>
1959         <question>
1960
1961             <para><indexterm>
1962                 <primary>force user</primary>
1963               </indexterm><indexterm>
1964                 <primary>force group</primary>
1965               </indexterm><indexterm>
1966                 <primary>bias</primary>
1967               </indexterm>
1968                 Is the bias against use of the <parameter>force user</parameter> and <parameter>force group</parameter>
1969                 really warranted?
1970                 </para>
1971
1972         </question>
1973         <answer>
1974
1975             <para><indexterm>
1976                 <primary>performance</primary>
1977               </indexterm>
1978                 There is no bias. There is a determination to recommend the right tool for the task at hand.
1979                 After all, it is better than putting users through performance problems, isn't it?
1980                 </para>
1981
1982         </answer>
1983         </qandaentry>
1984
1985         <qandaentry>
1986         <question>
1987
1988                 <para>
1989                 The example given for file and directory access control forces all files to be owned by one
1990                 particular user. I do not like that. Is there any way I can see who created the file?
1991                 </para>
1992
1993         </question>
1994         <answer>
1995
1996             <para><indexterm>
1997                 <primary>SUID</primary>
1998               </indexterm>
1999                 Sure. You do not have to set the SUID bit on the directory. Simply execute the following command
2000                 to permit file ownership to be retained by the user who created it:
2001 <screen>
2002 &rootprompt; find /usr/data/finance -type d -exec chmod g+s {}\;
2003 </screen>
2004                 Note that this required no more than removing the <constant>u</constant> argument so that the
2005                 SUID bit is not set for the owner.
2006                 </para>
2007
2008         </answer>
2009         </qandaentry>
2010
2011         <qandaentry>
2012         <question>
2013
2014             <para><indexterm>
2015                 <primary>Computer Management</primary>
2016               </indexterm>
2017                 In the book, <quote>The Official Samba-3 HOWTO and Reference Guide</quote>, you recommended use
2018                 of the Windows NT4 Server Manager (part of the <filename>SRVTOOLS.EXE</filename>) utility. Why
2019                 have you mentioned only the use of the Windows 200x/XP MMC Computer Management utility?
2020                 </para>
2021
2022         </question>
2023         <answer>
2024
2025             <para><indexterm>
2026                 <primary>MMC</primary>
2027               </indexterm><indexterm>
2028                 <primary>SRVTOOLS.EXE</primary>
2029               </indexterm>
2030                 Either tool can be used with equal effect. There is no benefit of one over the other, except that
2031                 the MMC utility is present on all Windows 200x/XP systems and does not require additional software
2032                 to be downloaded and installed. Note that if you want to manage user and group accounts in your
2033                 Samba-controlled domain, the only tool that permits that is the NT4 Domain User Manager, which
2034                 is provided as part of the <filename>SRVTOOLS.EXE</filename> utility.
2035                 </para>
2036
2037         </answer>
2038         </qandaentry>
2039
2040         <qandaentry>
2041         <question>
2042
2043             <para><indexterm>
2044                 <primary>valid users</primary>
2045               </indexterm><indexterm>
2046                 <primary>Active Directory</primary>
2047               </indexterm><indexterm>
2048                 <primary>Domain Member server</primary>
2049               </indexterm>
2050                 I tried to set <parameter>valid users = @Engineers</parameter>, but it does not work. My Samba
2051                 server is an Active Directory domain member server. Has this been fixed now?
2052                 </para>
2053
2054         </question>
2055         <answer>
2056
2057                 <para>
2058                 The use of this parameter has always required the full specification of the domain account, for
2059                 example, <parameter>valid users = @"MEGANET2\Domain Admins"</parameter>.
2060                 </para>
2061
2062         </answer>
2063         </qandaentry>
2064
2065         </qandaset>
2066
2067 </sect1>
2068
2069 </chapter>
2070