|
One of the features that makes SUSE relatively simple to manage is that all of the graphical configuration tools are gathered together in the YaST Control Center, (Yet another Setup Tool). You can start YaST from the Computer Menu on your task bar, if you are not authenticated as root you will be prompted for the root password. By selecting Network Services > Samba Server you will start SAMBA configuration tool. The default install will add SAMBA but if it had not been installed it will automatically install it for you with this selection.
The first step will ask you to set the workgroup or domain name. The one box will set either workgroup or domain name. I want to create a domain called BEGINLINUX so I have changed the default setting of WORKGROUP to BEGINLINUX. The name that you enter here has to be fifteen characters or less. The name needs to meet the restrictions for NETBIOS which allows for just 15 character names. The name can include Unicode characters, numbers, spaces, and symbols: ! @ # $ % ^ & ' ) ( . - _ { } ~ .
The second step, Step 2 or 2, requires you to state if you are creating a new domain (PDC) , acting as a domain controller in an existing domain (BDC) or a standalone server, (Not a Domain Controller). We are creating a new domain so we can leave the default selection of PDC.
These two steps, once completed, then take you to the main configuration tabs. From here we manage the SAMBA Server and create shares.
Start-Up Tab
The first tab, Start-Up, asks about start-up and firewall settings. Select “During Boot” is you would like the SAMBA service to run every time your server starts. This is normal. The firewall settings are greyed out as I disabled the firewall during the installation. If yours are not greyed then you will want to “Open Port in Firewall”
Shares Tab
Clicking the Shares tab allows you to edit, delete and define shares on the server. This is the main purpose of SAMBA : file and print sharing.
SUSE and most distributions of Linux will have similar default shares. Importantly the user’s home directories and all printers are shared. You can see from the selection above the “homes” share does not have a path. This “special share” which allows each user's home directory to be shared out individually. In other words, if your user account is called geeko your home directory can be accessed with the share-name of geeko on the server.
Use the Add button to create new shares, Edit to change the share settings and Delete to stop sharing a directory.
For the moment we will leave this “as is”. Essentially with the home directories shared out. Later we will look at creating new shares from the command line. It is easy enough with the GUI and is self explanatory, hence we shall see review this from the command line.
SAMBA offers flexibility in back-end account database storage. The flexibility is immediately obvious as one begins to explore this capability. Recent changes to SAMBA (since 3.0.23) have removed the multiple back-end feature in order to simplify problems that broke some installations. This removal has made the internal operation of SAMBA-3 more consistent and predictable. openSUSE 11.4 uses SAMBA version 3.5.7 and defaults to the TDB password back-end, (you can always check your version with the command rpm –qa samba : see the output from the following graphic).
smbpasswd: Encrypted Password Database
Traditionally, when configuring encrypt passwords = yes in Samba's smb.conf file, user account information such as username, LM/NT password hashes, password change times, and account flags have been stored in the smbpasswd file. There are several disadvantages to this approach for sites with large numbers of users (counted in the thousands). Because of the tradition behind the smbpasswd file many tutorials base themselves only around this password file for SAMBA. This is OK for small sites as we teach here but added security is offered with the openSUSE default TDB. The issues with smbpassd are discussed below:
-
The first problem is that all lookups must be performed sequentially. Given that there are approximately two lookups per domain logon (one during initial log-on validation and one for a session connection setup, such as when mapping a network drive or printer), this is a performance bottleneck for large sites. What is needed is an indexed approach such as that used in databases.
-
The second problem is that administrators who desire to replicate an smbpasswd file to more than one SAMBA server are left to use external tools such as rsync and ssh and write custom, in-house scripts.
-
Finally, the amount of information that is stored in an smbpasswd entry leaves no room for additional attributes such as a home directory, password expiration time, or even a relative identifier (RID).
TDB
SAMBA can store user and machine account data in a “TDB” (trivial database). Using this back-end does not require any additional configuration. This back-end is recommended for new installations that do not require LDAP.
As a general guide it is not recommend using the tdbsam back-end for sites that have 250 or more users. Additionally, tdbsam is not suited to sites that require replication of the account database. Clearly, for reason of scalability, the use of ldapsam should be encouraged.
The recommendation of a 250-user limit is purely based on the notion that this would generally involve a site that has routed networks, possibly spread across more than one physical location, or, not your home office / small office.
ldapsam
For larger implementation integration with LDAP is recommended. This allows replication of the back-end and the possibility of a single Linux account / SAMBA account for each user rather than a Linux account in /etc/passwd and the SAMBA account in the TDB back-end. Additionally and LDAP Server can provid authentication for many other services such as MySQL, Apache etc. Thus providing far more flexibility and simplified account management which needed in the Enterprise.
No matter which back-end we use the single command: smbpasswd , can be used to enable an existing Linux account for SAMBA access. When we close the initial YaST SAMBA configuration the root account will be SAMBA enabled. Other accounts can have their accounts enabled using the command smbpasswd or though the Users and Groups tool in YaST.
The final two tabs we do not need to use in this implementation.
-
Trusted Domains: Allows you to create trust relationships with other Domains so that their users may access your resources. An Enterprise feature that smaller set-ups will not require.
-
LDAP Settings: Stores the information required to connect to your LDAP password back-end. We are using the TDB so this is not required. We will look at using openLDAP in other tutorials.
Clicking the OK button in the bottom right of the main configuration will save your setting and will prompt for a SAMBA password for the root user. The root user will act as your Administrator of the domain. The password is stored in your password database as discussed before. On completion your SAMBA server is started and is ready to use. Remember though, at this stage we only have the root account that is SAMBA enabled. SAMBA enabled means that:
-
The account has a SID (Windows Unique Identifier)
-
It has a SAMBA password
- These, along with the username are stored in the SAMBA password back-end.
|
