Active Directory, Kerberos, and Security

Active Directory, Kerberos, and Security experiment 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. criticism 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. 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. straw-man 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. Introduction acquisitions risk assessment Active Directory Windows 2003 Serve 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. Active Directory 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 an island of broken technologies. This comment was made by one of Christine's staff as they were installing a new Samba-3 server at the new business. consultant hypothetical 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 reportThis report is entirely fictitious. Any resemblance to a factual report is purely coincidental. on his unit's operations and to investigate the role of Samba at his site. Here are key extracts from this hypothetical report:

vulnerabilities integrity practices Active Directory ... 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. ... accounts user accounts group Backup disaster recovery validated off-site storage 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. compromise secure network secure Your staff are justifiably concerned that the use of Samba may compromise their good efforts to maintain a secure network. winbind security secure network management The recently installed Linux file and application server uses a tool called winbind 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. isolated firewall best practices 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. ... security disable essential trusted computing 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. integrity hackers accountable flaws updates bug fixes alarm 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. employment jobs risk 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.

Active Directory independent expert 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: Good afternoon,

Stan 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. 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. Kerberos OpenLDAP Active Directory consultant 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. criticism policy Windows Servers Active Directory budgetted financial responsibility 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.

Assignment Tasks 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. Dissection and Discussion tool benefit choice consultant installation income employment 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. economically sustainable inter-operability file and print service cost alternative 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. documentation responsibility fix broken 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. commercial software commercial software End User License Agreement EULA accountable liability accepts liability price paid product defects reimburse extent 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. consumer EULA track record commercial software support vendor 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? source code Open Source hire programmer solve fix problem 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. Technical Issues Each issue is now discussed and, where appropriate, example implementation steps are provided. Winbind and Security Winbind Security network administrators Domain users Domain account credentials Network Neighborhood UNIX/Linux server browse shares 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. Domain Member server familiar fear unknown 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. network administrators recognize winbind over-ride Active Directory management tools fears 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. ADS Domain account ADS Domain winbind browsing permits access drive mapping protected security controls access controls 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: Shares themselves (i.e., the logical share itself) The share definition in &smb.conf; The shared directories and files using UNIX permissions Using Windows 2000 ACLs &smbmdash; if the file system is POSIX enabled Examples of each are given in . User and Group Controls User and Group Controls management User management group ADS permissions privileges flexibility access controls share definition 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. analysis system security safe-guards permissions excessive file system shared resource share definition 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. diligence weakness 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 defects 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. security protection compromise consequential risk 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. condemns security fixes updates development documentation security updates turn-around time 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. modularization next generation responsible dependability road-map published 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. foundation members Common Internet File System CIFS network attached storage NAS conferences presence and leadership leadership inter-operability 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) Cryptographic schannel digital 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 &smbmdash; they reflect accurately (at best) status at a snapshot in time. Meanwhile, the world moves on. public specifications protocols algorithm compatible network traffic observation defensible standards secure networking 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 digital sign'n'seal 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 and for which a fix was provided. In fact, Tangent Systems appears even todayJanuary 2004 to be unsure whether the problem has been resolved, it is evident that some delay in release of new functionality may have fortuitous consequences. secure networking protocols refereed standards proprietary digital rights protection networking protocols diffusion consumer choice 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 Active Directory Replacement Kerberos LDAP remote procedure call RPC 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. Active Directory Server OpenLDAP Kerberos project maintainers LDAP 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. missing RPC's road-map ADS server MMC managed 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. Kerberos Exposed kerberos unauthorized activities authorized location 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. strong cryptography identity integrity 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. trusted third-party principals trusting kerberos server secret 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. restricted export MIT Kerberos Heimdal Kerberos 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. Kerberos interoperability A storm has broken out concerning interoperability between MIT Kerberos and Microsofts' implementation of it. For example, a 2002 report by IDG states:

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. Kerberos unspecified fields 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.

DCE RPC 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 article:

Privilege Attribute Certificates PAC access control 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.

Implementation The following procedures outline the implementation of the security measures discussed so far. Share Access Controls Share Access Controls filter connection 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. Create/Edit/Delete Share ACLs Domain Administrator account 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 root). Click Start Settings Control Panel Administrative Tools Computer Management . In the left panel, [Right mouse menu item] Computer Management (Local) Connect to another computer ... Browse... Advanced Find Now . In the lower panel, click on the name of the server you wish to administer. Click OK OK OK . Computer Management In the left panel, the entry Computer Management (Local) should now reflect the change made. For example, if the server you are administering is called FRODO, the Computer Management entry should now say Computer Management (FRODO). In the left panel, click Computer Management (FRODO) [+] Shared Folders Shares . ACLs Share Permissions 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 Share Permissions tab. access control settings Everyone full control over-rule permissions rejected 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 Everyone, which therefore overrules any permissions set for the permitted group. When you are done with editing, close all panels by clicking through the OK buttons. Share Definition Controls Share Definition Controls check-point pile-driver credential powers privileges 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. access controls ACLs share definition controls hierarchy of control 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: Share-level ACLs Share-definition controls Directory and file permissions Directory and file POSIX ACLs Checkpoint Controls Checkpoint Controls Consider the following extract from a &smb.conf; file defining the share called Apps: [Apps] comment = Application Share path = /data/apps read only = Yes valid users = @Employees This definition permits only those who are members of the group called Employees to access the share. Domain Member servers winbind use default domain fully qualified valid users delimiter On domain member servers and clients, even when the winbind use default domain has been specified, the use of domain accounts in security controls requires fully qualified domain specification, for example, @"MEGANET\Northern Engineers". Note the necessity to use the double quotes to avoid having the space in the Windows group name interpreted as a delimiter. ACL access validate If there is an ACL on the share itself to permit read/write access for all Employees as well as read/write for the group Doctors, 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 Doctors, who is not also a member of the group Employees, would immediately fail to validate. share definition controls Consider another example. In this case, you want to permit all members of the group Employees except the user patrickj to access the Apps share. This can be easily achieved by setting a share-level ACL permitting only Employees to access the share, and then in the share definition controls excluding just patrickj. Here is how that might be done: [Apps] comment = Application Share path = /data/apps read only = Yes invalid users = patrickj permissions Let us assume that you want to permit the user gbshaw to manage any file in the UNIX/Linux file system directory /data/apps, but you do not want to grant any write permissions beyond that directory tree. Here is one way this can be done: [Apps] comment = Application Share path = /data/apps read only = Yes invalid users = patrickj admin users = gbshaw administrative rights Now we have a set of controls that permits only Employees who are also members of the group Doctors, excluding the user patrickj, to have read-only privilege, but the user gbshaw is granted administrative rights. The administrative rights conferred upon the user gbshaw permit operation as if that user has logged in as the user root 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. There are additional checkpoint controls that may be used. For example, if for the same share we now want to provide the user peters 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: [Apps] comment = Application Share path = /data/apps read only = Yes invalid users = patrickj admin users = gbshaw write list = peters check-point controls 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. Override Controls over-ride controls 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. 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 billc and member of the group Mentors read/write the files. Here is one way this can be done: [someshare] comment = Some Files Everyone May Overwrite path = /data/somestuff read only = No force user = billc force group = Mentors forced settings overheads 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. force user force group opportunistic locking oplock break performance degradation The use of the force user or the force group 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 oplock break 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, oplock breaks 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 oplock break, or time-out. Share Point Directory and File Permissions security privilege controls permission share definition controls 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. Microsoft Office Word Excel 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: A user opens a Work document from a network drive. The file was owned by user janetp and users, and was set read/write-enabled for everyone. File changes and edits are made. The file is saved, and MS Word is closed. The file is now owned by the user billc and group doctors, and is set read/write by billc, read-only by doctors, and no access by everyone. The original owner cannot now access her own file and is justifiably upset. There have been many postings over the years that report the same basic problem. Frequently Samba users want to know when this bug 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. MS Word ownership permissions 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 (billc) 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. 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. The question is, How can we solve the problem? 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: Using Directory Permissions to Force File User and Group Ownership Change your share definition so that it matches this pattern: [finance] path = /usr/data/finance browseable = Yes read only = No permissions user permissions group Set consistent user and group permissions recursively down the directory tree as shown here: &rootprompt; chown -R janetp.users /usr/data/finance accessible Set the files and directory permissions to be read/write for owner and group, and not accessible to others (everyone), using the following command: &rootprompt; chmod ug+rwx,o-rwx /usr/data/finance SGID 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 finance can read and write all files in the directory. The directory is not readable or writable by anyone who is not in the finance group. Simply follow this example: &rootprompt; find /usr/data/finance -type d -exec chmod ug+s {}\; group membership primary group /etc/passwd Make sure all users that must have read/write access to the directory have finance group membership as their primary group, for example, the group they belong to in /etc/passwd. Managing Windows 200x ACLs translate Windows 2000 ACLs Posix ACLs side effects 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. 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. Using the MMC Computer Management Interface 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 root). Click Start Settings Control Panel Administrative Tools Computer Management . In the left panel, [Right mouse menu item] Computer Management (Local) Connect to another computer ... Browse... Advanced Find Now . In the lower panel, click on the name of the server you wish to administer. Click OK OK OK . In the left panel, the entry Computer Management (Local) should now reflect the change made. For example, if the server you are administering is called FRODO, the Computer Management entry should now say: Computer Management (FRODO). In the left panel, click Computer Management (FRODO) [+] Shared Folders Shares . Security Properties Permissions Samba Domain server 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 Security tab. It is best to edit ACLs using the Advanced editing features. Click the Advanced button. This opens a panel that has four tabs. Only the functionality under the Permissions tab can be utilized with respect to a Samba domain server. access control permitted group 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 Everyone, which therefore overrules any permissions set for the permitted group. When you are done with editing, close all panels by clicking through the OK buttons until the last panel closes. Using MS Windows Explorer (File Manager) The following alternative method may be used from a Windows workstation. In this example we work with a domain called MEGANET, a server called MASSIVE, and a share called Apps. The underlying UNIX/Linux share point for this share is /data/apps. Click Start [right-click] My Computer Explore [left panel] [+] My Network Places [+] Entire Network [+] Microsoft Windows Network [+] Meganet [+] Massive [right-click] Apps Properties Security Advanced . This opens a panel that has four tabs. Only the functionality under the Permissions tab can be utilized for a Samba domain server. full control over-rule 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 Everyone, which therefore overrules any permissions set for the permitted group. When you are done with editing, close all panels by clicking through the OK buttons until the last panel closes. Setting Posix ACLs in UNIX/Linux desired security setting shared resource 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: Log into the Linux system as the user root. Change directory to the location of the exported (shared) Windows file share (Apps), which is in the directory /data. Execute the following: &rootprompt; cd /data Retrieve the existing POSIX ACLs entry by executing: &rootprompt; getfacl apps # file: apps # owner: root # group: root user::rwx group::rwx other::r-x recursively You want to add permission for AppsMgrs 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 -R option as shown. Execute the following: &rootprompt; setfacl -m -R group:AppsMgrs:rwx /data/apps Because setting an ACL does not provide a response, you immediately validate the command executed as follows: &rootprompt; getfacl /data/apps # file: apps # owner: root # group: root user::rwx group::rwx group:AppsMgrs:rwx mask::rwx other::r-x This confirms that the change of POSIX ACL permissions has been effective. setfacl getfacl directory tree Windows ACLs inheritance It is highly recommended that you read the online manual page for the setfacl and getfacl 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 inheritance properties. Key Points Learned 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: Winbind Active Directory password change logon hours 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. Sign'n'seal schannel 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. Kerberos OpenLDAP Active Directory inter-operability 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. 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. Questions and Answers Sign'n'seal registry hacks Does Samba-3 require the Sign'n'seal registry hacks needed by Samba-2? schannel Sign'n'seal registry change No. Samba-3 fully supports Sign'n'seal as well as schannel operation. The registry change should not be applied when Samba-3 is used as a domain controller. Does Samba-3 support Active Directory? Active Directory 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. mixed-mode When Samba-3 is used with Active Directory, is it necessary to run mixed-mode operation, as was necessary with Samba-2? native 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. share level access controls Is it safe to set share-level access controls in Samba? 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. share ACLs Is it mandatory to set share ACLs to get a secure Samba-3 server? file system security Windows 200x ACLs share definition controls share level ACL security 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. valid users The valid users did not work on the . Has this functionality been restored yet? meta-service Yes. This was fixed in Samba-3.0.2. The use of this parameter is strongly recommended as a safeguard on the meta-service. The correct way to specify this is: %S. force user force group bias Is the bias against use of the force user and force group really warranted? performance 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? 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? SUID 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: &rootprompt; find /usr/data/finance -type d -exec chmod g+s {}\; Note that this required no more than removing the u argument so that the SUID bit is not set for the owner. Computer Management In the book, The Official Samba-3 HOWTO and Reference Guide, you recommended use of the Windows NT4 Server Manager (part of the SRVTOOLS.EXE) utility. Why have you mentioned only the use of the Windows 200x/XP MMC Computer Management utility? MMC SRVTOOLS.EXE 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 SRVTOOLS.EXE utility. valid users Active Directory Domain Member server I tried to set valid users = @Engineers, but it does not work. My Samba server is an Active Directory domain member server. Has this been fixed now? The use of this parameter has always required the full specification of the domain account, for example, valid users = @"MEGANET2\Domain Admins".