Setting up Samba as a Domain Member
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.
|For versions of Samba earlier than 4.15.0, never use |
|All AD Domain members must be in the same |
Preparing the Installation
- Verify that no Samba processes are running:
# ps ax | egrep "samba|smbd|nmbd|winbindd"
- If the output lists any
winbinddprocesses, shut down the processes.
- If you previously run a Samba installation on this host:
- Backup the existing
smb.conffile. To list the path to the file, enter:
- Backup the existing
# smbd -b | grep "CONFIGFILE" CONFIGFILE: /usr/local/samba/etc/samba/smb.conf
- Remove all Samba database files, such as
*.ldbfiles. To list the folders containing Samba databases:
- Remove all Samba database files, such as
# smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR" LOCKDIR: /usr/local/samba/var/lock/ STATEDIR: /usr/local/samba/var/locks/ CACHEDIR: /usr/local/samba/var/cache/ PRIVATE_DIR: /usr/local/samba/private/
- 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
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.
To resolve a host name its IP address:
# nslookup DC1.samdom.example.com Server: 10.99.0.1 Address: 10.99.0.1#53 Name: DC1.samdom.example.com Address: 10.99.0.1
To resolve a IP address to its host name:
# nslookup 10.99.0.1 Server: 10.99.0.1 Address: 10.99.0.1#53 18.104.22.168.in-addr.arpa name = DC1.samdom.example.com.
Note that in a Samba AD, the reverse zone is not automatically configured. To set up a reverse zone, see DNS Administration.
Resolving SRV Records
Active Directory (AD) uses SRV records to locate services, such as Kerberos and LDAP. To verify that SRV records are resolved correctly, use the
nslookup interactive shell:
$ nslookup > set type=SRV > _ldap._tcp.samdom.example.com Server: 192.168.0.4 Address: 192.168.0.4#53 _ldap._tcp.samdom.example.com service = 0 100 389 dc2.samdom.example.com. _ldap._tcp.samdom.example.com service = 0 100 389 dc1.samdom.example.com. > exit
Alternatively, you can use the host command.
$ host -t SRV _ldap._tcp.samdom.example.com _ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com. _ldap._tcp.samdom.example.com has SRV record 0 100 389 dc2.samdom.example.com.
- The DNS server is not able to resolve the host name:
** server can't find DC1.samdom.example.com: NXDOMAIN
- The DNS server is not able to resolve the IP address:
** server can't find 22.214.171.124.in-addr.arpa: NXDOMAIN
- The DNS server used is not available:
;; connection timed out; no servers could be reached
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your
[libdefaults] default_realm = SAMDOM.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true
The previous example configures Kerberos for the
The Samba teams recommends to no set any further parameters in the
/etc/krb5.conf contains an
include line it will not work, you Must remove this line.
Configuring Time Synchronisation
Kerberos requires a synchronised time on all domain members. Thus it is recommended to set up an NTP client. For further details, see Configuring Time Synchronisation on a Unix Domain Member.
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
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 hostnamein /etc/hosts, remove it before you install samba.
- Please keep the line :
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.
Preparing a Domain Member to Join an NT4 Domain
For joining a host to an NT4 domain, no preparation is required.
For details, see Installing Samba.
|Install a maintained Samba version. For details, see Samba Release Planning.|
Setting up a Basic
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 (|
|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.|
It is recommended that your users will only use the Samba AD DC for authentication and will not store data on it or log into it. It is further recommended that you set up Unix domain members, using one of the the winbind backends, and use these as fileservers, printservers, etc. If you use the 'rid' or 'autorid' winbind backend, these will calculate 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' or 'autorid' backend you do not need to add anything to AD and in fact, any RFC2307 attributes will be ignored. When using these backends 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.
If you require your users and groups to have the same ID everywhere and have different login shell's and Unix home directory path's, you can do this by using the winbind 'ad' backend. If you only require the same ID everywhere with the same login shell and Unix home directory, you will need to add the template lines to smb.conf. If you do use the 'ad' backend, you need to add the relevant RFC2307 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:
You could also have any trusted domains starting at:
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
- To locate the file, enter:
# smbd -b | grep CONFIGFILE CONFIGFILE: /usr/local/samba/etc/smb.conf
To create a basic smb.conf, you need something like this (note, this does not include any 'idmap config' auth lines, they will be added later. It also does not show any shares)
[global] workgroup = SAMDOM security = ADS realm = SAMDOM.EXAMPLE.COM winbind refresh tickets = Yes vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes
If you are creating a new smb.conf on an unjoined machine and add these lines, a keytab will be created during the join:
dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab
If you do not want to enter the domain set in '
workgroup =' during login etc (just 'username' instead of DOMAIN\username) and have only one domain, add this line:
winbind use default domain = yes
|This will only work for the default domain, if you have more than one domain, do not set the line. For multiple domains, you must use 'DOMAIN\username'.|
For testing purposes only (remove for production), add these lines:
winbind enum users = yes winbind enum groups = yes
|The above lines just make 'getent passwd' and 'getent group' display all domain users and groups, they are not required for anything else and Samba will work correctly and faster without them.|
To disable printing completely, add these lines:
load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes
You now need to add the 'idmap config' lines for your preferred winbind method.
Choose backend for id mapping in winbindd
Select one of the following hyperlinks to find information about the relevant Samba domain back end and what
idmap config lines to add:
Back End Documentation Man Page
idmap config ad
idmap config rid
idmap config autorid
Add an additional ID mapping configuration for every domain. The ID ranges of the default (
*) domain and other domains configured in the
smb.conffile must not overlap.
Mapping the Domain Administrator Account to the Local
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.
|You should map the domain Administrator account to the local |
|If you have changed the domain Administrator account name, use the new admin name in the following instead of |
To map the domain administrator to the local
- Add the following parameter to the
[global]section of your
username map = /usr/local/samba/etc/user.map
- Create the
/usr/local/samba/etc/user.mapfile with the following content:
!root = SAMDOM\Administrator
When using the
adID mapping back end, never set a
uidNumberattribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID
rootuser on Samba AD DC's and thus the mapping fails.
For further details, see
username map parameter in the
smb.conf(5) man page.
Joining the Domain
- To join the host to an Active Directory (AD), enter:
# net ads join -U administrator Enter administrator's password: Passw0rd Using short domain name -- SAMDOM Joined 'M1' to dns domain 'samdom.example.com'
|When you join a computer to an AD domain with |
- To join the host to an NT4 domain, enter:
# net rpc join -U administrator Enter administrator's password: Passw0rd Joined domain SAMDOM.
Joining the Domain with samba-tool (>4.15.0 only)
|Do not join a domain member using |
- To join the host to an Active Directory (AD), enter:
# samba-tool domain join samdom.example.com MEMBER -U administrator
If you have problems joining the domain, check your configuration. For further help, see Troubleshooting Samba Domain Members.
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
winbindentry to the following databases in the
passwd: files winbind group: files winbind
- Keep the
filesentry as first source for both databases. This enables NSS to look up domain users and groups from the
/etc/groupfiles before querying the Winbind service.
- Keep the
- Do not add the
winbindentry to the NSS
shadowdatabase. This can cause the
- Do not add the
If there's a line containing an
[success=continue] winbind, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the
initgroupsline if it does not exist.
Do not use the same user names in the local
/etc/passwdfile as in the domain.
If you compiled Samba, add symbolic links from the
libnss_winbindlibrary 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:
If you do not require Network Browsing, you do not need to start the
nmbdservice on a Unix domain member.
The latest versions of Samba (from 4.11.0) now only use SMBv2 as the minimum client & server protocols. This means that anything that relies on SMBv1 will not work, unless you manually set
client min protocol = NT1and
server min protocol = NT1in
smb.conf. Samba no longer recommends using SMBv1.
You must not start the
sambaservice on a domain member. This service is required only on Active Directory (AD) domain controllers (DC).
Samba does not provide System V init scripts,
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:
# wbinfo --ping-dc checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded
If the previous command fails, verify:
- That the
winbinddservice is running.
smb.conffile is set up correctly.
Using Domain Accounts and Groups in Operating System Commands
Looking up Domain Users and Groups
libnss_winbind library enables you to look up domain users and groups. For example:
- To look up the domain user
# getent passwd SAMDOM\\demo01 SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash
- To look up the domain group
# getent group "SAMDOM\\Domain Users" SAMDOM\domain users:x:10000:
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:
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt
Setting up Additional Services on the Domain Member
On a Samba domain member, you can additionally set up:
- File shares to act as a file server. For details, see Samba File Serving.
- Print services to act as a print server. For details, see Print Server Support.
- PAM authentication of domain users for local services. For details, see Authenticating Domain Users Using PAM.
For details, see Troubleshooting Samba Domain Members.