Setup a Samba AD Member Server
This documentation provides a basic setup for a Samba Member Server that is part of an Active Directory.
This documentation uses the following configuration/settings:
Member Server: Installation Directory: /usr/local/samba/ Member Server Hostname: Member1 IP Address: 192.168.1.2 AD backend: DNS Server: 192.168.1.1 DNS Domain Name: samdom.example.com Realm: SAMDOM.EXAMPLE.COM NT4 Domain Name (NETBIOS): SAMDOM
This documentation is frequently updated to reflect the latest changes. Please see the Samba Release Planning for more specifics.
Please review the release notes for the version you have installed. It may contain important information, not yet reflected in this documentation.
Name resolution (DNS)
Configure your Member Servers /etc/resolv.conf to use the DNS server(s) and search domain of your AD:
nameserver 192.168.1.1 search samdom.example.com
Your DNS server(s) must be able to resolve the AD DNS zone, because services, such as Kerberos, use it to locate other services in your network.
Note that on many distributions such as Ubuntu and Fedora, /etc/resolv.conf may be automatically regenerated, so you may need to make changes instead in /etc/network/interfaces or similar locations
A correct time is imperative in an AD. For further information and configuring ntpd, see Time Synchronisation.
Different ways to install
Always check the OS Requirements for dependencies and recommendations.
You have a few options to install Samba:
- Build Samba yourself. For a Member in an Active Directory, add the following parameters to your 'configure' command:
# ./configure --with-ads --with-shared-modules=idmap_ad ...
- Install binary distribution packages. Make sure, that you use a recent Samba installation with Active Directory Domain Controller capabilities!
- Install from SerNet Enterprise Samba package.
Take care when running Samba commands, you may also have a previous version of Samba installed! To avoid inadvertently running the wrong version of a program, you should consider putting the „/usr/local/samba/bin/“ and „/usr/local/samba/sbin/“ directories at the beginning of your $PATH variable.
You can see what version of Samba and client tools, if any, is in your „$PATH“ variable by running:
# samba -V # smbclient -V
A note on provisioning
A member server must not be provisioned with samba-tool! The Member Server provisioning option isn't working yet. Set up the server through the traditional way as described below.
Set up a basic smb.conf
Usually this file is located in /usr/local/samba/etc/. Depending on your 'configure' parameters, or if you are using a distro/Sernet package, it could be in a different location:
[global] netbios name = Member1 workgroup = SAMDOM security = ADS realm = SAMDOM.EXAMPLE.COM encrypt passwords = yes idmap config *:backend = tdb idmap config *:range = 70001-80000 idmap config SAMDOM:backend = ad idmap config SAMDOM:schema_mode = rfc2307 idmap config SAMDOM:range = 500-40000 winbind nss info = rfc2307 winbind trusted domains only = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes [demoshare] path = /srv/samba/test read only = no
This very basic example will allow your Member Server to join your Active Directory.
In the example configuration, ID mapping for domain users/groups is done via RFC2307 attributes stored in AD. This means that all account/group information (uidNumber/gidNumber, loginShell, unixHomeDirectory, etc.) is retrieved from AD. This means that you must add these attributes to your AD accounts/groups (see i.e. "Unix attributes" tab in ADUC). If you use different UID/GID ranges in your AD than those shown in the example above, you will have to change the ranges in your smb.conf. For further information about RFC2307, see the Using RFC2307 on a Samba DC HowTo.
The above configuration will cause the mappings for non-domain accounts (i.e. the local Administrator, etc.) to be stored in a TDB file and the IDs are taken from the range given. The local range must not overlap with the one specified for your domain!
For further explanation on the smb.conf parameters and idmap parameters, check out the manpages.
Joining a Member Server to the domain
# net [rpc|ads] join -U administrator
You can use both 'net' parameters (rpc and ads) to join.
Make domain users/groups available locally through Winbind
If you have compiled Samba yourself, to have your domain users and groups available locally on your Member Server, you need to place two links in your /lib64 folder:
# ln -s /usr/local/samba/lib/libnss_winbind.so /lib64 # ln -s /lib64/libnss_winbind.so /lib64/libnss_winbind.so.2 # ldconfig
If you are running a 32-bit system ("uname -i" will return "i686"), you have to use /lib instead!
If you are using a distro/Sernet package, you should not have to do the above, you just need to install the correct package. See the documentation available from the source of your packages.
The final step of the configuration is to add 'winbind' to the 'passwd' and 'group' entry of your /etc/nsswitch.conf:
passwd: compat winbind group: compat winbind
Starting the daemons
If you have finished the above steps, you can start the daemons:
If you compiled samba yourself, you should write/get a start script to avoid having to manually start the services.
Testing the Winbind user/group mapping
To check if Winbind receives user and groups from the domain, run the following commands:
# wbinfo -u # wbinfo -g
This should show up a list of all users and groups, provided from the domain via Winbind.
If you had setup your /etc/nsswitch.conf correct, you should be able to use typical permission tools with domain users/groups
# id DomainUser # getent passwd # getent group # chown DomainUser:DomainGroup file # chgrp DomainGroup file etc.
Setting up additional services
Setting up PAM authentication
Important: Before you start doing changes in your PAM configuration
- make sure you know what you are doing!
- login within a second terminal and leave it open, until everything works as expected!
Otherwise you may lock yourself out and won't be able to login again!
- Place a link to pam_winbind.so in /lib64/security (64-bit platforms) or /lib/security (32-bit platforms).
# ln -s /usr/local/samba/lib/security/pam_winbind.so /lib64/security/
- Configure PAM to use Winbind:
- Whenever your distribution provides tools for configuring PAM, it's suggested to use them. i.e. RHEL6 is shipped with authconfig/authconfig-tui, Debian ships pam-auth-update.
- For manually changes: Typically the configuration files are located in /etc/pam.d/. Depending on your distribution, the filename(s) may differ. E. g. for RHEL6, you set up pam_winbind 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 >= 500 quiet 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 < 500 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
Testing login via pam_winbind
Assuming you have configured PAM for sshd to authenticate via Winbind, you can try logging in
[demo1@DC1 ~]$ ssh Member1 demo1@Member1's password: Last login: Sun May 4 11:40:00 2014 from DC1.samdom.example.com [demo1@Member1 ~]$