Setting up Samba as a Domain Member: Difference between revisions
Mmuehlfeld (talk | contribs) m (Fixed wording, updated link) |
m (/* typo) |
||
(62 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
= Introduction = |
= 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). |
|||
In the context of Samba, you usually only hear about servers ([[Active_Directory_Domain_Controller|AD DCs]], [[NT4_Domains|NT4 PDCs]], [[File_sharing|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)? |
|||
On a Samba domain member, you can: |
|||
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_sharing|file]] and/or [[Setup_a_Samba_print_server|print]] server. |
|||
* Use domain users and groups in local ACLs on files and directories. |
|||
'''See the [[Host_information_used_in_documentation|host information used in documentation]] page for used paths, hostnames, etc.''' |
|||
* 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|Domain Control]]. |
|||
{{Imbox |
|||
| type = important |
|||
| text = Never use <code>samba-tool domain provision</code> to create a Unix domain member, it will not work, you must follow the procedure laid out on this page. |
|||
}} |
|||
{{Imbox |
|||
| type = important |
|||
| text = All AD Domain members must be in the same <code>DNS</code> domain and the Realm must be the <code>DNS</code> domain in uppercase. |
|||
}} |
|||
= Installation = |
|||
You have the following options to install Samba: |
|||
= Preparing the Installation = |
|||
* [[Build_Samba_from_Source|Build Samba]] yourself |
|||
== General Preparation == |
|||
* Install [[Distribution-specific_Package_Installation|distribution specific packages]] |
|||
* Verify that no Samba processes are running: |
|||
* Install SerNet [http://www.samba.plus Samba+]/[http://www.samba.plus/older-packages/ Enterprise] packages |
|||
# ps ax | egrep "samba|smbd|nmbd|winbindd" |
|||
: If the output lists any <code>samba</code>, <code>smbd</code>, <code>nmbd</code>, or <code>winbindd</code> processes, shut down the processes. |
|||
* If you previously run a Samba installation on this host: |
|||
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter: |
|||
# smbd -b | grep "CONFIGFILE" |
|||
CONFIGFILE: /usr/local/samba/etc/samba/smb.conf |
|||
:* Remove all Samba database files, such as <code>*.tdb</code> and <code>*.ldb</code> files. To list the folders containing Samba databases: |
|||
# 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 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. |
|||
== Preparing a Domain Member to Join an Active Directory Domain == |
|||
On Linux and Unixes, you usually configure DNS settings in /etc/resolv.conf: |
|||
=== Configuring DNS === |
|||
nameserver 10.99.0.1 |
|||
nameserver 10.99.0.2 |
|||
search samdom.example.com |
|||
{{:Linux and Unix DNS Configuration}} |
|||
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 10.99.0.1 |
|||
== |
=== Configuring Kerberos === |
||
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your <code>/etc/krb5.conf</code> file: |
|||
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_Synchronisation|Time Syncronisation]] for further information and [[Time_Synchronisation#Configuring_time_synchronisation_on_a_Samba_Domain_Members|configuration examples]]. |
|||
[libdefaults] |
|||
default_realm = SAMDOM.EXAMPLE.COM |
|||
dns_lookup_realm = false |
|||
dns_lookup_kdc = true |
|||
The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm. |
|||
The Samba teams recommends to no set any further parameters in the <code>/etc/krb5.conf</code> file. |
|||
== Local hostname resolution == |
|||
If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line. |
|||
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 |
|||
=== 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 [[Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Unix_Domain_Member|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 <code>net</code> utility must be able to resolve the host name using DNS or using a correct entry in the <code>/etc/hosts</code> file. |
|||
To verify that your host name resolves correctly, use the <code>getent hosts</code> command. For example: |
|||
# getent hosts M1 |
# getent hosts M1 |
||
10.99.0.5 M1.samdom.example.com M1 |
10.99.0.5 M1.samdom.example.com M1 |
||
The host name and FQDN must not resolve to the <code>127.0.0.1</code> IP address or any other IP address other than the one used on the LAN interface of the domain member. |
|||
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: |
|||
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 <code>/etc/hosts</code> file. For example: |
|||
127.0.0.1 localhost |
|||
10.99.0.5 M1.samdom.example.com M1 |
10.99.0.5 M1.samdom.example.com M1 |
||
If you are using dhcp, check that <code>/etc/hosts</code> 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 <code>127.0.1.1 hostname</code> in /etc/hosts, remove it before you install samba. |
|||
* Please keep the line : <code>127.0.0.1 localhost</code> |
|||
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. |
|||
= Setup a Domain Member smb.conf file = |
|||
== Preparing a Domain Member to Join an NT4 Domain == |
|||
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: |
|||
For joining a host to an NT4 domain, no preparation is required. |
|||
'''Note:''' You should use the same "smb.conf" file on all domain members you set up in the domain. |
|||
= Installing Samba = |
|||
For details, see [[Installing_Samba|Installing Samba]]. |
|||
{{Imbox |
|||
| type = note |
|||
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]]. |
|||
}} |
|||
= Configuring Samba = |
|||
== Setting up a Basic <code>smb.conf</code> 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. |
|||
{{Imbox |
|||
| type = note |
|||
| text = The RFC2307 attributes (<code>uidNumber</code>, <code>gidNumber</code>, etc) are not added automatically when users or groups are created, you must add them manually. |
|||
}} |
|||
{{Imbox |
|||
| type = important |
|||
| text = 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: |
|||
:{| class="wikitable" |
|||
!Domain |
|||
!Range |
|||
|- |
|||
|<code>*</code> |
|||
|'''3000-7999''' |
|||
|- |
|||
|<code>DOMAIN</code> |
|||
|'''10000-999999''' |
|||
|} |
|||
You could also have any trusted domains starting at: |
|||
:{| class="wikitable" |
|||
!Domain |
|||
!Range |
|||
|- |
|||
|<code>TRUSTED</code> |
|||
|'''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 <code>smb.conf</code> file: |
|||
* To locate the file, enter: |
|||
# smbd -b | grep CONFIGFILE |
# smbd -b | grep CONFIGFILE |
||
CONFIGFILE: /usr/local/samba/etc/smb.conf |
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] |
[global] |
||
workgroup = SAMDOM |
|||
security = ADS |
|||
realm = SAMDOM.EXAMPLE.COM |
|||
winbind refresh tickets = Yes |
|||
log file = /var/log/samba/%m.log |
|||
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 '<code>workgroup =</code>' during login etc (just 'username' instead of DOMAIN\username), add this line: |
|||
winbind use default domain = yes |
|||
{{Imbox |
|||
| type = note |
|||
| text = This will only work for the default domain. For any other domains, you must use 'DOMAIN\username'. |
|||
}} |
|||
For testing purposes only (remove for production), add these lines: |
|||
winbind enum users = yes |
|||
winbind enum groups = yes |
|||
{{Imbox |
|||
| type = note |
|||
| text = 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 <code>idmap config</code> lines to add:''' |
|||
:{| class="wikitable" |
|||
!Back End |
|||
!Documentation |
|||
!Man Page |
|||
|- |
|||
|<code>ad</code> |
|||
|'''[[Idmap_config_ad|idmap config ad]]''' |
|||
|<code>idmap_ad(8)</code> |
|||
|- |
|||
|<code>rid</code> |
|||
|'''[[Idmap_config_rid|idmap config rid]]''' |
|||
|<code>idmap_rid(8)</code> |
|||
|- |
|||
|<code>autorid</code> |
|||
|'''[[Idmap_config_autorid|idmap config autorid]]''' |
|||
|<code>idmap_autorid(8)</code> |
|||
|} |
|||
:{{Imbox |
|||
| type = important |
|||
| text = Add an additional ID mapping configuration for every domain. The ID ranges of the default (<code>*</code>) domain and other domains configured in the <code>smb.conf</code> file must not overlap. |
|||
}} |
|||
== Mapping the Domain Administrator Account to the Local <code>root</code> 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. |
|||
{{Imbox |
|||
| type = note |
|||
| text = You can optionally map the domain Administrator account to the local <code>root</code> account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as <code>root</code> on the Unix domain member. If you do map Administrator to the <code>root</code> account, Administrator will be unknown to the OS and will not be able to log onto a Unix domain member. Only follow the method below to map <code>Administrator</code> to <code>root</code>, never give Administrator a <code>uidNumber</code> attribute, doing this will break the default Administrator mapping on a Samba AD DC. |
|||
}} |
|||
To map the domain administrator to the local <code>root</code> account: |
|||
* Add the following parameter to the <code>[global]</code> section of your <code>smb.conf</code> file: |
|||
username map = /usr/local/samba/etc/user.map |
|||
* Create the <code>/usr/local/samba/etc/user.map</code> file with the following content: |
|||
!root = SAMDOM\Administrator |
|||
# 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. |
|||
# Just adding one of the following three lines is not enough!! |
|||
# Please follow the links. |
|||
# |
|||
# - [[idmap_config_ad|use the winbind 'ad' backend.]] |
|||
# Or |
|||
# - [[idmap_config_rid|use the winbind 'rid' backend.]] |
|||
# Or |
|||
# - [https://www.samba.org/samba/docs/man/manpages-3/idmap_autorid.8.html use the winbind 'autorid' backend.] |
|||
:{{Imbox |
|||
See the manpage of "smb.conf" for detailed information about the parameters and options used. |
|||
| type = important |
|||
| text = When using the <code>ad</code> ID mapping back end, never set a <code>uidNumber</code> attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID <code>0</code> of the <code>root</code> user on Samba AD DC's and thus the mapping fails. |
|||
}} |
|||
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page. |
|||
= The domain join = |
|||
'''<u>A note on provisioning</u>:''' A Domain Member <u>must not</u> 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: |
|||
= Joining the Domain = |
|||
* To join the host to an Active Directory (AD), enter: |
|||
# net ads join -U administrator |
# net ads join -U administrator |
||
Line 114: | Line 333: | ||
Joined 'M1' to dns domain 'samdom.example.com' |
Joined 'M1' to dns domain 'samdom.example.com' |
||
* To join the host to an NT4 domain, enter: |
|||
If you encounter any error message(s), see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]]. |
|||
# net rpc join -U administrator |
|||
If you use the parameter : bind interfaces only = yes in smb.conf, join with : |
|||
Enter administrator's password: Passw0rd |
|||
Joined domain SAMDOM. |
|||
{{Imbox |
|||
= libnss_winbind = |
|||
| type = important |
|||
| text = Do not provision or join a domain member using the <code>samba-tool</code> utility. These options are unsupported and can cause problems with your AD replication. The options will be removed from <code>samba-tool</code> in a future release. |
|||
}} |
|||
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]]. |
|||
Domain users and groups are made available to your local system through libnss_winbind. The [[#Setup_a_Domain_Member_smb.conf_file|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. |
|||
= Configuring the Name Service Switch = |
|||
'''Important:''' If you have compiled Samba, you may need to add two symbolic links. See [[Libnss_winbind_Links|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. |
|||
To enable the name service switch (NSS) library to make domain users and groups available to the local system: |
|||
* Append the <code>winbind</code> entry to the following databases in the <code>/etc/nsswitch.conf</code> file: |
|||
passwd: files <u>winbind</u> |
|||
group: files <u>winbind</u> |
|||
:* Keep the <code>files</code> entry as first source for both databases. This enables NSS to look up domain users and groups from the <code>/etc/passwd</code> and <code>/etc/group</code> files before querying the Winbind service. |
|||
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail. |
|||
= Start daemons = |
|||
:{{Imbox |
|||
Depending on how you use your Domain Member, you have to start different daemons: |
|||
| type = note |
|||
| text = If there's a line containing an <code>initgroups</code> directive, add <code> [success=continue] winbind</code>, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add the <code>initgroups</code> line if it does not exist. |
|||
}} |
|||
:{{Imbox |
|||
For a pure Domain Member (domain logons only): |
|||
| type = note |
|||
| text = Do not use the same user names in the local <code>/etc/passwd</code> file as in the domain. |
|||
}} |
|||
:{{Imbox |
|||
# winbindd |
|||
| type = note |
|||
| text = If you compiled Samba, add symbolic links from the <code>libnss_winbind</code> library to the operating system's library path. For details, see [[Libnss_winbind_Links|libnss_winbind Links]]. If you used packages to install Samba, the link is usually created automatically. |
|||
}} |
|||
= Starting the Services = |
|||
For Domain Members [[File_sharing|sharing directories (file server)]] and/or [[Setup_a_Samba_print_server|printers (print server)]]: |
|||
Start the following services to have a fully functioning Unix domain member: |
|||
# smbd |
|||
# nmbd |
|||
# winbindd |
|||
* The <code>smbd</code> service |
|||
'''Note:''' You do not start the 'samba' daemon on a domain member. |
|||
* The <code>nmbd</code> service |
|||
* The <code>winbindd</code> service |
|||
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. |
|||
:{{Imbox |
|||
| type = note |
|||
| text = If you do not require Network Browsing, you do not need to start the <code>nmbd</code> service on a Unix domain member. |
|||
}} |
|||
:{{Imbox |
|||
| type = note |
|||
| text = You must not start the <code>samba</code> service on a domain member. This service is required only on Active Directory (AD) domain controllers (DC). |
|||
}} |
|||
= Testing Winbindd user/group retrieval = |
|||
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services. |
|||
== wbinfo == |
|||
* 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. |
|||
You first need to check that Winbindd is able to retrieve domain users and groups. On a successful setup, the following commands will print all users/groups in your domain: |
|||
# wbinfo -u |
|||
administrator |
|||
krbtgt |
|||
guest |
|||
... |
|||
# wbinfo -g |
|||
enterprise admins |
|||
domain computers |
|||
domain admins |
|||
... |
|||
= Testing the Winbindd Connectivity = |
|||
== Sending a Winbindd Ping == |
|||
== Using domain accounts/groups in OS commands == |
|||
To verify if the Winbindd service is able to connect to Active Directory (AD) Domain Controllers (DC) or a primary domain controller (PDC), enter: |
|||
If you have correctly included [[#libnss_winbind|libnss_winbind]] in your system, the following commands should print all local system users/groups, followed by any local Unix users/groups and then the ones from the domain (see [[#libnss_winbind|/etc/nsswitch.conf order]]): |
|||
# |
# wbinfo --ping-dc |
||
checking the NETLOGON for domain[SAMDOM] dc connection to "DC.SAMDOM.EXAMPLE.COM" succeeded |
|||
root:x:0:0:root:/root:/bin/bash |
|||
bin:x:1:1:bin:/bin:/sbin/nologin |
|||
daemon:x:2:2:daemon:/sbin:/sbin/nologin |
|||
... |
|||
demo01:*:10000:10000:demo01:/home/demo01:/bin/bash |
|||
... |
|||
If the previous command fails, verify: |
|||
# getent group |
|||
* That the <code>winbindd</code> service is running. |
|||
root:x:0: |
|||
* Your <code>smb.conf</code> file is set up correctly. |
|||
bin:x:1: |
|||
daemon:x:2: |
|||
... |
|||
domain admins:x:10001: |
|||
domain users:x:10000: |
|||
... |
|||
'''Note:''' If you're <u>not</u> getting domain accounts/groups in that output, verify that |
|||
* [[#libnss_winbind|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|idmap config ad]], accounts/groups have [[Administer_Unix_Attributes_in_AD_using_ADUC|RFC2307 attributes]] set |
|||
* "winbind enum users" and "winbind enum groups" are set to "yes" in your [[#Setup_a_Domain_Member_smb.conf_file|smb.conf]] |
|||
== Using Domain Accounts and Groups in Operating System Commands == |
|||
=== Looking up Domain Users and Groups === |
|||
Any domain accounts/groups shown by getent or id can be used in the OS, i.e. |
|||
The <code>libnss_winbind</code> library enables you to look up domain users and groups. For example: |
|||
# id demo01 |
|||
uid=10000(demo01) gid=10000(domain users) groups=10000(domain users),2001(BUILTIN\users) |
|||
* To look up the domain user <code>SAMDOM\demo01</code>: |
|||
# chown demo01:"domain users" file.txt |
|||
# ls -s file.txt |
|||
-rw-------. 1 demo01 domain users 992 18. Oct 2015 file.txt |
|||
# getent passwd SAMDOM\\demo01 |
|||
SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash |
|||
* To look up the domain group <code>Domain Users</code>: |
|||
# getent group "SAMDOM\\Domain Users" |
|||
SAMDOM\domain users:x:10000: |
|||
= Authenticating Domain Users Using PAM = |
|||
=== Assigning File Permissions to Domain Users and Groups === |
|||
''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.'' |
|||
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 <code>demo01</code> domain user and the group to the <code>Domain Users</code> domain group, enter: |
|||
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt |
|||
== 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|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. |
|||
= Setting up Additional Services on the Domain Member = |
|||
On a Samba domain member, you can additionally set up: |
|||
== Configure PAM == |
|||
* File shares to act as a file server. For details, see [[Samba_File_Serving|Samba File Serving]]. |
|||
* Print services to act as a print server. For details, see [[Print_Server_Support|Print Server Support]]. |
|||
* PAM authentication of domain users for local services. For details, see [[Authenticating_Domain_Users_Using_PAM|Authenticating Domain Users Using 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: |
|||
#%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 settings used in the example above, please consult the [http://www.linux-pam.org PAM] documentation and the manpages of pam.conf and pam_winbind. |
|||
= Troubleshooting = |
|||
For details, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]]. |
|||
== 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 [[File_sharing|share directories (file server)]] or act as an [[Setup_a_Samba_print_server|print server]]. |
|||
[[Category:Active Directory]] |
|||
[[Category:Domain Members]] |
|||
[[Category:NT4 Domains]] |
Revision as of 09:13, 12 November 2019
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 laid out on this page. |
All AD Domain members must be in the same DNS domain and the Realm must be the DNS domain in uppercase. |
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
, orwinbindd
processes, shut down the processes.
- If you previously run a Samba installation on this host:
- Backup the existing
smb.conf
file. 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
*.tdb
and*.ldb
files. 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
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.
For NetworkManager, set the DNS server using either the graphical interface or nmcli and restart the NetworkManager service. The visible /etc/resolv.conf file:
nameserver 127.0.0.53 search samdom.example.com
won't list the DNS server explicitly but nevertheless works correctly.
At this point, if you are joining a new AD DC, then its records will not exist, so there is no point in testing for them. Continue with joining your new AD DC and return here, if required, once the join has succeeded. |
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
or host
commands. The nslookup
command is available on Linux and Windows.
Forward Lookup
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
alternatively you can use the host
command:
# host DC1.samdom.example.com DC1.samdom.example.com has address 10.99.0.1
Reverse Lookup
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 1.0.99.10.in-addr.arpa name = DC1.samdom.example.com.
or
# host 10.99.0.1 1.0.99.10.in-addr.arpa domain name pointer 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
or
$ 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.
Error Messages
- 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 1.0.99.10.in-addr.arpa: NXDOMAIN
- The DNS server used is not available:
;; connection timed out; no servers could be reached
Configuring Kerberos
Samba supports Heimdal and MIT Kerberos back ends. To configure Kerberos on the domain member, set the following in your /etc/krb5.conf
file:
[libdefaults] default_realm = SAMDOM.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true
The previous example configures Kerberos for the SAMDOM.EXAMPLE.COM
realm.
The Samba teams recommends to no set any further parameters in the /etc/krb5.conf
file.
If your /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 /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.
Preparing a Domain Member to Join an NT4 Domain
For joining a host to an NT4 domain, no preparation is required.
Installing Samba
For details, see Installing Samba.
Install a maintained Samba version. For details, see Samba Release Planning. |
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 (uidNumber , gidNumber , etc) are not added automatically when users or groups are created, you must add them manually. |
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
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), add this line:
winbind use default domain = yes
This will only work for the default domain. For any other 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 ad
idmap config ad idmap_ad(8)
rid
idmap config rid idmap_rid(8)
autorid
idmap config autorid idmap_autorid(8)
Add an additional ID mapping configuration for every domain. The ID ranges of the default ( *
) domain and other domains configured in thesmb.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.
You can optionally map the domain Administrator account to the local root account on a Unix domain member. Configuring the mapping allows the domain Administrator to execute file operations as root on the Unix domain member. If you do map Administrator to the root account, Administrator will be unknown to the OS and will not be able to log onto a Unix domain member. Only follow the method below to map Administrator to root , never give Administrator a uidNumber attribute, doing this will break the default Administrator mapping on a Samba AD DC. |
To map the domain administrator to the local root
account:
- Add the following parameter to the
[global]
section of yoursmb.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, never set auidNumber
attribute for the domain Administrator account. If the account has the attribute set, the value will override the local UID0
of theroot
user 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'
- To join the host to an NT4 domain, enter:
# net rpc join -U administrator Enter administrator's password: Passw0rd Joined domain SAMDOM.
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. |
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
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.
- Keep the
- Do not add the
winbind
entry to the NSSshadow
database. This can cause thewbinfo
utility fail.
- Do not add the
If there's a line containing an initgroups
directive, add[success=continue] winbind
, otherwise the NSS library will not ask winbindd for a user's additional group memberships. Do not add theinitgroups
line if it does not exist.
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:
# 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
winbindd
service is running. - Your
smb.conf
file is set up correctly.
Using Domain Accounts and Groups in Operating System Commands
Looking up Domain Users and Groups
The libnss_winbind
library enables you to look up domain users and groups. For example:
- To look up the domain user
SAMDOM\demo01
:
# getent passwd SAMDOM\\demo01 SAMDOM\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash
- To look up the domain group
Domain Users
:
# 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.
Troubleshooting
For details, see Troubleshooting Samba Domain Members.