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>
7 <primary>experiment</primary>
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.
17 <primary>criticism</primary>
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.
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.
32 <primary>straw-man</primary>
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.
42 <title>Introduction</title>
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>
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 has been recently acquired.
61 During the time that the acquisition was closing, the Video Rentals business upgraded their Windows
62 NT4-based network to Windows 2003 Server and Active Directory.
66 <primary>Active Directory</primary>
68 Bob Jordan has been accepting of 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 their 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.
78 <primary>consultant</primary>
79 </indexterm><indexterm>
80 <primary>hypothetical</primary>
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
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>
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.
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>
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.
131 <primary>compromise</primary>
132 </indexterm><indexterm>
133 <primary>secure</primary>
134 </indexterm><indexterm>
135 <primary>network</primary>
136 <secondary>secure</secondary>
138 Your staff are justifiably concerned that the use of Samba may compromise their good efforts to maintain
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>
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 as it voids this fine work.
161 <primary>isolated</primary>
162 </indexterm><indexterm>
163 <primary>firewall</primary>
164 </indexterm><indexterm>
165 <primary>best practices</primary>
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.
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>
188 In respect of 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, 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 capabilites of Microsoft Windows NT4 server. Microsoft has moved well beyond that
194 with trusted computing initiatives that the Samba developers do not participate in.
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>
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.
218 <primary>employment</primary>
219 </indexterm><indexterm>
220 <primary>jobs</primary>
221 </indexterm><indexterm>
222 <primary>risk</primary>
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.
229 <primary>Active Directory</primary>
230 </indexterm><indexterm>
231 <primary>independent expert</primary>
233 This is also a challenge to rise above the trouble spot. Bob calls Stan's team together for a simple
234 discussion, but it gets further out of hand. When he returns to his office, he finds the following
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.
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.
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>
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.
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>
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 non-compliance the financial responsibility of the
286 out-of-step division. Hopefully, this will encourage all divisions to walk with us and not alone.
290 <title>Assignment Tasks</title>
293 Bob agreed with Stan's recommendations and has hired your services to help defuse the powder
294 keg. Your task is to answer each of the issues raised with a tractable answer. You must be able
295 to support your claims, keep emotions to a side, and answer technically.
302 <title>Dissection and Discussion</title>
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>
319 Samba-3 is a tool. No one pounding your door to 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 benefit your company more than
321 anyone else. 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.
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>
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.
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>
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 are fully cognizant of the responsibility they have to their users.
357 The Samba documentation clearly reveals the fact that full responsibility is accepted to fix anything
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>
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>
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.
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>
407 The real issues that a consumer (like you) needs answered is 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?
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>
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/fix the problem.
433 <title>Technical Issues</title>
436 Each issue is now discussed and, where appropriate, example implementation steps are
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>
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 onto 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.
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>
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.
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>
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.
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>
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
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>
544 Examples of each are given in <link linkend="ch10expl"/>.
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>
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.
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>
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.
606 <primary>diligence</primary>
607 </indexterm><indexterm>
608 <primary>weakness</primary>
610 The report that is critical of Samba really ought to have exercised greater due
611 diligence, as the real weakness is on the side of a Microsoft Windows environment.
616 <term>Security Overall</term>
617 <listitem><para><indexterm>
618 <primary>defects</primary>
620 Samba has been 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.
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>
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.
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>
658 The report condemns Samba for releasing updates and security fixes, yet Microsoft
659 on-line updates need to be applied almost weekly. The answer to the criticism made
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.
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>
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 would suggest a high
681 degree of dependability as well as on charter development consistent with published
682 road-map projections.
686 <primary>foundation members</primary>
687 </indexterm><indexterm>
688 <primary>Common Internet File System</primary>
690 </indexterm><indexterm>
691 <primary>network attached storage</primary>
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>
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
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>
722 The report correctly mentions the fact 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 snap-shot in time.
728 Meanwhile, the world moves on.
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>
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 this 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
758 <primary>Critics</primary>
759 </indexterm><indexterm>
760 <primary>digital sign'n'seal</primary>
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 appears even today<footnote>January 2004</footnote> to not be sure that the problem has been resolved.
770 So it is evident that some delay in release of new functionality may have
771 fortuitous consequences.
775 <primary>secure networking protocols</primary>
776 </indexterm><indexterm>
777 <primary>refereed standards</primary>
778 </indexterm><indexterm>
779 <primary>proprietary</primary>
780 </indexterm><indexterm>
781 <primary>digital rights</primary>
782 </indexterm><indexterm>
783 <primary>protection</primary>
784 </indexterm><indexterm>
785 <primary>networking protocols</primary>
786 </indexterm><indexterm>
787 <primary>diffusion</primary>
788 </indexterm><indexterm>
789 <primary>consumer</primary>
790 </indexterm><indexterm>
791 <primary>choice</primary>
793 One final comment is warranted. If companies want more secure networking protocols,
794 the most effective method by which this can be achieved is by users seeking
795 and working together to help define open and publicly refereed standards. The
796 development of closed source, proprietary methods that are developed in a
797 clandestine framework of secrecy, under claims of digital rights protection, does
798 not favor the diffusion of safe networking protocols, and certainly does not
799 help the consumer to make a better choice.
804 <term>Active Directory Replacement with Kerberos, LDAP, and Samba</term>
806 <primary>Active Directory</primary>
807 <secondary>Replacement</secondary>
808 </indexterm><indexterm>
809 <primary>Kerberos</primary>
810 </indexterm><indexterm>
811 <primary>LDAP</primary>
812 </indexterm><indexterm>
813 <primary>remote procedure call</primary>
817 <literallayout> </literallayout>
818 The Microsoft networking protocols extensively make use of remote procedure call (RPC)
819 technology. Active Directory is not a simple mixture of LDAP and Kerberos together
820 with file and print services, but rather is a complex intertwined implementation
821 of them that uses RPCs that are not supported by any of these component technologies
822 and yet by which they are made to interoperate in ways that the components do not
827 <primary>Active Directory</primary>
828 <secondary>Server</secondary>
829 </indexterm><indexterm>
830 <primary>OpenLDAP</primary>
831 </indexterm><indexterm>
832 <primary>Kerberos</primary>
833 </indexterm><indexterm>
834 <primary>project maintainers</primary>
835 </indexterm><indexterm>
836 <primary>LDAP</primary>
838 In order to make the popular request for Samba to be an Active Directory Server a
839 reality, it is necessary to add to OpenLDAP, Kerberos, as well as Samba, RPC calls
840 that are not presently supported. The Samba Team has not been able to gain critical
841 overall support for all project maintainers to work together on the complex
842 challenge of developing and integrating the necessary technologies. Therefore, if
843 the Samba Team does not make it a priority to absorb Kerberos and LDAP functionality
844 into the Samba project, this dream request can not become a reality.
848 <primary>missing RPC's</primary>
849 </indexterm><indexterm>
850 <primary>road-map</primary>
851 </indexterm><indexterm>
852 <primary>ADS</primary>
853 <secondary>server</secondary>
854 </indexterm><indexterm>
855 <primary>MMC</primary>
856 </indexterm><indexterm>
857 <primary>managed</primary>
859 At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the
860 Samba development roadmap. If it is not on the published roadmap, it cannot be delivered
861 anytime soon. Ergo, ADS server support is not a current goal for Samba development.
862 The Samba Team is most committed to permitting Samba to be a full ADS Domain member
863 that is increasingly capable of being managed using Microsoft Windows MMC tools.
869 <title>Kerberos Exposed</title>
872 <primary>kerberos</primary>
873 </indexterm><indexterm>
874 <primary>unauthorized activities</primary>
875 </indexterm><indexterm>
876 <primary>authorized location</primary>
878 Kerberos is a network authentication protocol that provides secure authentication for
879 client-server applications by using secret-key cryptography. Firewalls are an insufficient
880 barrier mechanism in todays networking world as at best they only restrict incoming network
881 traffic but can not prevent network traffic that comes from authorized locations from
882 performing unauthorized activities.
886 <primary>strong cryptography</primary>
887 </indexterm><indexterm>
888 <primary>identity</primary>
889 </indexterm><indexterm>
890 <primary>integrity</primary>
892 Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses
893 strong cryptography so that a client can prove its identity to a server (and vice versa) across an
894 insecure network connection. After a client and server has used Kerberos to prove their identity,
895 they can also encrypt all of their communications to assure privacy and data integrity as they go
896 about their business.
900 <primary>trusted third-party</primary>
901 </indexterm><indexterm>
902 <primary>principals</primary>
903 </indexterm><indexterm>
904 <primary>trusting</primary>
905 </indexterm><indexterm>
906 <primary>kerberos</primary>
907 <secondary>server</secondary>
908 </indexterm><indexterm>
909 <primary>secret</primary>
911 Kerberos is a trusted third-party service. That means that there is a third party (the kerberos
912 server) that is trusted by all the entities on the network (users and services, usually called
913 principals). All principals share a secret password (or key) with the kerberos server and this
914 enables principals to verify that the messages from the kerberos server are authentic. Thus
915 trusting the kerberos server, users and services can authenticate each other.
919 <primary>restricted export</primary>
920 </indexterm><indexterm>
921 <primary>MIT Kerberos</primary>
922 </indexterm><indexterm>
923 <primary>Heimdal Kerberos</primary>
925 Kerberos was until recently a technology that was restricted from being exported from the United States.
926 For many years that hindered global adoption of more secure networking technologies both within the USA
927 as well as outside it. A free an unencumbered implementation of MIT Kerberos has been produced in Europe
928 and is available from the University of Paderborn, Sweden. It is known as the Heimdal Kerberos project.
929 In recent times the USA government has removed sanctions affecting the global distribution of MIT Kerberos.
930 It is likely that there will be a significant surge forward in the development of Kerberos enabled applications
931 and in the general deployment and use of Kerberos across the spectrum of the information technology industry.
935 <primary>Kerberos</primary>
936 <secondary>interoperability</secondary>
938 A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation
939 of it. For example, a 2002 new report by <ulink url="http://www.idg.com.sg/idgwww.nsf/0/5DDA8D153A7505A748256BAB000D992A?OpenDocument">IDG</ulink>
944 A Microsoft Corp. executive testified at the software giant's remedy hearing that the company goes to
945 great lengths to disclose interfaces and protocols that allow third-party software products to interact
946 with Windows. But a lawyer with the states suing Microsoft pointed out that when it comes to the company's
947 use of the Kerberos authentication specification, not everyone agrees.
951 <primary>Kerberos</primary>
952 <secondary>unspecified fields</secondary>
954 Robert Short, vice president of Windows core technology at Microsoft, wrote in his direct testimony prepared
955 before his appearance that non-Microsoft operating systems can disregard the portion of the Kerberos version
956 5 specification that Windows clients use for proprietary purposes and still achieve interoperability with
957 the Microsoft OS. Microsoft takes advantage of unspecified fields in the Kerberos specification for storing
958 Windows-specific authorization data, Short wrote. The designers of Kerberos left these fields undefined so
959 that software developers could add their own authorization information, he said.
963 <primary>DCE</primary>
964 </indexterm><indexterm>
965 <primary>RPC</primary>
967 It so happens that Microsoft Windows clients depend on and expect the contents of the <emphasis>unspecified
968 fields</emphasis> in the Kerberos 5 communications data stream for their Windows interoperability, in
969 particular when Samba is being expected to emulate a Windows Server 200x Domain Controller. But the interoperability
970 issue goes far deeper than this. In the Domain control protocols that are used by MS Windows XP Professional
971 there is a tight interdependency between the Kerberos protocols and the Microsoft distributed computing environment
972 (DCE) remote procedure calls (RPCs) that themselves are an integral part of the SMB/CIFS protocols as used by
977 Microsoft makes the following comment in a reference in a <ulink url="http://www.microsoft.com/technet/itsolutions/interop/mgmt/kerberos.asp">
978 technet</ulink> article:
981 <blockquote><para><indexterm>
982 <primary>Privilege Attribute Certificates</primary>
984 </indexterm><indexterm>
985 <primary>access control</primary>
987 The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC
988 representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos
989 tickets to convey Privilege Attribute Certificates (PACs) that define user identity and group membership.
990 The DCE PAC is used in a similar manner as Windows NT Security IDs for user authorization and access control.
991 Windows NT services will not be able to translate DCE PACs into Windows NT user and group identifiers. This
992 is not an issue with Kerberos interoperability, but rather an issue of interoperability between DCE and
993 Windows NT access control information.
1002 <sect1 id="ch10expl">
1003 <title>Implementation</title>
1006 The following procedures outline the implementation of the security measures discussed so far.
1010 <title>Share Access Controls</title>
1013 <primary>Share Access Controls</primary>
1014 </indexterm><indexterm>
1015 <primary>filter</primary>
1016 </indexterm><indexterm>
1017 <primary>connection</primary>
1019 Access control entries placed on the share itself act as a filter at the time a when CIFS/SMB client (such as
1020 Windows XP Pro) attempts to make a connection to the Samba server.
1024 <title>Create/Edit/Delete Share ACLs</title>
1025 <step><para><indexterm>
1026 <primary>Domain Administrator</primary>
1027 </indexterm><indexterm>
1028 <primary>account</primary>
1030 From a Windows 200x/XP Professional workstation, log onto the Domain using the Domain Administrator
1031 account (on Samba Domains, this is usually the account called <constant>root</constant>).
1037 <guimenu>Start</guimenu>
1038 <guimenuitem>Settings</guimenuitem>
1039 <guimenuitem>Control Panel</guimenuitem>
1040 <guimenuitem>Administrative Tools</guimenuitem>
1041 <guimenuitem>Computer Management</guimenuitem>
1048 <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu>
1049 <guimenuitem>Connect to another computer ...</guimenuitem>
1050 <guimenuitem>Browse...</guimenuitem>
1051 <guimenuitem>Advanced</guimenuitem>
1052 <guimenuitem>Find Now</guimenuitem>
1053 </menuchoice>. In the lower panel, click on the name of the server you wish to
1054 administer. Click <menuchoice>
1055 <guimenu>OK</guimenu>
1056 <guimenuitem>OK</guimenuitem>
1057 <guimenuitem>OK</guimenuitem>
1058 </menuchoice>.<indexterm>
1059 <primary>Computer Management</primary>
1061 In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect
1062 the change made. For example, if the server you are administering is called <constant>FRODO</constant>,
1063 the Computer Management entry should now say: <guimenu>Computer Management (FRODO)</guimenu>.
1067 In the left panel, click <menuchoice>
1068 <guimenu>Computer Management (FRODO)</guimenu>
1069 <guimenuitem>[+] Shared Folders</guimenuitem>
1070 <guimenuitem>Shares</guimenuitem>
1074 <step><para><indexterm>
1075 <primary>ACLs</primary>
1076 </indexterm><indexterm>
1077 <primary>Share Permissions</primary>
1079 In the right panel, double-click on the share on which you wish to set/edit ACLs. This
1080 will bring up the Properties panel. Click the <guimenu>Share Permissions</guimenu> tab.
1083 <step><para><indexterm>
1084 <primary>access control settings</primary>
1085 </indexterm><indexterm>
1086 <primary>Everyone</primary>
1087 </indexterm><indexterm>
1088 <primary>full control</primary>
1089 </indexterm><indexterm>
1090 <primary>over-rule</primary>
1091 </indexterm><indexterm>
1092 <primary>permissions</primary>
1093 </indexterm><indexterm>
1094 <primary>rejected</primary>
1096 You may now edit/add/remove access control settings. Be very careful. Many problems have been
1097 created by people who decided that Everyone should be rejected but one particular group should
1098 have full control. This is a catch-22 situation because members of that particular group also
1099 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
1100 set for the permitted group.
1104 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
1112 <title>Share Definition Controls</title>
1115 <primary>Share Definition</primary>
1116 <secondary>Controls</secondary>
1117 </indexterm><indexterm>
1118 <primary>check-point</primary>
1119 </indexterm><indexterm>
1120 <primary>pile-driver</primary>
1121 </indexterm><indexterm>
1122 <primary>credential</primary>
1123 </indexterm><indexterm>
1124 <primary>powers</primary>
1125 </indexterm><indexterm>
1126 <primary>privileges</primary>
1128 Share-definition-based access controls can be used like a check-point or like a pile-driver. Just as a
1129 check-point can be used to require someone who wants to get through to meet certain requirements, so
1130 it is possible to require the user (or group the user belongs to) to meet specified credential-related
1131 objectives. It can be likened to a pile-driver by overriding default controls, in that having met the
1132 credential-related objectives, the user can be granted powers and privileges that would not normally be
1133 available under default settings.
1137 <primary>access controls</primary>
1138 </indexterm><indexterm>
1139 <primary>ACLs</primary>
1140 </indexterm><indexterm>
1141 <primary>share definition controls</primary>
1142 </indexterm><indexterm>
1143 <primary>hierarchy of control</primary>
1145 It must be emphasized that the controls here discussed can act as a filter, or give rights of passage,
1146 that act as a super-structure over normal directory and file access controls. However, share level
1147 ACLs act at a higher level than to share definition controls because the user must filter through the
1148 share level controls to get to the share definition controls. The proper hierarchy of controls implemented
1149 by Samba and Windows networking consists of:
1153 <listitem><para>Share Level ACLs</para></listitem>
1154 <listitem><para>Share Definition Controls</para></listitem>
1155 <listitem><para>Directory and File Permissions</para></listitem>
1156 <listitem><para>Directory and File Posix ACLs</para></listitem>
1160 <title>Check-point Controls</title>
1163 <primary>Check-point Controls</primary>
1165 Consider the following extract from a &smb.conf; file defining the share called <constant>Apps</constant>:
1168 comment = Application Share
1171 valid users = @Employees
1173 This definition permits only those who are members of the group called <constant>Employees</constant> to
1177 <note><para><indexterm>
1178 <primary>Domain Member</primary>
1179 <secondary>servers</secondary>
1180 </indexterm><indexterm>
1181 <primary>winbind use default domain</primary>
1182 </indexterm><indexterm>
1183 <primary>fully qualified</primary>
1184 </indexterm><indexterm>
1185 <primary>valid users</primary>
1186 </indexterm><indexterm>
1187 <primary>delimiter</primary>
1189 On Domain Member servers and clients, even when the <parameter>winbind use default domain</parameter> has
1190 been specified, the use of Domain accounts in security controls requires fully qualified Domain specification,
1191 for example, <smbconfoption name="valid users">@"MEGANET\Northern Engineers"</smbconfoption>.
1192 Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a
1197 <primary>ACL</primary>
1198 </indexterm><indexterm>
1199 <primary>access</primary>
1200 </indexterm><indexterm>
1201 <primary>validate</primary>
1203 If there is an ACL on the share itself to permit read/write access for all <constant>Employees</constant>
1204 as well as read/write for the group <constant>Doctors</constant>, both groups are permitted through
1205 to the share. However, at the moment an attempt is made to set up a connection to the share, a member of
1206 the group <constant>Doctors</constant>, who is not also a member of the group <constant>Employees</constant>,
1207 would immediately fail to validate.
1211 <primary>share definition controls</primary>
1213 Consider another example. In this case, you want to permit all members of the group <constant>Employees</constant>
1214 to access the <constant>Apps</constant> share, except the user <constant>patrickj</constant>. This can be
1215 easily achieved by setting a share level ACL permitting only <constant>Employees</constant> to access the share,
1216 and then in the share definition controls excluding just <constant>patrickj</constant>. Here is how that might
1220 comment = Application Share
1223 invalid users = patrickj
1226 <primary>permissions</primary>
1228 Let us assume that you want to permit the user <constant>gbshaw</constant>, to manage any file in the
1229 UNIX/Linux file system directory <filename>/data/apps</filename>, but you do not want to grant any write
1230 permissions beyond that directory tree. Here is one way this can be done:
1233 comment = Application Share
1236 invalid users = patrickj
1237 admin users = gbshaw
1240 <primary>administrative rights</primary>
1242 Now we have a set of controls that permits only <constant>Employees</constant> who are also members of
1243 the group <constant>Doctors</constant>, excluding the user <constant>patrickj</constant>, to have
1244 read-only privilege, but the user <constant>gbshaw</constant> is granted administrative rights.
1245 The administrative rights conferred upon the user <constant>gbshaw</constant> permit operation as
1246 if that user has logged in as the user <constant>root</constant> on the UNIX/Linux system, and thus
1247 for access to the directory tree that has been shared (exported) permit the user to override controls
1248 that apply to all other users on that resource.
1252 There are additional check-point controls that may be used. For example, if for the same share we now
1253 want to provide the user <constant>peters</constant> with the ability to write to one directory to
1254 which he has write privilege in the UNIX file system, you can specifically permit that with the
1258 comment = Application Share
1261 invalid users = patrickj
1262 admin users = gbshaw
1266 <primary>check-point controls</primary>
1268 This is a particularly complex example at this point, but it begins to demonstrate the possibilities.
1269 You should refer to the on-line manual page for the &smb.conf; file for more information regarding
1270 the check-point controls that Samba implements.
1276 <title>Override Controls</title>
1279 <primary>over-ride controls</primary>
1281 Override controls implemented by Samba permit actions like the adoption of a different identity
1282 during file system operations, the forced overwriting of normal file and directory permissions,
1283 and so on. You should refer to the on-line manual page for the &smb.conf; file for more information regarding
1284 the override controls that Samba implements.
1288 In the following example, you want to create a Windows networking share that any user can access.
1289 However, you want all read and write operations to be performed as if the user <constant>billc</constant>
1290 and member of the group <constant>Mentors</constant> read/write the files. Here is one way this
1294 comment = Some Files Everyone May Overwrite
1295 path = /data/somestuff
1298 force group = Mentors
1301 <primary>forced settings</primary>
1302 </indexterm><indexterm>
1303 <primary>overheads</primary>
1305 That is all there is to it. Well, it is almost that simple. The downside of this method is that
1306 users are logged onto the Windows client as themselves, and then immediately before accessing the
1307 file, Samba makes system calls to change the effective user and group to the forced settings
1308 specified, completes the file transaction, and then reverts to the actually logged on identity.
1309 This imposes significant overhead on Samba. The alternative way that effectively the same result
1310 can be achieved (but with lower system CPU overheads) is described next.
1314 <primary>force user</primary>
1315 </indexterm><indexterm>
1316 <primary>force group</primary>
1317 </indexterm><indexterm>
1318 <primary>opportunistic</primary>
1319 <secondary>locking</secondary>
1320 </indexterm><indexterm>
1321 <primary>oplock break</primary>
1322 </indexterm><indexterm>
1323 <primary>performance degradation</primary>
1325 The use of the <parameter>force user</parameter>, or the <parameter>force group</parameter>, may
1326 also have a severe impact on system (and in particular Windows client) performance. If opportunistic
1327 locking is enabled on the share (the default), it causes an <constant>oplock break</constant> to be
1328 sent to the client, even if the client has not opened the file. On networks that have high traffic
1329 density, or on links that are routed to a remote network segment, <constant>oplock breaks</constant>
1330 can be lost. This results in possible retransmission of the request, or the client may time-out while
1331 waiting for the file system transaction (read or write) to complete. The result can be a profound
1332 apparent performance degradation as the client continually attempts to reconnect to overcome the
1333 effect of the lost <constant>oplock break</constant>, or time-out.
1341 <title>Share Point Directory and File Permissions</title>
1344 <primary>security</primary>
1345 </indexterm><indexterm>
1346 <primary>privilege controls</primary>
1347 </indexterm><indexterm>
1348 <primary>permission</primary>
1349 </indexterm><indexterm>
1350 <primary>share definition controls</primary>
1352 Samba has been designed and implemented so that it respects as far as is feasible the security and
1353 user privilege controls that are built into the UNIX/Linux operating system. Samba does nothing
1354 with respect to file system access that violates file system permission settings, unless it is
1355 explicitly instructed to do otherwise through share definition controls. Given that Samba obeys
1356 UNIX file system controls, this chapter does not document simple information that can be obtained
1357 from a basic UNIX training guide. Instead, one common example of a typical problem is used
1358 to demonstrate the most effective solution referred to in the immediately preceding paragraph.
1362 <primary>Microsoft Office</primary>
1363 </indexterm><indexterm>
1364 <primary>Word</primary>
1365 </indexterm><indexterm>
1366 <primary>Excel</primary>
1368 One of the common issues that repeatedly pops up on the Samba mailing lists involves the saving of
1369 Microsoft Office files (Word and Excel) to a network drive. Here is the typical sequence:
1374 A user opens a Work document from a network drive. The file was owned by user <constant>janetp</constant>
1375 and <group>users</group>, and was set read/write enabled for everyone.
1379 File changes and edits are made.
1383 The file is saved, and MS Word is closed.
1387 The file is now owned by the user <constant>billc</constant> and group <constant>doctors</constant>,
1388 and is set read/write by <constant>billc</constant>, read only by <constant>doctors</constant>, and
1389 no access by everyone.
1393 The original owner can not now access her own file and is <quote>justifiably</quote> upset.
1398 There have been many postings over the years that report the same basic problem. Frequently Samba users
1399 want to know when this <quote>bug</quote> will be fixed. The fact is, this is not a bug in Samba at all.
1400 Here is the real sequence of what happens in the case mentioned above.
1404 <primary>MS Word</primary>
1405 </indexterm><indexterm>
1406 <primary>ownership</primary>
1407 </indexterm><indexterm>
1408 <primary>permissions</primary>
1410 When the user saves a file, MS Word creates a new (temporary) file. This file is naturally owned
1411 by the user who creates the file (<constant>billc</constant>) and has the permissions that follow
1412 that user's default settings within the operating system (UNIX/Linux). When MS Word has finished writing
1413 the file to disk, it then renames the new (temporary) file to the name of the old one. MS Word does not
1414 change the ownership or permissions to what they were on the original file. The file is thus a totally
1415 new file, and the old one has been deleted in the process.
1419 Samba received a request to create a new file, and then to rename the file to a new name. The old file that
1420 has the same name is now automatically deleted. Samba has no way of knowing that the new file should
1421 perhaps have the same ownership and permissions as the old file. To Samba, these are entirely independent
1426 The question is: <quote>How can we solve the problem?</quote>
1430 The solution is simple. Use UNIX file system permissions and controls to your advantage. Follow these
1431 simple steps to create a share in which all files will consistently be owned by the same user and the
1437 <title>Using Directory Permissions to Force File User and Group Ownership</title>
1439 Change your share definition so that it matches this pattern:
1442 path = /usr/data/finance
1448 <step><para><indexterm>
1449 <primary>permissions</primary>
1450 <secondary>user</secondary>
1451 </indexterm><indexterm>
1452 <primary>permissions</primary>
1453 <secondary>group</secondary>
1455 Set consistent user and group permissions recursively down the directory tree as shown here:
1457 &rootprompt; chown -R janetp.users /usr/data/finance
1461 <step><para><indexterm>
1462 <primary>accessible</primary>
1464 Set the files and directory permissions to be read/write for owner and group, and not accessible
1465 to others (everyone) using the following command:
1467 &rootprompt; chmod ug+rwx,o-rwx /usr/data/finance
1471 <step><para><indexterm>
1472 <primary>SGID</primary>
1474 Set the SGID (super-group) bit on all directories from the top down. This means all files
1475 can be created with the permissions of the group set on the directory. It means all users
1476 who are members of the group <constant>finance</constant> can read and write all files in
1477 the directory. The directory is not readable or writable by anyone who is not in the
1478 <constant>finance</constant> group. Simply follow this example:
1480 &rootprompt; find /usr/data/finance -type d -exec chmod ug+s {}\;
1485 <step><para><indexterm>
1486 <primary>group membership</primary>
1487 </indexterm><indexterm>
1488 <primary>primary group</primary>
1489 </indexterm><indexterm>
1490 <primary>/etc/passwd</primary>
1492 Make sure all users that must have read/write access to the directory have
1493 <constant>finance</constant> group membership as their primary group,
1494 for example, the group they belong to in <filename>/etc/passwd</filename>.
1501 <title>Managing Windows 200x ACLs</title>
1504 <primary>translate</primary>
1505 </indexterm><indexterm>
1506 <primary>Windows 2000 ACLs</primary>
1507 </indexterm><indexterm>
1508 <primary>Posix ACLs</primary>
1509 </indexterm><indexterm>
1510 <primary>side effects</primary>
1512 Samba must translate Windows 2000 ACLs to UNIX Posix ACLs. This has some interesting side effects because
1513 of the fact that there is not a 1:1 equivalence between them. The as-close-as-possible ACLs match means
1514 that some transactions are not possible from MS Windows clients. One of these is to reset the ownership
1515 of directories and files. If you want to reset ownership, this must be done from a UNIX/Linux login.
1519 There are two possible ways to set ACLs on UNIX/Linux file systems from a Windows network workstation,
1520 either via File Manager or via the Microsoft Management Console (MMC) Computer Management interface.
1524 <title>Using the MMC Computer Management Interface</title>
1528 From a Windows 200x/XP Professional workstation, log onto the Domain using the Domain Administrator
1529 account (on Samba Domains, this is usually the account called <constant>root</constant>).
1535 <guimenu>Start</guimenu>
1536 <guimenuitem>Settings</guimenuitem>
1537 <guimenuitem>Control Panel</guimenuitem>
1538 <guimenuitem>Administrative Tools</guimenuitem>
1539 <guimenuitem>Computer Management</guimenuitem>
1546 <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu>
1547 <guimenuitem>Connect to another computer ...</guimenuitem>
1548 <guimenuitem>Browse...</guimenuitem>
1549 <guimenuitem>Advanced</guimenuitem>
1550 <guimenuitem>Find Now</guimenuitem>
1551 </menuchoice>. In the lower panel, click on the name of the server you wish to
1552 administer. Click <menuchoice>
1553 <guimenu>OK</guimenu>
1554 <guimenuitem>OK</guimenuitem>
1555 <guimenuitem>OK</guimenuitem>
1557 In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect
1558 the change made. For example, if the server you are administering is called <constant>FRODO</constant>,
1559 the Computer Management entry should now say: <guimenu>Computer Management (FRODO)</guimenu>.
1563 In the left panel, click <menuchoice>
1564 <guimenu>Computer Management (FRODO)</guimenu>
1565 <guimenuitem>[+] Shared Folders</guimenuitem>
1566 <guimenuitem>Shares</guimenuitem>
1570 <step><para><indexterm>
1571 <primary>Security</primary>
1572 </indexterm><indexterm>
1573 <primary>Properties</primary>
1574 </indexterm><indexterm>
1575 <primary>Permissions</primary>
1576 </indexterm><indexterm>
1577 <primary>Samba Domain server</primary>
1579 In the right panel, double-click on the share on which you wish to set/edit ACLs. This
1580 brings up the Properties panel. Click the <guimenu>Security</guimenu> tab. It is best
1581 to edit ACLs using the <constant>Advanced</constant> editing features. Click the
1582 <guimenu>Advanced</guimenu> button. This opens a panel that has four tabs. Only the
1583 functionality under the <constant>Permissions</constant> tab can be utilized with respect
1584 to a Samba Domain server.
1587 <step><para><indexterm>
1588 <primary>access control</primary>
1589 </indexterm><indexterm>
1590 <primary>permitted group</primary>
1592 You may now edit/add/remove access control settings. Be very careful. Many problems have been
1593 created by people who decided that Everyone should be rejected but one particular group should
1594 have full control. This is a catch-22 situation because members of that particular group also
1595 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
1596 set for the permitted group.
1600 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
1601 buttons until the last panel closes.
1608 <title>Using MS Windows Explorer (File Manager)</title>
1611 The following alternative method may be used from a Windows workstation. In this example we work
1612 with a Domain called <constant>MEGANET</constant>, a server called <constant>MASSIVE</constant>, and a
1613 share called <constant>Apps</constant>. The underlying UNIX/Linux share point for this share is
1614 <filename>/data/apps</filename>.
1620 <guimenu>Start</guimenu>
1621 <guimenuitem>[right-click] My Computer</guimenuitem>
1622 <guimenuitem>Explore</guimenuitem>
1623 <guimenuitem>[left panel] [+] My Network Places</guimenuitem>
1624 <guimenuitem>[+] Entire Network</guimenuitem>
1625 <guimenuitem>[+] Microsoft Windows Network</guimenuitem>
1626 <guimenuitem>[+] Meganet</guimenuitem>
1627 <guimenuitem>[+] Massive</guimenuitem>
1628 <guimenuitem>[right-click] Apps</guimenuitem>
1629 <guimenuitem>Properties</guimenuitem>
1630 <guimenuitem>Security</guimenuitem>
1631 <guimenuitem>Advanced</guimenuitem>
1632 </menuchoice>. This opens a panel that has four tabs. Only the functionality under the
1633 <constant>Permissions</constant> tab can be utilized in respect to a Samba Domain server.
1636 <step><para><indexterm>
1637 <primary>full control</primary>
1638 </indexterm><indexterm>
1639 <primary>over-rule</primary>
1641 You may now edit/add/remove access control settings. Be very careful. Many problems have been
1642 created by people who decided that Everyone should be rejected but one particular group should
1643 have full control. This is a catch-22 situation because members of that particular group also
1644 belong to the group <constant>Everyone</constant>, which therefore overrules any permissions
1645 set for the permitted group.
1649 When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu>
1650 buttons until the last panel closes.
1657 <title>Setting Posix ACLs in UNIX/Linux</title>
1660 <primary>desired security setting</primary>
1661 </indexterm><indexterm>
1662 <primary>shared resource</primary>
1664 Yet another alternative method for setting desired security settings on the shared resource files and
1665 directories can be achieved by logging into UNIX/Linux and setting Posix ACLs directly using command-line
1666 tools. Here is an example session on the same resource as in the immediately preceding example on a SUSE 9
1672 Log into the Linux system as the user <constant>root</constant>.
1676 Change directory to the location of the exported (shared) Windows file share (Apps), which is in
1677 the directory <filename>/data</filename>. Execute the following:
1679 &rootprompt; cd /data
1681 Retrieve the existing Posix ACLs entry by executing:
1683 &rootprompt; getfacl apps
1693 <step><para><indexterm>
1694 <primary>recursively</primary>
1696 You want to add permission for <constant>AppsMgrs</constant> to enable them to
1697 manage the applications (apps) share. It is important to set the ACL recursively
1698 so that the AppsMgrs have this capability throughout the directory tree that is
1699 being shared. This is done using the <constant>-R</constant> option as shown.
1700 Execute the following:
1702 &rootprompt; setfacl -m -R group:AppsMgrs:rwx /data/apps
1704 Because setting an ACL does not provide a response, you immediately validate the command executed
1707 &rootprompt; getfacl /data/apps
1717 This confirms that the change of Posix ACL permissions has been effective.
1720 <step><para><indexterm>
1721 <primary>setfacl</primary>
1722 </indexterm><indexterm>
1723 <primary>getfacl</primary>
1724 </indexterm><indexterm>
1725 <primary>directory tree</primary>
1726 </indexterm><indexterm>
1727 <primary>Windows ACLs</primary>
1728 </indexterm><indexterm>
1729 <primary>inheritance</primary>
1731 It is highly recommend that you should read the on-line manual page for the <command>setfacl</command>
1732 and <command>getfacl</command> commands. This provides information regarding how to set/read the default
1733 ACLs and how that may be propagated through the directory tree. In Windows ACLs terms, this is the equivalent
1734 of setting <constant>inheritance</constant> properties.
1743 <title>Key Points Learned</title>
1746 The mish-mash of issues were thrown together into one chapter because it seemed like a good idea.
1747 Looking back, this chapter could be broken into two, but it's too late now. It has been done.
1748 The highlights covered are:
1752 <listitem><para><indexterm>
1753 <primary>Winbind</primary>
1754 </indexterm><indexterm>
1755 <primary>Active Directory</primary>
1756 </indexterm><indexterm>
1757 <primary>password change</primary>
1758 </indexterm><indexterm>
1759 <primary>logon hours</primary>
1761 Winbind honors and does not override account controls set in Active Directory.
1762 This means that password change, logon hours, and so on, are (or soon will be) enforced
1763 by Samba Winbind. At this time, an out-of-hours login is denied and password
1764 change is enforced. At this time, if logon hours expire, the user is not forcibly
1765 logged off. That may be implemented at some later date.
1768 <listitem><para><indexterm>
1769 <primary>Sign'n'seal</primary>
1770 </indexterm><indexterm>
1771 <primary>schannel</primary>
1773 Sign'n'seal (plus schannel support) has been implemented in Samba-3. Beware of potential
1774 problems acknowledged by Microsoft as having been fixed, but reported by some as still
1775 possibly an open issue.
1778 <listitem><para><indexterm>
1779 <primary>Kerberos</primary>
1780 </indexterm><indexterm>
1781 <primary>OpenLDAP</primary>
1782 </indexterm><indexterm>
1783 <primary>Active Directory</primary>
1784 </indexterm><indexterm>
1785 <primary>inter-operability</primary>
1787 The combination of Kerberos 5, plus OpenLDAP, plus Samba, cannot replace Microsoft
1788 Active Directory. The possibility to do this is not planned in the current Samba-3
1789 roadmap. Samba-3 does aim to provide further improvements in interoperability so that
1790 UNIX/Linux systems may be fully integrated into Active Directory Domains.
1794 This chapter reviewed mechanisms by which Samba servers may be kept secure. Each of
1795 the four key methodologies was reviewed with specific reference to example deployment
1805 <title>Questions and Answers</title>
1810 <qandaset defaultlabel="chap10qa" type="number">
1815 <primary>Sign'n'seal</primary>
1816 </indexterm><indexterm>
1817 <primary>registry hacks</primary>
1819 Does Samba-3 require the <constant>Sign'n'seal</constant> registry hacks needed by Samba-2?
1826 <primary>schannel</primary>
1827 </indexterm><indexterm>
1828 <primary>Sign'n'seal</primary>
1829 </indexterm><indexterm>
1830 <primary>registry change</primary>
1832 No. Samba-3 fully supports <constant>Sign'n'seal</constant> as well as <constant>schannel</constant>
1833 operation. The registry change should not be applied when Samba-3 is used as a Domain Controller.
1843 Does Samba-3 support Active Directory?
1850 <primary>Active Directory</primary>
1852 Yes. Samba-3 can be a fully participating native mode Active Directory client. Samba-3 does not
1853 provide Active Directory services. It cannot be used to replace a Microsoft Active Directory
1854 server implementation. Samba-3 can function as an Active Directory client (workstation) toolkit,
1855 and it can function as an Active Directory Domain Member server.
1865 <primary>mixed-mode</primary>
1867 When Samba-3 is used with Active Directory, is it necessary to run mixed-mode operation, as was
1868 necessary with Samba-2?
1875 <primary>native</primary>
1877 No. Samba-3 can be used with NetBIOS over TCP/IP disabled, just as can be done with Windows 200x
1878 Server and 200x/XPPro client products. It is no longer necessary to run mixed-mode operation,
1879 as Samba-3 can join a native Windows 2003 Server ADS Domain.
1889 <primary>share level access controls</primary>
1891 Is it safe to set share level access controls in Samba?
1898 Yes. Share level access controls have been supported since early versions of Samba-2. This is
1899 very mature technology. Not enough sites make use of this powerful capability, neither on
1900 Windows server or with Samba servers.
1910 <primary>share ACLs</primary>
1912 Is it mandatory to set share ACLs to get a secure Samba-3 server?
1919 <primary>file system security</primary>
1920 </indexterm><indexterm>
1921 <primary>Windows 200x ACLs</primary>
1922 </indexterm><indexterm>
1923 <primary>share definition controls</primary>
1924 </indexterm><indexterm>
1925 <primary>share level ACL</primary>
1926 </indexterm><indexterm>
1927 <primary>security</primary>
1929 No. Samba-3 honors UNIX/Linux file system security, supports Windows 200x ACLs, and provides
1930 means of securing shares through share definition controls in the &smb.conf; file. The additional
1931 support for share level ACLs is like frosting on the cake. It adds to security, but is not essential
1942 <primary>valid users</primary>
1944 The <parameter>valid users</parameter> did not work on the <smbconfsection name="[homes]"/>.
1945 Has this functionality been restored yet?
1952 <primary>meta-service</primary>
1954 Yes. This was fixed in Samba-3.0.2. The use of this parameter is strongly recommended as a safeguard
1955 on the <smbconfsection name="[homes]"/> meta-service. The correct way to specify this is:
1956 <smbconfoption name="valid users">%S</smbconfoption>.
1966 <primary>force user</primary>
1967 </indexterm><indexterm>
1968 <primary>force group</primary>
1969 </indexterm><indexterm>
1970 <primary>bias</primary>
1972 Is the bias against use of the <parameter>force user</parameter> and <parameter>force group</parameter>
1980 <primary>performance</primary>
1982 There is no bias. There is a determination to recommend the right tool for the task at hand.
1983 After all, it is better than putting users through performance problems, isn't it?
1993 The example given for file and directory access control forces all files to be owned by one
1994 particular user. I do not like that. Is there any way I can see who created the file?
2001 <primary>SUID</primary>
2003 Sure. You do not have to set the SUID bit on the directory. Simply execute the following command
2004 to permit file ownership to be retained by the user who created it:
2006 &rootprompt; find /usr/data/finance -type d -exec chmod g+s {}\;
2008 Note that this required no more than removing the <constant>u</constant> argument so that the
2009 SUID bit is not set for the owner.
2019 <primary>Computer Management</primary>
2021 In the book, <quote>The Official Samba-3 HOWTO and Reference Guide</quote>, you recommended use
2022 of the Windows NT4 Server Manager (part of the <filename>SRVTOOLS.EXE</filename>) utility. Why
2023 have you mentioned only the use of the Windows 200x/XP MMC Computer Management utility?
2030 <primary>MMC</primary>
2031 </indexterm><indexterm>
2032 <primary>SRVTOOLS.EXE</primary>
2034 Either tool can be used with equal effect. There is no benefit of one over the other, except that
2035 the MMC utility is present on all Windows 200x/XP systems and does not require additional software
2036 to be downloaded and installed. Note that if you want to manage user and group accounts in your
2037 Samba controlled Domain, the only tool that permits that is the NT4 Domain User Manager which
2038 is provided as part of the <filename>SRVTOOLS.EXE</filename> utility.
2048 <primary>valid users</primary>
2049 </indexterm><indexterm>
2050 <primary>Active Directory</primary>
2051 </indexterm><indexterm>
2052 <primary>Domain Member server</primary>
2054 I tried to set <parameter>valid users = @Engineers</parameter>, but it does not work. My Samba
2055 server is an Active Directory Domain Member server. Has this been fixed now?
2062 The use of this parameter has always required the full specification of the Domain account, for
2063 example, <parameter>valid users = @"MEGANET2\Domain Admins"</parameter>.
git.samba.org / tprouty / samba.git / blob