diff options
Diffstat (limited to 'docs-xml/Samba3-ByExample/SBE-KerberosFastStart.xml')
| -rw-r--r-- | docs-xml/Samba3-ByExample/SBE-KerberosFastStart.xml | 2071 |
1 files changed, 2071 insertions, 0 deletions
diff --git a/docs-xml/Samba3-ByExample/SBE-KerberosFastStart.xml b/docs-xml/Samba3-ByExample/SBE-KerberosFastStart.xml new file mode 100644 index 0000000000..b593eed4ff --- /dev/null +++ b/docs-xml/Samba3-ByExample/SBE-KerberosFastStart.xml @@ -0,0 +1,2071 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<chapter id="kerberos"> + <title>Active Directory, Kerberos, and Security</title> + + <para><indexterm> + <primary>experiment</primary> + </indexterm> + By this point in the book, you have been exposed to many Samba-3 features and capabilities. + More importantly, if you have implemented the examples given, you are well on your way to becoming + a Samba-3 networking guru who knows a lot about Microsoft Windows. If you have taken the time to + practice, you likely have thought of improvements and scenarios with which you can experiment. You + are rather well plugged in to the many flexible ways Samba can be used. + </para> + + <para><indexterm> + <primary>criticism</primary> + </indexterm> + This is a book about Samba-3. Understandably, its intent is to present it in a positive light. + The casual observer might conclude that this book is one-eyed about Samba. It is &smbmdash; what + would you expect? This chapter exposes some criticisms that have been raised concerning + the use of Samba. For each criticism, there are good answers and appropriate solutions. + </para> + + <para> + Some criticism always comes from deep inside ranks that one would expect to be supportive of a particular + decision. Criticism can be expected from the outside. Let's see how the interesting dynamic of + criticism develops with respect to Abmas. + </para> + + <para><indexterm> + <primary>straw-man</primary> + </indexterm> + This chapter provides a shameless self-promotion of Samba-3. The objections raised were not pulled + out of thin air. They were drawn from comments made by Samba users and from criticism during + discussions with Windows network administrators. The tone of the objections reflects as closely + as possible that of the original. The case presented is a straw-man example that is designed to + permit each objection to be answered as it might occur in real life. + </para> + +<sect1> + <title>Introduction</title> + + <para><indexterm> + <primary>acquisitions</primary> + </indexterm><indexterm> + <primary>risk</primary> + </indexterm><indexterm> + <primary>assessment</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>Windows 2003 Serve</primary> + </indexterm> + Abmas is continuing its meteoric growth with yet further acquisitions. The investment community took + note of the spectacular projection of Abmas onto the global business stage. Abmas is building an + interesting portfolio of companies that includes accounting services, financial advice, investment + portfolio management, property insurance, risk assessment, and the recent addition of a a video rental + business. The pieces do not always appear to fit together, but Mr. Meany is certainly executing an + interesting business growth and development plan. Abmas Video Rentals was recently acquired. + During the time that the acquisition was closing, the Video Rentals business upgraded its Windows + NT4-based network to Windows 2003 Server and Active Directory. + </para> + + <para><indexterm> + <primary>Active Directory</primary> + </indexterm> + You have accepted the fact that Abmas Video Rentals will use Microsoft Active Directory. + The IT team, led by Stan Soroka, is committed to Samba-3 and to maintaining a uniform technology platform. + Stan Soroka's team voiced its disapproval over the decision to permit this business to continue to + operate with a solution that is viewed by Christine and her group as <quote>an island of broken + technologies.</quote> This comment was made by one of Christine's staff as they were installing a new + Samba-3 server at the new business. + </para> + + + <para><indexterm> + <primary>consultant</primary> + </indexterm><indexterm> + <primary>hypothetical</primary> + </indexterm> + Abmas Video Rentals' head of IT heard of this criticism. He was offended that a junior engineer + should make such a comment. He felt that he had to prepare in case he might be criticized for his + decision to use Active Directory. He decided he would defend his decision by hiring the services + of an outside security systems consultant to report<footnote>This report is entirely fictitious. + Any resemblance to a factual report is purely coincidental.</footnote> on his unit's operations + and to investigate the role of Samba at his site. Here are key extracts from this hypothetical + report: + </para> + + <blockquote><para><indexterm> + <primary>vulnerabilities</primary> + </indexterm><indexterm> + <primary>integrity</primary> + </indexterm><indexterm> + <primary>practices</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm> + ... the implementation of Microsoft Active Directory at the Abmas Video Rentals, Bamingsham site, + has been examined. We find no evidence to support a notion that vulnerabilities exist at your site. + ... we took additional steps to validate the integrity of the installation and operation of Active + Directory and are pleased that your staff are following sound practices. + </para> + + <para> + ... + </para> + + <para><indexterm> + <primary>accounts</primary> + <secondary>user</secondary> + </indexterm><indexterm> + <primary>accounts</primary> + <secondary>group</secondary> + </indexterm><indexterm> + <primary>Backup</primary> + </indexterm><indexterm> + <primary>disaster recovery</primary> + </indexterm><indexterm> + <primary>validated</primary> + </indexterm><indexterm> + <primary>off-site storage</primary> + </indexterm> + User and group accounts, and respective privileges, have been well thought out. File system shares are + appropriately secured. Backup and disaster recovery plans are well managed and validated regularly, and + effective off-site storage practices are considered to exceed industry norms. + </para> + + <para><indexterm> + <primary>compromise</primary> + </indexterm><indexterm> + <primary>secure</primary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>secure</secondary> + </indexterm> + Your staff are justifiably concerned that the use of Samba may compromise their good efforts to maintain + a secure network. + </para> + + <para><indexterm> + <primary>winbind</primary> + </indexterm><indexterm> + <primary>security</primary> + </indexterm><indexterm> + <primary>secure</primary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>management</secondary> + </indexterm> + The recently installed Linux file and application server uses a tool called <command>winbind</command> + that is indiscriminate about security. All user accounts in Active Directory can be used to access data + stored on the Linux system. We are alarmed that secure information is accessible to staff who should + not even be aware that it exists. We share the concerns of your network management staff who have gone + to great lengths to set fine-grained controls that limit information access to those who need access. + It seems incongruous to us that Samba winbind should be permitted to be used considering that it voids this fine work. + </para> + + <para><indexterm> + <primary>isolated</primary> + </indexterm><indexterm> + <primary>firewall</primary> + </indexterm><indexterm> + <primary>best practices</primary> + </indexterm> + Graham Judd [head of network administration] has locked down the security of all systems and is following + the latest Microsoft guidelines. ... null session connections have been disabled ... the internal network + is isolated from the outside world, the [product name removed] firewall is under current contract + maintenance support from [the manufacturer]. ... our attempts to penetrate security of your systems + failed to find problems common to Windows networking sites. We commend your staff on their attention to + detail and for following Microsoft recommended best practices. + </para> + + <para> + ... + </para> + + <para><indexterm> + <primary>security</primary> + </indexterm><indexterm> + <primary>disable</primary> + </indexterm><indexterm> + <primary>essential</primary> + </indexterm><indexterm> + <primary>trusted computing</primary> + </indexterm> + Regarding the use of Samba, we offer the following comments: Samba is in use in nearly half of + all sites we have surveyed. ... It is our opinion that Samba offers no better security than Microsoft + ... what worries us regarding Samba is the need to disable essential Windows security features such as + secure channel support, digital sign'n'seal on all communication traffic, and running Active Directory in + mixed mode so that Samba clients and servers can authenticate all of it. Additionally, we are concerned that + Samba is not at the full capabilities of Microsoft Windows NT4 server. Microsoft has moved well beyond that + with trusted computing initiatives that the Samba developers do not participate in. + </para> + + <para><indexterm> + <primary>integrity</primary> + </indexterm><indexterm> + <primary>hackers</primary> + </indexterm><indexterm> + <primary>accountable</primary> + </indexterm><indexterm> + <primary>flaws</primary> + </indexterm><indexterm> + <primary>updates</primary> + </indexterm><indexterm> + <primary>bug fixes</primary> + </indexterm><indexterm> + <primary>alarm</primary> + </indexterm> + One wonders about the integrity of an open source program that is developed by a team of hackers + who cannot be held accountable for the flaws in their code. The sheer number of updates and bug + fixes they have released should ring alarm bells in any business. + </para> + + <para><indexterm> + <primary>employment</primary> + </indexterm><indexterm> + <primary>jobs</primary> + </indexterm><indexterm> + <primary>risk</primary> + </indexterm> + Another factor that should be considered is that buying Microsoft products and services helps to + provide employment in the IT industry. Samba and Open Source software place those jobs at risk. + </para></blockquote> + + <para><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>independent expert</primary> + </indexterm> + This is also a challenge to rise above the trouble spot. You call Stan's team together for a simple + discussion, but it gets further out of hand. When you return to your office, you find the following + email in your in-box: + </para> + + <para> + Good afternoon, + </para> + + <blockquote><attribution>Stan</attribution><para> + I apologize for the leak of internal discussions to the new business. It reflects poorly on our + professionalism and has put you in an unpleasant position. I regret the incident. + </para> + + <para> + I also wish to advise that two of the recent recruits want to implement Kerberos authentication + across all systems. I concur with the desire to improve security. One of the new guys who is championing + the move to Kerberos was responsible for the comment that caused the embarrassment. + </para> + + <para><indexterm> + <primary>Kerberos</primary> + </indexterm><indexterm> + <primary>OpenLDAP</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>consultant</primary> + </indexterm> + I am experiencing difficulty in handling the sharp push for Kerberos. He claims that Kerberos, OpenLDAP, + plus Samba-3 will seamlessly replace Microsoft Active Directory. I am a little out of my depth with respect + to the feasibility of such a move, but have taken steps to pull both of them into line. With your consent, + I would like to hire the services of a well-known Samba consultant to set the record straight. + </para> + + <para><indexterm> + <primary>criticism</primary> + </indexterm><indexterm> + <primary>policy</primary> + </indexterm><indexterm> + <primary>Windows Servers</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>budgetted</primary> + </indexterm><indexterm> + <primary>financial responsibility</primary> + </indexterm> + I intend to use this report to answer the criticism raised and would like to establish a policy that we + will approve the use of Microsoft Windows Servers (and Active Directory) subject to all costs being covered + out of the budget of the division that wishes to go its own way. I propose that dissenters will still remain + responsible to meet the budgeted contribution to IT operations as a whole. I believe we should not coerce + use of any centrally proposed standards, but make all noncompliance the financial responsibility of the + out-of-step division. Hopefully, this will encourage all divisions to walk with us and not alone. + </para></blockquote> + + <sect2> + <title>Assignment Tasks</title> + + <para> + You agreed with Stan's recommendations and hired a consultant to help defuse the powder + keg. The consultant's task is to provide a tractable answer to each of the issues raised. The consultant must be able + to support his or her claims, keep emotions to the side, and answer technically. + </para> + + </sect2> +</sect1> + +<sect1> + <title>Dissection and Discussion</title> + + <para><indexterm> + <primary>tool</primary> + </indexterm><indexterm> + <primary>benefit</primary> + </indexterm><indexterm> + <primary>choice</primary> + </indexterm><indexterm> + <primary>consultant</primary> + </indexterm><indexterm> + <primary>installation</primary> + </indexterm><indexterm> + <primary>income</primary> + </indexterm><indexterm> + <primary>employment</primary> + </indexterm> + 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 + make or reject. It is likely that your decision to use Samba can greatly benefit your company. + The Samba Team obviously believes that the Samba software is a worthy choice. + If you hire a consultant to assist with the installation and/or deployment of Samba, or if you hire + someone to help manage your Samba installation, you can create income and employment. Alternately, + money saved by not spending in the IT area can be spent elsewhere in the business. All money saved + or spent creates employment. + </para> + + <para><indexterm> + <primary>economically sustainable</primary> + </indexterm><indexterm> + <primary>inter-operability</primary> + </indexterm><indexterm> + <primary>file and print service</primary> + </indexterm><indexterm> + <primary>cost</primary> + </indexterm><indexterm> + <primary>alternative</primary> + </indexterm> + In the long term, the use of Samba must be economically sustainable. In some situations, Samba is adopted + purely to provide file and print service interoperability on platforms that otherwise cannot provide + access to data and to printers for Microsoft Windows clients. Samba is used by some businesses to + effect a reduction in the cost of providing IT services. Obviously, it is also used by some as an + alternative to the use of a Microsoft file and print serving platforms with no consideration of costs. + </para> + + <para><indexterm> + <primary>documentation</primary> + </indexterm><indexterm> + <primary>responsibility</primary> + </indexterm><indexterm> + <primary>fix</primary> + </indexterm><indexterm> + <primary>broken</primary> + </indexterm> + It would be foolish to adopt a technology that might put any data or users at risk. Security affects + everyone. The Samba-Team is fully cognizant of the responsibility they have to their users. + The Samba documentation clearly reveals that full responsibility is accepted to fix anything + that is broken. + </para> + + <para><indexterm> + <primary>commercial</primary> + </indexterm><indexterm> + <primary>software</primary> + </indexterm><indexterm> + <primary>commercial software</primary> + </indexterm><indexterm> + <primary>End User License Agreement</primary> + <see>EULA</see> + </indexterm><indexterm> + <primary>accountable</primary> + </indexterm><indexterm> + <secondary>liability</secondary> + </indexterm><indexterm> + <primary>accepts liability</primary> + </indexterm><indexterm> + <primary>price paid</primary> + </indexterm><indexterm> + <primary>product defects</primary> + </indexterm><indexterm> + <primary>reimburse</primary> + </indexterm><indexterm> + <primary>extent</primary> + </indexterm> + There is a mistaken perception in the IT industry that commercial software providers are fully + accountable for the defects in products. Open Source software comes with no warranty, so it is + often assumed that its use confers a higher degree of risk. Everyone should read commercial software + End User License Agreements (EULAs). You should determine what real warranty is offered and the + extent of liability that is accepted. Doing so soon dispels the popular notion that + commercial software vendors are willingly accountable for product defects. In many cases, the + commercial vendor accepts liability only to reimburse the price paid for the software. + </para> + + <para><indexterm> + <primary>consumer</primary> + </indexterm><indexterm> + <primary>EULA</primary> + </indexterm><indexterm> + <primary>track record</primary> + </indexterm><indexterm> + <primary>commercial software</primary> + </indexterm><indexterm> + <primary>support</primary> + </indexterm><indexterm> + <primary>vendor</primary> + </indexterm> + The real issues that a consumer (like you) needs answered are What is the way of escape from technical + problems, and how long will it take? The average problem turnaround time in the Open Source community is + approximately 48 hours. What does the EULA offer? What is the track record in the commercial software + industry? What happens when your commercial vendor decides to cease providing support? + </para> + + <para><indexterm> + <primary>source code</primary> + </indexterm><indexterm> + <primary>Open Source</primary> + </indexterm><indexterm> + <primary>hire</primary> + </indexterm><indexterm> + <primary>programmer</primary> + </indexterm><indexterm> + <primary>solve</primary> + </indexterm><indexterm> + <primary>fix</primary> + </indexterm><indexterm> + <secondary>problem</secondary> + </indexterm> + Open Source software at least puts you in possession of the source code. This means that when + all else fails, you can hire a programmer to solve the problem. + </para> + + <sect2> + <title>Technical Issues</title> + + <para> + Each issue is now discussed and, where appropriate, example implementation steps are + provided. + </para> + + <variablelist> + <varlistentry> + <term>Winbind and Security</term> + <listitem><para><indexterm> + <primary>Winbind</primary> + </indexterm><indexterm> + <primary>Security</primary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>administrators</secondary> + </indexterm><indexterm> + <primary>Domain users</primary> + </indexterm><indexterm> + <secondary>Domain account</secondary> + </indexterm><indexterm> + <primary>credentials</primary> + </indexterm><indexterm> + <primary>Network Neighborhood</primary> + </indexterm><indexterm> + <primary>UNIX/Linux server</primary> + </indexterm><indexterm> + <primary>browse</primary> + </indexterm><indexterm> + <primary>shares</primary> + </indexterm> + Windows network administrators may be dismayed to find that <command>winbind</command> + exposes all domain users so that they may use their domain account credentials to + log on to a UNIX/Linux system. The fact that all users in the domain can see the + UNIX/Linux server in their Network Neighborhood and can browse the shares on the + server seems to excite them further. + </para> + + <para><indexterm> + <primary>Domain Member server</primary> + </indexterm><indexterm> + <primary>familiar</primary> + </indexterm><indexterm> + <primary>fear</primary> + </indexterm><indexterm> + <primary>unknown</primary> + </indexterm> + <command>winbind</command> provides for the UNIX/Linux domain member server or + client, the same as one would obtain by adding a Microsoft Windows server or + client to the domain. The real objection is the fact that Samba is not MS Windows + and therefore requires handling a little differently from the familiar Windows systems. + One must recognize fear of the unknown. + </para> + + <para><indexterm> + <primary>network administrators</primary> + </indexterm><indexterm> + <primary>recognize</primary> + </indexterm><indexterm> + <primary>winbind</primary> + </indexterm><indexterm> + <primary>over-ride</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + <secondary>management tools</secondary> + </indexterm><indexterm> + <primary>fears</primary> + </indexterm> + Windows network administrators need to recognize that <command>winbind</command> does + not, and cannot, override account controls set using the Active Directory management + tools. The control is the same. Have no fear. + </para> + + <para><indexterm> + <primary>ADS Domain</primary> + </indexterm><indexterm> + <primary>account</primary> + <secondary>ADS Domain</secondary> + </indexterm><indexterm> + <primary>winbind</primary> + </indexterm><indexterm> + <primary>browsing</primary> + </indexterm><indexterm> + <primary>permits</primary> + </indexterm><indexterm> + <primary>access</primary> + </indexterm><indexterm> + <primary>drive mapping</primary> + </indexterm><indexterm> + <primary>protected</primary> + </indexterm><indexterm> + <primary>security controls</primary> + </indexterm><indexterm> + <primary>access controls</primary> + </indexterm> + Where Samba and the ADS domain account information obtained through the use of + <command>winbind</command> permits access, by browsing or by the drive mapping to + a share, to data that should be better protected. This can only happen when security + controls have not been properly implemented. Samba permits access controls to be set + on: + </para> + + <itemizedlist> + <listitem><para>Shares themselves (i.e., the logical share itself)</para></listitem> + <listitem><para>The share definition in &smb.conf;</para></listitem> + <listitem><para>The shared directories and files using UNIX permissions</para></listitem> + <listitem><para>Using Windows 2000 ACLs &smbmdash; if the file system is POSIX enabled</para></listitem> + </itemizedlist> + + <para> + Examples of each are given in <link linkend="ch10expl"/>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>User and Group Controls</term> + <listitem><para><indexterm> + <primary>User and Group Controls</primary> + </indexterm><indexterm> + <primary>management</primary> + <secondary>User</secondary> + </indexterm><indexterm> + <primary>management</primary> + <secondary>group</secondary> + </indexterm><indexterm> + <primary>ADS</primary> + </indexterm><indexterm> + <primary>permissions</primary> + </indexterm><indexterm> + <primary>privileges</primary> + </indexterm><indexterm> + <primary>flexibility</primary> + </indexterm><indexterm> + <primary>access controls</primary> + </indexterm><indexterm> + <primary>share definition</primary> + </indexterm> + User and group management facilities as known in the Windows ADS environment may be + used to provide equivalent access control constraints or to provide equivalent + permissions and privileges on Samba servers. Samba offers greater flexibility in the + use of user and group controls because it has additional layers of control compared to + Windows 200x/XP. For example, access controls on a Samba server may be set within + the share definition in a manner for which Windows has no equivalent. + </para> + + <para><indexterm> + <primary>analysis</primary> + </indexterm><indexterm> + <primary>system security</primary> + </indexterm><indexterm> + <primary>safe-guards</primary> + </indexterm><indexterm> + <primary>permissions</primary> + <secondary>excessive</secondary> + </indexterm><indexterm> + <primary>file system</primary> + </indexterm><indexterm> + <primary>shared resource</primary> + </indexterm><indexterm> + <primary>share definition</primary> + </indexterm> + In any serious analysis of system security, it is important to examine the safeguards + that remain when all other protective measures fail. An administrator may inadvertently + set excessive permissions on the file system of a shared resource, or he may set excessive + privileges on the share itself. If that were to happen in a Windows 2003 Server environment, + the data would indeed be laid bare to abuse. Yet, within a Samba share definition, it is + possible to guard against that by enforcing controls on the share definition itself. You + see a practical example of this a little later in this chapter. + </para> + + <para><indexterm> + <primary>diligence</primary> + </indexterm><indexterm> + <primary>weakness</primary> + </indexterm> + The report that is critical of Samba really ought to have exercised greater due + diligence: the real weakness is on the side of a Microsoft Windows environment. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>Security Overall</term> + <listitem><para><indexterm> + <primary>defects</primary> + </indexterm> + Samba is designed in such a manner that weaknesses inherent in the design of + Microsoft Windows networking ought not to expose the underlying UNIX/Linux file + system in any way. All software has potential defects, and Samba is no exception. + What matters more is how defects that are discovered get dealt with. + </para> + + <para><indexterm> + <primary>security</primary> + </indexterm><indexterm> + <primary>protection</primary> + </indexterm><indexterm> + <primary>compromise</primary> + </indexterm><indexterm> + <primary>consequential risk</primary> + </indexterm> + The Samba Team totally agrees with the necessity to observe and fully implement + every security facility to provide a level of protection and security that is necessary + and that the end user (or network administrator) needs. Never would the Samba Team + recommend a compromise to system security, nor would deliberate defoliation of + security be publicly condoned; yet this is the practice by many Windows network + administrators just to make happy users who have no notion of consequential risk. + </para> + + <para><indexterm> + <primary>condemns</primary> + </indexterm><indexterm> + <primary>security fixes</primary> + </indexterm><indexterm> + <primary>updates</primary> + </indexterm><indexterm> + <primary>development</primary> + </indexterm><indexterm> + <primary>documentation</primary> + </indexterm><indexterm> + <primary>security updates</primary> + </indexterm><indexterm> + <primary>turn-around time</primary> + </indexterm> + The report condemns Samba for releasing updates and security fixes, yet Microsoft + online updates need to be applied almost weekly. The answer to the criticism + lies in the fact that Samba development is continuing, documentation is improving, + user needs are being increasingly met or exceeded, and security updates are issued + with a short turnaround time. + </para> + + <para><indexterm> + <primary>modularization</primary> + </indexterm><indexterm> + <primary>next generation</primary> + </indexterm><indexterm> + <primary>responsible</primary> + </indexterm><indexterm> + <primary>dependability</primary> + </indexterm><indexterm> + <primary>road-map</primary> + <secondary>published</secondary> + </indexterm> + The release of Samba-4 is expected around late 2004 to early 2005 and involves a near + complete rewrite to permit extensive modularization and to prepare Samba for new + functionality planned for addition during the next-generation series. The Samba Team + is responsible and can be depended upon; the history to date suggests a high + degree of dependability and on charter development consistent with published + roadmap projections. + </para> + + <para><indexterm> + <primary>foundation members</primary> + </indexterm><indexterm> + <primary>Common Internet File System</primary> + <see>CIFS</see> + </indexterm><indexterm> + <primary>network attached storage</primary> + <see>NAS</see> + </indexterm><indexterm> + <primary>conferences</primary> + </indexterm><indexterm> + <primary>presence and leadership</primary> + </indexterm><indexterm> + <primary>leadership</primary> + </indexterm><indexterm> + <primary>inter-operability</primary> + </indexterm> + Not well published is the fact that Microsoft was a foundation member of + the Common Internet File System (CIFS) initiative, together with the participation + of the network attached storage (NAS) industry. Unfortunately, for the past few years, + Microsoft has been absent from active involvement at CIFS conferences and has + not exercised the leadership expected of a major force in the networking technology + space. The Samba Team has maintained consistent presence and leadership at all + CIFS conferences and at the interoperability laboratories run concurrently with + them. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>Cryptographic Controls (schannel, sign'n'seal)</term> + <listitem><para><indexterm> + <primary>Cryptographic</primary> + </indexterm><indexterm> + <primary>schannel</primary> + </indexterm><indexterm> + <primary>digital sign'n'seal</primary> + </indexterm> + The report correctly mentions that Samba did not support the most recent + <constant>schannel</constant> and <constant>digital sign'n'seal</constant> features + of Microsoft Windows NT/200x/XPPro products. This is one of the key features + of the Samba-3 release. Market research reports take so long to generate that they are + seldom a reflection of current practice, and in many respects reports are like a + pathology report &smbmdash; they reflect accurately (at best) status at a snapshot in time. + Meanwhile, the world moves on. + </para> + + <para><indexterm> + <primary>public specifications</primary> + </indexterm><indexterm> + <primary>protocols</primary> + </indexterm><indexterm> + <primary>algorithm</primary> + </indexterm><indexterm> + <primary>compatible</primary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>traffic</secondary> + <tertiary>observation</tertiary> + </indexterm><indexterm> + <primary>defensible standards</primary> + </indexterm><indexterm> + <primary>secure networking</primary> + </indexterm> + It should be pointed out that had clear public specifications for the protocols + been published, it would have been much easier to implement these features and would have + taken less time to do. The sole mechanism used to find an algorithm that is compatible + with the methods used by Microsoft has been based on observation of network traffic + and trial-and-error implementation of potential techniques. The real value of public + and defensible standards is obvious to all and would have enabled more secure networking + for everyone. + </para> + + <para><indexterm> + <primary>Critics</primary> + </indexterm><indexterm> + <primary>digital sign'n'seal</primary> + </indexterm> + Critics of Samba often ignore fundamental problems that may plague (or may have plagued) + the users of Microsoft's products also. Those who are first to criticize Samba + for not rushing into release of <constant>digital sign'n'seal</constant> support + often dismiss the problems that Microsoft has + <ulink url="http://support.microsoft.com/default.aspx?kbid=321733">acknowledged</ulink> + and for which a fix was provided. In fact, + <ulink url="http://www.tangent-systems.com/support/delayedwrite.html">Tangent Systems</ulink> + have documented a significant problem with delays writes that can be connected with the + implementation of sign'n'seal. They provide a work-around that is not trivial for many + Windows networking sites. From notes such as this it is clear that there are benefits + from not rushing new technology out of the door too soon. + </para> + + <para><indexterm> + <primary>secure networking protocols</primary> + </indexterm><indexterm> + <primary>refereed standards</primary> + </indexterm><indexterm> + <primary>proprietary</primary> + </indexterm><indexterm> + <primary>digital rights</primary> + </indexterm><indexterm> + <primary>protection</primary> + </indexterm><indexterm> + <primary>networking protocols</primary> + </indexterm><indexterm> + <primary>diffusion</primary> + </indexterm><indexterm> + <primary>consumer</primary> + </indexterm><indexterm> + <primary>choice</primary> + </indexterm> + One final comment is warranted. If companies want more secure networking protocols, + the most effective method by which this can be achieved is by users seeking + and working together to help define open and publicly refereed standards. The + development of closed source, proprietary methods that are developed in a + clandestine framework of secrecy, under claims of digital rights protection, does + not favor the diffusion of safe networking protocols and certainly does not + help the consumer to make a better choice. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>Active Directory Replacement with Kerberos, LDAP, and Samba</term> + <indexterm> + <primary>Active Directory</primary> + <secondary>Replacement</secondary> + </indexterm><indexterm> + <primary>Kerberos</primary> + </indexterm><indexterm> + <primary>LDAP</primary> + </indexterm><indexterm> + <primary>remote procedure call</primary> + <see>RPC</see> + </indexterm> + <listitem><para> + <literallayout> </literallayout> + The Microsoft networking protocols extensively make use of remote procedure call (RPC) + technology. Active Directory is not a simple mixture of LDAP and Kerberos together + with file and print services, but rather is a complex, intertwined implementation + of them that uses RPCs that are not supported by any of these component technologies + and yet by which they are made to interoperate in ways that the components do not + support. + </para> + + <para><indexterm> + <primary>Active Directory</primary> + <secondary>Server</secondary> + </indexterm><indexterm> + <primary>OpenLDAP</primary> + </indexterm><indexterm> + <primary>Kerberos</primary> + </indexterm><indexterm> + <primary>project maintainers</primary> + </indexterm><indexterm> + <primary>LDAP</primary> + </indexterm> + In order to make the popular request for Samba to be an Active Directory Server a + reality, it is necessary to add to OpenLDAP, Kerberos, as well as Samba, RPC calls + that are not presently supported. The Samba Team has not been able to gain critical + overall support for all project maintainers to work together on the complex + challenge of developing and integrating the necessary technologies. Therefore, if + the Samba Team does not make it a priority to absorb Kerberos and LDAP functionality + into the Samba project, this dream request cannot become a reality. + </para> + + <para><indexterm> + <primary>missing RPC's</primary> + </indexterm><indexterm> + <primary>road-map</primary> + </indexterm><indexterm> + <primary>ADS</primary> + <secondary>server</secondary> + </indexterm><indexterm> + <primary>MMC</primary> + </indexterm><indexterm> + <primary>managed</primary> + </indexterm> + At this time, the integration of LDAP, Kerberos, and the missing RPCs is not on the + Samba development roadmap. If it is not on the published roadmap, it cannot be delivered + anytime soon. Ergo, ADS server support is not a current goal for Samba development. + The Samba Team is most committed to permitting Samba to be a full ADS domain member + that is increasingly capable of being managed using Microsoft Windows MMC tools. + </para></listitem> + </varlistentry> + </variablelist> + + <sect3> + <title>Kerberos Exposed</title> + + <para><indexterm> + <primary>kerberos</primary> + </indexterm><indexterm> + <primary>unauthorized activities</primary> + </indexterm><indexterm> + <primary>authorized location</primary> + </indexterm> + Kerberos is a network authentication protocol that provides secure authentication for + client-server applications by using secret-key cryptography. Firewalls are an insufficient + barrier mechanism in today's networking world; at best they only restrict incoming network + traffic but cannot prevent network traffic that comes from authorized locations from + performing unauthorized activities. + </para> + + <para><indexterm> + <primary>strong cryptography</primary> + </indexterm><indexterm> + <primary>identity</primary> + </indexterm><indexterm> + <primary>integrity</primary> + </indexterm> + Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses + strong cryptography so that a client can prove its identity to a server (and vice versa) across an + insecure network connection. After a client and server has used Kerberos to prove their identity, + they can also encrypt all of their communications to assure privacy and data integrity as they go + about their business. + </para> + + <para><indexterm> + <primary>trusted third-party</primary> + </indexterm><indexterm> + <primary>principals</primary> + </indexterm><indexterm> + <primary>trusting</primary> + </indexterm><indexterm> + <primary>kerberos</primary> + <secondary>server</secondary> + </indexterm><indexterm> + <primary>secret</primary> + </indexterm> + Kerberos is a trusted third-party service. That means that there is a third party (the kerberos + server) that is trusted by all the entities on the network (users and services, usually called + principals). All principals share a secret password (or key) with the kerberos server and this + enables principals to verify that the messages from the kerberos server are authentic. Therefore, + trusting the kerberos server, users and services can authenticate each other. + </para> + + <para> + <indexterm><primary>restricted export</primary></indexterm> + <indexterm><primary>MIT Kerberos</primary></indexterm> + <indexterm><primary>Heimdal Kerberos</primary></indexterm> + Kerberos was, until recently, a technology that was restricted from being exported from the United States. + For many years that hindered global adoption of more secure networking technologies both within the United States + and abroad. A free and unencumbered implementation of MIT Kerberos has been produced in Europe + and is available from the <ulink url="http://www.pdc.kth.se/heimdal/">Royal Institute</ulink> of + Technology (KTH), Sweden. It is known as the Heimdal Kerberos project. In recent times the U.S. government + has removed sanctions affecting the global distribution of MIT Kerberos. It is likely that there will be a + significant surge forward in the development of Kerberos-enabled applications and in the general deployment + and use of Kerberos across the spectrum of the information technology industry. + </para> + + <para> + <indexterm><primary>Kerberos</primary><secondary>interoperability</secondary></indexterm> + A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation + of it. For example, a 2002 + <ulink url="http://www.idg.com.sg/idgwww.nsf/0/5DDA8D153A7505A748256BAB000D992A?OpenDocument">IDG</ulink> + report<footnote>Note: This link is no longer active. The same article is still + available from <ulink url="http://199.105.191.226/Man/2699/020430msdoj/">ITWorld.com</ulink> (July 5, 2005)</footnote> by + states: + </para> + + <blockquote><para> + A Microsoft Corp. executive testified at the software giant's remedy hearing that the company goes to + great lengths to disclose interfaces and protocols that allow third-party software products to interact + with Windows. But a lawyer with the states suing Microsoft pointed out that when it comes to the company's + use of the Kerberos authentication specification, not everyone agrees. + </para> + + <para> + <indexterm><primary>Kerberos</primary><secondary>unspecified fields</secondary></indexterm> + Robert Short, vice president of Windows core technology at Microsoft, wrote in his direct testimony prepared + before his appearance that non-Microsoft operating systems can disregard the portion of the Kerberos version + 5 specification that Windows clients use for proprietary purposes and still achieve interoperability with + the Microsoft OS. Microsoft takes advantage of unspecified fields in the Kerberos specification for storing + Windows-specific authorization data, Short wrote. The designers of Kerberos left these fields undefined so + that software developers could add their own authorization information, he said. + </para></blockquote> + + <para> + <indexterm><primary>DCE</primary></indexterm> + <indexterm><primary>RPC</primary></indexterm> + It so happens that Microsoft Windows clients depend on and expect the contents of the <emphasis>unspecified + fields</emphasis> in the Kerberos 5 communications data stream for their Windows interoperability, + particularly when Samba is expected to emulate a Windows Server 200x domain controller. But the interoperability + issue goes far deeper than this. In the domain control protocols that are used by MS Windows XP Professional, + there is a tight interdependency between the Kerberos protocols and the Microsoft distributed computing environment + (DCE) RPCs that themselves are an integral part of the SMB/CIFS protocols as used by + Microsoft. + </para> + + <para> + Microsoft makes the following comment in a reference in a + <ulink url="http://www.microsoft.com/technet/itsolutions/interop/mgmt/kerberos.asp"> + technet</ulink> article: + </para> + + <blockquote><para><indexterm> + <primary>Privilege Attribute Certificates</primary> + <see>PAC</see> + </indexterm><indexterm> + <primary>access control</primary> + </indexterm> + The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC + representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos + tickets to convey Privilege Attribute Certificates (PACs) that define user identity and group membership. + The DCE PAC is used in a similar manner as Windows NT Security IDs for user authorization and access control. + Windows NT services will not be able to translate DCE PACs into Windows NT user and group identifiers. This + is not an issue with Kerberos interoperability, but rather an issue of interoperability between DCE and + Windows NT access control information. + </para></blockquote> + + </sect3> + + </sect2> + +</sect1> + +<sect1 id="ch10expl"> + <title>Implementation</title> + + <para> + The following procedures outline the implementation of the security measures discussed so far. + </para> + + <sect2> + <title>Share Access Controls</title> + + <para><indexterm> + <primary>Share Access Controls</primary> + </indexterm><indexterm> + <primary>filter</primary> + </indexterm><indexterm> + <primary>connection</primary> + </indexterm> + Access control entries placed on the share itself act as a filter at the time a when CIFS/SMB client (such as + Windows XP Pro) attempts to make a connection to the Samba server. + </para> + + <procedure> + <title>Create/Edit/Delete Share ACLs</title> + <step><para><indexterm> + <primary>Domain Administrator</primary> + </indexterm><indexterm> + <primary>account</primary> + </indexterm> + From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator + account (on Samba domains, this is usually the account called <constant>root</constant>). + </para></step> + + <step><para> + Click + <menuchoice> + <guimenu>Start</guimenu> + <guimenuitem>Settings</guimenuitem> + <guimenuitem>Control Panel</guimenuitem> + <guimenuitem>Administrative Tools</guimenuitem> + <guimenuitem>Computer Management</guimenuitem> + </menuchoice>. + </para></step> + + <step><para> + In the left panel, + <menuchoice> + <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu> + <guimenuitem>Connect to another computer ...</guimenuitem> + <guimenuitem>Browse...</guimenuitem> + <guimenuitem>Advanced</guimenuitem> + <guimenuitem>Find Now</guimenuitem> + </menuchoice>. In the lower panel, click on the name of the server you wish to + administer. Click <menuchoice> + <guimenu>OK</guimenu> + <guimenuitem>OK</guimenuitem> + <guimenuitem>OK</guimenuitem> + </menuchoice>.<indexterm> + <primary>Computer Management</primary> + </indexterm> + In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect + the change made. For example, if the server you are administering is called <constant>FRODO</constant>, + the Computer Management entry should now say <guimenu>Computer Management (FRODO)</guimenu>. + </para></step> + + <step><para> + In the left panel, click <menuchoice> + <guimenu>Computer Management (FRODO)</guimenu> + <guimenuitem>[+] Shared Folders</guimenuitem> + <guimenuitem>Shares</guimenuitem> + </menuchoice>. + </para></step> + + <step><para><indexterm> + <primary>ACLs</primary> + </indexterm><indexterm> + <primary>Share Permissions</primary> + </indexterm> + In the right panel, double-click on the share on which you wish to set/edit ACLs. This + will bring up the Properties panel. Click the <guimenu>Share Permissions</guimenu> tab. + </para></step> + + <step><para><indexterm> + <primary>access control settings</primary> + </indexterm><indexterm> + <primary>Everyone</primary> + </indexterm><indexterm> + <primary>full control</primary> + </indexterm><indexterm> + <primary>over-rule</primary> + </indexterm><indexterm> + <primary>permissions</primary> + </indexterm><indexterm> + <primary>rejected</primary> + </indexterm> + You may now edit/add/remove access control settings. Be very careful. Many problems have been + created by people who decided that everyone should be rejected but one particular group should + have full control. This is a catch-22 situation because members of that particular group also + belong to the group <constant>Everyone</constant>, which therefore overrules any permissions + set for the permitted group. + </para></step> + + <step><para> + When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu> + buttons. + </para></step> + </procedure> + + </sect2> + + <sect2> + <title>Share Definition Controls</title> + + <para><indexterm> + <primary>Share Definition</primary> + <secondary>Controls</secondary> + </indexterm><indexterm> + <primary>check-point</primary> + </indexterm><indexterm> + <primary>pile-driver</primary> + </indexterm><indexterm> + <primary>credential</primary> + </indexterm><indexterm> + <primary>powers</primary> + </indexterm><indexterm> + <primary>privileges</primary> + </indexterm> + Share-definition-based access controls can be used like a checkpoint or like a pile-driver. Just as a + checkpoint can be used to require someone who wants to get through to meet certain requirements, so + it is possible to require the user (or group the user belongs to) to meet specified credential-related + objectives. It can be likened to a pile-driver by overriding default controls in that having met the + credential-related objectives, the user can be granted powers and privileges that would not normally be + available under default settings. + </para> + + <para><indexterm> + <primary>access controls</primary> + </indexterm><indexterm> + <primary>ACLs</primary> + </indexterm><indexterm> + <primary>share definition controls</primary> + </indexterm><indexterm> + <primary>hierarchy of control</primary> + </indexterm> + It must be emphasized that the controls discussed here can act as a filter or give rights of passage + that act as a superstructure over normal directory and file access controls. However, share-level + ACLs act at a higher level than do share definition controls because the user must filter through the + share-level controls to get to the share-definition controls. The proper hierarchy of controls implemented + by Samba and Windows networking consists of: + </para> + + <orderedlist> + <listitem><para>Share-level ACLs</para></listitem> + <listitem><para>Share-definition controls</para></listitem> + <listitem><para>Directory and file permissions</para></listitem> + <listitem><para>Directory and file POSIX ACLs</para></listitem> + </orderedlist> + + <sect3> + <title>Checkpoint Controls</title> + + <para><indexterm> + <primary>Checkpoint Controls</primary> + </indexterm> + Consider the following extract from a &smb.conf; file defining the share called <constant>Apps</constant>: +<screen> +[Apps] + comment = Application Share + path = /data/apps + read only = Yes + valid users = @Employees +</screen> + This definition permits only those who are members of the group called <constant>Employees</constant> to + access the share. + </para> + + <note><para><indexterm> + <primary>Domain Member</primary> + <secondary>servers</secondary> + </indexterm><indexterm> + <primary>winbind use default domain</primary> + </indexterm><indexterm> + <primary>fully qualified</primary> + </indexterm><indexterm> + <primary>valid users</primary> + </indexterm><indexterm> + <primary>delimiter</primary> + </indexterm> + On domain member servers and clients, even when the <parameter>winbind use default domain</parameter> has + been specified, the use of domain accounts in security controls requires fully qualified domain specification, + for example, <smbconfoption name="valid users">@"MEGANET\Northern Engineers"</smbconfoption>. + Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a + delimiter. + </para></note> + + <para><indexterm> + <primary>ACL</primary> + </indexterm><indexterm> + <primary>access</primary> + </indexterm><indexterm> + <primary>validate</primary> + </indexterm> + If there is an ACL on the share itself to permit read/write access for all <constant>Employees</constant> + as well as read/write for the group <constant>Doctors</constant>, both groups are permitted through + to the share. However, at the moment an attempt is made to set up a connection to the share, a member of + the group <constant>Doctors</constant>, who is not also a member of the group <constant>Employees</constant>, + would immediately fail to validate. + </para> + + <para><indexterm> + <primary>share definition controls</primary> + </indexterm> + Consider another example. In this case, you want to permit all members of the group <constant>Employees</constant> + except the user <constant>patrickj</constant> to access the <constant>Apps</constant> share. This can be + easily achieved by setting a share-level ACL permitting only <constant>Employees</constant> to access the share, + and then in the share definition controls excluding just <constant>patrickj</constant>. Here is how that might + be done: +<screen> +[Apps] + comment = Application Share + path = /data/apps + read only = Yes + invalid users = patrickj +</screen> + <indexterm> + <primary>permissions</primary> + </indexterm> + Let us assume that you want to permit the user <constant>gbshaw</constant> to manage any file in the + UNIX/Linux file system directory <filename>/data/apps</filename>, but you do not want to grant any write + permissions beyond that directory tree. Here is one way this can be done: +<screen> +[Apps] + comment = Application Share + path = /data/apps + read only = Yes + invalid users = patrickj + admin users = gbshaw +</screen> + <indexterm> + <primary>administrative rights</primary> + </indexterm> + Now we have a set of controls that permits only <constant>Employees</constant> who are also members of + the group <constant>Doctors</constant>, excluding the user <constant>patrickj</constant>, to have + read-only privilege, but the user <constant>gbshaw</constant> is granted administrative rights. + The administrative rights conferred upon the user <constant>gbshaw</constant> permit operation as + if that user has logged in as the user <constant>root</constant> on the UNIX/Linux system and thus, + for access to the directory tree that has been shared (exported), permit the user to override controls + that apply to all other users on that resource. + </para> + + <para> + There are additional checkpoint controls that may be used. For example, if for the same share we now + want to provide the user <constant>peters</constant> with the ability to write to one directory to + which he has write privilege in the UNIX file system, you can specifically permit that with the + following settings: +<screen> +[Apps] + comment = Application Share + path = /data/apps + read only = Yes + invalid users = patrickj + admin users = gbshaw + write list = peters +</screen> + <indexterm> + <primary>check-point controls</primary> + </indexterm> + This is a particularly complex example at this point, but it begins to demonstrate the possibilities. + You should refer to the online manual page for the &smb.conf; file for more information regarding + the checkpoint controls that Samba implements. + </para> + + </sect3> + + <sect3> + <title>Override Controls</title> + + <para><indexterm> + <primary>over-ride controls</primary> + </indexterm> + Override controls implemented by Samba permit actions like the adoption of a different identity + during file system operations, the forced overwriting of normal file and directory permissions, + and so on. You should refer to the online manual page for the &smb.conf; file for more information regarding + the override controls that Samba implements. + </para> + + <para> + In the following example, you want to create a Windows networking share that any user can access. + However, you want all read and write operations to be performed as if the user <constant>billc</constant> + and member of the group <constant>Mentors</constant> read/write the files. Here is one way this + can be done: +<screen> +[someshare] + comment = Some Files Everyone May Overwrite + path = /data/somestuff + read only = No + force user = billc + force group = Mentors +</screen> + <indexterm> + <primary>forced settings</primary> + </indexterm><indexterm> + <primary>overheads</primary> + </indexterm> + That is all there is to it. Well, it is almost that simple. The downside of this method is that + users are logged onto the Windows client as themselves, and then immediately before accessing the + file, Samba makes system calls to change the effective user and group to the forced settings + specified, completes the file transaction, and then reverts to the actually logged-on identity. + This imposes significant overhead on Samba. The alternative way to effectively achieve the same result + (but with lower system CPU overheads) is described next. + </para> + + <para><indexterm> + <primary>force user</primary> + </indexterm><indexterm> + <primary>force group</primary> + </indexterm><indexterm> + <primary>opportunistic</primary> + <secondary>locking</secondary> + </indexterm><indexterm> + <primary>oplock break</primary> + </indexterm><indexterm> + <primary>performance degradation</primary> + </indexterm> + The use of the <parameter>force user</parameter> or the <parameter>force group</parameter> may + also have a severe impact on system (particularly on Windows client) performance. If opportunistic + locking is enabled on the share (the default), it causes an <constant>oplock break</constant> to be + sent to the client even if the client has not opened the file. On networks that have high traffic + density, or on links that are routed to a remote network segment, <constant>oplock breaks</constant> + can be lost. This results in possible retransmission of the request, or the client may time-out while + waiting for the file system transaction (read or write) to complete. The result can be a profound + apparent performance degradation as the client continually attempts to reconnect to overcome the + effect of the lost <constant>oplock break</constant>, or time-out. + </para> + + </sect3> + + </sect2> + + <sect2> + <title>Share Point Directory and File Permissions</title> + + <para><indexterm> + <primary>security</primary> + </indexterm><indexterm> + <primary>privilege controls</primary> + </indexterm><indexterm> + <primary>permission</primary> + </indexterm><indexterm> + <primary>share definition controls</primary> + </indexterm> + Samba has been designed and implemented so that it respects as far as is feasible the security and + user privilege controls that are built into the UNIX/Linux operating system. Samba does nothing + with respect to file system access that violates file system permission settings, unless it is + explicitly instructed to do otherwise through share definition controls. Given that Samba obeys + UNIX file system controls, this chapter does not document simple information that can be obtained + from a basic UNIX training guide. Instead, one common example of a typical problem is used + to demonstrate the most effective solution referred to in the immediately preceding paragraph. + </para> + + <para><indexterm> + <primary>Microsoft Office</primary> + </indexterm><indexterm> + <primary>Word</primary> + </indexterm><indexterm> + <primary>Excel</primary> + </indexterm> + One of the common issues that repeatedly pops up on the Samba mailing lists involves the saving of + Microsoft Office files (Word and Excel) to a network drive. Here is the typical sequence: + </para> + + <orderedlist> + <listitem><para> + A user opens a Work document from a network drive. The file was owned by user <constant>janetp</constant> + and <group>users</group>, and was set read/write-enabled for everyone. + </para></listitem> + + <listitem><para> + File changes and edits are made. + </para></listitem> + + <listitem><para> + The file is saved, and MS Word is closed. + </para></listitem> + + <listitem><para> + The file is now owned by the user <constant>billc</constant> and group <constant>doctors</constant>, + and is set read/write by <constant>billc</constant>, read-only by <constant>doctors</constant>, and + no access by everyone. + </para></listitem> + + <listitem><para> + The original owner cannot now access her own file and is <quote>justifiably</quote> upset. + </para></listitem> + </orderedlist> + + <para> + There have been many postings over the years that report the same basic problem. Frequently Samba users + want to know when this <quote>bug</quote> will be fixed. The fact is, this is not a bug in Samba at all. + Here is the real sequence of what happens in this case. + </para> + + <para><indexterm> + <primary>MS Word</primary> + </indexterm><indexterm> + <primary>ownership</primary> + </indexterm><indexterm> + <primary>permissions</primary> + </indexterm> + When the user saves a file, MS Word creates a new (temporary) file. This file is naturally owned + by the user who creates the file (<constant>billc</constant>) and has the permissions that follow + that user's default settings within the operating system (UNIX/Linux). When MS Word has finished writing + the file to disk, it then renames the new (temporary) file to the name of the old one. MS Word does not + change the ownership or permissions to what they were on the original file. The file is thus a totally + new file, and the old one has been deleted in the process. + </para> + + <para> + Samba received a request to create a new file, and then to rename the file to a new name. The old file that + has the same name is now automatically deleted. Samba has no way of knowing that the new file should + perhaps have the same ownership and permissions as the old file. To Samba, these are entirely independent + operations. + </para> + + <para> + The question is, <quote>How can we solve the problem?</quote> + </para> + + <para> + The solution is simple. Use UNIX file system permissions and controls to your advantage. Follow these + simple steps to create a share in which all files will consistently be owned by the same user and the + same group: + </para> + + + <procedure> + <title>Using Directory Permissions to Force File User and Group Ownership</title> + <step><para> + Change your share definition so that it matches this pattern: +<screen> +[finance] + path = /usr/data/finance + browseable = Yes + read only = No +</screen> + </para></step> + + <step><para><indexterm> + <primary>permissions</primary> + <secondary>user</secondary> + </indexterm><indexterm> + <primary>permissions</primary> + <secondary>group</secondary> + </indexterm> + Set consistent user and group permissions recursively down the directory tree as shown here: +<screen> +&rootprompt; chown -R janetp.users /usr/data/finance +</screen> + </para></step> + + <step><para><indexterm> + <primary>accessible</primary> + </indexterm> + Set the files and directory permissions to be read/write for owner and group, and not accessible + to others (everyone), using the following command: +<screen> +&rootprompt; chmod ug+rwx,o-rwx /usr/data/finance +</screen> + </para></step> + + <step><para><indexterm> + <primary>SGID</primary> + </indexterm> + Set the SGID (supergroup) bit on all directories from the top down. This means all files + can be created with the permissions of the group set on the directory. It means all users + who are members of the group <constant>finance</constant> can read and write all files in + the directory. The directory is not readable or writable by anyone who is not in the + <constant>finance</constant> group. Simply follow this example: +<screen> +&rootprompt; find /usr/data/finance -type d -exec chmod ug+s {}\; +</screen> + + </para></step> + + <step><para><indexterm> + <primary>group membership</primary> + </indexterm><indexterm> + <primary>primary group</primary> + </indexterm><indexterm> + <primary>/etc/passwd</primary> + </indexterm> + Make sure all users that must have read/write access to the directory have + <constant>finance</constant> group membership as their primary group, + for example, the group they belong to in <filename>/etc/passwd</filename>. + </para></step> + </procedure> + + </sect2> + + <sect2> + <title>Managing Windows 200x ACLs</title> + + <para><indexterm> + <primary>translate</primary> + </indexterm><indexterm> + <primary>Windows 2000 ACLs</primary> + </indexterm><indexterm> + <primary>Posix ACLs</primary> + </indexterm><indexterm> + <primary>side effects</primary> + </indexterm> + Samba must translate Windows 2000 ACLs to UNIX POSIX ACLs. This has some interesting side effects because + there is not a one-to-one equivalence between them. The as-close-as-possible ACLs match means + that some transactions are not possible from MS Windows clients. One of these is to reset the ownership + of directories and files. If you want to reset ownership, this must be done from a UNIX/Linux login. + </para> + + <para> + There are two possible ways to set ACLs on UNIX/Linux file systems from a Windows network workstation, + either via File Manager or via the Microsoft Management Console (MMC) Computer Management interface. + </para> + + <sect3> + <title>Using the MMC Computer Management Interface</title> + + <procedure> + <step><para> + From a Windows 200x/XP Professional workstation, log on to the domain using the Domain Administrator + account (on Samba domains, this is usually the account called <constant>root</constant>). + </para></step> + + <step><para> + Click + <menuchoice> + <guimenu>Start</guimenu> + <guimenuitem>Settings</guimenuitem> + <guimenuitem>Control Panel</guimenuitem> + <guimenuitem>Administrative Tools</guimenuitem> + <guimenuitem>Computer Management</guimenuitem> + </menuchoice>. + </para></step> + + <step><para> + In the left panel, + <menuchoice> + <guimenu>[Right mouse menu item] Computer Management (Local)</guimenu> + <guimenuitem>Connect to another computer ...</guimenuitem> + <guimenuitem>Browse...</guimenuitem> + <guimenuitem>Advanced</guimenuitem> + <guimenuitem>Find Now</guimenuitem> + </menuchoice>. In the lower panel, click on the name of the server you wish to + administer. Click <menuchoice> + <guimenu>OK</guimenu> + <guimenuitem>OK</guimenuitem> + <guimenuitem>OK</guimenuitem> + </menuchoice>. + In the left panel, the entry <guimenu>Computer Management (Local)</guimenu> should now reflect + the change made. For example, if the server you are administering is called <constant>FRODO</constant>, + the Computer Management entry should now say: <guimenu>Computer Management (FRODO)</guimenu>. + </para></step> + + <step><para> + In the left panel, click <menuchoice> + <guimenu>Computer Management (FRODO)</guimenu> + <guimenuitem>[+] Shared Folders</guimenuitem> + <guimenuitem>Shares</guimenuitem> + </menuchoice>. + </para></step> + + <step><para><indexterm> + <primary>Security</primary> + </indexterm><indexterm> + <primary>Properties</primary> + </indexterm><indexterm> + <primary>Permissions</primary> + </indexterm><indexterm> + <primary>Samba Domain server</primary> + </indexterm> + In the right panel, double-click on the share on which you wish to set/edit ACLs. This + brings up the Properties panel. Click the <guimenu>Security</guimenu> tab. It is best + to edit ACLs using the <constant>Advanced</constant> editing features. Click the + <guimenu>Advanced</guimenu> button. This opens a panel that has four tabs. Only the + functionality under the <constant>Permissions</constant> tab can be utilized with respect + to a Samba domain server. + </para></step> + + <step><para><indexterm> + <primary>access control</primary> + </indexterm><indexterm> + <primary>permitted group</primary> + </indexterm> + You may now edit/add/remove access control settings. Be very careful. Many problems have been + created by people who decided that everyone should be rejected but one particular group should + have full control. This is a catch-22 situation because members of that particular group also + belong to the group <constant>Everyone</constant>, which therefore overrules any permissions + set for the permitted group. + </para></step> + + <step><para> + When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu> + buttons until the last panel closes. + </para></step> + </procedure> + + </sect3> + + <sect3> + <title>Using MS Windows Explorer (File Manager)</title> + + <para> + The following alternative method may be used from a Windows workstation. In this example we work + with a domain called <constant>MEGANET</constant>, a server called <constant>MASSIVE</constant>, and a + share called <constant>Apps</constant>. The underlying UNIX/Linux share point for this share is + <filename>/data/apps</filename>. + </para> + + <procedure> + <step><para> + Click <menuchoice> + <guimenu>Start</guimenu> + <guimenuitem>[right-click] My Computer</guimenuitem> + <guimenuitem>Explore</guimenuitem> + <guimenuitem>[left panel] [+] My Network Places</guimenuitem> + <guimenuitem>[+] Entire Network</guimenuitem> + <guimenuitem>[+] Microsoft Windows Network</guimenuitem> + <guimenuitem>[+] Meganet</guimenuitem> + <guimenuitem>[+] Massive</guimenuitem> + <guimenuitem>[right-click] Apps</guimenuitem> + <guimenuitem>Properties</guimenuitem> + <guimenuitem>Security</guimenuitem> + <guimenuitem>Advanced</guimenuitem> + </menuchoice>. This opens a panel that has four tabs. Only the functionality under the + <constant>Permissions</constant> tab can be utilized for a Samba domain server. + </para></step> + + <step><para><indexterm> + <primary>full control</primary> + </indexterm><indexterm> + <primary>over-rule</primary> + </indexterm> + You may now edit/add/remove access control settings. Be very careful. Many problems have been + created by people who decided that everyone should be rejected but one particular group should + have full control. This is a catch-22 situation because members of that particular group also + belong to the group <constant>Everyone</constant>, which therefore overrules any permissions + set for the permitted group. + </para></step> + + <step><para> + When you are done with editing, close all panels by clicking through the <guimenu>OK</guimenu> + buttons until the last panel closes. + </para></step> + </procedure> + + </sect3> + + <sect3> + <title>Setting Posix ACLs in UNIX/Linux</title> + + <para><indexterm> + <primary>desired security setting</primary> + </indexterm><indexterm> + <primary>shared resource</primary> + </indexterm> + Yet another alternative method for setting desired security settings on the shared resource files and + directories can be achieved by logging into UNIX/Linux and setting POSIX ACLs directly using command-line + tools. Here is an example session on the same resource as in the immediately preceding example on a SUSE 9 + Linux system: + </para> + + <procedure> + <step><para> + Log into the Linux system as the user <constant>root</constant>. + </para></step> + + <step><para> + Change directory to the location of the exported (shared) Windows file share (Apps), which is in + the directory <filename>/data</filename>. Execute the following: +<screen> +&rootprompt; cd /data +</screen> + Retrieve the existing POSIX ACLs entry by executing: +<screen> +&rootprompt; getfacl apps +# file: apps +# owner: root +# group: root +user::rwx +group::rwx +other::r-x +</screen> + </para></step> + + <step><para><indexterm> + <primary>recursively</primary> + </indexterm> + You want to add permission for <constant>AppsMgrs</constant> to enable them to + manage the applications (apps) share. It is important to set the ACL recursively + so that the AppsMgrs have this capability throughout the directory tree that is + being shared. This is done using the <constant>-R</constant> option as shown. + Execute the following: +<screen> +&rootprompt; setfacl -m -R group:AppsMgrs:rwx /data/apps +</screen> + Because setting an ACL does not provide a response, you immediately validate the command executed + as follows: +<screen> +&rootprompt; getfacl /data/apps +# file: apps +# owner: root +# group: root +user::rwx +group::rwx +group:AppsMgrs:rwx +mask::rwx +other::r-x +</screen> + This confirms that the change of POSIX ACL permissions has been effective. + </para></step> + + <step><para><indexterm> + <primary>setfacl</primary> + </indexterm><indexterm> + <primary>getfacl</primary> + </indexterm><indexterm> + <primary>directory tree</primary> + </indexterm><indexterm> + <primary>Windows ACLs</primary> + </indexterm><indexterm> + <primary>inheritance</primary> + </indexterm> + It is highly recommended that you read the online manual page for the <command>setfacl</command> + and <command>getfacl</command> commands. This provides information regarding how to set/read the default + ACLs and how that may be propagated through the directory tree. In Windows ACLs terms, this is the equivalent + of setting <constant>inheritance</constant> properties. + </para></step> + </procedure> + + </sect3> + + </sect2> + + <sect2> + <title>Key Points Learned</title> + + <para> + The mish-mash of issues were thrown together into one chapter because it seemed like a good idea. + Looking back, this chapter could be broken into two, but it's too late now. It has been done. + The highlights covered are as follows: + </para> + + <itemizedlist> + <listitem><para><indexterm> + <primary>Winbind</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>password change</primary> + </indexterm><indexterm> + <primary>logon hours</primary> + </indexterm> + Winbind honors and does not override account controls set in Active Directory. + This means that password change, logon hours, and so on, are (or soon will be) enforced + by Samba winbind. At this time, an out-of-hours login is denied and password + change is enforced. At this time, if logon hours expire, the user is not forcibly + logged off. That may be implemented at some later date. + </para></listitem> + + <listitem><para><indexterm> + <primary>Sign'n'seal</primary> + </indexterm><indexterm> + <primary>schannel</primary> + </indexterm> + Sign'n'seal (plus schannel support) has been implemented in Samba-3. Beware of potential + problems acknowledged by Microsoft as having been fixed but reported by some as still + possibly an open issue. + </para></listitem> + + <listitem><para><indexterm> + <primary>Kerberos</primary> + </indexterm><indexterm> + <primary>OpenLDAP</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>inter-operability</primary> + </indexterm> + The combination of Kerberos 5, plus OpenLDAP, plus Samba, cannot replace Microsoft + Active Directory. The possibility to do this is not planned in the current Samba-3 + roadmap. Samba-3 does aim to provide further improvements in interoperability so that + UNIX/Linux systems may be fully integrated into Active Directory domains. + </para></listitem> + + <listitem><para> + This chapter reviewed mechanisms by which Samba servers may be kept secure. Each of + the four key methodologies was reviewed with specific reference to example deployment + techniques. + </para></listitem> + </itemizedlist> + + </sect2> + +</sect1> + +<sect1> + <title>Questions and Answers</title> + + <para> + </para> + + <qandaset defaultlabel="chap10qa" type="number"> + <qandaentry> + <question> + + <para><indexterm> + <primary>Sign'n'seal</primary> + </indexterm><indexterm> + <primary>registry hacks</primary> + </indexterm> + Does Samba-3 require the <constant>Sign'n'seal</constant> registry hacks needed by Samba-2? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>schannel</primary> + </indexterm><indexterm> + <primary>Sign'n'seal</primary> + </indexterm><indexterm> + <primary>registry change</primary> + </indexterm> + No. Samba-3 fully supports <constant>Sign'n'seal</constant> as well as <constant>schannel</constant> + operation. The registry change should not be applied when Samba-3 is used as a domain controller. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para> + Does Samba-3 support Active Directory? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>Active Directory</primary> + </indexterm> + Yes. Samba-3 can be a fully participating native mode Active Directory client. Samba-3 does not + provide Active Directory services. It cannot be used to replace a Microsoft Active Directory + server implementation. Samba-3 can function as an Active Directory client (workstation) toolkit, + and it can function as an Active Directory domain member server. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>mixed-mode</primary> + </indexterm> + When Samba-3 is used with Active Directory, is it necessary to run mixed-mode operation, as was + necessary with Samba-2? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>native</primary> + </indexterm> + No. Samba-3 can be used with NetBIOS over TCP/IP disabled, just as can be done with Windows 200x + Server and 200x/XPPro client products. It is no longer necessary to run mixed-mode operation, + because Samba-3 can join a native Windows 2003 Server ADS domain. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>share level access controls</primary> + </indexterm> + Is it safe to set share-level access controls in Samba? + </para> + + </question> + <answer> + + <para> + Yes. Share-level access controls have been supported since early versions of Samba-2. This is + very mature technology. Not enough sites make use of this powerful capability, neither on + Windows server or with Samba servers. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>share ACLs</primary> + </indexterm> + Is it mandatory to set share ACLs to get a secure Samba-3 server? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>file system security</primary> + </indexterm><indexterm> + <primary>Windows 200x ACLs</primary> + </indexterm><indexterm> + <primary>share definition controls</primary> + </indexterm><indexterm> + <primary>share level ACL</primary> + </indexterm><indexterm> + <primary>security</primary> + </indexterm> + No. Samba-3 honors UNIX/Linux file system security, supports Windows 200x ACLs, and provides + means of securing shares through share definition controls in the &smb.conf; file. The additional + support for share-level ACLs is like frosting on the cake. It adds to security but is not essential + to it. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>valid users</primary> + </indexterm> + The <parameter>valid users</parameter> did not work on the <smbconfsection name="[homes]"/>. + Has this functionality been restored yet? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>meta-service</primary> + </indexterm> + Yes. This was fixed in Samba-3.0.2. The use of this parameter is strongly recommended as a safeguard + on the <smbconfsection name="[homes]"/> meta-service. The correct way to specify this is: + <smbconfoption name="valid users">%S</smbconfoption>. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>force user</primary> + </indexterm><indexterm> + <primary>force group</primary> + </indexterm><indexterm> + <primary>bias</primary> + </indexterm> + Is the bias against use of the <parameter>force user</parameter> and <parameter>force group</parameter> + really warranted? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>performance</primary> + </indexterm> + There is no bias. There is a determination to recommend the right tool for the task at hand. + After all, it is better than putting users through performance problems, isn't it? + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para> + The example given for file and directory access control forces all files to be owned by one + particular user. I do not like that. Is there any way I can see who created the file? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>SUID</primary> + </indexterm> + Sure. You do not have to set the SUID bit on the directory. Simply execute the following command + to permit file ownership to be retained by the user who created it: +<screen> +&rootprompt; find /usr/data/finance -type d -exec chmod g+s {}\; +</screen> + Note that this required no more than removing the <constant>u</constant> argument so that the + SUID bit is not set for the owner. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>Computer Management</primary> + </indexterm> + In the book, <quote>The Official Samba-3 HOWTO and Reference Guide</quote>, you recommended use + of the Windows NT4 Server Manager (part of the <filename>SRVTOOLS.EXE</filename>) utility. Why + have you mentioned only the use of the Windows 200x/XP MMC Computer Management utility? + </para> + + </question> + <answer> + + <para><indexterm> + <primary>MMC</primary> + </indexterm><indexterm> + <primary>SRVTOOLS.EXE</primary> + </indexterm> + Either tool can be used with equal effect. There is no benefit of one over the other, except that + the MMC utility is present on all Windows 200x/XP systems and does not require additional software + to be downloaded and installed. Note that if you want to manage user and group accounts in your + Samba-controlled domain, the only tool that permits that is the NT4 Domain User Manager, which + is provided as part of the <filename>SRVTOOLS.EXE</filename> utility. + </para> + + </answer> + </qandaentry> + + <qandaentry> + <question> + + <para><indexterm> + <primary>valid users</primary> + </indexterm><indexterm> + <primary>Active Directory</primary> + </indexterm><indexterm> + <primary>Domain Member server</primary> + </indexterm> + I tried to set <parameter>valid users = @Engineers</parameter>, but it does not work. My Samba + server is an Active Directory domain member server. Has this been fixed now? + </para> + + </question> + <answer> + + <para> + The use of this parameter has always required the full specification of the domain account, for + example, <parameter>valid users = @"MEGANET2\Domain Admins"</parameter>. + </para> + + </answer> + </qandaentry> + + </qandaset> + +</sect1> + +</chapter> + |