Difference between revisions of "Setting up Samba as a Domain Member"

From SambaWiki
m (/* reset * range)
m (/* re-added note about not using this info on a DC, Note to Marc: If you take it out again, I will just put it back!)
Line 5: Line 5:
Generally speaking, a Samba server is just a Samba workstation that provides file shares or print services. This is how we will structure our documentation here - being a Domain Member is the prerequisite for configuring a Samba [[Samba_File_Serving|file]] and/or [[Setup_a_Samba_print_server|print]] server.
Generally speaking, a Samba server is just a Samba workstation that provides file shares or print services. This is how we will structure our documentation here - being a Domain Member is the prerequisite for configuring a Samba [[Samba_File_Serving|file]] and/or [[Setup_a_Samba_print_server|print]] server.
| type = important
| text = None of the smb.conf <code>idmap_ad</code> information to be found here will have any affect on a Samba AD DC, none of it should be added to the smb.conf found on a DC.

Revision as of 20:06, 9 December 2016


In the context of Samba, you usually only hear about servers (AD DCs, NT4 PDCs, file servers, etc.). You usually do not hear much about a Samba workstation as a Domain Member, similar to hosts running a version of Windows e. g. Windows 10 Pro or some other workstation edition. What if you want to join a Linux workstation to the domain, to authenticate user logins against your Domain Controller(s)?

Generally speaking, a Samba server is just a Samba workstation that provides file shares or print services. This is how we will structure our documentation here - being a Domain Member is the prerequisite for configuring a Samba file and/or print server.


You have the following options to install Samba:

Preparing the host for the domain join

AD DNS zone resolution

Many things in an Active Directory, such as Kerberos, rely on DNS. Therefore it is required that the host is able to resolve AD DNS zones. If you have multiple DCs acting as a DNS server, it's recommended to setup multiple nameserver entries for fail over reasons.

On Linux and Unixes, you usually configure DNS settings in /etc/resolv.conf:

search samdom.example.com

Some tools, such as NetworkManager, may overwrite manual changes in that file. Please consult your distributions documentation for configuring name resolution.

To verify a correct name resolution, try resolving the hostname of one of your Domain Controllers:

# host -t A DC1.samdom.example.com
DC1.samdom.example.com has address


In an Active Directory, accurate time synchronization is necessary for Kerberos, to prevent replay attacks and for resolving directory replication conflicts. For those reasons, if the time differs to your AD, your host won't be able to access AD servers and any shares it provides won't be accessible by others. See Time Syncronisation for further information and configuration examples.

Local hostname resolution

During the Domain join, Samba tries to register/update the hosts name and IP in your AD DNS. This requires that "net" can resolve both, either using DNS or /etc/hosts. To verify, run

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

The commands output must show the correct LAN interface IP (not 127.*.*.*!) and the hostname including the AD DNS zone. Additional alias names are optional. If you get a different output, fix it in your DNS or by adding/changing the /etc/hosts entry:      M1.samdom.example.com    M1

Setup a Domain Member smb.conf file

Before joining a domain, it is necessary to create the Samba configuration file "smb.conf". The following command shows, where the file is located in your installation:

Note: You should use the same "smb.conf" file on all domain members you set up in the domain.

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

In the following you see an smb.conf example sufficient to join a domain, if you add an "idmap config" part, fitting to your environment.

       security = ADS
       workgroup = SAMDOM
       realm = SAMDOM.EXAMPLE.COM

       log file = /var/log/samba/%m.log
       log level = 1

       # idmap config used for your domain.
       # Click on the following links for more information
       # on the available winbind idmap backends, 
       # Choose the one that fits your requirements
       # then add the corresponding configuration.
       idmap config * : backend = tdb
       idmap config * : range = 2000-9999
       # Just adding one of the following three lines is not enough!!
       # Please follow the links.
       #  - use the winbind 'ad' backend.
       #                  Or
       #  - use the winbind 'rid' backend.
       #                  Or
       #  - use the winbind 'autorid' backend.

See the manpage of "smb.conf" for detailed information about the parameters and options used.

The domain join

A note on provisioning: A Domain Member must not be provisioned by using "samba-tool"! This would setup an AD DC on your Domain Member with some parts turned off and writes to sam.ldb instead of passdb.tdb. Don't use this way to join, to avoid unwanted side effects! The Domain Member provisioning option will be removed in the future.

The following command will join the host to the domain and automatically register/update its DNS record:

# net ads join -U administrator
Enter administrator's password: Passw0rd
Using short domain name -- SAMDOM
Joined 'M1' to dns domain 'samdom.example.com'

If you encounter any error message(s), see Troubleshooting Samba Domain Members.


Domain users and groups are made available to your local system through libnss_winbind. The smb.conf configuration was already done in a previous step. Next is to tell your system to retrieve that information from winbindd by adding "winbind" to the following two lines of your /etc/nsswitch.conf:

passwd: files winbind
group:  files winbind

Keep the existing database "files" (sometimes you may find "compat" instead of "files"). It defines that accounts and groups are first looked up in local files (/etc/passwd and /etc/group), then using Winbindd.

Note: Do not add 'winbind' to the 'shadow' line, this has been reported to cause problems with 'wbinfo', it is also totally unneeded.

Note: you cannot have users & groups with the same name in the local files and the domain i.e. a user 'foo' that appears in /etc/passwd would be the same user as 'DOMAIN\foo', in this instance you would need to remove or rename one of the users.

Important: If you have compiled Samba, you may need to add two symbolic links. See libnss_winbind Links for OS specific information on where to place them. Samba package installations usually place the file directly in the OS library path or have the links included.

Start daemons

Depending on how you use your Domain Member, you have to start different daemons:

For a pure Domain Member (domain logons only):

# winbindd

For Domain Members sharing directories (file server) and/or printers (print server):

# smbd
# nmbd
# winbindd

Note: You do not start the 'samba' daemon on a domain member.

If you installed Samba using packages, you usually have init scripts or systemd/upstart support included. If you have compiled Samba, you will need to write your own scripts. For automatic startup of the service(s) at boot time, please consult you distributions documentation.

Testing Winbindd domain controller connectivity


You first need to check if winbind is able to connect to a domain controller with wbinfo --ping-dc:

# wbinfo --ping-dc
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded

Using domain accounts/groups in OS commands

If you have included libnss_winbind in your system and setup smb.conf correctly, the following commands should print the relevant information for the supplied user or group:

# getent passwd demo01
# getent group Domain\ Users
domain users:x:10000:

Note: If you do not get any output, verify that

Note: if you want to display all users & groups with 'getent', add these lines to your smb.conf (This is only recommended for testing):

winbind enum users = yes
winbind enum groups = yes

Any domain accounts/groups shown by getent or id can be used in the OS, i.e.

# id demo01
uid=10000(demo01) gid=10000(domain users) groups=10000(domain users),2001(BUILTIN\users)
# chown demo01:"domain users" file.txt
# ls -s file.txt
-rw-------. 1 demo01 domain users 992  18. Oct 2015  file.txt

Note: For various reasons, Administrator needs to be mapped to the Unix user 'root', this is done automatically on a Samba AD DC. On a domain member you will need to add a line to 'smb.conf':

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

You will then need to create /usr/local/samba/etc/user.map:

!root = SAMDOM\Administrator SAMDOM\administrator Administrator administrator

Do not give Administrator a uidNumber attribute, this will turn Administrator into a normal Unix user, without the required permissions & rights it needs.

Authenticating Domain Users Using PAM

If you have setup this Domain Member as a server providing file shares or print services, you may want to skip this part, By following this part, you will allow domain users to logon locally to the hosts console.

General information

Important note: Before you start changing your PAM configuration:

  • make sure you know what you're doing!
  • before you start, login within a second terminal and keep it open until everything works as expected. Otherwise, you may lockout yourself and won't be able to login again!

If you have compiled Samba, you need to add a symbolic links. See pam_winbind Link for OS specific information, where to place it. Samba package installations usually place the file directly in the right folder or have a link included.

Configure PAM

Note: Whenever your distribution ship tools to configure PAM, it's recommended to use them, instead of manually editing the configuration files!

  • Red Hat based OS: authconfig/authconfig-tui
  • Debian based OS: pam-auth-update
  • SUSE based OS: yast

For manual changes: Typically the PAM configuration files are located in /etc/pam.d/ Depending on your distribution, the filename(s) may differ. E. g. on RHEL, you configure system login authentication in /etc/pam.d/password-auth-ac:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_winbind.so use_first_pass                    # <-- add this line
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so    # <-- add this line
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok                       # <-- add this line
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

For additional information about PAM configuration and settings used in the example above, please consult the PAM documentation and the manpages of pam.conf and pam_winbind.

Verify domain user login

Try to login on the local console with a domain user account:

CentOS Linux 7 (Core)
Kernel 3.10.0-229.11.1.el.7.x86_64 on an x86_64

M1 login: demo01
Password: Passw0rd

[demo01@M1 ~]$ _

Setting up additional services

Now you have successfully made your host be a Domain Member, you can, as on a Windows OS, additionally share directories (file server) or act as an print server.