Installing SaMBa with OpenLDAP support
The Samba Section
Preparations
First off, get yourself this wonderful book - and READ IT. Next, make sure our user backend of choice, OpenLDAP, is properly installed and can be used to authenticate users. If you haven't yet installed OpenLDAP, go to the relevant section of this wiki, and get going. Make sure your OpenLDAP is running well.
Software installation
This is easy: using aptitude, install the following packages:
- samba, the actual server.
- samba-tools, a set of utilities.
- samba-doc - note that we NEED samba-doc, as this package contains a configuration file that we need (the LDAP schema file).
- smbclient, that can make your Linux server work with a Windows or SaMBa server; we need this to test our own server.
As usual, Debian is asking us for the configuration details. For SaMBa 3.2, there are only two simple questions:
- What do you want to be your Windows workgroup name? (we provide the name "AMBER")
- Do you want to modify smb.conf to use WINS setting from DHCP? (we provide "no")
Now we have our SaMBa configuration file as /etc/samba/smb.conf, but we're going to follow two time-honoured tradions: we're going to save the original configuration file for future reference, and we're going to rename our configuration file to smb.conf.master, while providing SaMBa with a comment-stripped version of it:
cd /etc/samba cp smb.conf smb.conf.sample mv smb.conf smb.conf.master testparm smb.conf.master testparm -s smb.conf.master > smb.conf
Now remember: when we want to change our SaMBa configuration, we edit smb.conf.master. Once we're ready with that, we ALWAYS need to run those last two lines; the first of those will check our updated configuration, to see if we haven't made some silly typo that renders the configuration wholly or partially crippled, and the second one creates a comment-stripped version of it that SaMBa will actually be using.
WINS configuration
To enable WINS, we add the following lines to smb.conf.master:
## Browsing/Identification ### workgroup = AMBER netbios name = DWORKIN
# Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes os level = 33 domain master = yes local master = yes preferred master = yes name resolve order = wins lmhosts hosts bcast dns proxy = yes
Now this does a whole lot of things with the SaMBa nmbd daemon - at least when you remember to save the master config file, test it with testparm and write the actual smb.conf as desribed previously, AND then restart your nmbd daemon:
/etc/init.d/samba restart
OK so what do the configuration lines mean?
- workgroup = AMBER - this line makes the SaMBa server a member of workgroup AMBER.
- netbios name = DWORKIN - here we define the server NetBIOS name to be "dworkin".
- wins support = yes - this line actually turns on the WINS support, so it instructs the nmbd daemon to start acting as a WINS server.
- os level = 33 - this gives our WINS server a "rank" of 33, meaning that it will be sure to become the WINS master browser, even if there are Windows servers on the network tat act as domain controllers.
- domain master = yes - this will tell our server that it will not be just any master browser, but a domain master browser, so that our server will be the master browser on each and every subnet that it is connected to.
- local master = yes - this setting is vital to being a domain master browser, as it ensures that our WINS server is also the local master browser.
- preferred master = yes - adding this line makes the nmbd daemon initiate a browser election as soon as it starts up, so that it essentially gets the master browser role as fast as possible.
- name resolve order = wins lmhosts hosts bcast - this ensures that for a WINS request, the nmbd daemon not only checks its WINS database, but also the local lmhosts file (if it exists), the Linux /etc/hosts file, and finally, to revert to a broadcast to see if it can locate the requested name by shouting out for it.
- dns proxy = yes - this makes nmbd to check a requested name with the DNS server, if it cannot be found in the WINS database itself.
After restarting, we can see if our Linux server is now a WINS master browser by inspecting the SaMBa log file, by default /var/log/samba/nmbd.log. It should show something like
[2008/11/21 16:18:03, 0] nmbd/nmbd.c:main(849) nmbd version 3.2.4 started. Copyright Andrew Tridgell and the Samba Team 1992-2008 [2008/11/21 16:18:03, 0] nmbd/asyncdns.c:start_async_dns(155) started asyncdns process 25707 [2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(336) become_domain_master_browser_wins: Attempting to become domain master browser on workgroup AMBER, subnet UNICAST_SUBNET. [2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(350) become_domain_master_browser_wins: querying WINS server from IP 192.168.67.10 for domain master browser name AMBER<1b> on workgroup AMBER [2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(110) ***** Samba server DWORKIN is now a domain master browser for workgroup AMBER on subnet UNICAST_SUBNET ***** [2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(291) become_domain_master_browser_bcast: Attempting to become domain master browser on workgroup AMBER on subnet 192.168.67.10 [2008/11/21 16:18:03, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(304) become_domain_master_browser_bcast: querying subnet 192.168.67.9 for domain master browser on workgroup AMBER [2008/11/21 16:18:11, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(110) ***** Samba server DWORKIN is now a domain master browser for workgroup AMBER on subnet 192.168.67.10 ***** [2008/11/21 16:18:26, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(395) ***** Samba name server DWORKIN is now a local master browser for workgroup AMBER on subnet 192.168.67.10 *****
Furthermore, we can test on the server itself if a WINS lookup succeeds:
dworkin:# nmblookup -M amber querying amber on 127.255.255.255 192.168.67.10 amber<1d>
Finally, we tell our DHCP server to provide clients with the IP address of our WINS server. We do this by adding the following line to /etc/dhcp3-server/dhcpd.conf:
option netbios-name-servers 192.168.67.10;
This line can either be added to the global section, or within the subnet declaration for each individual subnet that you want to inform of this WINS server.
OpenLDAP adaptation
In order for our OpenLDAP server to recognise the SaMBa-specific attributes that we're going to use, we need to add the "samba" schema to the OpenLDAP server. After installation of samba-doc, we can find this schema in /usr/share/doc/samba-doc/examples/LDAP, where it sits gzipped between some other schema files; as the README explains, what we need is samba.schema.gz, so we unzip it and copy it to our OpenLDAP schema directory
cd /usr/share/doc/samba-doc/examples/LDAP gunzip samba.schema.gz cp samba.schema /etc/ldap/schema
Next up, we include this schema into our LDAP configuration, by adding the following line to /etc/ldap/slapd.conf under # Schema and objectClass definitions:
include /etc/ldap/schema/samba.schema
Not only do we need schema updates, we could also do with some more indices. Thus, we change the relevant section of /etc/ldap/slapd.conf to read:
# Indexing options for database #1 index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
Ofcourse, it's not just enough to add these parameters, we also need to generate the indices, and restart our LDAP server:
sudo invoke-rc.d slapd stop sudo -u openldap slapindex sudo invoke-rc.d slapd start
Check to see if the Samba objects are now usable in your LDAP server, e.g. by opening your LDAP Account Manager, and go to tools > schema browser; you should have objects like "sambaConfig" and "sambaDomain".
Feed OpenLDAP with Samba information
Now we can add the Samba3 account information to our LDAP server. There are two ways of doing that: create an LDAP ldif file with the necessary information, or use the graphic LDAP manager to add it. For small amounts of users, the last way is quickest. What you need is to take two steps:
Add the SaMBa domain to the LDAP tree
For this step, as root you perform the following command
net getlocalsid
This will a string like "SID for domain DWORKIN is: S-1-5-21-2406862431-3150385097-213705319". With this SID, we can create the LDAP object that represents the SaMBa domain. To that end we log into our LDAP account manager, go to "Samba domains", and create our domain. There are only three pieces of information that are mandatory:
- the domain name, in our example "amber"
- the forementioned SID, in our example "S-1-5-21-2406862431-3150385097-213705319".
- the RID base; this has a default of 1000, which you should not change unless you know exactly what you're doing.
However, there are other options that you might find it worth setting, like the minimal password length, password history length, if users should be disconnected "outside logon hours" etcetera. We would advise you to not set too many options until you've finished testing all basic functionality of your SaMBa server.
In case you're curious, the LDAP ldif file for such an account could look like this:
dn: sambaDomainName=amber,ou=domains,dc=saruman,dc=biz objectClass: sambaDomain sambaDomainName: amber sambaSID: S-1-5-21-2476862421-3150885297-210706319 sambaAlgorithmicRidBase: 1000 sambaMinPwdLength: 7 sambaPwdHistoryLength: 5 sambaLogonToChgPwd: 0 sambaForceLogoff: -1 sambaRefuseMachinePwdChange: 1 dn: sambaDomainName=DWORKIN,dc=saruman,dc=biz objectClass: sambaDomain sambaDomainName: DWORKIN sambaSID: S-1-5-21-2476862421-3150885297-210706319 sambaAlgorithmicRidBase: 1000 sambaNextUserRid: 1000 sambaMinPwdLength: 5 sambaPwdHistoryLength: 0 sambaLogonToChgPwd: 0 sambaMaxPwdAge: -1 sambaMinPwdAge: 0 sambaLockoutDuration: 30 sambaLockoutObservationWindow: 30 sambaLockoutThreshold: 0 sambaForceLogoff: -1 sambaRefuseMachinePwdChange: 0
Add the SaMBa account information to LDAP user accounts
Again we use our LDAP account manager, and we now go to a user that we want to provide access to SaMBa. When you choose to edit the user, there should be a tab "Samba 3". In this tab, you can click the button "Add Samba 3 account"; until you've done that, this user has no access at all to the Samba server.
When adding (or changing) a users Samba account information, there is actually only one mandatory field:
- "Domain": from this pulldown list you can choose the SaMBa/Windows domain that the user will belong to. When you have only your one SaMBa domain entered in your LDAP, this field will show the name of that domain.
Furthermore, there are a few more fields that you might want to fill. They are:
- "Display name": the name that Windows shows for a user
- "Samba password": this may be a different password from a Unix account that the user may have
- Windows group: this is the primary group that the user belongs to, from a SaMBa perspective instead of a Unix perspective.
Having added the necessary information, the user should be able from a Windows machine to browse the SaMBa server, and see all non-hidden shares that are available to him. Furthermore, from a Linux prompt, you could use smbclient to verify that SaMBa honours the users name and password:
smbclient //192.168.67.10/Data -U jan
If the Data share has been made (for that: see further down), and if user "jan" has a Samba account in LDAP, and if you type the correct password, then you're greeted with an SMB client prompt:
smb: \>
Here you can type commands like "dir", "del" and "mkdir"; type "help" to see all available commands.
Samba configuration for LDAP authentication
To get SaMBA to use OpenLDAP as a backend is actually quite straightforward. The main work is done in smb.conf.master, where we add the following section:
passdb backend = ldapsam:ldap://127.0.0.1 ldap suffix = dc=saruman,dc=biz ldap machine suffix = ou=hosts ldap user suffix = ou=people ldap group suffix = ou=groups ldap admin dn = cn=admin,dc=saruman,dc=biz ldap delete dn = no # allow user privileges enable privileges = yes
One note: if you use testparm -s to test and convert smb.conf.master, then it's possible that your ldap suffix statement gets lower than one or more than the other ldap statements; you should rectify that before starting SaMBa, because otherwise SaMBa gets mighty confused, and cannot find the right LDAP OU's.
Now the above declares the LDAP account admin,saruman,biz to be the LDAP admin account - but SaMBa hasn't got the admin password yet, so it can't do much. To this end, we let SaMBa store the password for this admin account in its own little secret file /etc/samba/secrets.tdb. We do this by running
smbpasswd -W Setting stored password for "cn=admin,dc=saruman,dc=biz" in secrets.tdb New SMB password: Retype new SMB password:
If we used a lowercase -w, then we could have specified the password on the command line (smbpasswd -w SuperSecret).
With the above configuration, we should now be able to create a share, and make it available to our LDAP accounts. To this end, we create a directory that we're going to share, and give it a workable set of permissions. Suppose we have an LDAP user "jan" and an LDAP group "networkusers". We could then, as root, do this:
cd /data/samba mkdir Data chown jan:networkusers Data chmod g+rwxs,o-rwx Data
This ensures that user "jan", as well as every user that's a member of "networkusers", is allowed to read and write in this share. However, thanks to the "sticky bit" set for the group with the chmod command, files that are written to this directory are automatically owned by the group "networkusers", who have read & write rights.
Next step would be to share this directory, by adding the following section to smb.conf.master:
[Data] comment = Data directory for us all browseable = yes path = /data/samba/Data guest ok = no read only = no create mask = 0770 create directory mask = 0770
This makes the directory usable via the share "Data". Notice that we do not allow unauthenticated users ("guest ok = no"), that we allow writing in this share ("read only = no", although we could also have used "writeable = yes", which is the same), and that we mask every create operation (for both files and directories) so that they can set any right under "user" and "group", but cannot set any rights under "other". This prevents anyone other than the "networkusers" to read (let alone write) the files in this share.