Setting up Samba as a Domain Member
In the context of Samba, you usually hear only about servers (AD DCs, NT4 PDCs, file servers, etc.). You mostly not hear very much about a Samba workstation as a Domain Member, like in the Windows world about hosts running 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 workstation is a Samba server that provides neither file shares nor print services. The other way around - and 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.
See the server information used in documentation page for paths used, hostnames, etc.
You have the following options to install Samba:
- Build Samba yourself
- Install distribution specific packages
Preparing the host for the domain join
AD DNS zone resolution
Many things in an Active Directory, like Kerberos, rely on DNS. Therefore it is required that the host is able to resolve AD DNS zones. If you're having 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:
nameserver 10.99.0.1 nameserver 10.99.0.2 search samdom.example.com
Some tools like 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 10.99.0.1
In an Active Directory, an accurate time synchronization is necessary for Kerberos to prevent replay attacks and for resolving directory replication conflicts. For that reasons, your host won't be able to access AD servers or be accessed by others if providing shares, if the time differs to your AD. 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 via DNS or /etc/hosts. To verify, run
# getent hosts M1 10.99.0.5 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're getting a different output, fix it in your DNS or by adding/changing the /etc/hosts entry:
10.99.0.5 M1.samdom.example.com M1
Setup a Domain Member smb.conf file
Before joining a domain, it's necessary to create Sambas configuration file "smb.conf". The following command shows, where the file is located in your installation:
# smbd -b | grep CONFIGFILE CONFIGFILE: /usr/local/samba/etc/smb.conf
In the following you see an smb.conf example, that is sufficient to join a domain, if you add an "idmap config" part, fitting to your environment:
[global] netbios name = M1 security = ADS workgroup = SAMDOM realm = SAMDOM.EXAMPLE.COM log file = /var/log/samba/%m.log log level = 1 dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab winbind refresh tickets = yes winbind trusted domains only = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes # Default idmap config used for BUILTIN and local accounts/groups idmap config *:backend = tdb idmap config *:range = 2000-9999 # idmap config used for your domain. # Choose one of the following backends fitting to your # requirements and add the corresponding configuration. # - idmap config ad # - idmap config rid # - idmap config autorid
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 via "samba-tool"! This process isn't implented yet.
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 error messages during Domain Member join.
Domain 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 via Winbindd.
Important: If you have compiled Samba, you may need to add two symbolic links. See libnss_winbind links for OS specific information, where to place them. Samba package installations usually place the file directly in the OSs library path or have the links included.
Depending on how you use your Domain Member, you have to start different daemons:
For a pure Domain Member (domain logons only):
# smbd # nmbd # winbindd
If you installed Samba via packages, you usually have init scripts or systemd/upstart support included. If you have compiled Samba, you need to do write your own scripts. See the init script page for examples. For automatic startup of the service(s) at boot time, please consult you distributions documentation.
Testing Winbindd user/group retrieval
The first check is, if Winbindd in general is able, to retrieve domain users and groups. On a successful setup, the commands will print all users/groups in your domain:
# wbinfo -u administrator krbtgt guest ...
# wbinfo -g enterprise admins domain computers domain admins ...
Using domain accounts/groups in OS commands
# getent passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin ... administrator:*:10000:10000:Administrator:/home/Administrator:/bin/bash demo01:*:10001:10000:demo01:/home/demo01:/bin/bash ...
# getent group root:x:0: bin:x:1: daemon:x:2: ... domain admins:x:10001: domain users:x:10000: ...
Note: If you're not getting domain accounts/groups in that output, verify that
- libnss_winbind configuration is correct - expecially if "ldconfig" is able to find "libnss_winbind.so.2" and "libnss_winbind.so"
- if using idmap config ad, accounts/groups have RFC2307 attributes set
- "winbind enum users" and "winbind enum groups" are set to "yes" in your smb.conf
If you're seeing domain accounts/groups, you can use them in OS, like
# id administrator uid=10000(administrator) gid=10000(domain users) Gruppen=10000(domain users),10001(domain admins),2001(BUILTIN\users),2000(BUILTIN\administrators)
# chown administrator:"domain users" file.txt # ls -s file.txt -rw-------. 1 administrator domain users 992 18. Oct 2015 file.txt
Authenticating Domain users via PAM
If you had setup this Domain Member as a server providing file shares or print services, you may want to skip this part, to prevent domain users logging on local to the hosts console.
Important note: Before you start changing your PAM configuration:
- make sure you know what you're doing!
- login within a second terminal, before you start and keep it open until everything works like 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.
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:
#%PAM-1.0 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 used settings in the above example, 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 ~]$ _