Configuring Samba AD

We are going to install Samba on our Ubuntu server. To do that, we need to do several things.

• Set the hostname

• Update Apparmor

• Update DNS

Once these tasks are done, we can configure Samba.

First we need to make sure that our hostname is set correctly. We are going to use the hostname dc1.samba.example.com, which is unique in our domain. For a complete understanding of Samba naming recommendations, please read https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ . Our host needs to match the following configuration:

$ hostname –s
dc1
$ hostname –d
samba.example.com

It is a good idea to add dc1.samba.example.com to your /etc/hosts file too.

127.0.0.1   localhost dc1 dc1.samba.example.com

Also, because we are going to let Samba manage its own DNS subdomain, we need to allow it access to bind configuration. The bind9 server must be on the same server as the Samba AD server as it requires access to certain directories. Because we are using an Ubuntu server, we need to make some changes to Apparmor that will allow the bind9 service to access Samba directories. Remember, we spoke about Apparmor in Chapter 12; it is a security module that describes security access for system resources (such as ports and files).

We will add the following to our /etc/apparmor.d/local/usr.sbin.named file, remembering that we add localhost changes into the /etc/apparmor.d/local directory:

# Samba4 DLZ and Active Directory Zones
/var/lib/samba/lib/** rm,
/var/lib/samba/private/dns.keytab r,
/var/lib/samba/private/named.conf r,
/var/lib/samba/private/dns/** rwk,

After saving this file, we then need to load this into Apparmor with the following:

$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.named

To configure our bind9 service in preparation for our Samba configuration, we are going to add the following to the bottom of our /etc/bind/named.conf.options file:

include "/var/lib/samba/private/named.conf";

We will need to reload our bind9 configuration with the following:

$ sudo rndc reload

Now it’s time to configure Samba. Samba provides a tool, called samba-tool, to help configure the Samba server. You may need to remove or copy off any existing /etc/samba/smb.conf file that is present on your system as the following command will create a new file for you.

In Listing 13-1, we have used samba-tool in interactive mode (--interactive). For a full list of options that you can provide on the command line, see samba-tool provision --help. We have provided the --use-rfc2307 option, which tells Samba to store user and group information in the internal LDAP directory. This is useful for maintaining consistent user IDs/group IDs (UIDs/GIDs) across domain members and has some associated benefits; see https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD . We have also provided our preferred hostname (--host-name), dc1.

Listing 13-1. Configuring Samba with samba-tool

$ sudo samba-tool domain provision --use-rfc2307 --host-name=dc1 --interactive
Realm [SAMBA.EXAMPLE.COM]:
 Domain [SAMBA]:
 Server Role (dc, member, standalone) [dc]:
 DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: BIND9_DLZ
Administrator password:
Retype password:
Looking up IPv4 addresses
More than one IPv4 address found. Using 192.168.0.10
Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=samba,DC=example,DC=com
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=samba,DC=example,DC=com
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
See /var/lib/samba/private/named.conf for an example configuration include file for BIND
and /var/lib/samba/private/named.txt for further documentation required for secure DNS updates
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba 4 has been generated at /var/lib/samba/private/krb5.conf
Setting up fake yp server settings
Once the above files are installed, your Samba4 server will be ready to use
Server Role:           active directory domain controller
Hostname:              dc1
NetBIOS Domain:        SAMBA
DNS Domain:            samba.example.com
DOMAIN SID:            S-1-5-21-295742502-4045385941-247307200

In interactive mode we are given the defaults in the [] brackets, and we have chosen the defaults for Realm, Domain, and Server Role. The Server Role setting is dc, which stands for domain controller , meaning we are the authority for the Samba Windows domain, SAMBA.

For DNS , we have the options SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, and NONE. We have chosen BIND9_DLZ, which will tells Samba to manage our DNS subdomain dynamically through the special Samba module we included in our named.conf.options file previously. Samba will create all the necessary DNS records required during the setup process. SAMBA_INTERNAL is also suitable if you want to let Samba own and manage your DNS setup. BIND9_FLATFILE is not a recommended option, and you should choose NONE if you want to completely manage your own DNS.

You will be asked to provide the administrator password. The password needs to be eight or more characters and complex, requiring symbols, letters, and numbers. Once that has been entered, the setup of Samba completes quickly. Once it is complete, we can start our service.

$ sudo systemctl start samba-ad-dc

This starts the Samba service, and you can use the systemctl status samba-ad-dc command to check it has started alright. Also, remember to enable it on boot with systemctl enable samba-ad-dc.

Testing Samba

Now we can test that we can authenticate against the service. To do that, we use the smbclient command, which is the tool used to interact with the Samba service.

$ smbclient –L dc1 -U Administrator
Enter Administrator's password:
Domain=[EXAMPLE] OS=[Windows 6.1] Server=[Samba 4.3.9-Ubuntu]

    Sharename       Type      Comment
    ---------       ----      -------
    netlogon        Disk
    sysvol          Disk
    IPC$            IPC       IPC Service (Samba 4.3.9-Ubuntu)
Domain=[EXAMPLE] OS=[Windows 6.1] Server=[Samba 4.3.9-Ubuntu]

    Server               Comment
    ---------            -------

    Workgroup            Master
    ---------            -------
    WORKGROUP            DC1

Here we have gotten a listing (-L) from our dc1 Samba service using the Administrator user (-U) to authenticate. If you get errors here, then you have made an error in your setup. There is a troubleshooting page that might help you here: https://wiki.samba.org/index.php/Samba_AD_DC_Troubleshooting .

You can see from the test that we have two disk shares (netlogon and sysvol) and one IPC$ (interprocess connection for communicating with Samba). We can run the ls command (-c) to get a listing of the netlogon share, again testing that we can list the netlogon share.

$ smbclient //localhost/netlogon -UAdministrator -c 'ls'
Enter Administrator's password:
Domain=[EXAMPLE] OS=[Windows 6.1] Server=[Samba 4.3.9-Ubuntu]
  .                                   D        0  Sat Sep 24 14:02:06 2016
  ..                                  D        0  Sat Sep 24 14:02:15 2016

        10098468 blocks of size 1024. 7667640 blocks available

$ host -t SRV _ldap._tcp.samba.example.com.
_ldap._tcp.samba.example.com has SRV record 0 100 389 dc1.samba.example.com.
$ host -t SRV _kerberos._udp.samba.example.com.
_kerberos._udp.samba.example.com has SRV record 0 100 88 dc1.samba.example.com.
$ host -t A dc1.samba.example.com.
dc1.samba.example.com has address 192.168.0.10

$ sudo ln –sf /var/lib/samba/private/krb5.conf /etc/krb5.conf

[libdefaults]
    default_realm = SAMBA.EXAMPLE.COM
    dns_lookup_realm = false
    dns_lookup_kdc = true

$ kinit [email protected]
Password for [email protected]:
Warning: Your password will expire in 41 days on Mon 07 Nov 2016 11:04:17 PM UTC

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting       Expires              Service principal
09/26/2016 23:34:37  09/27/2016 09:34:37  krbtgt/[email protected]
    renew until 09/27/2016 23:34:30

Configuring Samba Shares

To access Samba shares, there will be several things we will need to do:

• Add the share to smb.conf

• Create the directory and add permissions

• Create any system users that are necessary

• Add Samba users to Samba

Let’s start by looking at the Samba configuration file we are going to use. This is what is created by the provision process.

The configuration file can be broken up into two sections, the [global] configuration options and then the specific configuration options, such as [netlogon], [sysvol], and so forth (see Listing 13-2). The [global] section, as the name implies, defines the configuration options that affect the whole server, and the specific configurations in [netlogon] and [sysvol] affect only those services they are trying to define.

Listing 13-2. Samba /etc/samba/smb.conf File

# Global parameters
[global]
    workgroup = SAMBA
    realm = SAMBA.EXAMPLE.COM
    netbios name = DC1
    server role = active directory domain controller
    server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
    idmap_ldb:use rfc2307 = yes

[netlogon]
    path = /var/lib/samba/sysvol/samba.example.com/scripts
    read only = No

[sysvol]
    path = /var/lib/samba/sysvol
    read only = No

Let’s go through the [Global] section. First you see the option workgroup. This option should be familiar to you if you are a Windows user. It is the workgroup name that will appear in your network neighborhood. A workgroupis a collection of computers sharing information. Usually, in a workgroup, the computers do not have central authentication, and each host in the workgroup takes care of its own authentication. In other words, you maintain a list of users with access to each host on each host.

Central authentication is achieved when one of the hosts in the workgroup becomes a primary domain controller (PDC) . Hosts join the domain and then use the PDC to authenticate user access to their resources. If the host is not part of a domain, it can still share resources, but it will have to maintain its own authentication and access lists.

Setting the workgroup here does not make our host a PDC, just part of a workgroup. We have set this to our domain name, EXAMPLE.

workgroup = SAMBA

Next you need to configure NetBIOS . NetBIOS is a local broadcast protocol that is used to handle connection information between hosts. NetBIOS information is used to match names to Internet Protocol (IP) addresses in WINS servers, kind of like DNS. The NetBIOS protocol itself is used for a name service, session service, and datagram server. As you can see in Listing 13-2, we are setting the netbios name option to dc1, and we will be able to use this NetBIOS name to refer to our host.

The server role directive is set to active directory domain controller. This obviously means that we are operating an AD DC. If you were to use the classic domain controller, you would set it here (NT4). The server services directive defines the services that this server supports. You can add or remove services here with a + or -, like -kdc.

You can further control access to your Samba service by specifying what hosts can access your service by using the hosts allow option. In our configuration, we specify the loopback network and the 192.168.0. network. The notations 127. and 192.168.0. are equivalent to specifying the network masks 127.0.0.0/8 and 192.168.0.0/24, respectively. Here you can also specify individual hosts by using their full IP address and exclude certain hosts by using the EXCEPT clause. For example, if we want to allow access to all hosts on our 192.168.0. network except a naughty host with the address 192.168.0.15, we would use the following in hosts allow:

hosts allow = 127. 192.168.0. EXCEPT 192.168.0.15

You can also use fully qualified domain names (FQDNs) like headoffice.example.com or gateway.example.com to specify individual hosts. We don’t show it here, but hosts deny allows you to list the hosts and networks you do not want to access this service.

We are going to have the networks 192.168.0.0 to 192.168.30.0 access this Samba service, so we will specify the following, which will allow any address in the 192.168.0.0/16 range to connect:

hosts allow = 127. 192.168.

Samba considers some of the services, demarcated in sections beginning with the [] brackets, to be “special.” Specifically, [global], [printers], and [homes] describe special services. Samba treats these services differently from, say, a [sales] or [tmp] share.

For example, as you would expect, when Samba receives a file via the [printer] service, it deals with it differently from a file received via a user-defined [tmp] service. Samba has functions that are associated with definitions only in these “special” services. In this example, a path definition in [printer] defines a spooling directory. When your printer spools your printout to this path via the [printer] service, Samba automatically passes it on to CUPS for printing. Setting the value for path in another service will not trigger this behavior. This special behavior also applies to [homes], where Samba will create home directories dynamically if required. You can read more under the “Special Sections” section in the smb.conf man page.

When you define your own services, you use a set of directives that are common to special services and user-defined services. In Table 13-1, we have listed the directives that we will use in our example. You would use these directives to alter or create your own services.

You can use these service directives to define the path and access rights to your shares. There are many more directives available, and you can find a comprehensive explanation of them in the man smb.conf page.

The [netlogon] share is not classified as a special service in Samba, but it is a standard service in many default smb.conf files and is included by default in the Ubuntu and CentOS Samba packages. That and [sysvol] have been created as part of the default configuration process. The [netlogon] service is used to authenticate Windows clients and can contain things such as login scripts and other information. The [sysvol] service is required by each domain controller and is a folder that is replicated on other domain controllers.

We are going to add the following to the section at the end of the file to set up a sales share that members of the sales group can share:

[sales]
        comment = shared sales directory
        path = /data/staff/sales
        readonly = yes
        public = no
        browseable = yes
        valid users = +SAMBAsales
        write list = jsmith, bsingh
        force create mode = 0770
        force directory mode = 2770
        create mask = 0770
        directory mask = 2770
        force group = sales
        force user = exbackup

We have added a share called [sales]. This share is to be made available to our sales staff only. We have decided to put our staff-shared documents into the /data/staff directory, and the sales directory will be under that. We have specified that it should be read-only by default (readonly = yes). This stops unintended users from writing to this directory. We have also denied public or guest users (public = no). It is browsable (browserable = yes), so it will appear in share browser lists for this Samba server. We have also specified here a valid users list, which is set to the sales group (valid users = +SAMBAsales). The + indicates to Samba to look through the local Unix user/group lists. The people in the sales group will have read-only access to the [sales] share. We then specify exactly who we want to have read/write access, jsmith and bsingh. We could use group lists here as well. If we had a group called sales_admins, we could add write list = @sales_admins.

The last section ensures that files and directories are created with the correct ownership, group, and permissions. We don’t want users owning their own documents throughout the directory tree and then having to get someone to change the permissions or ownership for them later when they want to share those documents with others. We want the owner to always be exbackupso that we will always be able to access the shares with our backup scripts, and we want the shares to have group ownership according to their departmental group. We want files to be readable and writable, and for directories we should give full access to the specified users and groups but no access for the general public.

force create mode = 0770
force directory mode = 2770
create mask = 0770
directory mask = 2770
force group = sales
force user = exbackup

As you saw in Chapter 4, the permissions here are read, write, and execute/access on all files and directories. This might be too liberal for your requirements, but it gives you an idea how to use the permissions. You might want to create files with only 0660 permissions, which is entirely reasonable but might entail some administration overhead.

Samba should automatically load your new configuration without a need to restart the service; however, if you do not see your configuration, you can restart the service with the following:

$ sudo systemctl restart samba-ad-dc

Adding Users to Samba

We now have a basic Samba configuration. You can add your own shares to this configuration as you see fit. There are several things we need to do now to the host to get it ready for users. We are shortly going to create our Samba users and groups via the samba-tool command, and once that is done, we will create our directories and assign permissions.

We have set up Samba in such a way that requires user accounts to be administered on the Samba host. Samba provides a subcommand to samba-tool to administer user accounts on your Samba host. The tool samba-tooluses the following syntax:

$ sudo samba-tool user --help
Usage: samba-tool user <subcommand>

User management.

Options:
  -h, --help  show this help message and exit

Available subcommands:
  add          - Create a new user.
  create       - Create a new user.
  delete       - Delete a user.
  disable      - Disable an user.
  enable       - Enable an user.
  list         - List all users.
  password     - Change password for a user account (the one provided in authentication).
  setexpiry    - Set the expiration of a user account.
  setpassword  - Set or reset the password of a user account.
For more help on a specific subcommand, please type: samba-tool user <subcommand> (-h|--help)

Let’s list the current users we have.

$ sudo samba-tool user list
Administrator
dns-dc1
krbtgt
Guest

You can see that we have four current users that have been created by the Samba provisioning. We are going to add two more users, jsmith and bsingh, who are part of the sales team.

$ sudo samba-tool user create jsmith
New Password:
Retype Password:
User 'jsmith' created successfully

We have added a new user called jsmith. We will do the same for bsingh. The password should be at least 8 characters and complex.

Unfortunately, tbear has just left the firm, and his Samba account needs to be disabled. To do that, we disable tbear’s details like so:

$ sudo samba-tool user disable tbear
Disabled user tbear

If we wanted to remove him completely, we would use samba-tool user delete.

Next we are going to create our sales group, and then we will add jsmith and bsingh to it. We use samba-tool again via the group subcommand. Issuing help shows our options.

$ sudo samba-tool group
Usage: samba-tool group <subcommand>

Group management.

Options:
  -h, --help  show this help message and exit

Available subcommands:
  add            - Creates a new AD group.
  addmembers     - Add members to an AD group.
  delete         - Deletes an AD group.
  list           - List all groups.
  listmembers    - List all members of an AD group.
  removemembers  - Remove members from an AD group.
For more help on a specific subcommand, please type: samba-tool group <subcommand> (-h|--help)

As you can see, it is similar to the user subcommand. First let’s add the sales group.

$ sudo samba-tool group add sales
Added group sales

That is simple, and you should add the group staff too. We can now add our users to the sales group.

$ sudo samba-tool group addmembers sales jsmith,bsingh
Added members to group sales

We can list the members of the sales group now.

$ sudo samba-tool group listmembers sales
jsmith
bsingh

We can delete groups and remove members of groups with the following:

$ sudo samba-tool group removemembers sales tbear
Removed members from group sales

We have removed the user tbear from the sales group; we can also delete the fails group with the following:

$ sudo samba-tool group delete fails
Deleted group fails

Samba will authenticate our users and provide them with access to any shares they have access to. Samba will use Winbind to authenticate and map users and groups for us. We still need to create one Linux system user, though. This user will own the files and therefore needs to exist on each Samba server. This user will be our backup user. We will show you more on how we will use this user in our backup strategies in Chapter 14.

$ sudo useradd –u 903 exbackup

Next, we need to create the directory /data/staff/sales. We will make exbackup the owner of the files and directories in /data/staff. We need to make sure that the appropriate groups can access the shares we have defined, and we will do that shortly.

$ sudo mkdir –p /data/staff/sales
$ sudo chown exbackup –R /data/staff

We have set up the sales group in Samba. We need to query Winbind now to get the GID that has been assigned to the sales group, and then we will change the group ownership on our directories. These users and group don’t exist in the normal Linux /etc/passwd or /etc/group file, so we need to use the GID that Samba will use when accessing files and directories.

$ wbinfo --group-info sales
SAMBAsales:x:3000010:

We can see that wbinfo has queried the group information for the sales group and the GID 3000010 has been assigned to it. We will use this GID to change the group ownership.

$ sudo chgrp 3000010 /data/staff/sales

We also found that the staff GID was 3000012, and we will use that here:

$ sudo chgrp 3000012 /data/staff

Now we have set permissions on those directories. We want to prevent general access to the directories and allow only defined users and groups.

$ sudo chmod 0750 /data && sudo chmod 2750 /data/staff
&& sudo chmod 2770 –R /data/staff/sales

We are now ready to use our Samba service .

Required iptables Rules for Samba

Samba 4 requires the following ports to be open in your firewall:

• UDP protocol on ports 137 and 138 for NetBIOS name services

• TCP protocol on port 139 for NetBIOS sessions

• The Microsoft-dn TCP port 445 for the Samba server

For Ubuntu we just need to add the following commands:

$ sudo ufw allow samba
$ sudo ufw allow bind9

There are many ports that are listening with Samba. It is a good idea to change your ufw default policy to deny to deny access to ports unless explicitly allowed.

$ sudo ufw default deny

This should be done with some caution as it can block other legitimate processes listening on the host.