Setting up Samba as a Domain Member: Difference between revisions

From SambaWiki
mNo edit summary
(41 intermediate revisions by 4 users not shown)
Line 13: Line 13:




{{Imbox
| type = important
| text = For versions of Samba earlier than 4.15.0, 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. For example, the <code>DNS</code> domain could be <code>samdom.example.com</code> and the Realm would be <code>SAMDOM.EXAMPLE.COM</code>.
}}




Line 25: Line 34:


* If you previously run a Samba installation on this host:
* If you previously run a Samba installation on this host:
:* Remove the existing <code>smb.conf</code> file. To list the path to the file, enter:
:* Backup the existing <code>smb.conf</code> file. To list the path to the file, enter:


# smbd -b | grep "CONFIGFILE"
# smbd -b | grep "CONFIGFILE"
Line 44: Line 53:
== Preparing a Domain Member to Join an Active Directory Domain ==
== Preparing a Domain Member to Join an Active Directory Domain ==


== Configuring DNS ==
=== Configuring DNS ===


For details, see [[Linux_and_Unix_DNS_Configuration|Linux and Unix DNS Configuration]].
{{:Linux and Unix DNS Configuration}}






== Configuring Kerberos ==


Samba is either compiled against Heimdal Kerberos or MIT Kerberos.


=== Configuring Kerberos ===
The Kerberos file <code>/etc/krb5.conf</code> needs to only contain the following:

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:


[libdefaults]
[libdefaults]
Line 61: Line 70:
dns_lookup_kdc = true
dns_lookup_kdc = true


The previous example configures Kerberos for the <code>SAMDOM.EXAMPLE.COM</code> realm.
Using anything other than the above, could lead to errors.


The Samba teams recommends to no set any further parameters in the <code>/etc/krb5.conf</code> file.
You will need to replace <code>SAMDOM.EXAMPLE.COM</code> with your KERBEROS realm.


If your <code>/etc/krb5.conf</code> contains an <code>include</code> line it will not work, you '''Must''' remove this line.
= Configuring Time Synchronisation =





=== 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]].
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]].
Line 71: Line 86:





== Local Host Name Resolution ==

=== 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.
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.
Line 99: Line 116:


For joining a host to an NT4 domain, no preparation is required.
For joining a host to an NT4 domain, no preparation is required.






= Installing Samba =
= Installing Samba =
Line 114: Line 135:


= Configuring Samba =
= Configuring Samba =



Samba can use various winbind idmap backends, The three main ones are:
* ad
* autorid
* rid


=== Choosing an idmap backend ===

It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.


* If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.


If you use the 'ad' backend, 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, you can 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 it would definitely be a good idea to use a different range.


* If you only need users and groups to have Unix IDs, you can use the 'autorid' or 'rid' idmap winbind backend.


The 'autorid' or 'rid' idmap winbind backends 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. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.


Once you Have decided which winbind idmap backend to use, you have to choose 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 SAMDOM domain users and groups: ADUC, by default, starts these at 10000
The default domain '*' also known as the 'well Known SIDs': ????
Trusted domains: ????
Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????


As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' 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.

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 default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain 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 should only be used with the 'autorid' idmap backend.



== Setting up a Basic <code>smb.conf</code> File ==
== Setting up a Basic <code>smb.conf</code> File ==
Line 122: Line 214:


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


To create a basic smb.conf using the 'autorid' idmap backend, you will need something like this:
* Edit the <code>smb.conf</code> file and set the following configuration:


[global]
[global]
Line 134: Line 226:
log level = 1
log level = 1
# Default ID mapping configuration for local BUILTIN accounts
# Default ID mapping configuration using the autorid
# and groups on a domain member. The default (*) domain:
# idmap backend. This will work out of the box for simple setups
# - must not overlap with any domain ID mapping configuration!
# as well as complex setups with trusted domains.
idmap config * : backend = autorid
# - must use a read-write-enabled back end, such as <code>tdb</code>.
# - Adding just this is not enough
idmap config * : range = 10000-9999999
# - You must set a DOMAIN backend configuration, see below
idmap config * : backend = tdb
idmap config * : range = 1000000-2000000


:For information on the parameters, see the <code>smb.conf(5)</code> man page.
For information on the parameters, see the <code>smb.conf(5)</code> man page.


The following table lists the most important idmap backends with links to their documentation, click the relevant <code>Documentation</code> link for how to setup each idmap backend:
* '''You must add an ID mapping configuration, for each domain that you want Samba to be aware of, to the <code>[global]</code> section of your <code>smb.conf</code> file.'''
* '''You must click on one of the following hyperlinks to find information about the Samba domain back ends:'''


:{| class="wikitable"
:{| class="wikitable"
Line 166: Line 254:
|-
|-
|<code>hash</code>
|<code>hash</code>
|
|[[Idmap_config_hash|idmap config hash]]
|<code>idmap_hash(8)</code>
|<code>idmap_hash(8)</code>
|-
|-
|<code>ldap</code>
|<code>ldap</code>
|
|[[Idmap_config_ldap|idmap config ldap]]
|<code>idmap_ldap(8)</code>
|<code>idmap_ldap(8)</code>
|-
|-
|<code>nss</code>
|<code>nss</code>
|
|[[Idmap_config_nss|idmap config nss]]
|<code>idmap_nss(8)</code>
|<code>idmap_nss(8)</code>
|}
|}
Line 182: Line 270:
| 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.
| 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 ==
== Mapping the Domain Administrator Account to the Local <code>root</code> User ==
Line 189: Line 280:
{{Imbox
{{Imbox
| type = note
| type = note
| text = Mapping the domain administrator to the local <code>root</code> account is optional. Only configure the mapping if the domain administrator must be able to execute file operations on the domain member using <code>root</code> permissions.
| text = You should 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. When you 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.
}}
{{Imbox
| type = note
| text = If you have changed the domain Administrator account name, use the new admin name in the following instead of <code>Administrator</code>.
}}
}}

To map the domain administrator to the local <code>root</code> account:
To map the domain administrator to the local <code>root</code> account:


Line 204: Line 298:
:{{Imbox
:{{Imbox
| type = important
| type = important
| text = When using the <code>ad</code> ID mapping back end, do not set the <code>uidNumber</code> attribute for the domain administrator account. If the account has the attribute set, the value overrides the local UID <code>0</code> of the <code>root</code> user and thus the mapping fails.
| 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.
For further details, see <code>username map</code> parameter in the <code>smb.conf(5)</code> man page.






= Joining the Domain =
= Joining the Domain =
Line 221: Line 311:
Using short domain name -- SAMDOM
Using short domain name -- SAMDOM
Joined 'M1' to dns domain 'samdom.example.com'
Joined 'M1' to dns domain 'samdom.example.com'

{{Imbox
| type = note
| text = When you join a computer to an AD domain with <code>net ads join</code>, the computers forward dns record should be created (if not already existing), but, if your computer has a fixed ipaddress, you will have to create the reverse PTR record yourself.
}}



* To join the host to an NT4 domain, enter:
* To join the host to an NT4 domain, enter:
Line 227: Line 323:
Enter administrator's password: Passw0rd
Enter administrator's password: Passw0rd
Joined domain SAMDOM.
Joined domain SAMDOM.

== Joining the Domain with samba-tool (>4.15.0 only) ==


{{Imbox
{{Imbox
| type = important
| 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.
| text = Before Samba 4.15.0 , you could not join a Unix domain member using <code>samba-tool domain join</code>, this option was unsupported, did not work and would cause problems with your AD replication. You can only use <code>samba-tool domain join</code> if the Unix domain member has Samba >= 4.15.0 installed.
}}
}}


* To join the host to an Active Directory (AD), enter:
If you have problems joining the domain, check your configuration. For further help, see [[Troubleshooting_Samba_Domain_Members|Troubleshooting Samba Domain Members]].




# 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|Troubleshooting Samba Domain Members]].


= Configuring the Name Service Switch =
= Configuring the Name Service Switch =
Line 251: Line 349:


:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.
:* Do not add the <code>winbind</code> entry to the NSS <code>shadow</code> database. This can cause the <code>wbinfo</code> utility fail.

:{{Imbox
| 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
:{{Imbox
Line 257: Line 360:
}}
}}


:{{Imbox
* 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.
| 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 =


Start the following services to have a fully functioning Unix domain member:


* The <code>smbd</code> service
* The <code>nmbd</code> service


* The <code>winbindd</code> service


= Starting the Services =


:{{Imbox
To start the services on a domain member:
| 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.
}}


* Start the <code>winbindd</code> service to enable the name service switch (NSS) library to look up domain users and groups:


:{{Imbox
# winbindd
| type = important

| text = 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 <code>client min protocol = NT1</code> and <code>server min protocol = NT1</code> in <code>smb.conf</code>. Samba no longer recommends using SMBv1.
* If you set up file shares or printer services on the domain member, additionally start the <code>smbd</code> and <code>nmbd</code> service:
}}


# smbd
# nmbd


:{{Imbox
:{{Imbox
Line 280: Line 392:
| 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).
| 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).
}}
}}



Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or service files for other init services.
Line 319: Line 432:
# getent group "SAMDOM\\Domain Users"
# getent group "SAMDOM\\Domain Users"
SAMDOM\domain users:x:10000:
SAMDOM\domain users:x:10000:




=== Assigning File Permissions to Domain Users and Groups ===
=== Assigning File Permissions to Domain Users and Groups ===
Line 325: Line 440:


# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt
# chown "SAMDOM\\demo01:SAMDOM\\domain users" file.txt






= Setting up Additional Services on the Domain Member =
= Setting up Additional Services on the Domain Member =

Revision as of 19:21, 28 April 2022

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.



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, or winbindd 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:
# 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:
# 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.




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.



Configuring Samba

Samba can use various winbind idmap backends, The three main ones are:

  • ad
  • autorid
  • rid


Choosing an idmap backend

It can appear to be a complex decision choosing which winbind idmap backend to use, hopefully reading this can point you to the one to use.


  • If you require users and groups to have the same IDs everywhere, or have different login shells and Unix home directory paths, then you need to use the winbind idmap 'ad' backend and add RFC2307 attributes to AD.


If you use the 'ad' backend, 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, you can 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 it would definitely be a good idea to use a different range.


  • If you only need users and groups to have Unix IDs, you can use the 'autorid' or 'rid' idmap winbind backend.


The 'autorid' or 'rid' idmap winbind backends 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. Using these idmap backends, you do not add anything to AD and any added RFC2307 attributes will be ignored. When using these backends you can set the 'template shell' and 'template homedir' parameters in the smb.conf global section and everyone will get the login shell and Unix home directory path you set. If you do not set 'template shell' or 'template homedir', the defaults, '/bin/false' and '/home/%D/%U' , will be used.


Once you Have decided which winbind idmap backend to use, you have to choose 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 SAMDOM domain users and groups: ADUC, by default, starts these at 10000
   The default domain '*' also known as the 'well Known SIDs': ????
   Trusted domains: ????
   Anything that isn't a 'well Known SID' or a member of SAMDOM or a trusted domain: ????


As you can see from the above, if you are creating a new domain, you shouldn't set either the default domain '*' or the 'SAMDOM' 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.

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 default domain '*' range above the 'SAMDOM' domain range, the ranges will conflict if the domain grows to the point that the next ID would be the same as the default domain 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 should only be used with the 'autorid' idmap backend.


Setting up a Basic smb.conf File

Before joining the domain, configure the domain member's smb.conf file:

  • To locate the file, enter:
# smbd  -b | grep CONFIGFILE
  CONFIGFILE: /etc/samba/smb.conf

To create a basic smb.conf using the 'autorid' idmap backend, you will need something like this:

[global]
       security = ADS
       workgroup = SAMDOM
       realm = SAMDOM.EXAMPLE.COM

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

       # Default ID mapping configuration using the autorid
       # idmap backend. This will work out of the box for simple setups
       # as well as complex setups with trusted domains.
       idmap config * : backend = autorid
       idmap config * : range = 10000-9999999

For information on the parameters, see the smb.conf(5) man page.

The following table lists the most important idmap backends with links to their documentation, click the relevant Documentation link for how to setup each idmap backend:

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)
hash idmap_hash(8)
ldap idmap_ldap(8)
nss idmap_nss(8)



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.

To map the domain administrator to the local root account:

  • Add the following parameter to the [global] section of your smb.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

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.

Joining the Domain with samba-tool (>4.15.0 only)

  • 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 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.
  • Do not add the winbind entry to the NSS shadow database. This can cause the wbinfo utility fail.

Starting the Services

Start the following services to have a fully functioning Unix domain member:

  • The smbd service
  • The nmbd service
  • The winbindd service





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:



Troubleshooting

For details, see Troubleshooting Samba Domain Members.