Table of Contents
This chapter provides information regarding the types of server that Samba may be configured to be. A Microsoft network administrator who wishes to migrate to or use Samba will want to know the meaning, within a Samba context, of terms familiar to MS Windows administrator. This means that it is essential also to define how critical security modes function before we get into the details of how to configure the server itself.
The chapter provides an overview of the security modes of which Samba is capable and how they relate to MS Windows servers and clients.
A question often asked is, “Why would I want to use Samba?” Most chapters contain a section that highlights features and benefits. We hope that the information provided will help to answer this question. Be warned though, we want to be fair and reasonable, so not all features are positive towards Samba. The benefit may be on the side of our competition.
Two men were walking down a dusty road, when one suddenly kicked up a small red stone. It hurt his toe and lodged in his sandal. He took the stone out and cursed it with a passion and fury befitting his anguish. The other looked at the stone and said, “This is a garnet. I can turn that into a precious gem and some day it will make a princess very happy!”
The moral of this tale: Two men, two very different perspectives regarding the same stone. Like it or not, Samba is like that stone. Treat it the right way and it can bring great pleasure, but if you are forced to use it and have no time for its secrets, then it can be a source of discomfort.
Samba started out as a project that sought to provide interoperability for MS Windows 3.x clients with a UNIX server. It has grown up a lot since its humble beginnings and now provides features and functionality fit for large scale deployment. It also has some warts. In sections like this one we tell of both.
So, what are the benefits of features mentioned in this chapter?
Samba-3 can replace an MS Windows NT4 Domain Controller.
Samba-3 offers excellent interoperability with MS Windows NT4-style domains as well as natively with Microsoft Active Directory domains.
Samba-3 permits full NT4-style Interdomain Trusts.
Samba has security modes that permit more flexible authentication than is possible with MS Windows NT4 Domain Controllers.
Samba-3 permits use of multiple account database backends.
The account (password) database backends can be distributed and replicated using multiple methods. This gives Samba-3 greater flexibility than MS Windows NT4 and in many cases a significantly higher utility than Active Directory domains with MS Windows 200x.
Administrators of Microsoft networks often refer to three different type of servers:
Domain Controller
Primary Domain Controller
Backup Domain Controller
ADS Domain Controller
Domain Member Server
Active Directory Domain Server
NT4 Style Domain Domain Server
Stand-alone Server
The chapters covering Domain Control, Backup Domain Control and Domain Membership provide pertinent information regarding Samba configuration for each of these server roles. The reader is strongly encouraged to become intimately familiar with the information presented.
In this section the function and purpose of Samba's security modes are described. An accurate understanding of how Samba implements each security mode as well as how to configure MS Windows clients for each mode will significantly reduce user complaints and administrator heartache.
In the SMB/CIFS networking world, there are only two types of security: User Level and Share Level. We refer to these collectively as security levels. In implementing these two security levels, Samba provides flexibilities that are not available with Microsoft Windows NT4/200x servers. In actual fact, Samba implements Share Level security only one way, but has four ways of implementing User Level security. Collectively, we call the Samba implementations Security Modes. They are known as: SHARE, USER, DOMAIN, ADS, and SERVER modes. They are documented in this chapter.
An SMB server tells the client at startup what security level it is running. There are two options: Share Level and User Level. Which of these two the client receives affects the way the client then tries to authenticate itself. It does not directly affect (to any great extent) the way the Samba server does security. This may sound strange, but it fits in with the client/server approach of SMB. In SMB everything is initiated and controlled by the client, and the server can only tell the client what is available and whether an action is allowed.
We will describe User Level Security first, as its simpler.
In User Level Security, the client will send a
session setup request directly following protocol negotiation.
This request provides a username and >
Samba needs to be significantly modified to work with a high-speed server inter-connect system to permit transparent fail-over clustering.
Particular functions inside Samba that will be affected include:
The locking database, oplock notifications, and the share mode database.
Failure semantics need to be defined. Samba behaves the same way as Windows. When oplock messages fail, a file open request is allowed, but this is potentially dangerous in a clustered environment. So how should inter-server pool failure semantics function and how should this be implemented?
Should this be implemented using a point-to-point lock manager, or can this be done using multicast techniques?
Allowing fail-over servers to handle different functions within the exported file system removes the problem of requiring a distributed locking protocol.
If only one server is active in a pair, the need for high speed server interconnect is avoided. This allows the use of existing high availability solutions, instead of inventing a new one. This simpler solution comes at a price the cost of which is the need to manage a more complex file name space. Since there is now not a single file system, administrators must remember where all services are located a complexity not easily dealt with.
The virtual server is still needed to redirect requests to backend servers. Backend file space integrity is the responsibility of the administrator.
Fail-over servers must communicate in order to handle resource fail-over. This is essential for high availability services. The use of a dedicated heartbeat is a common technique to introduce some intelligence into the fail-over process. This is often done over a dedicated link (LAN or serial).
Many fail-over solutions (like Red Hat Cluster Manager, as well as Microsoft Wolfpack) can use a shared SCSI of Fiber Channel disk storage array for fail-over communication. Information regarding Red Hat high availability solutions for Samba may be obtained from: www.redhat.com.
The Linux High Availability project is a resource worthy of consultation if your desire is to build a highly available Samba file server solution. Please consult the home page at www.linux-ha.org/.
Front-end server complexity remains a challenge for high availability as it needs to deal gracefully with backend failures, while at the same time it needs to provide continuity of service to all network clients.
MS-DFS links can be used to redirect clients to disparate backend servers. This pushes complexity back to the network client, something already included by Microsoft. MS-DFS creates the illusion of a simple, continuous file system name space, that even works at the file level.
Above all, at the cost of complexity of management, a distributed (pseudo-cluster) can be created using existing Samba functionality.