Introduction

A Samba domain member is a Linux machine joined to a domain that is running Samba and does not provide domain services, such as an NT4 primary domain controller (PDC) or Active Directory (AD) domain controller (DC).

On a Samba domain member, you can:

Use domain users and groups in local ACLs on files and directories.

Set up shares to act as a file server.

Set up printing services to act as a print server.

Configure PAM to enable domain users to log on locally or to authenticate to local installed services.

For details about setting up a Samba NT4 domain or Samba AD, see Domain Control.

Never use samba-tool domain provision to create a Unix domain member, it will not work, you must follow the procedure layed out on this page.

Preparing the Installation

General Preparation

Verify that no Samba processes are running:

# ps ax | egrep "samba|smbd|nmbd|winbindd"

If the output lists any samba, smbd, nmbd, or winbindd processes, shut down the processes.

If you previously run a Samba installation on this host:

Remove the existing smb.conf file. To list the path to the file, enter:

Starting with a clean environment helps you to prevent confusion, and no files from your previous Samba installation are mixed with your new domain member installation.

Preparing a Domain Member to Join an Active Directory Domain

Configuring DNS

Active Directory (AD) uses DNS in the background, to locate other DCs and services, such as Kerberos. Thus AD domain members and servers must be able to resolve the AD DNS zones.

The following describes how to manually configure Linux clients to use DNS servers. If you are running a DHCP server providing DNS settings to your client computers, configure your DHCP server to send the IP addresses of your DNS servers.

Configuring the /etc/resolv.conf

Set the DNS server IP and AD DNS domain in your /etc/resolv.conf. For example:

nameserver 10.99.0.1
search samdom.example.com

Some utilities, such as NetworkManager can overwrite manual changes in that file. See your distribution's documentation for information about how to configure name resolution permanently.

Testing DNS resolution

To verify that your DNS settings are correct and your client or server is able to resolve IP addresses and host names use the nslookup command. The command is available on Linux and Windows.

Configuring Time Synchronisation

Local Host Name Resolution

When you join the host to the domain, Samba tries to register the host name in the AD DNS zone. For this, the net utility must be able to resolve the host name using DNS or using a correct entry in the /etc/hosts file.

To verify that your host name resolves correctly, use the getent hosts command. For example:

# getent hosts M1
10.99.0.5 M1.samdom.example.com M1

The host name and FQDN must not resolve to the 127.0.0.1 IP address or any other IP address other than the one used on the LAN interface of the domain member.

If no output is displayed or the host is resolved to the wrong IP address and you are not using dhcp, set the correct entry in the /etc/hosts file. For example:

127.0.0.1 localhost
10.99.0.5 M1.samdom.example.com M1

If you are using dhcp, check that /etc/hosts only contains the '127.0.0.1' line shown above. If you continue to have problems, contact the sysadmin who controls your DHCP server.

On debian related systems you will also see the line 127.0.1.1 hostname in /etc/hosts, remove it before you install samba.

Please keep the line : 127.0.0.1 localhost

if you need to add aliases to the machine hostname, add them to the end of the line that starts with the machines ipaddress, not the 127.0.0.1 line.

Installing Samba

Configuring Samba

Setting up a Basic smb.conf File

When Setting up smb.conf on a Unix domain member, you will need to make a few decisions.

Do you require users and groups to have the same IDs everywhere, including Samba AD DCs ?

Do you only want your users and groups to have the same IDs on Unix domain members ?

After making your decision, you will have another decision to make, this decision could affect what you think you have already decided.

Do you want or need individual users to have different login shells and/or Unix home directory paths ?

If you need your users to have different login shells and/or Unix home directory paths, or you want them to have the same ID everywhere, you will need to use the winbind 'ad' backend and add RFC2307 attributes to AD.

The RFC2307 attributes are not added automatically when users or groups are created.

The ID numbers found on a DC (numbers in the 3000000 range) are NOT rfc2307 attributes They cannot and will not be used on Unix Domain Members, if you want to have the same ID numbers everywhere, you must add uidNumber & gidNumber attributes to AD and use the winbind 'ad' backend on Unix Domain Members. If you do decide to add uidNumber & gidNumber attributes to AD, you do not need to use numbers in the 3000000 range and in fact it would definitely be a good idea to use a different range.

If your users will only use the Samba AD DC for authentication and will not store data on it or log into it, you can use the the winbind 'rid' backend, this calculates the user and group IDs from the Windows RID, if you use the same [global] section of the smb.conf on every Unix domain member, you will get the same IDs.
If you use the 'rid' backend you do not need to add anything to AD and in fact, any RFC2307 attributes will be ignored.
When using the 'rid' backend you must set the 'template shell' and 'template homedir' parameters in smb.conf, these are global settings and everyone gets the same login shell and Unix home directory path, unlike the RFC2307 attributes where you can set individual Unix home directory paths and shells.

There is another way of setting up Samba, this is where you require your users and groups to have the same ID everywhere, but only need your users to have the same login shell and use the same Unix home directory path. You can do this by using the winbind 'ad' backend and using the template lines in smb.conf. This way you only have to add uidNumber & gidNumbers attributes to AD.

Having decided which winbind backend to use, you now have a further decision to make, the ranges to use with 'idmap config' in smb.conf.
By default on a Unix domain member, there are multiple blocks of users & groups:

The local system users & groups: These will be from 0-999

The local Unix users and groups: These start at 1000

The 'well Known SIDs': ????

The DOMAIN users and groups: ADUC, by default, starts these at 10000

Trusted domains: ????

Anything that isn't a 'well Known SID' or a member of DOMAIN or a trusted domain: ????

As you can see from the above, you shouldn't set either the '*' or 'DOMAIN' ranges to start at 999 or less, as they would interfere with the local system users & groups. You also should leave a space for any local Unix users & groups, so starting the 'idmap config' ranges at 3000 seems to be a good compromise.

You need to decide how large your 'DOMAIN' is likely to grow to and you also need to know if you have any trusted domains or if you may need to have any in future.

Bearing the above information in mind, you could set the 'idmap config' ranges to the following:

Domain

Range

*

3000-7999

DOMAIN

10000-999999

You could also have any trusted domains starting at:

Domain

Range

TRUSTED

1000000-9999999

If you set the '*' range above the 'DOMAIN' range, the ranges will conflict if the 'Domain' grows to the point that the next ID would be the same as the '*' range start ID.

With the above suggested ranges, no range will overlap or interfere with another.

You may also have seen examples of the '*' range being used for everything, this is not recommended and should not be used.

Before joining the domain, configure the domain member's smb.conf file:

To locate the file, enter:

# smbd -b | grep CONFIGFILE
CONFIGFILE: /usr/local/samba/etc/smb.conf

Choose backend for id mapping in winbindd

After reading this wikipage, click on one of the following hyperlinks to find information about the relevant Samba domain back end:

Add an additional ID mapping configuration for every domain. The ID ranges of the default (*) domain and other domains configured in the smb.conf file must not overlap.

Mapping the Domain Administrator Account to the Local root User

Samba enables you to map domain accounts to a local account. Use this feature to execute file operations on the domain member's file system as a different user than the account that requested the operation on the client.

Mapping the domain administrator to the local root account is optional. Only configure the mapping if the domain administrator must be able to execute file operations on the domain member using root permissions. You should be aware that mapping Administrator to the root account will not allow you to log onto Unix domain members as Administrator.

To map the domain administrator to the local root account:

Add the following parameter to the [global] section of your smb.conf file:

username map = /usr/local/samba/etc/user.map

Create the /usr/local/samba/etc/user.map file with the following content:

!root = SAMDOM\Administrator

When using the ad ID mapping back end, do not set the uidNumber attribute for the domain administrator account. If the account has the attribute set, the value overrides the local UID 0 of the root user and thus the mapping fails.

For further details, see username map parameter in the smb.conf(5) man page.

Do not provision or join a domain member using the samba-tool utility. These options are unsupported and can cause problems with your AD replication. The options will be removed from samba-tool in a future release.

Configuring the Name Service Switch

To enable the name service switch (NSS) library to make domain users and groups available to the local system:

Append the winbind entry to the following databases in the /etc/nsswitch.conf file:

passwd: files winbind
group: files winbind

Keep the files entry as first source for both databases. This enables NSS to look up domain users and groups from the /etc/passwd and /etc/group files before querying the Winbind service.

Do not add the winbind entry to the NSS shadow database. This can cause the wbinfo utility fail.

Do not use the same user names in the local /etc/passwd file as in the domain.

If you compiled Samba, add symbolic links from the libnss_winbind library to the operating system's library path. For details, see libnss_winbind Links. If you used packages to install Samba, the link is usually created automatically.

Starting the Services

Start the following services to have a fully functioning Unix domain member:

The smbd service

The nmbd service

The winbindd service

If you do not require Network Browsing, you do not need to start the nmbd service on a Unix domain member.

You must not start the samba service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).

Samba does not provide System V init scripts, systemd, upstart, or service files for other init services.

If you installed Samba using packages, use the script or service configuration file provided by the package to start Samba.

If you built Samba, see your distribution's documentation for how to create a script or configuration to start services.

Testing the Winbindd Connectivity

Sending a Winbindd Ping

To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter:

Assigning File Permissions to Domain Users and Groups

The name service switch (NSS) library enables you to use domain user accounts and groups in commands. For example to set the owner of a file to the demo01 domain user and the group to the Domain Users domain group, enter: