View source for Installing SaMBa with OpenLDAP support

== The Samba Section==

== Preparations ==
First off, get yourself [http://oreilly.com/catalog/9780596007690/index.html 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 [[OpenLDAP | 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'''<br>
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'''<br>
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.<br>
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'').

= Samba share configuration =
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.