SUSE Support

Here When You Need Us

Configure Samba File Server with AD Users

This document (000020593) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15 SP4
SUSE Linux Enterprise Server 15 SP3
SUSE Linux Enterprise Server 15 SP2
SUSE Linux Enterprise Server 15 SP1
SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server 12 SP4
SUSE Linux Enterprise Server 12 SP3
SUSE Linux Enterprise Server 12 SP2
SUSE Linux Enterprise Server 12 SP1
SUSE Linux Enterprise Server 12

Situation

Recent CVE patches have removed fallbacks in samba behavior leading to more particular configuration needed in ID mapping to communicate with the AD server.

Resolution

Some Pre-requisites

  1. AD join is completed. See TID: https://www.suse.com/support/kb/doc/?id=000018831
  2. SMB is configured
    1. 12SP5 Documentation: https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-samba.html
    2. 15SP3 Documentation: https://documentation.suse.com/en-us/sles/15-SP3/html/SLES-all/cha-samba.html
  3. If you choose to use SSSD, but also want to run a samba file server, then running winbindd is mandatory since samba 4.8. In that situation, when a user establishes an SMB session, SSSD provides the NSS information and smbd delegates the user authentication to Winbind. Additionally, it requires careful setup because both services will attempt to renew the computer account password at regular intervals which can end in one daemon or another not able to login.

Option 1: Using Winbind

  1. Install required packages:

    # zypper in samba
    
  2. Prepare the shares directory:

    # mkdir /srv/share1
    # chgrp "EXAMPLE\\Domain Users" /srv/share1
    # chmod g+w /srv/share1
    
  3. Configure shares in /etc/samba/smb.conf:

    [share1]
    path = /srv/share1
    read only = no
    
  4. Configure idmap settings: It is important to select the appropriate idmap backend for your needs and to set the ranges properly. See the following TID for options and examples: https://www.suse.com/support/kb/doc/?id=000017458 Example in the “[global]” section of the /etc/samba/smb.conf:

    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config EXAMPLE : backend = rid
    idmap config EXAMPLE : range = 20000-29999
    
  5. Enable and start samba daemon:

    # systemctl enable smb
    # systemctl start smb
    

Option 2: Using SSSD

In this setup sssd will provide the NSS information for the AD users and winbindd will perform the authentication of the SMB sessions. It is not possible to run smbd without winbind. The fallback behavior where smbd contacted the domain controller directly was removed in samba 4.8.

Also, after CVE-2020-25717 patches, it is necessary to properly set up the idmap settings because fallback behavior ignoring the domain was removed.

For more information please see: https://www.suse.com/support/kb/doc/?id=000020533

  1. Install required packages:

    # zypper in samba samba-winbind
    
  2. Both SSSD and Winbind change the machine account password at regular intervals by default. This can be a problem because the SSSD daemon stores the machine account password in the system keytab and samba stores it in the secrets.tdb file. If/When the password is changed by one of the services, the other service will stop working since it now has an outdated password.

    To prevent this problem, we have to tell samba to update the system keytab as well when the machine password is changed. The netbios name of the AD server will be needed for the workgroup parameter.
    Add to the /etc/samba/smb.conf:

    [global]
    workgroup = EXAMPLE
    realm = EXAMPLE.COM
    security = ADS
    kerberos method = secrets and keytab
    

    Likewise we can tell SSSD to update the secrets.tdb file. Add to the /etc/sssd/sssd.conf one of the following parameters:

    [domain/example.com]
    
    # To update samba's secrets.tdb, *or*
    ad_update_samba_machine_account_password = true
    
    # To disable password changes.
    # If the AD server requires password changes this will not be an option.
    ad_maximum_machine_account_password_age = 0
    

    Restart SSSD after any changes:

    # systemctl restart sssd
    
  3. Join to the domain:

    If the computer was already joined to the domain using adcli, we need to join again using “net” to create the secrets.tdb file for samba. Since we have also configured samba to update the system keytab, we can join using the “net” utility (”-U” could also be used. Either way the AD user must be able to create/modify computer accounts):

    # kinit Administrator
    # net ads join -k
    
  4. Prepare the shares directory:

    # mkdir /srv/share1
    # chgrp "EXAMPLE\\Domain Users" /srv/share1
    # chmod g+w /srv/share1
    
  5. Configure shares in /etc/samba/smb.conf:

    [share1]
    path = /srv/share1
    read only = no
    
  6. Configure idmap settings:

    After CVE-2020-25717 patches it is necessary to set the correct idmap settings so winbindd will get the NSS information for AD users from sssd through NSS. It is important to select the appropriate idmap backend and to set the ranges properly. See the following TID for options and examples: https://www.suse.com/support/kb/doc/?id=000017458

    Example in the “[global]” section of the /etc/samba/smb.conf:

    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config EXAMPLE : backend = nss
    idmap config EXAMPLE : range = 200000-2000200000
    
  1. Start Winbind and samba daemons:

    # systemctl enable smb
    # systemctl enable winbind
    # systemctl start smb
    # systemctl start winbind
    

Test

Any user should be able to replace "user1" below. Keep in mind that the command won't work if the foo.txt file already exists in the share (/srv/share1):

# touch foo.txt
# smbclient //localhost/share1 -U EXAMPLE\\user1 -c 'put foo.txt'
Password for [EXAMPLE\\user1]:
putting file foo.txt as \\foo.txt (0,0 kb/s) (average 0,0 kb/s)
ls -l /srv/share1/
total 0
-rwxr--r-- 1 user1 domain users 0 feb 18 13:51 foo.txt

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000020593
  • Creation Date: 28-Sep-2023
  • Modified Date:28-Sep-2023
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.