Section 11.2. Dissection and Discussion
11.2. Dissection and DiscussionSamba-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. 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. 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. 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. 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? 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. 11.2.1. Technical IssuesEach issue is now discussed and, where appropriate, example implementation steps are provided. Winbind and Security Windows network administrators may be dismayed to find that winbind 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. winbind 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. Windows network administrators need to recognize that winbind does not, and cannot, override account controls set using the Active Directory management tools. The control is the same. Have no fear. Where Samba and the ADS domain account information obtained through the use of winbind 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:
Examples of each are given in Section 11.3. User and Group Controls 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. 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. 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. Security Overall 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. 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. 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. 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. 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. Cryptographic Controls (schannel, sign'n'seal) The report correctly mentions that Samba did not support the most recent schannel and digital sign'n'seal 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 they reflect accurately (at best) status at a snapshot in time. Meanwhile, the world moves on. 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. 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 digital sign'n'seal support often dismiss the problems that Microsoft has acknowledged[2] and for which a fix was provided. In fact, Tangent Systems[3] 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.
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. Active Directory Replacement with Kerberos, LDAP, and Samba 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. 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. 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. 11.2.1.1 Kerberos ExposedKerberos 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. 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. 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. 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 University of Paderborn, 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. A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation of it. For example, a 2002 IDG[4] report[5] by states:
It so happens that Microsoft Windows clients depend on and expect the contents of the unspecified fields 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. Microsoft makes the following comment in a reference in a technet[6] article:
|
EAN: 2147483647
Pages: 142